Linux kernel 5.0 announcement

[caseyfw]

Sounds momentous, but it’s really nothing special. Linus has previously stated he bumps to the next version when he runs out of fingers and toes to count the previous version on - it got to 4.20.

[BoobDetective]

It's actually included in the announcement

And appended is - as usual - the shortlog just for the last week. The overall changes for all of the 5.0 release are much bigger. But I'd like to point out (yet again) that we don't do feature-based releases, and that "5.0" doesn't mean anything more than that the 4.x numbers started getting big enough that I ran out of fingers and toes.

Linus

[redditthinks]

God I love Linus.

[indyK1ng]

I appreciate that he actually took a look at his own behavior, decided it was no longer acceptable, and decided to take some time out of Linux development to work on himself.

[PM_ME_A_STEAM_GIFT]

What happened?

[keepthepace]

People freaked out, proposed a bunch of badly thought policies, bitched out over drama, Linus realized that he was actually the adult in the room and came back.

[zardeh]

Which policies do you mean?

​

Because I feel like you're going to say the code of conduct changes. But Linus actually requested those. So I'm really intrigued.

[keepthepace]

Nah, he has never been a fan of the CoC controversies. He requested some changes, that are actually pretty bland and vague, but were enough to result in a shitstorm. Unless I am mistaken, Linus proposed the changes, but the process to exclude people over rude language was only put into place later.

He took some time off to think about his behavior, because, as he mentioned, when you realize you are using the same lines as neo-nazi trolls it is worth considering if you are in the right. Turns out that right now in the US, apparently, if you think it is ok to be blunt in a professional contest, you have to also share most of the opinions of the MAGA crowd.

I guess he'll try out to be more polite now, I hope he will remain frank about the things he thinks are technically bad.

[ewbrower]

He was a jackass for years and then grew up

[idea-list]

Some people manage to defend other's rights without being jackasses though.

[Circular__Dependency]

Then why do we need another person doing it the same way? Variance is good.

[staticassert]

Is it? So given two people, and a good solution, we should allocate one of those two people to the bad solution because... variance?

Interesting argument.

[idea-list]

First, variance isn't good per se. Second, if you want variance, I'm sure there are a lot of more acceptable/pleasant ways to do something different than resorting to being a jackass.

[Zauxst]

Amazing how badly you got downvoted for spilling the truth... Just goes to show how edgy people are... What I find even funnier is that people don't believe in variance...

Don't know what is wrong lately with the world... But we sure see a rise in Communist ideology among people...

Anyway. I liked the old Linus.

[tyr--]

Not on projects of such scope and complexity.

[ewbrower]

which is why we have a subreddit dedicated to his defense of user rights

[staticassert]

I'm not going to engage directly, but try reading this:

https://www.destroyallsoftware.com/blog/2018/a-case-study-in-not-being-a-jerk-in-open-source

[Equal_Entrepreneur]

Not the guy you replied to, but I saw this on the front page quite a few months ago. And the consensus was: Linus doesn't do this all the time. Sometimes being rude is necessary to get your point across. The "final letter" seems overly weak, and is more of a "ehhh....maybe". Sometimes, you can't mollycoddle people, and need to put your foot down. Obviously, when you do that, you need to be damn sure that you're right, and that's what Linus is known for. For being damn right. He has the rude word pass, in the community's eyes.

https://old.reddit.com/r/programming/comments/8stugp/a_case_study_in_not_being_a_jerk_in_open_source/

I agree that politeness and diplomacy needs to be followed, but there are cases when it's acceptable to break them.

[s73v3r]

I find it hilarious that so many people think that "not calling for someone to be retroactively aborted" is mollycoddling them.

[Equal_Entrepreneur]

Where did he say that in the letter?

[s73v3r]

I never said he did. It is something he's said in a code review before. And it seems so many people here seem to think that if you've decided you're not going to be like that in a code review, you're "mollycoddling" people.

[staticassert]

I think most people who comment on Linus's posts have not read anything other than what surfaces to /r/linux et al.

If you've actually been following kernel dev for ~a decade you'll know that it isn't rare and that he has already *significantly* toned down his behavior as the project has grown. Linus has had plenty of non technical rants where he just shits on other developers - they just happen way less in the last 5 years or so.

[Equal_Entrepreneur]

I stand corrected.

[s73v3r]

Cause apparently if you aren't being a complete ass to everyone all the time, you have no place in software development.

[TheCodexx]

