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.
Except that I said that I have 5 computers running different 3rd party packages (for Slackware) which is what I need updated.
As mentioned above, slackpkg with the slackpkg+ extensions is more than capable of handling this.
Quote:
Originally Posted by Skaendo
Yea, but I don't need portability. I have other packages that have some of the same dependencies as other packages so it makes no sense to install a bundled build of any given package.
But what happens when they require different versions of the same library? IMO, static linking makes more sense these days for exactly that reason. Dynamic linking was all but required back when we were all on dial-up internet and every byte counted... not so much now that hard drive space is all but unlimited and we have gigabit internet connections.
And something like a statically linked ffmpeg can save you days/weeks of collating & compiling dependencies.
Quote:
Originally Posted by Skaendo
If I wanted that I might as well install windows.
There's more luggage that comes with Windows which makes this an invalid proposition.
@Skaendo posted about click, click. We all time to time wish there will be click, click and job done. But experience tells that after twenties or more clicks - it stops to work. At the bottom is lest someone else do this for me. I prefer to deal with what does not work on Slackware than why do clicks not work?
But what happens when they require different versions of the same library? IMO, static linking makes more sense these days for exactly that reason. Dynamic linking was all but required back when we were all on dial-up internet and every byte counted... not so much now that hard drive space is all but unlimited and we have gigabit internet connections.
Surely the main argument in favour of dynamic linking is not the time taken to download software but the impossibility of tracking and updating all the packages that use a particular library whenever that library gets an upgrade. With dynamic linking, you don't have to; you just upgrade the library itself and everything else follows.
As much as I love Slackware (7+ year user), I also am debating leaving. The current climate around here has been pushing me over the edge
People are just bored waiting for the next release. There's not much to complain about with either stable or current, since they rarely break.
Put lots of people in a queue and make them wait a little too long and fights will inevitably break out. I think the general tone of the forum will change once there's a release.
Surely the main argument in favour of dynamic linking is not the time taken to download software but the impossibility of tracking and updating all the packages that use a particular library whenever that library gets an upgrade. With dynamic linking, you don't have to; you just upgrade the library itself and everything else follows.
With a static binary, you can upgrade the library underneath it, or even remove the library altogether. The main argument against static binaries is their size.
For a period of 6 or 7 years, I was the "official" Slackware package maintainer for ScummVM. I haven't done it for several releases now, for various reasons (which I feel bad about)... but anyhow, to ensure that my packages were backward (& forward!) compatible, I'd use static linking. With the earlier versions, the difference in size was only 10-15%... But by the last one, it was quite significant in size. They still make my last packages available for download on their website (https://www.scummvm.org scroll down to "Older versions" on the download page). There's a 32 bit and 64 bit version. I no longer have access to any 32 bit hardware, so can't test the i486 package. The 64 bit version works like a charm on -current! The date stamp on the file says 2013. And I can't remember which version of Slackware I used to compile it... but I'm gonna say it was either 13.37 or 14.0. That would not be possible with dynamic linking. There'd have to be a package for each version of Slackware, and it wouldn't run on custom setups.
I fully appreciate Mr Volkerding for Slackware and maintaining for so long as it is still IMO the best distro around, and hope that both are around for a long time to come but I think that our adventure is about to come to an end.
You don't have to post. I still run Slackware on a couple of older machines but I hardly post here now, there's just no reason for me to. Most people who run Slackware don't post here.
If it's stressing you out, take a break. Most people only come here out of habit anyway. You can tell that from the amount of arguments there are over nothing. People are bored during the day, they have some time on their hands, so they log in here out of routine looking for some iota of a discrepancy that they can pull someone up on. As Gerard said, people have grown weary. It would have been better if 15.0 were released a couple of years ago. A lot of regulars have moved on and many other posters here - even quality ones - are now just biting each other in the backsides. Hopefully that will change when 15.0 is released: then there should be a lot of posts from newer users which will give the community a greater sense of purpose and cohesion.
I certainly hope so anyway, because this forum is quite an unpleasant place at the moment.
Last edited by Lysander666; 05-28-2021 at 07:19 AM.
I certainly hope so anyway, because this forum is quite an unpleasant place at the moment.
I agree that we are getting a lot of troll posts here depicting the demise of Slackware, a targeted campaign. I try not to let that get me down because then the bastards win. I will not give in to the negativity.
It's good to see you here, mate!
LQ is and continues to be my go to Linux forum. This is where I arrived as a fledgling in 2004 and received kind help from senior Slackers.
mods, please close this thread. I know, I know, it's like playing Whac-A-Mole. I am wondering why people who take the time to feed such threads don't use this time instead to do something useful for their fellow slackers like writing documentation and/or SlackBuilds, reporting bugs, answering help requests...
With a static binary, you can upgrade the library underneath it, or even remove the library altogether. The main argument against static binaries is their size.
For a period of 6 or 7 years, I was the "official" Slackware package maintainer for ScummVM. I haven't done it for several releases now, for various reasons (which I feel bad about)... but anyhow, to ensure that my packages were backward (& forward!) compatible, I'd use static linking. With the earlier versions, the difference in size was only 10-15%... But by the last one, it was quite significant in size. They still make my last packages available for download on their website (https://www.scummvm.org scroll down to "Older versions" on the download page). There's a 32 bit and 64 bit version. I no longer have access to any 32 bit hardware, so can't test the i486 package. The 64 bit version works like a charm on -current! The date stamp on the file says 2013. And I can't remember which version of Slackware I used to compile it... but I'm gonna say it was either 13.37 or 14.0. That would not be possible with dynamic linking. There'd have to be a package for each version of Slackware, and it wouldn't run on custom setups.
Static vs dynamic isn't just for size. There's benefits with both sides. The obvious benefit with static linking is simplicity for a single package. It is really nice for someone to be able to grab Eric's ffmpeg or VLC without the mountain of dependencies to go along with it. I'm not sure if there are any other benefits. It is vastly more complex to prepare that package than a dynamically linked one.
With dynamic, the obvious benefit is the size. However, there are other benefits as well. With static linking, you lose the ability to track what versions of libraries are being used in your programs. If one of the libraries used in a statically linked package has a security issue, how easy is it for you to notice that? Especially if you weren't the one who prepared the package. Hopefully the person who did prepare the package is paying attention and provides an updated package and hopefully you notice that and upgrade the package.
NOTE: this isn't to argue that we should only use/provide dynamically linked packages. I appreciate Eric's statically linked packages (even if I don't use them as I prefer to compile my own packages) and they are a massive benefit to the community. But I think the only benefit with statically linked packages are the simplicity for the end user to not have to track down a ton of dependencies, however, I'd be happy to be corrected with additional benefits of statically linked packages.
I am wondering why people who take the time to feed such threads don't use this time instead to do something useful for their fellow slackers like writing documentation and/or SlackBuilds, reporting bugs, answering help requests...
We do useful thing. We post to make impression Slackware is still alive. This thread has 11 thousands of views - largest funeral ever.
This thread has 11 thousands of views - largest funeral ever.
Nope, Princess Di's funeral had an estimated 2.5 billion people watch worldwide. I'm too lazy to see if hers was even the largest.
Quote:
Two thousand people attended the ceremony in Westminster Abbey while the British television audience peaked at 32.10 million, one of the United Kingdom's highest viewing figures ever. An estimated 2.5 billion people watched the event worldwide, making it one of the biggest televised events in history.
We do useful thing. We post to make impression Slackware is still alive. This thread has 11 thousands of views - largest funeral ever.
So that's as many times people have been bored reading rants they're not interested in. If the goal is to have as many views as possible, Twitter, Facebook, Youtube or similar are more appropriate, I think. With the added benefit for me that I won't come across it on media I don't visit.
Last edited by Didier Spaier; 05-28-2021 at 02:53 PM.
Static vs dynamic isn't just for size. There's benefits with both sides.
Absolutely. 100%.
Quote:
Originally Posted by bassmadrigal
NOTE: this isn't to argue that we should only use/provide dynamically linked packages.
Agree with this too. I think any highly practical and useful system will have a good mix of both. Dynamic linking makes a lot of sense for the base system and the parts that come with it. For 3rd party binaries, you might get issues where that 3rd party has a library on their system that isn't part of the default installation. Eric's ffmpeg or VLC packages are perfect examples of this.
Quote:
Originally Posted by bassmadrigal
But I think the only benefit with statically linked packages are the simplicity for the end user to not have to track down a ton of dependencies, however, I'd be happy to be corrected with additional benefits of statically linked packages.
Well, as above, it also makes the binaries portable across versions and distributions. My scummvm binary from 2013 still runs on a system which is quite far removed from the one it was compiled on.
In some cases, static linking can blow up in your face when it has to interact with other components on the system, that are using a different API. Let's say Cairo for example (using this one because I have personally run into it in the past). You build an application with bundled cairo, statically. That application has to interface with your GTK+. That's all fine and dandy when your static cairo uses the same API as system, but when system cairo changes and gtk+ has been recompiled for it... boom, your application is using the wrong cairo API.
For another example, it would also be very fragile to statically link glibc (which is why it's not usually done except for some low level system utilities that may need to work before a filesystem is available for example)... when interfaces change, an application could be broken. If it just linked to libc.so.6 and friends, those functions in the (backwards compatible) shared library use the correct interfaces.
But I disagree with "static linking bad... always". There are some things where I want the static libraries along with the shared and there are some things that I prefer to be static. Often applications that use ffmpeg can build it statically, for example.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.