Just you, indeed! We all make different choices based on whatever ideals we hold dearest, and they all have consequences.

I hope that yours work out good for your future.

Mine have worked out fantastically well by my own measures which do not include "amount of cash" as a constituent parameter. I suspect I could not explain any of that sufficient to your actually understanding it. That is not a sleight, just acknowledgment of our obviously differing perspectives and works both ways (Ex: Why do you pay rent? What do you value more than cash? What was the most unpopular decision you ever made, and why?).

I hope the "screwing over" remark was offhand and not something that you would defend on due consideration. Directed towards Pat of all people in the context of Slackware version release scheduling I can't help feeling seriously offended on behalf of Pat and all concerned. Please reconsider that thought.

I do not know Pat except as originator and guardian of Slackware and by his presence here at LQ. But I know and respect the character he has demonstrated consistently and repeatedly, and that respect is not so fickle as to depend on whether or when there may be another Slackware release.

We can't know what choices he makes each day. Pat's choices are his own, made for his own private reasons unless he also chooses to share them with us. Give the man some respect for having made them, and breathing room to follow his course!

If your choices are at odds with his, then at least say, "Thanks for ride!", when you leave to follow your own path.

For all of you who don't want to put in the effort of keeping your -current install up to date, you do have the option of just installing it and not applying updates (ever, or only once a month, or once a year, or whatever you're comfortable with).

Using current has certain implications of the user's willingness to use, test and debug new software. I can certainly understand the plight of people who wish to use stable software, but require newer software for their new hardware. At the time Slackware might not be the best distro for those people. Of course some people are more than comfortable living with current and the increased maintenance burden.

I would prefer to let updates slide a few days, but I figure since money's often tight and donating is often tighter, seeing if things break is something I can do. :)

Likewise I am in a similar position. I don't update everyday, but I usually at least try to diagnose, solve or at least report any issues I find with newer software in current or elsewhere. Not everyone has the time, energy or will to do this and I won't fault anyone for not doing it. Still using current may not always be smooth sailing and this can be required.

There are reasons why it says on DW Release model: Fixed
So what difference does it make 3 years with no RC, even if there were 10 years with no RC it would be perfectly normal.
Even if stable release is not maintained at all, which is not the case with 14.2, one can backport and maintain in house, I do this all the time, where's the problem.
I'll usually test all RC, but rolling release/unstable branch whatever you want to call it, more often than not gets pulled from under your feet, so I just don't.

I, for example, cannot do that. I lack the skills.

I naively expect my operating system to work for me, not the other way around. But you guys, go on and assure each other how little you need a new stable release. That's the trend around here that grants you "Did you find this post helpful? Yes". I may sound bitter, but I did need a more modern -stable Slackware release in a very critical moment of my work. Did not happen and I managed nevertheless, "stayed true" to Slackware and even credited my beloved distro in the end result. It just felt like swimming against the current (no pun intended) and I am not sure I am ready to do this again. I understand Patrick has his own problems, I have tried to help by donating and I try to give something in return to the community. However, it annoys me when users just overlook the obvious, that 14.2 is too old to run on modern hardware.

If one is unversed in it, -current is like a daunting mythological beast, a roc or harpy only for the experienced to wrestle with. But if one has been running 14.2 for any sizeable length of time, -current is more like a guinea pig or rabbit - ultimately non-threatening, just needing to be fed once in a while.

I can only guess at the delay for 15.0 but part of it must be related to waiting for kernel 5.3 and Xfce 4.14. Still, -current is very stable, possibly moreso than a lot of so-called 'stable' distros [as an example I've had Ubuntu 18.04/Xubuntu lock up on me multiple times, and Debian Stretch fail to boot on occasion, neither of which have happened with -current]. Just download one of Eric's ISOs, install and update it once a week, month, or go the 'solarfields' way and never update it. It's fantastic for newer hardware. Just keep an eye on the changelogs.

OK, see you tomorrow.

Yeah, I was also thinking that Pat is perhaps evaluating which 5.x kernel to use, and perhaps some other additions. Pat always delivers a first rate release; 15.0 will be amazing. :)

That's a pretty big jump from 4.19, isn't it?

Perhaps. We don't know what Pat is thinking. The kernel numbering system is rather arbitrary anyway. Pat will pick a well-supported kernel for 15.0.
Interesting times ahead.

This is pretty much my mindset as well. In the last 3 years I used 14.2 for the first year and switched to current for the last two years. I've gotten pretty lax about updating current and have gone over 4 months at the longest between updates. The only issues I've had with Pats current have been my own fault when I forgot to update my initrd and did a reboot. The other debugging I've had to do is with Plasma 5 but it's been running pretty stable for the last year or so.