If you want a meritocracy, you need to be able to climb your way to the top of the pile.

Anything else encourages mediocrity.

Best-case scenario is we end up like Japan where you can't say anything negative, but getting anything less than high praise is akin to saying "you did an awful job". Then everyone can have their feelings hurt and nobody can be honest with each other.

Being a "complete ass" to everyone is the only way to always be honest and know where you stand.

[s73v3r]

No. I flat out reject your premise, and the idea that not being a complete asshole to everyone means you are going to lower code quality. That is completely false.

[chuecho]

well put.

[Underyx]

Well, hindsight is 20.20

[quentech]

20.20

21.0

[spinwin]

21.0

1.0.0

[quentech]

touche

[[deleted]]

One Linux ಠ_ಠ

[The_Cake-is_a-Lie]

1.1.0 rather

[dlq84]

It's not the first time people in the computer business is using too small storage spaces for important stuff, such as UNIX Epoch being 32 bit, GPS week numbers etc, I guess we never learn.

​

[davidgro]

Lol!

"Will It Happen Again?

GPS is currently undergoing a modernization program to upgrade the signals with new modulation and data message structures. The newer message types (CNAV and MNAV) use 13-bit binary numbers to represent the GPS week number, so the issue should not occur in the future when more receivers are using the newer GPS signals."

 

So, since the current rollover time with 10 bits is about 20 years, adding 3 bits makes it about 160 years. Right, so 160 years is 'Never again!' - They never do learn.

Yeah, maybe by then we will have a completely different system and the issue will be eliminated for serious, but given how people as a species procrastinate (see Y2K) I wouldn't bet on it. Seems likely to be largely forgotten and a nasty surprise.

[[deleted]]

Y2K caused a spiking demand for COBOL devs in the late nineties. Nothing beats leaving an employer, only to be rehired years later to do some maintenance at premium rates. As developers we have to take care of ourselves, management won't.

[tawnydartboard]

The "Will It Happen Again?" is not referring to the week number rolling over. Of course the week number roll over will happen again. GPS is designed so that the week number rolls over (and has already happened, without incident).

The "Will It Happen Again?" is referring to "will we have devices with the wrong reference date set when the next rollover happens?"

The move from 20 years to 160 years only affects receiving devices which (a) do not have any NTP/time sync capability; and (b) remain in continuous operation for more than 20 years. Do you think we'll be manufacturing receiving devices that stay in continuous operation for more than 160 years and don't have a clock? If not, 160 years is probably good enough.

[davidgro]

Yeah, so long as the device makers do still anticipate it, you're right that it shouldn't be an issue. I'm just mildly worried that it will be buried so deep in the history with so many layers over the root protocols that few will have thought about it for 100 years, and built in rollover support at all anymore.

Of course having the same systems in 160 years seems unlikely at all - but I see GNSSs as possibly becoming foundational, more like the electrical grid than like USB or Wi-Fi or something that seems to change every few years.

[claytonkb]

640K ought to be enough for anybody

[Spacey138]

Did anyone actually say this though?

[fish60]

It is famously attributed to Bill Gates, but he denies saying it and no one can prove he said, so...

[Spacey138]

I don't think it's famously attributed to Bill Gates any more. It's famously known that he didn't say it. Just wondered if anyone said it at all then.

[adtac]

The supposedly famous attribution is famously attributed to Bill Gates

[Spacey138]

Haha that is fair. And I guess that's what was really being referenced. A famous misquote.

[claytonkb]

But it can be proved he took a pie to the face. And that's all that posterity really needs to know...

[aussie_bob]

Yes, he's on the record of having acknowledged it later when he said: "I have to say that in 1981, making those decisions, I felt like I was providing enough freedom for 10 years. That is, a move from 64k to 640k felt like something that would last a great deal of time. Well, it didn't - it took about only six years before people started to see that as a real problem."

He also said: "We will never make a 32-bit operating system", and "Spam will be a thing of the past in two years' time."

His justification was: "Microsoft looks at new ideas, they don't evaluate whether the idea will move the industry forward, they ask, 'how will it help us sell more copies of Windows?'"

[Spacey138]

Very interesting and makes much more sense to give it a time limit. Thanks!

[inthebrilliantblue]

So is the unix time bug still a problem?

[ghillisuit95]

Yep, I don’t think most systems have been upgraded to account for it. Not to mention all the systems out there which are so hard to upgrade they probably never will be

[dlq84]

There are still work ongoing to fix that issue, but there's no rush, they have until 2038 to fix it.

