So last week we talked about the differences between linux distros and a bit of historical context. You can easily find other ZWOS episodes by searching for the threads tagged with the “ZWOS” tag.
We made the distinction between source and binary distros. We looked at the software distribution system in binary distros and looked at the software that connects computers with the software repositories, the package managers.
We also made the observation that the different distros are growing much closer to each other as time goes by, and that there are ever less performance differences between distros.
So chosing a distro based on performance of distro A over distro B, is not really a valid base for choice any more. In fact, even when factoring in source distros and binary distros together, performance as a whole will always be a compromise, for any distro. A source distro will take much longer to update for instance, because of the need for local compiling. Ten years ago, that was a non-issue, because the Linux kernel was small and the software packages in GNU/Linux distros were much more limited and not all that frequently updated. Nowadays, the Linux kernel is huge and the huge code base of most GNU/Linux software projects requires a lot of updates all the time, so source based distros require much much much longer to update than binary distros. This time has to be factored in, because it is system downtime.
So when we look at system downtime and download speed and frequency, OpenSuSE is the clear winner of all distros, because being an RPM distro it uses Delta RPM by default, which means that the amount of data that has to be downloaded to upgrade software, is minimal. A saving of 75-90 % of data bandwidth/volume for upgrades is not unusual for RPM distros. The DeltaRPM system also doesn’t really require extra system resources when hashing data, because the data hashing has to be done anyway in RPM distros, as safe data transfer is also a standard feature. This being an in important safety feature, it’s system overhead should not be counted against the cost of the package management system, as it’s a very minimal cost for a huge improvement in safety. OpenSuSE also has a feature that other RPM distros don’t have, and that makes it the winner in this category, and that’s a feature called “Live Kernel Patching”. Basically, OpenSuSE’s Yast tool has evolved so much that it is able to patch a running kernel. Since we already saw in ZWOS that everything in linux is a file, we understand that this is theoretically possible, the trick however is to perform it in such a way that the system does not lose settings or sessions.
Non-RPM distros do not encrypt the connection between the user and the repositiry, which opens the possibility of MIM attacks. Personally, I don’t understand that linux distros offer unencrypted HTLM or FTP ISO downloads and unencrypted package uploads and downloads from repositories in 2016. I think it’s retarded to do that nowadays. It compromises fundamentally the security of every single user. I think that it’s ostrich policy, but that’s a personal comment, and as always, such comments, although they point to finger to a basically very simple to solve problem that cannot be objectively denied, tend to attracts nothing but the typical shitstorm from independent distro communities. The “No! and shut up and fuck off!” attitude that is deeply entrenched in independent distro communities is what makes them weak and exposed to manipulation, but even saying that is the equivalent of spitting on the cross in those communities. The fact that it can’t be discussed in those communities or in the presence of fanbois or estimed members of those communities, does not make it less true, and users should be informed and should know what they’re getting into. A MIM attack on an unencrypted data stream is a really simple task for well equipped hacker communities and government agencies in 2016.
Besides not being encrypted, the non-RPM distros also do not use DeltaRPM or another incremental update system, so update packages have to be downloaded in full. For users in places with good bandwidth and uncapped data volumes, that is not an issue, but for companies with lots of machines (where the updates use intranet bandwidth) and for users with less time or bandwidth/data volume, it is definitely a handicap.
Clear loser in the uptime/bandwidth category are source distros, the local compiling takes forever, which is normal, and which definitely has advantages, but these do not balance any more with the disadvantages in this day and ages, unless for very specific use case scenarios.
Another aspect of performance is how lean a system is. Minimal systems are obviously faster than full-featured systems. To advertise this or that distro as higher performance because of this is very deceiving: these systems will offer less features, often less security features.
For instance, Arch is often praised as very fast. It also does not come with any MAC system by default. There is no AppArmor or SELinux by default, and if you would install a MAC/RBAC, it would bless optimized for Arch, so a similar install or Arch versus for instance Fedora with SELinux would probably see Arch lose in performance against Fedora, as SELinux is highly optimized for RedHat/Fedora/CentOS. Not all installs require a MAC though. For instance an air gap machine that controls an appliance of some kind, does not need to waste resources on a MAC/RBAC.
On average though, it’s pretty safe to say that all distros perform very similar these days if they are configured functionally in a similar way. Any distro can be configured lean or bloated. There is a difference in the amount of bloat distros are presented with on the default ISO’s, but for instance OpenSuSE, which is a pretty full-featured distro in the standard ISO, offers the function to configure your own custom distro through the SuSE Build Service. You can totally configure a minimal distro there and the ISO will be generated for you automatically. The SuSE Build Service is actually a very modern feature, that assembles a combined software package Just-In-Time, so that the exposure to possible code fraud is extremely low, much lower than any other software source. I personally think that the SuSE Build Service, which also provides packages for all other distros, even non-RPM distros, is the way of the future for open source package distribution. It offers the best security features and the best functionality by far. For the moment though, only SuSE offers a service like that.
So what do we base our decision for a distro on, if performance of distros is not really a valid argument?
Basically, distros have become a software service. Distro communities or distro-making companies take care of software maintenance and distribution. They don’t control the application software, they only provide a cocktail of the Linux kernel and a repository maintenance service of third party packages.
Those services are very important and very time-consuming. It is not a small feat to do all that and still keep the entire system running, in all its possible combinations and configurations… that requires a lot of testing and patching.
That testing is done through different systems. The most common system is to have several “branches” of a distro, one experimental, one for testing purposes, and one stable. That was the original system all distros used, and that is still used by several distros. It implies a release model for stable software that is periodical. This is the preferred model for uptime-maximizing installs, for instance server installs. The periodical release schedule makes the number of updates minimal, and the security maximal.
Since the popularity of linux on the desktop has risen, the popularity of rolling release schedules has also risen, to the point where distros have expanded their offerings to include rolling release schedules that are considered fit for daily use and production. In a rolling release schedule, individual packages will be merged as soon as the package is considered stable enough for that repo, whereby the individual package is tested upstream, but not on the same install base as where it is merged to. That can potentially create problems. Those problems also do pop up in reality, but mostly not to the extent of stopping the system from working or causing major flaws.
Modern hardware evolution has become incremental at best, but drivers and software subsystems have become very important aspects of computer performance and functionality.
Whereas this does not concern sysadmins running servers, it does concern desktop users a lot. Desktop users want all hardware, even the latest and greatest peripherals, to just work with maximum performance right out of the box. For that, they need the latest software, not only the latest kernels because of the hardware support, but also the latest functional applications, for instance desktop environments optimized for touch screen input, etc…
The users who find this latest and greatest support important for them, will prefer a bleeding edge distro, that pushes out new packages as soon as possible. These users will also prefer rolling release models, because those distros do not require a version upgrade, but basically, just keep fresh eternally without any real downtime.
The release model and maintenance quality have become the main factors in choice of distro nowadays, as other factors have evened out pretty much across distros.
Theoretically, most derivative distros have become superfluous. It’s totally possible to install Debian Testing for instance on a machine, enjoying the quality of Debian maintenance, while getting the same packages for applications from the SuSE Build Service, enjoying the maintenance quality of SuSE, and thus getting - without any added discomfort - a better quality and more secure equivalent to the likes of Ubuntu or Mint. Ubuntu’s owner, Canonical, has however seen this coming and has changed the license on their desktop environment Unity and their display server Mir, and has declined evolving along with the open source display server Wayland, to avoid the better quality software distribution by others leading to making Ubuntu superfluous. But for people that use any other desktop environment than Unity on Ubuntu, there really is no reason any more to use the Ubuntu repositories or install an Ubuntu spin… they would probably be better off install Debian Testing and using the SuSE Build Service to get an equivalent with better software quality. What Canonical has done to stop this evolution, is like what Microsoft and other software console vendors do to stop evolution. What Canonical should have done, is start a competitive software build service of their own, because that’s the real future: distro-independent high quality software maintenance and repository services. It would increase the possibilities for users to have even more custom installs and options.
Another sign that linux users evolve towards an even further custom/individual software sourcing, is the popularity of user repositories. Desktop users typically experience community repositories as a drag because of the “engineered by committee” aspect of them. The Arch Linux community started a packaging system that was aimed at easy packaging of custom code by users, with a separate package manager that allows other users to easily tap into the stock of software packaged by other users. The AUR (Arch User Repository) is the largest collection of application software for linux in the world. Desktop users that understand and accept the risks of installing software packaged by other users without peer review, can install a wealth of applications from the AUR. The only other distro that has a user repository is Fedora. The COPR repository does have a lot more rules than AUR though, en requires registration, and doesn’t require the use of a separate package manager, but otherwise, the principle is the same as the AUR: The COPR however is still very much Fedora, which is called the “engineers distro” for a reason, the software offered on the COPR is mainly serious software offered for testing purposes, whereas the AUR has all kinds of software for all kinds of purposes, and the AUR is many times bigger than the COPR.
This ZWOS has been a little longer than the others, I want to keep that an exception. Next week, there will be another topic and it will be a little shorter again. The topic for next week will be a little info on MAC (Mandatory Access Control) and RBAC (Role-Based Access Control) systems in linux.