Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

The kernel absolutely does not do this "every few years".

Linux was written from day 1 in "ANSI C", which is C89 (Edit - it was actually C89 with GNU extensions. Thanks for the corrections). Only now, after 30 years of development, are they considering moving to C99, which is itself over 20 years old.



sort by: page size:

C90 is partly to blame is here. It rejects sensible code due to limitations of hardware and compilers older than Linux itself.

I find it hard to believe that a decades old compiler with an actual compile-in-one-pass limitation would produce something useful from the current kernel source. It's affecting the the entire kernel development just so that someone somewhere with an abandonware compiler doesn't get a shock of updating it once every 30 years.


Linux seems to have a policy of avoiding breaking changes. Nice for maintaining software, but it's not the best quality kernel as a result.

There is actually a similar question that is asked in the interview:

> Is there anything in the kernel which is not optimal, but would require a complete rewrite to address properly? In other words, the kernel is 30 years old and knowledge, languages and hardware have changed a lot in these 30 years: if you rewrote it from scratch now, what would you change?

And Linus' answer was very interesting for me - and after reading it, I would answer your question (tongue in cheek): "Never, because it seems that Linux developers were quite successful in starting all over again for quite some parts of the Linux kernel."

I guess it's not really an answer to your question, but kind-of ;)


So the Linux kernel is worse quality now than in 1991?

Those breaking changes often are years apart which I sn much better than what the kernel currently offers.

Stubbornness of Linux kernel maintainers. My understanding that your proposed behavior is the behavior on FreeBSD and OS X, and people have proposed bringing Linux in line.

Interesting. However, Last modified: 2014. There has happened a lot in the Linux Kernel since then. I wonder what the state of the art is nowadays and how it compares to the Kernel.

while I am certain this is a reality, it seems so unbelievable. I started using Linux back in December 1991 and it is just seems so unreal that the kernel is at v3.1; that on first glance this article seems fake.

Is it just me?


I'm not sure that it would be less confusing to do that. Old kernels are still maintained too, so you'd have new releases like 2018.42 still happening in late 2019. And then people would wonder why some server is running a "year old kernel" when exploits came out less than six months ago.

What's wrong with simple monotonically increasing digits?


Sigh. So yet another rewrite, which will result in yet another round of regressions. Hopefully, at the end of it we will have something better than yet another unofficial driver with partial functionality that lags behind in support for newer hardware.

It's a real shame that many things in Linux land are so badly designed/maintained that they have to be re-written from scratch every few years. The major exception being the base kernel itself I suppose.


This happens a lot with established systems. I also don't know which Linux kernel versions I'm using. Was relevant once, now most changes don't impact me anymore. They are quite specialized. ...

That's probably reasonable. The Linux kernel has historically been very good about not breaking existing compiled code by changing ABIs like this.

Right but I feel like you're missing the point of the article, since the latest version of something as long running as the linux kernel is unlikely to be flakey.

I'm talking about the kernel space itself, not the APIs exposed to userland to interface with the kernel from your application. Internal APIs and behaviors are mostly identical over the past ~20 years, and any changes are usually moved to a new export. I don't think this should be taken for granted.

The kernel doesn't change in Smooth Life, right ?

So they work on re-implementing something that is known to have been working just fine for the last 15 years, what justify a re-write? Are they going to maintain that forever and push Linux distro and the industry to move to that new solution?

They were advised months ago that this could happen and they kept going with that. It might suck as a user, but you have to respect whichever standards the Linux kernel asks for.

I've been running Linux for about 4 years now (Ubuntu -> Mint -> Fedora -> Arch over the first year or so, been on Arch ever since), and I've never had to recompile my kernel (I did choose to do it once, but this was because I was interested in trying it out rather than something not working right; I'm a bit masochistic that way).

"Why don't they just swap the NT kernel out for the Linux kernel" has been a pretty common catchphrase of Linux users for years. This isn't anything new.
next

Legal | privacy