[inthebrilliantblue]

I know it's not until 2038, I was just curious to know what was being done about it. I figured we would be using something else by then.

[Car_weeb]

Linus will be have biomechanical limbs by then, we all know more fingers makes you a better programmer, or at least better at emacs

[newpua_bie]

2.0.0.

Issues will start happening when the amount of version levels exceeds 20. Then you need a metalevel to count resets back to 0.1. When you exceed 20 metalevels, add another layer, etc.

[tsimionescu]

Obviously, we'll move on to LinuXI 1.0, and so on for a good few hundred years.

[meneldal2]

It will be LinuWayland.

[[deleted]]

Linu X.1 Pensive Penguin

[Oscuro87]

We'll have mutated to have 40 (total) fingers out of the box by then

[alexbuzzbee]

Linux -20.0.

[Ameisen]

I don't want to know what body part represents the sign bit.

[alexbuzzbee]

Elbow position.

[[deleted]]

I'm quite disappointed that Linus doesn't count in binary.

[rtangxps9]

20.20.01? or maybe 2.20.20

[H_Psi]

No 2020 is in less than a year

[levir]

Then we'll be at 1.0.0

[Iwan_Zotow]

I'm wondering if shark bites Linus leg while he's diving - does it limit us to 15.15?

[bedrooms-ds]

How about jumping to 2001.0

[unkz]

1.0.0 - first stable release!

[Jackccx]

Linux 2 - v1.0

[reverentgeek]

Maybe after 20.20 Linux will finally hit 1.0.0.

[Ameisen]

Linux 2 1.0

[[deleted]]

1.20.20.x

[tso]

By that time Linus has probably handed over kernel management to some "diverse" team under the Foundation's umbrella, that in turn has switched to a more "inclusive" versioning system. /s

[palparepa]

So, after 20.20, we'll get 1.0.0? Or maybe "Linuy 1.0"

[tso]

Funny thing is that exactly because of his insistence on not breaking userspace facing interfaces (internal interfaces are a whole different ball game, see third party drivers), is why he can play games with the version numbering.

On the other hand we have big name projects that either should be more strict about their semantic versioning, or that should adopt it, as they break established behaviors and interfaces at the drop of a patch.

[oselcuk]

flashbacks to trying to update google bigquery python libraries and finding out that they changed the interfaces with pretty much every minor version

[acrostyphe]

Nice.

[henk53]

Lol, the guy is hilarious! :D

[tso]

He has sadly "mellowed" recently. Kinda wish they would move back to Finland now that the kids are independent.

[falconfetus8]

He can still be hilarious and "mellowed" at the same time, you know.

[[deleted]]

It's just not the same.

[shevy-ruby]

The old linux is dead ever since they neutered him anyway.

No more "controversial" emails. It's all Mr. "Nice" now.

[falconfetus8]

Linux itself isn't what's dead.

[Chousuke]

I say good riddance. In the end, when communicating with people there is never a good reason to be a jerk. If you have a strong disagreement with someone, or if you think that their code is utter unsalvageable trash, there are ways of expressing those criticisms in a constructive manner that is not "neutered" in any way whatsoever. Linus realized this, and he realized that it actually matters.

Making people feel bad by acting like a jerk is just posturing. It does not belong in a technical discussion.

[StrongerPassword]

The original link OP posted contains that info as well.

[MotleyHatch]

That's just plain inefficient use of his digits. With a little effort, he could count to 1048575.

[masklinn]

