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.
Wed Apr 25 04:38:51 UTC 2018
[...]
d/parallel-20180422-noarch-1.txz: Added.
Parallel - build and execute shell command lines from standard input in parallel. Uh, oh...
BUT, for a shell scripting feature (somehow similar with xargs), its location in D series is a bit strange. I imagined that its place is in AP series, eventually...
Last edited by Darth Vader; 05-18-2018 at 03:00 AM.
But upgrading your databases is nontrivial. So maybe it's better to have postgresql upgrades decoupled from Slackware upgrades.
It's just like anything else, minor version upgrades for security stuff is dead simple, restart the daemon. For other stuff, it requires an import/export, but it's only 3 commands...
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"
There is no tragedy, postgres works every well and is easy to maintain. Easier in my opinion that mysql because mysql requires the user to know a little bit about the numerous different table types and has a lot of inconsistency issues, and in some cases plainly lacking real database features such as a timestamp with a time zone.
I'd WAY rather understand how to import and export every other year for a major release then hack time zone support into my app because the database won't do it.
Anyway, the SBo postgres package works fine, the only con is that it requires me to rebuild php to get the module. If postgres was in EXTRA, and the pgsql.so and pdo_pgsql.so modules were included in php (but disabled in php.ini), that would make my life WAY easier as I would just install postgres from EXTRA, uncomment two lines in php.ini and presto chango, php works. For those that don't want postgres, they don't install from EXTRA and it's just like it's always been.
My point is that a non intrusive change here makes slackware much nicer for those of us that want a real database.
There is no tragedy, postgres works every well and is easy to maintain. Easier in my opinion that mysql because mysql requires the user to know a little bit about the numerous different table types and has a lot of inconsistency issues, and in some cases plainly lacking real database features such as a timestamp with a time zone.
I'd WAY rather understand how to import and export every other year for a major release then hack time zone support into my app because the database won't do it.
Anyway, the SBo postgres package works fine, the only con is that it requires me to rebuild php to get the module. If postgres was in EXTRA, and the pgsql.so and pdo_pgsql.so modules were included in php (but disabled in php.ini), that would make my life WAY easier as I would just install postgres from EXTRA, uncomment two lines in php.ini and presto chango, php works. For those that don't want postgres, they don't install from EXTRA and it's just like it's always been.
My point is that a non intrusive change here makes slackware much nicer for those of us that want a real database.
IF the PostgreSQL is added to Slackware, as you pointed out, the PHP will build support for it.
BUT also the same will do Qt4 (or future Qt5) and probably other applications and libraries.
Then, I believe its place will not be in /extra, but in the main tree, maybe in N series.
And that's OK, because like you highlighted, PostgreSQL is a fine database server, with annual major releases and multi-annual maintenance and security support.
I for one, as one of those who uses PostgreSQL since Ice Age, I believe that it will be a fine addition to Slackware, and a non-invasive one.
I really hope that our BDFL will not be convinced for contrary by some who get mental scars from the usage of PostgreSQL.
Last edited by Darth Vader; 05-18-2018 at 12:03 PM.
Parallel - build and execute shell command lines from standard input in parallel. Uh, oh...
BUT, for a shell scripting feature (somehow similar with xargs), its location in D series is a bit strange. I imagined that its place is in AP series, eventually...
It's written in Perl. Also, it's strange to keep fixating on which series a package belongs in, as if it's a dependency system or something.
nginx and postgresql are doing just fine on SBo. I don't see what adding them to Slackware core would bring to the table, aside from shifting the maintenance burden from people who know them well and use them regularly, to people who have a thousand other packages to look at.
As for php and qt, both of those have scripts up on SBo as well for postgresql support:
- php-pgsql
- libqsqlpsql
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.
GNU parallel is quite a bit more advanced than xargs (but I'm sure you know that if you've gone over the tutorial ;-)
If all your script requires is a parallel xargs, check out the xargs -P option. It's already able to do simple parallelization. In fact, even the busybox version supports this.
# Remove man pages for the servers (not currently supported or shipped...
# do they even work properly without the evil PAM?)
find $PKG/usr/man -name slap* -exec rm -f {} \;
find $PKG/usr/man -type d -empty -exec rmdir {} \;
Even after the recent changes to pkgtools, enabling multi-threading where possible, creating txz packages with /sbin/makepkg still only uses one core here, I guess because of the compression preset level used.
[...]
Maybe if $XZ_THREADS_FORCED is set to 'yes' makepkg should drop the -9 from $COMPRESSOR for txz?
Perhaps I'll look at making the compression level a user-serviceable part. But I thought I should weigh in again here... the test you're running using random data doesn't really give real-world results since most compressors do a lousy job compressing random bytes. So here are three tests on my own machine using the Linux kernel source as the testfile:
Code:
bash-4.4$ time cat /tmp/linux-4.14.41.tar | xz -9 --threads=6 -c > /tmp/testfile.1.xz
real 2m23.472s
user 8m27.252s
sys 0m3.310s
bash-4.4$ time cat /tmp/linux-4.14.41.tar | xz --threads=6 -c > /tmp/testfile.2.xz
real 1m13.695s
user 6m42.475s
sys 0m1.356s
bash-4.4$ time cat /tmp/linux-4.14.41.tar | lbzip2 -9 -c > /tmp/testfile.3.bz2
real 0m10.049s
user 0m57.865s
sys 0m0.926s
bash-4.4$ ls -lh testfile.?.*
-rw-r--r-- 1 volkerdi users 96M May 18 13:10 testfile.1.xz
-rw-r--r-- 1 volkerdi users 101M May 18 13:12 testfile.2.xz
-rw-r--r-- 1 volkerdi users 116M May 18 13:13 testfile.3.bz2
As you can see, xz is still fairly slow even when the -9 is dropped, but look at the results using lbzip2 (bzip2 compression)!
The moral of the story is that if you're concerned about makepkg compression time, forget about building a .txz package - have it build .tbz instead. It will produce a larger package than xz will, but for packages intended for local use it's still a modest increase.
nginx and postgresql are doing just fine on SBo. I don't see what adding them to Slackware core would bring to the table, aside from shifting the maintenance burden from people who know them well and use them regularly, to people who have a thousand other packages to look at.
As for php and qt, both of those have scripts up on SBo as well for postgresql support:
- php-pgsql
- libqsqlpsql
Fair enough.
I figured I would mention it since sendmail was removed. If we are going to force the sendmail/imapd users to migrate to postfix/docecot (or remove postfix and SBo sendmail) all in the name of it's a better mail system, then why not get a modern/feature-full database server in there while we are at it?
At least postfix supports milter, so it can mostly do what sendmail does....
There's a lot of very good software out there, and Postgres is one of them but we can't include it all in the distro and I think we need to be wary of Everything-but-the-kitchensinkism when requesting things to be added to the distro.
Postgres is the sort of thing that I prefer to install to /opt independently of the distro, but that's just me.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
