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.
This thread's topic is "requests for -current". It is very unlikely that upx be integrated as suggested in post #1076 to Slackware 14.2, thus maybe if would be preferable to discuss about it in another thread.
Last edited by Didier Spaier; 05-26-2016 at 04:13 PM.
Sorry Pat, but what I said, unless somehow it went left-field in description, was to use upx prior to the packaging phase in a Slackbuild to compress and reduce the size of all binary executables in a package.
The binaries would be useable while compressed as they would have in place decompression and virtually no memory overhead during execution. Binaries compressed would be a fraction of their size, example: A 2.5MB binary would effectively be 500-600KB compressed. On a single file it looks negligible, but against several dozen, or hundreds of binaries, you could reduce the size of a package, or a set of packages by (rough estimate) 45~66% maybe less or more.
Don't get me wrong, but why are you guys even talking about run-time (de)compression here? I know computers are now fast enough to not seem affected by these (very fast) decompressors but still.. the errors that sometime appear, the extra layer of complexity, the virus-warnings... and how about 'ldd' and 'readelf' commands (which are sometimes usefull if one decides to go on his own and uninstall some packages)... and all for what? For a few hundred MBs or maybe one GB?
P.S. And all this coming from a guy that has a stroke when hears about PAM... Pff....
People always suggest stuff to add to Slackware, but rarely does anyone talk about saving space, reducing sizes, etc. Figured making a suggestion to do something beneficial would be nice, but apparently trying to think outside the box doesn't go over well.
I figured it might be nice to suggest something to research helping the distribution in a different sense. Maybe I figured saving Patrick some bandwidth on his networks might be a decent idea. Might not be much, but at least it's an idea.
Sorry Pat, but what I said, unless somehow it went left-field in description, was to use upx prior to the packaging phase in a Slackbuild to compress and reduce the size of all binary executables in a package.
We will never do this, and I'd be surprised to hear of any other distribution thinking it's a good idea unless they were targeting an embedded platform. Even then squashfs would probably be a better solution.
Quote:
The binaries would be useable while compressed as they would have in place decompression and virtually no memory overhead during execution. Binaries compressed would be a fraction of their size, example: A 2.5MB binary would effectively be 500-600KB compressed. On a single file it looks negligible, but against several dozen, or hundreds of binaries, you could reduce the size of a package, or a set of packages by (rough estimate) 45~66% maybe less or more.
It's good that they include information on the UPX webpage about how efficient the decompression is on a Pentium 133, since that's the kind of hardware you'd need to have to care about this sort of thing.
No conversation about netatalk? There is so much change/updates in this version of slackware.... why not run a reasonably recent netatalk as well?
If it would help I'll write out all of the rc.d bit and polish up a build script. I'm going to do that anyway and replace the dated default package so it's no big deal....
For the latest ghostcript build, you have removed openjpeg also, after a diff compare with the official 2.1.0 source, it has some extra fixed for use in GS. Please see the diff in attached openjpeg.txt file. That maybe the reason it is not removed in Linux from scratch. The code in GS is not a full openjpeg source, only the "openjp2" part.
Also, in the script to remove unwanted library directories, there is no png directory, only libpng.
For the latest ghostcript build, you have removed openjpeg also, after a diff compare with the official 2.1.0 source, it has some extra fixed for use in GS. Please see the diff in attached openjpeg.txt file. That maybe the reason it is not removed in Linux from scratch. The code in GS is not a full openjpeg source, only the "openjp2" part.
Thanks, I'd noticed that Fedora removed the openjpeg directory in their .spec file, but upstream says it's not supported so I'll revert to using the bundled version. I have no test cases here to show problems with using the system library, but better to play it safe.
Quote:
Also, in the script to remove unwanted library directories, there is no png directory, only libpng.
No conversation about netatalk? There is so much change/updates in this version of slackware.... why not run a reasonably recent netatalk as well?
Should have been mentioned months ago.
At some point there was a blocker against upgrading netatalk further (needed PAM, maybe?). I'm not sure if that's still the case, but it's probably too late to mess with it now, sorry.
I really hope Pat does something with Network manager. It will not do a simple dhcpcd . Before everyone jumps on this and says I do not understand it.
Network manager has three things to do
1 bring the device up
2 make a hand shake
3 use crypto or not.
Other wise it prety much useless.
If it works for you on a fresh install I am on mars then.
Me and Bob sucking down some some cosmic babes.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