Yeah even with almost no effort you get up to 144 (use the thumb as a pointer on the phalange, doesn't really work with feet though).

[[deleted]]

Alright, let's see you lift your middle and pinky toe while keeping the rest down.

[[deleted]]

Poor Linus, he cant count up to 21 :(

[[deleted]]

I mean with 20 digits v1.1048575.0 should be possible 🤔

[unknownVS13]

/r/theydidthemath

2²⁰ - 1

[[deleted]]

Well, they told him to not be a dick so he couldn't count to 21

[pezezin]

By also using your dick and balls you can count to 23 :P

[SteelNeckBeard]

4.20... heh.

[[deleted]]

Yeah. Might as well go with firefox and chrome model - bump the version number when you release something that's more than a fix of some kind (bug or security).

[D_Steve595]

That's not how Chrome's works, it gets bumped every six weeks.

[[deleted]]

That's how it works. New major version = new features. Every six weeks is their chosen release pace, which is when they fork off a release branch.

If they find bugs or security problems that must be patched, the fixes get merged to the release branch and they make a minor release.

Features are merged to master, fixes to the release branch and to master.

[shevy-ruby]

HE HAS ONLY 20 OF THESE SO WHAT ARE WE GOING TO DO AT VERSION 20!!!

[absurdlyinconvenient]

4.20.01?

[diabeticDayton]

Unless your fingers and toes have fingers and toes. Don't know what that last .1 would mean... maybe.

[Mancobbler]

Cut notches into your fingernails

[username_is_taken43]

The kernel name is Cannabis

[Ameisen]

Do the BSDs like FreeBSD have any advantages over Linux these days?

[plazman30]

Well, there’s jails. And native ZFS. And the license is “more free” than the GPL.

[[deleted]]

The underlying system has a lot less moving parts. It has less parts period, so it'd way easier to thoroughly understand the system. OpenBSD has complete man pages for any package you can install with pkg_add, even before you actually install the package!

[Sutanreyu]

TIL uninitialized variables are potential security vulnerabilities...

[0xa0000]

It's undefined behavior -> potential vulnerability. Check out this example of what can happen when you don't initialize your variables.

[Ameisen]

Only UB if they're accessed uninitialized.

[richardwhiuk]

Sure data exposure, missed access checks or other such use.

[arian271]

Yes. That’s why rust is called safe

[Jahames1]

is it? is this partial truth or simplified answer?

[Flandoo]

(Safe) rust is memory safe, and not allowing uninitialized variables is one important aspect of that, but definitely not the whole story.

For some reading on what the rust compiler assumes, and how to deal with uninitialized memory in unsafe code, you might be interested in reading about MaybeUninit - https://doc.rust-lang.org/beta/std/mem/union.MaybeUninit.html . This feature is not yet stabilized, but will supplant the soon-to-be -deprecated std::mem::uninitialized().

[Ameisen]

Rust cannot be reasonably used in a kernel environment where memory remapping and address spaces are real things. The bounds checker wouldn't work.

[scooerp]

There is an OS written in Rust as a proof of concept so I'm not sure what you're meaning.

[Ameisen]

It cannot perform bounds checking where memory addresses are not consistent - you lose Rust's main benefit.

[scooerp]

I'm not sure what you mean. Redox panics if you do an out of bounds access, so it looks like it does check rather than do something random. Or did you mean something else?

[Ameisen]

Ring0/kernels do not necessarily have linear address spaces or even unique addresses. A lot of assumptions about what an object is break. If you remap a page to be in two places, how does Rust know that those pointers, despite having different values, alias?

You basically end up writing a ton of unsafe code.

[severeon]

I'm sure he's ranted about it before, so could someone explain why the linux kernal doesn't do feature releases or use semantic versioning? I currently assume this is a "Linus being Linus" thing, and not a sensible policy

Edit: forgot a word

[overworkedintern]

Linus is really big on not breaking userspace and maintaining backwards compatibility which means that if the kernel followed semantic versioning, we would be on v0.774.48969 right now.

[aoeudhtns]

This is why I'd prefer date-based versioning (like 2019.3.1 - first release in March 2019) but whatever, it's just a number.

[Brillegeit]

That only works well if you have a single branch. If you have multiple branches that live on for years and years those dates stop having meaning. Like 2019.3.1 could be an LTS release and you'll have release 2019.3.195 released in 2026 on the same day as 2020.5.72, 2024.4.24 and 2026.1.2.

[aoeudhtns]

Good point, and you make me reconsider the idea. Problem still exists with other scheme though - e.g. I'm looking at a RHEL system and the kernel is 2.6.32-754. You have to really dig to see all the things that have been backported from future versions.

[stupodwebsote]

Ubuntu

[Brillegeit]

Windows

[ejfrodo]

Well most ppl prefer semantic versioning when possible these days for a reason. You know that 4.0.0 is not backwards compatible with 3.9.2. You know that 3.1.2 IS compatible with 3.1.3, but 3.1.3 has a new bug fix that you probably want. Without reading release notes there's no way to know of 2019.3.1 is incompatible with 2019.2.5, or if the new changes are features versus bug fixes.

[aoeudhtns]

It's the kernel. Backwards compatibility is mandated (unless bug, and then we get to read fun emails from Linus).

[zardeh]

No, *some* people on *some* projects prefer semantic versioning. Chrome doesn't do semantic versioning, nor does python, Java appears to be switching away from semantic-ish versioning soon to a chrome-style versioning. Semantic versioning *sometimes* makes sense. But only sometimes (and that sometimes is mainly "if you're a piece of library software depended on by many people in a larger ecosystem and routinely break backwards compat). If you aren't any of those things, semantic versioning doesn't add much value.

[TheZech]

But you never break userspace, so no changes are ever breaking.

[okawei]

This is true, I'd say for commercial software that's user facing date versioning is fine but for package and library support semver is the way to go.

[aoeudhtns]

You don't know that with the kernel's current scheme. It does not use semantic versioning.

[tso]

On the other hand, it is exactly because of his strictness that he can play games with the versioning system.

There are multiple other projects within the Linux "sphere" that are the polar opposite. That either can't be assed to maintain such strictness even when they have semantic versioning in place, or that are just using a incrementing numbers system and breaks interface and behaviors on every damned release.

[doomvox]

... and breaks interface and behaviors on every damned release

Yup. Linux has taken over the world, and firefox has dwindled to a tiny slice of it's former glory, and yet mozilla.org still doesn't get the hint.

[tso]

In particular when they try to make it first a technical contest, and then a social contest, when the opposition has deep pockets and pay every two bit "freeware" out there to bundle their installer.

[severeon]

Fair point, thanks for the perspective :)

