LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 10-03-2019, 03:32 PM   #76
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware, Proxmox, Debian, CentOS, Ubuntu
Posts: 1,212

Rep: Reputation: Disabled

Quote:
It should only be a snapshot
That was all I intended and I think all that Poprocks intended.

Quote:
rather than release a new Slackware branched off a more recent version of current
Pat treats Current as a testing branch. Only he deems Current ready for release. Point releases would be announced only between a speculated 2 to 3 year Current cycle. Pat could return to 9 month to 1 year releases and that would render the discussion moot.

Quote:
you propose redefining release and making a song and dance about Slackware 14.2.502
The idea was that approximately every 6 months to 1 year, Pat would update the ISO to a point release. Basically the original release plus /patches, although some method of merging or slip streaming /patches packages is needed. For example, there could have been 14.3 14.4, and 14.5 releases.

Quote:
Do you pair work in Marketing?
On occasion Pat has shared that marketing is not a strong skill. I suspect he welcomes various ideas even if he rejects them. Once upon a time he tried a marketing ploy of bumping the version from 4 to 7, something that did not go over well. Incremental point releases gain market attention and PR notice at the click-bait sites. I think the idea of a point release is palatable and keeps Slackware "in the news." An alternative is return to a 9 month to 1 year release cycle.

Another idea is to provide newer kernels in /extra or /testing. This provides users a way to install kernels with newer drivers and avoid compiling kernels. If provided in /extra then Pat has to ensure compatibility with existing packages. Providing in /testing eliminates that upstream responsibility.
 
2 members found this post helpful.
Old 10-03-2019, 03:36 PM   #77
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.2
Posts: 3,470

Rep: Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813Reputation: 1813
Well, most of this is about perception, isn't it?

Quote:
My God, the last release of Slackware was in 2016!!!! It must be abandoned!
Quote:
Well, yeah, but the last patch as I write this was released on October 2, 2019 and there have been a lot of updates since that release.
Now, I underlined the word "most" above for a reason; it isn't all about perception. I bought a new laptop a few weeks ago and ended up installing -current on it in order to get installer nvme support as well as proper AMD graphics support.

EDIT: I'm not actually quoting anyone, merely simulating a short conversation.
 
5 members found this post helpful.
Old 10-03-2019, 03:51 PM   #78
OldHolborn
Member
 
Registered: Jul 2012
Distribution: Slackware
Posts: 187

Rep: Reputation: 153Reputation: 153
Quote:
Originally Posted by upnort View Post
keeps Slackware "in the news."
Only if you want the news to say "rehashing the same old stuff with the odd security patch while the world moves on"

Quote:
Originally Posted by upnort View Post
An alternative is return to a 9 month to 1 year release cycle.
Yep! 1 or even 2.

But it's 3 and 3 with no sign of it settling down towards Stable
 
Old 10-03-2019, 03:57 PM   #79
philanc
Member
 
Registered: Jan 2011
Posts: 233

Rep: Reputation: 191Reputation: 191
Quote:
Originally Posted by OldHolborn View Post
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?
No. a "new Slackware branched off a more recent version of current" means a new release, which --given Pat's high standards-- has to be maintained for a very long time. Given the growing complexity of desktop linux, maintenance is a growing burden. And making new releases, let say every year, makes the thankless maintenance work even bigger, because all releases have to be maintained.

The "point-release" approach is precisely not to create a new release (with all the added maintenance work), but to periodically propose a new install media (ISO image or directory tree) with existing patches applied.

It would allow a user to download and install for example a recent Slackware 14.2.3 issued let say last June, and then download and apply 3 months of patches instead of 3 years.
  • it could enforce the perception that Slackware is alive and kicking for people who are not forum or IRC regulars,
  • it would not require much more maintenance work since patches are still prepared for release 14.2 in the example, as they are now.

Of course, we all want as you said "more modern packages" (including a more modern kernel). But at least many of us also want maintained stable releases. And the more releases the higher the effort.

Quote:
Do you pair work in Marketing?
No. No "pair", no marketing. Just people discussing ideas about how to make Slackware more attractive to a larger number of people. Because "more attractive" means more donations, more Patrons. Just better survival odds.
 
