Alien Pastures

My thoughts on Slackware, life and everything

Category: Rant (Page 3 of 10)

Patrick, next Slackware and moving forward with KDE Plasma5

July 26, 2018 / / 25 Comments

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…

Eric

Tracking development of slackware in git

May 30, 2018 / / 19 Comments

Something had been nagging me for a long time, and I finally had enough of that itch and decided to deal with it.

As you know, there’s a private and a public side to Slackware’s development. The discussions and decisions are handled internally among the members of ‘the team’ and are not shared with the public at large until an update is done to the ‘slackware-current’ tree which can be found on every Internet mirror.
Thus you have access to the latest state of development always. But for some people it is a compelling idea to be able to access the development updates in a public repository like git – where you can track the changes over time.

A recent discussion on LinuxQuestions brought up the topic of SlackBuild scripts in Slackware-current. The scripts you can find in the -current directory tree on the Slackware mirrors are always the latest version. Sometimes there’s a good reason to want to go back in time and fetch an earlier version. In the thread post with the appropriate number “1337” it is ponce (Matteo Bernardini) who replies with a link to a git repository maintained by Adrien Nader which already has been tracking the development in -current for nearly 8 years!. So it’s quite a convenient way to retrieve a historical version of any script.

Me being me, it’s the existence of that repository which has been nagging me for a couple of years. Why? Because I wondered how it was done. And if I question an issue long enough, I will eventually create my own solution – as a learning exercise of course, but also to give back to the community.

And so, today arrived. I was pondering – if I were to create a git repository for tracking the developments in -current, what would I want in there? Exactly the same as Adrien’s? The answer has been “no” for a while. The most important capability that is missing from Adrien’s repo is that it contains a lot of compressed files that are impossible to read. Think of patches and doinst.sh scripts, and more. So I gave myself the task to implement a git repository with uncompressed files, as an improvement on the original effort. Also, it should track all relevant files in the complete tree, not just in the “./source/” subdirectory. In particular the documentation files (various .TXT files).

The result is a script, maintain_current_git.sh, and a repository, https://git.slackware.nl/current/ .
The repository just had its first commit. For those who want to check out a commit in order to compile a package from there, the maintain_current_git.sh script generates another script called ‘recompress.sh‘ and stores that script in the root directory of the repository. When you run this recompress script in the root directory of the repository, it will re-compress all the files that had been un-compressed before committing them to git. That way, a SlackBuild script will find the correct files and will function as intended. Note that you would still have to download the source tarballs from somewhere, because this repository of mine will only track the Slackware-specific files.

I decided that it is prudent and more respectful to not import Adrien’s work into my own repository. The two are similar but different and I think everyone of you can choose which repository suits your needs better.

I have scheduled the above script to run twice a day and update the git repository when new updates become available.
As with all my scripts, this one has a “-h” parameter to explain its usage. Let me know if it – and the git repository – are useful to you.
This particular script may be a bit messy because I have not spent a lot of time polishing it. I hope that’s OK 😉

Have fun!

Fun and games in -current when ABIs break

April 2, 2018 / / 32 Comments

Oh my.
It was not an April Fools joke when the ChangeLog.txt of slackware-current mentioned the following (I left out the non-relevant package updates):

 

+--------------------------+
Sun Apr 1 02:53:26 UTC 2018
...
l/icu4c-61.1-x86_64-1.txz: Upgraded.
 Shared library .so-version bump.
...
l/poppler-0.63.0-x86_64-1.txz: Upgraded.
 Shared library .so-version bump.

All of us  who follow Slackware’s development know that “shared library version bump” means ABI breakage. I.e. a lot of 3rd-party binaries will suddenly not find required library versions anymore. In particular icu4c and poppler are nasty beasts. Slackware’s own packages had been carefully updated and recompiled where needed of course, so there was no breakage in the distro itself. But many people do not run a bare Slackware installation… a lot of software is usually installed on top. And that is the software which will be affected by an incompatible change like this one on April 1st.

What’s this  version bump all about? How is it possible that it affects your computer so deeply?

Most programs depend on other programs. Software developers hate to re-invent the wheel if they can avoid it. Lots of lower-level or widely used functionality has been put into software libraries. Think of network access functionality, text rendering, encryption etc – smart people have created useful, efficient and robust software and stuffed that code into libraries. Your own program can link against these libraries at run-time and access the functionality they have to offer and your program needs.
If many programs link to the same libraries, that reduces the memory footprint because a library has to be loaded into memory only once even if many programs are using it. These libraries are therefore called ‘shared libraries‘ or ‘shared objects‘ (hence the extension ‘.so‘) or also dynamic libraries. For this dynamic linking to work, programs use binary interfaces at runtime that were established when the program was compiled and linked.
A shared library version only needs to change if the Application Binary Interface (ABI) changes. When that happens, all binaries that depend on the library need to be recompiled to adjust to the new ABI.
Among others, an ABI depends on the machine architecture, and on the toolchain (compiler, linker) used to generate the binary code from its sources. An ABI guarantees binary compatibility: the program will work on every machine with the same ABI, without a need for recompilation.

