Linux 5.19(lore.kernel.org)

72 pointsby jrepinc4 tahun yang lalu33 comments

lore.kernel.org

https://lore.kernel.org/lkml/CAHk-=wgrz5BBk=rCz7W28Fj_o02s0Xi0OEQ3H1uQgOdFvHgx0w@mail.gmail.com/T/#u

36 comments

nequo4 tahun yang lalu

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.

sph4 tahun yang lalu

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.

NullPrefix4 tahun yang lalu

Negative numbers would be hard to parse. Is Linux-5.19 version -5.19, the negative, or 5.19, the positive?

sph4 tahun yang lalu

The two minuses negate each other.

Linux--5.19 == Linux+5.19

heywoodlh4 tahun yang lalu

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.

[1] https://ubuntu.com/about/release-cycle

sph4 tahun yang lalu

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.

pkrumins4 tahun yang lalu

I just checked and I still have some older servers running 2.6.22 from almost 10 years ago. I like the saying: if it ain’t broke don’t upgrade it.

yjftsjthsd-h4 tahun yang lalu

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.

ah-4 tahun yang lalu

    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.

jasoneckert4 tahun yang lalu

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/

blt4 tahun yang lalu

excitedly waiting for video output and sleep to work on the laptops!

tux19684 tahun yang lalu

For anyone else that didn't know, Asahi is Linux crafted for the Apple M1 chip:

https://asahilinux.org/about/

rowanG0774 tahun yang lalu

Awesome! I remember Linus wanting to use the M1 macbooks but he was very somber on Linux working on there.

[deleted]4 tahun yang lalu

gigel824 tahun yang lalu

Oh no, is Linus switching over to the dark side? (using an Apple laptop)

darthrupert4 tahun yang lalu

X86 might not be the dark side, but it feels every day more and more like the Dark Age.

have_faith4 tahun yang lalu

Didn’t he use an Air for many years?

jjice4 tahun yang lalu

Yeah, he mentions this is his third Apple machine. He doesn't have anything against the hardware as far as I'm aware - just wants Linux to run on it.

[deleted]4 tahun yang lalu

brianhorakh4 tahun yang lalu

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!

edgyquant4 tahun yang lalu

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.

sph4 tahun yang lalu

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.

giancarlostoro4 tahun yang lalu

> I think Linus would be more of a Zig guy.

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.

kaba04 tahun yang lalu

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?

sph4 tahun yang lalu

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.

kaba04 tahun yang lalu

> 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.

sph4 tahun yang lalu

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.

kaba04 tahun yang lalu

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)

claudiojulio4 tahun yang lalu

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.

kcexn4 tahun yang lalu

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.

sph4 tahun yang lalu

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.

kcexn4 tahun yang lalu

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.

yjftsjthsd-h4 tahun yang lalu

> 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)...

CaliforniaKarl4 tahun yang lalu

C++? The Linux kernel is written in C, not C++.

smegsicle4 tahun yang lalu

must be confusing linux kernel with windows kernel

happens all the time

[deleted]4 tahun yang lalu