By the way, today I opened a new position in one of my IT teams in Veldhoven, The Netherlands (ASML’s HQ):
I am looking for a Senior MATLAB Support Engineer to help support the roughly 8000 MATLAB and SimuLink users in our Research, Development & Engineering departments.
I assume that many of you will have been reading the recent Linux Questions thread “Donating to Slackware” and in particular Patrick Volkerding’s reply where he explains that the Slackware Store (an entity independent of Slackware with which he has a business arrangement involving a percentage of sales profit and medical insurance) has not been paying him any money for the last two years and that most likely all the PayPal donations through the Store have gone into the pockets of the Store owners. Read that thread if you have not done so yet.
Basically Pat is broke. That thread lists a PayPal address which Pat eventually shared and where donations can be sent directly to him, so that he can fix his roof, his airco, his crashing server and his wife’s car. That would be a start.
That LQ thread is also perused to discuss possible ways forward for Pat (setting up a Patreon account, or a business PayPal account, etc) so that he can support his family and continue working on Slackware. To me it looks like the Store will be a thing of the past unless they change their attitude. Switching from a business model where revenue is generated from optical media sales, to a model where supporters set up a recurring payment in exchange for the prolonged existence of their favorite distro, and possibly get Pat to write up some hands-on stories as a reward, may ultimately benefit Pat, and Slackware, more than the way things are handled at the moment. If you are doubting the financial impact of a recurring payment through Patreon or PayPal, look at it this way: if you donate one euro per month, you will probably not even notice that the money is shifted out. But with 2000 people donating one euro per month, Pat would have a basic income (pre-tax) already. Not a lot, but it’s a start. The 2000 people is a rough estimate of the people who ordered a DVD or CD through the store: the owners told Pat that the earnings of the 14.2 release were 100K (and Pat got 15K out of that, go figure!). Divide that through ~50 euro per DVD, results in 2000 people. Then there’s all these people who donated money through the Store or bought shirts, caps and stickers. I think the amounts of money even a small community (like us Slackware users) can contribute should enable Pat to shed his financial worries. The fact that the Slackware Store basically has been ripping off the hand that feeds them is enraging and inexcusable.
This is all about a community standing up to provide support for what (or who) bonds us together.
Very important to take from Pat’s reply is that he’s “never really been in this for the money” but without income, Slackware’s development is ultimately affected too. I hesitated writing this article, even after Patrick’s LQ post, because it is Patrick’s life and I won’t decide for him how to live it. But I am passionate about Slackware, and care a great deal for Pat, Andrea and Briah, and wish them nothing but the best.
So, in that LQ thread and in private talks, I guess that there will be a lot of discussions as well about the shape and form of a future Slackware. Should it shrink to a “core distro” on which others can build their repositories, for instance offering Plasma5, MATE, Cinnamon desktop environments? How to integrate these external repositories so that a new install could effortlessly be expanded with extra functionality? Should Plasma5 be included? Should PAM be included? And so forth. Lots of exciting developments in stock!
As for KDE Plasma5, I talked with Pat about the way forward and what his plans are with regard to Slackware and Plasma5. Pat indicated that he would at this moment be in favor of going with the latest and greatest instead of adopting LTS (Long Term Support) releases of KDE, because of the reports from several Slackware Plasma5 users that several usability bugs have been solved in the latest releases (part of those improvements can be attributed to the newer Qt5). If Pat decides not to adopt Plasma5 into Slackware, then as long as he provides a solid base in Slackware 15.0 I can keep providing Plasma5 as an add-on through my ‘ktown’ repository. That “solid base” would at least have to be Qt5, its supporting libraries, and recompiled/upgraded phonon, poppler, harfbuzz etc packages to add Qt5 support so that I can cut my “deps” section substantially and no longer have to provide alternate versions of packages that are also part of Slackware but lack required functionality.
And that is why my next update of ‘ktown‘ will see the removal of the LTS software versions in the ‘latest‘ sub-repository and at the same time, the bleeding edge ‘testing‘ sub-repository will be promoted to the ‘latest‘. The ‘testing’ and ‘latest’ will then contain the same packages, so that everyone will upgrade to the same July ’18 packages.
I still need to start collecting the new KDE source archives, sync my virtual machines to latest -current and start compiling. Don’t expect packages before the weekend…
I acquired the slackware.nl domain. More precisely, the domain was given to me – for free – by its previous owner whose name I will not divulge unless he gives me permission to do so (someone sympathetic to Slackware but no longer using Slackware himself). Thanks!
So, I setup some server configurations using slackware.nl for stuff I am hosting under (mostly) alienbase.nl:
I have generated a new GPG key to replace my old one which was based on a 1024-bit DSA primary key. The new primary key is 4096-bit RSA. I will be transitioning away from my old one.
The old key will continue to be valid, but i prefer all future correspondence to use the new key. I would also like this new key to be re-integrated into the web of trust. The online version of this message is signed by both my keys (old and new) to certify the transition.
The above text is based on a “gpg-transition-document” template which seems to be pretty widely used on the Internet for purposes of GPG key transitioning. My own text (the one of this blog post) can also be found here: http://www.slackware.com/~alien/gpg_transition_20160821.txt . That text file has been digitally signed with my old and new keys so that you can verify the correctness of my statements.
Many of us will remember the time when a true Slacker did not bother herself with build scripts. The “configure && make && make install” mantra was at the forefront of everyone’s mind when it came to installing new software. Slackware made this possible. Unlike the other big distros, the Slackware package management did (and does!) not get in your way. If you want to compile your software by hand, bypassing the package management ‘database’ (which in Slackware is nothing more than a directory), then nothing or no one is stopping you.
But when you compile and upgrade a lot of software, or when you have to re-install your computer, all that hand-compiled stuff is quite tricky, if not pretty hard, to replicate unless you wrote down all that you did. And if you had been writing your compile and build steps down anyway, then it was a small step towards formalizing this documentation into an actual build script. And Slackware was (mostly) developed using build scripts, called “SlackBuilds” because of these scripts’ extension “.SlackBuild”. So, these scripts used by Slackware became gradually more common among users of Slackware. And once you had compiled a package using a build script, other advantages would become obvious: if you owned more than one computer you did not have to compile your software twice. You would transfer the package to your other computer(s) and use the Slackware ‘pkgtools’ to install or upgrade the package. Fast and deterministic.
In those days, there was a web site called “linuxpackages.net” – formerly known as “linuxmafia.org” but I guess that name had a negative vibe to it. Linuxpackages.net would offer binaries for Slackware, nicely packaged in case you were not inclined to compile stuff yourself. The site was pretty popular, but it had a major disadvantage: the packages did not have a proper quality control and it would happen ever so often that people’s computers broke after installing one of their packages. The ‘LP‘ packages were apparently built on unclean systems, introducing unknown dependencies, and the build scripts would often be absent. Good old NoobFarm has a lot of nice LP related quotes taken from the regular Slackware meeting places on the Net.
Also in those days, somewhere end of May, beginning of June 2006 (don’t have exact records of our first contact) there was a relative Slackware freshman called Robby Workman. He and his pal Erik Hanson (who initiated the GWare project, a Gnome build for Slackware after Slackware dropped that Desktop Environment from the distro) envisioned a web site where one would be able to find – not binaries, but SlackBuild scripts. These scripts would be quality-tested by a small team of people who carried trust in the community. High-quality scripts and skilled, trustworthy people at the helm, this would certainly gain some traction and be generally beneficial to the Slackware ecosystem. Robby and Erik contacted me because I knew Pat, some of my work had landed in Slackware releases, and my SlackBuilds repository (scripts plus packages) was already quite well-known but not well-organized (no proper ChangeLog.txt).
At that time I was not yet a part of the Slackware coreteam by the way – that would take until August of that same year. Robby and Erik asked me if I would be interested to join them and become part of the admin team of this new SlackBuilds.org (SBo) project they had in mind and I said “yes”. We talked this through with Pat and in particular, we discussed our scope. We wanted Pat to be sympathetic of our cause and we did not want to become a possible burden to him on the long run. For that reason, the golden rule was established that all SlackBuild entries at slackbuilds.org would follow the style of the “mother” scripts. Basically, a SBo script should be transferable into the Slackware core distro without feeling out of place. I think it was this rule that made Pat give the nod of approval. Just think of the scenario where the SBo site would become popular using a style of SlackBuild scripts that did not look at all like Slackware’s own. There was a good chance that people would start demanding that Slackware must adopt the scripting style of SBo. This was a big no-no.
In contrast, my own SlackBuild scripts do a whole lot more than a basic Slackware script – notably my scripts will download the source tarballs for you. You will not find any of those scripts on slackbuilds.org for the exact reason I just explained.
I dug through my email logs and the oldest record I still have is this, the first test email of the then already functional project:
Coïncidentally this day (8 June 2006) also marks the start of formalizing my own SlackBuilds repository. I had been working on my gen_repos_files.sh script since April 2006 and used it for the first time on June 8th. The first entry in the ChangeLog.txt says:
Thu Jun 8 15:10:57 UTC 2006
Starting the ChangeLog.txt for Alien's SlackBuild repository.
Ten years have passed since those days, and SlackBuilds.org has brought a lot of good to Slackware. SBo submissions find their way into the Slackware distro core quite regularly. Which is nice, but more important is the fact that users of the distro are no longer tied to the “small” (other distros’ judgement) official repository but can tap into a vast repository of high-quality build scripts. I don’t think that anybody can concieve today of the idea that there would not be a SlackBuilds.org repository.
The fact that the SlackBuild scripts of SBo remained so basic allowed several “third party” tools to be conceived that wrap themselves around the SBo content as it were, providing queue control and automation for the process of building your own packages as well as all their dependencies. Well-known examples are sbopkg, sbotools and slpkg. The queue management feature is special. Slackware is a distro that does not concern itself with dependency management – you install the full distro, it is small enough, and that fulfills all the dependencies. Working with 3rd party packages and scripts is different though, and these tools around SBo have found ways to build and install all the required dependencies along with the package that you want to have in the first place. All of that is made possible by the SBo “info” file which is part of every submission. It contains the essential information about the software that is to be packaged, it is easily parseable and therefore ideal source material for the 3rd party tools:
PRGNAM="name of application"
VERSION="version of application"
HOMEPAGE="homepage of application"
DOWNLOAD="direct download link(s) of application source tarball(s) arch-independent or x86"
MD5SUM="md5sum(s) of the source tarball(s) defined in DOWNLOAD"
DOWNLOAD_x86_64="direct download link(s) of application source tarball(s), x86_64 only"
MD5SUM_x86_64="md5sum(s) of the source tarball(s) defined in DOWNLOAD_x86_64"
MAINTAINER="name of SlackBuild script maintainer"
EMAIL="email address of author"
I have since retired as a SBo admin, although I still hang out in the users- and admin-channels on IRC. Others have come and gone as well, and the current team is still going strong (and with Robby & Erik still at the wheel). I admire these guys a lot, because just look at the size of the repository! The package database for Slackware 11.0 (which we started with in 2006) contains 429 submissions. Compare that number to the Slackware 14.1 repository’s 5745 entries. That’s more than 13 times as many! And now imagine that this small team (the admin team has grown a bit bigger since the beginning but not much) still QA’s every script by compiling it and checking the outcome. On top of that, the team has to test all these scripts against the upcoming Slackware 14.2 release and make sure that there will be a high-quality SBO repository for Slackware 14.2 when that gets released. The project is using GIT to manage this transition process. Learning about and understanding git is one of the most important things that I took from the SBo project.
These guys need your praise and support. Go tell them in the slackbuilds-users mailing list!
Dear visitor, you seem to be using an Ad Blocker. Please consider whitelisting 'Alien Pastures'. I use the revenue from displaying ads (small as it is) to keep this site running. Thanks!