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.
There's not much point to that (yet), since xz won't do multithreaded decompression anyway. Better to keep the packages as small as possible.
It does multithreaded compression, which speeds up (sometimes significantly) building packages - I was talking about makepkg, not installpkg/updatepkg.
The argument for size is fair. I ran a quick, very non-scientific, experiment (on a desktop i7-2600 CPU, so nothing fancy), using dataset consisting of all *.txz found in slackware64-current/ and measured:
Code:
# time needed to decompress all of them (with xz -d -c $txz > $tar)
real 3m35.757s
user 2m59.463s
sys 0m11.564s
# time needed to compress all *.tar using xz -T 8 -c $tar > $txz (if not specified, default compression level is -6)
real 35m9.892s
user 77m41.284s
sys 0m51.763s
# time needed to compress all *.tar using xz -9 -T 8 -c $tar > $txz
real 56m9.063s
user 69m7.453s
sys 1m29.274s
# time needed to decompress all *.txz which were compressed with default compression level:
real 4m6.563s
user 3m11.040s
sys 0m10.759s
# time needed to decompress all *.txz which were compressed with -9:
real 3m52.308s
user 3m0.414s
sys 0m12.272s
# space used by *.txz:
2761140 slackware64-current-original (as shipped in slackware)
2754864 slackware64-current-optimize-size (-9 -T 8)
2941344 slackware64-current-optimize-time (-T 8)
I think the difference in resulting size isn't that big (2.7GB vs 2.9GB) in light of the compression time win, but I do understand that most users download and decompress packages rather than creating (compressing) them. There are still folks who package 3rd-party software, and I think it would be useful for them to be able to choose compression options without too much hassle.
Having options in makepkg to choose -threads is ok, but it requires editing SlackBuilds to make use of it. It would be great to have the default tunable via env variable, which still can be overriden by command line option later on:
Code:
@@ -105,7 +105,9 @@
# Set maximum number of threads to use. By default, this will be the number
# of CPU threads:
-THREADS="$(nproc)"
+if [ -z "$THREADS" ]; then
+ THREADS="$(nproc)"
+fi
# Parse options
unset ACLS XATTRS
And then something similar to replace hardcoded "-9" with a user-defined level.
I think a lot of Slackware users would be unhappy to have avahi imposed upon them (though I have considered it).
But doesn't netatalk-3 also have a hard dep on PAM?
No, and if you have pam installed anyway and really want it omitted netatalk 3.1.11 allows you to pass "--without-pam" to ./configure.
As for avahi, I'm not sure that it's imposed any more than anything else, you don't have to install it if you don't want it. Seems like slackware is re-evaluating what packages to include (like dropping sendmail/imapd for postfix/dovecot), and lots of stuff is starting to use it (like samba) so it might be worth it.
Also, while we are talking about imposed, and ditching the old, and in with the new, I'd love to see postgres. With native partitioning support, fantastic procedural language, no licensing problems, and a configuration that's just as simple, I'd say it's an even more welcome change than postfix. Maybe put it in extra....
But upgrading your databases is nontrivial. So maybe it's better to have postgresql upgrades decoupled from Slackware upgrades.
You talk about migration from MySQL to PostgreSQL? There is no need for, and the PostgreSQL server would work well along with MySQL.
In other hand, if you talk about the difficult to upgrade PostgreSQL databases, from when we care about offering to users some "stupid" paths of upgrading?
IF someone starts to use PostgreSQL, he should learn to use it properly, plain and simple.
So, this argument is moot, in my humble opinion.
And yes, I would love to see PostgreSQL into Slackware. It is a very nice database server.
Last edited by Darth Vader; 05-17-2018 at 08:32 PM.
If you knew anything about postgresql, you would know about pg_upgrade.
Like I said, I do not consider an argument like "the difficult to upgrade the PostgreSQL databases" as good enough to limit the Slackware users choices by default.
IF an user will consider that these upgrades are too much for him, he can just use MariaDB instead, plain and simple.
Last edited by Darth Vader; 05-17-2018 at 08:27 PM.
Postgresql is still actively supporting version 9.6 which is scheduled for EoL in September 2021 ( but the developers do make a 'best effort' to fix critical bugs after EoL ).
Because of the potential pain of changing our postgresql Major Version, I've created a clone of the new SBo Version 10 postgresql.SlackBuild as postgresql-9.SlackBuild
We've decided to keep running pg 9.6 until we come up with a Migration and Testing Plan for the DataBases and for a few of our Programs linked to /usr/lib{,64}/postgresql/9.?/lib/
Unless maybe Pat and the Team would stick with a postgresql Major Version for the life of a Slackware Release ...
But then again, postgresql 10 is scheduled for EoL in October 2022 which will be before the useful EoL of Slackware 15.0.
Unless maybe Pat and the Team would stick with a postgresql Major Version for the life of a Slackware Release ...
Still I fail to notice where's the tragedy from the Slackware POV, considering that the PostgreSQL developers offer at least several years of support for a Major Release...
Also, it is not supposed you guys to use stable releases in production and Slackware to stick on the software's Major Releases for lifetime of a release?
Last I checked, our BDFL still does not pushed in the Slackware 14.2 "patches" the Plasma5, for example.
So, excuse me, but I cannot treat this story in other way than "yet another scary story ventilated in this forum"
Last edited by Darth Vader; 05-17-2018 at 10:06 PM.
I discovered GNU Parallel these days and IMHO it would be a great addition to a distro like Slackware which probably has quite a few console users. It's like "xargs" but executes the commands in parallel, using all those cores modern CPUs have.
I discovered GNU Parallel these days and IMHO it would be a great addition to a distro like Slackware which probably has quite a few console users. It's like "xargs" but executes the commands in parallel, using all those cores modern CPUs have.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
