Same sentiments here.

And it's the wrong way.
Today I had to install a new server at work.
As much as I wanted to use Slackware, I would have hard time explaining to the management (when asked) why I used a "beta" release on a production server instead of a "stable" one.
Even at home I don't run current.
So Debian got installed instead. Debian 10.1 released on September 7, 2019.
Debian stable does releases every ~ 2 years. And supports them for ~5 years.
The party line that "it's ready when it's ready" is utter BS.
It's ready any time, just do the release.
For applications, if there is no major release for over a year, I consider it abandoned / dead.
For Linux distros, 3 years is about the outer limit.

4 members found this post helpful.

Don't apologize or explain yourself to EU snowflakes.
This trend of "my feelings are offended by ...just about everything" attitude of recent years is like a cancer.
It's this "cancel" what you don't like or don't agree with way of dealing with everything.
In past, we'd never have any friends with this attitude. But when faced with this, we flipped a finger and said "[removed]", giggled and went on to our favorite watering hole to have a beer together and a long conversation about everything and anything (well.. women, politics the most popular topics).

So you will never use Red Hat Enterprise Linux (or its free partner distro CentOS)?
- Red Hat Enterprise Linux 7.0 (Maipo), June 10, 2014; 5 years ago
- Red Hat Enterprise Linux 8.0, May 7, 2019; 4 months ago
(from wikipedia), so that's almost 5 (FIVE) years between major releases (there have been point updates in between for RHEL 7, though, 7 up till now)

Or Suse Linux Enterprise
- SLE 11 24 March 2009
- SLE 12 27 October 2014
- SLE 15 16 July 2018
(there have been no 13 or 14 releases).
So again, in a commercial distro, 4 to 5 years inbetween major releases.

In Suse the equivalent of -current is openSUSE Tumbleweed, while openSUSE LEAP is much more closely related to SLE

2 members found this post helpful.

That's right, I considered CentOS but when I noticed how old the release is, I rejected it immediately. It looks like the distro is understaffed and not maintained sufficiently.
I don't have clients that would want Redhat and pay for the support for Linux, but I'd say it could be considered an exception to the rule due to it's commercial nature.
I strictly reject any software that has dual releases - enterprise/community (open) and never would use one. It's fake open source and I see them forked all the time. Suse is similar in nature to former Mandrake. Don't hear much about either any more on the net.
Sad thing is Mandrake was really good 20 years ago, and I used it for couple years, until they started with the membership/free editions BS. That's when I switched to Slackware.
One year release cycle may look too frequent to some, but those with a new computer are looking at fairly fresh software release, instead of wondering whether this 3 year old OS will run on their new computer.
I liked the one year release cycles of Slackware, and although I don't upgrade as soon as I see a new release, I take my time and install when I have some free time, usually during winter long weekends or holidays.

So, Slackovado, this all begs the question what is it that you require that is so bleeding edge that stable 14.2 doesn't have or can't get? In my experience Enterprise systems almost always stay a bit behind with "tried and true" excepting very specialized areas of development. As for new hardware support, Debian 10.1 is on 4.19.0 iirc and my 14.2 is running 5.0.20. So what is it 14.2 can't get for you?

1 members found this post helpful.

I'm having a really hard time getting my AMD RX580 to run properly on 14.2 even with trying to update specific packages to support it. I'm now up to the 5.3.1 kernel and I upgraded mesa, which led to many other things needing to be upgraded, and something in there broke my opengl. I've been digging through it trying to find what's broken, but it's been a slow process and I don't have as much time to work on it as I'd like. I'm tempted to just reinstall all the stock packages and then try again.

I'm half tempted to switch to -current, but I know I won't keep it up to date, which can make building stuff from ponce's -current unofficial SBo repo a nightmare.

Upgrading the kernel will provide support for most hardware, but if you're wanting upgraded graphics, you better either run Nvidia and their blob or you gotta get later versions of mesa and the like for the proper support.

chrisVV, you've been a member long enough to know posts like #40 aren't acceptable here at LQ.

--jeremy

4 members found this post helpful.

My

I admit this cycle has been longer than usual I am itching for a release; but it will be ready when its ready.

3 members found this post helpful.

A 3-year old stable release with security patches is perfectly fine for a server OS. For a desktop OS it's somewhere between getting a bit long in the tooth and being non-functional on modern hardware.

I think the previous release model worked when releases came out about once to twice per year. Now, the distro on -current and patches/ are no less up-to-date than ever, but optics matter, and the perception is that 14.2, released 3 years ago, is out of date.

Perhaps it's time to re-think the versioning model. 14.2 has received many, many patches. If after a certain point in time, a new ISO were re-rolled applying the current patches, and released as a point release (eg, Slackware 14.3, 14.4, etc.), and new releases as we know them always applied a major version bump, Slackware might not be perceived as out-of-date as it is.

This would be a similar model to Debian, but simplified. When we see that the newest version of stretch is 9.11, released in September 2019, it seems current, even though it's really just 9.0, which was released back in 2017, with security patches.

3 members found this post helpful.

It begs no question since as I clearly (obviously not clearly enough for you) stated that I didn't want to have to explain to management why I installed a beta version of an obscure distro on a production server.
Further I didn't want to go through another distro upgrade in near future when new Slackware is finally released.
Debian is freshly released and good for next couple years right now when I needed it.

I like this idea. Rolling out a new ISO image requires little work and support. I have a cron job that creates a new ISO image from my local mirror. I pay no mind to the task.

I don't merge /patches but I think in terms of this idea that would make sense. I'm thinking the installer could be updated to look for /patches and if present in the ISO, install those packages. Loosely something like Windows slip streaming.

A point-release creates an illusion that a distro is "keeping pace." Whole number rollouts could be reserved for major releases every two to three years.

Equally obvious as not clearly enough for you (my apologies) is I wasn't asking why you didn't choose -Current (which, btw is beta in name only at worst, not to mention the old saw about software being beta, obsolete or both ) I asked why you didn't just choose 14.2? and specified what about 14.2 was so old AND could not be upgraded to suit your purposes? Quite honestly my question was not meant to be an attack or even bait so no need to be so defensive. I honestly would like to know what specifics compel people to the other old saw "New == Improved".

1 members found this post helpful.

Especially since/if Pat is no longer manufacturing, packaging, selling physical CD/DVD disks.

+1

The point-release should not be maintained as a distinct release (i.e. no patch created only for a specific point-release). It should only be a snapshot of the corresponding major release with all existing patches applied at the time it is created. (or else, it would become a maintenance nightmare...).

For example a Slackware 14.2.<n> could be issued today, either as a 14.2.n directory tree, or as a 14.2.n ISO install image, with all existing patches for 14.2 applied (not in a separate patches/ subdirectory). The maintenance effort (creating patches) should be mostly unchanged.

1 members found this post helpful.

So, rather than release a new Slackware branched off a more recent version of current, so bringing us a new "stable" with more modern packages ( which seems to be what many, myself included, want ) you propose redefining release and making a song and dance about Slackware 14.2.502?

Do you pair work in Marketing?

2 members found this post helpful.