Hacker News Reader

Comment by oxff | Hacker News Reader

The issue with Kernel development is that it's a dying profession. Nobody is interested in it. That's why there's an attempt with sexy new language, to bring more developers to work on it.

Probably less than 30 people in the world understand the thing as a holistic entity. From evolutionary terms, there's a giant risk of losing relevant technical knowledge to keep it up in the future.

I do not support adding it to the Kernel, I think we should just throw away the kernel entirely, but I understand why they're looking at Rust.

View on HN

> The issue with Kernel development is that it's a dying profession. Nobody is interested in it.

That's a pretty wild assertion and files in the face of the highly active kernel development process.

e.g. > Linus has released 5.18-rc1 and closed the merge window for the 5.18 release... 13,207 non-merge changesets were merged during this merge window.

https://lwn.net/Articles/890119/

> I think we should just throw away the kernel entirely

That's the dumbest thing I've see on HN in some months. The kernel is deployed in hundreds of millions of devices worldwide and continues to be the dominant OS in many many sectors.

The issue is about the # of new developers joining the development if you look at the Linux kernel development as an organization, not about # of non-merge changesets merged.

> That's a pretty wild assertion and files in the face of the highly active kernel development process

No, OP is right. 99.9% of things added to the kernel in any given release are drivers (mostly for obscure server hardware that the average LKML lurker would never have access to). So while there's certainly active development, it's all centered around drivers, and the "kernel" part of the kernel are mostly stable (modulo the occasional greenfield project like eBPF). (Note that I said 99.9% of things added, I'm sure security patches make up a lot more than 0.01% of kernel patches).

> The kernel is deployed in hundreds of millions of devices...

There are billions of Android phones alone. Not to mention the huge numbers of servers, IoT devices, embedded computers, and all the SBCs in my closet.

To be charitable, they may have meant something more like 'personal devices which people use directly'. (Though maybe not - it would be odd to exclude servers, which are one of Linux's biggest 'clients'. Perhaps they meant to exclude the more mundane types: routers, lightbulbs, etc.)

That Linux kernel is full of Google specifics, uses a microkernel like architecture since Project Treble, can be compiled since years with clang, now uses Rust for Bluetooth drivers,...

https://www.androidpolice.com/2021/09/24/google-plans-to-bri...

Marketing,

"The timeline for shifting to an "upstream first" cycle for new features starts in 2023, with 2020-2022 dedicated to making it work for pre-existing functionality. The Pixel 6 is expected to be the first Android device to ship with the GKI and Linux kernel 5.10, marking a major step in this process."

Means this is still one year away, if it actually happens, and then only Pixel devices will support it anyway, as so far most OEMs couldn't care less.

Not to mention that upstream will never accept all the things that make Android Linux not really Linux.

Most embedded/embedded-like devices running Linux are running a modified version of the kernel with a heavily customized userspace. These are still Linux by any reasonable definition. I'll leave it at this.

The kernel isn't dying, it's niche. It always has been and it always will be.

Fortunately for the kernel, despite being niche, it has a rock-solid onramp forcing people to get into it. There will always be companies interested in the n'th degree of performance, both generally, and for some specific hardware. Someone has to go do the relevant kernel work for those things. So while you or I may never touch it, it is effectively impossible for a kernel like Linux to just rot away because nobody cares. It would require first a multi-year, if not multi-decade process of fading first.

nice?

It's on most of the smartphones on the planet. Plus it is the dominant server OS. Plus in the top 3 in many embedded categories (a highly diverse set of technologies)

In context, it should be clear that kernel development is a niche.

> It's on most of the smartphones on the planet.

Sadly enough, probably not for long: https://en.wikipedia.org/wiki/Fuchsia_(operating_system)

Haha, I heard another good one about a nun going into a bar..

Even if Fuchsia is crapware, Google has the money to keep polishing that ball of mud, and eventually force it as the new version of Android, quality be damned. The rest of the world will have no recourse but to switch. It will be painful for quite a while, but people will survive. I mean, people survive using Windows, and not enough people switch away from that, either.

I’m not saying that Fuchsia is necessarily bad, I’m saying that Google will do anything to get away from GPL code, including, if necessary, forcing Android to Fuchsia. It doesn’t actually matter if Fuchsia is any good.

From what I can see, the Fuchsia kernel is actually quite interesting. I like the foci on (1) capabilities and (2) message passing. It's not the most innovative thing in the known universe - in fact both of those concepts are of pretty late-80s-to-early-90s vintage, from the OOP boom when programmers were misspending their ill-gotten performance gains[0] – but they make a degree of sense. The userspace bits I'm less sure about. Like you say, it seems to be a non-GPL-ed clone of Linux. It's the kind of thing I'd expect of some cheap Chinese company. This kind of fragmentation is emphatically not a good thing for our industry and Google knows it, and I very much hope they don't get away with it, but I suspect its being a clone is exactly why it'll be a very easy transition to force on end-users. Programmers will never in a million years use it on the server side, though.

[0] https://en.wikipedia.org/wiki/Andy_and_Bill%27s_law

> Programmers will never in a million years use it on the server side, though.

Why not? Certain people are using microkernels, for christsakes. Why not Fuschia on the server?

The biggest obstacle might be drivers. A “server” is defined more loosely than “an Android phone”. An Android phone manufacturer has the incentive to make sure that drivers for that hardware exist in Android, regardless if Android is Linux-based or Fuchsia-based. And Google can make Android switch to Fuchsia, and therefore can control where that incentive leads. Google, however, does not control what runs on servers, and server hardware manufacturers know that if they don’t have a driver in Linux, they won’t sell very much of their hardware, since existing hardware run Linux-based systems.

I meant to say "unikernel." Don't know where that brain fart came from!

> Google, however, does not control what runs on servers, and server hardware manufacturers know that if they don’t have a driver in Linux, they won’t sell very much of their hardware, since existing hardware run Linux-based systems.

I'm not sure if "It's the way things are" is quite the argument its made out to be. Some server hardware is beginning to look more and more like a phone/Chromebook. And things do change. "Not in a million years" was the argument made against Linux compared to the traditional enterprise UNIX vendors and where are they now?

If Linux developers are actually afraid of that, then they should simply switch the license away from the GPL, or dual license it, or do anything else than what they're currently doing.

You might not know, but it’s commonly held not to be practially possible to switch the license of Linux, since its copyright is not owned by a single entity – it is owned in myriads of small portions depending on who wrote that piece. Some of those people have since passed away, their copyrights now being held by their descendants.

Yes I know, I've heard that a lot and it's a weak and harmful comment that kernel people should absolutely not be making. It actually pains me to see it typed again. You don't actually want a software project to be like that, it makes it very difficult to enforce the license when it actually needs to be enforced because you can't get consensus from all the copyright holders. It also increases the risk that some copyright holder (like one of those descendents) goes rogue and you have another Patrick McHardy situation.

If there really was enough reason and will to do it, they would just track down those people, or they would remove that code and replace it with something else. Just like they've done every time in the past when there was copyright problems. Just like any other big open source project has done when licensing became a problem.

It might or might not be a good idea in general to not have a centralized copyright holder entity, but at least it cuts down on the humongous license flame wars, which, incidentally, is what you would get if you actually wanted to go through with an endeavor such as you describe.

Anyway, what Linux developers might be afraid of can not be mitigated by simply switching to an MIT license. What would happen is basically some modern variant of this:

https://lwn.net/Articles/162686/

I think you're talking about users and they're talking about engineers.

Android Linux !== Linux.

> Probably less than 30 people in the world understand the thing as a holistic entity

As we only have two other "big" (popular) kernels to compare to this one, do you think they (Apple and Microsoft) have more people "holistically" understanding the entire kernel or less? Since the nature of those companies are closed-source, I'm fairly certain even less people understand those ones "holistically".

> I do not support adding it to the Kernel, I think we should just throw away the kernel entirely, but I understand why they're looking at Rust.

How would that work in reality? Re-use the existing tests to build a new kernel from scratch? Sounds like a very far-out idea that wouldn't help with any of the current problems, but I'm happy to entertain the idea and hear your reasoning here.

> How would that work in reality? Re-use the existing tests to build a new kernel from scratch? Sounds like a very far-out idea that wouldn't help with any of the current problems, but I'm happy to entertain the idea and hear your reasoning here.

While I would tend to agree that a full production replacement would be such a massive undertaking as to be impractical, https://github.com/nuta/kerla does something very like that - Linux userspace ABI on an all-new Rust kernel. (And even at this small scale, I find it mind-blowing that this worked)

Since they're complaining about maintainability, I assume they're advocating for microkernels?

AIUI, you can still build a minimal kernel that's easily understood as a whole. And patches to shrink the minimal build even further are highly sought after because they expand the usability of Linux in deeply embedded environments.

Oh no. We have some early career devs that put up patches to the kernel recently. They were super excited about getting to do that work, and it was a big day for them - as it should be it's awesome.

I guess I need to go let them know they are Nobodies. oxff said so.

There may not be many “big and professional” operating system projects but, at the hobby level, it seems that there is a lot of interest in kernel dev actually.

HaikuOS, SerenityOS, Redox, and ReactOS are all going strong. The BSDs continue to advance as well. Redox is written in Rust even.

I believe Google sees Fuschia as a true Linux competitor.

When you say “we should just throw away the kernel entirely”, what are you suggesting?

> That's why there's an attempt with sexy new language, to bring more developers to work on it.

At no point did any active kernel developer express any such sentiment. Nobody is worried about not being unable to attract new blood.

It's only spoken of in knowing glances, like Voldemort.

> I do not support adding it to the Kernel, I think we should just throw away the kernel entirely

What would you use instead?

> The issue with Kernel development is that it's a dying profession. Nobody is interested in it.

That's simply false. I'd love to work on the kernel. I have immense respect for the people who work on it. Only reason I haven't tried contributing code is I don't think I'm skilled enough.

> 30 people in the world understand the thing as a holistic entity

Probably a lot more than 30. There are probably more than 30 PhD students studying kernels at this very minute. However, I think you're right that no one is interested. People greatly underestimate the effect the kernel has on the full OS. They think it's "just" the kernel. This is why so many people keep saying that Windows will get a Linux kernel in Windows 10, no, 11, no, 12, etc. It's just a "kernel", like a grain of corn, something insignificant. So there isn't much interest in working on kernels. It's as unsexy as it gets.

Reply on news.ycombinator.com