Slashdot Mirror
Is Modern Linux Becoming Too Complex?
An anonymous reader writes: Debian developer John Goerzen asks whether Linux has become so complex that it has lost some of its defining characteristics. "I used to be able to say Linux was clean, logical, well put-together, and organized. I can’t really say this anymore. Users and groups are not really determinitive for permissions, now that we have things like polkit running around. (Yes, by the way, I am a member of plugdev.) Error messages are unhelpful (WHY was I not authorized?) and logs are nowhere to be found. Traditionally, one could twiddle who could mount devices via /etc/fstab lines and perhaps some sudo rules. Granted, you had to know where to look, but when you did, it was simple; only two pieces to fit together. I've even spent time figuring out where to look and STILL have no idea what to do."
No problems here. Slackware seems to keep things simple. Granted, I haven't tried to mount a camera with DigiKam in a couple of years.
There has to be ONE networking script, no matter whether the one actually used is wired, wireless or pigeon carrier based.
Well, that's not really true. I mean, look at what I'm asking for WRT libvirt. There's a facility already present in the system for doing what they're doing, and they simply ignore it, with consequences for users. And what's more, the facility works really well for what they're doing with it, which they're doing very poorly.
And anyway, it's not true because interfaces can have their own scripts. I've used this functionality for firewalling on debian.
Linux is getting more and more similar to Windows, a huge abstraction layer crammed in between user and system in the vain attempt to make it "easy", and in this actually making everything overly complex.
Well, some things need centralized management, simply so that pieces of the system don't step on one another. Networking is basically the ideal example. Mounts are another. Nobody complains that everyone is expected to use fstab to define those, or that all mounts are tracked in the mtab.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I can - and do - make Linux dance to my tune and I've used it as my only desktop operating system at home for years. But yes, the learning curve was a pain in the neck. 90% of the time, everything installs and works perfectly. 7% of the time, you hit a problem that you can fix with a quick web search and twenty minutes of work. 3% of the time, you hit a headache that requires days of research and trying different things until you solve it or give up and try a different distribution or give up and go back to a proprietary operating system. I probably made a dozen switches to Linux that failed before they finished or only lasted a few months before I acquired enough skill to make the switch permanent.
/etc/fstab files listed disks and partitions like /dev/sda1 (first disk, first partition) and /dev/sdb2 (secon disk, second partition). The newer /etc/fstab files can support that format, but the preferred way to work is to use the UUID (universally unique identifier) of each disk partition. Yes, UUIDs make the file harder to read. Yes, UUIDs take a little more time to set up. But the advantage is that if you add a hard drive, solid state disk, etc... or remove one, it can change the order drives are enumerated to the operating system. If your /etc/fstab has the UUIDs of the partitions then that change is not a problem. If your /etc/fstab has /dev/sda1, /dev/sda2, etc... that change can break your boot process or at least mount some partitions in the wrong place. Likewise, the systemd "journalctl -r" is a new command to learn instead of "tail /var/log/messages". But the systemd journal uses digital hashes to make sure the system log has not been tampered with by a hacker. /var/log/messages has no such security, so the old way is convenient but less safe. Some changes are stupid, and unnecessary. But some are necessary, and useful.
About once every four or five hours of play, Minecraft crashes for my kids on my Linux machine. The display becomes completely unresponsive. So I have to switch to a virtual terminal or use a remote ssh (or better, mosh) connection into the machine, run "ps aux | grep -i minecraft" to find the processes related to minecraft, and "kill -9 PID" the processes for Minecraft. A full screen crash that hung the entire graphical interface has not happened to me on Windows more than a handful of times since Windows 98. I would never expect a casual user or even a moderately technical one that does not have a lot of Linux experience to be able to deal with this. I think I read somewhere that Wayland (the replacement for the X11 window system that underpins most graphical applications on Linux) has some fundamental design differences with X11 specifically so that a crash or hang of a full screen application can be detected and dealt with inside the graphical interface instead of requiring a switch to a terminal or remote shell.
All of these things can be improved and should be improved. I want to do my part, but work plus kids keep me too busy.
But to the article's original complaint, I think that sounds like the whining of someone who refuses to learn something new. For example, older
My question is whether it is really warranted to overburden and complicate scripts and even the functionality of some tools to pander to the quirks of hardware hardly anyone uses. My approach would be to leave it out and offer patches for the 3 people who actually want to use them.
Yet what really sold me on Linux is what you don't like. The nasty years of Windows Vista when perfectly good contemporary hardware had to be replaced. The present day situation where support for a product just goes away.
Linux now has the best support for devices of any OS.
My favorite example is when I was setting up a Dual boot system that used a USB to RS-232 adapter on both sides of the boot. I set it up first on the Linux end. No problem, Just enable the serial port (Linux looks at serial ports as a security issue) in bash, and it just worked. Now I start to set up on the Windows side. No worky. It sees the adapter, but no driver install. Nor help.
After a websearch I found out that the Adapter I had used was an old Staples adapter used for an ancient Palm Pilot my wife used maybe a decade ago. No Windows support, and none is forthcoming.
Its happily working on a Linux only system now, saved someone 50 bucks. It's also marked "do not use on Windows". Problem is, there really are a lot more than 3 of us who are using hardware other than the really common stuff. And your negative is our positive.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
1) go back to the old version of my distro, which has security holes, or 2) stop using Linux.
I think you missed 3) switch to Gentoo or Sla---
No, I'm not going to use Slackware, because it's prehistoric.
Ok, Gentoo it is.
I'm very happy with it. I even have in my /etc/paludis/package_mask.conf a section labeled Lennart Poettering that prevents systemd or pulseaudio from ever being pulled in by anything. grub2/OpenRC boots like a charm
Tempest in a tea pot really: I had the very same issue with Jessie and a little googling around quickly found the issue and a solution (for example here: https://lists.debian.org/debia...).
/etc/fstab for the key. Now the automounting of USB keys for the currently logged user is normally taken care of by udev, who does things properly. But for backward compatibility if there's a /etc/fstab entry udev bows out and let the legacy system handle the key, and that's where one end-up with a USB key mounted as root instead of as the user. Fix: remove the useless /etc/fstab entry. As this has been discussed already on the Debian user mailing list it's likely been fixed in the install process by now (not check, will try with a new laptop next week).
In short, if one installs (installed?) Debian Jessie from a USB key the installer would add an entry in
All in all: a small installation process glitch in the testing distribution, so still beta. But let's not waste such an opportunity to rant on how much the old times were betters, and young ones are hopeless. I guess the real issue is that early Linux users (me included) are getting older, and more adverse to changes.
But that's exactly the point, do the scripts really need to lug about support for stuff that maybe one, maybe two people actually use?...
:-) This topic is perfect for /. because of the complete lack of scope.
When you refer to "scripts", what level/layer are you referring to? I don't even think there is a well defined naming convention for that (ex. something like an OSI model with respect to configuration of hardware).
Given the networking example...
On the GUI level, there are loads of interfaces, many specialized, to aid in configuring the network. Some of them are protocol-specific, such as various VPN utilities, kppp and other ppp utilities, dial up interfaces, and a bunch of wifi ones too. Many of those are somewhat modular, with a backend/libs, command line interface, gnome/gtk interface, qt/kde interface, and possibly others (curses, xfce, tk, etc). That said, there is a primary target within this cadre: Network Manager and all its cousins.
On the other end of things, within the kernel, there's loads of drivers and standardized ways for those to interface with the various kernel subsystems. Those drivers necessarily have a wide variety of options... that's kinda the point. The vast majority of those can be compiled into the kernel, built as modules, or not built at all. This layer is fairly well defined as there is a clear separation of user space and kernel space; this ends at the first layer that provides a user space API (and this could be considered to constitute two layers... kernel space and user space of that... think OSI layer 1 and 2).
On that kernel level (similar to OSI media layers), I don't think we have a problem. This is, at least partially, due to the monolithic nature of the kernel and it's management by a benevolent dictator. A few comments here have mentioned support for old hardware, but I don't think they are referring to the drivers themselves nor the kernel... they're likely referring to something further up in user space. IMO, if the question is posed here, the answer is "No, Linux is not becoming too complex".
On the top end of the GUI side, I'd also argue that, "No, Linux is not becoming too complex". Yes, it can be a quagmire of various utilities at times, and some work better than others, but that *should* be fine. Hell, that's the only way to quiet those that complain about supporting all that old hardware - just snip it out of the GUI utility or hide it in advanced areas. I would never want to enforce a rule that these must all go through some specific middle ware, though that's really the part we should all be talking about.
So... the middle. This thread referenced "/etc/network/interfaces". That does NOT exist on all distributes (ex. redhat based systems don't have this). Personally, I like /etc/network/interfaces, but it's a good example of fragmentation of "standard" ways/interfaces to configure the kernel networking subsystem. Is it bad that debian and redhat both do it different? IMO, the "becoming too complex" question would imply that this is NOT bad, since this has been this way FOR A LONG LONG LONG TIME, and I'd agree that this amount of differentiation is ok and even good, but this could easily be argued is and firmly into the grey area.
The part that I have very large concerns with is what is currently happening with the low-level just above kernel... specifically, systemd and its related parts. Networking is an example here, as one of its goals is to provide one unified/common way to configure the network.... but doesn't that already exist!?!? It's called the kernel! On the other hand, maybe it will prove to be a useful shim? The fact that a single framework is going in above the kernel, which some direct ties to the kernel, and is casting a very wide net in terms of things it is, or can, control (logging, network, dhcp, login, init, sessions, mounts, consoles/vte, timedated/ntp, devices/udevd)... we'd better hope and pray it's designed well cause everything and the kitchen sink will soon have direct dependencies on the interfaces it's implementing.
Who modded this up?
SystemD has put in jeopardy the entire presence of Linux in the server room:
1: AFIAK, as there have been zero mention of this, SystemD appears to have had -zero- formal code testing, auditing, or other assurance that it is stable. It was foisted on people in RHEL 7 and downstreams with no ability to transition to it.
Formal code testing is pretty much what Redhat brings to the table.
2: It breaks applications that use the init.d mechanism to start with. This is very bad, since some legacy applications can not be upgraded. Contrast that to AIX where in some cases, programs written back in 1991 will run without issue on AIX 7.1. Similar with Solaris.
At worst it breaks their startup scripts, and since they are shell scripts they are easy to fix.
3: SystemD is one large code blob with zero internal separation... and it listens on the network with root permissions. It does not even drop perms which virtually every other utility does. Combine this with the fact that this has seen no testing... and this puts every production system on the Internet at risk of a remote root hole. It will be -decades- before SystemD becomes a solid program. Even programs like sendmail went through many bug fixes where security was a big problem... and sendmail has multiple daemons to separate privs, unlike SystemD.
Do you really understand the architecture of either SystemD or sendmail? Sendmail was a single binary written in a time before anyone cared about security. I don't recall sendmail being a bundle programs but then it's been a decade since I stopped using it precisely because of it's poor security track record. Contrary to your FUD, Systemd runs things as separate daemons with each component using the least amount of privileges needed to do it's job and on top of that many of the network services (ntp, dhcpd) that people complain about are completely optional addons and quite frankly, since they seem designed around the single purpose of Linux containers, I have not installed them. This is a basic FAQ entry on the systemd web site so I really don't get how you didn't know this.
4: SystemD cannot be worked around. The bash hole, I used busybox to fix. If SystemD breaks, since it encompasses everything including the bootloader, it can't be replaced. At best, the system would need major butchery to work. In the enterprise, this isn't going to happen, and the Linux box will be "upgraded" to a Windows or Solaris box.
Unlikely, it is a minority of malcontents who are upset about SystemD who have created an echo chamber of half truths and outright lies. Anyone who needs to get work done will not even notice the transition.
5: SystemD replaces many utilities that have stood 20+ years of testing, and takes a step back in security by the monolithic userland and untested code. Even AIX with its ODM has at least seen certification under FIPS, Common Criteria, and other items.
Again you use the word "monolitic without having a shred of knowledge about how SystemD works.The previous init system despite all of it's testing was a huge mess. There is a reason there were multiple projects that came before SystemD that tried to clean up the horrific mess that was the previous init.
6: SystemD has no real purpose, other than ego. The collective response justifying its existence is, "because we say so. Fuck you and use it." Well, this is no way to treat enterprise customers. Enterprise customers can easily move to Solaris if push comes to shove, and Solaris has a very good record of security, without major code added without actual testing being done, and a way to be compatible. I can turn Solaris 11's root role into a user, for example.
Solaris has already transitioned to it's own equivalent daemon that does roughly what SystemD does.
As for SystemD: It all
I didn't shut down all systemd talk. Just the stuff that was flamebait. What you didn't see is the comments that I deleted, which degenerated exceptionally quickly into namecalling and four-letter words. I am happy to tolerate many viewpoints on my personal blog as long as they are expressed with respect. I have seen sooooo many threads, whether here or elsewhere, start with statements like the one there. That post was on a technical matter, and things that are verifiably false and rehash the way a systemd decision was made were both off-topic and non-respectful.
There are a lot more systemd comments on the post, by the way. Some pro, some against.
"Systemd is a problem because..." was fine. "forced upon us" is a completely different discussion that is still highly-charged, produces nearly instant flamewars, and I didn't want to go there (yesterday).
My blog is my own little corner of the Internet where I try to raise the level of discourse just a bit. It's fighting a tidal wave, but I do try.