The second number has over time generally went from 0 to 19, at which point the first number incremented, meaning 20 versions each. The only exception to this so far was kernel 4.20
15:33 this reminds me of a rumor about why Windows 9 was skipped, because apperently lots of software would hardcode checking Windows 9x for 95/98 and making Windows 9 would trigger those checks so they just skipped to Windows 10.
ironically that check would be fine if they looked for a second number at all. I don't see why you wouldn't do that. The only thing that would actually cause that is checking for windows 9 followed by anything.
The only reason I doubt this is that windows doesn’t actually report that version anywhere, it always reports version 6 and has done so ever since they had the exact same problem Linux did in the shift from xp to vista. XP had been around so long a ton of sw was just looking for “version 5.x” and the move to 6.x broke it. After that they just never incremented again.
I confess that I was today old when I found out that the "odd=development, even=stable" procedure is no longer a thing ... Somehow that seems to have stuck in the back of my head. Thanks for mentioning that!
I've been using Debian since spring 1994. In those days kernel images were not included in the repositories, so to update the kernel you had to compile it yourself. I remember writing a few scripts to help with the process. Things became easier when make-kpkg came along. This package compiles the kernel source code and produces a .deb file that you can install using dpkg. To this day, I still compile the kernel rather than use the one in the (unstable debian) repository. I'm currently running kernel version 6.7.1. which I compiled 8 days ago. (edit: I see 6.7.2 is the latest stable version. It seems I'm already running an obsolete kernel).
It's almost like the major minor releases served a purprose more than 'bigger number better', and it's interesting to see such .... weirdness in the kernel space... because it's only a hint of what's under the hood.
Any sort of semver would have been pointless in any case. Linus's rule is "you don't break userspace," so communicating breaking changes by major version would have been completely pointless.
Calver would be very nice to have though, i.e. first digit being the year of release like with ubuntu. Since many major distros also use calver it would make things more convenient
Major version bump would be when hardware support is removed. So the removal of any drivers or architecture support could be deferred until the next major release. Many drivers have been removed and more deprecations are on the agenda. The minor could be any new functionality. Adding a io-uring to something would warrant this to be bumped. Also, any new hardware support. Patch would be any fix of any kind as long as it doesnt add a new feature. Same thing goes for the ABI and userspace syscalls. Many things have been removed from the kernel, leaving old and off systems in the dark. Semver does make sense, even for a kernel. You just need to zoom out and not just think about userspace.
Not breaking userspace is one thing, but plenty of stuff breaks on any given linux system if you try to run a substantially newer kernel. It's more of an ideal than a guarantee.
the UNAME26 thing reminds me of one reason I heard for no Windows 9, namely that it would break compatibility with apps that would think Windows 9 was 95 or 98.
ah 2.6 i remember it like yesterday and using puppy linux for years just to keep a old laptop displaying data at a job sight not the best fit but it was a old laptop and it never let us down and was never turned off and was only replaced because it started making grinding sounds and had a error on the screen after 8 years of up time when the hdd failed when it went to write some minimal logging data for the day rip T40 you made me proud.
9:20 That reminds me of a funny cite by Benno Rice in a Linux conference, in his talk about "The Tragedy of systemd", where he talks about why some arguments against it aren't really valid: "It's buggy! - it's _software_ !"
@@citywitt3202 That was basically also the only line that stuck for me, I watched it half a year ago (I can look it up because I made a clip of that line, I'm just too lazy to look it up right now XD)
I remember the Alan Cox early days of stable kernels, I used to send him emails about things that don't work. I always build a new kernel every time he released it.
Happy to run 6.7.0-204 and running Nobara Linux... and i am switched from Windows and that was the best thing i ever did.. running DOS and Windows all my life. Now i am so happy to make the switch as it even made my Windows games run faster. Thank you GloriousEggroll!!
I have Mint Cinnamon 21.3 on my older work machine and dual boot windows 10 and Nobara KDE on my gaming PC. I think this is the way. There's some trial and error moving away especially dual boot and existing NTFS drives. I'm done with Windows after Windows 10 support is dropped by Steam. If GPU pass-though ever gets more streamlined I imagine linux desktop would gain an even more significant following. Playing recent Windows only games on Windows inside a virtual machine on a Linux host with gpu pass-through with very playable performance is almost like being in god mode.
I settled on EndeavourOS because the wifi in my laptop works perfectly on it, unlike every other Linux-based distro I've tried, even ChromeOS Flex and FydeOS. Gaming also works good enough.
My first kernel was 1.2.13, shipped with Slackware 3.0. In those days, the odd/even scheme was very important as kernels progressed by leaps and bounds, and the gains of running an experimental kernel often dwarfed the risks. I remember the kernel 2.0 as being the first really usable version, beyond tinkering. The 2.2 was a disaster, but 2.4 and 2.6 got back on track. Now, development is much more incremental, there isn't that urgency to try running the bleeding edge.
I started with Slackware 2.x can't remember exactly which minor release. I think it had a 1.1.x kernel. I had just built my first IBM compatible PC, from some very nice high end 486 used parts. My main computer at the time was an Acorn (Risc PC), has I had been using those since the early 80s where I'd cut my teeth after using the BBC Micro at school. I just built the PC to experiment with, I tried out DOS and Windows 3.x, then I thought I'd give this Linux thing a try, so I downloaded Slackware set of floppies over a dial-up connection over several days! I booted Linux with "LOADLIN" from DOS and I never looked back! It didn't take me long to set up a 10base-2 Ethernet network and sharing the modem through the Linux box! I still have pretty much the same setup today except I switched to using Linux for the desktop too by the late 90s after building my second PC with and AMD K6 and Voodoo2 graphics (which mainly used to play glquake in Linux!). Regarding the versioning, I think Linus should hse gone with YEAR.NUMBER.MINOR, the current "system" I find meaninglessly stupid. The current system is better than 2.6.x ... is it though? Why not just drop the first two numbers entirely in that case as browsers did?
I remember how big a change it was from 2.4 to 2.6, that magical number when drivers started being easy (well, outside of decent OpenGL performance). And then the incremental improvements of such until, a 3.0 that didn't feel any different from the 2.6 I had gotten so accustomed to. I never got X running with kernel < 2.4, so...
@@АлексейГриднев-и7р Different kind of arguing then. Even as it is it's hard for some to grasp that Wayland is not a "drop-in" replacement for X11. Calling it X12 would have people even more vocal about "but everything should work as before!".
I started using Linux in -98 or -99. The 2.6 kernel was a part of my shift to Gentoo. I really wanted to try new kernels, and had no idea how old my current kernel was. shifting kernel on my current distro was a bother, so I just hopped over to Gentoo. Stayed on until early 2011, so most of the 2.6 lifetime. Great memories!
When I code I just go with incrementing build numbers at release (EX:v001) and if it goes on long enough you can roll everything into a 1.0 release. When you're updating as a team I can fully understand sub-versioning by year or if it's an addon for an existing piece of software just adopting their version ahead of your build, whether you reset when THEY reset is up to you. I would be fully content with making build 100 a 1.0 release as well - after 100 builds it's probably time. If it wasn't Linus at the helm I'm sure the community would have adopted a year.ver a LONG time ago.
I've been using Linux from basically the start. I was using Minix on a 286 when Linux was released, and I bought a new computer so that I could install it (I think I bought a 486DX33, but I'm not certain. It's been a while) Personally, I really liked GKH's proposal, and I don't understand why it wasn't adopted. The only downside I see is that version numbers would have jumped from 2.X.X to 2009.0.0
I seem to recall at some point in the early 2.6 series, Linus actually said there would never be another major version number, since a major version change should signify an ABI/API breaking change, and he was adamant about avoiding such a breaking change. However, I've been completely unable to find any reference to this, so it may have just been hearsay.
I remember hearing the same thing around that time frame. I don't remember the exact source though. I was very surprised (and also rolled my eyes) when I read the 3.0 naming announcement that effectively boiled down to "just because."
I remember Linus actually talking about a kernel flag making some program think it's running on 2.6, when it's actually not. I think it was a talk with Pottering as a guest. Edit: yes it was. Video is titled "Linus Torvalds schools Lennart Poettering on the importance of users" comment is about at the 4 minute mark
The first ever linux distro I got my hands was Mandrake 6, a 7ish CD set with a computer mag I can't remember. That was 2.2.?, gcc4.4, Xfree86, OG Gnome or IceWM if you wanted a taskbar, it had OOorg, GIMP... Maybe netscape as the browser? Proper wow stuff. Then I ended up with Mandrake 9 (more CDs), flashy KDE 3 and all manner of fancy stuff. Then someone showed me Debian Sarge and I loved it - I always had a love/hate thing with RPM and apt seemed so much more clean. The installer was spot on, plus it had ALL THE PACKAGES haha... I remember it taking like a day to build my first kernel, that would have been the 2.4 / early 2.6. amazeballs. Followed along then with the release of Squeeze (2.6.30?) I basically stopped using Windows. Ran Debian until Jessie, then Gentoo since. In there was scattered Centos 6, and I stull have NetBSD stuff scattered about. From Mandrake 6 to Linux 6, hmmm...
I had debian with 2.4 as my first linux :) it was also on multiple cds. After that it was Ubuntu with free cds sent by canonical. I wish I kept them, I ordered few of each release as long as they were going.
@@forthphoto Cool! Yeah I wish I kept my Mandrake 9 CDs, that was properly *the beginning* haha - though I've still got a tgz of my old Debian 4 installation, perhaps I should find an old pentium 4 from somewhere and re-live the experience. I'd have to find an old nvidia GeForce 4 to get it going too 🤣
In the past, saying the number of the first Linux kernel you had access to spoke a lot about your level of knowledge, prior to 2.1 (1996) you would have a different notion of devices (plug and play support), in 2.4 (2001) SMT issues, filesystems and networking, 2.6 (2003) filesystems, significant improvements with USB, and so on. Today, saying that it started with kernel number X or Y doesn't mean anything, there are no longer major technological milestones that separate one from the other.
imo the current kernel versioning is good. Short, semi memorable and easy to programmatically compare against other kernel versions. The problem of having a year in version number is that it increases the version number length, provides low value and so it would be easy to mistype by human users. So better continue as it currently is
Since you ask so nicely, my first foray into Linux was back in 2012 running Ubuntu 10.04 LTS for about 2 weeks as an experiment, but I didn't get serious about daily driving it until I set up my home server in 2019
Do kinda wish we had the year as a major version, since I like knowing how out of date I am, but I guess its not that big a deal since generally a kernel shouldn't break backwards compatibility, so semver becomes a little pointless. Though there are cases where things are dropped and it would be at least nice to have that on a clear "major" change so I can be like "oh this is gone now" in case it would brick my system. (unlikely for me since my system is not even remotely niche nor old, but still, I think there are definitely tinkerers and devs that would appreciate it) Perhaps it be better to have dropped things on a yearly basis if you did that yearly number versioning, if I do anything big that I'd probably adopt that if semver doesn't make sense.
I hecking love calver. Every project should consider using it, and _especially_ ones that have no intention of respecting the semver API/ABI compatibility rules.
It's trivial to see how out of date the kernel is with "uname -a" which includes the kernel's build date. For example on my laptop I'm running now: Linux msi 6.9.1-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 23 18:50:13 UTC 2024 x86_64 GNU/Linux
i always thought 2.6 was just a point where they made some really major changes and switched to a new numbering scheme because they were at it anyway. then again, this also explains why modern linux systems occasionally get identified as "linux 2.6.x", it's just a lot more stupid than i could ever imagine.
Yes, Linus quite literally said that he revised the versioning system to get rid of the subpatch madness of four-part version numbers where major changes actually happened in the third part, and version 2.6.40 just was renamed to 3.0. There is even still a UNAME26 "persona" to pass to the personality(2) syscall which will report kernel version 2.6.(40+x) to outdated software that explicitly checks for version 2.6, even though it no longer counts the releases since 3.0 correctly (3.19 -> 2.6.59, 4.0 -> 2.6.60, 4.20 -> 2.6.80, 5.0/6.0 -> 2.6.60).
Our tills are work we're a mess prior to them being migrated from CentOS to Debian last year, one till was running a 2.x kernel so old it had compatibility issues.....with mice.
For that to happen, we will need to wait for about 14 more major versions (7-20), i.e. about 280 "minor" versions. At the current rate of ~5.5 versions a year, that would take about 50 years. Question is, will Linus even be alive by then, being about 105 years old?
Having seen this, I'm starting to think the best versioning system would just be as simple as YEAR.DAY.MINUTE so for example if I were to release my completely unready project called paw now, I would be giving it the version 2024.28.1282 because it said 21:01 at the time I looked at the clock, it was the 28th day of the year and the year was 2024. I can't imagine a better versioning system that would be easy to construct a flat integer out of.
That's actually a really good idea. I mostly go for YYYY.M.D-Hmm(+GitHash), but using Day of the Year instead of Day of the Month and Minute of the Day is actually really nice. (I might steal that idea for new projects)
Yeah, that's a variation of calver. 💯 would recommend for projects that either already have a static ABI or don't care about telegraphing breaks of backwards compatibility.
@@GSBarlev Well I don't need to care about compatibility, my project is all about a launcher and library pair. One launcher per major version of the library, e.g. paw1 for libpaw1, paw2 for libpaw2, etc
Very large projects (that don't really work with semantic versioning) should go with year-minor-bugfix or even year-month-increment. Obviously you don't write the whole year in, the last two digits are fine, e.g. 24.0.2. Systematic solutions are better than what-feels-right solutions, imo.
15:50 You'd think they would have learned that lesson from Windows where Microsoft wasn't able to name Windows 95 "version 4.0" because so many programs were expecting 3.xx numbers, which led to it reporting version 3.95 to avoid breaking things.
Major.Minor.Build.Revision Increment Revision when you make minor changes, such as Hotfixes. Increment Build when you make a release or release candidate. Increment Minor when you make moderate to major changes, such as large new features. Increment Major when you make such huge, sweeping changes, it's bordering on rewrite.
I wish they went with a Greg's 2008 proposal of {year}.{number}.{minor_release}. It is a lot more logical and structured than today's effective {major_release/20}.{major_release%20}.{minor_release} format. I also wish that the LTS versions were better marked. WINE does an excellent job with this by synchronizing their LTS release with their X.0 release at the end/beginning of the year.
Personally I think either the "whole number increment every update" or the "time/date" are the best ways to do versioning. they're simple and to the point.
The middle number actually means something. The first number rolls over when the second is too big but the second number is only incremented on major releases. The last number is just minor patches and will continually increase as long as that kernel version is supported. Those can get quite large
The year-based version numbers were a good idea. Another good idea, on the current versioning system, would have been to make 6.0 the first release with Rust support. But kernel version numbers don’t seem to receive the courtesy of good ideas.
I really don't understand the point of even having a major version number if you are just going to increment it when minor gets "too big", that seems not at all different than just... how counting in decimal works but with an extra layer of complexity. Might as well take a decimal number and put a dot before the last digit. And what are they going to do when major version becomes "too big"?
When I first used linux it was with a 2.6 kernel in the early 2000s and that was a little controversial for distros as it was so new and everything assumed 2.2 or 2.4 so documentation could be a bit problematic during the changeover period. Knowing what Kernel you were on back then was super important. Seeing that the Kernel was still 2.6 a decade later was surprising considering how fast things got to 2.6 in the first place. 2.6 did a lot of things right hence it's longevity.
This is a pretty decent coverage of the history of the version number, but I think you left out how the versioning system currently works, i.e first and second digits are the release version, and the third digit is stable release for that linux version.
I started using Linux in the fall of 1995 using Slackware. Using all 70 or so floppy's. That didn't last long until I ordered the cdrom disc of Slackware. I remember the 2.6 series. I think Linus said in one of his interviews. That the change to x.1 through x.20 (which always stops on 19) because he only has 10 fingers and toes. 😂
been using linux since i was 18 years old so 24 years so that would mean i started in 2000. ... i would say i played around with linux in 1998 with Red Hat ... when i said played around with i got a CD from a pc mag and basically load the cd from my pc and it didnt seem to like the hardware all to well, but it worked, but i never installed it on the computer as the family probalby would beat me senseless. uumm so yeah my first real install distro I used in 2000 is Knoppix or maybe it was debian and i switch over to knoppix in 2001 not sure but i know it was maily debian i first used with linux on my own pc on my own hardware with installation in 2000.... the system i use now is Arch Linux and I also use Gentoo as well on some of my other computers.
Oh Knoppix, long time no see... a favourite of mine for some time, no-nonsense distro with great plug'n'play capabilities ! Today I'm running Manjaro, close to Arch but with less headaches 🙂
How long have I been using Linux? Well the last time I installed Windows on bare metal I own was an AMD XP-M laptop where I couldn't get Wireshark to work with NDIS wrapper and the PCMCIA wifi card.
2.6 was a horrible mess with how long it went, yes I still think versioning by the year would be extremely good idea, far better than the arbitrary "change when the second number would hit 20", at least the first number and instead of like 2024 you could go with just 24, by the time we get to 2100 adding a new digit would be fine, or rolling back to 00, after all, who the hell is gonna check compatibility with 100 year old kernel version, lol
I remember when this first happened going from 2.6 to 3 took a bit for proprietary drivers to update as they weren't packaged to deal with a major number jump like that. Thankfully they kinda expect it now
2.0.36 was the first Linux kernel I installed on my personal machine in 1999 (SuSE 6.0). But I had already been using Linux some years before that at university. Must have been sometime around '96, and I remember the student's server being updated quite regularly; so probably some 1.3.x or pre2.0 (which was also a strange time for versioning 🙂- pre2.0.0 to pre2.0.14 between May '96 and and June '96, and then back to "real" 2.0.0).
I just checked my Big Pile of Old CDs™ and I've got some disks from InfoMagic dated 1995, containing SLS with kernel version 1.1.50. I can't remember, was that an LTS kernel? 😂
Daily driving Linux for about 8 years. Dual booting, and for my couple years Mac primary running it on an older laptop, all the way back to 1999. I bought it from Waldenbooks. Back in the days the old numbering system was still in place. Getting my Diamond Monster Fusion(Voodoo Banshee) card working in anything but text mode took some work. Had to find an out of tree kernel driver, compile the kernel, configure X by hand. Hope I didn't fuck up the refresh rate settings and break my monitor.
oh also needed the x server for it. And none of these things were actually included with any distro. Kids these days have no idea what we had to deal with back then, and I was lucky my hardware was supported at all.
I mean the kernel development and release process has changed with the needs of the world. New hardware comes out extremely frequently and it can't be afforded that the Linux kernel wait to get drivers/hardware support or features 2-3 years after WinNT or Darwin. Additionally, very very very frequent security issues now require frequent updates to deal with those. It allows for releases to be relatively small (compared to the older release model) that also tend to be more stable and WHEN there's a bug, a LOT EASIER to figure out what change caused the problem. The larger a release always leads to a much more difficult time tracking down bugs and vulnerabilities.
I seem to remember there was actually one distro that released a kernel labeled "2.6.40". So technically we did get a 2.6.40 even if it was a rebadged 3.0 release
My vert first linux experience was with RedHat 9 around 2003. Didn't really play with it too, too much until Fedora Core 3 in 2004. Didn't have broadband till the following year, 2005. Was nice being able to download linux at home finally!
The first Linux version I used was 1.2, but only briefly. I remember it having these weird commands that were very similar but not quite the same as DOS…
Honestly... I get giving up on semantic-like versioning. When you make many slightly different package versions with changes every week, it can be annoying to decide when to increment the version number.
I have used Desktop Linux for like 5 years or so now, no Windows install. But I have used Linux in VM and Dual boot, servers etc. since Slackware 3.6 including building LFS
I would still prefer the odd/even numbering, or reverse date-based (for sorting) but that might just be nostalgia, even if within these schemas there were arbitrary numbers or combined... odd/even with a date-stamp. Arbitrary numbers convey less information. They work, its just that you now have to look up other things to get the same information. 2.6 was a massive leap forward in compatibility and it was incredibly stable. I ran my desktop for over a year, only needed to restart the gui, not the underlying OS. I have a sneaky feeling Checkpoint are still running it. ;)
IMHO they should adopt semantic versioning. For example every year on december bump the major version and only drop hardware support on that bump. Recently they drop support for very old GPUs. That is a breaking change IMHO. So every move from mainline to staging folder and every driver drop should be major bump. So for the user every LTS version could means your hardware is no longer supportes but at least you had support in the previous LTS.
@15:46, this sounds like a problem that Microsoft also had to figure out when they went from Windows 8, to Windows 10 because they had code looking for 9x. :P Yep. Everyone's done this at one point. Did Mac run into any versioning bugs in its past or similar issues?
I've been using Linux for 7 years through UNRAID. And a little over 2 and 1/2 years as my daily driver desktop, I currently run Linux mint with a custom kernel on top of it. And will likely be looking at some kind of rolling release when my current situation pisses me off enough to switch
I've only been on Linux about 5 months now and already on vanilla Arch+hyprland, going great so far, now that i say that grub is probably gonna rm rf itself tomorrow or something
I remember being into reading about the linux kernel and wondering why 1.3 series was going so high, like, would they just keep increasing the number? 1.3.500 anybody? It was wild! Are they gonna stop at some point or what?
Reminds me that Windows kernel versions were stuck at 6.x from Vista to the few first versions of Windows 10 where it jumped to 6.4 to 10.0. That's also a near decade of the "same version but big changes". And Windows 11 versions still start with 10.0 (definitely because Windows 11 is still Windows 10, fight me).
Thé 2.4 transition was difficult as it broke a lot of things. 2.6 was a little better (and it was the beginning of my sys admin career). The 2.6 time releases were a far smother experience but I too had some strange bugs when 3.0 came because devs are morons.
A time-based version actually seems super logical given that the releases are time-based anyways. Although I think it's harder to remember and differentiate version numbers based on years at a glance since they always start the same. The current system is decent in that regard, even though it's probably a bit confusing to people that don't know how it works. I guess using just the last 2 digits of the year could be an idea. It would give pretty similar version numbers, just with more meaning. And if we get to 2100, we can switch to 3 numbers. Though I guess the major version would still rise a lot quicker this way and eventually, differentiating 66 from 68 wouldn't be that easy again.
Still not a fan of the numbering system. If it were up to me, it would probably just be a simple integer for every version. It's just a simple and stupid naming scheme without much downside.
I'm shocked to realize I've been daily driving Linux for 5 yrs now, Manjaro, then eventually full on Arch. I dabbled as far back as 2003 i think (Suse), then got more serious in 2011 when i revived a friends old laptop with Ubuntu (i think). Every time I tried Linux was because of Windows doing something progressively more stupid or offensive. I won't willingly let Microsoft touch my files anymore. So I guess i was there for the beginning and end of 2.6, but didn't give it any thought at the time.
I've been using Linux as my main OS for a bit over 6 months now so I am still getting to grips with how the 'behind the scenes' parts of the system works along with the development history. It is interesting how the version numbers had meaning at a few points and then degraded into meaningless chaos and randomness which sounds like some of my old college projects. I do think it would be a lot easier for the general user though if the version number was based on the release date rather than changing 'when Linus feels like it'. While (for example) 2024.1.28 is a bit of a kludge, I think it would be better if the year was based on two digits (like 24.1.28) so it becomes more manageable. After all, how likely is it that anyone will still be using Linux in 2124? At the end of the day version numbers like 6.6.11 really don't tend to mean much without a particular frame of reference past bigger number = newer.
![ILLSLICK X YOUNGOHM - We're The same [Official Video]](http://i.ytimg.com/vi/yUJNkobYR0E/mqdefault.jpg)
The second number has over time generally went from 0 to 19, at which point the first number incremented, meaning 20 versions each. The only exception to this so far was kernel 4.20
What did Linus mean by this?
I ran the "hightime" kernel for about a year. The reason I ended up no longer using it was a hard drive failure. Head Crash.
Kernel 4.20: Smoke Weed Everyday!
#SaveVersion6.9
@@chaos5411there was an effort
i love it when linus 'listens to the voices'.
truly taking the path of the legendary terry davis
This joke will send you to hell but it was worth it 💀💀
15:33 this reminds me of a rumor about why Windows 9 was skipped, because apperently lots of software would hardcode checking Windows 9x for 95/98 and making Windows 9 would trigger those checks so they just skipped to Windows 10.
ironically that check would be fine if they looked for a second number at all.
I don't see why you wouldn't do that. The only thing that would actually cause that is checking for windows 9 followed by anything.
Incorrect. It was never released because Microsoft Germany was opposed to it.
@@cynodont7391 I'm just going to call it now, this will be an underrated comment.
The only reason I doubt this is that windows doesn’t actually report that version anywhere, it always reports version 6 and has done so ever since they had the exact same problem Linux did in the shift from xp to vista. XP had been around so long a ton of sw was just looking for “version 5.x” and the move to 6.x broke it. After that they just never incremented again.
@@cynodont7391 why?
I confess that I was today old when I found out that the "odd=development, even=stable" procedure is no longer a thing ... Somehow that seems to have stuck in the back of my head. Thanks for mentioning that!
SDL libraries do it still
Same.
I also thought this was still true.
They stopped doing this around Linux 2.5.... because it ended up being unweildy. so they started doing Linux-next and every version was a stable.
@@Wingnut353 Either you expect everyone else didnt watch the video or you didnt watch it yourself. Which one is it?
First Reiser, next the Decade of 2.6. Brodie is taking me-and, I suspect, a large portion of his subscribers-on one heck of a trip down memory lane.
Did you notice the new SCO-vs.-IBM news? ;)
Reiser is a good example NOT to listen to the voices in your head.
I vaguely remember 3.x being buggy... go figure that a lot of android kernels are 3.x.
Ah yes, program's looking for 2.6, just like looking for "Windows 9" to catch 95/98
I've been using Debian since spring 1994. In those days kernel images were not included in the repositories, so to update the kernel you had to compile it yourself. I remember writing a few scripts to help with the process. Things became easier when make-kpkg came along. This package compiles the kernel source code and produces a .deb file that you can install using dpkg. To this day, I still compile the kernel rather than use the one in the (unstable debian) repository. I'm currently running kernel version 6.7.1. which I compiled 8 days ago. (edit: I see 6.7.2 is the latest stable version. It seems I'm already running an obsolete kernel).
@CesarLP96If you want the latest version, yes (and you get to configure it as you want).
It's almost like the major minor releases served a purprose more than 'bigger number better', and it's interesting to see such .... weirdness in the kernel space... because it's only a hint of what's under the hood.
Any sort of semver would have been pointless in any case. Linus's rule is "you don't break userspace," so communicating breaking changes by major version would have been completely pointless.
I think using something like Windows build versions would have been more useful here, like Linux build 17830.
@@acerIOstreamWell, it's basically already is something like build number, except it split into 3 numbers.
Calver would be very nice to have though, i.e. first digit being the year of release like with ubuntu. Since many major distros also use calver it would make things more convenient
Major version bump would be when hardware support is removed.
So the removal of any drivers or architecture support could be deferred until the next major release. Many drivers have been removed and more deprecations are on the agenda.
The minor could be any new functionality. Adding a io-uring to something would warrant this to be bumped. Also, any new hardware support.
Patch would be any fix of any kind as long as it doesnt add a new feature.
Same thing goes for the ABI and userspace syscalls.
Many things have been removed from the kernel, leaving old and off systems in the dark.
Semver does make sense, even for a kernel. You just need to zoom out and not just think about userspace.
Not breaking userspace is one thing, but plenty of stuff breaks on any given linux system if you try to run a substantially newer kernel. It's more of an ideal than a guarantee.
Don't worry, *eventually* the major version has to become 42.
Or they would have to go like 41.41.41.xx 😂
Or version 41 gets followed by 43, just like Windows skipped 9 wouldn't put it behind linus to do that out of spite, if he is still in charge / alive.
I am using Linux 2.5.12. Need to try this new 2.6 stuff!
the UNAME26 thing reminds me of one reason I heard for no Windows 9, namely that it would break compatibility with apps that would think Windows 9 was 95 or 98.
ah 2.6 i remember it like yesterday and using puppy linux for years just to keep a old laptop displaying data at a job sight not the best fit but it was a old laptop and it never let us down and was never turned off and was only replaced because it started making grinding sounds and had a error on the screen after 8 years of up time when the hdd failed when it went to write some minimal logging data for the day rip T40 you made me proud.
9:20 That reminds me of a funny cite by Benno Rice in a Linux conference, in his talk about "The Tragedy of systemd", where he talks about why some arguments against it aren't really valid: "It's buggy! - it's _software_ !"
I remember watching that a year ago and that was the line that stuck for me.
@@citywitt3202
That was basically also the only line that stuck for me, I watched it half a year ago (I can look it up because I made a clip of that line, I'm just too lazy to look it up right now XD)
I remember the Alan Cox early days of stable kernels, I used to send him emails about things that don't work. I always build a new kernel every time he released it.
10:53 pretty certain, it's his gut feeling.
Happy to run 6.7.0-204 and running Nobara Linux... and i am switched from Windows and that was the best thing i ever did.. running DOS and Windows all my life. Now i am so happy to make the switch as it even made my Windows games run faster. Thank you GloriousEggroll!!
I have Mint Cinnamon 21.3 on my older work machine and dual boot windows 10 and Nobara KDE on my gaming PC. I think this is the way. There's some trial and error moving away especially dual boot and existing NTFS drives. I'm done with Windows after Windows 10 support is dropped by Steam. If GPU pass-though ever gets more streamlined I imagine linux desktop would gain an even more significant following. Playing recent Windows only games on Windows inside a virtual machine on a Linux host with gpu pass-through with very playable performance is almost like being in god mode.
I settled on EndeavourOS because the wifi in my laptop works perfectly on it, unlike every other Linux-based distro I've tried, even ChromeOS Flex and FydeOS. Gaming also works good enough.
My first kernel was 1.2.13, shipped with Slackware 3.0. In those days, the odd/even scheme was very important as kernels progressed by leaps and bounds, and the gains of running an experimental kernel often dwarfed the risks. I remember the kernel 2.0 as being the first really usable version, beyond tinkering. The 2.2 was a disaster, but 2.4 and 2.6 got back on track. Now, development is much more incremental, there isn't that urgency to try running the bleeding edge.
I started with Slackware 2.x can't remember exactly which minor release. I think it had a 1.1.x kernel. I had just built my first IBM compatible PC, from some very nice high end 486 used parts. My main computer at the time was an Acorn (Risc PC), has I had been using those since the early 80s where I'd cut my teeth after using the BBC Micro at school.
I just built the PC to experiment with, I tried out DOS and Windows 3.x, then I thought I'd give this Linux thing a try, so I downloaded Slackware set of floppies over a dial-up connection over several days! I booted Linux with "LOADLIN" from DOS and I never looked back! It didn't take me long to set up a 10base-2 Ethernet network and sharing the modem through the Linux box! I still have pretty much the same setup today except I switched to using Linux for the desktop too by the late 90s after building my second PC with and AMD K6 and Voodoo2 graphics (which mainly used to play glquake in Linux!).
Regarding the versioning, I think Linus should hse gone with YEAR.NUMBER.MINOR, the current "system" I find meaninglessly stupid. The current system is better than 2.6.x ... is it though? Why not just drop the first two numbers entirely in that case as browsers did?
I remember how big a change it was from 2.4 to 2.6, that magical number when drivers started being easy (well, outside of decent OpenGL performance). And then the incremental improvements of such until, a 3.0 that didn't feel any different from the 2.6 I had gotten so accustomed to. I never got X running with kernel < 2.4, so...
There definitely was a time where it felt like we would see 2.6.519... anybody that used rHELL 5 would probably have flashbacks to 2.6.38-3xx kernels.
RHEL5 used 2.6.18, but I get your point.
This is like X being on version 11 since 1984 (idk the actual date)
I wonder if the whole X vs Wayland debate could have been less fierce if they just called it X12…
@@АлексейГриднев-и7р Different kind of arguing then. Even as it is it's hard for some to grasp that Wayland is not a "drop-in" replacement for X11. Calling it X12 would have people even more vocal about "but everything should work as before!".
@@АлексейГриднев-и7р calling it "X12" would be even more controversial since people would expect some kind of retrocompatibility with X11.
Not what is means, not that development hasn't stalled
I started using Linux in -98 or -99. The 2.6 kernel was a part of my shift to Gentoo. I really wanted to try new kernels, and had no idea how old my current kernel was. shifting kernel on my current distro was a bother, so I just hopped over to Gentoo. Stayed on until early 2011, so most of the 2.6 lifetime. Great memories!
When I code I just go with incrementing build numbers at release (EX:v001) and if it goes on long enough you can roll everything into a 1.0 release. When you're updating as a team I can fully understand sub-versioning by year or if it's an addon for an existing piece of software just adopting their version ahead of your build, whether you reset when THEY reset is up to you.
I would be fully content with making build 100 a 1.0 release as well - after 100 builds it's probably time. If it wasn't Linus at the helm I'm sure the community would have adopted a year.ver a LONG time ago.
I've been using Linux from basically the start. I was using Minix on a 286 when Linux was released, and I bought a new computer so that I could install it (I think I bought a 486DX33, but I'm not certain. It's been a while)
Personally, I really liked GKH's proposal, and I don't understand why it wasn't adopted. The only downside I see is that version numbers would have jumped from 2.X.X to 2009.0.0
I seem to recall at some point in the early 2.6 series, Linus actually said there would never be another major version number, since a major version change should signify an ABI/API breaking change, and he was adamant about avoiding such a breaking change.
However, I've been completely unable to find any reference to this, so it may have just been hearsay.
I remember hearing the same thing around that time frame. I don't remember the exact source though. I was very surprised (and also rolled my eyes) when I read the 3.0 naming announcement that effectively boiled down to "just because."
@@arazilsongweaver Thanks! That's enough of a confirmation to know that I'm not losing my mind. 😂
I remember Linus actually talking about a kernel flag making some program think it's running on 2.6, when it's actually not. I think it was a talk with Pottering as a guest. Edit: yes it was. Video is titled "Linus Torvalds schools Lennart Poettering on the importance of users" comment is about at the 4 minute mark
At this point, Brodie just being anticipating about the nice upcoming 6.9.x kernel
The first ever linux distro I got my hands was Mandrake 6, a 7ish CD set with a computer mag I can't remember. That was 2.2.?, gcc4.4, Xfree86, OG Gnome or IceWM if you wanted a taskbar, it had OOorg, GIMP... Maybe netscape as the browser? Proper wow stuff. Then I ended up with Mandrake 9 (more CDs), flashy KDE 3 and all manner of fancy stuff. Then someone showed me Debian Sarge and I loved it - I always had a love/hate thing with RPM and apt seemed so much more clean. The installer was spot on, plus it had ALL THE PACKAGES haha... I remember it taking like a day to build my first kernel, that would have been the 2.4 / early 2.6. amazeballs. Followed along then with the release of Squeeze (2.6.30?) I basically stopped using Windows. Ran Debian until Jessie, then Gentoo since. In there was scattered Centos 6, and I stull have NetBSD stuff scattered about.
From Mandrake 6 to Linux 6, hmmm...
I had debian with 2.4 as my first linux :) it was also on multiple cds. After that it was Ubuntu with free cds sent by canonical. I wish I kept them, I ordered few of each release as long as they were going.
@@forthphoto Cool! Yeah I wish I kept my Mandrake 9 CDs, that was properly *the beginning* haha - though I've still got a tgz of my old Debian 4 installation, perhaps I should find an old pentium 4 from somewhere and re-live the experience. I'd have to find an old nvidia GeForce 4 to get it going too 🤣
Good times
In the past, saying the number of the first Linux kernel you had access to spoke a lot about your level of knowledge, prior to 2.1 (1996) you would have a different notion of devices (plug and play support), in 2.4 (2001) SMT issues, filesystems and networking, 2.6 (2003) filesystems, significant improvements with USB, and so on.
Today, saying that it started with kernel number X or Y doesn't mean anything, there are no longer major technological milestones that separate one from the other.
imo the current kernel versioning is good. Short, semi memorable and easy to programmatically compare against other kernel versions. The problem of having a year in version number is that it increases the version number length, provides low value and so it would be easy to mistype by human users. So better continue as it currently is
They could go Chromium and Firefox way. Keeps increasing the major version always. This way, only one number is used, very easy to compare also.
Since you ask so nicely, my first foray into Linux was back in 2012 running Ubuntu 10.04 LTS for about 2 weeks as an experiment, but I didn't get serious about daily driving it until I set up my home server in 2019
Bike shed colour referendum had me in stitches. I know he's not always PC (the opposite, even), but that's also refreshing
Oh he is PC. However he can be arrogant indeed.
Do kinda wish we had the year as a major version, since I like knowing how out of date I am, but I guess its not that big a deal since generally a kernel shouldn't break backwards compatibility, so semver becomes a little pointless. Though there are cases where things are dropped and it would be at least nice to have that on a clear "major" change so I can be like "oh this is gone now" in case it would brick my system. (unlikely for me since my system is not even remotely niche nor old, but still, I think there are definitely tinkerers and devs that would appreciate it) Perhaps it be better to have dropped things on a yearly basis if you did that yearly number versioning, if I do anything big that I'd probably adopt that if semver doesn't make sense.
I hecking love calver. Every project should consider using it, and _especially_ ones that have no intention of respecting the semver API/ABI compatibility rules.
Error: number bigger than number of fingers and toes
It's trivial to see how out of date the kernel is with "uname -a" which includes the kernel's build date. For example on my laptop I'm running now:
Linux msi 6.9.1-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 23 18:50:13 UTC 2024 x86_64 GNU/Linux
i always thought 2.6 was just a point where they made some really major changes and switched to a new numbering scheme because they were at it anyway. then again, this also explains why modern linux systems occasionally get identified as "linux 2.6.x", it's just a lot more stupid than i could ever imagine.
Yes, Linus quite literally said that he revised the versioning system to get rid of the subpatch madness of four-part version numbers where major changes actually happened in the third part, and version 2.6.40 just was renamed to 3.0. There is even still a UNAME26 "persona" to pass to the personality(2) syscall which will report kernel version 2.6.(40+x) to outdated software that explicitly checks for version 2.6, even though it no longer counts the releases since 3.0 correctly (3.19 -> 2.6.59, 4.0 -> 2.6.60, 4.20 -> 2.6.80, 5.0/6.0 -> 2.6.60).
Maybe also do a video on the zen kernel. I don’t personally use it, but it does still occasionally come across my screen
Our tills are work we're a mess prior to them being migrated from CentOS to Debian last year, one till was running a 2.x kernel so old it had compatibility issues.....with mice.
I am more interested in what will happen when the major number will became too big for Linus.
For that to happen, we will need to wait for about 14 more major versions (7-20), i.e. about 280 "minor" versions. At the current rate of ~5.5 versions a year, that would take about 50 years. Question is, will Linus even be alive by then, being about 105 years old?
Having seen this, I'm starting to think the best versioning system would just be as simple as YEAR.DAY.MINUTE so for example if I were to release my completely unready project called paw now, I would be giving it the version 2024.28.1282 because it said 21:01 at the time I looked at the clock, it was the 28th day of the year and the year was 2024. I can't imagine a better versioning system that would be easy to construct a flat integer out of.
That's actually a really good idea. I mostly go for YYYY.M.D-Hmm(+GitHash), but using Day of the Year instead of Day of the Month and Minute of the Day is actually really nice. (I might steal that idea for new projects)
Unix timestamp
Yeah, that's a variation of calver. 💯 would recommend for projects that either already have a static ABI or don't care about telegraphing breaks of backwards compatibility.
@@GSBarlev Well I don't need to care about compatibility, my project is all about a launcher and library pair. One launcher per major version of the library, e.g. paw1 for libpaw1, paw2 for libpaw2, etc
@@zxuiji Is there a reason not to tie your versioning to the library version then?
Thank you for the little lesson in history Brodie, it's always nice to hear about how Linux used to be then and how much it changed now.
Very large projects (that don't really work with semantic versioning) should go with year-minor-bugfix or even year-month-increment. Obviously you don't write the whole year in, the last two digits are fine, e.g. 24.0.2.
Systematic solutions are better than what-feels-right solutions, imo.
Only using the last two is quite literally reintroducing the Y2K bug in a sense. I wonder why I didn't choose the full year at work...
15:50 You'd think they would have learned that lesson from Windows where Microsoft wasn't able to name Windows 95 "version 4.0" because so many programs were expecting 3.xx numbers, which led to it reporting version 3.95 to avoid breaking things.
Major.Minor.Build.Revision
Increment Revision when you make minor changes, such as Hotfixes.
Increment Build when you make a release or release candidate.
Increment Minor when you make moderate to major changes, such as large new features.
Increment Major when you make such huge, sweeping changes, it's bordering on rewrite.
I wish they went with a Greg's 2008 proposal of {year}.{number}.{minor_release}. It is a lot more logical and structured than today's effective {major_release/20}.{major_release%20}.{minor_release} format. I also wish that the LTS versions were better marked. WINE does an excellent job with this by synchronizing their LTS release with their X.0 release at the end/beginning of the year.
💯. The Linux kernel, development of which is dominated by adding support for newly released hardware, is pretty much the *ideal* use-case for calver.
Can somebody actually count how many versions were released since 3.0? I am curious what version of 2.6.x would we be on now if it had stayed on 2.6 😂
Personally I think either the "whole number increment every update" or the "time/date" are the best ways to do versioning. they're simple and to the point.
The middle number actually means something. The first number rolls over when the second is too big but the second number is only incremented on major releases. The last number is just minor patches and will continually increase as long as that kernel version is supported. Those can get quite large
The year-based version numbers were a good idea. Another good idea, on the current versioning system, would have been to make 6.0 the first release with Rust support. But kernel version numbers don’t seem to receive the courtesy of good ideas.
Wow, I still remember building the 2.4* kernel when I was building them for router systems. I have not even kept track of the kernel versions since.
Now they have 7 stable kernels, that escalated quick.
13:26 JetBrains' version numbering scheme
2.6 era was just wierd, and i do remember alot of things breaking with app updates.
I like the year.major.minor/revision format. Would have been nice to have that for an easier indication on when the kernel was released that I'm using
I really don't understand the point of even having a major version number if you are just going to increment it when minor gets "too big", that seems not at all different than just... how counting in decimal works but with an extra layer of complexity. Might as well take a decimal number and put a dot before the last digit. And what are they going to do when major version becomes "too big"?
When I first used linux it was with a 2.6 kernel in the early 2000s and that was a little controversial for distros as it was so new and everything assumed 2.2 or 2.4 so documentation could be a bit problematic during the changeover period. Knowing what Kernel you were on back then was super important. Seeing that the Kernel was still 2.6 a decade later was surprising considering how fast things got to 2.6 in the first place. 2.6 did a lot of things right hence it's longevity.
User since 2017. Started with Peppermint 8. Currently using KDE neon.
This is a pretty decent coverage of the history of the version number, but I think you left out how the versioning system currently works, i.e first and second digits are the release version, and the third digit is stable release for that linux version.
I started using Linux in the fall of 1995 using Slackware. Using all 70 or so floppy's. That didn't last long until I ordered the cdrom disc of Slackware. I remember the 2.6 series. I think Linus said in one of his interviews. That the change to x.1 through x.20 (which always stops on 19) because he only has 10 fingers and toes. 😂
versioning with the year would be great.
been using linux since i was 18 years old so 24 years so that would mean i started in 2000. ... i would say i played around with linux in 1998 with Red Hat ... when i said played around with i got a CD from a pc mag and basically load the cd from my pc and it didnt seem to like the hardware all to well, but it worked, but i never installed it on the computer as the family probalby would beat me senseless. uumm so yeah my first real install distro I used in 2000 is Knoppix or maybe it was debian and i switch over to knoppix in 2001 not sure but i know it was maily debian i first used with linux on my own pc on my own hardware with installation in 2000.... the system i use now is Arch Linux and I also use Gentoo as well on some of my other computers.
Oh Knoppix, long time no see... a favourite of mine for some time, no-nonsense distro with great plug'n'play capabilities ! Today I'm running Manjaro, close to Arch but with less headaches 🙂
How long have I been using Linux? Well the last time I installed Windows on bare metal I own was an AMD XP-M laptop where I couldn't get Wireshark to work with NDIS wrapper and the PCMCIA wifi card.
2.6 was a horrible mess with how long it went, yes
I still think versioning by the year would be extremely good idea, far better than the arbitrary "change when the second number would hit 20", at least the first number
and instead of like 2024 you could go with just 24, by the time we get to 2100 adding a new digit would be fine, or rolling back to 00, after all, who the hell is gonna check compatibility with 100 year old kernel version, lol
I remember when this first happened going from 2.6 to 3 took a bit for proprietary drivers to update as they weren't packaged to deal with a major number jump like that. Thankfully they kinda expect it now
2.0.36 was the first Linux kernel I installed on my personal machine in 1999 (SuSE 6.0). But I had already been using Linux some years before that at university. Must have been sometime around '96, and I remember the student's server being updated quite regularly; so probably some 1.3.x or pre2.0 (which was also a strange time for versioning 🙂- pre2.0.0 to pre2.0.14 between May '96 and and June '96, and then back to "real" 2.0.0).
Started on 2.4.x
I just checked my Big Pile of Old CDs™ and I've got some disks from InfoMagic dated 1995, containing SLS with kernel version 1.1.50. I can't remember, was that an LTS kernel? 😂
Daily driving Linux for about 8 years.
Dual booting, and for my couple years Mac primary running it on an older laptop, all the way back to 1999. I bought it from Waldenbooks. Back in the days the old numbering system was still in place.
Getting my Diamond Monster Fusion(Voodoo Banshee) card working in anything but text mode took some work. Had to find an out of tree kernel driver, compile the kernel, configure X by hand. Hope I didn't fuck up the refresh rate settings and break my monitor.
oh also needed the x server for it. And none of these things were actually included with any distro.
Kids these days have no idea what we had to deal with back then, and I was lucky my hardware was supported at all.
I mean the kernel development and release process has changed with the needs of the world. New hardware comes out extremely frequently and it can't be afforded that the Linux kernel wait to get drivers/hardware support or features 2-3 years after WinNT or Darwin. Additionally, very very very frequent security issues now require frequent updates to deal with those. It allows for releases to be relatively small (compared to the older release model) that also tend to be more stable and WHEN there's a bug, a LOT EASIER to figure out what change caused the problem.
The larger a release always leads to a much more difficult time tracking down bugs and vulnerabilities.
The oldest kernel version I remember seeing on a system I've used is 2.0.x...
Linux user since '96, as primary desktop '98 (when IBM announced there would be no OS/2 updates). I still remember KDE 1.0.0beta1...
I seem to remember there was actually one distro that released a kernel labeled "2.6.40". So technically we did get a 2.6.40 even if it was a rebadged 3.0 release
My vert first linux experience was with RedHat 9 around 2003. Didn't really play with it too, too much until Fedora Core 3 in 2004. Didn't have broadband till the following year, 2005. Was nice being able to download linux at home finally!
The first Linux version I used was 1.2, but only briefly. I remember it having these weird commands that were very similar but not quite the same as DOS…
Honestly... I get giving up on semantic-like versioning. When you make many slightly different package versions with changes every week, it can be annoying to decide when to increment the version number.
I started in 1999 with Suse 6.2. I went exclusively linux in 2000/early 2001. From Suse to Slackware to Gentoo.
Did have some good "do you remember when we all ran 2.6.something kernel"-talk some months ago!
nice kernel version :)
i start around 1996, with Suse on 6 floppy disks, gold ..
I have used Desktop Linux for like 5 years or so now, no Windows install. But I have used Linux in VM and Dual boot, servers etc. since Slackware 3.6 including building LFS
I never really thought about it, but old blogs and posts mentioning that they are running some version of 2.6 is definitely a thing.
I would still prefer the odd/even numbering, or reverse date-based (for sorting) but that might just be nostalgia, even if within these schemas there were arbitrary numbers or combined... odd/even with a date-stamp. Arbitrary numbers convey less information. They work, its just that you now have to look up other things to get the same information.
2.6 was a massive leap forward in compatibility and it was incredibly stable. I ran my desktop for over a year, only needed to restart the gui, not the underlying OS. I have a sneaky feeling Checkpoint are still running it. ;)
IIRC I think I started running Linux around 3.16
I'm using it since the winter of 2005/2006. It's been v. 2.6.something at the time, and it kept being that... XD
IMHO they should adopt semantic versioning.
For example every year on december bump the major version and only drop hardware support on that bump.
Recently they drop support for very old GPUs. That is a breaking change IMHO.
So every move from mainline to staging folder and every driver drop should be major bump.
So for the user every LTS version could means your hardware is no longer supportes but at least you had support in the previous LTS.
@15:46, this sounds like a problem that Microsoft also had to figure out when they went from Windows 8, to Windows 10 because they had code looking for 9x. :P
Yep. Everyone's done this at one point.
Did Mac run into any versioning bugs in its past or similar issues?
I've been using Linux for 7 years through UNRAID. And a little over 2 and 1/2 years as my daily driver desktop, I currently run Linux mint with a custom kernel on top of it. And will likely be looking at some kind of rolling release when my current situation pisses me off enough to switch
Have you done a vid on the insanity of the cloud providers and kernels? Like WTF 4.14 is the default.
I've only been on Linux about 5 months now and already on vanilla Arch+hyprland, going great so far, now that i say that grub is probably gonna rm rf itself tomorrow or something
same whatever the hell feels good version numbers with a release year tacked on the end, that'd make sense too.
The first time I ran Linux, I was running kernel 2.0.something, with Debian 2 and RedHat 5.0.
I remember being into reading about the linux kernel and wondering why 1.3 series was going so high, like, would they just keep increasing the number? 1.3.500 anybody? It was wild! Are they gonna stop at some point or what?
My first kernel was 2.0.36, on Debian I believe. We've come a long way since then!
Reminds me that Windows kernel versions were stuck at 6.x from Vista to the few first versions of Windows 10 where it jumped to 6.4 to 10.0. That's also a near decade of the "same version but big changes".
And Windows 11 versions still start with 10.0 (definitely because Windows 11 is still Windows 10, fight me).
Thé 2.4 transition was difficult as it broke a lot of things. 2.6 was a little better (and it was the beginning of my sys admin career). The 2.6 time releases were a far smother experience but I too had some strange bugs when 3.0 came because devs are morons.
Linus looked at Gabe Newel and thought "that won't be me. 3.0 now or never"
Since 2003
A time-based version actually seems super logical given that the releases are time-based anyways. Although I think it's harder to remember and differentiate version numbers based on years at a glance since they always start the same. The current system is decent in that regard, even though it's probably a bit confusing to people that don't know how it works. I guess using just the last 2 digits of the year could be an idea. It would give pretty similar version numbers, just with more meaning. And if we get to 2100, we can switch to 3 numbers. Though I guess the major version would still rise a lot quicker this way and eventually, differentiating 66 from 68 wouldn't be that easy again.
Shoutout to YellowDog Linux 6, on my PS3
I remember how long we used the 2.6.xx kernel.
Still not a fan of the numbering system. If it were up to me, it would probably just be a simple integer for every version.
It's just a simple and stupid naming scheme without much downside.
I'm shocked to realize I've been daily driving Linux for 5 yrs now, Manjaro, then eventually full on Arch. I dabbled as far back as 2003 i think (Suse), then got more serious in 2011 when i revived a friends old laptop with Ubuntu (i think). Every time I tried Linux was because of Windows doing something progressively more stupid or offensive. I won't willingly let Microsoft touch my files anymore. So I guess i was there for the beginning and end of 2.6, but didn't give it any thought at the time.
I've been using Linux as my main OS for a bit over 6 months now so I am still getting to grips with how the 'behind the scenes' parts of the system works along with the development history. It is interesting how the version numbers had meaning at a few points and then degraded into meaningless chaos and randomness which sounds like some of my old college projects.
I do think it would be a lot easier for the general user though if the version number was based on the release date rather than changing 'when Linus feels like it'. While (for example) 2024.1.28 is a bit of a kludge, I think it would be better if the year was based on two digits (like 24.1.28) so it becomes more manageable. After all, how likely is it that anyone will still be using Linux in 2124? At the end of the day version numbers like 6.6.11 really don't tend to mean much without a particular frame of reference past bigger number = newer.
The issue with that is that different countries have different year formats, 28.1.24 for a lot of people would be 2024
4 digits is the way to go
1:10 im so... when you say but, i listen butt