1 members found this post helpful.
Old 10-03-2019, 03:59 PM   #80
OldHolborn
Member
 
Registered: Jul 2012
Distribution: Slackware
Posts: 187

Rep: Reputation: 153Reputation: 153
Quote:
Originally Posted by Richard Cranium View Post
Well, most of this is about perception, isn't it?
No, or not here anyway.

Stable = patches come along you should install them

Current = Do I, don't I? Do I feel lucky today?

What message do we give a new(ish) user? Do we start tellling them *not* to apply patches?

New stable = it's up to date and you should install patches.

Sorted!
 
Old 10-03-2019, 04:05 PM   #81
Poprocks
Member
 
Registered: Sep 2003
Location: Toronto, Canada
Distribution: Slackware
Posts: 470

Rep: Reputation: 246Reputation: 246Reputation: 246
I think we all know we're just discussing for discussion's sake and the decision-making is all up to Pat. Can't we just have fun brainstorming?
 
4 members found this post helpful.
Old 10-03-2019, 05:39 PM   #82
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware, Proxmox, Debian, CentOS, Ubuntu
Posts: 1,212

Rep: Reputation: Disabled
Quote:
Of course, we all want as you said "more modern packages" (including a more modern kernel). But at least many of us also want maintained stable releases. And the more releases the higher the effort.
Here I empathize with Pat and the team. Desktop users tend to want updated packages. Server users and admins tend to want only patched packages. Like most things in life, there is a struggle to find balance and there are points of diminishing returns.

Pat is not alone with finding this balance. One of the common complaints about Debian and Red Hat distros is the age of software and the challenge of trying to update to something newer.

The Debian maintainers are resolving that old claim with shorter release cycles.

My guess is Pat will do likewise after releasing 15.0.

Quote:
Can't we just have fun brainstorming?
I thought that is what we were doing.
 
Old 10-03-2019, 05:46 PM   #83
Poprocks
Member
 
Registered: Sep 2003
Location: Toronto, Canada
Distribution: Slackware
Posts: 470

Rep: Reputation: 246Reputation: 246Reputation: 246
Absolutely, @upnort.

Pat said something similar in the TLLTS interview in 2006.

Personally I think KDE5 has probably been a big issue for this release cycle. Sure, Pat could just take the work AlienBob has done and throw it into -current, but it's a huge amount of software as well as a big undertaking. You can't really unring the bell either once it's added.

I think if it weren't for KDE5, we'd easily be into beta territory by now.
 
1 members found this post helpful.
Old 10-03-2019, 08:13 PM   #84
FTIO
Member
 
Registered: Mar 2015
Location: Las Vegas, NV
Distribution: Slackware 14.1_32
Posts: 262

Rep: Reputation: 130Reputation: 130
Quote:
Originally Posted by jkh2cpu View Post
I use slackware64-current on my main box, and slackware64 on the stable, never crash box.

On the main box, I like to diddle with gimp-2.99 which is gimp-master. The gimp requirements of babl and gegl are switching to meson/ninja for building. I'd like to see ninja and meson on slackware64, which means slackware-14.3 or maybe 15.0.

I see on my subscription slackware64 dvd that the kernel dates from 2016, so I'm guessing it's time for a new release.

John.
Ugh...
Attached Thumbnails
Click image for larger version

Name:	AwJeezNotthisCrapAgain.jpg
Views:	45
Size:	28.0 KB
ID:	31455  
 
Old 10-03-2019, 09:17 PM   #85
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware, Proxmox, Debian, CentOS, Ubuntu
Posts: 1,212

Rep: Reputation: Disabled
Quote:
Personally I think KDE5 has probably been a big issue for this release cycle.
My guess is KDE5, Xfce 4.14, and PAM are the big decisions for Pat. I suspect the kernel version is a not significant concern (4.19.x will suffice for the next release).
 
2 members found this post helpful.
Old 10-04-2019, 12:46 AM   #86
ttk
Member
 
