SoylentNews is people
SoylentNews
from the it's-already-perfect-is-not-the-right-answer dept.
We all know about Microsoft's latest OS, so I won't rehash. A lot of us intensely dislike it, to put it politely. Those of us who can, use other operating systems. This is Soylent, so let's focus on the one that is the most important to us: Linux.
I have been using Windows as my OS since right after Atari times. A few years ago I bought an ARM (ARMHF/ARMv7) netbook and put Lubuntu on it. I had problems with my first Linux experience, mainly in the area of installing software: missing packages in Synaptic, small dependency hells, installing a package at a time by hand, some broken stuff. I put it down mainly to the architecture I have been using, which can't be supported as well as x86-64.
Now, we all know that no software is perfect, and neither is Linux, even though it is now my main OS. We support it in spirit and financially, but there is always room for improvement.
So, the question is: What are your problems with Linux and how can we fix them? How do we better it? Maybe it's filesystems, maybe it's the famous/infamous systemd. Let's have at it.
(Score: 3, Insightful) by MadTinfoilHatter on Wednesday February 22 2017, @08:06PM
4: Systemd is an improvement!
One of the things which has been a benefit is systemd. Most of the arguments against it are nonsense.
Actually I find a large portion of the arguments to be well reasoned, and thought out - at least far more well thought out than the "Hey, let's abandon everything we know about good design, because, you know, FASTER BOOT TIMES!!!11 one one" that is what the systemd-camp so often offers. Granted, your argument is a notch above that, but all you say has been debunked long ago. Here is a fairly comprehensive list of anti-systemd arguments, [without-systemd.org] and while I admit that not all the arguments are top notch, some of them are golden.
The declarative file format is much easier to read and write than shell scripts since it requires less wheel reinventing. shell scripts can be convoluted and obfuscated, systemd often has a simple declaration which would require many lines of shell script dealing with PIDs and so on.
Superficially, this is true, but it's really just shuffling the complexity around. What's really going on, though, is that the complexity has been moved from the logic into the language.
In stark contrast to Bourne shell, so many of systemd's unit directives are highly specialised building blocks which aren't easily reusable. This isn't necessarily a bad thing, except that because systemd units aren't real programs, there's no way to escape to more basic primitives as required. Inevitably, what this means is that more and more directives will be added over time as more and more use cases are discovered. See Steven McDonald's page for more details. [steven-mcdonald.id.au]
Add to this fact that every sysadmin on the planet knows at least some shell scripting - what's going to be easier to fix when a bug is found? The shell script or the systemd C code?
The idea that it is monolithic is a lie. The system is highly modular consisting of dozens of components.
The claim that systemd is modular is pure sophistry. In fact it's Fallacy #1 [blogspot.cz] on Jude Nelson's list of systemd proponent fallacies.
Lennart Poettering claims that systemd is not monolithic by pointing out that it is made of upwards of 69 separate binaries. This is a non sequitur, because "modular" and "monolithic" are not mutually exclusive terms.
A piece of software is modular if it is decomposable into distinct functional units such that each unit addresses a specific concern. Systemd, the Linux kernel, and X.org are all examples of modular software. Systemd addresses its concerns with its binaries, the Linux kernel with loadable kernel modules, and X.org with its drivers and extensions.
Now, a piece of software is monolithic if its components (if it has any at all) are tightly coupled--that is, components logically depend on one another to the point where using them in different contexts requires re-implementing the missing ones. Examples include Linux and X.org--in Linux's case, you can't use a kernel module without the kernel, the kernel can't run without the requisite kernel modules to interface with the hardware, and you can't use a Linux kernel module with other kernels or as a stand-alone program. Similarly, you can't use an X video driver without the X server, you can't use the X server without at least one video driver, and you can't use X's video drivers with other graphics managers or as stand-alone programs.
Under these definitions, systemd qualifies as both modular and monolithic. You cannot run journald without systemd, and cannot run systemd without journald (at least, not without losing logging for systemd-supervised programs). None of the *ctl programs work without systemd, nor do its collection of systemd-*d daemons. It used to be possible to run logind separately, but not anymore. According to the systemd developers, udev will likely be next to hard-depend on systemd. The point is, despite the fact that systemd is comprised of multiple binaries, the hierarchical logical coupling between them means that it is more accurate to think of them as extensions to systemd-PID-1 that just happen to run in separate address spaces. They are not truly independent, composable programs.
You can always run processes using the older SysV method and shell scipts if that is what you want, so the idea that systemd has taken something away from you is also false. I have set up SysV scripts in systemd with no issues.
The fact that it worked for you in some cases doesn't mean that it works anywhere near as well as SysV did. I haven't had personal problems, but that's mostly because I've been shunning systemd like the plague. But since it's anecdote time, a buddy of mine however began channeling Samuel Jackson after trying systemd for a couple of months... "I've had it with this motherf***** systemd on this motherf****** machine!" He switched to Devuan and was happy.
Database log files are a benefit when you have to deal with massive log files since it makes querying the file much faster and more precise. If you can store log files into an SQL database you can query certain fields in the table for what you are looking for without having to parse the file.
Okay, I really don't get what you're talking about here. I've been on one single project where the devs decided that cramming all the log files into a mysql database would be a good idea. It was the slowest and most horrible cludge I've ever seen. Something that would take grep seconds took the relational DB a minute or more. You had to search for stuff in one hour blocks, or the DB would grind to a complete halt. After 3 days the sysadmins put their foot down and we were back to normal text logs. Wanting logs in binary format sounds like the ramblings of a lunatic - even more so if the binary logs can fuck themselves up so that they're unrecoverable, [freedesktop.org] and troubleshooting therefore becomes a nightmare.
Finally I would like to close with this link [landley.net], which is one of the more insightful explanations about the philosophical problems that many of us have with what is probably the worst thing to hit the Linux world since the SCO lawsuits: systemd.
(Score: 3, Insightful) by Marand on Thursday February 23 2017, @05:35AM
In stark contrast to Bourne shell, so many of systemd's unit directives are highly specialised building blocks which aren't easily reusable. This isn't necessarily a bad thing, except that because systemd units aren't real programs, there's no way to escape to more basic primitives as required. Inevitably, what this means is that more and more directives will be added over time as more and more use cases are discovered.
There was another way that could have given us the best of both worlds, but it wasn't taken. Bourne shell isn't required for init scripts; it's fully possible to implement an interpreter for a systemd-style declarative init format and use it where convenient, and then fall back to writing programs when you need something "low level" that it can't do. I explain this in more detail in my other comment. [soylentnews.org]