Of course the one caveat is that I don't have too many SBo packages or self packaged software and none that have extensive dependency lists. Most of the updating I do outside of current is via slackpkgplus with alienBOB's repositories and I'm grateful for the work he puts into maintaining software. If you use more third party software then I understand the reservations with tracking current.

It's a matter of using a LTS kernel release. 4.19.x will fall out of support too soon to be suitable for Slackware 15.0, so Slackware 15.0 will need to be based on a more recent LTS kernel, but there isn't one yet, per https://www.kernel.org/

No, not larger than from 4.14 to 4.19, which has already happened in -current (on Oct 23 2018). But I do not expect 5.3 to be more stable then say 5.1 or so, especially in the first year, to look at the number of patches 4.14 and even 4.9 are still getting.
The kernel for 14.2, 4.4.x seems to stabilizing a bit more now, but still already has a lot more patches then say the 3.x ones (3.18 ended up at .109, 3.16 is still being maintained, but is only at .69).
So waiting FOR 5.3 would probably postpone Slackware 15's release to at least 2020, for that kernel to stabilize a bit more.

Hrm. Although I seem to recall having other kernels in /testing or /extra in the distant past. That could be an option, if 5.whatever isn't ready.

I think a lot of these patches are due to Spectre/Meltdown/etc. We are at an unprecedented place in regards to security with computer hardware.

But then I'm not a kernel developer and don't know how many of the patches are for stabilization/bug fixes vs mitigation for new security issues with processors.

That being said, 4.19 is scheduled to be EOL by DEC 2020, which is 1.5 years away. This would limit the length of time Pat can provide kernel security updates for the next release. (I don't understand why the kernel devs gave back-to-back kernel releases 6 years of support... they really should spread that out to every other or every third release.)

I do not know which releases you mean.
Lately they've made every 5th a LTS one (4.4, 4.9, 4.14 and 4.19) so the next one should normally be (what would have been) 4.24, which will now be versioned as 5.3, seeing that 5.0 could have been 4.21.
In the 2.6 era the LTS ones were much closer together:
(from kernel.org)
Kernel 2.6.40 became 3.0 to flatten the version number scheme and then 3.20 became 4.0
There is no real significance in the .0 releases anymore, other that "the minor version became too large".

A lot of them are for newer hardware too, like all kinds of SSD's that aren't connected through S-ATA connections anymore. Hardware development is going very fast at the moment too, that's one of the reasons 14.2 now feels old, there's too much hardware out there that especially the installer doesn't support.

Belated happy 3rd birthday, Slackware 14.2!

I'd sort of like to see a Slackware 14.3 release using the 4.19.x kernel series. If the 5.3.x kernel series is a LTS release and once it stabilizes (whatever that means), a fairly "quick-turn" Slackware 15.0 utilizing the 5.3.x kernel series could be released. Best of both worlds for me!

Of course, this ship belongs to and is being steered by PV and I defer to his expertise.

Best,
Lumpy

I'm strictly talking about their extended LTS, which is for 6 years rather than the standard of 2 years. Almost all LTS kernels get around 2 years of updates, but the powers that be decided that the 4.4 and 4.9 kernels will get 6 years of support, so the 4.4 will be supported until 2022 and the 4.9 will be supported to 2023.

In my opinion, it would've been better to space the extended LTS support to every 2nd or 3rd kernel. That could've left the 4.4 until 2022 and then the 4.14 or 4.19 for much longer support times. Hopefully the new 5.x LTS will be extended support, but I've thought that for 4.14 and 4.19, so I won't hold my breath.

That could be because some major distro's LTS releases (NOT RHEL, they do their own kernel maintenance and do not even use LTS kernels, i.e. the latest RHEL 8 uses 4.18, which was already EOL at the time OF the release) are using those kernel versions.
I haven't tried to find out which ones, but in the past that has been the reason of extended longterm kernel support.
In the end it's Greg Kroah-Hartman's decision as it's mainly him supporting the LTS kernels and backporting new patches TO them.

Interesting. I've toyed with the idea of installing -current alongside 14.2 to get an idea of what's coming in 15.0, because, yeah, I'm excited about 15.0 coming. But I must not be a very demanding user, because 14.2 does everything I want Slackware to do, so installing -current has been of lower importance to me than other things like learning OpenBSD and dabbling in programming languages and SBCs. I can wait for when 15.0 is ready.

Besides -current being low priority for me, another thing holding me back from installing -current has been the admin burden I thought I would have to take on. But I update 14.2 when security fixes come out for the software I'm actually using, or 1x week, whichever comes first, but not when bugfixes or any other updates come out. So far, that has caused me no problems.

It hadn't occurred to me to update -current on the same basis. So on that suggestion, I checked how many days in May and June security fixes came: 14.2 had 8, -current had 10, some days with more than one security fix, but not all of those were for software I use.

While in -current many more *things* would update, amd each updating session would run longer, since I'm using Slackpkg+ (and Alien Bob's packages would also update), I doubt I would spend any more man-hours per year updating. I would spend a bit more time reading changelogs, and maybe generate new initrd's more often, but I would also probably get more choosy about when I ran updates.