Registered: May 2012
Location: Sebastopol, CA
Distribution: Slackware64
Posts: 878
Blog Entries: 27

Rep: Reputation: 1225Reputation: 1225Reputation: 1225Reputation: 1225Reputation: 1225Reputation: 1225Reputation: 1225Reputation: 1225Reputation: 1225
Quote:
Originally Posted by upnort View Post
Here I empathize with Pat and the team. Desktop users tend to want updated packages. Server users and admins tend to want only patched packages.
You hit the nail on the head, there. There's an intrinsic tension between the two roles, and the Slackware team has always done a very good job of walking the line between them.

If I ever tried to fork Slackware again, it would have a fairly narrow focus on the server role. Servers are my main interest, and trying to solve a simpler problem might result in a higher quality solution than if I tried to walk the desktop/server tightrope.
 
3 members found this post helpful.
Old 10-04-2019, 06:01 AM   #87
Slackovado
Member
 
Registered: Mar 2005
Location: BC, Canada
Distribution: Slackware 14.2 x64
Posts: 298

Rep: Reputation: 62
Quote:
Originally Posted by enorbet View Post
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".
You are correct. I didn't quite answer directly to your question. Although I thought I mentioned it earlier in the thread, that I didn't want an old release and also didn't want testing version.
It's quite possible that 14.2 would work just fine but I am still not sure what/how many features I will be implementing.
I actually started a related (in my thoughts) thread earlier about porting a server 2008 and Exchange 2007 into Linux.
And that's why I want to install the latest stable releases available and not a 3 year old distro.
So it's mostly just a preemptive move, but one that makes sense when investing time and effort into a production server.
Honestly, after a lot of thought given to it, I might have gone with Debian anyway, even if new Slackware was just released. Mostly because of the number of packages ready for deployment and how extensively it's tested. And it's always been stable and solid for me, even though I've hated it for how different it it from Slackware.
 
Old 10-04-2019, 08:18 AM   #88
chemfire
Member
 
Registered: Sep 2012
Posts: 233

Rep: Reputation: Disabled
To the talk about integrating the packages and re-spining the ISOs as point releases eg 14.2.x etc. I don't this is a very good idea for a few reasons.

1) It would increase the size of the repos considerable. A lot mirrors already don't carry the ISOs because of bandwidth / storage. ISO image are very convenient for end users and It may discourage mirrors from mirroring them by creating superfluous ones.

2) Creating your own re-spin with the patches merged is quite trivial as they are full packages. Maybe its even worth doing if you are going to do a large number of installs. Who honestly does that though? If you are doing a large number of installs you probably want to clone a system anyway; not run through the installer a bunch of times. Its also pretty easy grab the entire patches directory and upgradepkg --install-new *.t?z; as well. If you do this before any system config work than you can blindly take any .new files a step 0 as well. So I don't see much value to justify effort spent this way technically speaking, really it only offers marketing value.

3) You will create more confusion. Lets be honest many of us on this board have a decade or more experience in the Slackware universe; but given how far the rest of the Linux world has drifted Slackware can be pretty darn alien to new folks. Do you really want them figuring out if they can use that slackbuild/package for 14.2 on their 14.2.3 system?

4) Not sure things a lot of people are using slackpkg, sbopkg, etc would understand a new versioning scheme and more trees; but I have not looked at the code. These might also need modification, even if it is trivial. Of course if you don't create or don't publish separate trees you can avoid that as well but its just one more thing to consider

5) All of this takes effort from Slackware's already highly limited human resources; I dare if spare cycles exist time would be better invested in just updating the website, fixing broken links, maybe sticking a little progress report on current out there etc.
 
2 members found this post helpful.
Old 10-04-2019, 08:22 AM   #89
solarfields
Senior Member
 
Registered: Feb 2006
Location: Outer Shpongolia
Distribution: Slackware
Posts: 1,031

Rep: Reputation: 606Reputation: 606Reputation: 606Reputation: 606Reputation: 606Reputation: 606
i don't care that much of 'more modern packages'. What I need is updated kernel (this I can do) and newer ATI drivers (this I can't do). That's it..
 
