Slashdot Mirror
Systemd Rolls Out Its Own Mount Tool (phoronix.com)
An anonymous Slashdot reader writes: I'm surprised this hasn't surfaced on Slashdot already, but yesterday Phoronix reported that systemd will soon be handling file system mounts, along with all the other stuff that systemd has encompassed. The report generated the usual systemd arguments over on Reddit.com/r/linux with Lennart Poettering, systemd developer and architect, chiming in with a few clarifications.
Lennart argued it will greatly improve the handling of removable media like USB sticks.
Lennart argued it will greatly improve the handling of removable media like USB sticks.
That would be funny if it weren't true.
Lennart argued it will greatly improve the handling of removable media like USB sticks.
... everything starts looking like a nail.
invited complaints, counter-arguments, and forks to get away from your shit, maybe you should take that as a hint to just stop. Chances are that you are, in fact, not the only sane man left.
Indeed. The only ones upset about this are the ones that did not know what it was about.
Yep. That won't stop the hivemind from shouting against it, though. According to Slashdotters, everything must be done as it's always been done, regardless of any externalities.
Meanwhile, I have a server (based on an ugly inherited design) that has to figure out its remote filesystems based on the network structure, as determined by a user-run script. The process I inherited was to boot the server, run the script, then mount the filesystems it reported needing. Then and only then could the main daemon be started manually.
Fuck that.
An upcoming rework will automate the process with scripts, but it seems like the sort of thing that falls right in systemd's wheelhouse. Systemd's goal is to start the system services, which would reasonably include my daemon. It therefore also seems reasonable that systemd could have access to mounting functions, to ensure the system is ready to start that daemon.
You do not have a moral or legal right to do absolutely anything you want.
fuck off retarded, nothing optional about that shit
= 'I don't know a fucking thing about it but I hate it anyway.'
Which is kinda ironic for a forum once centered around new technology. We've gotten old :(.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Well duh, of course systemd will have its own editor. How else are you going to be able to fix your configuration when the system won't boot? Do you think that Lennart will ever add a keystroke to cancel starting a broken unit during boot? I mean, you could ctrl-c most service startup scripts in SysV init, and if init could do it, then it must be wrong.
So it's subsumed the auto mounter. That is no better.
I think it is like Emacs without the editor part.
Emacs has been around since 1976 -- I've used it almost daily since 1985. Let's see if systemd is still here and useful in 40 years.
You're like the senior management at Blockbusters who saw Netflix as a minor niche player who presented no threat to them. Or like the managers at Polaroid who thought digital cameras were just a fantasy.
Systemd is a cancer and it will keep spreading until the host is dead. Just like cancer it's not malicious, it sincerely believes it knows better than the healthy cells it's infecting, but that doesn't make it less lethal.
lucm, indeed.
There are already the usual anti-systemd flames and complaints about how it's absorbing ever more functionality.
As for the server itself, that is roughly the current plan. The devil's in the details, though, when it comes to handling errors in detecting the network configuration and mounting the remote filesystems. For example, as node A initializes, it should try to connect to (and mount) nodes B, C, and D, but if a node is down, the other node connections should function normally until the missing node returns, at which time that connection should be established and the data synchronized among the nodes.
Writing standard scripts to handle the process isn't an intractable problem, but it'd be much simpler with a more robust environment. I'm curious (and a bit hopeful) to see whether systemd can provide the necessary functionality without extensive custom scripting.
You do not have a moral or legal right to do absolutely anything you want.
What the hell is a "disttro"?
It's a misspelling of 'distrro', which is itself a misspelling of 'distro', which is a shortened form of 'distribution'. Glad to be of service.
a major distro with systemd removed (with broken functionality)
While this is mostly true for those hosting their own systems, one of the larger pieces of the Linux `ecosystem' today is AWS. The heavily used Amazon Linux AMI has the traditional SysV init and Amazon has not indicated that they intend to move to systemd. This at least ensures that it will not be possible to entirely neglect SysV init methods; if it doesn't run on EC2 it's broken for many people, and indeed there are cases of commercial software vendors discovering that their paying customers need SysV init compatibility for this reason.
I personally haven't had problem with systemd anywhere I've had to deal with it, and I've become comfortable working with it. The doomsayers predicted all manner of problems with systemd. They were wrong as far as I know. A minor bug here and there, quickly fixed. Journalctl is very handy; a lot nicer than chasing creatively named log files hither and thither. On the other hand, when I deal with EC2 instances and SysV init I'm fine with that as well. I understand both the rational for systemd and the reasons behind Amazon staying with SysV init; I'm happy to live with both.
Maw! Fire up the karma burner!
Some of us actually know how to do more than yum -y install. You know -- that old fashioned "compile from source"? Or even find an rpm.
The point is not "duh give me teh rpms", the point is why the fuck would you pay $2,000 per cpu per year to get a polite "piss off" from Red Hat whenever support is needed because you installed (from source or other) a version or software that is not in their repo. That's like renting a car that has no radio and bragging that you can go to Best Buy to get a car radio installed in it.
If you want the general Red Har ecosystem but you rely on non-supported software, use CentOS for free and be done with it.
lucm, indeed.
This one expects that the forking will go byebye soon. If anything Mr. Poettering has learned, much like the White House, how to get crap past the radar. You do so by turning up the heat ever so slowly...
fuck off retarded, nothing optional about that shit
You know you have won when the other side resorts to profanity.
Systemd objections are not about "any change is bad". They're about "this change is bad".
Socialism: a lie told by totalitarians and believed by fools.
Yes... and ought to. It's a job that absolutely belongs in a desktop environment and absolutely does NOT belong any lower in the stack than that - because there is no universally 'correct' way to deal with removable media - the common pattern is ONLY correct in a D.E. - lower in the stack any number of options could be correct for the use-case up to and including completely preventing the mounting of any removable media for security reasons.
Unicode killed the ASCII-art *
Indeed. We didn't mind simpleinit, or upstart or openRC or slackware's BSD-init - all of these were different init systems in the past. We didn't mount autofs or any of a dozen mount helpers added on top of the unix basic during the years.
To suggest that the opposition to SystemD is generically opposing change is to ignore that the people opposing it have been embracing change in all the areas where it plays for decades and are STILL embracing change in those areas - we're just not embracing THIS change because we believe it's badly designed. Having this many basic tools in a common code-base with massive interdependency that makes it near impossible to swap tools out with other tools or run any of them without running all of them... THAT Is a terrible design.
Hell, we don't even do that on the desktop where it may almost make sense. For over a decade KDE has had performance improvements if you run KDE apps in a KDE desktop - but never, once, did we have a KDE app you couldn't run under Gnome or OpenBox or any other DE you want. The coupling was always weak - use the features when available, don't depend on them. And vice versa - all the apps ran under all the desktops. You didn't struggle to run gimp or libreOffice if you chose KDE as your desktop - despite neither of them being written for it. In fact, there were patches you could install to integrate them better which were entirely optional.
That's a good design.
Unicode killed the ASCII-art *
Better for distro maintainers != better for users or better for Linux.
Better is an ENTIRELY subjective thing. Better at what ? Better *how* ?
Whether something is demonstrably better depends on what your chosen measurements are. That's like saying a Boeing 747 is demonstrably better a motorcycle.
Whether or not the statement is true depends entirely on the job description. If the job description is 'ferrying lots of people from coast to coast" then it's true, if the job description is "getting to the other side of town with minimal traffic problems" then it's utterly false.
No systemd is NOT better than anything by many, many measures. The only thing it is consistently better at is making distro maintainers' jobs easier. That's not a bad thing, but it's the wrong metric. Here in my country we have a similar issue in the medical insurance field. The largest local insurer by a long shot is also demonstrably the worst insurer you can have. They frequently refuse to pay claims they are liable for (relying on the imbalance of power their wealth gives them should a client choose to sue). Their customer service is absolutely atrocious.
So how the hell did they get to be the biggest insurer ? Because the deals they offer employers is demonstrably the best in the market. They save employers lots of money, so employers make them the default insurance offered - and employees are stuck with the worst insurance imaginable.
That's pretty much the relationship with systemd and distro-maintainers versus users.
Unicode killed the ASCII-art *
You know it's weird, but there is literally not a single thing on your list that Linux hasn't been used for successfully and doing successfully for the better part of 20 years. None of these are new problems. So since systemD is only 6 years old and most major distro's didn't adopt it until the last 3, I guess all of us were just suffering some mass delusion when we watched all this stuff working beautifully back in 2000 when nobody had ever concevied of systemD - and progressively get better every year since.
Now nobody is saying that there cannot be better solutions for this - what I can tell you is that a better solution CANNOT come from a massive bunch of tightly coupled tools with opague interfaces that are so utterly cross dependent that none of them can run (at least without massive hacks) unless you also run all the others.
The ONLY way to EVER do a good solution - especially at the system level - is to build it out of lots of LOOSELY coupled tiny bits that don't care how you put them together or what you put them together with (including pieces that the creators never knew existed).
That design has allowed an OS first compiled in 1969 to scale to the largest supercomputers and the smallest embedded devices alike, to survive 50 years of computing history jumping from platform to platform and architecture to architecture, resilient across one major revolution after the other - because it could adapt to any need and any use-case. Because you never had to redesign it to meet a new challenge, you just had to add a few small tools to the mix, and put the others together in a new way.
The lego-blocks approach is the heart and soul of the unix philosophy - and it's a philosophy worth preserving because that philosophy is literally the ONLY thing that has caused Unix to be the single longest-living architecture in computer history. It's an architecture that's so easy to evolve that no revolution was out of it's reach. From mainframes to PC's to phones - it went where the hardware went and was consistently the most reliable and cheapest and fit-for-purpose answer because it was designed to be easy to rebuild by simply taking the blocks and hooking them up in a new way that Kernighan and Ritchie never imagined.
In other words - everything SystemD is not.
We love doing things in new ways, we love change - but we're GOOD at spotting the difference between progress and regression - and systemd is NOT progress, systemD is doing on Linux the exact same mistakes that every operating system besides unix in history has made. If it remains dominant too long - the outcome will be that Linux goes the way of Multics or VMS because, like those, it will not be able to survive the next revolution.
Unicode killed the ASCII-art *
Great! What can we do to speed up this process a bit, its about time that linux started to replace some of its aging, creaking old architecture with new tools liberated of old, out of date practices and effectively made a system which took care of the things I really dont give a shit about.
My computer is not my work, I use it to do my work, I do not want to spend time configuring it, I want to spend time doing my work and enjoying myself, I really couldnt give a fuck how to configure it 90% of the time.
I think you summarize the problem pretty well. Systemd is a desktop solution for people who essentially want a Macbook.
What would be great? Having systemd only in specialized desktop distributions. Not on servers and not on desktop for power users. Even better: systemd should be a distribution itself, not be a part of other distributions. And it would also have the exclusivity of pulseaudio.
lucm, indeed.
Depends on what you mean by lethal. Cancer causes severe degradation in the host to the point of death. The same can not be said about the systemd systems which are happily running along just fine.
The guy with his systemd cancer equality is modded +5, and you write the actual truth and its at 1. There are Linux people out there as bad as the Microsoft shills.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
No. My argument is that on the server, many of systemd's components are either solutions in search of a problem or trying to solve real problems the wrong way. It started with things like accepting log corruption in return for faster performance. On most desktops, that is a justifiable trade-off. On a server, it is a minority use case. With a really tiny minority on whose servers I for one would not be willing to rely.
As I said: systemd is acceptable for desktops or other user-facing systems. Things that you expect to break anyhow because of user dumbness, hardware failure or spilled coffee, where reinstallation or replacement is cheaper and more practical than investing in reliability. There it brings you net benefits due to its design trade-offs. On a server I want to be able to retrace why something failed, not just have the system go back to some mostly functional default state or take a guess at what might be the best way to proceed. On a server I need to trust the system to do exactly what it is supposed to do, and to do it not just once or twice but every single time.
I know that it has become a bit of a trend to treat servers like just another machine and simply redeploy instead of fixing issues. For many business cases this may be the more economic solution. It is not the one I consider sensible and future-proof.
Rudolf Hess edited Mein Kampf. He was the very first grammar nazi.