The one thing I'm not sure about is the few Slackbuilds I have on 14.2. That might be a deal killer for using -current for now. I'm not experienced in compiling packages, so I would have to get proficient at that to get the same packages in -current, no? I would probably not keep both 14.2 (or 15.0) and -current on a machine long term.

TKS

What is it you need? I've got a few installed with current. Ponce has a repository of updated slackbuilds for current. (They are what the new archive will be.) There's also a lot of clever people here, if you're having problems, but do check Ponce's stickied thread first before building anything.

Lilypond and OBS are the two I built. OBS just had a lot of dependencies, while Lilypond did have an issue that's got a workaround. (I still don't know what the deal is with 2.8, but 2.9.13 is going to be the next stable release of lilypond. Does make sense that newer code works better on current than a source tree that's 4+ years old.)

garpu, thanks, I'd forgotten about Ponce's repo.

I use three slackbuilds, one of those being a dependency for another, and I just checked that all three are in Ponce's repo. I once installed another two, but don't use them anymore.

So with that Slackbuilds on -current question answered, -current is looking like a candidate for the next installation on my machine, if 15.0 doesn't come out first.

TKS

When it was announced, it sounded like it was going to be all kernels from 4.4 and on, but nothing has been extended after 4.9.

https://itsfoss.com/linux-lts-kernel-six-years/

EDIT: After doing a bit more searching, it sounds like they're waiting to see if people are actually using extended LTS releases. The below quote is directly from Greg Kroah-Hartman

Nobody was born with 'skills' as you call it, for the most part it's just experience and knowledge of OS internals accumulated over time, or lack thereof.
Blame the hardware vendor who only builds a driver for one specific version of windows, and doesn't share source code for that driver.
What is obvious the 'old' windows OS will not work on new hardware by design, you're either pushed to 'new' and 'improved' OS, or write your own driver from scratch.
While this is common for hardware vendors, it's not standard for all OS; i.e. linux kernel isn't supposed to break userspace so it's possible to get new hardware support for old OS.
It may be hard to fix sometimes, but sure as hell beats having a hardware vendor decide which OS you may or may not run on your property.

The grass isn't greener out there folks. Over the last little while I've tried out several distros for the heck of it and I find them sadly wanting. Very grateful for Patrick and the entire Slackware Team. Very happy to be a Slacker. :)

*** Strong Opinion Alert ***

I think it is the future that is "not greener", and we are at a point of forced sea change, and not for the better. Slackware is our refuge where we continue to build on proven ideas, while Linux itself has become very much a corporate entity now entirely under the Open Source flag and other distros chase business models void of Free Software ideals.

In the end, when keeping to the path becomes too difficult for Pat and Slackware, there will be no path with continuity for us to follow - we will change or become increasingly isolated running our privately maintained versions on aging hardware.

Free Software gave birth to the tidal wave of innovation which spawned GNU, Linux and a thousand other useful projects. But Free Software is now practically a four letter word, and our information and computing world is fundamentally changed for the worse without it as the driving force. Definitely not greener...

It was nice while it lasted. Thanks for holding the line as long as you have Pat, I hope we can continue another birthday or two or three!

.. on whatever hardware we can support.

I'm actually pretty okay with this. The worst-case scenario you describe is more or less what using free software was like in the early 1990s. It wasn't as nice as the massive, intricate software ecosystem we have today, but I used it and enjoyed it.

It might not even get that bad. Let's stick by our values and see where they take us.

If it becomes impossible for Pat to maintain Slackware in its present form I will not be upset if he is forced to adapt to tidal forces and make unwanted changes to our operating system. We're a happy anomaly in the open source ocean. I am grateful that Patrick stays true to his vision for Slackware.

I thought SecureBoot would be doom for Linux, and so far, it isn't. If it becomes standard on all motherboards and unable to be turned off, then people will find a way. Back in the 90's, boot floppies were common, and it wouldn't surprise me if we need to go to the equivalent in the future.