When will an ABI usually change?

One case is when the library’s API (Application Programming Interface, i.e. the way in which access to the library routines is defined in its source code) changes. This mostly occurs in software that is not yet stable and where its programmers add new functionality or revise the methods of calling the library’s functionality. Mature software on the other hand has a well-defined API which is rarely subject to change.

Another case is when the toolchain is updated. Slackware’s toolchain has been very stable and ABI changes have seldomly been introduced. As an example, Patrick talks about the a.out to ELF migration and the libc5 to glibc migration in a 2012 interview.

So why does well-established software like icu4c and poppler change their ABI almost on every minor release, thereby pissing off a really large crowd? You tell me. Arrogance or sloppiness, but let’s attribute it to bad project management. Because it probably could have been avoided in many if not all cases.

Anyway, some of you upgraded first to this new batch of updates in -current, then found out that some 3rd party packages stopped working, and then started looking for a cause.
Folks: if you are running slackware-current, you always check the ChangeLog.txt first. And if you spot a “shared library version bump” you stop right there and assess the situation. Some friends on LinuxQuestions were a bit more vocal about the way they had found themselves at a dead Plasma5 screen… others understood the situation better and and realized they had to wait for 3rd party packagers to update their repositories instead of assuming ill will.
If you are unable to cope with this kind of occasional breakage, use a stable Slackware release. That’s what all of us have been telling you all along.

My packages have been affected as well:

  • Plasma 5 stopped working,
    The fix is to recompile several packages among which a number of big ones: qt5, qt5-webkit and calligra. That means, you will have to have patience. The 64bit repository has been updated in the meantime. After upgrading from my ‘ktown’ repository your Plasma5 will again be fully functional. The 32bit repository updates will hopefully follow tomorrow have been uploaded now. I had to restart the 32bit qt5 compilation because of an internal compiler error halfway.
    The updated Plasma5 will even have some new functionality – since i slipped in the KMymoney program which otherwise would have been introduced at the April update of ‘ktown‘.
  • LibreOffice stopped working.
    The 64bit packages have been recompiled. They have been updated actually since there was a micro source version bump from 6.0.3.1 to 6.0.3.2 yesterday – my luck! The 32bit packages have to wait until after ‘ktown‘ updates have been completed and then I will upload them. New libreoffice packages for -current are now available.
  • Pale Moon stopped working.
    I was able to recompile the packages inbetween the Plasma5 compilation because it only takes little time. The updated palemoon packages are already in my repository.
  • Calibre stopped working.
    This will have to wait until after all the other updates New calibre packages for -current are now available..

And probably other stuff is broken too but I have not yet spotted that. If you find breakage, please report it so that I can recompile the package.

Encrypted Media Extensions on the World Wide Web

July 11, 2017 / / 6 Comments

Today, a post about Digital Rights Management. I am not going to bore you with the pros and cons of restricting your freedom, but I do want to point to a meaningful event which happened this week.

Before I continue, I want you to fully realize that with Slackware Linux, your rights are not taken away. You are free to use – or not use – technologies that allow you to watch “protected” content like Netflix videos. Our browsers will work just as well if you choose not to use DRM technologies. The libraries which implement the DRM layer are separate from the Slackware packages containing the browsers (Firefox, Chromium) and are not distributed with the OS. It is up to you to add DRM extensions if you need them. You are and remain in control of your OS.

With that out of the way, what happened?
This week, the World Wide Web Consortium (W3C) has finally approved the Encrypted Media Extensions (EME) as part of the HTML5 standard. Objections from the Electronic Frontier Foundation, Free Software Foundation and other digital freedom advocates have not been honored. But that does not necessarily mean it’s a bad thing. EME is a standard to implement DRM, but it is not a DRM solution itself. EME allows companies that built their business model around the commercial distribution of protected media content to create rich applications that run in your browser, based on international standards.
Digital Rights Management is not new and it is not going away either. However: it is in need of standardizing to improve the current status-quo. Because there are already several de-facto standards to stream protected content to your browser: Flash, Silverlight, to name the two that have been most widely used in the past years. Both these technologies are dying or dead already. New technologies that build on HTML5 are already becoming unofficial standards; think of Widevine, which is a DRM solution from Google. Not just browser plugins like the ones I mentioned, but also applications can implement DRM when they allow you to watch or listen to multimedia without the option to make unrestricted local copies. Locally stored content will be encrypted and can only be played back using the original app. Lots of those on Android for instance.

DRM solutions are proprietary. Their code is not free and the libraries are distributed as binary-only. There’s a logic to that of course. Think what you will, but there are both providers and consumers that embrace them. What is more important, is that there is wisdom in embedding these technologies in Web standards. We should not encourage companies to pollute our computers with incompatible and non-interoperable solutions. So yes, I am glad that EME is a W3C standard finally. Let the Web remain viable, allowing maximum flexibility and compatibility.

