I am a sucker for a good editor. I like atom. Don’t yell at me. Its pretty good for my use cases. It has lots of nice extensions I can and have used.
Atom is not without its dependencies though. Installing it, which should be relatively simple, turns out to be … well … interesting.
[root@centos7build nyble]# rpm -ivh ~/atom.x86_64.rpm error: Failed dependencies: libXss.so.1()(64bit) is needed by atom-1.26.0-0.1.x86_64
In searching the interwebs for what Xss is, I happened across this little tidbit
Experiencing this on CentOS 7 as well. Running yum install libXScrnSaver works there as a workaround.
While you might think, hey great, he found something that worked, let me briefly describe this machine to you, so we can decide if it is really “great”.
This is a HVM, running KVM, with no display. It is a build machine I set up for building my NyBLE stack. Its running locally on one of my 10 year old boxen. I wanted to put atom on there, as it is on my gigabit lan, and I don’t mind remote X here at home. The editor performs nicely from my laptop.
That is, in order to use a text editor, I had to install a screensaver on a headless VM.
Ok, this isn’t quite the worst of it. While I was researching what the minimal installation of CentOS I could get away with and have something fully functional for my purposes, I started looking into the package groupings. Take the “Minimal Install” grouping, which I would assume, would install the bare minimum I need to get an operational system.
[root@centos7build ~]# yum group info "Minimal Install" ... Environment Group: Minimal Install Environment-Id: minimal Description: Basic functionality. Mandatory Groups: +core Optional Groups: +debugging
Ok, it is build upon the core group. Lets look at that.
[root@centos7build ~]# yum group info "core" Loaded plugins: fastestmirror ... Group: Core Group-Id: core Description: Smallest possible installation. Mandatory Packages: audit basesystem bash +btrfs-progs coreutils cronie curl dhclient e2fsprogs filesystem +firewalld glibc hostname initscripts iproute iprutils iptables iputils irqbalance kbd kexec-tools less man-db ncurses openssh-clients openssh-server parted passwd plymouth policycoreutils procps-ng rootfiles rpm rsyslog selinux-policy-targeted setup shadow-utils sudo systemd tar +tuned util-linux vim-minimal xfsprogs yum Default Packages: +NetworkManager +NetworkManager-team +NetworkManager-tui +NetworkManager-wifi +aic94xx-firmware +alsa-firmware biosdevname dracut-config-rescue +ivtv-firmware +iwl100-firmware +iwl1000-firmware +iwl105-firmware +iwl135-firmware +iwl2000-firmware +iwl2030-firmware +iwl3160-firmware +iwl3945-firmware +iwl4965-firmware +iwl5000-firmware +iwl5150-firmware +iwl6000-firmware +iwl6000g2a-firmware +iwl6000g2b-firmware +iwl6050-firmware +iwl7260-firmware +iwl7265-firmware kernel-tools libsysfs linux-firmware microcode_ctl +postfix Optional Packages: dracut-config-generic dracut-fips dracut-fips-aesni dracut-network initial-setup openssh-keycat rdma-core selinux-policy-mls tboot
Look at all that nice firmware I don’t need/want. As part of core. Which is part of “Minimal Install”.
And NetworkManager. And postfix.
The problem is, when you install other packages, they will pull often large additional swaths of dependencies in to provide a library or a function which isn’t really used or needed.
Like the libXss with atom.
What I want, as a user, is to be able to build/install a minimal sized effectively appliance OS. I don’t want/need massive dependency radii. In fact, such a thing is an anti-pattern. It is the opposite of what I need.
Assume I am building minimal sized installations as appliances I can deploy quickly and easily. Do I really need LaTeX in, because of an obscure tertiary or worse dependency graph?
And, to make matters worse, if you try to excise the unneeded packages, you invariably risk the integrity of the package set you are attempting to install. As that dependency graph is unforgiving.
If I were a conspiracy theorist (I am not), I might follow a flight of fancy over distro lockin with extended dependency radii.
I am, or like to think of myself as, pragmatic, which means I try not to let things like this get in the way of doing what I need to get done. And please understand, these dependency radii are inhibitors, barriers to be overcome in many cases.
They aren’t helpful.
I don’t see distros adding much value beyond bug databases and some packaging/tooling. When the latter gets in the way of the former, I’ll do what I can to contain the damage.
I know some people are as wedded to their distros as others are to OSes. Distros, OSes, etc. are details of an instance. Not the purpose of the instance. They are tools to be used, changed when they don’t work for something that does work. No one tool is perfect, no one distro, OS, kernel, toolchain is beyond question.
This is one of the reasons I question the longevity of distros that attempt to enforce their world view on wide package radii. There is a long tail of users for everything, and the ardent defenders of a particular way of thinking will defend it to the last developer. Even as the world moves on and leaves them behind.
Lets encourage the distro people to rethink what it is they deliver. So minimal is really minimal. There is far more value in that, than in trying to tie everything through package management and package dependency graphs that thwart peoples attempts to reduce footprint and increase efficiency.