This is an old revision of the document!
I want to choose a barebones Linux to which I can add and customize. Barebones file system, barebones init. barebones window environment, AppImage instead of a package manager.
I've used Crunchbang, which is based on Debian with a customized OpenBox. Crunchbang folded when Debian transitioned to systemd. The userbase resurrected as Bunsenlabs and Crunchbang+
Thread about MX Linux and Devuan Linux on debian.net
Linux purists, are saying that Systemd is causing bloat. The issue is that because Systemd is becoming a standard among many distros, some programs are being written that are dependent on it. These programs won't run on distros without Systemd.
Tomas, the guy over at Slax, is able to articulate the situation, but says he doesn't really care, that he's happy that someone else takes care of that layer of linux, while he works on modularity along the surface.
I've seen Windows become bloated, and I already know that I'm in the camp of KISS simplicity, especially under the hood. The complexity will increase until one person is not able to grasp it all to be able to organize it. Then there is chaos. It won't matter that Linux is open source. Then the wrong people will take advantage of the chaos for their own ends.
“ Because after systemd, no one will be able to work on their own system any more. They will just pull down systemd, and accept whatever it is - because it is a massive, deeply interconnected rat's nest, and no one but its very small group of creators will ever be able to extend or maintain it. ” source
Perhaps the main issue is that software is being made that is not modular/portable, with dependencies on systemd. MX Linux, uses a systemd shim, in order to be more compatible with software, while retaining an independent init system.
I searched for “systemd modularity” and came up with this page, which is by a developer of systemd, stating the myths surrounding the controversy surrounding systemd. Despite all of what he may say, which I am not necessarily disagreeing with, the KISS philosophy is usually the safe bet.
Runit’s size makes it much faster than most inits and especially suitable for older hardware. Its size also makes it easy to understand and learn. In fact, a few hours is all that is needed to learn runit. The fact that it was developed on Debian may make it especialy suitable for Debian derivatives. init Alternatives, linux-magazine.net
Does not matter that last update was 2015: Why is the init system still Runit despite it no longer being developed? Reddit
BusyBox provides many common UNIX utilities in a single small executable for embedded systems. The package includes runit… archlinux.org
MX Pros:
1. stable, quick and reliable Debian Stable distro with great tools; 2. One-click updates from MX-Updater that you don't really need to worry about. No need to check on any update announcements or advisories before installing updates for fear that an update might break something. 3. Packaging Team really does a great job giving us packages that are not found in standard Debian repos or which are updated beyond the versions found in Debian.
MX Cons:
1. there does come a point at which updates of certain packages can no longer be repackaged for MX as they depend on a higher version of certain key platforms on which that Debian Stable branch is based. 2. Eventual need for reinstallation. Fixed releases like Debian/Ubuntu based distros have a base of key platforms/packages that don't change, and everything else for that version is built on these platforms. Every 2+ years, a new release with the latest base is released. Eventually you have to reinstall to get the latest base, because at some point in time, newer versions of some of your applications may no longer be installable on the older base since they will be built to depend on the newer base. Even if you don't care or need newer versions of programs, you should upgrade once they no longer provide security updates for your version of Debian.
I will state that I don't find the reinstallation every 2+ years that difficult. You can preserve the /home partition of your current MX install when installing the new version of MX over the /root partition. And besides, backing up your data isn't so hard if you already store most of your data and media in a separate partition or drive rather than in /home of your distro. That way, the installation process doesn't affect the main place that you store your data.
Rolling Distro Pros:
1. rolling distros upgrade everything, even the key platforms the rest of the distro gets built on, all the time. If your favourite package has some new feature coming that you really want, you'll get it soon enough.
In Debian, you may have a scenario where you are looking forward to a long awaited feature or a bugfix for an annoying (but not serious/dangerous) bug in an application, then you find that the new version of the app with the new feature or fix can't be built to work on your version of Debian.
2. no need to reinstall the distro as it just keeps rolling on.
Rolling Distro Cons:
1. in return for the above benefits, you will generally need to give the distro more care and reading up before installing updates/upgrades. Since everything is being upgraded, even foundations, updates can sometimes be a little tumultuous. Some rolling distros are easier to manage than others, because the developers try to control and moderate some changes before releasing the updates to the users. Some just throw all updates into the repos and the user has to do all the work.
The one you mention is not difficult as long as you don't jump straight into updating when you are notified of any. Wait two days then read the update announcement forum thread to see if some known issues have cropped up and what the solution is. Then update, incorporating the solutions if needed. Most of the time nothing's going to go wrong even if you don't read the announcements first. But once a while an update will come along that bites you in the butt, and knowing Murphy's Law, it'll be the one for which you didn't do your homework.
2. you may also need to carry out some regular maintenance on certain config files.
During updating, some config files may have updates but your existing .conf file will not be written over. Instead, the new version is saved with a different suffix. I ignore most of these changes, but there are one or two config files where I do take notice of new versions. Some changes might need to be merged into the current config file. But I do it at my leisure, maybe once every few months.
I like to customize, and I need things under the hood to be stable. The only person making changes needs to be me, otherwise when things go wrong there will be too many variables to deal with. A rolling distro placates creativity and drives complacency. You end up accepting what's given to you, because it's too hard to do otherwise.
Compiling from source vs using package managers, Reddit
Ubuntu and Debian combined have the largest repository base.
“You may want to know whether the software repo is compatible or not in between Debian and Ubuntu. The answer is both yes and no. Most of the time the software repositories works well in both systems with little changes or no changes at all. But many times you may need to edit the deb packages for satisfying the dependencies.
Moreover, Ubuntu has its packaging system called PPA through Launchpad that indeed doesn’t work on Debian. Canonical has developed a universal package management system called Snap and it also available in Debian repo. ” source
However, Ubuntu is not Debian, and MX Linux is further away. Using PPA in MX Linux is not as easy: https://mxlinux.org/wiki/system/add-ppa-repository
Just because you don't have access to all the software in the two largest repositories, isn't the end of the world. Usually, the stuff that may not be compatible, is that way because it's a bloated piece of junk. Good software is integrated to have fewer dependencies.
When software is written, developers will often use existing libraries for certain functions. Existing functions and API's make programming easier because the developer doesn't have to reinvent the wheel.
“In an ideal world, libraries would be fully backward compatible, so that a program that depends on one version of a library, would work with any newer version of that library. But library developers don't do that, and I don't know why. Linux wants to be ideal, and take up less hard drive space and resources (like RAM), and therefore use only one version of each library. So sometimes you want to install two programs that both use the same library, but different versions, and this makes for dependency hell. The portable theology, says “lets bundle the library into the program itself, so that it doesn't use the one that comes with the system”. This is contrary to the Linux ideal, but makes things much easier for the end user.” 2018: Portable Software
Since the amount of RAM available in current hardware is usually more than sufficient, one solution would be that each program load its own library versions.
Needing additional libraries means that the developer didn't take the time to extract the parts used within a library and add those to the main program, reducing the overall footprint. This requires more work: software developers are usually not interested in taking this step.
Modular software is easier to take with you when you move from one system to another. There are groups like https://appimage.org, that package program dependencies and make a singular module. There is also Flatpak and Snap packages. These articles covers all three:
https://ostechnix.com/linux-package-managers-compared-appimage-vs-snap-vs-flatpak
https://linuxhint.com/snap_vs_flatpak_vs_appimage
The only current file system capable of larger partitions and which does not have journaling or user permissions is exFat. Also it is supported by Windows. denabre on Reddit veprof.com
“exFAT isn't supported for booting on UEFI systems but for BIOS systems it should work.” porteus.org
Desktop Environment versus Window Manager, ghacks.net
Comparison & List of Desktop Environments, eylenburg
A full desktop environment is a complete graphical user interface (GUI) that includes not only a window manager, but also a range of other applications and utilities, such as a taskbar, a system tray, a compositor for transparency, a file manager, and a desktop background. The Ultimate Guide to Building Your Own Desktop Environment, Michael Neuper
You can rank by different methods at distrowatch, including by average rating, page hits, etc.
Top 20 Linux Distributions in 2023, Ranked by Google Trends Scores, fostips.com
The following do not use systemd.
Having their own portable software may not be important because AppImage makes truly portable software across different Linux distros?
Having full hardware support may not be important because some DriverPacks for Linux may exist?
Which desktop environment has the most diverse library of plugins/extensions/addons?
Key: indep: independent, alternativeto hearts, distrowatch page hit rank, distrowatch rating, google trend
distro | init system | package manager | desktop environment | forked from | hearts | rank | rating | trend |
---|---|---|---|---|---|---|---|---|
void | runit | containers + xbps | xfce | indep | 10 | 93 | 9.21 | 35 |
antix | runit | apt | icewm > fluxbox > jwm | debian | 16 | 15 | 8.15 | 38 |
slax | sysvinit | modules + apt | fluxbox | debian | 26 | 79 | 6.75 | 42 |
porteus | sysvinit | modules + slpkg | many | slax | 13 | 106 | 9.07 | - |
puppy | busybox | ppm + many | jwm | indep | 98 | 19 | 7.51 | 31 |
slitaz | busybox | tazpkg | openbox | indep | 50 | 150 | 6.29 | - |
tiny core | busybox | tce-load | flwm | indep | 19 | 75 | 6.7 | - |
dcore | busybox | sce self contained extension | flwm | tiny core | - | - | - | - |
Honorable Mentions:
distro | init system | package manager | desktop environment | forked from |
---|---|---|---|---|
damn small linux | runit | apt | fluxbox & jwm | antix |
Is there something like DriverPacks for Linux? This question was asked on Linux Mint forum in 2009.
There doesn't seem to be anything equivalent to Snappy Drivers on Linux: alternativeto.net.
How do drivers differ between Windows and Linux?
Comparison of the driver architectures used by the two operating systems has shown that the Windows operating system has a more developed architecture than Linux. This does not mean that the Windows architecture offers better functionality than that of Linux, rather it has a more formally defined driver model, which driver developers are encouraged to follow. Although driver writers can ignore the Windows driver model and construct their own monolithic drivers, it was found that most driver writers did not take this route. No formally defined driver model exists for the Linux operating system. Linux driver writers produce drivers based on their own personal designs. Unless two groups of driver developers cooperate and produce drivers that work together, drivers from different developers cannot operate together under the Linux operating system. Under Windows, drivers from two or more sets of developers can be made to work together, provided the developers have followed the Windows Driver Model (WDM) to construct their drivers. The Windows driver architecture supports PnP (Plug and Play) and Power management, by dispatching messages at appropriate times to device drivers which have been implemented to handle these messages. No such facility is offered by the current Linux driver architecture. A Comparison of the Linux and Windows Device Driver Architectures, Tsegaye and Foss, Rhodes University 2004
On Linux some drivers are built into the kernel and stay permanently loaded. Non-essential ones are built as kernel modules, which are usually stored in the /lib/modules/kernel-version directory. This directory also contains various configuration files, like modules.dep describing dependencies between kernel modules.
While Linux kernel can load some of the modules at boot time itself, generally module loading is supervised by user-space applications. For example, init process may load some modules during system initialization, and the udev daemon is responsible for tracking the newly plugged devices and loading appropriate modules for them.
…
The most prominent differences stem from the fact that Windows is a closed-source operating system developed by a commercial corporation. This is what makes good, documented, stable driver ABI and formal frameworks a requirement for Windows while on Linux it would be more of a nice addition to the source code. Documentation support is also much more developed in Windows environment as Microsoft has resources necessary to maintain it.
On the other hand, Linux does not constrain device driver developers with frameworks and the source code of the kernel and production device drivers can be just as helpful in the right hands. The lack of interface stability also has an implications as it means that up-to-date device drivers are always using the latest interfaces and the kernel itself carries lesser burden of backwards compatibility, which results in even cleaner code. Linux vs. Windows device driver model: architecture, APIs and build environment comparison, Dan Nanni 2020
Everything hardware is supposed to be supported by the linux kernel. As the kernel gets updated, more hardware is supported out of the box. However, too often there is a lot of “patches” that need to be applied specifically to get the most from your computer's hardware. Devices prepackaged with an operating system, such as Windows, Macos, or Android, have all this taken care of for you. Such is an advantage of buying from System76 or Purism: see 12 Places Where You Can Buy Linux Computers.
Linux has advanced in the ability to fully support a laptop or desktop without the need for hunting for additional drivers, etc. Chances are, whatever distro you try out won't need additional drivers. However, having support for hardware doesn't mean the driver is optimized for a particular device.
Something like power management can be very device specific. Linux isn't necessarily optimized for your particular hardware. Although the same can be said about Windows OS, where manufacturers provide custom drivers as addons.
This page gives lengthy details on configuring linux power management: https://wiki.archlinux.org/index.php/Power_management
I would like to find some benchmarks, showing battery life of linux vs manufacturer OS.
It occurred to me, to look up what it would take to connect a bluetooth mouse with a distro like Slitaz, which is even smaller than Antix.
http://doc.slitaz.org/en:guides:bluetooth
It's complicated. Computers are supposed to automate human processes. That's why we have them. So perhaps the smallest, leanest distro is not for me? I can spend hours trying to figure out which distro is right for me. It is a rabbit hole.
Something as ubiquitous as a Macbook, should have plenty of support, right? See that the 2016 and 2017 models are not 100% supported, and battery life is poor:
State of Linux on the MacBook Pro 2016 & 2017
There are instructions on tweaking the Macbooks on the following distros:
User's experience with both MacOS and Linux on a Macbook Air:
https://medium.com/@alex_nekrasov/installing-linux-on-macbook-air-838f9b087338
User's experience switching to Linux on a 2015 Macbook Pro:
https://medium.com/swlh/running-linux-on-my-macbook-9738b3b4f84d
This article compares power consumption between MacOS and Linux. However, he used Linux with no power optimizations (like from PowerTop):
https://www.phoronix.com/scan.php?page=news_item&px=MTE2Njk
July 2019: Linux 5.3 Will Surprisingly Support The Newest Keyboard/Trackpads Of Apple MacBooks, phoronix.com. The drivers had to be reverse engineered, because Apple purposely tries to avoid Linux progress.
Booting without ReFit/ReFind: https://glandium.org/blog/?p=2830
Android is linux with Google on top.
People use whatever they are given. If they were given computers with linux (laptop, desktop, phones), they would use linux. They can't be bothered to install something else unless it's super easy, such as installing a web browser like Chrome.
Perhaps if linux was given out as a usb drive and just worked right out of the box with the option to dual boot the original operating system, then more people would try it out.
However, sometimes it doesn't fully work, requiring additional drivers one must go out and look for. This isn't the fault of Linux, but of industry with no incentive to make Linux work on their devices. Industry actually works against linux becoming mainstream, because they make money by having proprietary operating systems.
In the case of Google and Android, Google took the free and added a proprietary layer on top which makes them money.
Trying to make sure I'm not missing any other controversial aspects of Linux, I found in the Wikipedia article:
“ Some security professionals say that the rise in prominence of operating system-level virtualization using Linux has raised the profile of attacks against the kernel, and that Linus Torvalds is reticent to add mitigations against kernel-level attacks in official releases. “
I read this as: The establishment wants to complicate something simple, so that it can later use the complexity to leverage power. History repeats itself over and over. They want to add complexity to the kernel in the name of “security”.
https://www.vice.com/en_us/article/3km9qb/linus-torvalds-is-back-with-linux
Article about news sources criticizing Linus Torvalds, and Linus Torvalds being influenced by the criticism. This could be good, and this could be bad. Good if the meritocracy continues; good if people treat each other well. Bad if this is an underhanded way of controlling the developers.
Discussion