Linux 5.19
lore.kernel.org
lore.kernel.org
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.
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.
Linux--5.19 == Linux+5.19
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.
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.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!
happens all the time
I'm being tongue in cheek here, please do not read too much into this.
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.
Performance/reliability issues caused by programmers can be found and rectified. Performance issues caused by compilers may not be replicable even between builds.
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 don't get your comparison. 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.
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.
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)
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)...