Alien Pastures

My thoughts on Slackware, life and everything

Category: Science (Page 1 of 2)

I am hiring (ASML Veldhoven Netherlands)

September 14, 2021 / / 3 Comments

As you may know, I am working at ASML since 2016, first in a technical IT role but nowadays as an IT Group Leader focusing on providing services and solutions in Virtual Product Development (VPD) and Engineering Simulation (simulation driven design) toward our internal customers (mechanical and optical engineering, and research).

ASML is an exciting company to work for, and the amount of work we do is rapidly expanding as a result of the pandemic and the resulting increase in demand for consumer electronics and computer chips. As a company we are at the forefront of lithography innovation with our EUV machines (Extreme Ultra Violet laser powered).
See this one-minute intro video for instance:

To keep up the pace with the ever increasing demands from our ASML Research and Engineering colleagues, I have been growing the IT teams that report to me. I hired quite a lot of people during the past two years that I have been in the manager seat, and I am now hiring again!
I am also posting here on my blog because it is becoming more challenging every year to find the right people within a reasonable time.

Specifically: I have a job opening for an “IT Infra Automation & Integration Expert“. This job is located at ASML HQ, Veldhoven, The Netherlands. Note that you’d have to move to the Netherlands if you are interested and want to apply.
We are looking for a new colleague in the “SIMS” team of our IT Agile Release Train “Engineering Simulation Services”. This IT ART delivers a Simulation Workplace to our internal customers who are in Mechanical and Optical Engineering as well as Research departments.
See the online profile for all the job details. Feel free to ask below in the comments section about further background info.

Hope this is of interest to someone!
Eric

Chromium 78 for Slackware

October 25, 2019 / / 11 Comments

This week, Google released the first 78 version in the “stable” channel of their Chromium sources – the basis of Chrome, Opera, Vivaldi and even the Edge browsers, and of course the Chromium open-source browser itself. The release notes contain a fairly long list of security issues (CVE’s) which were taken care of.

I built packages for you today, so that you can enjoy the latest&greatest Chromium browser on Slackware 14.2 or -current.

 

What’s new in Chromium 78?

  • Tab hover cards. If you have a multitude of browser tabs open, it becomes difficult to recognize which tab has what page open. From now on, if you move your mouse over a tab you will see a small ‘hover card’ showing the title and the hostname of the page you have open in there.
  • Dark mode. You can now force ‘dark mode’ on every web site, whether the web site supports it or not. The web site code is not changed at all, and Chromium will perform a smart color inversion. You can choose between several algorithms. This is an experimental feature still, so you will have to enable it via chrome://flags like so: 
    chrome://flags/#enable-force-dark
  • Chrome Password Safety tool which was available as an extension since February of this year has now been folded into the core of the browser. This feature will inform you of weak, leaked or re-used passwords in your list of saved passwords. Later on, Google is going to add functionality that will warn you when you try to use a password which is leaked online – even if you do not save your passwords in the browser.
    Still an experimental feature in this version of Chromium, you will have to enable it first via chrome://flags:

    chrome://flags/#password-leak-detection
  • A new extended menu which appears if you click “customize” in the lower right corner of the ‘new tab‘ page. Decorate the ‘new tab’ with your own background image or a different theme. This is still an experimental functionality so you have to enable it explicitly via chrome://flags : 
    chrome://flags/#ntp-customization-menu-v2
chrome://flags/#chrome-colors
  • Just missed the deadline for Chrome 78:
    DNS-over-HTTPS (DoH): Google has started a field test of its newly developed technology to tunnel your DNS queries through regular HTTPs requests. This security feature will be invaluable to those of you who do not want to risk 3rd parties to sniff your DNS requests for instance on a public Wi-Fi network. It will also prevent potential DNS spoofing attacks.
    This  Google blog article about DoH explains the caveats of using their implementation and the difference with the Mozilla Firefox implementation of DoH. Firefox enables DoH by ecapsulating your DNS requests in HTTPs and sending those to a CloudFlare server, while Chrome honours your existing DNS configuration (like paternal controls and safe browsing). The Chrome browser will check if your DNS provider is among a list of DoH-compatible providers, and swiches to your DNS provider’s equivalent DoH service. If the DNS provider isn’t in the list, Chrome will keep using regular DNS requests. Therefore, you’ll have to actively check whether this feature is going to work for you.
    As said, that same blog page mentions that this feature did not make Chrome 78 at the last moment.
    Also good to know is that the field trial is only going to be enabled for a small percentage of Chrome users (and not on Linux or iOS at all) – once it gets enabled. Not sure if this is going to be available to all of us Linux Chromium users any time soon.

Enjoy the new browser release!

Eric

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.

Plasma5 Wayland works on Slackware

October 24, 2017 / / 27 Comments