I mentioned Widevine in the text, and I have something new to tell about that too.
My package repository contains the chromium-widevine-plugin. It is a add-on package to my chromium browser package that allows you (among others) to watch Netflix video content in your Chromium browser. In the past I have always used the Google Chrome RPM’s to extract the ‘libwidevinecdm.so‘ library and make a Slackware package out of it. Google stopped distributing 32bit versions of the Chrome browser after version 48 so those of you on 32bit Slackware and using my Chromium package, were stuck with an old version of the Widevine CDM library and no way of knowing how long this library would remain compatible with newer Chromium sources.
But Mozilla have since then extended Firefox’ capabilities, so that it too is now able to use Widevine’s Content Decryption Module. In Firefox, this DRM capability was implemented in such a way that by default, the browser is completely DRM-free. You (the enduser) first have to explicitly enable DRM in the browser’s settings after which Firefox will download the Widevine CDM from an Internet URL. And since Firefox comes in 32bit as well as 64bit variants, I was thinking “where do they download these Widevine libraries and are they useable in Chromium as well?”

So I set out to find the Firefox download location for Widevine CDM libraries, found them, retrieved them and tested the libraries in 32bit and 64bit Chromium. Lo and behold…. this worked!

I have now rewritten my SlackBuild script for the chromium-widevine-plugin package to use this alternate download location. And since I no longer have to extract the library from a Chrome RPM, I have also changed the package version numbering. The package version no longer reflects the Chrome release, but now it is actually reflecting the internal version of the Widevine CDM library.

Have fun watching Netflix! While I am at it, I recommend The Expanse, or perhaps Helix. If you’re not so much into Sci-Fi (or have already seen those series) and want to know more about our basic foods, check out Cooked.

Palemoon browser

May 9, 2017 / / 31 Comments

The Pale Moon browser was forked off the Mozilla Firefox codebase a couple of years ago, before Firefox switched to the Australis User Interface. Since then, the project has steadily been diverging from the Firefox codebase, optimizing its Gecko layout engine and rebranding that to ‘Goanna’ (which is the name of just another lizard). The community has a large vote in the direction the Pale Moon browser’s features are taking.

People are drawn to Pale Moon because it promises to be a browser that is leaner than the modern-day Firefox. Pale Moon has the look and feel of Firefox like it was years ago, which has a certain appeal. Firefox and Chrome are both plagued by code bloat. The Australis UI ruined Firefox for many people. Also, Pale Moon supports the old Mozilla Sync (Weave 1.x). You can easily setup your own private sync server at home.
Yet, Pale Moon promises to give you a contemporary user experience regardless.

On SlackBuilds.org (SBo) you will find two different scripts to create a Pale Moon package. One, called palemoon, will wrap the official binaries into a Slackware package. The other, called PaleMoon, is a build-from-source which attempts to stay close and true to the Pale Moon project’s official recommendations about the use of compilers (GCC 4.x but not newer) and optimizations (compiler flags are “-O2 -msse2 -mfpmath=sse”). The Pale Moon developers have decided that these conditions are necessary to compile their sources into a stable browser (i.e. one that is not prone to crashing all the time on sites that are heavy on media or JavaScript).

The lead developer of Pale Moon is also very strict about the use of his official branding by 3rd party source builds that are re-distributed as unofficial binaries. Builds that do not conform to these policies, must use unofficial branding (a monochrome logo, and the name “New Moon”). The scripts on slackbuilds.org do not re-distribute binaries so they are not affected by these policies.

I decided that I was curious enough to write a SlackBuild of my own, and see what I thought of Pale Moon. I took inspiration from Slackware’s mozilla-firefox.SlackBuild and then did two things crucially different from the official recommendations. I used the default gcc compiler of the Slackware release I built the package on (Slackware 14.2 has gcc-5.3.0 and -current had 5.4.0 at the time when I ran the compilation… of course, now -current has gcc-7.1.0). And the optimization I chose is “-Os”; a conservative optimization with a focus on smaller code size, instead of better speed.

The resulting package seems to be stable, and it is not crashing on web sites where other 3rd party builds seem to falter. See this LQ thread for more details about problematic web sites which my binary shows without issue. Also – judging from the forum posts – it appears that many crashes are triggered when running Pale Moon in KDE4 with the oxygen theme selected for your GTK+2 programs. I fixed that instability by applying a patch to oxygen-gtk2 that can be found in its code repository but was never included in an official release. That patched oxygen-gtk2-1.4.6.1 package is available in my SlackBuild repository, and is also included in my ‘ktown‘ repository for the Plasma 5 desktop environment. I urge you to upgrade your Slackware package to this version.

Moonchild, the lead developer, gave his approval to use official branding in a series of private conversations we had, but being a Windows person he wants his Linux developer to check my package out. I told him that I will have a Pale Moon package in my repository, or none at all – I will not use unofficial “New Moon” branding. My package should give you a stable browsing experience – if not, let me know and do not bother the Pale Moon developers. So, if you see the palemoon package disappear from my repository, you’ll know that I have fallen out with the project and am not agreeing to their requests.
So far so good of course – this is Slackware, and we offer a nice & stable OS to run this browser on. I hope that some of you will find your new favorite browser in Pale Moon.

« Older posts Newer posts »

© 2024 Alien Pastures

Theme by Anders Noren — Up ↑