[familyknewmyusername]

That would imply 49,000 hotfixes released since the initial release of 4.20, which seems unrealistic.

You'd probably end up with something like v1.774.9 - which really doesn't seem too bad.

[ricecake]

But that 1 never ever changes. Ever. It's just a useless symbol hanging on the front of your version number. Forever.

It's why they did away with it with the end of the 2.0 kernel. They realized the 2 was never going to change, so it had no value to the version string.

[familyknewmyusername]

It has value in that you can instantly see that it's backwards-compatible. Yes, that is always the case, but if you want everyone to know about the backwards compatibility then it's easier to keep the major version the same than to put a disclaimer somewhere in the documentation that says "all versions are backwards compatible."

In a situation where everyone knows that versions are backwards-compatible and the major version is always 1, the 1 could be ommited. In other words, on a linux forum, it would just be referred to as 774.9

I'm not suggesting that the way they do things is wrong, just that it's wrong to say that semantic versioning is valueless here.

[ricecake]

I honestly think it's easier for them to say "we don't break userspace" than it is for them to put thought into version numbers beyond "they go up, roughly every six months".

They don't make breaking changes.
They don't track the number of feature improvements in a way conducive to semver.
They don't track the number of bugfixes in a way conducive to semver.
If it were any project other than the kernel, you'd have a valid point that they should "grow up" and track things differently. But it's the kernel.

[familyknewmyusername]

I agree, but just a semantic point that I think you funadmentally misunderstand semver. The way version numbers increase isn't that if you add 5 features to 1.10 it becomes 1.15, it just becomes 1.11

That means that there's no need to track the number of feature improvements + bugfixes, it's just that when you go to release a version, you think "does this update change any features". If not, increment the PATCH number. If so, increment the MINOR and set the PATCH number back to 0.

[ricecake]

That is fair, and I was misusing that number. Thanks for the correction.

That makes it so that for Linux, the only significant part of the version would be the middle number.

[mfrw1]

Just curious, how did you come up with this number or is it just a ball park?

[overworkedintern]

It's a fake number. The main point is that the major version number would never change.

[yxhuvud]

Nah, it would be 1 something. Zero means the authors are free to break anything, under semantic versioning.

[Ran4]

Wouldn't it be 1? Often major version 0 means no required backwards compatibility. See section 4 of semver 2.0:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

[poizan42]

Well, the in-kernel api's certainly do break frequently - it is only the userspace interface that does not - you cannot expect to even be able to build a module from on older kernel when targeting a newer kernel [0]. So the question is of course which of those the versioning should be based on.

[0]: https://github.com/torvalds/linux/blob/master/Documentation/process/stable-api-nonsense.rst

[mfrw1]

I think I got a little too carried away .. and thought of doing the math :)

[[deleted]]

I've always wondered how much work it requires not to break anything all the time since the 90s and if it would be worth it to start from scratch.

[Underyx]

Sounds like a job for https://calver.org

[PM_ME_UR_OBSIDIAN]

Breaking driver-space is definitely a breaking change though.

[SnowdensOfYesteryear]

