Getting smart young people to contribute to Linux Distros (and BSD for that matter) to me is a tough job.
Linux kicked off in the 90s because young people at that time wanted a real OS, so Linux came out and people flocked to improve it.
Today, almost all kids use Cell Phones, which are all locked down. I think only a few young kids rely on PCs, thus the issue. I hope it can be solved at some point and good contributors can be found. Otherwise we will be left with just IBM Red Hat.
I suspect the same number of people want a real OS as before, the difference is that everyone now has an OS of a weaker kind that gives them access to the same web that we're all on. So it's a similar problem that we have on the web as a whole—it's not that there's less good content (there's actually dramatically more), it's that it's hard to find it in the deluge of bad content.
The trick that we have now is that young people with potential to be highly technical won't just come to us automatically like they did when we were 60% of the web. Instead we have to make a more conscious effort to do outreach and give people a taste of the power of real computing.
I agree with your assumption that there’s the same number of people who want a real OS as there ever was.
However, I believe there are more active distros and related highly-technical projects today than ever. So everyone has to share fewer contributors, except of course whatever the few hot/popular projects are (the latter is nothing new).
I do worry though. Major academic institutions are having to put freshmen in remedial computer classes to teach them what files, folders, and devices are.
The average persons is getting farther and farther away from an actual PC and deeper into the “app” world. Everything is moving to “the cloud”. Even software development is being pushed to virtual desktops/thin clients (look at GitHub workspaces [or whatever it’s called] as an example). The extremely large majority of software development today is web/cloud based. There are more and more of the non-technical buying “computers” that are really just glorified tablets.
At some point, likely not/hopefully not in our lifetimes, it could become unprofitable for manufacturers to build PCs or only a few remain and the costs become prohibitively expensive to anyone but for-profit companies/corps.
There are still a bunch of young ones on PCs because of gaming, unfortunately the gaming scene is chiefly on Windows. Proton and Steam Deck were improvements, but the market share is still heavily leaning towards Microsoft.
Maybe if things get better we could see a steadily increase in Linux users, as we are already seeing
> Getting smart young people to contribute to Linux Distros (and BSD for that matter) to me is a tough job.
I mean, they came with enthusiasm and a lot of hard work, brought a new language with many advantages (as said by the BDFL humself), dusted off the whole GPU stack, tried to formalize a bit the FS systems, then got shunned out by the greybeards because “muh youngsters and their religion”.
That's not really a fair representation of the argument, and the stereotyping of everyone who disagrees or expresses some caution as an old stubborn greybeard who refuses to learn anything new is exactly the thing people (rightfully) complain about.
I'm not going to spend half an hour (or more) doing a full detailed write-up in response to a lazy assertion, especially since your attitude does not resemble that of a person with genuine interest in understanding other people's viewpoints.
Stereotyping an entire viewpoint as you did in your previous comment is pretty much always wrong. I might be a bit more forgiving if it has included some context or details, but it doesn't. Your post is little more than an insult.
I will add that people having been choking each other over all sorts of technical stuff for as long as this "free software" thing has existed, because there are usually 20 ways to do anything and typically between 2 and 10 ways are reasonable. This is really nothing new and discussions surrounding Rust are really not that special.
> You're trying to convince everyone to switch over to the religion as promulgated by Rust, and the reality is that ain't gonna happen because we have 50+ filesystems in Linux. They will not all be instantaneously converted over to Rust. Before that happens, we will continue to refactor C code because we want to make the C code better. If it breaks the Rust bindings, at least for the foreseeable future, the Rust bindings are a second class citizen, and those filesystem that depend on the Rust bindings will break, and that is the Rust bindings problem, not the filesystem community at large problem, and that's going to be true for a long long time. And I think we just simply need to accept that, because the answer "you are not allowed to refactor the C code because it would break 5 critical filesystem that distros depend upon" is not a starter. So we'll see; I suspect the best thing to do is for you to continue maintaining your Rust bindings. Over time, there will be continued C code refactoring -- maybe we will start using kfree RCU. If that breaks Rust, we will find out whether this concepts of encoding huge amount of semantics into the type system is a good thing or a bad thing, and instead of trying to convince us to what is actually correct, let's see what happens in a year or two. And it will either work or it won't, and we will see, more likely, where does the pain get allocated. Because with most of these sort of engineering things it's almost always a pain allocation question.
> [...]
> You're not going to force all of us to learn Rust -- if I make a change, I will fix all of the C code, because that's my responsibility. Because I don't know Rust, I'm not going to fix the Rust bindings.
Some of his language is more emotionally charged than was productive, sure, but I think his underlying concern is reasonable: most kernel maintainers don't know Rust, and so when they make changes to C code, they won't be able to fix Rust clients of that C code. The Rust maintainers accept this, and agree to take responsibility for updating Rust code to match changes in C (which is contrary to the usual development workflow of the kernel, hence the concern over what happens if major distros start depending on Rust code).
Note also that Ts'o isn't objecting to including Rust in the kernel! His recommendation is to ship the Rust bindings and see "where the pain gets allocated" as the C code continues to evolve. (The idea being that either Rust's type system and borrow checker will make it easy to identify semantic breakages early, thus making Rust code lower-maintenance than C, or the Rust bindings will turn out to be fragile and high-maintenance, and that the best way to tell is by waiting to see).
I'm not a part of the Linux kernel community at all, and I certainly don't know all the context that led to Almeida leaving the project -- I imagine Ts'o's comments were a "straw that broke the camel's back" kind of thing. But the Linux kernel is a complex project and critical infrastructure, so surely concerns about organization and maintainability need to be hashed out before Rust can make it to production.
Also, Ts'o's comments struck me as some of the most reasonable out of that talk, at least from a technical perspective -- the next commenter after Ts'o objects to Rust in the kernel on the basis that its function call syntax reminds him of Java.
> (which is contrary to the usual development workflow of the kernel, hence the concern over what happens if major distros start depending on Rust code)
The issue here is that this wasn't decided in this moment: it was decided as soon as the Rust was approved to merge. You're right that it's a concern, which is why it was addressed back then, and so a few years later, bringing it up feels like an argument in bad faith rather than a genuine attempt to bring a concern to the table.
Just because it was discussed way back when doesn't mean everyone has to accept the resolution from that. People obviously think it wasn't addressed in a good way.
There's a lot that you can say about all of that, but calling it "bad faith" is not great, to put it mildly. I had seen the video before, but didn't realize the person speaking is Ted Ts'o (I'm sad case and don't recognize Linux developers by voice alone). Ted has spent about 30 years working on all of this stuff, including investing a great deal of his spare time on it. He isn't some sort of random internet troll or anonymous HN user. Dismissing his views as "bad faith" does not leave me impressed.
I don't see how anyone but Linus could sign off on changing something as large as "Rust code is now required to build the kernel." I'm also not aware of anyone suggesting that should change.
I know who Ted is as well. That's why I expect better behavior. Then again, I'm not involved in any way, so my opinions don't really matter.
> Just because it was discussed way back when doesn't mean everyone has to accept the resolution from that. People obviously think it wasn't addressed in a good way.
That's precisely it, and why we also usually call behavior like Ted's "passive aggressive", and why Steve is right to call it out as seemingly made in bad faith. The person to whom he should address his complaints is the decider, the BDFL, Linus Torvalds, not anyone else.
Snipping, delay tactics, bureaucratic maneuvering, and endless bike shedding can poison projects. If you think Rust in the kernel is a mistake (not -- you think, in good faith, this implementation detail or that is technically incorrect), you need to plainly express that view to the person who makes the decisions, instead of whining to and about the people doing good work, endorsed by project leadership.
It's fine to be on record that "this thing will never work". It's less fine to work non-constructively to kill something before it gets an opportunity to work.
Eh, it's no longer allowed to voice discontent in public once Linus has spoken? What a bizarre thing to say. This is never how kernel dev worked, or indeed, how most projects work. Linus is not and has never been a "I have decided, now everyone heed my edict"-type of BFDL.
A long-term contributor with a great deal of investment in the project phrased things in the moment in a way that perhaps wasn't too brilliant (he was clearly emotional/nervous/whatever, as can be heard from his voice), and now he's somehow a bad faith actor trying to poison the project? Again just completely bizarre.
You come out here with some pretty big accusations based on basically nothing other than "he strongly disagrees". Well, he, ehm, he is allowed to state those views. If you want to radically change how kernel dev works and expect people who have been working on this for 3 decodes to just nod and smile and voice disagreement only in the Approved Way™, then I think you will end up bitterly disappointed. That's not how it works anywhere.
You need to actually convince people. And yes, sometimes people will phrase things in a suboptimal way, but that doesn't mean they're acting in bad faith. Bizarre thing to claim with such aggression and force.
> Snipping, delay tactics, bureaucratic maneuvering, and endless bike shedding can poison projects.
So do your baseless accusations that border on character assassinations, or dismissing people's concerns as "bike shedding" that they're somehow no longer allowed to bring up.
If you want to hold people to high standards of kind, empathic, and careful communication, then start by employing those standards yourself. That is: it's okay to criticise Ted for how he handled things. It's not okay to guess at his motivations, dismiss his views outright, and things like that. One is (hopefully constructive) criticism. The other is a personal attack and exactly the sort of thing that toxifies these discussions.
> Eh, it's no longer allowed to voice discontent in public once Linus has spoken? What a bizarre thing to say.
I'm sorry you misunderstood me, because I said nothing about simply voicing one's discontent. I guess it needs to be stated explicitly:
Everyone, including Ted T'so, please feel free to voice your discontent.
My argument was only: When you do voice your discontent, please direct it to the right/responsible person (Linus) and not someone else. Or if it's easier for you: Don't shoot the messenger. Which I thought was clear when I said:
>> The person to whom he should address his complaints is the decider, the BDFL, Linus Torvalds, not anyone else.
> You come out here with some pretty big accusations based on basically nothing other than "he strongly disagrees".
I'm sorry, but recall you said:
>>> Just because it was discussed way back when doesn't mean everyone has to accept the resolution from that. People obviously think it wasn't addressed in a good way.
I only agreed with you about what I thought we both believed the problem to be: Ted, like some others, is frustrated by Rust being included in Linux, and is venting his frustration at the Rust for Linux maintainer, not Linus.
> So do your baseless accusations that border on character assassinations, or dismissing people's concerns as "bike shedding" that they're somehow no longer allowed to bring up.
To be very clear -- I didn't say these were examples of Ted's behavior, although I do think they are examples of bad behavior that have been directed at the Rust for Linux project. I thought was I clear in all my comments about what I believe the problem was re: Ted's behavior. I said Ted not taking his concerns directly to project leadership (Linus), and instead directing his ire at Wedson, was passive aggressive.
> It's not okay to guess at his motivations, dismiss his views outright, and things like that. One is (hopefully constructive) criticism.
Again -- I'm befuddled -- because I was responding to your own statement of the situation, quoted herein. If you read things differently now, 3 hours later, or you regret making that comment, because it was the first to guess at Ted's motivations, I'm fine to leave it here, but please refer to your own comment, before you start preaching to anyone else about good manners.
> When you do voice your discontent, please direct it to the right/responsible person (Linus)
He is not "the right person". The disagreement was on how to best integrate Rust in the filesystem code. That's up to the filesystem people. The great success from Linux comes from Linus not doing that kind of micromanagement. This is not how kernel dev works or has ever worked.
If "assume good faith and don't dismiss arguments as bad faith" is guessing at people's motivations then I guess I am shrug.
> He is not "the right person". The disagreement was on how to best integrate Rust in the filesystem code.
Linus is absolutely the right person because the subject for discussion was the inclusion of Rust for Linux in the kernel.
Despite this being very clear, you're now trying to conflate the "Filesystems in Rust" discussion with what you were referring to the broader Rust for Linux question.
I mean -- you're pretty slippery, but I can certainly remind you again of what you wrote:
>>>>> Just because it was discussed way back when doesn't mean everyone has to accept the resolution from that. People obviously think it wasn't addressed in a good way.
Now, I'm sure you remember what was being discussed "way back when"? Yes, it was the argument re: inclusion of Rust for Linux in the kernel, not the "Filesystems in Rust" discussion.
> If "assume good faith and don't dismiss arguments as bad faith" is guessing at people's motivations then I guess I am shrug.
I completely agree this is ordinarily the right way to act, but there are limits to what we can accept in good faith. When someone acts as passive aggressively as Ted T'so has, or as slippery and dishonest as you have here, even if it's embarrassing to me to have to point such things out, I think it's right to say "Wow maybe someone needs to have a talk with Ted or arp242". Despite your (bad) behavior, I still want someone to be honest and direct with you.
I don't know why you're so aggressive or insulting over a simple "let's assume good faith". I do know these sort of personal attacks you keep doing are explicitly disallowed on HN. So please just stop.
Rust on Linux will happen. One way or another. At the worst, one funeral at a time. I wouldn’t sweat it.
I remember a HN comment that I really liked and can’t find now that went something like:
You know what stopped me from programming? It wasn’t that I didn’t have a good computer. It wasn’t that I started later than all the other kids. It wasn’t that I had to work. Nothing. Nothing stopped me from programming.
There’ll always be folks like that. And I hope I’ll be like that for some thing too!
> Linux kicked off in the 90s because young people at that time wanted a real OS
It's easy to underestimate how inferior MS-DOS was, unless you lived through it. Windows (3.x and later 9x) was slightly better, but still had severe issues. Modern Windows is, from what I've heard, a lot better, so the incentive to migrate is not as strong.
> Today, almost all kids use Cell Phones, which are all locked down.
Not just cell phones; with Secure Boot and BitLocker, computers are more locked down too. In particular, BitLocker means that it's harder to share disk space between Windows and an alternative operating system; back in the MS-DOS (and Windows 9x) days, it was not unusual to install Linux in a directory (or a disk image file) on the same partition used by the other operating system.
> Not just cell phones; with Secure Boot and BitLocker, computers are more locked down too.
You can just disable secure boot, no? I just got a brand new laptop today, and I could just disable it. I know you can get Linux to work with it, but I can't be arsed to mess about with it and the practical security benefits for me are basically zero.
Also, don't underestimate the friction that existed in the 90s or early 00s. Nothing worked on Linux or BSD. My government sent me .doc files. Tons of stuff was Windows-only desktop software.[1] Mucking about with xfree86 -configure and /etc/X11/.... was far from easy or straight-forward. Internet access was far more rare and "just Google it" wasn't really a thing, etc. etc. etc.
If I look at the amount of effort I spent to "just get Linux running" back in 2000 or so when I first tried it vs. today, then I'm fairly sure the overall experience is a lot better today. Sure, you need to deal with some stupid nonsense, but that was always the case.
[1]: For all the hate the "modern web" gets from some people here: it does replace tons of crappy desktop stuff with an abstracted isolated VM which, among other benefits, makes running "alternative" systems like Linux or BSD far more viable.
> You can just disable secure boot, no? I just got a brand new laptop today, and I could just disable it. I know you can get Linux to work with it, but I can't be arsed to mess about with it and the practical security benefits for me are basically zero.
An imagined conversation:
“Mom, I want to disable secure boot so I can try a free operating system.”
“Oh no you don’t. Security is important.”
This won’t happen to anyone who actually knows what they’re talking about, but it’s having a real impact on the pipeline for getting there. The conversation isn’t as imagined as all that.
Systems like Ubuntu, Suse, etc. should "just work" with secure boot. This has been the case for over 10 years (Ubuntu starting with 12.04, in a quick check). I just run a custom hacked-up version of Void Linux because I'm cool like that, but no one new to Linux is doing that – they start out with Ubuntu or such, just as I started out with Mandrake back in the day.
Also I actually got my laptop with Ubuntu pre-installed, a concept that barely existed in 2000.
Some distros use the MS signed grub shim, but you can generally just go into the BIOS and whitelist whatever bootloader you installed (and optionally disable the factory-loaded MS keys, which I generally do, since I don’t dual boot).
Linux kicked off in the 90s because young people at that time wanted a real OS, so Linux came out and people flocked to improve it.
Today, almost all kids use Cell Phones, which are all locked down. I think only a few young kids rely on PCs, thus the issue. I hope it can be solved at some point and good contributors can be found. Otherwise we will be left with just IBM Red Hat.