4 ms·
Major versions of Linux used to be awaited with bated breath. For many years I ran a "Linux kernel major release pool", which probably nobody here remembers,
by linsomniac 4y ago
Major versions of Linux used to be awaited with bated breath. For many years I ran a "Linux kernel major release pool", which probably nobody here remembers, but it was fairly popular. Npw, it's fairly boring when a new release comes out. Don't get me wrong, I don't think that's necessarily a bad thing...
- WastingMyTime89 4y agoIt’s mostly because Linux stopped having major release. Linus changes the first number when he finds that the second one is growing too big which apparently means twenty-ish.
- yjftsjthsd-h 4y agoI personally wish it had gone semver and the version expressed how "boring" and stable it was; "Linux 6.0" sounds like a big deal (but in spite of all the features and changes really isn't*), where "Linux 2.1028.0" would better reflect the reality IMO - smooth, stable progression. * EDIT: In the sense of being non disruptive and safe; the features are very non-boring:)
- capableweb 4y agoSemver makes sense when you want to have a way of breaking the API interface and signal that to people. If there is one thing I've learned from reading various messages from Linus on the mailing lists, is that WE DO NOT BREAK USERSPACE! So Linux would be perpetually on the same major version, which means there is little reason to use Semver in this case. Also, the first number gets updated whenever Linus feels like the second number gets too large, not sure how "2.1028.0" would solve that :)
- yjftsjthsd-h 4y ago> So Linux would be perpetually on the same major version, Yes:) > which means there is little reason to use Semver in this case. Okay, that's fair. If semver is there to signal breaking changes and there will never be breaking changes maybe it's not super useful. > Also, the first number gets updated whenever Linus feels like the second number gets too large, not sure how "2.1028.0" would solve that :) That's not "also"; I'm specifically saying that Torvald's versioning system is bad. Honestly I'd be happier with losing the leading number completely and doing an increment per feature release; right now the "major" version field just doesn't mean anything.
- creshal 4y agoSemver makes really no sense. The userspace ABI tries to never have breaking changes; yet the internal APIs for use by drivers, and indeed the drivers themselves, can have breaking changes every single release. Not that most users care, as most of the tens of thousands of devices supported are fairly obscure and the changes don't affect the other users… yet kernel API changes that break, say, Nvidia's drivers or ZFS or other high-profile out of tree drivers, have an outsized effect. You either have to increase the semver major version with every single release, or somehow version internal APIs separately, which isn't really practical either.
- bombcar 4y agoI still have scars from 2.4->2.6.
- kstrauser 4y agoThat was an exciting year, in the “our house is on fire” sense.
- Gibbon1 4y agoMy companies first embedded linux project was right smack in the middle of that. I think there were some big changes in gcc. NAND flash was relatively new. So much out of date docs, broken/incompatible code, and false starts.
- stusmall 4y agoI was working on an embedded system long after that transition happened. The BSP we got from the chip vendor was still targeting 2.4. We had to port all the drivers over ourselves. The long tail of old software in embedded world is ridiculous and painful
- mschuster91 4y agoAt least Android did a good job in forcing chipset vendors to keep up their BSPs with recent kernel versions... basically every chipset in use by anything with Android will have a decently modern kernel version. Now, if Google would also enforce open-source compliance... the amount of hoops one has to jump through to get OSS dumps is absurd, and most of these lack critical parts (e.g. build toolchain, kernel config, partition layouts, DTBs) so it's OSS in theory but unusable to develop alternative OSes in practice.
- midislack 4y ago2.4.15 was still the very best Linux kernel, everything bloated like crazy afterwards.
- ajsnigrutin 4y agoBut we did get alsa in our kernels :D
- saagarjha 4y agoThat’s because major releases are done when Linus feels like it, not because there’s something major in the new release.
- ajsnigrutin 4y agoI blame browsers for this... They were the ones who started the "version inflation", where a new major version meant almost nothing... and everything else followed slowly. The problem i see is, what's next? Google chrome is at 106... a few more years, and 200.. 300? What happens if linus runs out of fingers for the major number too? I miss the "good old times", where 2.4.17->2.4.17.1 meant a minor patch, ->2.4.18 meant a new version with some new features, -> 2.6.x meant some large changes, and 3.x meant something huge, with possible backwards incompatibilities and making you choose, between a mature 2.x version vs a newish 3.x version.
- eesmith 4y agoThe "good old times" include Solaris 2.6 -> Solaris 7 ;)
- gruturo 4y agoWhile true, that was also SunOS 5.6 to SunOS 5.7. One name for the marketing brochures, one for techies (and their scripts). Works for me.
- ChrisRR 4y agoLinux version 2 was release in June 1996, and v3 in July 2011 15 years later. Everything in-between was incremental. This massively predates web browsers with 100 versions
- ajsnigrutin 4y agoLinux v3 should be 2.6.40 Also in 2011 firefox went from "slow versioning" (up to version 4) to a new major version number every few months... the unofficial reason was, that chrome was "overtaking" firefox in version numbers, and "higher number == better browser" (chrome went from 9 to 16 that year).