Last year August 2016 I experimented with Wayland, the alternative to the X Window system. My goal was to see if it is possible to run a Plasma5 desktop session on a Wayland compositor instead of using X.Org.
There was one big showstopper at the time. Kwin_wayland has a dependency on the ‘logind’ DBus API and at that time last year, this API was only provided by systemd-logind. Luckily, someone treated the logind component of systemd similarly to its udev component. Where Slackware already uses “eudev” which is a standalone udev source extracted from the systemd source, there’s also “elogind” which is the standalone logind sourcecode, extracted from systemd sourcecode. With some difficulty I managed to create a Slackware package for elogind and everything compiled. I just could not get a working Wayland session.
As it turns out today, that failure to get Wayland working was an omission on my side… more on that later.

Shortly after, IBM told me I would lose my job, I found another job at ASML and life was hectic and remained so. I never got another opportunity to research the root cause of my Wayland failure.
Now that I have a week off, I decided to revisit the old Wayland disaster. After last year’s frustration over the need for elogind, I talked to the ConsoleKit2 developer and to the KWin developer, to see if CK2 could be extended with the required logind DBus API (parts of that API were already incorporated) and to get CK2 accepted as an alternative to systemd-logind on systems that don’t ship with systemd. Both wishes were fulfilled this summer, so I could drop elogind from my package set. I still needed to recompile / upgrade some other packages to add wayland support to them, but the fact is: Slackware does not need PAM or systemd to get Wayland working.

Therefore, my KDE 5_17.10_testing repository contains mostly what you already know and love: KDE Frameworks 5.39.0, Plasma 5.11.0 and Applications 17.08.2. All based on Qt 5.9.2. Just with 17 differences in the package list.

Why does Wayland work now, while it did not last year?
Well, that was entirely my perception of things. Probably would have worked last year as well, if only I had recognized the signs. Last year, and yesterday as well, all the puzzle pieces seemed to be OK, but their integration failed. The signs (using strace and gdb to find out why the Wayland session would not start) were telling me that KWin was trying to find a logind provider on the DBus and no-one was answering. It took a sudden insight this morning, the realization that there is one difference between Slackware and all those other distros. And I have been using a workaround for ages, and I just did not think about that.
It’s PAM.
When you login on a system running PAM, a login session is registered on the bus using either ConsoleKit2 or systemd-logind. Our PAM-free Slackware needs an additional “ck-launch-session” command in front of the “dbus-launch” command to connect a new ConsoleKit2 session to the bus and let KWin find it there… when I fixed that, my Wayland session just sprang into existence!

How to start a Plasma5 Wayland session

  • Runlevel 3 (console): run the ‘startkwayland‘ command as your regular user.
  • Runlevel 4 (SDDM): select “Plasma (Wayland)” from the session dropdown and then proceed to login.

Caveats

Of course… nothing works 100% the first time. So what have I ran into? Note that I have been running Wayland for a couple of hours only, so I can say little about its stability.

  • Dropbox does not start, unless you ‘unset’ the QT_QPA_PLATFORM variable first. This is caused by the fact that Dropbox uses its own internal Qt5 libraries and it does not come with Wayland support.
  • Gnome-keyring does not start for some reason, so you can not auto-login to skypeforlinux for instance
  • HP-tray was eating 100% CPU at some point and draining my battery. I had to kill the process.
  • Yakuake does not work (I know, it is not part of my ‘ktown’ package set)
  • Unlike an X.Org session, the Wayland session does not require an additional <Ctrl> keypress to switch to a virtual console. Therefore, when I wanted to invoke krunner with <Alt><F2>, instead I was switched to the second virtual console, tty2. Upon returning to the Wayland session (which was running on VT4 as opposed to VT7 for X.Org) the krunner window was waiting for me. Apparently both the OS and KWin process the <Alt><FunctionKey> combos.

A note about NVIDIA: I know that there are issues between the binary driver and Wayland. Please do your research if you use the binary Nvidia blob. My laptop has an Intel GPU which runs on the open source kernel driver, and has no issues.

Note: check out the KDE page which documents the Wayland issues: https://community.kde.org/Plasma/Wayland_Showstoppers

What’s needed to make Plasma5 work with Wayland in Slackware

We need Wayland support in the core of the OS as well as in the dependencies for Plasma5. Also we need a version of ConsoleKit2 that works with Kwin_wayland. Which means:

  • add a wayland-protocols package (wayland is no longer sufficient)
  • add an upgraded ConsoleKit2
  • recompile Slackware’s mesa using a slightly modified SlackBuild script (change the package tag from ‘alien’ to ‘wayland’)
  • write a xorg-server.SlackBuild script based on the code in the x11.SlackBuild framework of Slackware, and recompile xorg-server with that script (change the package tag from ‘alien’ to ‘wayland’)?
  • recompile libxkbcommon (change the package tag from ‘alien’ to ‘wayland’)
  • recompile qt5 (change the package tag from ‘alien’ to ‘wayland’)?

With the ‘deps’ taken care of, proceed to Frameworks:

  • recompile kwayland and plasma-framework (change the package tag from ‘alien’ to ‘wayland’)

And finally the Plasma packages that use Wayland in some way or other:

  • recompile kinfocenter, kscreenlocker, kwayland-integration, libkscreen2, plasma-desktop, plasma-integration, plasma-workspace, powerdevil and kwin (change the package tag from ‘alien’ to ‘wayland’)

