This sounds so familiar and in particular the lazy bit! Although I have at least reached the state of having a Guix install medium with a non-free kernel ready to go.

Nice ideas, but in my opinion, none of it is going to happen (unless someone gets fed up enough to fork Slackware and make it an open community project, seems unlikely though since there's so many other projects that function this way where all the groundwork has already been laid). Actually I think one of the cool things about Slackware is/was the closed development model, so you get a system that works well because it has a unified vision behind it (rather than changes coming from different directions), but it seems to be breaking down now for whatever reason, although I acknowledge that the current state of affairs will be totally fine for some.

He doesn't actually do any coding at all these days.

While I don't agree at all that "the situation is diabolical and unacceptable", I do agree that it's likely that everyone has a time or three wondered "if there will ever be a 15.0" and exactly as you note because of no progress mentions and even what feels like a bit of dismayed frustration regarding Plasma by Eric but Slackware is great, is optionally free, and IS worth waiting for. Like you I do wish there was a bit more two-way communication. At some point of growth a distro becomes less just an offering and morphs into a relationship.

Since I am one of those guys asking "What can't you do" I should mention two things. -

1) Two months ago I did "move on" to -Current so it may seem that I'm being hypocritical (as opposed to "hyper-critical" ) but I don't see it that way since the sole reason is Plasma5/KTown and it's just that I like it better than v4, not because there's anything I can't do in 14.2.

2) Hardware support is a non-issue since it is entirely handled by the kernel, the "stock" kernel is still very supportive and it's easy to build the newest ones with "make oldconfig" or if you're especially lazy "makeolddefconfig" withb just a moment in menuconfig or xconfig to check box whatever new hardware you need.

So I'm still asking "What exactly can't (or now, couldn't) you do?" Do you actually do "production" that Eric finds limiting and "stale"? Do you find Ubuntu or even Debian, especially the Stable releases, so much newer and more useful? Was it really worth all the adjustment certainly required at the very least for the different syntax of any deep level work in systemd?

TLDR - Isn't the move from 14.2 Stable to Ubuntu extreme compared to moving to ~Current? If it wasn't, sorry Brother but I have to conclude you are far more concerned with a false sense of "new and improved" and the Windows-y business plan of a "do it for me" Ubuntu. Canonical? Seriously?

Wasn't it you that noted as a benefit that (paraphrased) "Slackware wasn't designed with User ease in mind"?... and further noted that as a tradeoff for User Power? What happened? Tired of the Power or the responsibility?

---
nevermind

I don't think I've ran into any major issues with software compiling that hurt due to a lack of a new version while running 14.2. Yes, there are newer versions of several programs that I use that won't compile on 14.2 (kodi and several KDE based applications), but there hasn't been anything introduced in those newer versions that I felt devastated that I couldn't run them. However, it seems there is still a very large amount of software I use that can have their latest versions compile and run fine on 14.2.

The only serious limitation I've found with 14.2 is hardware support. Much of that can be solved with a kernel update, but video card support isn't nearly as easy to upgrade as you tend to need to upgrade several portions of the graphic stack. This is not something for the faint of heart.

I will continue to use 14.2 for the foreseeable future while looking with eager anticipation towards the 15.0 release. I would love to have newer versions of a lot of software, but I'll continue to stick with this for the time being.

NOTE: I do realize that my situation isn't everybody's and others might run into a lot more roadblocks when staying with 14.2, some being disastrous which requires either upgrading to -current or switching to a different OS. Others may prefer the bleeding edge that -current tends to offer. There is no perfect version for anyone and I'm not here to tell anyone what version of Slackware (or other distro) they should be running. But I think we can agree that it would be nice to have 15.0 released sooner rather than later and that it'd be nice to get a statement from Pat on where we're at.

4 members found this post helpful.

Thanks for the broadened clarity, bassmadrigal. I probably should've noted "given an nvidia graphics card" since those don't require any additional work on the stack.

The thing to keep in mind that this lack of hardware support includes the 14.2 installer not detecting NVME drives, which by now are a common feature in laptops; although one can work around that it is a pretty big hurdle to jump through for anyone that has not previously used Slackware.

2 members found this post helpful.

No more to say.
http://www.slackware.com/~msimons/slackware/grfx/


AMD Threadripper / AMD Epyc/ AMD Ryzen/ AMD Radeon Pro

Frontline AMD 64 cores /128 thread's cpu AMD Threadripper

What, AMD architecture to be lost in Slackware ?

Want Testing More ? https://amd.com
https://www.amd.com/ru/products/processors-desktop

It run at Linux Slackware 64-bit current, AMD Ahtlon II 250 / AMD RADEON 6770 / 8Gb RAM:
https://warthunder.ru

https://vk.com/warthunder

Also STEAM in non-predictable state for Slackware 64-bit current (i, and my little sun, was complete testing).

My blog about Linux, FreeBSD, and Cyber Life at https://vk.com/7cyber

1 members found this post helpful.

I think you need me to jog your memory - following a fourth internal hard drive installation on my main machine, Slackware refused to boot. After several hours I decided to install Debian, and after a few months I moved to Ubuntu because of the newer graphics stack. So in answer to your question, "what exactly can't/couldn't you do on 14.2?" - well, get the OS to start. Would -current have worked instead? Maybe, maybe not, but did I care when I 99.9% knew that Debian would solve it for me? No.

I am beyond the point of low-level tinkering these days: if I want to install something new, I just want the process automated for me. I don't want to search for dependencies, I don't want to watch the compile fail, I don't want to find that something didn't install because I didn't use the right flag. In the past, when I used to come up against a problem I would enjoy researching it, for hours on end... to think of all the work I put in trying to understand persistent naming, only for my tried-and-tested documented method to fail the third time inexplicably. But priorities change and the intellectual satisfaction I used to gain from such problem-solving dissipated and now I prefer for my time to be spent in other ways. It is no surprise to me that a few of the most experienced long-term Linux users I know moved to Windows on their home machines.

As far as I see it, if somebody wants to move off one distro to another, that's OK, and it's not for someone else to tell them, or to imply, that their choice is wrong. I'm guilty of this too though - the amount of time I must have spent telling people not to use systemd I hate to think - the amount of time I used to spend berating users on FDN did little but enhance that forum's poor reputation - and I'm sorry for that, I'm sorry to everyone who I talked down to, because now it just doesn't matter to me anymore [but that's just what "they" want, right?].

