Alien Pastures

My thoughts on Slackware, life and everything

Category: Rant (Page 4 of 10)

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.

Procmail config woes

November 3, 2015 / / 1 Comment

Damn… last friday I updated my ~/.procmailrc file on slackware.com to get rid of some persistent spam, and forgot to actually check the validity of that change.

I wish I had checked the logs… on sunday I started wondering why the mail had stopped arriving for alien at slackware dot com, on monday I asked Pat to check the fetchmail schedules and the sendmail queues (nothing stuck there) and emails I sent from outside as a test never arrived. It took until this evening to realize that I had stopped receiving emails after I made an edit in my mail configuration.

Damn again. Anyone who sent me an email between last friday Oct 30 and today Nov  3 21:00 UTC, please re-send it. Last one that I read and answered was one from McQuen.

Apologies if I sent your email to the blackhole called /dev/null …

« Older posts Newer posts »

© 2025 Alien Pastures

Theme by Anders Noren — Up ↑