If you value always having the latest software, you go for a rolling-release distro, where any update might break this or this part of your system, esp. if you add things yourself. If you value having the least trouble, you go for a stable distro, where things can slowly get too old to support this or this particular thing. It's a matter of choice, and you can hardly have both.

Now, this 15.0 is special, because it has a very unusually long development cycle. This is why it currently turns to be a such tragic choice. I don't know if Pat is contemplating some revolution in the Slackware's life cycle, but the "when it's golden-ready" model seems, sadly, to get a bit breathless nowadays. In the whole Linux ecosystem a release is more and more a not-so-bad development point you almost-freeze and maintain for a not-so-long period.

2 members found this post helpful.

That's a very sweet offer but not necessary. My Slackware-14.2 has been rock stable for two years and only occupies 13GB and I built it up in precisely this way. I find it fun and educational too. So I plan to build -15 in the same way. It will be easier actually because I have the old packages file directory to guide me in what I need.

Right now it boots properly, X works, slackpkg with plus works, and I confirmed this morning that I can build software on it. That's all I really want from an alpha-release.

1 members found this post helpful.

RE: Quote:
Originally Posted by enorbet
Do you consider it wiser to put up the deed to your home as collateral on a 2 dollar bet?

I suspect you missed my point so let me clarify. What application do you imagine is more valuable than the base operating system? Perhaps if you are a software developer your work may require up-to-the-minute applications and libraries. I really don't know of any other use case that must have all the latest. Many who think they do are merely seduced and salivating over the false idea that "New==Improved". Sometimes newer is better but not always. Sometimes newer is just bloated, overly complicated, and slower. Some prefer the base system never be at risk. The worst that can happen in Slackware, if one is even moderately careful and knowledgeable, is a new app won't run or run right. The system still works so anything wrong can be fixed until said app does run right..

A major advantage of Slackware, that few these days grasp, is it's Vanilla nature which makes building from source easy and solid, so the vast array of software is not restricted by someone creating a package for you.

So, are you really free on a rolling release, or are you simply locked down with comfortable, convenient chains?... and more importantly and back to my point, are you really comfortable risking the base system? Is fixing a base system easier, less time consuming or less maintenance than fixing a single app?

1 members found this post helpful.