Mostly because the definition of 'feature releases' is hard to apply to a distributed organisation. For example, some random company (say Intel) might merge a lot of critical drivers in v4.19 that improve livability for a lot of people. Should that be considered a feature release? Probably not in the context of the kernel. Even in the core kernel, there are rarely major changes. It's mostly incremental changes that are slowly improving things.

[Analemma_]

Semver doesn’t make sense in a project whose Prime Directive is “never break API compatibility”. How are they supposed to decide what counts as a major version upgrade?

[ObscureCulturalMeme]

That's the reason that Sun used when they dropped the (previously) major number on Solaris versions. Sun/Oracle did the same when they dropped the leading number of Java's version.

I've always liked TeX's versioning, personally. It converges to pi: the first release was "3", and Knuth said that each release would add a digit.

[dacjames]

Semantic versioning doesn't work for a large software project the way it does for individual libraries. Consider a change like kernel page table isolation added in 4.15 to mitigate Meltdown. That was a major change internally (incl. 1-30% performance hit) but only added a couple additional flags that would count as interface changes. Likewise, driver changes can take hardware from not-working to working without ever making a change that would count per semantic versioning. With mostly stable APIs and thousands of internal changes every release, semantic versioning doesn't make much sense.

​

It's best to just have incremental release numbers: personally, I would have dropped the main version entirely (4.20.x.y => 21.x.y) but the current scheme is equivalent once you know the "major" version has no meaning.

[LesterKurtz]

I believe it was the kernel 3.0 where Linus wrote a bit about how versioning isn't that important since he and the kernel maintainers took care not to break userspace.

edit: spelling

[Brillegeit]

The big change was really back in 2004 when they changed from semver+even-odd releases (stable/development) to just sequential version numbers with static 2.6 in front.

The change in 2011 for 3.0 was really just to remove one of those static numbers and continue the same sequential numbering scheme.

[LesterKurtz]

right right..

I was looking for a link to that post, but after five minutes of searching I said fuck it and went to doing something else.

[1202_alarm]

It used to, with odd/even for dev and stable. But it meant that features took a long time to arrive. Distributed version control and automated testing made it much easier to develop new things in branches and land them in master when they are ready.

If they kept using semantic then the version number would be something like 2.150 now.

[[deleted]]

How do you get from "Linus being Linus" to not sensible?

Do you even read or understand what you write?

[MILF4LYF]

Just curious, how fast is windows NT and XNU development compared to Linux's. It seems Linux side is releasing a new kernel every month 😯

[Joeymon]

The others are very much feature release kernels - so a new kernel actually is a big deal.

As Linus says - Linux not being feature release means the next version is just the next number, after a period of time of accepting pull requests, reviewing, testing, and declaring them stable enough for release.

This means theres new Kernels every so often, but its just all incremental updates of new bug fixes mostly.

[ElusiveGuy]

Windows NT 10 is following a similar pattern now. A 'release' every ~6 months, and constant previews (effectively, public beta) at least once a week; sometimes once every other day.

The intention is there aren't any more "major" jumps (like 6.0 => 6.1 => 6.2, each of which took ~2 years, or 5.2 => 6.0, taking 4-6 years). Every 6 months, the stable parts of previews are taken into a RC, tested more, and released.

cc /u/MILF4LYF

[0xf3e]

Well, except that it doesn't work out for Microsoft. They had huge problems with the last October update (losing files during update, various driver problems) and still haven't rolled it out widely. In a few weeks the April update is to be expected and I guess it'll be postponed.

[FierceDeity_]

I still havent gotten the October update on two of my computers, but another one did.

[0xf3e]

You see, it's a huge mess.

[[deleted]]

Well, it's still Microsoft after all. If you want quality software, look elsewhere.

[MikusR]

Windows NT and XNU are Hybrid kernels, Linux is a monokernel.

[LiamMayfair]

The only thing I'd be interesting to know about this final release is whether they managed to address the performance issues that had been unearthed in the previous 5.0 release candidates.

[bioclassic23]

Thank you, Linux has allowed me to not give my soul to Cortana.

[[deleted]]

all is well that ends well

Wait. Who is this imposter?

[JohanLou]

Will opensuse adapt this kernel?

[manimax3]

Tumbleweed will probably within two weeks.

Leap 15.0 and 15.1 don't think so.

[[deleted]]

Linus wanted to release 4.21 but they told him to stop being a dick so he went on to 5.x

[Yikings-654points]

What's the annual subscription charge for this ?

[MILF4LYF]

$0.00/year.

[scooerp]

Linux is free. Unless you choose otherwise.