Perhaps it is time to turn Slackware to rolling release distribution
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.
@GazL I can't prove it at the moment but I think you wrong. This is just very expensive approach to rebuild everything due to small changes. It just doesn't make sense.
Yes, it's annoying, but if a change in the library results in a ABI change then running an old executable against the newer library is going to be very dodgy. This is the reason we have SONAMEs in the first place, and why they are bumped.
That said, libraries that use "Symbol versioning" don't have this problem, but then they don't tend to bump SONAMEs either. However, backward compatibility through "Symbol versioning" isn't free, it takes extra effort from the developers and not all projects can be bothered to do it.
I attach the output of "pkg upgrade" typed today. This is not a distribution upgrade, just a periodic upgrade of the packages included in GhostBSD, based on FreeBSD Stable. Food for thought?
I attach the output of "pkg upgrade" typed today. This is not a distribution upgrade, just a periodic upgrade of the packages included in GhostBSD, based on FreeBSD Stable. Food for thought?
From GhostBSD web page
Code:
GhostBSD 21.09.29 ISO Now Available 09/30/2021 - 22:09
GhostBSD 21.11.24 ISO is now available 11/26/2021 - 13:56
this remind me Alien Bob slaklive based on current (or 15.0 RC?)
You can already enjoy an "almost" rolling release, I think slackware is more similar to debian stable/sid cycle, where things settle down a bit in -current before the release, and then it starts rolling again. And lot of people will tell you that debian sid is rolling, even if it isn't really.
If you take a look at the changelog, since last week it's almost always bufixes and slackbuild tweaks to make it as stable as possible. Even python 3.10 was reverted for stability reasons, unlike in fedora 35 where you see people complaining daily about the poor experience with 3rd party builds.
I also think you and others should understand that the creator of slackware went through some hard times this release cycle, that alone is something that in my experience changes a lot about your sense of time and duties, not in a bad way it's just a shift of priorities.
Add to this that big decisions on the future of the distribution were made, the addition of PAM and Plasma5 being the most prominent, plasma was seriously risking missing the new release, if not from the work of Alienbob and the rest of the community. Plasma missing would have been really really bad for the appealing of the distro, in the year 2021.
The ideal stable cycle should be between 2 and 3 years before a new release, this one has taken twice as much but that's totally okay in my opinion for the given reasons.
And if you look at the other players, debian, arch, fedora, they have hundreds of people behind testing stuff almost fulltime, and while some of them might experience a moment of down in life, there's plenty of people to cover the work share. And still you see abandoned packages, old sources, stuff neglected, even big dependency hell fiascos like the recent linus tech tips debacle.
Here you have one man in minnesota, a dozen of main developers scattered around the globe and a little forum community, keeping up with upstream more than arch, pondering new additions without embracing it blindly like fedora, and finally putting out a stable release hard as a rock.
Be patient a little more, it's a work of art among other things
.
I echo the sentiment whole-heartedly. To add to this, there are equally rewarding things in life where personal efforts are more compounding on each other. A good system with good personal pursuits compound each other effects & enrich lives even more. Doing things is the real step up from tinkering with tools although tinkering is part of doing things as well. The more stable your tools are, the more enriched your pursuits will be.
From the design perspective, Don Norman once said in one of his books that good designs are hidden in plain sight so much so that one takes it for granted for doing things. Bad design makes you aware of its presence.
Last edited by medictruck; 11-27-2021 at 11:02 PM.
Reason: Grammar & clarity.
GhostBSD 21.09.29 ISO Now Available 09/30/2021 - 22:09
GhostBSD 21.11.24 ISO is now available 11/26/2021 - 13:56
this remind me Alien Bob slaklive based on current (or 15.0 RC?)
Most amusing. For at least the last few releases of GhostBSD it has resisted all my efforts to get it to boot up on my Elitepad. Alien Bob's slacklive boots well and runs flawlessly for me on the same computer. Go figure!
Most amusing. For at least the last few releases of GhostBSD it has resisted all my efforts to get it to boot up on my Elitepad. Alien Bob's slacklive boots well and runs flawlessly for me on the same computer. Go figure!
This could be because some of its hardware is not supported by your version of FreeBSD. It is well known that FreeBSD is not in par with Linux in this regard. FreeBSD recommends to check your hardware compatibility and they do provide a comprehensive hardware compatibility list associated to each release, like this one.
Anyway I do not request that Slackware use a release model similar to that of FreeBSD, as I fully realize that handle it by a single individual is just not possible, as skilled and productive as they be. I would say the same for the Debian model. I am just fond of systems engineering and found the pkg system of FreeBSD awesome. Again, I won't request that Slackware adopt it for the same reasons as the release model. Still I would prefer to continue using Slackware as a basis for Slint because it fits the needs of most of our users.
Last edited by Didier Spaier; 11-28-2021 at 03:47 AM.
Speaking of rolling releases. Anyone know how CENTOS STREAM is working out for RedHat? Are people actually using it, or was Redhat's ham-fisted curtailing of CENTOS8's EOL date a fatal blow for the brand.
edit: Ok, I just googled, and it seems that CENTOS STREAM has a version number (8) and an EOL (2024), so that doesn't sound like a true 'rolling' distro anyway.
Rolling-release was about the only thing I thought it had going for it, and by the looks of it that was just a mischaracterisation of the model by the tech journos.
Speaking of rolling releases. Anyone know how CENTOS STREAM is working out for RedHat? Are people actually using it, or was Redhat's ham-fisted curtailing of CENTOS8's EOL date a fatal blow for the brand.
CentOS Stream needs to find new user base. Or perish.
After six months Texworks stopped to work due to new library version. Instead of rebuild I created link *.8.so -> *.9.1.so.
Instead of linking to a different version, you can copy back the old library version. Only the shared library so file, not headers. It can coexist with the new one because the file names are different. This is how PV includes some old versions in aaa_libraries and Eric in poppler-compat and boost-compat.
When I do that, I move the old versions in /usr/local/lib64 which is otherwise empty, so I can remove them easily when not needed any longer. In /usr/lib64 they would probably be forgotten forever.
Instead of linking to a different version, you can copy back the old library version. Only the shared library so file, not headers. It can coexist with the new one because the file names are different.
Sure you right. But nonetheless it is good to rethink why this works.
Say if I can build the same Texworks version against two different library versions - seems API didn't change. There is this ABI thing - which is complete mystery for me - and how loader works.
Point is I didn't rebuild Texworks but only created fake links so new version is used yet all needed objects coming from new library are successfully loaded.
I am just trying to understand why this works. There is something behind the scene. System depending on hundreds of libraries can't be rebuild because of update/upgrade couple of libraries. Which from other hand may be necessary. Perhaps today can be. But shared libraries are ancient times. When to rebuild everything was extremely expensive. Imagine shutting down mainframe to rebuild and tests. Just not possible.
Point is I didn't rebuild Texworks but only created fake links so new version is used yet all needed objects coming from new library are successfully loaded.
Successfully loaded, not successfully used.
Ok, demo time....
$ ls -l
total 72
drwxr-xr-x 2 gary gary 4096 Nov 28 12:43 libGazL-1.0
drwxr-xr-x 2 gary gary 4096 Nov 28 13:05 libGazL-2.0
-rwxr-xr-x 1 gary gary 20216 Nov 28 13:00 demo
-rw-r--r-- 1 gary gary 64 Nov 28 12:55 demo.c
lrwxrwxrwx 1 gary gary 12 Nov 28 13:08 libGazL.so -> libGazL.so.2
lrwxrwxrwx 1 gary gary 16 Nov 28 12:57 libGazL.so.1 -> libGazL.so.1.0.0
-rwxr-xr-x 1 gary gary 16528 Nov 28 12:57 libGazL.so.1.0.0
lrwxrwxrwx 1 gary gary 16 Nov 28 13:06 libGazL.so.2 -> libGazL.so.2.0.0
-rwxr-xr-x 1 gary gary 16528 Nov 28 13:06 libGazL.so.2.0.0
demo will still work, because libGazL.so.1 still exists, but it won't compile anymore because libGazL.so now points to libGazL.so.2 with the new version of show() that expects a msg parameter.
But looks what happens if we get rid of so.1 and symlink it.
Code:
$ rename libGazL.so.1 libGazl.old libGazL.so.1*
$ ./demo
./demo: error while loading shared libraries: libGazL.so.1: cannot open shared object file: No such file or directory
$ ln -sf libGazL.so.2 libGazL.so.1
$ ./demo
���� 5
$
The message text is corrupted. Now, not that big a deal in this example, but that message text could have been a pointer to something far more significant whose corruption can have unpredictable and possibly disastrous effects.
This is why symlinking between different sonames is a bad idea.
I don't think it is good example. For me only interested thing is what is passed as second argument. For me there should segfult here. What part of memory is accessed when function is collecting the second argument? I mean the first argument is put in memory, address is passed, but the second is pointer pointing to what? This why I think there should be segfault.
Edit: Did you verify exit code? Your example is worrisome. It says one can possibly run application with broken API. You don't need much more to create virus. One can't build it but run by ldd call. I guess I just won million dollars prize. How to hack Linux.
Edit: there is application with broken API, instead of system error there is side effect. In your example is completely harmless. But one can imagine totally disastrous side effect. So the question is why this work?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