You seem to misunderstand. Packages aren't frozen, but they're only upgraded when security issues or bugs arise (see the changelog for the stable 14.2 release -- there's been a LOT of patches since 14.2 was released). Once a stable release of Slackware is released, stability is paramount. When you start upgrading programs, instability can be introduced. Security issues or bugs are taken into account and the severity of the issue compared to the potential instability is reviewed and Pat will make a decision.

If upstream still maintains the branch that is in a stable release, Pat will use that. If not, he may try and backport patches or consider switching to a newer branch (but trying to determine if the potential instability is worth the security issue). If packages aren't expected to break other things, Pat is more likely to update them (like Firefox). However, Pat will stick with the same kernel version (it was released with 4.4.14 kernel and is currently at the 4.4.240 kernel).

Other projects, like SBo (similar to Arch's AUR) can and do have package updates. It's up to the maintainers to decide what update philosophy they keep.

But if you're running a webserver and you have multiple sites on there that use php, you don't want some random update from your OS go and break all those sites. You don't want a kernel upgrade to break some of your hardware (a lot of people had issues with the 5.10.x kernels crashing their systems).

This philosophy is not for everyone, but most Slackers prefer the way Pat manages his distro.

3 members found this post helpful.

I appreciate the way that Pat manages Slackware; our distro is stable, secure, and predictable. Looking forward to 15.0.

2 members found this post helpful.

Slackware is...

A distribution which is released when stable and not according to a fixed schedule. Every release of Slackware Linux is thoroughly tested by the Slackware team and the community. Slackware places high value on stability rather than the “newness” or “freshness” of software.

A distribution where “simplicity” is preferred over “convenience.” The lack of GUI helpers (common in many other commercial distributions) for system administration tasks is a case in point.

A distribution where system configuration and administration is done through simple ncurses helper scripts or by directly editing well-commented configuration files through a text editor.

A distribution that does not add layers of abstraction or complexity on top of existing solutions. For instance, Slackware package management is handled by simple scripts acting on compressed tarball package files (*.tgz, *.txz, *.tbz) and there is no dependency handling for package management.

A distribution which abides by the common-sense dictum “if it's not broken, don't fix it.”

A distribution where the major decisions are taken by the BDFL (Benevolent Dictator for Life, the current chief maintainer Patrick Volkerding) and where the development process is more closed than purely community based distributions. As a result, Slackware is highly focused on its core strengths and values and does not cater to every preference of its community or others. For this reason, there is less pressure on the Slackware development team to be popular and cater to the larger mass market.



Snipped from https://docs.slackware.com/slackwarehilosophy


The day "we" deviate, I'm off....

Not that that matters anything for anyone!


But that philosophy page was exactly what it took to make me a slackware follower... my way too to run an OS.


Back on track, please...

1 members found this post helpful.

Did we forget to wager bets when the real mcKoy will hit the streets?

I'd say it's due at next phase of the middlest Jupiter moon

Whooops! Don't feel badly. I forgot to re-run lilo on my laptop when installing a new kernel. Didn't keep a good one around, either. Think that's actually the first time I made that mistake...

Heh. I've got a little betting pool among friends (to a donation to my local food pantry--groceries or $20) if I get the covid vaccine or a 3060 video card first. (And in what month. So far I'm thinking June for the vaccine. Friends say April and July. Nobody's betting that I find a 3060.)

I don't think ray tracing is so big a deal that it's important to get a video card that supports it right now, marketing notwithstanding. And by the time it is, video cards will have become much more affordable.

Just my

1 members found this post helpful.

That is indeed stupid, especially if you use a linux distro as a desktop OS. The cause of that is because there is not 1 linux distro base with a certain tool-set and specific mainline of libs, package-format, etc.. But there are many distro's with many different versions of libs, toolsets, etc. So a vendor can not just release one binary version of their software package when it expects certain libs, toolsets to be on the target system.

To overcome that, you need to either do "manual labor" to compile a certain version of software yourself, if that is possible. Or, go for one of the solutions like Appimage, Snaps, flatpacks. But these solutions are not perfect, since they normally contain everything that that software needs. And with for example Ubuntu's Snap those packages can be 10 to 100 times the size of the regular package. And some do not integrate well visually, which makes it looks messy. But even though Ubuntu is being criticized a lot on Snap, they are at least trying to create a structural solution for this issue. And obviously some other distro's come up with their own solution, so that we now have an x amount of solutions again, which creates basically the same issue again!

It would be nice to have some kind of hybrid method with Snap, that for example a software package checks with your system, what matches on your system with that what it needs. And then creates a snap package for your system. That could reduce the size a lot.

To structurally overcome this it would be better to have 1 base linux system, LTS fixed featured complete mainline release, for all. I suggest Slackware :P

But basically this issue is the price the user pay's for his freedom.

Naw. I can totally do without it. It's a silly little pool to kill time while waiting for the vaccine. And, hey, it might raise some money for my local food pantry, too.

I noticed 5.11 is in testing. Are we waiting for coming LTS kernel realese? Kernel arithmetic tells it should be 5.5.x. I myself would be very happy of this. I would have chance to install 15.0. I can't install system with kernel which EOL is in next year. From other hand -current is not a productive. One can't invest much in -current. I mean I could but for this I need much better equipment than now. Old laptops are not well suited for mass rebuilds etc.

-current already has the latest LTS release: 5.10. (https://www.kernel.org/category/releases.html)

If you search the forum I think you'll find some clues as to why 5.11 is in testing.

Yeah, but planned EOL for 5.10 is the next year. If Slackware keeps policy to stick with LTS kernels, then, assuming 15.0 will be released this year with 5.10.x, new release 15.1 would has to appear just next year. My arithmetic tells me that I would be running 15.0 for year in best case. What about people running 14.2? The kernel 4.4 also has EOL in next year.