Whatever works for the user is the most important thing. We are now in the 2020s: computing - and its userbase - have changed hugely since the 1990s. Slackware is clearly struggling to catch up.

5 members found this post helpful.

Hello Lysander
I read that entire thread (sorry I missed it before) and it looks to me that many didn't bother to check out the specs on your motherboard. Unless I'm mistaken it is a Core 2 Duo system with an ICH10 chipset and the latest BIOS/UEFI update is dated 2010. That's a perfectly valid system but with a BIOS that old there are some limitations and quirks with getting SSDs to run right, even as SATA and forget about PCIe.

I'm in the same boat actually with the next gen Z77 system. I can't directly boot an NVME drive on a PCIe sled BUT if I use a bootloader (LILO) from a system fully recognized in BIOS (a mechanical SATA drive) AND have the kernel, config, and System.map from the NVME copied to the mechanical installation, at some point in the boot process (I'm assuming once fstab gets loaded) the process hits !!Turbo!! NVME speed and positively "screams to the finish line", and it's all NVME from then on. It's a PITA to upgrade and not elegant but it will do until my new board is installed that does support NVME IN BIOS.

Obviously something is loading in Debian and Ubuntu kernel that takes over from your older BIOS and works fine. I'm just saying whatever that is, what quirk you could learn from that, could be used to continue using the power of Slackware instead of being shackled to repositories and auto-dependency resolution. I grant you that some people like that convenience but it IS a tradeoff and DID come at a cost and it is not because Slackware is "struggling to keep up". That convoluted problem is divided among your older hardware (much like mine) and yourself.

If you're pleased with your tradeoff of convenience over power that's fine and dandy but make no mistake you have opted to step down a bit from the role of Admin to User, even if Advanced User is more accurate. You could have chosen to learn something to make Slackware, even 4 year old 14.2 work for you. You instead chose convenience and that's not because Slackware is old. I think that's just an excuse because you got frustrated with old hardware (2010 at best) mixed with new hardware, and admittedly less than optimal support recognizing that quandry.

It is a tough situation dealing with the many transitions in hardware compatibility at the firmware level. I do sympathize with you and you are missed. Good luck in your new home.

5 members found this post helpful.

^_^
Boots fine here. But then again, I would not buy any hardware that is not confirmed to work with LTS kernels anyway so YMMV.
Some of us have different hardware where it is futile to fix something that ain't broke as it may cause new and unpredictable bugs.

I think it was some of the wine devs who once advised me to only buy previous series of motherboards to use with linux/unix..
So I listened to their advice and went for DDR2 when DDR3 was current, might go for DDR3 now that DDR4 is current, etc.
Guess that's why I never end up in situation where kernel driver for my hardware does not exist yet.

Anyway, we're way off track by now.. XFCE by default will not make any difference.

3 members found this post helpful.

Disapointingly unfair.

As said before, good luck in your new home !

True, but without enterprise level support, or the kind of custom support MS gives to those still running Windows XP, "stale" software is just that - outdated and potentially vulnerable.

I had to do this years ago with Debian stable, more than a few times, which even when released was "out of date" and you could run into trouble quite soon if you had newer hardware. The solution was somewhat easier there as you could attempt backports of existing packaged mesa, drm and X if necessary from the unstable or testing repositories and then just compile a newer kernel. But it was certainly not hassle free. On some occasions dependent on specific hardware and how old a release was, you would get away with it, on other occasions it made more sense to just follow the testing or unstable branches.

With the latest Slackware being over 4 years since release, some may find themselves in either of the above scenarios, particularly off putting if they were new to Slackware, and trying to install the 14.2 release - and facing compiling a whole new graphics stack and kernel or switching to following the -current branch.

4 members found this post helpful.

For the hardware and standard APIs there is also Xorg and OpenGL which are difficult to upgrade in an old system.

For gaming these are useful in their latest version even for old hardware (in which we can't do all).

So that's why I now use Slackware current.

1 members found this post helpful.

I've no doubt whatsoever that a glass door salesman would be very interested in replacing the standard steel airlock hatch with 2mm of glass.
And always because: 'everyone has glass doors these days' and: 'your steel hatch and periscope is so deprecated and obsolete' but never because: 'glass door company don't give a toss about security'.
It's not that obvious that company profit > customer security, until the point where it defies the laws of physics. Like that shoddy IoT device with hardcoded root password.