SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I love this: so many of the software magazines have been running features about "when will 5 happen?" and "what big changes will there be in kernel v5?" a la Windows 10 which was called W10 because 'it was such a big important release that we skipped 9' or whatever it was they said.
Now we get this with LT essentially saying, "I don't know why it's called 5, we just did it because we were bored with the 4.xx series". Great, stick that in your pipes and smoke it, software zines.
I love this: so many of the software magazines have been running features about "when will 5 happen?" and "what big changes will there be in kernel v5?" a la Windows 10 which was called W10 because 'it was such a big important release that we skipped 9' or whatever it was they said.
Now we get this with LT essentially saying, "I don't know why it's called 5, we just did it because we were bored with the 4.xx series". Great, stick that in your pipes and smoke it, software zines.
When I first read it, I'm like Linux is falling in the traits of Windows. If this continue to happen then technology is doomed for mankind...
When I first read it, I'm like Linux is falling in the traits of Windows. If this continue to happen then technology is doomed for mankind...
Playing around with version numbers [for various reasons] has been a trend for a while, and this trend existed before Windows did it. I remember Winamp skipping from version 3 to version 5 back in 2003.
Quote:
What happened to Winamp 4? You're not imagining things. Yes, we skipped a version number for the following reasons: a) Winamp 5 combines the best aspects of Winamp 2 and Winamp 3 into one player. Hence Winamp 2 + Winamp 3 = Winamp 5! b) Who the hell wants to see a Winamp 4 Skin :P c) We think that a Fibonacci sequence for versioning might be pretty damn cool. d) We improved so much in Winamp 5 that we figured it warranted skipping a version.
When they did it I remember thinking, "how can they? How dare they skip a whole version number?!". Needless to say, the outrage subsided.
Last edited by Lysander666; 01-10-2019 at 03:31 AM.
Playing around with version numbers [for various reasons] has been a trend for a while, and this trend existed before Windows did it. I remember Winamp skipping from version 3 to version 5 back in 2003.
Slackware going from 4.0 to 7.0 in 1999 (and those two releases were in the SAME year):
Code:
Mon Oct 25 15:44:34 CDT 1999
(* Slackware-stable version 7 is released *)
Mon May 17 20:17:35 CDT 1999
(* Slackware 4.0.0-stable is released *)
Or much more recent SLE (Suse Linux Enterprise) going from 12 to 15 (openSUSE had a 13.x set of releases, but there never was any mention of 14, the inbetween openSUSE Leap used 42.x as its point releases).
Slackware going from 4.0 to 7.0 in 1999 (and those two releases were in the SAME year):
[CODE]Mon Oct 25 15:44:34 CDT 1999
(* Slackware-stable version 7 is released *)
Of course, I forgot all about Slackware 4-7.
The earliest example I can find of version skipping is MacOS jumping from version 7.1 to 7.5 in 1994 because 7.5 was seen as a significant improvement. There may be earlier ones.
In short, PROBLEMCHYLD, devs can skip or change version numbers for all sorts of reasons from practicality to creativity to their own amusement. I'm personally pleased that the opportunity to release Slackware 13.37 wasn't missed.
The earliest example I can find of version skipping is MacOS jumping from version 7.1 to 7.5 in 1994 because 7.5 was seen as a significant improvement. There may be earlier ones.
Windows wins again <grin>
Windows/NT going from 3.1x to 3.5 in 1994 - but these are minor version jumps, we were talking about a major release jump.
BTW: The NT version number is not now generally used for marketing purposes, but is still used internally and NT 10 is the internal version for Windows 10, Windows Server 2016 and Windows Server 2019 (according to wikipedia).
Before that all releases since Vista had a 6.x NT version.
While you dear fellow Slackers are busy researching the versioning decisions, quite entertaining, I must admit, I'm worried that given the pace&style in which the kernel is newly developed, the 5.x will soon turn into stable and Greg Kroah-Hartman will write another blog post and "urinate" on all the other inferior versions, emphasizing that the latest stable is the one they put all their best knowledge&efforts to make it the best performing and the more stable and secure.
All this in the context of the upcoming Slack 15 that will be released with 4.19
(if I'm about to follow drmozes' statement) https://www.linuxquestions.org/quest...4/#post5943592
Just as a thought, maybe a suggestion, given the point above, also the latest CPU security issues (some changes being backported just partially on older stable kernels) and the speed and diversity in which HW is developing nowadays, maybe always supporting the latest stable kernel release, the one endorsed by the kernel folks, would be the way to go for Slackware.
Last edited by abga; 01-10-2019 at 08:14 PM.
Reason: stable
Just as a thought, maybe a suggestion, given the point above, also the latest CPU security issues (some changes being backported just partially on older stable kernels) and the speed and diversity in which HW is developing nowadays, maybe always supporting the latest stable kernel release, the one endorsed by the kernel folks, would be the way to go for Slackware.
The problem there is: stable Kernel releases live much less long then stable Slackware ones and the newest stable kernel often cannot be backported TO that Slackware version as the toolset to compile it (gcc + glibc) is now out-of-date.
That's why Slackware 14.1 is still on 3.10 (and 14.0 on 3.2), because otherwise you won't be able to compile kernel modules, like for nVidia or VirtualBox, on those systems. Even 14.2 cannot compile a 4.19 kernel anymore.
Only -current really has the capability to switch kernel versions as it is NOT a stable version (and it often breaks those modules for a while until the developers OF those packages catch-up with that newer kernel).
So Pat has decided to go with the LTS kernel releases as at least they get some support and backported patches for a longer period. If you look at 4.xx kernel releases you see that 4.15 thru 4.18 are already out of support (although less then a year old) and 4.20 will follow soon after 5.0 has been released. But 4.19 will not.
Just a clarification, I used bold as a highlight for the stable word because it was an edit - an omission in my original post.
This topic was discussed in some older on-subject threads and you have your point related to the toolchain being dependent on the kernel headers. I do remember that the term "LTSB" was also questioned in those threads - use the search function on the Slackware forum here on LQ.
However, due to these new CPU vulnerabilities, the toolchain also needs backported patches and it might be that only a limited set of these will be actually applied on older versions of the toolchain, much like in the fashion in which the kernel is doing. For instance, gcc 5.5, that comes with Slackware 14.2 got some, not sure they are all the ones that were added in gcc 8.0 (had no time to follow them): https://github.com/hjl-tools/gcc/com...-branch/master
Still to your point, maybe it won't be a bad idea to release and support the kernel together with a correspondingly compiled toolchain. Take them both as interdependent, as they are actually the core of any distribution, not only the kernel.
I don't know, I have a feeling that things are getting rather close though. If left longer than two weeks it will be the longest gap between releases ever. PV has been rather quiet of late [and Eric, for that matter], and no new kernel on stable for nearly four months. Of course none of these things by themselves indicate much, but just call it a hunch. Of course I am happy [and privileged] to wait as long as the man wants, but I have an inkling that we're nearly there.
Back to my point, things have (fundamentally) changed and that's what I reflected on.
That is certainly true. Things like the kernel and i.e. Firefox keep on being updated in a rapid pace but distribution releases have gotten so complicated that they are not.
Above I already mentioned that Slackware 4.0 was succeeded by 7.0 in less then half a year and the 3.x versions were even more rapidly (3.0 to 3.6, 7 releases, in about 3 years).
From 7.0 onwards the delay between releases has become larger, first to about a year but lately getting close to three years (if 15.0 will be released in the summer).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
