That's a shame. Having a "project" is what kicks off learning the cool bits about computers. If you can't do it with the devices we're giving kids, we are robbing our future inventors.
I’ve noticed most of the people we hire these days for dev roles have no idea how computers or operating systems work. I’ll have someone with a pretty impressive title reach out to me with a basic OS question, and I wonder how they got to where they are without this foundational knowledge. Most of this stuff I learned on my own when I got my first computer.
There are people here on this forum openly admitting they don’t see how ‘knowing Linux’ is useful, so no point actually learning it.
I have no idea if they really never learn and wing it until they become managers or become great cloud engineers who simply scale up instead of running strace.
I don’t know how someone uses modern dev tools without understanding some very basics of the Linux CLI. I see this all the time. If a command in some documentation isn’t a straight copy/paste, they’re done for.
Knowing Linux is different than knowing how to use a CLI.
I dislike that the two are conflated.
Firstly, Mac and Windows both offer a very mature command line interface.
But also, I don’t think knowing Linux should require you to know the command line either. If other operating systems don’t require it, neither should Linux.
If you’re focusing on “developer tools”, even then, what tools do most devs need that can’t be done from a UI? I live a lot of my time in the terminal but there’s very little that can’t actually be wrapped in a UI
all your points are valid, and you don't "need" the knowledge but it sure feels like the UI can get in the way of some things, mislead your formation of a mental model, or reduce the clarity & density of information. I find most source control tools with mouse-driven UIs like this.
I think CLI tools can help compartmentalise functionality and that can be helpful.
But I think they can also obscure functionality the same way as a GUI tool.
Take git for example, it’s much easier to visualize how it works from a GUI. Squashing is also faster in a GUI. But some other operations are clearer when you’re giving every flag yourself.
Ultimately I think it comes down to the UX of something regardless of the form of UI it’s presented in.
Let me flip that around on you: why would someone need to know Linux specifically for the majority of jobs out there?
I’m very familiar with Linux. My day job for years was Linux based and I honestly do not think one needs to know it, or any other OS specifically , unless your job specifically requires it.
Your question is a trap because you’re not qualifying what type of job you’re talking about. I could say “because your code runs on Linux and you should learn it” and then you’ll just say “well I wasn’t talking about jobs writing code running on Linux”.
Assuming the discussion is about a typical developer that runs code that is deployed to “the cloud”, and the cloud is basically 99% Linux, yes. You absolutely need to know enough about how Linux actually works to be effective at your job. Otherwise you’ll fall into the sort of trap zillions of “big data” engineers fall into, where you spend countless hours writing custom code that takes up terabytes of RAM that could have been a simple sed/awk/grep pipeline that uses a handful of kilobytes.
Surely, if my question is a trap then so is the initial premise I’m replying to?
It doesn’t specify a job and that’s exactly what I’m calling out.
Even your response assumes that a “typical” developer is one who deploys to the cloud , but what is that based off of? And how many of those need to interact with the cloud infrastructure itself?
Your second point about taking up terabytes of RAM doesn’t really matter if it’s on the cloud or not, and certainly doesn’t matter if it’s Linux . It’s also assuming that you can’t have a UI frontend that just calls the necessary efficient code or CLI commands behind the hood.
So my question remains: what percentage of jobs actually require you to know Linux specifically?
We can apply the principle of charity and assume that because OP was making this complaint at all, it was probably in the context of jobs where ostensibly there is plenty of value in learning Linux. You don’t need to ask for qualification here, it’s just assumed by context that, for OP’s point, these were probable roles that really should have Linux knowledge.
But you turn that around and say “but why would you need Linux knowledge??!”, taking the least-charitably-possible interpretation of OP’s comment, as if they’re talking about janitors or something, challenging them to prove why the majority of jobs (!!??!!??) needs Linux knowledge.
I dunno man, maybe because in their head they’re referring to a category of people for whom working Linux knowledge really should be expected, and it’s assumed that readers of their comment will probably understand that, and that they’re not going to be prompted to qualify every last thing they say.
But sure. Yeah. Linux technically refers only to a Kernel and not the whole OS so people shouldn’t say “learning Linux” if they only mean a CLI and a basic unix-like environment. You’re very smart, thank god you’re here to clarify all of this for us.
I need to stop with HN for a while, the level of pedantry has gotten absolutely out of control and I’m getting angry just reading this shit.
> There are people here on this forum openly admitting they don’t see how ‘knowing Linux’ is useful
That could literally apply to any job, especially as a developer.
And then the rest of your inane rant is about something I didn’t say. I didn’t say anything about linux being limited to the CLI, in fact my other comments say Linux is much more than the CLI.m. So now you’re just inventing your own argument to be angry about.
So maybe take your own advice, and give a charitable reading instead of getting angry because you’re unable to make a point. Because not only did you take the least charitable version of what I said, you invented arguments I didn’t make.
And maybe you should take a break from the internet if things make you this angry this easily.
Yes, I wasn't specific enough: it comes from developers. I can see how frontend devs don't want to 'learn Linux' but not wanting to learn how to configure an HTTP server because 'this is Linux' is at the very least poor taste.
Now, talking about people who actually deploy code to backends... these are the folks I had in mind. I imagine most of them don't deploy to Windows Server and they sure aren't deploying to any macos backends.
I think you’re arguing backwards from the assumption that people aren’t learning those skills because it’s Linux versus the actual learning of the skill itself.
Why would a frontend dev need to know how to configure a http server beyond what node or wamp/lamp gives them?
The number of full stack people is very low compared to dedicated backend and frontend folks. People focus on the needs of their job, and if their job doesn’t require wearing both hats they usually don’t go out of their way to do it.
Even at many companies that deploy things to the cloud, they’ll have dedicated folks for that because the people writing the code to run are busy writing the code.
That it eventually runs on Linux is not very meaningful to most devs unless their app needs special compiling configurations or libraries.
Re frontend devs not knowing how to configure an HTTP server: it's literally the front end. Caching, cors, cookies, maximum request sizes, these are all things frontend devs should know to work effectively as a team with the backend folks, but the backend folks gladly help out, usually. I'm not even saying they should know basics of DNS even if I think they should if they want their work load into their customer's browsers quickly. I can accept the browser is the OS and whatever happens outside of it is dark magic, like I said it is just poor taste.
> Even at many companies that deploy things to the cloud, they’ll have dedicated folks for that because the people writing the code to run are busy writing the code.
And this is the root of the problem. A week's worth of coding sure saves them a day of configuring their host systems, not to mention optimizing their cloud spend up. The folks who actually know how the system works and how to diagnose when it doesn't are in short supply and are also effin busy.
> That it eventually runs on Linux is not very meaningful to most devs unless their app needs special compiling configurations or libraries.
This is true only until it isn't. There can be times of coasting and then the dreaded base image version bump comes and 90% of the organization has no clue if they're impacted or how to check if they are.
But most frontend devs don’t need to do any of the things you’ve mentioned. By your own comment, they have a backend team who handle it and they work in concert. Would it be nice if they could understand each other better? Sure but most backend folks aren’t picking up JavaScript and UI frameworks either , or learning about browser tech.
And all the stuff you mentioned can be done by learning those skills on windows or Mac. Linux doesn’t really need to factor in, and now you’re saying to learn an entirely new operating system in addition to a new skillset.
You’re trying to say they should be more than what they are, but for a scenario they can’t predict coming up? In which case any number of other things might happen too, and there is likely already a team of people better suited to handle those issues. What would the sales pitch be to have someone learn it?
I think there’s an impedance mismatch between what you expect to provide value to someone as a hypothetical future goal and what they actually need to achieve their objectives.
The sales pitch is the difference between being a programmer and an engineer: one writes code, the other solves business problems. The value delivered by good engineering may be less than a lucky coder who doesn't have time to learn the tools of the trade, but this is expected: engineering is making sure luck doesn't matter for the business, within the operational envelope and in the assigned budget.
Linux is important if that's what the backend deploys to. If it is, it's a part of the operational envelope - I am saying engineers should have familiarity with what production is running on. I don't particularly care where those skills are being picked up as long as you know that on the production box there's strace instead of dtruss and you know how to check what the D state process is waiting for or whatever interesting issue arises which only happens under load, with networked storage and with at least a couple dozen cpus. (This is also why I don't care for frontend devs to 'know Linux', but having some knowledge about HTTP and their production HTTP servers would be beneficial, as would be knowing that networks aren't magic...)
Thanks! I share it from time to time, but I thinking HN algos doesn't like it, or maybe others don't think it's as cool as you.
Hopefully once I have a full tech stack (or at least an editor+shell) actually working it will get some more interest. In the meantime... you could share it, I certainly won't object!
Thunderbolt is capable of doing this, but USB has had support for peer to peer and alternative client support for quite a while. USB OTG (On-The-Go), which allows a USB client device to also act as a host, has been around since the 2.0 spec. This is what lets USB devices like phones and tablets also connect to card readers, keyboards, and other USB devices.
What Thunderbolt can do however that is quite magical, is operate as a point to point network interface. Driver support can be a bit dodgy, but it's totally feasible to build a 3 node compute cluster with point to point cluster node networking over Thunderbolt at 20 Gb/s.
Just off the top of my head, Ross Scott on youtube (AccursedFarms) has plenty of videos on the subject. A few of them are tucked away in reviews but he now has a dedicated "dead game news" series.
These may not be games you'd want to play but the important message is that it's concerning that the biggest publishers (Ubisoft, EA etc.) can release stuff that will randomly die at some point in the future for no good reason and that they won't even release a patch or server software so you can play the product you paid them for.
You're talking about games that were online-only where the servers have been shutdown. This is not at all what the comment I'm responding to is about, which is games that rely on a DRM that connects to the internet to validate your installation, meaning that even full solo, fully offline games would stop working.
It's a fun little thing but BEWARE! It's still a bit buggy and crashy* and rough around the edges. You can kinda see what Zep is going for but a lot of it is quite mysterious and there's little in the way of API docs (as-in, people are having to print all the global lua tables to figure out how to do stuff)
*Not as much as 0.1a but there's still kinks to be worked out for 0.1c.
I've always wondered what Japanese console style games would look like on the Amiga and whether it was underpowered or I just didn't like the design of most of it's games.
Bonk got a fab conversion by Factor 5 but they were wizards.
From what I can tell, there isn't even a version of Roblox Studio available. Scratch seems to work though.