It seems like OS development goes in waves of complexity and simplification, though, like a lot of things in the universe. We're seeing a pattern of simplification, for good or for ill. I'm concerned about the Linux ecosystem, that having been said, and what the commodification of FOSS is doing to it. Things do need to change, because hardware is changing, however. Should it go in the direction it is? I'm not sure. I think if change does happen to Slackware, it will be measured, reasoned, and not change for the sake of the newest shiny thing that doesn't work.

Very true. Let us not forget how difficult it is for Pat out there. Remember this (https://www.linuxquestions.org/quest...9/) from last year?
Man, this broke my heart.
I'm not exactly in a very good financial situation, but I tried to help, because without Slackware I don't know how I will continue to work. So, if anybody out there knows some sure way to give money to Pat, a small contribution once in a while will be good for him, and in return it will be good for the whole of the Slackware community and to our good old Slackware Linux.

I used Paypal. If there are other ways people know about, or if the man himself can, sort of, validate the most appropriate ways of contributing, that would be great. :hattip:

Long live Slackware.

Long live 14.2!

Seeing as how it is probably the last version of any Linux distro that I will be able to use at least for the foreseeable future.

I do not think Pat would make the 'unwanted changes'. It would be kinder to put Slackware down, allowing it to stay true to itself, than to make it into something it never was. There's no point given it an extended synthetic existence on life support just for the sake of it.

Quality of life is better than quantity. If the big 'unwanted change' seemed unavoidable, I would completely understand it if Pat decided to put it to rest rather than change Slackware into a mutant.

I apologize for suggesting that unsettling scenario. Like you I am very comfortable and happy with the present state of Slackware.

Haha, no need to apologise at all. I think it's inevitable in these kinds of threads. But at least we both addressed that 'potential' politely, respectfully and most importantly, namelessly.

Care to share which you tried and a general thought or two about what was lacking or not up to snuff compared to Slack? Unless that's offtopic :p

No, not really off topic. And I bet one of them was Debian :p

I ran Arch and Debian for a while. I had a lock-up with Debian. It put me off. Very happy to be running Slackware and OpenBSD.

'Debian' used to lock up on me too, which is one of the reasons I moved on from it.

hitest, your comments made me think of something. If it were inevitable that Slackware couldn't avoid The Crawling Chaos any further, it would be the end of an era not only for Slackware but for the Linux desktop in general.

It would essentially be a tragedy. It would mean that the disease had crept so far into the ecosystem that it had become inseparable from that ecosystem to the point whereby curing it would mean killing its host. I know that many of us have, in the past, discussed which OS we would move to in such a scenario but, on reflection, I think that we would be duty-bound to move to *BSD since migrating back into Linux-land would be giving the contagion further organisms to infect and convert. More heads for an increasingly-powerful hydra.

I don't actually think we're at that point yet, but it's a very important option for consideration. Does convenience matter that much to us - or should we brave a bit more research to stand up for our ethics? If there are people here who already use *BSD, then that's great. I personally do not. But as Slackware users, such learning curves should present us with little drama. Why are we even here otherwise?

I do not foresee Slackware forcibly adopting the init system that shall not be named. There's simply no need for it.
Perhaps we will have to adopt elogind which (just like eudev) is a piece of the S**D code that can be used standalone, but even elogind is currently only required if Slackware were to adopt KDE Plasma 5 *and* would add Wayland at the same time.

I still hope that ConsoleKit2's implementation of the 'login1' protocol will be finalized one day, so that other software like KWin and SDDM can incorporate CK2 as an alternative login1 provider to elogind.

I've used OpenBSD since 2011(version 5.0). Like Slackware OpenBSD is simple, elegant, and robust. OpenBSD has exceptional documentation and a wonderful community(just like Slackware).

How about the project leader? I've heard... stuff... ;)

Bahahahaha. True. The leader of Linux has a colourful history too. That does not influence my decision on which operating systems to use.

Today I learned that the guy who made reiserfs is doing time for murder. Damn, I missed a lot of news in grad school.

Anything that can be done can also be undone. ;)

Yes, it esssentially meant the end of the kernel developers supporting reiserfs version 4, the implementation in the kernel has stayed at 3.x(from the man page for 'mkreiserfs', for the '--format FORMAT' option)

Although work has been done on reiserfs 4, it hasn't been incorporated into the mainline kernel(from the wikipedia page for reiserfs)
and(again from wikipedia for the reiser4 fs).

And now I read the entire Wikipedia page on Hans Reiser. Creepy stuff.

Careful observers might have noticed that CRUX is much more BSD-like than Slackware. And it looks like that at least in theory it has better chances to survive.


Cheers