You will have noticed that the packages I tagged with ‘wayland‘ instead of the usual ‘alien‘ tag, are the ones that picked up Wayland support as compared with their originals. This makes it quite easy for you to switch back to the original packages (mesa and xorg-server in Slackware and the other 13 in ‘ktown’) if you are done with your testing. The remaining ‘alien’ packages (wayland-protocols and ConsoleKit2) can be kept without penalty.

A final note about this updated xorg-server package. My version of that package is a 4-into-1 package; it contains xorg-server-xephyr, xorg-server-xnest and xorg-server-xvfb as well. If you decide to remove the testing packages and want to go back to Slackware’s non-wayland version of xorg-server, you must also re-install the other three xorg-server-x* packages.

Installing or upgrading Frameworks, Plasma and Applications

Please use the README file in the ‘latest’ repository for the installation & upgrade instructions. I reserved the README.testing in the ‘testing’ repository to highlight the differences between the two repositories.

Where to get these ‘testing’ packages for Plasma Wayland

Package download locations are listed below (you will find the sources in ./source/5/ and packages in /current/testing/ subdirectory). Only “bear” has the packages for now, the mirrors should follow within 24 hours. If you are interested in the development of KDE 5 for Slackware, you can peek at my git repository too. There is now only one source tree to create both ‘latest‘ and ‘testing‘ repositories.

Live ISO of PLASMA5

There will probably not be a Plasma5 Live ISO image based on the ‘testing’ repository with working Wayland support. My ‘bear’ server just does not have the disk space to host an additional 4 GB ISO file. Nevertheless, you can tranfer the existing Plasma5 Live ISO to USB stick, change the ‘latest‘ ktown repository to ‘testing‘ in the slackpkg+ configuration file “/etc/slackpkg/slackpkgplus.conf” and run “slackpkg update ; slackpkg install ktown ; slackpkg upgrade ktown” to get the 4 new packages and upgrade the 13 other packages. If you do not use slackpkg with slackpkg+ then simply look at the short list of packages to be installed or upgraded, higher up on this page.

Have fun! Eric

July 17 updates – Plasma 5, Live ISOS and more

July 18, 2017 / / 76 Comments

Slackware turned 24 today, 17 July.

To celebrate I have created some goodies for you. Nothing you can eat or drink…

First, Plasma 5 updates.

I have uploaded the July ’17 set of Plasma 5 packages for Slackware 14.2 and -current to the ‘ktown’ repository. KDE 5_17.07 contains: KDE Frameworks 5.36.0, Plasma 5.10.3 and Applications 17.04.3. All based on Qt 5.9.0 for Slackware-current and Qt 5.7.1 for Slackware 14.2.
NOTE: I will no longer be releasing Plasma 5 packages for 32bit Slackware 14.2.

What’s new this time

Apart from the usual upgrades to the Frameworks, Plasma and Applications subsets, there is only one interesting piece of news: I added ‘kile’ to the applications-extra directory. Kile is a LaTex editor and the port to the KDE Frameworks 5 is well underway. I based the package on a git snapshot of its repository. One more KF5 application in “applications-extra”.
The goal of the KDE community is that the Applications 17.12 release (i.e. end of this year) will not have any application that is still kdelibs4 based. Everything in Plasma 5 Desktop should then finally be based on KF5.

Installing or upgrading Frameworks 5, Plasma 5 and Applications

As always, the accompanying README file contains full installation & upgrade instructions.

Recommended reading material

There have been several posts now about KDE 5 for Slackware-current. All of them contain useful information, tips and gotchas. If you want to read them, here they are: http://alien.slackbook.org/blog/tag/kde5/

Where to get the new packages for Plasma 5

Package download locations are listed below (you will find the sources in ./source/5/ and packages in /current/5/ and  /14.2/5/ subdirectories). If you are interested in the development of KDE 5 for Slackware, you can peek at my git repository too.

Live ISO of PLASMA5

A Plasma5 Live ISO image will follow shortly on http://bear.alienbase.nl/mirrors/slackware-live/latest/ in case you want to try it out first (check the timestamp of the ISO on the web page). I am currently testing it, looks fine. Here is a screenshot showing the QtAv player (a proper QT5 and QML based video player so that you can forget about kplayer or gmplayer):

What else is in stock

The PLASMA5 Live ISO is crammed with all my relevant big packages (libreoffice, vlc and friends) and I refreshed a few of these packages:

  1. A package is available for the latest MKVToolnix 13.0.0 – Slackware 14.2 and -current.
  2.  I built the latest Calibre 3.4.0 for Slackware 14.2 and -current, adding several internal modules which I omitted in my first Calibre 3 release. As a consequence, Calibre now also depends on unrar for which I also compiled the latest release (5.5.6) into a Slackware package.
  3. Podofo is another dependency for Calibre that received a long overdue update, and my repository now contains version 0.9.5.

And I am also preparing Live ISO images for the variants SLACKWARE (64bit and 32bit), XFCE (64bit and 32bit) and MATE. They should go online at the same time as the PLASMA5 ISO.

Have fun! Eric

« Older posts

© 2024 Alien Pastures

Theme by Anders Noren — Up ↑