Spin off from 'What version of Python 3.x should ship with Slackware 15.0?'
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I am as disappointed as others that Slackware has not seen a release in over 5 years. It is also frustrating not knowing the plans for Slackware and what caused the delay. Was it waiting for PAM? Was Pat working on PAM on his personal test station for years getting the PAM configuration to the spot he thought was right before pushing it out to the public? Maybe, maybe not.
All I'm saying is it is really easy to look back now and see that releases should've been made, but it's much harder to realize at the time that things were going to still be years away from a release.
I linked my SlackBuild repo (which is not in sync with SBo anymore, but it also holds the SlackBuilds that aren't on SBo) in the post you quoted. I also have my random scripts repo available. For my custom packages, I don't have them available, because I just took existing SlackBuilds and used them for the versions of software that I wanted to install. I probably still have the packages available in /tmp/ if you really think there is a benefit of making them public. However, it seems that most people who need newer software just decide to run -current. I don't want to do that because I don't have the personal time in my life to keep -current up to date and fix my broken 3rd-party packages when an update breaks them.
Pretty sure I never called you lazy. I have no reason to call you lazy because I don't know what you're doing. If I did, please point it out so I can learn from it and try to not do it in the future. I try to refrain from name calling while I'm online.
You're right, I don't have a clue what you've had to do. But just because you had to do a lot of stuff doesn't mean that Pat is lazy.
We actually had a thread about the activity in Slackware and how much faster paced development of 15.0 has been compared to previous versions. I even came up with commands to determine how many packages per day Pat has averaged when provided a ChangeLog.
-current is averaging 12.53 packages per day and 14.2 averaged 4.55 packages per day (before release... this doesn't count packages that were released as patches).
So Pat has averaged almost 3x as many package changes per day during 15.0 development compared to 14.2 development. Even if we remove the "Rebuilt" option, he's still averaging 8.09 packages a day, so almost double 14.2's development. Hardly lazy in my mind.
I'm seeing pip in the package database of my -current machine from 2019.
The first two come from aaa_libraries and the latter is from the libpng package. However, you're not going to see all the symlinks in the package database as those are logged in the script database (/var/lib/pkgtools/scripts/). (The below is from my 14.2 machine.)
Code:
jbhansen@craven-moorhead:/share/gothrough/slackware-mirrors$ grep libpng..\\.so /var/log/scripts/*
/var/log/scripts/aaa_elflibs-14.2-x86_64-23:( cd usr/lib64 ; rm -rf libpng16.so.16 )
/var/log/scripts/aaa_elflibs-14.2-x86_64-23:( cd usr/lib64 ; ln -sf libpng16.so.16.23.0 libpng16.so.16 )
/var/log/scripts/aaa_elflibs-14.2-x86_64-23:( cd usr/lib64 ; rm -rf libpng14.so.14 )
/var/log/scripts/aaa_elflibs-14.2-x86_64-23:( cd usr/lib64 ; ln -sf libpng14.so.14.18.0 libpng14.so.14 )
/var/log/scripts/aaa_elflibs-14.2-x86_64-23:( cd usr/lib64 ; ln -sf libpng14.so.14 libpng.so.14 )
/var/log/scripts/libpng-1.6.37-x86_64-1_slack14.2:( cd usr/lib64 ; rm -rf libpng16.so )
/var/log/scripts/libpng-1.6.37-x86_64-1_slack14.2:( cd usr/lib64 ; ln -sf libpng16.so.16.37.0 libpng16.so )
/var/log/scripts/libpng-1.6.37-x86_64-1_slack14.2:( cd usr/lib64 ; rm -rf libpng16.so.16 )
/var/log/scripts/libpng-1.6.37-x86_64-1_slack14.2:( cd usr/lib64 ; ln -sf libpng16.so.16.37.0 libpng16.so.16 )
/var/log/scripts/libpng-1.6.37-x86_64-1_slack14.2:( cd usr/lib64 ; ln -sf libpng16.so libpng.so )
Like I said Bass they are not on the FILELIST.txt that is what I use to see the changes to cat the FILELIST.TXT look for pip2 and libpng.so14
I made this very clear to you. It is in the var.log but not on the file list. Then Showed you the build script for the package.
You understand how the FILELIST.TXT is created right.
Sure you do your a smart guy Like your scripts. But the file list is a huge deal when working with Current. ok. It shows the installed record of packages. then shows all the extra content.
So do your self a favor cat | grep and look for them on FILELIST.text get back with me.
Keep up the great work on them scripts.I guess pat installed libpng14 as a default installed from pasture. I do not think so.
Relax Bass this isn't an issue for you it is for me as I try to make sure builds to don't use pip2 or libpng-14.so.
It is a big one for me. I rely on the filelist.
You do understand Libpng may have been built with a different Zlib this causes issues with none slackware builds.
There is a newer "they think faster" for of zlib-ng they are developing for Cloud based apps. We have split minizip from Zlib. then we build Libpng with this supposed faster zlib. This was my issue.
OK relax you want to be part of the work get with me.
You do understand why we remove all /usr/lib*/*.la files right.
pthread is part of the GLIBC now. pthread is able to use what is in the /usr/lib* look here I finished the work on it.
Pat updated far more packages than the builds provided by Eric and Robby (not to dismiss the work they did on those, I have mad respect for both of them as well as Stuart and Vincent, in addition to the regulars like Matteo, Willy, Didier, and probably others I'm forgetting).
24K package changes since 14.2! That's a crazy large amount!
Quote:
Originally Posted by lovemeslk
Pat can call My dad a Sock Puppet all he wants But he still has My Visa card on his server.
Pat hasn't called you anything and he doesn't have a server that has your card info on it.
Quote:
Originally Posted by lovemeslk
I have the First amendment right to speak Honestly.
You misunderstand what the first amendment offers you... it is that the government can't silence you, but private websites, like LQ, have every right to censor what you say.
Quote:
Originally Posted by lovemeslk
Like I said Bass they are not on the FILELIST.txt that is what I use to see the changes to cat the FILELIST.TXT look for pip2 and libpng.so14
I made this very clear to you. It is in the var.log but not on the file list. Then Showed you the build script for the package.
You understand how the FILELIST.TXT is created right.
You seem to misunderstand what the FILELIST.txt is... it is a list of files on the mirror/installation media, not what will end up on your computer. The files that will be installed on your computer are listed on the MANIFEST.bz2 file on any mirror and installation media.
Seriously, look through the FILELIST.txt file. It will contain all the files that will exist on the mirror or installation media you download. It will contain the packages and source files, but not the files that reside within the packages. That is what the MANIFEST.bz2 file will contain.
Quote:
Originally Posted by lovemeslk
I guess pat installed libpng14 as a default installed from pasture. I do not think so.
Pat has libpng14 installed via the aaa-libraries package. This is specified in this file. The same happened with 14.2.
Quote:
Originally Posted by lovemeslk
You do understand Libpng may have been built with a different Zlib this causes issues with none slackware builds.
Nope! Both libpng and zlib were part of the rebuilds for glibc 2.23. They weren't even upgraded during this rebuild, so there's no chance it was built against a different zlib. Neither have been upgraded since the last mass rebuild.
Code:
Mon Feb 15 19:23:44 UTC 2021
Here we go again... upgraded to glibc-2.33 and one last mass rebuild for
Slackware 15.0. The only packages upgraded in this batch are glibc and the
kernels - everything else is just a rebuild against the new glibc. Not
rebuilt in this batch: devs (best to just leave this alone), glibc-zoneinfo,
kernel-firmware, rust, linux-faqs, linux-howtos, aspell-en, mozilla-firefox,
mozilla-thunderbird, and seamonkey. There's a new Rust compiler but Firefox
and Thunderbird will need to be patched to use it, so we'll hold off on
those until they're ready for the new Rust either with patches or new
upstream releases. Until we have that and a few more scheduled upgrades I'm
not quite ready to call this beta yet, but you can call it 15.0-alpha1. :-)
Cheers!
--snip--
l/libpng-1.6.37-x86_64-3.txz: Rebuilt.
--snip--
l/zlib-1.2.11-x86_64-4.txz: Rebuilt.
Quote:
Originally Posted by lovemeslk
There is a newer "they think faster" for of zlib-ng they are developing for Cloud based apps. We have split minizip from Zlib. then we build Libpng with this supposed faster zlib. This was my issue.
Slackware doesn't contain a minizip package nor the zlib-ng package. I'm not sure what you're trying to claim...
Quote:
Originally Posted by lovemeslk
You do understand why we remove all /usr/lib*/*.la files right.
To be honest, I don't know anything beyond what was posted in the ChangeLog when the change was made.
Code:
Hi folks, and welcome to the third ever Slackware Mass Rebuild (and the
longest ChangeLog entry in project history). There were two primary
motivations for rebuilding everything in the main tree. The first was to
switch to the new C++ ABI. The second was to get rid of all the .la files
in the LD_LIBRARY_PATH. Really, having .la files installed has been mostly
obsolete since things began to use pkg-config instead, but it's not easy
to get rid of them unless you do it all at once. If you just take them out
of one package, any other packages containing .la files that refer to the
removed ones will be broken. We've removed a few here and there before
(and then handled any packages that had referred to them with a rebuild),
but it was time to finally remove all the ones in /lib{,64} and
/usr/lib{,64}. One of the reasons that this really needed to happen is that
many projects are starting to migrate to build systems other than autotools,
and those systems do not generate .la files. So if we didn't get rid of them
now, we might end up in a situation later on where they are being removed
by upstream and then we would have to chase down the dependency breakage and
recompile (possibly many) other packages. The .la files that are outside of
the LD_LIBRARY_PATH were not removed (and shouldn't be) - those ones are
often used by the lt_dlopen() function to load plugins and removing those
ones can break things. But those ones don't cause problems... they aren't
likely to try to infect .la files produced by other packages.
IMPORTANT NOTE: If you have any third party or other packages installed on
your system that don't come with Slackware, and those packages have installed
any .la files, it is very likely that they refer to some .la files which we
have just removed, and that trying to compile against these packages will no
longer work. Luckily, the solution is simple: remove them. This command will
remove any stale .la files from the LD_LIBRARY_PATH:
rm /{,usr/}lib{,64}/*.la
Moving forward, nothing shipped in Slackware will contain any .la files in
those directories, and any SlackBuilds intended to be used with Slackware 15.0
should contain this bit of script:
# Don't ship .la files:
rm -f $PKG/{,usr/}lib${LIBDIRSUFFIX}/*.la
In addition to those goals, the opportunity was taken to clean up slack-desc
files and make many trivial fixes to build scripts. We've also made it easy
to recompile everything again should there be a good reason to do so.
You'll also find various updates scattered throughout this long list.
Enjoy, and sorry about the bandwidth. ;-)
Quote:
Originally Posted by lovemeslk
pthread is part of the GLIBC now. pthread is able to use what is in the /usr/lib*
There was some huge precursors to changes that where in the wind 4 years ago. "Eric OMG do not miss spell his name" Took that on. He delivered the hardest work of that dev team.
Then I watched Willy do the same.
I watched the Maintainers of XFCE4 keep updated.
Then I watched Pat just try to catch up.
As I say Eric the top Team Dev in my books spoon fed Pat and Pat did not have time for it.
That is my point of view and watching the Mistakes that Eric made and fixed only to see Pat V do the same .
I even brought that to the attention in here LQ.
I said you need to Release 3 years ago do to the huge Problems with changes.
At this point I had to create my own 14.3 and 15.0 and now looking for 15.1 as I see it.
This was caused by two huge changes in the GLIBC and Huge changes from GCC 5.5.0 to the 8.0 to the 9.20 to the 11.0.
I am sorry but that is how the community works.
Pat can call My dad a Sock Puppet all he wants But he still has My Visa card on his server.
I have the First amendment right to speak Honestly.
The failure to draw a line in the sand is a big deal to people maintaining there work with Slackware.
I figured after 2 years he was burned out or personal issues.
So Like Eric did you pick up and try to get it to work.
Yes, Eric did a lot.
Would you add a new 32 bit and 64 bit Stable to take care of when you are flat out broke with 3 mouths to feed, issues regarding funding, and with the distress from that? I understand the complaints and I think people probably should've found something else to use if they needed a production server and Slackware 14.2 wasn't fresh enough for their needs. There are people that are using 14.1 so there are people that find 14.1 fresh enough. He was paid $15,000 out of $100,000 for Slackware 14.2 and he had to make do with that for 2 years. I doubt he had a nest egg for hard times with payments like that. I think most people would be consumed with worry. I sure would be and the crushing stress and depression would be affecting me. Slackware probably would have ended in 2018 if people weren't willing to donate to the project to save it.
There are two ways to look at this in my opinion. That the project was affected by total financial distress and it is just now getting its footing back with a new release in sight, or this is a sign of things to come and the new normal. I believe it is the former. Only time will tell who is right. I think the long wait between 14.2 and 15 was caused by the store. If it was something else then I imagine Slackware would've been downsized.
good morning Radical been waiting for you.
How you been Dad told me all about you.
Quote:
Would you add a new 32 bit
32 bit would be gone the ability to build the gcc-32bit has been around a long time Explained By Eric.
The Kernel ability to turn on -m32 has been around a long time.
Do you realize Drakeo My father headed a fund raiser for Pat V. among his close friends. And was given to him. Eric had some huge donations think back. instead sent to Pat's new store.
You Know Dad is A sock puppet to Pat. Wow you try to keep a cell phone from a half blind man and unable to control his hands.
But you know what. Pat likes the same beer I do to. I am not afraid to give.
I guess I am the little sock puppet.
Lets git with it. lets put out a USB thumb drive for slackware. You want to organize this get with me.
My dad was the one that wanted Slackware to go Public and backed it with 10k of his own money.
Lets do another crowd fund drive.
You get it? not afraid to give. We know the frustration.
We understood the meaning of the Bear server. We all did.
Not Rich but I do support the tools.
I get it Slackware guru's in here love to hate Wrong? seems that's the way for the new people.
Drink a beer. Because I am
Pat updated far more packages than the builds provided by Eric and Robby (not to dismiss the work they did on those, I have mad respect for both of them as well as Stuart and Vincent, in addition to the regulars like Matteo, Willy, Didier, and probably others I'm forgetting).
24K package changes since 14.2! That's a crazy large amount!
Pat hasn't called you anything and he doesn't have a server that has your card info on it.
You misunderstand what the first amendment offers you... it is that the government can't silence you, but private websites, like LQ, have every right to censor what you say.
You seem to misunderstand what the FILELIST.txt is... it is a list of files on the mirror/installation media, not what will end up on your computer. The files that will be installed on your computer are listed on the MANIFEST.bz2 file on any mirror and installation media.
Seriously, look through the FILELIST.txt file. It will contain all the files that will exist on the mirror or installation media you download. It will contain the packages and source files, but not the files that reside within the packages. That is what the MANIFEST.bz2 file will contain.
Pat has libpng14 installed via the aaa-libraries package. This is specified in this file. The same happened with 14.2.
Nope! Both libpng and zlib were part of the rebuilds for glibc 2.23. They weren't even upgraded during this rebuild, so there's no chance it was built against a different zlib. Neither have been upgraded since the last mass rebuild.
Code:
Mon Feb 15 19:23:44 UTC 2021
Here we go again... upgraded to glibc-2.33 and one last mass rebuild for
Slackware 15.0. The only packages upgraded in this batch are glibc and the
kernels - everything else is just a rebuild against the new glibc. Not
rebuilt in this batch: devs (best to just leave this alone), glibc-zoneinfo,
kernel-firmware, rust, linux-faqs, linux-howtos, aspell-en, mozilla-firefox,
mozilla-thunderbird, and seamonkey. There's a new Rust compiler but Firefox
and Thunderbird will need to be patched to use it, so we'll hold off on
those until they're ready for the new Rust either with patches or new
upstream releases. Until we have that and a few more scheduled upgrades I'm
not quite ready to call this beta yet, but you can call it 15.0-alpha1. :-)
Cheers!
--snip--
l/libpng-1.6.37-x86_64-3.txz: Rebuilt.
--snip--
l/zlib-1.2.11-x86_64-4.txz: Rebuilt.
Slackware doesn't contain a minizip package nor the zlib-ng package. I'm not sure what you're trying to claim...
To be honest, I don't know anything beyond what was posted in the ChangeLog when the change was made.
Code:
Hi folks, and welcome to the third ever Slackware Mass Rebuild (and the
longest ChangeLog entry in project history). There were two primary
motivations for rebuilding everything in the main tree. The first was to
switch to the new C++ ABI. The second was to get rid of all the .la files
in the LD_LIBRARY_PATH. Really, having .la files installed has been mostly
obsolete since things began to use pkg-config instead, but it's not easy
to get rid of them unless you do it all at once. If you just take them out
of one package, any other packages containing .la files that refer to the
removed ones will be broken. We've removed a few here and there before
(and then handled any packages that had referred to them with a rebuild),
but it was time to finally remove all the ones in /lib{,64} and
/usr/lib{,64}. One of the reasons that this really needed to happen is that
many projects are starting to migrate to build systems other than autotools,
and those systems do not generate .la files. So if we didn't get rid of them
now, we might end up in a situation later on where they are being removed
by upstream and then we would have to chase down the dependency breakage and
recompile (possibly many) other packages. The .la files that are outside of
the LD_LIBRARY_PATH were not removed (and shouldn't be) - those ones are
often used by the lt_dlopen() function to load plugins and removing those
ones can break things. But those ones don't cause problems... they aren't
likely to try to infect .la files produced by other packages.
IMPORTANT NOTE: If you have any third party or other packages installed on
your system that don't come with Slackware, and those packages have installed
any .la files, it is very likely that they refer to some .la files which we
have just removed, and that trying to compile against these packages will no
longer work. Luckily, the solution is simple: remove them. This command will
remove any stale .la files from the LD_LIBRARY_PATH:
rm /{,usr/}lib{,64}/*.la
Moving forward, nothing shipped in Slackware will contain any .la files in
those directories, and any SlackBuilds intended to be used with Slackware 15.0
should contain this bit of script:
# Don't ship .la files:
rm -f $PKG/{,usr/}lib${LIBDIRSUFFIX}/*.la
In addition to those goals, the opportunity was taken to clean up slack-desc
files and make many trivial fixes to build scripts. We've also made it easy
to recompile everything again should there be a good reason to do so.
You'll also find various updates scattered throughout this long list.
Enjoy, and sorry about the bandwidth. ;-)
I'm not really sure what I'm supposed to be looking at. What does the secondlife client have to do with pthread and .la files?[/QUOTE]
Quote:
read below
This is my work Sir My stuff took it over from Dad. They drop support 2015 for Linux. It is a huge take on for me.
I am nothing close to as good as Dad is. But I took it on. Created my own fork called https://drakeo.bitbucket.io/.
Dude this is a huge open source project. And can be compiled native by Slackware Linux 14.2 and Slackware current.
It is way over my head but the last 2 years been catching up.
We build Libraries Bass then build the code against the Libraries. I brought up the point why libpng-14 in current.
then not on file list.
So no reason I see we need libpng-14.0 I think this is an oversight.
lets get to pip2'
the calls I need have to be pip3 do to I want pure python3 at this point.
I want to make sure the user knows they have pip2 and pip3
This isn't hard to ask.
pip2 was never in slackware 14.2.
\Since it is in Slackware-current could you put pip2 on the filelist.
That means Pat manually stuffs it in to a build fine. but please take time put it on the FILELIST.Txt
What else do we have to go by.
It is a virtual world client for Linux.
next month when new stuff gets pushed it will break it in a huge way. But hey be better than last time.
when they put 32bit builds and called them 64 bit libraries.
So maintaining these libraries and the build for a native slackware Linux client
This was a huge project I was given. Way to hard for me but I am getting through it. I am not a Dev.
I never had a windows machine growing up so I am giving it a shot. I have to build this in windows and Mac.
I do not have 10k to buy the Kakadu licences so I have to get involved with openjpeg.
I need a line in the Sand Pat deal with it.
You do realize one of the libraries is Chromium it's self just to build another one.
look 14.1 was the last to use libpng-14.so. 14.2 was all libpng-16.so I have no clue why we need it in current do to pthread.
I am working on Current.
My question to you why do we need Libpng-14.so and pip2.?
Then Explain sir why they are not on the FILELIST.TXT
How can these scripts libraries help or hurt a project build.
Your a dang smart guy. Seen your Scripts. Sure you understand.
This is Python3.10.0 issue. What part of the slackware installer needs libpng14.0 because Last I looked nothing is building against it
PS
All builds are controlled by python scripts. Through a build-cmd script.
Last edited by lovemeslk; 10-23-2021 at 02:10 AM.
Reason: PS
Do you realize Drakeo My father headed a fund raiser for Pat V. among his close friends. And was given to him. Eric had some huge donations think back. instead sent to Pat's new store.
You Know Dad is A sock puppet to Pat.
That was nice of him and very gracious. "New store?" I hope it wasn't "that" store that took 85% of the money.
Quote:
I guess I am the little sock puppet.
I don't think anyone is a sock puppet. Slackware has stable funding now and it will sink or swim based on design decisions and competition. Is there no other operating system that meets your needs better? You sound miserable and there are a lot of Linux distributions out there to choose from. kikinovak used Slackware as a base for Microlinux, even wrote a book on it, and later decided that CentOS better suited his needs. I suppose now he is using OpenSUSE or Rocky. He seems happy with his choice. It just made better sense for him to switch his OS based on his needs.
This thread definitely "spun off" from the python 3.x debate. Would be nice if the mods could close this thread and let it die, since people are just arguing about Pat in here.
We get it, you have personal issues with him. You should try to resolve those personally, not on a public forum IMO.
Maybe it is an oversight or maybe Pat keeps it there for projects people want to build that don't work against the newer libpng. If you have programs linking to the older one, they should be fixed. They shouldn't do that since the pkgconfig for libpng points to the proper library.
Quote:
Originally Posted by lovemeslk
then not on file list.
\Since it is in Slackware-current could you put pip2 on the filelist.
That means Pat manually stuffs it in to a build fine. but please take time put it on the FILELIST.Txt
Then Explain sir why they are not on the FILELIST.TXT
As I said in the previous reply, you have a misunderstanding of what the FILELIST.txt is. It is NOT a list of all the files that will be on the system after installation. It IS a list of all the files on the mirror and/or installation media.
This is out of the top of the FILELIST.txt file.
Code:
Sat Oct 23 19:06:27 UTC 2021
Here is the file list for this directory. If you are using a
mirror site and find missing or extra files in the disk
subdirectories, please have the archive administrator refresh
the mirror.
You won't see any files on the system in FILELIST.txt, because that's not what it is for.
The slackware{64}/MANIFEST.bz2 contains a file list of all the files in packages and what will end up on your system if you install those packages.
I guess the whole point of the thread was to "spin off" from the python debate, which it has successfully done.
TBH this is just one more angry internet conversations on an internet filled with angry conversations. The concern that Slackware is taking a "too long" is purely subjective and given the way Slackware has always been developed, I really don't think 5 years is abnormal.
But if you guys really want to argue about it, get your numbers straight. There have been >51418 package updates since 14.2. Someone mentioned 24k updates which is a gross underestimate of how much work actually goes into a distro.
So if we consider -current and 14.2 across all x86_* ports:
-current : 50150 changes
-14.2 : 1268 changes
That's 2016 to now. The total is actually closer to 52k/53k when you add in maintenance updates for older (14.1 and ealier) releases in the 2016-2021 timeframe.
I really shouldn't reply again but I'll take the bait. A detractor could say that there could have been a few point releases in the past 5 years between 14.2 and 15.0 with all those changes to Current. Maybe you are right that the crooks at the store taking 85% of the proceeds, leaving a family of 3 with nothing to live on had nothing to do with the developmental cycle, and it was all by design. If that is true then people who are unhappy should find another distro.
I think people who are unhappy probably should find something else that makes them happy unless they are "only happy when it rains." https://www.youtube.com/watch?v=GpBFOJ3R0M4
TBH this is just one more angry internet conversations on an internet filled with angry conversations.
No different than life itself then?
Quote:
The concern that Slackware is taking a "too long" is purely subjective and given the way Slackware has always been developed, I really don't think 5 years is abnormal.
"Some" people here think they own Slackware and can dictate to everyone else when Plasma 5 should be included, when 15 should be released, etc., etc., etc.
All most tiresome, and eye watering in its arrogance.
"Some" people here think they own Slackware and can dictate to everyone else when Plasma 5 should be included, when 15 should be released, etc., etc., etc.
True. But on the other hand, Slackware is nothing without its users, right?
"Some" people here think they own Slackware and can dictate to everyone else when Plasma 5 should be included, when 15 should be released, etc., etc., etc.
All most tiresome, and eye watering in its arrogance.
I think that your remark does not do justice to the concerns voiced in this thread.
What is so bad about asking for a new stable release BEFORE the previous one gets so stale that it is unfit or even unsafe to use as a multi-user system? As I said, I am perfectly fine with running Slackware-current on my laptop until eternity, but that is the case of 'Slackware for the desktop'. The case of 'Slackware for the server' does not benefit at all from a rolling release scheme.
"Some" people here think they own Slackware and can dictate to everyone else when Plasma 5 should be included, when 15 should be released, etc., etc., etc.
All most tiresome, and eye watering in its arrogance.
It is true that people try to dictate and those people should go elsewhere, but what if this development cycle was an imposed choice due to the thieves at the store? Python 3.9 is the better choice for SBo maintainers and Alien Bob with a Slackware release coming, but people thought they were on the 5 year plan, so they were looking at the EOL dates for Python versions. They liked that Python 3.10 would be supported longer, so they voted accordingly regardless how disruptive it is to 3rd party package maintainers they rely on.
Python 3.10 and Current work well for me for my needs. Current is very stable. I can live without a Slackware release for forever but some people can't. I see people constantly complaining on here about the development cycle and they ignore the "store" sized elephant in the room. You can say it will be 5, 6, 7 years between stables so go elsewhere if you want don't like it to detractors, but should people assume that over one development cycle? People are confused on what to expect and if Slackware is right for them. There has been a lot of hazing toward Pat over this confusion over the years without any compassion for the circumstances he found himself in. I think that is unfair to him. I don't know how long the next development cycle will be but I know it will be different from this one because of improved circumstances. I call BS on the idea that the development cycle was completely part of a divine plan that would have be enacted even if Slackware had billions of dollars, and I call BS on the idea that the project is rudderless. I find both arguments tiresome so I re-framed them so people can see the store sized elephant. The store is gone and those issues are gone too in my opinion. Circumstances have improved with stable funding, new things like PAM and Plasma 5 were added, and we are headed for a glorious Slackware 15 release, and the next development cycle will not be affected by thieves taking 85% of the proceeds.
I think that your remark does not do justice to the concerns voiced in this thread.
What is so bad about asking for a new stable release BEFORE the previous one gets so stale that it is unfit or even unsafe to use as a multi-user system?
I wasn't criticising those who are just asking, even if they're voicing their demands every single day. I was criticising those who think their opinion matters more than the opinion of those who aren't clamouring for a new release, just because the latter are mostly silent.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
