I like the evolutionary approach of the Linux kernel's development model means that version numbers are arbitrary labels:
Anyway, regardless of all that, this obviously
means that the merge window (*) will open tomorrow.
[...]
(*) I'll likely call it 6.0 since I'm starting to
worry about getting confused by big numbers again.
The new version of the Linux kernel is out and we can just get on with our lives.
I don't think there's anything good or insightful in Linus' approach to version numbers. I think he just doesn't care about it at all, and so why not have some fun.
In my view version numbers either have a significance (semver & co.) or just get rid of it and use something derived from a date. Because why is it 5.19 then 6.0 and not sqrt(2) and tomorrow we try negative numbers?
No software depends on a specific kernel version number, thankfully, so as a sysadmin I'd rather have Linux 2022.5.2 (year.sequential-number.patch) than 5.19. Possibly unpopular idea since I get bashed every time I criticize Linux and its versioning, as if I shouldn't dare question it.
That's an interesting perspective. I am also a sysadmin and I sometimes care about the kernel I run (I run the Zen kernel on my XPS running Arch), but I also don't really find much value in the version number unless it has a feature I need/want. Like you, it wouldn't add or detract for me to know that a feature I want is in kernel 5.19 vs version 2022.5.2.
Huh, although, the one question I'm not sure about would be LTS releases. For some reason -- in my head, at least -- it feels unorganized to mark a version based on date as an LTS. I guess Ubuntu does that and it doesn't bother me but for some reason I have a double standard with the kernel.
Tangent: is there an official timeline where the decided support lifetime for the kernel versions are? Something like Ubuntu's lifecycle table[1]? I ask because there was one time I was gonna run 5.10 but wasn't sure when it was EOL because Greg K H was going to shorten it but then decided to extend it.
Kernels in LTS releases are already weird. A RHEL kernel might have version 5.6 yet it's been released today with a ton of backports on top of a kernel that's years old.
If it's truly not broken (especially no security exposure), then sure, but that's rare, and Linux is good enough about backwards compatibility that there's generally no reason not to use a newer kernel.
On a personal note, the most interesting part here is that I did the
release (and am writing this) on an arm64 laptop. It's something I've
been waiting for for a _loong_ time, and it's finally reality, thanks
to the Asahi team. We've had arm64 hardware around running Linux for a
long time, but none of it has really been usable as a development
platform until now.
It's the third time I'm using Apple hardware for Linux development - I
did it many years ago for powerpc development on a ppc970 machine.
And then a decade+ ago when the Macbook Air was the only real
thin-and-lite around. And now as an arm64 platform.
Not that I've used it for any real work, I literally have only been
doing test builds and boots and now the actual release tagging. But
I'm trying to make sure that the next time I travel, I can travel with
this as a laptop and finally dogfooding the arm64 side too.
Ditto here - I've been using Asahi as my daily driver (development workstation) for over 3 months now with no plans on changing from it any time soon: https://jasoneckert.github.io/myblog/asahi-linux/
Hopefully rust language enhancements will finally merge into Linux 6.0
i believe Linus knows how significant RUST would be for multi-arch linux. This benign version bump should give all the C++ devs plenty of headroom to stay in a stable 5.x while the rustaceans oxidize the kernel ecosystem to make it (more) architecturally neutral, typesafe, easier to dev modules and more secure. Ive been a linux user since 0.97 and I can't recall being this excited about the future!
This is a perfect example of the type of blatantly ignorant (in the real meaning) message common on Reddit. The confidence with which you’ve just spoke out of your ass is astounding.
I don't think Linus cares about Rust at all. He's been hands off about it, he knows kernel devs would like to adopt it so he's neutral, but I'll bet a tenner he will not start writing Rust anytime soon, and, if I can be so presumptuous to make assumptions, I don't think he's much of a fan, for many of the same reasons he prefers C over C++. I think Linus would be more of a Zig guy.
I'm being tongue in cheek here, please do not read too much into this.
I think he'd just prefer to keep using C but I could be wrong. It feels like he is definitely married to C. If there was another language I felt he would adopt, it would of been Go had Go not adopted a GC.
You can learn the standard libraries of both and 10 years later they still are mostly the same. It is pretty commendable.
I honestly don't get how Go managed to get this fake "low-level language" image, but no, it is not at all a low-level language. Like how does it even enter the discussion over, say, Haskell?
Maybe because there was one of the original creators of C behind Go, and Pike is a de facto old school Unix guy? Many people, myself included, thought we'd get C but a little more modern and secure.
I don't get your comparison. Go is much lower level than Haskell, even with a GC.
> Go is much lower level than Haskell, even with a GC.
No, it isn’t. Can you actually show me anything that would imply that? Haskell can use pointers/FFI, etc. just fine. They are on the exact same level, the same way as countless other languages including C# and D.
I think we have a different definition of high-level.
To me it's not language features, but which "abstraction level" you operate in, and how far removed it is from how a CPU actually works. In Go or C, it's for loops and manual type conversions, in C# you have stuff like Linq, in Haskell you operate on monads and functors. So, compared to all of those, Haskell is much higher level than C# or C. I'd say even higher than Erlang, which doesn't have pointers.
Imagine an assembler language with a GC. If such an abomination existed, I would consider it to be lower level than C, because you're still closer to the machine, even if memory allocation is done for you.
I don’t know how objective your definition can be. Is Brainfuck high or low-level? It is quite similar to how a very primitive CPU operates, yet it is quite far from the actual CPU.
A more objective definition could be what is available to the programmer to control. Here, assembly is on the lowest level, C/C++/Rust on a higher one (with the difference in them being expressivity), and Js, Java, Haskell being even higher. In theory, you can do everything in a lower level language than what is possible in a higher level one, so you get an easy Litmus test to decide (and thus C++ and Rust are actually lower level than C, because they have language-level simd support)
C++ is insecure in memory and has infinite unexpected behavior. Rust, on the other hand, does not compare with it, as it is safe. Linus doesn't like C++ because it sucks.
If I recall correctly, Linus doesn't like C++ because it introduces abstractions that take control away from the programmer and delegates it to the compiler. Over time this just reduces the performance of the kernel, and makes it harder to find the root cause of faults and bugs.
In a parallel universe where Linus learns Rust, I can imagine many legendary rants where a new kernel developer tries to be smart with some obscure macro and then getting summarily shot down by him.
Yeah, Linus doesn't like C++ because of the abstractions and complexity, which Rust doesn't save us from. He'd rather have a less secure but simpler (and more widespread) language. That said, it's great of him to stay open minded and opening the doors to Rust in the mainline tree.
I think he's always been OK with C++, Python, Rust etc., for tooling around the kernel. But found that for the kernel itself, the performance and reliability guarantees were strict enough that he didn't want to risk there being performance or reliability issues caused by the compiler.
Performance/reliability issues caused by programmers can be found and rectified. Performance issues caused by compilers may not be replicable even between builds.
> how significant RUST would be for multi-arch linux
Er, isn't Rust's list of target architectures a subset of Linux's? Maybe after the Rust GCC frontend is prod-quality it would at least not be a regression (outside of architecture specific drivers)...
