The Problem With Package Managers

As Linux moves farther away from its UNIX roots, and more towards being yet another appliance for the drooling masses (the same drooling masses who just five years ago couldn’t grok the difference between a CD-ROM tray and a cup holder), our once great proliferation of usable choices has dwindled due to a tendency on the part of developers to target only Debian- or Red Hat-based distributions, with a strong bias towards Ubuntu on the Debian side, while few of the more generous developers will also target SuSE, and even fewer will distribute software as a distribution-agnostic tarball. This situation leaves users of other distributions in a precarious position, especially in the case of those of us who–like the author of this article–believe that systemd is a baroque, labyrinthine monument to bogosity (how Lennart Poettering manages to get hired by any reputable software development firm is an atrocity that boggles the mind–his other big “hit” is a three-coil, peanut-laden steamer of a solution-looking-for-a-problem called PulseAudio), and would seek one of the increasingly rare sysvinit based distributions to get away from it.

This is a problem mostly due to package managers. If you’re on a Debian-based system, you get apt. Red Hat, yum. SuSE, zypper. These utilities should need no introduction, and are often praised by Linux users: a single command will install a package and all of its required shared libraries and dependencies, and another command will upgrade packages to the latest and greatest versions, all from a centralized, cloud-based repository or list of repositories. They do provide some convenience, but at a cost: the days of reliably being able to find a simple tarball that will work with the incantation of ./configure; make; make install seem to be numbered. This was a nice, cross-platform solution, and had the added benefit of producing binaries that were well-optimized for your particular machine.

One bright light in all this darkness is the pkgsrc tool in NetBSD: you check out a full source tree from a CVS repository, and this creates a directory structure of categories (editors, databases, utilities, etc.) into which are further subdirectories representing packages. All you need to do is descend into the desired subdirectory and type an appropriate make incantation to download the package and its dependencies, build them, and install them to your system. Updates are similar: fetch the latest updates from the CVS repo, and repeat the process.

However, not even pkgsrc has solved the other big problem with most package managers, and that is the politics of getting new packages into the repositories. The Node.js package manager, npm, is the only one that does this correctly (in the FOSS sense) in any way: you go to the npmjs.org website, create an account, choose a package name (and hope it hasn’t already been taken by another developer), and you are in charge of that little corner of the npm world. You manage your dependencies, your release schedule, your version scheme, the whole nine yards. With Linux distributions, it seems that only a blood sacrifice to the gatekeepers will allow you to contribute your own packages, and even when you get past their arcane requirements, it is still a mass of red tape just to publish patches and updated versions of your software. Node.js, for instance, has not been updated in the mainline distribution repositories since v0.10, which is by all measures an antique.

In order to meet my standards, there are three solutions, that should be employed together:

  • Publicly and brutally shame developers who release only deb and rpm packages but no ./configure; make; make install tarball until they are so insecure that they cry into their chocolate milk and do the right thing (or strengthen the developer gene pool by quitting altogether and opting for a job wiping viruses for drooling PC users with The Geek Squad)
  • Push the Linux distributions to abandon the brain-dead cathedral approach to repo management and opt for a more bazaar-like egalitarian approach like npm
  • Make countless, humiliating memes of Lennart Poettering in embarrassing and compromising contexts (this bit is more for the health of UNIX as a whole than for package managers, but it’s the duty of every good UNIX citizen)

 

ArcaOS 5.0: Initial Impressions of the Latest OS/2 Distribution

I’ve been a fan of OS/2 since the 1995 release of OS/2 Warp 3.0. I stuck with it as my main operating system for around five years, by which time the difficulties inherent in making the sparsely-updated OS run on modern hardware forced me towards Linux, MacOS, and other operating systems for daily computing tasks. But, I’ve always tried to keep an OS/2 system around, even if not as my primary machine. An IBM Aptiva machine running OS/2 Warp Connect 3.0 was my OS/2 system from 2000-2004, and too many others to mention filled its shoes from then on.

I learned about eComStation a rather long time after its 2001 release, but was impressed with it right away. Especially the many improvements to its installer. I bought new licenses for eCS every time a new version was released, but always had to dig up relatively old hardware to support its limited selection of drivers. Laptops were typically a no-go.

When ArcaOS 5.0 was released, I picked up a license right away. Arca Noae’s online shop is quite straightforward: I simply added the personal license to my shopping cart, checked out, and waited to receive an e-mail saying that my personalized ISO image was ready for download. This was delivered in a compact 7-zip format, which expanded to approximately 1.1GiB. Too large for a CD-R, so I burned the image to DVD-R media and proceeded to begin installing it on my Lenovo ThinkPad T530i (2.4GHz dual-core i3, 16GiB RAM, 1TiB SSHD storage, Intel HD3000 graphics).

My first impression of the updated installer revealed that the ridiculously long product keys of the eComStation days have mercifully been removed in exchange for the personalized ISO approach, which embeds the license holder’s name in the ACPI driver (and possibly elsewhere, though I haven’t looked). I noticed that even in the installer, ArcaOS was running my laptop in full 1080p resolution. The installer detected the T530i’s on-board Ethernet NIC, and automatically set it up for DHCP configuration. Sadly, the on-board Wi-Fi was neither detected nor supported.

When I got to the part of the installer where you select a destination volume for ArcaOS to format and install itself onto, it became clear that something was wrong, as my 1TB hybrid hard drive was being seen as 511GiB and with a corrupt partition table. It took two more false starts to correct this, and the solution was in changing the SATA controller mode BIOS setting from AHCI to compatibility mode, and disabling UEFI entirely.

Once the system was installed–a process which took about half an hour–ArcaOS booted up to the familiar Workplace Shell UI in glorious 1080p. I immediately set about doing my usual customizations to make it feel more like my beloved OS/2 Warp Connect. However, not everything was perfect:

  • The MS-DOS and Win-OS/2 subsystems seem to be completely broken, both in full-screen and windowed mode. The command prompts for the former only produce a blinking cursor, and the latter locks up the system entirely. I’ve had problems before attempting to run DOS and Windows 3.x apps under OS/2 and eCS when they are installed on a volume larger than 2GiB, but have never seen them freeze entirely under any IBM release of OS/2 or in any release of eComStation.
  • While the Panorama VESA video driver supports my Intel HD 3000 GPU in 1080p resolution, attempting to increase color depth from 64K colors to 16M colors results in a complete system lock-up, requiring me to power cycle the machine in order to recover.
  • If the eCS-era tools for switching between Panorama, SNAP, and other video drivers are present in ArcaOS, I cannot find them. At one point, I tried to add OS components using Selective Install, which ended up resetting my display drivers to vanilla VGA: 640×480 and 16 colors. The only way I could find to fix this was to reinstall the OS from scratch.
  • The UniAud driver shows up in hardware manager, as does my on-board sound, but there is no sound from the speakers, save for the occasional high-pitched chirp.
  • MultiMac does not yet support my Intel Centrino 2200 Wi-Fi adapter. I expected this, as Wi-Fi chipsets are notoriously proprietary. I have high hopes for the forthcoming FreeBSD driver ports.

The improvements in video card support and Ethernet support, as well as in the installer, make ArcaOS a compelling update for any OS/2 user. However, Arca Noae has some non-trivial work to do in order to bring the product up to the same level of polish as eComStation 2.1.