Old 10-04-2019, 11:54 AM   #90
philanc
Member
 
Registered: Jan 2011
Posts: 233

Rep: Reputation: 191Reputation: 191
Quote:
Originally Posted by chemfire View Post
To the talk about integrating the packages and re-spining the ISOs as point releases eg 14.2.x etc. I don't this is a very good idea for a few reasons.
Interesting points.
Quote:
1) It would increase the size of the repos considerable. A lot mirrors already don't carry the ISOs because of bandwidth / storage. ISO image are very convenient for end users and It may discourage mirrors from mirroring them by creating superfluous ones.
Yes. I overlooked this one (you know, all the blah blah about storage is so cheap nowadays, etc.). Some mirrors probably use some space graciously offered by third parties with some quota attached.

OTOH, one point-release each year wouldn't represent more storage than the full release each year that some people ask for.
Quote:

2) Creating your own re-spin with the patches merged is quite trivial as they are full packages. Maybe its even worth doing if you are going to do a large number of installs. Who honestly does that though? If you are doing a large number of installs you probably want to clone a system anyway; not run through the installer a bunch of times. Its also pretty easy grab the entire patches directory and upgradepkg --install-new *.t?z; as well. If you do this before any system config work than you can blindly take any .new files a step 0 as well. So I don't see much value to justify effort spent this way technically speaking, really it only offers marketing value.
Agreed. It wouldn't target skilled people that know Slackware well. Rather users who want to try Slackware, and find on the site a fresh (one year old at max) install media.
Quote:


3) You will create more confusion. Lets be honest many of us on this board have a decade or more experience in the Slackware universe; but given how far the rest of the Linux world has drifted Slackware can be pretty darn alien to new folks. Do you really want them figuring out if they can use that slackbuild/package for 14.2 on their 14.2.3 system?
I don't think so. Understanding that a slackbuild is valid for a stable release and all subsequent point-releases is not too difficult. Not for people building with Slackbuilds anyway. A Slackbuild could be deemed valid for 14.2 and all 14.2.x snapshots.
Quote:

4) Not sure things a lot of people are using slackpkg, sbopkg, etc would understand a new versioning scheme and more trees; but I have not looked at the code. These might also need modification, even if it is trivial. Of course if you don't create or don't publish separate trees you can avoid that as well but its just one more thing to consider
This is closely related to the previous point. Maybe the term "point-release" is confusing. Maybe it would be better to simply offer recently updated installation snapshots. I think this what is done by the big distros (redhat, debian).

Quote:

5) All of this takes effort from Slackware's already highly limited human resources; I dare if spare cycles exist time would be better invested in just updating the website, fixing broken links, maybe sticking a little progress report on current out there etc.
Yes. And this is the most important factor. This is precisely why I think that demanding more frequent (yearly!) full-fledged releases is not reasonable. A full release come with years of support...

When the resources are limited and the scope and complexity grow year after year, something has to go:

- either reduce drastically the scope (the biggest elephant in the room here is KDE, but all the desktop stuff is huge (gtk, qt))

- and/or reduce the new release frequency (this is what is happening)

- and/or reduce the number and the duration of old releases maintenance

We often ask for more (more features, more frequent releases, ...). Maybe we should start saying what we are ready to give up.

Last edited by philanc; 10-04-2019 at 11:55 AM. Reason: typo
 
2 members found this post helpful.
  


Reply

Tags
new release


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
How long after release of a new major release do you wait to put a Linux server into production? silence00 Linux - Server 1 08-29-2019 10:49 AM
LXer: I'm excited for a new Ubuntu releaseófor the first time in a long time LXer Syndicated Linux News 0 05-01-2017 11:33 PM
Slackware Essentials update with new release of Slackware? mralk3 Slackware 9 11-10-2015 04:23 PM
how to understand user time, sys time, wait time, idle time of CPU guixingyi Linux - Server 1 08-24-2010 10:10 AM
LXer: Linux Foundation Announce New Members, New Standards Release, New Testkit LXer Syndicated Linux News 0 04-08-2007 11:04 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 04:46 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration