Alien Pastures

My thoughts on Slackware, life and everything

Category: Rant (Page 1 of 10)

Let me remind you who started the war in Ukraine and how

February 19, 2025 /

I am going to spit 77 million people in the face here, and it needs to be done. I am raging. If you live in the USA and do not want to be confronted by my ‘leftist’ or ‘commie’ political views then unsubscribe from this blog and get the fuck out.
Listen carefully. Blatant lies are coming from the Oval office with the intention to destroy an ally.

The war in Ukraine did not start in 2022, and it was not started by Ukraine.

In February of 2014 Russia invaded Ukraine and annexed Crimea. NATO shied away from aiding Ukraine because of a justified fear of escalating the conflict. And in July of 2014, Russians shot down a commercial airplane over eastern Ukraine, killing hundreds of passengers. Hard work of a journalist collective provided the proof which held up in court.

In the years that followed, Russia kept arming and fueling the hatred of separatists in the eastern Ukraine. Why? Possibly because with the occupation of the Donbas, Russia now has control over 40% of Ukraine’s mineral riches. It’s always about the money, right? Or is the hunger for power stronger than greed?

In 2022 Russia invaded Ukraine from multiple fronts. Not because of what the traitor in the Oval office tells you – that  Ukraine started this war because of their request to join NATO – no, that request was sent to NATO in 2002, TWENTY years before Putin started his ‘special operation’. The invasion of Ukraine was ordered by a mad Russian dictator whose pride was hurt when the West kept ignoring him as a serious partner on the world stage.

Remember this account from what happened during those initial days?

This is not what happens if you pre-empt a strike because you fear your opponent. This is brutal sadism, trademark of Russian warfare where the state, not people, is the only thing that counts.

Those of you who put a traitor in the Oval office have made yourselves complicit, not just because you have enabled the autocracy or even dictatorship which is being created in the USA as we speak. But also complicit in the possible destruction of a European country: Ukraine. Your president with his delusions of grandeur will try again to grab Canada, Panama and Greenland and will leave Ukraine defenseless against Russia’s aggression. He does not care about you. He is a narcissist.
Next may be the start of an all-out war in Europe because Putin sees an opportunity. The USA now believes that Russia is not the enemy and Europe is its own enemy. And who the fuck cares about that in the USA?
I don’t understand you assholes who put this conman on a throne. All because you could not tolerate a black woman in the Oval office?
You don’t believe this? The orange guy keeps doing exactly what he has been telling you for years. There’s no reason to believe that he will change all of a sudden.

Fuck you all, maggots.

And indeed, I have disabled comments to this article. Suck it up.

GNU Screen user? How to migrate hardstatus colors to screen5

December 9, 2024 / / 7 Comments

And no, don’t try to convince me that I should switch to tmux!

I have been using GNU Screen for ages. It’s a convenient and safe way to manage a remote Linux server. Screen enables me to have multiple ‘windows’ available in a terminal, running its processes independently. When I close screen (or when my ssh connection fails), the processes contained in the remote screen session keep running.
It’s how I can compile Chromium for instance – a package compilation can take up to 12 hours. I go to sleep and the next morning I reconnect the screen client to the remote socket of the still running screen daemon and continue as if I was never away.
Yes I know that tmux is supposed to be the successor of screen, but I simply don’t care.

I operate multiple Slackware servers in remote datacenters and run screen sessions over ssh connections. To avoid any confusion about the server that I am executing commands on, I have configured screen to show relevant information in the bottom line. This concept is called “hardstatus” in screen. Here’s an example showing the three active bash prompts, highlighting  that I am currently working in ‘Window 1‘, but it also shows the server’s hostname in green and the local time in blue.

Before typing anything, I first look at the green text to confirm that I am connecting to the right server.

Now, recently Slackware-current upgraded from GNU screen 4 to version 5 and with that, an old compatibility syntax was removed – a syntax that made it easy to define the colors in that status line. But the info page which describes the syntax is probably written for even more stubborn people than me.

It took me a while to get the look and feel of my screen 4.x status line reproduced in screen 5. In fact, I fixed the hardstatus definition only today (after 4 months of barely tolerating the junked colors and finally having enough of it), and I want to share it with you.

This is what defines the status line in my Linux computers with screen 4:

# Tabbed colored hardstatus line:
hardstatus alwayslastline
hardstatus string '%{= Kd} %{= Kd}%-w%{= Kr}[%{= KW}%n %t%{= Kr}]%{= Kd}%+w %-= %{KG} %H%{KW}|%{KY}%101`%{KW}|%D %M %d %Y%{= Kc} %c%{-}'

And this is how the definition had to change for screen 5 in order to show the exact same status line:

# Tabbed colored hardstatus line:
truecolor on
hardstatus off
hardstatus alwayslastline '%{= .;#999999} %{= .;#999999}%-w%{= #ff0000;#999999}[%{= #ffffff;#999999}%n %t%{= #ff0000;#999999}]%{= .;#999999}%+w %-= %{#00ff00;#999999} %H%{#ffffff;#999999}|%{#ffff00;#999999}%101`%{#ffffff;#999999}|%D %M %d %Y%{= #00ffff;#999999} %c%{-}'

In case you are curious about my full ~/.screenrc definition file, you can find it in liveslak: https://git.liveslak.org/liveslak/tree/make_slackware_live.sh?h=1.8.1.2#n2053 – I still have to fix the hardstatus definition there though.

I hope that this helps some of you old guys.
In the comments section below, I won’t tolerate GNU haters, screen haters or other evangelists. Keep it civil.

Cheers, Eric

Authenticators for 2FA

July 6, 2024 / / 22 Comments

Multi-factor authentication: it is difficult to find high-profile websites these days that allow you to get away with a simple password-based login. It’s a sobering thought to realize how fast your ‘secure’ password can be hacked using sophisticated techniques that go way beyond brute-force cracking.

So, multi-factor authentication has become the rage. When you authenticate yourself, you increase the security of your account by providing multiple ‘factors‘: something you know (a password or PIN code); but also something you have (a cryptographic identification device or a token); and something you are (which could be a biometric quality such as a fingerprint or a face-iD).

When requiring 2 of these factors,  we talk of ‘two-factor authentication’, better known as ‘2FA’. Then, usually these will be the use of a password combined with the string of digits (a token) produced by an authenticator – whether that is a hardware device or a software implementation.

Popular are authenticator apps on smartphones. Google, Apple and Microsoft have their own authenticators which you can find in the respective stores for your smartphone. They are really easy to use and completely interchangeable – every authenticator will generate the exact same code for a website at the same moment in time.
The disadvantage of these authenticators becomes clear when you lose your smartphone… gone are the authentication codes you need to logon to your account! You’ll have to contact customer support to disable your 2FA so that you can access your data again, and then re-enable 2FA using an authenticator on your new phone.

That’s why Authy became so popular: this is an authenticator which stores your 2FA tokens securely in the company’s (Twilio) cloud storage. With Authy, you can authorize another device (smartphone or desktop) to generate the same 2FA codes for you. And as long as you remember the passphrase which encrypts your cloud-stored tokens, you do not need your original phone to authorize a new phone. Really convenient!
Unfortunately, Authy does not offer a way to export your tokens from their app.  It’s total vendor lock-in as it happens so often. And this month, Authy’s Windows and Linux desktop applications stop working, leaving only Android and iOS as supported platforms for your authenticator. On top of that, there was a recent breach of Authy’s cloud storage, leaking 30+ million email addresses associated with Authy accounts. That facilitates phishing attacks of course, but also, when you try to recover your account after the loss of your phone, Authy would first ask for your phone number and then continue granting access to the related account. Security updates to Authy apps on all platforms are now preventing application initialization based on your phone number, but it speaks a clear message: if you cannot fully trust the company providing you with one of two authentication factors, it may be time to switch.
But, the lack of export capability… indeed.

I have been using Authy for a couple of years, precisely because of the convenience it offers in the rare case that you lose (access to) your phone. Now being really pissed about the vendor lock-in, I went to look for an acceptable alternative authenticator. And I found Ente Auth. It is an open source 2FA authenticator, with the option (not mandatory) to create an account at Ente and sync your local 2FA tokens to their cloud server.  The end-to-end encryption used by Ente has been independently audited,  and the app allows you to both import (from other authenticators that are not Authy) as well as export your tokens. Ente’s server offers a read-only version of the authenticator interface which means, after login you can find your 2FA codes in your browser as well.
Switching from Authy to Ente Auth was a slow and painful proces, where I had to disable and re-enable 2FA on many web sites, but now I am ready to use Ente Auth exclusively. I can only highly recommend this app.

What’s more: Ente has also open-sourced its backend server. Ente is first and foremost an open source and secure alternative to Google Photos or iCloud: a place to store your photos and videos. But the authentication backend has been built as a standalone functionality from the start, which allowed the company to build Ente Auth around that backend. By open-sourcing the backend, you can actually have complete control over cloud-storage of your 2FA tokens! An account on ente.io is then not needed, you simply instruct the authenticator app to connect to your own server address.
And as a bonnus, you also get a secure and self-hosted alternative to Google Photos.

If there’s an interest in a follow-up article explaining how to self-host the Ente Auth server backend, let me know in the comments section below.

Have fun! Eric

In the works: LibreOffice 24.2.0 for Slackware 15.0

February 20, 2024 / / 21 Comments

Apart from post-COVID syndrome there were some other setbacks lately, but those were mostly software-centered. Like the fact that I can not build a 32bit Chromium package for instance.
But also the realization that the latest LibreOffice 24.2.0 can no longer be compiled on Slackware 15.0 – its gcc 11.2.0 compiler is considered “too old”.
With the help and insight of Pat Volkerding I was able to compile LibreOffice on Slackware 15.0 anyhow:

I need to test the resulting binaries, and I still need to see whether I can repeat this on 32bit Slackware of course… but it looks promising.
More to follow.

Update 2024-Feb-21:

+--------------------------+
Wed Feb 21 12:41:50 UTC 2024
libreoffice: updated to 24.2.0 for Slackware 15.0 and -current.
Depends on openjdk17.
openjdk17: added v17.0.10_7 for Slackware 15.0 and newer.
Only install one version of Java!

Cheers, Eric

Chromium 121 for Slackware… don’t hold your breath

January 24, 2024 / / 30 Comments

Chromium 121 sources were released yesterday, and as much as I would like to tell you that the Slackware packages are ready, in fact it appears that you will have to wait for them for an unspecified amount of time.

I found out that the build of Chromium now needs Google’s custom version of the Rust compiler, next to Google’s custom version of the Clang compiler. Those Rust and Clang versions are intertwined and Google advises packagers to simply use their own pre-compiled binaries which they provide for download.

You guessed… those binaries are not available for a 32bit OS. Nothing new, and it is for that exact reason that as part of compiling Chromium for Slackware, the complete LLVM toolchain is built from Google’s sources first. For every package I release. Tweaking the LLVM/Clang compilation so that they work for 32bit Slackware took a lot of time – after all, no one at Google tests their sources for 32bit build compatibility. So I patch here and there and every time feel lucky that it still works.

Until today, when I ran into the new Rust requirement. And after the umptiest iteration of a Chromium package build using a variety of changing options, I still fail to even start compiling a Rust binary.

I am taking a break from this to consider my options. My aim is to keep supporting the 32bit Slackware package. I just need to figure out how Google messed this up again and find a way around it. In the meantime, don’t hold your breath – I only have a few hours each evening to do the troubleshooting. A new package will appear when it’s ready.

All the best, Eric

Update 2024-jan-29: I have buillt 64bit packages for Chromium (also -ungoogled) version 121.0.6167.85 and uploaded them to my repository.
Note that I can not currently compile their 32bit versions because until now I have not been successful in building Google’s custom llvm and rust from source. I had to revert to downloading and using Google’s pre-compiled binaries which they only supply for 64bit systems.

I am still determined to find a way to compile these llvm and rust compilers from Google’s own sources. But I have no ETA on that unfortunately.

« Older posts

© 2025 Alien Pastures

Theme by Anders Noren — Up ↑