Slashdot Mirror
Busybox Deletes Systemd Support
ewhac writes: On 22 October, in a very terse commit message, Busybox removed its support for the controversial 'systemd' system management framework. The commit was made by Denys Vlasenko, and passed unremarked on the Busybox mailing lists. Judging from the diffs, system log integration is the most obvious consequence of the change.
The real "Libtards" are the Libertarians!
link dont work?
http://git.busybox.net/busybox/commit/?id=accd9eeb719916da974584b33b1aeced5f3bb346
No repositories found
remove systemd support
systemd people are not willing to play nice with the rest of the world. Therefore there is no reason for the rest of the world to cooperate with them.
remove systemd support
systemd people are not willing to play nice with the rest of the world. Therefore there is no reason for the rest of the world to cooperate with them.
...remind me why I should care?
Rumors of under-the-table incentives abound...
Wonder why so many other devs are so eager to put the systemd dick in their mouths.
Is there a swallow column and a spit column?
"Legacy Unix sucks! Let's make something called PowerDOS^H^H^Hshell!" - Bill Gatus of Borg
Makes it very difficult to troubleshoot. This was a good change.
P.S. I think I Love You.
With the major distros all moving to systemd, it's nice to see someone burn that bridge. I think if at least one top level distro was anti-systemd, then the drama would all go away, because the group that distrusts systemd could just go there. Someone quick spend your life forking fedora to a non-systemd thing. Pls?
Great work BusyBox!
Now if some of the desktop distros would listen to their core base and drop systemd as the default things would really be looking up for 2015 and next year.
That's not to say some of the ideas in systemd are entirely without merit. But the execution is entirely and utterly wrong. Maybe not for a version of Windows, but totally wrong for UNIX.
If given a choice, the user base stays with what works and quick adopts the better available alternatives. When forced they will look for the quickest out, seeing those that try coercion as a form of damage that must be rooted around.
The best thing to come from this is that the systemd crew have pulled much their code under one umbrella making it much easier to see which bits to replace. Now if they can try a little harder and embrace avahi and pulseaudio in the same way.
Wonder why so many other devs are so eager to put the systemd dick in their mouths.
I discussed that topic a bit in my journal.
Basically, systemd guys did a good job finding out what the init script writers wanted, at both RedHat and Debian, and giving it to them. When the init script writers needed something, they responded. Since the init script writers were the ones who decided if systemd got included in the distro, that was a good idea.
"First they came for the slanderers and i said nothing."
Generally, I've noticed that people are divided into two categories about systemd, depending on their viewpoint:
Those who like systemd almost always talk about features.
Those who dislike systemd almost always talk about architecture and design and code. The Unix way.
Systemd does make things easier for some people and some tasks, which is why it's been adopted. The problem is that it's ugly as sin from an architectural standpoint.
"First they came for the slanderers and i said nothing."
Systemd does make things easier for some people and some tasks, which is why it's been adopted.
Systemd is funded by Redhat, isn't it? How does it make server administration easier?
I've had to work with a Redhat 7 server at work, and all systemd does is force me to learn new ways to do the things I've been doing for years.
Systemd is funded by Redhat, isn't it?
Mostly, yes.
How does it make server administration easier?
I've never heard a server administrator say systemd makes things easier for them. There are probably some server administrators somewhere who will claim that.
Systemd makes things easier for people who write init scripts. Init script writers are the people who have primarily been responsible for its adoption in various distros.
"First they came for the slanderers and i said nothing."
Then there are people like me. I started using Linux back in the '90s, just to learn it. I ended up moving to Fedora with Fedora Core 6, and made it my main OS with Fedora 9. I can't say that I was thrilled with systemd when it came along, but I realized that it wasn't going away any time soon, and learned enough to work with it. At this point, I suspect, sooner or later every mainstream Linux distro is going to end up using it so if you want to work in Linux system administration you're either going to have to know something about it or find yourself stuck in a dead-end niche job.
Good, inexpensive web hosting
Systemd makes server administration a lot harder - almost a nightmare. There's no way to see how stuff is related anymore, while with init you could see it with a quick glance using ls.
And if you add your own stuff it's not easier, it's darn hard.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
I can't say that I was thrilled with systemd when it came along, but I realized that it wasn't going away any time soon
That's not much of an endorsement.
People who choose Linux do it because they appreciate a quality OS, well built and put together with care. That's why we like Linux.
If you don't care about quality, you might as well use Windows.
"First they came for the slanderers and i said nothing."
That's not much of an endorsement.
That's because it wasn't intended to be one. My personal opinion is that for the most part, it's a solution looking for a problem, but I'd rather learn to work with it than waste my time complaining, especially as I don't have the coding skills to do anything about it.
Good, inexpensive web hosting
The answer to the question no one asked.
Well I agree with your point that anyone who is afraid to learn to use systemd needs to have some sense knocked into him.
Learning how to use it isn't that hard, and I don't think you can make valid arguments against systemd until you learn to use it.
"First they came for the slanderers and i said nothing."
Besides being really Windows NT style rather than UNIX style, the rudeness and lack of empathy will kill systemd.
It isn't very technical? Why don't you use ReiserFS than? I still hear it is unmatched in technical quality in some aspects.
I have a problem with my debian server. The problem is that since upgrading to systemd, running fdisk causes the server to mount the partitions from the disk I'm trying to repartition. Even removing them from /etc/fstab doesn't prevent them from being mounted.
I did not have this problem before systemd and God alone know where the stray configuration causing this misbehavior lies.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
I think you've probably hit the nail on the head wiith your code review 9 comment, in that (it seems) systemd doesn't code to well-defined interfaces. One suggested correction to the above - this should not be "The Unix Way", but just "The Way".
I wonder if thsi topic would have been as controversial or toxic if the systemd people had tried to agree a new set of interfaces first with the community.
You never know what is enough unless you know what is more than enough. - Blake
The Linus Torvald's you know and love is but a figurehead puppet used by the open source conglomerates as clean shaven media representative. This man was born without birth certificates as part of a Middle Eastern slave harem and is commonly known as the Lunix Colonel.
The real Linus Torvald's has not left his mothers basement for 25 years. Nor has he shaved in this time. In March 1994 the Kernel was released as version 1.0.0 to celebrate Torvald's beard reaching 1 foot in length. 2 years later, largely due to a healthy diet of lutefisk they celebrated the milestone of 2 feet.
Unfortunately due to interference by corporate actors such as the Soviet conspiracy, Red Hat, the numbers became stagnated and no longer accurately reflected the true length of Torvald's beard. He was forced to trim.
This event caused Torvald's great sadness and resulted in him spiralling out of control into deep depression like parts of Mark Shuttleworth's Challenger spacecraft. He stopped showering for several years and this corresponding time period contained the greatest number of bugs in both the Linux kernel, and his beard.
The depression and lack of hygiene was contagious and spread to Open Source Wizard Richard Stallman who became known for his podiatric-auto-canibillia and was more likely to be associated with sores and sauce than source. The rival HURD kernel will never be completed as Stallman has forgotten how to program.
Torvald's mean while continued coding until his fingers bled, pushing code into his git under pseudonyms of various nerds around the world who paid the open source conglomerate to keep the sole Linux Mainframe online.
In 2011 Torvald's was able to wrestle control back over his versioning system and matched the released to the length of his beard for the 3rd time. This greatly improved the kernel and led to the development of some of the key technology of the 21st century: System D.
Seeing that his kernel was getting bigger, Torvald's began researching peer to peer Bitcoin block chains and Tor network services as a way to revolutionise the kernel for the first time since Al Gore invented the internet. System D was to use the one true linux mainframes hard drive to store pictures of Torvalds Penis, the system D version numbers were to reflect it's size at any time in some of the first research into Quantum computing versioning. After Jarrod from subway the initial angel investor due to seeing how this technology could be useful for his own interests, Google joined the project with the creation of it's D-wave computer - The first self contained and self replicating System D computer.
This caused a further rift between Stallman and Torvald's, as Linus had turned his operating system into a more advanced version of HERDs naming system. Many gnus were killed in the great battle of recursion.
In 2013 Torvald's beard had grown to a staggering 4 feet, as long as Eric S Raymonds was tall. This also marked the first time that Linux and System-D were the same thing as at the time Torvald's penis was 4 feet long.
Torvald's beard is currently approaching 4.3 feet long. He last had a shower this morning when he nearly got an erection and it is currently free from bugs.
People have found.
I know it's not the Slashdot way, but systemd discussions generate much more smoke than fire. Could people posting here please provide very clear links which show a real history of comments and preferably real code. The systemd guys have been under very specific pressure and so there should also be some tolerance of "overreacting too quickly"
Who found what bugs? with what software? who precisely responded? What exactly was incompatible? How did the distro makers feel about it?
As far as I can tell systemd has a few new neat features for normal users (show me the logs from the last day / boot etc) but is mostly pushed by distro makers. Since distro makers are the people who deliver Linux to the users and then have to fix the bugs they are pretty much the most important people in the community. If systemd is doing something they need then we need to either support it or provide an alternative which can provide the same things.
Systemd makes things easier for people who write init scripts. Init script writers are the people who have primarily been responsible for its adoption in various distros.
This. It seems everyone is forgetting that Linux is not a democracy. It's controlled by the people that write the code. This is largely true even if they work for companies like RedHat. Is there currently any alternative to systemd which is willing to listen to and handle the concerns of the init script writers? Particularly things like race conditions and init script bugs?
Judging from the diffs, system log integration is the most obvious consequence of the change.
He's removed the code that allowed syslogd to be socket activated by systemd.
72 lines of code.
Watch this Heartland Institute video
It's not an init system. It's a "system management framework", didn't you read the article?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Its all about the configuration files so you know what is related. "init" is an executable binary file so how do you see whats related? Sounds like you are victim of the misinformation posted by a lot of ACs about systemd.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
It shows exactly how they relate. Units have dependencies instead of just a sequence number. You can see exactly what depends on what.
Systemd is funded by Redhat, isn't it?
A good question is 'why is systemd funded by Redhat?' Sure they'll say writing init scripts is easier. But is that it or is there more to the story? I suspect so and believe it's actually the US government's plan to attack the Linux sphere. How? systemd makes the Linux ecosystem less heterogeneous. It puts much of the system under control of a single all-powerful and complex program. In other words, it introduces a single point of potential failure on all linux systems that adopt it. With almost certainty Redhat has covert CIA and NSA agents working for it. They have a building in Arlington for Christ's sake so given those agencies expressed concern over linux that is a no-brainer. It is very likely and reasonable to believe the real purose --- the one behind the guise of plausible deniable of writing easier init scripts --- is to infiltrate linux and introduce Heartland-style "bugs" that just happens to completely breach security. It is a conspiracy because I have no evidence. But it makes absolute sense and in fact would make little sense to expect agencies not to have infiltrated Redhat. The sum story is this scenario is plausible enough to seriously worry about it.
Systemd also makes things easier for software devs that do stuff further up in the stack. That is why everybody makes their software depend on systemd.
Systemd is king as long as there are no alternatives to enable e.g. running X11 (or wayland) server as a user. Or for moving the console code out of the kernel. Or to manage cgroups conveniently for software devs.
Systemd does solve some hard problems that developers tried to solve for literally decades.
The sad thing is that none of the self-proclaimed alternatives has even started to think about these.
Linux is controlled by money because its authors have been hired by commercial companies who control their employees. Red Hat management forbids to create competitive solutions, I speculate because Red Hat is partially owned by proprietary IT companties in a risk of FOSS competition.
systemd was created for containers. Containers are a quick&dirty way of packaging. Containers again come from the evil business side of Linux, no sane person would make that debugging nightmare happen.
have to know something about it
yep how to take it off, believe me you'd have to have quite a depth of knowledge of your system to achieve that. It could be the new interview question.
I remember dumping the prevailing operating system and leaving a job that demanded that I continue using it. I considered that the dead-end job and linux was the solution. Here we are again. Lots of dogs barking but the caravan moves on.
I really would like someone to post a pros and cons for systemd vs init and a real in-depth review comparing both. So far I've seen nothing other than some fanatics on both sides. I'm completely indifferent about systemd vs. init right now for the desktop or server. So far I've been able to learn the commands and make my own startup scripts without much hassle.
Well I agree with your point that anyone who is afraid to learn to use anal sex needs to have some sense knocked into him.
Learning how to use it isn't that hard, and I don't think you can make valid arguments against anal sex until you learn to use it.
Do you see the problem with your statement now?
Since the systemd my Linux desktops have become faster, more reliable (init.d for instance had no service watchdog), the logging infrastructure is nicer to use, and significant amount of resources have been released. Why on earth any distribution really would want to go 15 years back? That would be suicide for the distribution.
That makes no sense at all. Systemd programs are also executable binary files. And init uses a text based configuration file. Beyone that I have no idea what point you're trying to make.
SJW n. One who posts facts.
It's always good to see mature professionals make decisions for solid technical reasons.
Years? How about decades...
Now when you say "Redhat 7"... I hope you're referring to RHEL 7 and not "Redhat 7" (a.k.a. "Redhat Linux 7").
Redhat 7 was back in 2000 running the 2.2 kernel while RHEL 7 was released in 2014 running the 3.10 kernel.
I still have some old Redhat 6,7, etc CDs laying around from back in the day, so just popped in my head when I read your post.
I doubt if everyone who jumped aboard the systemd cargo ship really knew the journey they were in for. Some of those travelers started to regret their ticket purchase when sudo was eaten up by systemd. And others... well it will take a bit longer to realize their fate.
Mature professionals are not swayed by the latest coolness. In contrast they are strongly aware of risk and liability, and working with an uncooperative supplier introduces both, as well as unpleasantness and annoyance at work.
Oh, a framework.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
You're looking at trees, when you should be looking at the forest.
ffs, init was 20k LOC systemd is now 100+ bins and 430k LOC. Before systemd you had a log file that was text and parsable using the commands that are core to unix (or specialized applications/services to injest them later), after systemd you have a binary log that mind you has code controlling it that can choose to destroy that log if it finds it is unreadable or corrupted. Init was special purpose and streamlined to do one task well, systemd is coupled to auth, dbus, vm startup and shutdown, vm management, privilege escalation, ....
No one is complaining about the features of systemd, everyone is complaining about the design of those features that is reminiscent of MS architecture and design (that even MS has started to run away from). Poettering has stood in front of rooms full of people and flatly said he does not care about posix or unix he wants to build something new. He is -- hes building a monolithic userspace kernel and RH is using the init functionality to shoehorn itself into a controlling position.
Because of the way systemd/XDG/pam/dbus are designed, the more he extends it the more other core bins on the system will need to integrate with it or rebuild functionality that has been displaced by it for no reason. It is a loss lead development and it will me Linux's loss in the long term.
It's only by looking at them one at a time and drawing the relations in some external tool that I can figure out how they are related.
It's like going back to stone and chisel to do filing.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Surprisingly redhat sells consulting, so it may not be too paranoid to think that the systemd exists only to make things more complicated so even the old beards need to buy consultance.
Systemd makes things easier for people who write init scripts.
And for people who want to define event based daemon control
And for people who want to read through log files without having to become regex experts.
And for people who don't want to switch to 100 different tools to run their computer.
Mind you few people will ever say a system is easier if that system is new and requires them to read a man page. Change is never easy. The only acid test would be sitting a few people who've not used linux before in front of both systems. Then you can determine which system is easier to administrate.
Commit Message:
systemd people are not willing to play nice with the rest of the world.
Therefore there is no reason for the rest of the world to cooperate with them.
Signed-off-by: Denys Vlasenko
http://webcache.googleusercontent.com/search?q=cache:eoce3kM0y_gJ:git.busybox.net/busybox/commit/%3Fid%3Daccd9eeb719916da974584b33b1aeced5f3bb346+&cd=1&hl=en&ct=clnk&gl=uk
"And for people who want to define event based daemon control" sigaction.
"And for people who want to read through log files without having to become regex experts." ??? So people who just scan the entire text file and do a search in their viewer program could only do so with systemd? And here's me thinking that even vi allows a simple search on /var/log/message ...
"And for people who don't want to switch to 100 different tools to run their computer." Hyberbolocks. NWOR. Try not going all hysterical next time and maybe you won't look like a moronic tool.
Also with regard to systemd, I really do like distros that have it in my virtual machines because I can do a full reboot in seconds, whereas other distros take much longer.
I don't know how the hell you borked the init systems, but booting VMs is so fast that I always have prompt as soon as I have console output up which is around 1s after the virtual BIOS. If you have trouble during shutdown the speedup isn't even desirable. I'd rather have my apps save data than and shut down than be killed and loose data. At least they pulled that 'feature'.
Maybe the problem is the distro used: RHEL and SUSE pre systemd are slow as hell while Debian 7 boots as fast as I have described. Which is even a little slower in version 8, because the first terminal spawned is a little buggy. Hurra for dynamically spawned ttys to save memory. A nice example for solving a non-problem with a complex solution and breaking lots of stuff.
Or just read the posts on ssh restart behaviour. Be true to systemd style and break remote sshd updates or make an exemption in behaviour to appease sysadmins.
The thread referenced above is worth a read. I wish I had mod points to recommend it.
Good. Let more projects follow suit.
Busybox has no business supporting systemd. Busybox is designed to be as lightweight and as portable as possible, with only the bare minimum of dependencies.They shouldn't have included support for systemd, in the first place.
This is trivial to do with systemd-analyze. systemd-analyze dot | dot -Tsvg > systemd.svg.
Its all about the configuration files so you know what is related. "init" is an executable binary file so how do you see whats related? Sounds like you are victim of the misinformation posted by a lot of ACs about systemd.
Sorry. But configuration files don't beat scripts. If you need an option that isn't there: Tough luck. If you need to handle something differently: Tough luck.
It is like working with a GUI. You can only work with the stuff presented. If I look at the init systems at my disposal the dependencies are also declared at the top of the file and resolved (either at boot, or per 'precompile').
Init scripts are more powerful configuration files and I trust my distros maintainers or myself to provide the necessary init files. To that matter: I prefer a central repository compared to the jungle some systems offer.
Commit was removed 5m ago. Systemd may be successful at bribing busybox as we speak.
Just an anecdote: during a recent upgrade from Debian Wheezy to Jessie, the first boot into the new system failed with a message from systemd about mtab not being a link into /proc/something (a trivial problem as far as I can see).
Can't remember the exact message from systemd, but it was something about being "frozen"
No going into single user, nothing, just F... you and go reboot on the CD image. Happy enough that the machine was on my desk...
And they wonder why many people don't like systemd....
What SystemD is doing is a good idea, it's how they're doing it and their attitude. They seem to have the mindset of Devs and not sysadmins. Windows is an example of an OS by Devs. It's death by a thousand cuts. You can't quite pout you finger on exactly what is wrong, but there's a whole lot of small issues that amass into some real annoying rare cases that don't affect most users, but should never happen in the first place.
LaunchD has existed for a long time and is fully opensource and well tested. It has gotten the run-through with iOS which needs to be easy to use and work reliably in some very complicated environments, like cell phones. Of course there is the very strong "not invented here" mindset that a lot of GPL people have. Comparing SystemD to LaunchD is like comparing btrfs to ZFS. The most annoying mind-set that I've seen from the SystemD people is the whole "if everything is working as expected, this situation should never happen, so we may as well not handle this situation". How I hate that. If you know about a failure case, handle it! I hate that "limp along and some time later, fail in some unrelated way that gives the wrong impression". Works great when it works, but the failure cases are a mess.
Did you know that both LaunchD and ZFS had numerous old-school Unix people working on them in all stages of development? These are people who grew up using and managing mainframes and many now make a living managing datacenters. Who would you rather having designing the critical infrastructure of your OS. A sysadmin dev hybrid programmer who grew up learning exactly why things are designed the way they are, or some wide-eyed dev who likes flashy things and assumes the wisdom of a sysadmin is just the rantings of some old person?
Mind you, I'm a fairly young person that loves flashy things, plays AAA video games, and watches anime, not some neck-beard.
"And for people who want to define event based daemon control" sigaction.
Yay another tool.
"And for people who want to read through log files without having to become regex experts." ??? So people who just scan the entire text file and do a search in their viewer program could only do so with systemd? And here's me thinking that even vi allows a simple search on /var/log/message ...
So I don't want to manually search a text file and your answer is that I should use another tool to manually search a text file? An editor no less reading a continuously changing file?
"And for people who don't want to switch to 100 different tools to run their computer." Hyberbolocks. NWOR. Try not going all hysterical next time and maybe you won't look like a moronic tool.
You're right. I stand corrected. After your comment here I realise the error of my ways as there are now 102 tools which I can use.
Systemd will likely be the nail in the coffin for our Linux servers, and push me into just going with Windows. There are already enough little issues with Samba that the pain isn't worth it.
Dependancy and target based startup is not a bad idea and can be useful in many scenarios. Its probably not necessary to start many services, though many admins can benefit from the feature where needed and it can actually make administration easier. Since SystemD provides Sys V init, and backwards compatability, the criticism of systemd is a bit overblown as people can simply use system v init features on systemd if they want. The integration of cron, syslog and init was important for being able to launch a service dependant based on say another cron event occuring. There are better ways to do this however using a decentralized model using well defined IPC bus interfaces and protocols allowing for the functionalities to be in seperate processes but allowing processes to communicate with each other, and each a user swappable components as I will describe later. There is no need to have one big monolithic process or poorly understood components which are not swappable and do not communicate using well understood and documented protocols that can facilitate users swapping out components.
I doubt that systemd would be as big of a controversy as it is if the additional functionality was added but not heavily used all over the place for most of the services on the system and the distribution had not felt the need to convert every single service to the new type of init file. Its sort of like people who think they have to use every single C++ feature when C++ is not intended for that, its a bag of tools where the programmer is supposed to choose the tool they need, rather than something where the programmer is supposed to use every single last tool. Instead, the distributions who adopted it felt the need to convert most services over to the new init file format. This created a very much so in your face kind of obtrusiveness that was easily noticeable by many. It was unnecessary in many cases as dependancy based startups can stil even be triggered from System V style initializations. Since systemd supports SysV startup, the majority of init files could have been left in SysV format which would have avoided much controversy. Another possibility is to offer init files in both the old and new formats so people can choose which one they desire.
I believe in a mechanism not policy approach. Systemd's own model of dependancy init are useful in some cases however, are probably overkill for other services. The features should be there for those cases that people may need to use them. Systemd does allow users to the flexibility to use sysV init so the fact is for starting your services you can always have the started from sysV scripts even on Systemd. Ive done it and works fine.
Many complain about the all or nothing approach of systemd. An init system like this should be built around IPC bus, using well defined protocols, interfaces and message formats which are extremely well documented to the public. This way we can get the dependancy based start up, while giving admins complete control and allowing the init system to be built from swappable components. Lets say we wanted to have a daemon started after 5 conditions are fulfilled, 3 other daemons started, the network interface up and 5 minutes elapsed from system boot. The init components that start the 3 prereq daemons would produce IPC bus messages as each of those are started. The kernel would generate a bus message when the network interface would go up. You could write your own init daemon that would watch the bus for all of these events and would also set a 5 minute timer as well, it would keep track of all of these events and when all of them are fulfilled it could then start the daemon and would announce on the bus that it it doing so.
This would allow you to write drop in replacements yourself for any part of the init system. The bus interfaces would all be well documented so you could write your own python script if you wanted to watch the bus for events and be able to start a daemon or process when you see the prerequisite events on the bus. Th
Red Hat paid for the development of systemd because their high-paying customers (probably IBM chiefly) wanted a systems management suite like SMF. For companies like IBM and Google, deploying a million virtual servers every day, having faster boot times, not having to craft init scripts, etc. are worthwhile features. There was no conspiracy to destroy the other init systems--Debian, Ubuntu, SUSE, Arch, and the others have merely found that systemd is easier to develop upon than SysVinit or Upstart, since it automates a lot of the maintenance routines that SysV pushed into user space.
And produced within the past 3 years that would not run anything larger than busybox acceptably and still have room in its flash for the rest of the device-specific applications necessary.
Furthermore, as musl-libc proves, there is room for improvement in both standards compliance as well as memory/disk usage. musl managed to produce a libc that not only provides better standards compliance in most cases than glibc, but be dramatically smaller (1/6th or less the size of equiv glibc so/a files), have proper posix thread error reporting, have equivalent dlloader support to glibc, and work with all compilers back to 2.95.3 or earlier (it requires 3.4 or later to compile due to C99 compliant features, but will compile apps supporting 2.95.3 just fine.
Users are the most important people. No users mean no distro and no distro people. But take away the distro and users will just find another or another os.
systemd is not for users or for admins. It is only for distro people. They want to push the work of packaging software for their distro to the people writing the software. They are lazy.
Also, a few corporate monkeys at redhat are willing to screw millions of people over with shitty distro so that their docker/container stuff will boot a half second faster. That is what systemd is all about.
I think there there should be RedhatOS and other distros should be real Linux - i.e. Linux without systemd.
I'd give you mod points if I had them.
While it I'm not the one to give you an in depth pro/con, I feel like systemd is more appropriate for the workstation/desktop/laptop. When it comes to the server, I really like the mantra "do one thing, do it well." Servers are multi-faceted machines in that sense. A service fails, just restart it -THAT- service. Systemd fails, restart the server. Silver lining: it should boot up faster.
Chewbacon
The Bible is like Wikipedia: written by a bunch of people and verifiable by questionable sources.
GNU, BSD, Linux, et cetera became ubiquitous because they all offer lots of choices. Minimal, text-only OS? Sure. Fancy GUI with special effects? Sure. Headless? Sure. A single, simple ethernet connection to the world? Sure. A multi-interface, multi-homed, routing, NAT and firewall setup? Sure.
Try to take away people's choices, and you're going to piss people off. I don't even run GNU/Linux, but I'm pissed about the mess that is being made to open source software. Now we're going to have to come up with a label for software that depends on systemd, like "systemd encumbered", because it won't be compilable on any other operating system.
systemd started as a port to launchd over from BSD architecture to SysV. Most of your comments lack foundation. Systemd has the capabilities of launchd. As far as failure cases the people pushing systemd the most strongly are the people who run the most sophisticated date centers and cloud OS installations that run the internet. The people opposed are mainly people who manage dozens of servers and came up in the Ubuntu years post Unix. So your facts are simply off.
As far as failure cases the people pushing systemd the most strongly are the people who run the most sophisticated date centers and cloud OS installations that run the internet.
I don't think that's true lol.....you are the only person in that category I've ever seen who favored systemd. And from what I gathered discussing it with you previously, you only like it because of features you hope will eventually make it into systemd (features which I think will never make it, but that's predicting the future so who knows).
"First they came for the slanderers and i said nothing."
System boot time is only important if the system is booting frequently.
Such as a laptop that's booted for fifteen minutes between boarding the city bus and transferring to a different bus.
The posts were people are wrangling about whether Sytemd is workable or ran by asshole devs as opposed to asshole sysadmins etc is the one of the problems with Linux at large. The problems with Linux like this, are the reason that Windows as crappy as it has become, as nosy as it have become, and generally onerous, is still in control of 90% of desktop computers. The ONLY place Linux in ANY FLAVOR has reached critical mass is via Android which is Google's custom flavor. I would love to have an alternative to windows and apple. Yet, because you all still haven't got your act together, I am stuck waiting for Google's chrome os. smh
> the people pushing systemd the most strongly are the people who run the most sophisticated date centers
This kind of dismissive attitude is a classic example of the systemd problem. It's fanboys just baselessly assume that anyone who's not on board is "just an amateur". Both parts of that are quite wrongful. That includes the assumption about the experience of critics AND the idea that the "amateurs" don't matter.
If Redhat wants to build "pretentious cloud Linux" they should just do that and leave the rest of Linux alone.
A Pirate and a Puritan look the same on a balance sheet.
In the ideal dependency-oriented init, where would you recommending that "service A requires service B" information be provided? In file names?
And they give exactly the worst problem with systemd as a reason: The people behind it. These people are not part of the Linux community, they are a hostile invasion force.
Of course, there are numerous technical problems with systemd, but the simple and clean way to address them is to just not use it.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Well said.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
It is really a surprise, yes. Maybe some new == better stupidity. For the Debian technical committee it is quite clear however: They have been subverted by people with connections to Red Hat.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
There definitely are many people who claim to be systems administrators who claim that systemd makes their job easier. I expect that for certain, perhaps many, use cases it's true. That is shouldn't be true for all use cases is hardly a surprise.
I've seen this put "One size doesn't fit all."
And BusyBox is aiming at SMALL computers. So systemd is probably not even usable by many of their target audience. And for most it's probably unreasonably excessive overhead.
I think we've pushed this "anyone can grow up to be president" thing too far.
Systemd definitely makes sysadmins life easier. No longer do you need to maintain separate init scripts, log maintenance scripts and a tool like supervisord to maintain/restart failed jobs. Systemd does all this in a single config. Having said that I think systemd's implementation is kind of questionable, not really a fan. But the vitriol against it is overblown because the grey beard community hates change.
I mentioned my frustration at having to learn a new way to manage my systems along with my acceptance that times change and knowing my skills have to be updated in turn. I mentioned this to someone who admins a system we use and he said that he appreciates systemd.
I replied, "oh, so you're the one!"
I don't feel like I have the expertise to judge the fundamental issues for or against systemd. I do feel like it's in the best interest of an admin to learn how to use the systems likely to be encountered, regardless of personal preference.
B) Eliminate all the stupid users. This is frowned upon by society.
Rewriting scripts into more powerful and flexible C libraries is also a central part of UNIX. Add some markup so you can do dependency resolution, support for cgroups and parallel startup, and you have either OpenRC or Systemd. OpenRC admittedly is more of a work in progress.
Systemd takes the position that, because the key component in process management is Linux-specific, it's okay if the service manager is Linux-specific too. Having an OS-independent service management layer was seemingly a bad idea, since most of the major UNIXes have replaced it. In point of fact, cgroups are only the latest version of process tracking in Linux, because pidfiles just aren't a substitute for kernel-level features that guarantee that processes are what they say they are with the resources they say they have.
The failures of SysV init are as much political as technical: pretending that SysV was a one-size-fits-all solution just pushed the maintenance problem onto the distro maintainers. The distro maintainers are maintaining Linux, not UNIX, and fragmentation doesn't hurt them -- quite the opposite. So in a few years the big players' existing practices will be codified as The New Standard, the smaller vendors will grumble and implement it, and everything will be fine until the next new OS/feature comes along.
Have you learned anything else about technology in the last thirty years, or just shell scripts?
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
I administer a whole host of Linux boxes and some of them are servers. Of course, that's just a half-rack leased for my own use and my own, personal, systems. Honestly? I learned a few new commands. Meh... It hasn't hurt anything at my end. I don't stray too far from the roost though, so it's pretty much out of sight and out of mind for me.
Of equal importance is to note that this reply is from someone who spends the vast majority of their time in userland (though, almost certainly, with a terminal open and usually doing something via remote). Also important is to qualify the below by reducing the importance to consider that I'm not to be confused with a professional. Having said that...
Truth told, I've not noticed it helping anything that affects my use patterns. It hasn't hindered anything, either. I've had nary a problem. I kind of want to fit in and say how I hate it, how it's not the Unix Way, and that it's too bloated, too complex, and the ruination of all the distros I know and love. Actually? Meh... I'm not really impacted, in the least. I guess it makes the dev's live's easier (for the distro packagers, at least) and I tend to donate to a few of them so, by extension, I guess you could say that I'm getting a bit more (theoretically) bang for my buck?
Mostly, I just watch and see what's going to happen next. Someone did a huge, academic-style, write up on it. It took me a minute to dig it out of my browser history on a networked box (long story - I'm still not home) but I was able to find it for you. I think, I'm not sure, it may have been on Slashdot? Anyhow, if you've not seen this then this makes an EXCELLENT read:
http://blog.darknedgy.net/tech...
In the end, I've concluded, I just doesn't seem to matter to me - yet. It doesn't really impact me. I'm sure that it does others but, for me, it just works. I want to hate it. I want to be in the cool crowd and rage against the evils of the domineering Red Hat and crew... I want to be enraged enough to key cars, throw bricks through windows, or at least post vile, spittle speckled, angry posts on the internet but it just hasn't bit me yet. Maybe when it does? I'll start my brick collection, just in case.
"So long and thanks for all the fish."
The sum story is this scenario is plausible enough to seriously worry about it.
WTF? Seriously? Dude... Erf... I don't even know where to begin.
You can't quite pout you finger on exactly what is wrong
I think I could Poett my finger on what's wrong.
On the SE sub AskUbuntu we had a person who wanted to get network status and needs to rely on systemd to do so, or so it seems - I couldn't find any other way to do so programmatically. They didn't want to actually poll for output but insisted (and restricted) that their script rely on an outputted signal rather than poll for a status. (Sorry, I'm not a great programmer so my verbiage may not be adequate.) Try as I might, I was unable to do so within the limits of a script.
I'm not sure where I'm going with this - I don't see this as a bad thing. I just do wonder if there may end up being limits in the future that actually impact customizations. As stated above, I don't dislike systemd - yet. I doesn't really impact me, much or at all. Eventually he allowed for polling. I did think about banging a quick app out in C that did the polling and then pushed it but that just seemed silly as his goal was to avoid compute cycles. I could have used the practice, anyhow.
No real point, I guess, except that there may come a time, in the future, where it's time to get out the pitchforks and torches. We've not yet reached that point, to my mind, but should probably keep a barrel of heated pine pitch and the fork tines properly sharpened. You know, just in case.
"So long and thanks for all the fish."
Why has nobody written a tool to view the binary log? Just 'cause it's binary doesn't mean that it can't be done - does it? I'd think that someone would do this. Maybe I'm missing something here but this doesn't seem insurmountable. If I gotta do it myself then, well... You don't want that. I'll put Clippy in it, probably by accident. However, if this were a problem then I'd think someone would have resolved it. It's not like we don't already have tools to open, edit, and even change binary files - I'm sure there's a format that they're using to make them. Dunno it but I'm guessing there is. It seems that if this were a problem then someone would have proposed and created a solution. (And that is the Unix Way, by the way.)
What am I missing? I'm guessing I'm missing something because it seems fairly obvious to me and like I could probably spend a while doing some research and figure out how to parse those binary error logs even if it means some form of extraction must occur prior to parsing them. They make hex editors. It seems that one could create a plug-in that automagically formatted the data or even just write one with that included as its primary function?
"So long and thanks for all the fish."
One suggested correction to the above - this should not be "The Unix Way", but just "The Way".
Yeah lol, lately I've been thinking that "The Unix Way" can be easily summarized as, "Write Good Code."
I wonder if thsi topic would have been as controversial or toxic if the systemd people had tried to agree a new set of interfaces first with the community.
I don't think it would be as controversial, because if they had been thinking in terms of interfaces their code would have been drastically better.
"First they came for the slanderers and i said nothing."
There is some good discussion in the links of this journal entry.
The cons are mostly architectural, for example, Gnome shouldn't depend on any particular init system........tying them in like that is too brittle.
"First they came for the slanderers and i said nothing."
SOMEPeople who choose Linux do it because they appreciate a quality OS, well built and put together with care. That's why we like Linux.
Not all of us. In fact, there are some things that I honestly feel are lesser quality than I can get with other operating systems. I use Linux because I like to tinker. I use Linux not because it is perfect or easy but because it is imperfect and can be made difficult. I like to learn, to poke, and to grow. I use it because I enjoy the freedoms and customization opportunities. I use it, not because of its quality, but because of its imperfections and those imperfections give me reasons to explore and play.
There are lots of inferior things in open source. There are lots of superior things in open source. I think your statement is too generic and overly broad. Oddly, I usually agree (almost entirely) with you. I've poked at distros that lacked quality and were not built with care. I stuck with them (often for quite a while) just to see if I could make it into something that worked for me. And yes, I include the distro with the kernel - nobody runs just the kernel.
"So long and thanks for all the fish."
This is correct.
In addition, all of the features that the systemd people have been plugging could be easily done before systemd. Some of those features actually already exist in the programs that systemd tries to replace but are turned off by default. They are turned off by default because there are inherent tradeoffs with those features that are best considered by the user on a case-by-case basis. In other words, the safest, most general purpose configuration is to have those features turned off.
Do people really believe that nobody had ever previously thought of starting stuff in parallel to speed up the boot process? Were you aware that it is not difficult to do exactly that with the existing init/rc script systems?
I have no problem with Redhat making whatever kind of tools / modifications they want that don't violate the GPL. What I don't understand is why so many veteran project leaders, (even Linus,) caved in to demands to change certain things to facilitate a project that breaks the safest, most general purpose configurations. I have been using Linux since before kernel version 1.0.0. I don't remember anything breaking backward compatibility in the Linux world on a scale even remotely like this before. Linux distributions generally don't change things just for the sake of change. They require that the new thing is significantly better than the old thing before including the new thing in a default configuration. There is something unprecedented about systemd and probably something sinister about the way it is being pushed. Maybe it is just that big money has finally realized that Linux is really important and it has thereby attracted the sociopaths. I am very glad to see that Busybox has decided to not support it.
Bravo for common sense.
some of the comments are worthy of comment.
http://developers.slashdot.org/comments.pl?sid=8258597&cid=50840843
^Redhat was "ok" until 7.3. Many, including myself, abandoned it at 8.0. They are Microsoft wannabe's. That was when we found out.
http://developers.slashdot.org/comments.pl?sid=8258597&cid=50840903
http://developers.slashdot.org/comments.pl?sid=8258597&cid=50840959
^ The fact is that systemd strives for basic control of the rest of whatever Linux system is affected by it. The binary logging issue is an obviously intentional distraction. Busybox got it right.
If systemd is sofa king great... have a systemd distro. One. If it is so outstanding.. people will flock to it in droves. Now why is this shitstain pwnd being pushed on other distros? Find that out you will find some lying fucks.
http://developers.slashdot.org/comments.pl?sid=8258597&cid=50843055
^ This is an emotional response regarding the attitude of systemd folks and Redhat. Yep. They are dicks. This is not news. Again, Busybox is right.
http://developers.slashdot.org/comments.pl?sid=8258597&cid=50840695 ... for an AC. That is like trophy shit on Slashdot now. Why 5? It is total shill. That AC said "That's not to say some of the ideas in systemd are entirely without merit. " ... while saying "But the execution is entirely and utterly wrong. Maybe not for a version of Windows, but totally wrong for UNIX.". Am I hypnotized now? No. systemd is precisely control freak thinking. It should be deleted from all distros and let Redhat lose it's users in droves. Natural selection. Look up the definition of shill.
^ This got modded to 5
http://git.busybox.net/busybox/commit/?id=accd9eeb719916da974584b33b1aeced5f3bb346
^ Every dev of every other Linux distro should print that out and fasten it to a wall above their monitors in font size 10,000+.
There is no believable overt incentive for any distro to absorb systemd into their code.
There was a factual statement made. That factual statement was false. And as an aside I didn't say the opponents were amateurs I said the opposite. But I did deal with the reality of where the center of opposition is.
That is a good blog post.
Maybe the greatest legacy of systemd will be to spark a world-wide discussion about what a proper startup manager should look like.
"First they came for the slanderers and i said nothing."
Linux is controlled by money because its authors have been hired by commercial companies who control their employees. Red Hat management forbids to create competitive solutions, I speculate because Red Hat is partially owned by proprietary IT companties in a risk of FOSS competition.
systemd was created for containers. Containers are a quick&dirty way of packaging. Containers again come from the evil business side of Linux, no sane person would make that debugging nightmare happen.
RedHat was backing Upstart, a Canonical project. Systemd was started by RedHat developers working without the direction of management, it was forces external to RedHat who actually got RedHat on board with Systemd.
I did an Internship with RedHat years ago, I don't know how they compare to other open source companies but in my experience they give their developers a remarkable amount of autonomy.
I stole this Sig
> Mind you few people will ever say a system is easier if that system
> is new and requires them to read a man page. Change is never easy.
Many people change when the new tool is better, even if it requires learning new ways of doing things. Many new and improved tools make a serious effort at backwards-compatiblity to make the transition easier (systemd does not do this). That's why, for example, many people switched from syslogd to rsyslog or syslog-ng. why many changed from ncsa or cern httpd to apache. why many changed from csh to posix sh (or bash or ksh or zsh). Many of these people who have gone through all these changes and more are the same people complaining about systemd, so their objection is clearly not because they are afraid of or too lazy to change.
> The only acid test would be sitting a few people who've not used
> linux before in front of both systems. Then you can determine
> which system is easier to administrate.
you are making the classic mistake of confusing 'easy to learn' with 'easy to use'. nano is an easy to learn editor, but hard to use for complex editing tasks. vi is moderately hard to learn but extremely easy to use once you've learnt a few basic things about it.
"And for people who want to read through log files without having to become regex experts." ??? So people who just scan the entire text file and do a search in their viewer program could only do so with systemd? And here's me thinking that even vi allows a simple search on /var/log/message ...
So I don't want to manually search a text file and your answer is that I should use another tool to manually search a text file? An editor no less reading a continuously changing file?
Seriously someone who doesn't know how to use tail -F or cat and grep should NOT be admining a Unix based system.
I thought you might appreciate it. I'd actually thought of you when I read it but never remembered to share the link with you. I've been reading your review, after all. I'm not entirely sure that the author is unbiased but, again, I'm not really sure that I'm qualified to opine. At least, no, I'm qualified to give an opinion but it shouldn't be weighted a whole lot. It's not self-depreciation. It's an astute awareness of my skill level and familiarity with the topic. *grins* It's also better to admit that I don't know and to then learn than it is to pretend I know and not have someone give good instruction or correction.
Strange, I know... It works for me, however. Hell, I don't even mind the Grammar Nazi trolls. They help me to improve my writing. ;-)
"So long and thanks for all the fish."
Red Hat's new strategy: embrace, extend, extinguish...
I don't see why you can't just set the service to start after the network is up. Hell, that's a simple sysvinit thing, an iirc, systemd supports such a thing. Admittedly, I've not been on a Red Hat system in quite a while, as my primary concentration has been focused on debugging Android related issues, so I'm behind the curve, on systemd, these days.
Or I could just open a file in gedit.
You are demonstrating the biggest advantage and the biggest downsides to Linux at the same time. The rich and widely available different ways to administer the system, and the self important douchbags in the community who believe their way is the one true way (tm).
I can't help but thinking back to the basic differences in the system. Logging: using simple commands to extract exactly the relevant logs at the relevant priority from a logging daemon vs borderline regexing your way though text files (if you're lucky and the file hasn't been rotated into gzip document). Controlling a daemon: a simple config file with a handfull of directive words vs writing an entire bash script which among other things juggles PID files. Controlling a daemon: simple commands vs hoping your script file that doesn't even understand if a program is running or not.
I think people's view of systemd is clouding their judgement on how easy or hard it is to use. I do understand a lot of arguments against systemd, but the thought that it's harder to use than the alternatives we currently have is laughable. Experience is clouding judgement. For me VI is easy to use because I have learnt to use it. I see a lot of the same arguments applying here.
No real point, I guess, except that there may come a time, in the future, where it's time to get out the pitchforks and torches.
You could make the same assumption about every program ever created. Change is rarely feature complete at a time when the first versions are rolled out. I understand a lot of people have a desire to do something and are getting knocked back with requests to the systemd developers. But at this point rightfully so. Any project at this stage in development but carefully prevent feature creep. When a system is fundamentally stable and feature complete, then it can be expanded to start including edge cases.
What I'm trying to say is that in the future you may just be able to do what you want rather than thinking of pitchforks and torches.
With you except for the reference to btrfs and AAA video games. Whatever its technical merits or shortcomings, btrfs has yet to achieve the level of "integration" of systemd. You can happily run most modern GNU/Linux desktops without it. While some distros are using some of btrfs's more advanced features, these tend to be optional and extX remains the system default for practically all distros. Contrast that with systemd, which has its footprint in practically all the major distros released within the last few years.
It's only a little, lightweight framework. You worry too much.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
What SystemD is doing is a good idea, it's how they're doing it and their attitude. They seem to have the mindset of Devs and not sysadmins. Windows is an example of an OS by Devs. It's death by a thousand cuts. You can't quite pout you finger on exactly what is wrong, but there's a whole lot of small issues that amass into some real annoying rare cases that don't affect most users, but should never happen in the first place.
Please provide at least one example.
What you say is just an opinion by someone who, from my point of view of 20+ years of Unix administration, doesn't understand anything of what he's talking about and is spouting BS he read somewhere else.
The small issues amassing in real annoying rare cases are sth that always existed on any OS, but you seem to say only systemd is causing that.
So what you're saying is clearly BS.
LaunchD has existed for a long time and is fully opensource and well tested. It has gotten the run-through with iOS which needs to be easy to use and work reliably in some very complicated environments, like cell phones. Of course there is the very strong "not invented here" mindset that a lot of GPL people have.
You don't even understand the GPL and what it's for, so your case is getting even worse. You sound like a proprietary software shill, not like someone who understands Linux, and therefore not as someone legitimate to talk about systemd. FYI, launchd is one of the init that have been studied before making systemd.
Studied by people that actually understood the GPL, Unix (BSD and System V), and Linux. At least far better than you ever could.
Comparing SystemD to LaunchD is like comparing btrfs to ZFS. The most annoying mind-set that I've seen from the SystemD people is the whole "if everything is working as expected, this situation should never happen, so we may as well not handle this situation". How I hate that. If you know about a failure case, handle it! I hate that "limp along and some time later, fail in some unrelated way that gives the wrong impression". Works great when it works, but the failure cases are a mess.
Oh my god! Thankfully you don't do systemd administration. FYI, the kernel works just like that! Systemd is tailored for Linux, and it shares lots of its design.
If your memory is physically malfunctioning and corrupted, the kernel (and systemd) is choosing to not do anything about it, and not handle it, because they decided they can't, and prefer launching a kernel panic (or a systemd halt)! That you hate that just means you hate Linux and systemd, but some people like me find this a legitimate and sensible choice and will continue to use both.
Did you know that both LaunchD and ZFS had numerous old-school Unix people working on them in all stages of development?
Did you know there was a problem with the licences of both and the GPL? Did you know that LaunchD and ZFS were not made for Linux?
These are people who grew up using and managing mainframes and many now make a living managing datacenters. Who would you rather having designing the critical infrastructure of your OS. A sysadmin dev hybrid programmer who grew up learning exactly why things are designed the way they are, or some wide-eyed dev who likes flashy things and assumes the wisdom of a sysadmin is just the rantings of some old person?
In the case of a free GPL OS like Linux, I would not want any of these sysadmins touching Linux infrastructure at all. People trained in proprietary buggy Unix OS, no thanks! People that couldn't to this day do better than the GNU OS? No thanks!
Now, if the sysadmin dev hybrid programmer who grew up learning exactly why things are designed the way they are was actually working on Linux, yes of course I would chose this one. Oh wait, that's exactly who Lennart Poettering (the one that launched systemd) is!
Mind you, I'm a fairly young person that loves flashy things, plays AAA video games, and watches anime, not some neck-beard.
Don't worry, it shows in what you've written. Fortunately, the one developing systemd and Linux are not like you.
>And for people who want to read through log files without having to become regex experts.
There is no reason to use regex at all to read and parse log files. If you do, you gain a bunch of abilities that can save a lot of time - but nothing you do with regex's could not be done without them.
More-over, if you do NOT use regex's with journalctl then you can't get those features EITHER -the people who do want those features learn regex anyway.
>And for people who don't want to switch to 100 different tools to run their computer
If you don't believe that 100 different tasks require 100 different tools - you should not be using a unix like system in the first place. Go run windows, it's DESIGNED specifically for the purpose you just stated.
Trying to hack that design onto Linux is in and off itself terrible because it's completely incompatible with how the entire system was designed, evolved and developed. It's a major pain to all the people who did that evolving, designing and developing and could very well lead to a major exodus of them away from what they see as a terrible design - and that loss would kill the linux ecosystem.
Do one thing and do it well became a principle for very, very good reasons - it's a superior design both in terms of technical merrit AND user-friendliness. Since the very beginning there have been those who have been convinced they knew better, and each and every one of them has failed dismally.
While Unix has been going strong thanks to the flexibility, scalability, portability and reliability of that design since 1969. It's the single most long-lived design in the history of software - because it works for anything and everything you can throw at it.
Unicode killed the ASCII-art *
I've never heard a server administrator say systemd makes things easier for them. There are probably some server administrators somewhere who will claim that.
Systemd makes things easier for people who write init scripts. Init script writers are the people who have primarily been responsible for its adoption in various distros.
Your problem is right there: init scripts writers are server administrators, even the most seasoned one. That's why you never heard a server administrator say systemd is easier, that's because you can't recognise one when you see one.
Or I could just open a file in gedit.
You are demonstrating the biggest advantage and the biggest downsides to Linux at the same time. The rich and widely available different ways to administer the system, and the self important douchbags in the community who believe their way is the one true way (tm).
You're wrong on this one. If you need a graphical tool to administer your system, you clearly are not meant for sysadmin work.
Most of the time, graphical tools like gedit aren't even usable (like on a constantly changing file) or available.
> Mind you few people will ever say a system is easier if that system
> is new and requires them to read a man page. Change is never easy.
Many people change when the new tool is better, even if it requires learning new ways of doing things. Many new and improved tools make a serious effort at backwards-compatiblity to make the transition easier (systemd does not do this). That's why, for example, many people switched from syslogd to rsyslog or syslog-ng. why many changed from ncsa or cern httpd to apache. why many changed from csh to posix sh (or bash or ksh or zsh). Many of these people who have gone through all these changes and more are the same people complaining about systemd, so their objection is clearly not because they are afraid of or too lazy to change.
No, you're wrong, the people you're talking about all made the change to systemd. And I'm one of them.
That's why most Linux distros switched to systemd BTW, you know, the same ones that switched from syslog to rsyslog or syslog-ng.
The people complaining about systemd are a minority that are on Devuan or fled to BSD by their own admission.
I know I'm never looking back to sysvinit, but then again, I started avoiding sysvinit 15+ years ago, and yet, I'm one of the most proficient admins with it.
The knowledge of the braindead sysvinit by most sysadmins is actually abysmal.
The Linuxtoday editors are biased toward systemd benefits and contributors, I thnik. This issue about Busybox has not entries in Linuxtoday covarage in October.
Nah, I said it wrong. I should have said, "Systemd makes things easier for people who write init scripts for distros."
"First they came for the slanderers and i said nothing."
As stated elsewhere in this thread - I don't have any problems with it. I'd like to. I'd love to fit in and have something to rant and rave about. No, it just works. I learned a few new commands (some of them are useful). That is it. It hasn't borked anything, here. I 'administer' a number of servers and desktops but they're all my own. I'm not a professional and I don't stray too far from fairly typical use patterns.
"So long and thanks for all the fish."
Funny, when you're posting in a new thread instead of replying.
[...] Anyhow, if you've not seen this then this makes an EXCELLENT read:
http://blog.darknedgy.net/tech...
In the end, I've concluded, I just doesn't seem to matter to me - yet. It doesn't really impact me. I'm sure that it does others but, for me, it just works. I want to hate it. I want to be in the cool crowd and rage against the evils of the domineering Red Hat and crew... I want to be enraged enough to key cars, throw bricks through windows, or at least post vile, spittle speckled, angry posts on the internet but it just hasn't bit me yet. Maybe when it does? I'll start my brick collection, just in case.
Seriously, thank you, your post is one of the best I've read on Slashdot, especially because you cite the ONLY really good (blog) post describing systemd problems I've ever read. ...
As the author note, not a single systemd opponent can articulate any specific problem in systemd, just general things that they attribute to systemd but can't understand.
This blog post is genuinely good, and from someone that actually understand what he's talking about (he's at least read some of the code in systemd).
The flaws of systemd are clearly explained, and even I being a pro systemd person, can agree completely with everything written there.
This is an essential read for any systemd proponent or opponent actually.
What it shows, is that you can do better than systemd, because systemd devs took the practical way, not the high standard one.
Basically, it's like systemd were Linux, and the alternative must be like Minix (or GNU Hurd), that's how I'd summarize what is written in the blog post.
Most of the flaws described in the post are shortcuts chosen by the devs (and the systemd devs are aware of them), just like Linus did with Linux, so as to provide an implementation in a reasonable amount of time.
Now, if you look at the state of Linux and the state of Minix or the Hurd, I personnally agree with the choice made by the systemd devs.
The competition just now has to start implementing and proposing their high standard alternative to systemd and stop the complaining that doesn't help anyone.
Some have started (s6 with OpenRC might lead to sth), but nothing usable is available yet. Instead, there's lots of red herring and bad mouthing systemd by the competition, making them losing their time in useless discussions. Things like "systemd didn't invent socket activation, it's not even really socket activation" (hint: we don't care, the functionality is provided and advertised, when it wasn't before, or the projects like inetd and xinetd went abandoned), "systemd didn't invent cgroups, you can use them with scripts" (hint: we don't care, nobody used them with sysvinit, and systemd uses them by default), "you can jail your processes without systemd" (hint: this is laughable, as it was so complicated to do, and even more to do right in shell scripts, that it was never done, or always done wrong, and wrong feeling of security is worse than no security),
Nah, I said it wrong. I should have said, "Systemd makes things easier for people who write init scripts for distros."
Not only in distros actually, but also for upstream projects that distribute init configurations.
And usually distro init script writers are far better than most admins (and commercial software vendors script writers) out there that don't even understand how to write shell scripts. I've encountered countless horrors everywhere, and as early as I'm authorized, I reimplement most init scripts, and it's not true only on Linux, but even on AIX, Solaris and HP-UX (back in the day).
I do that since 15+ years. I'm sure most seasoned sysadmins do the same as soon as they encounter one init script bug that breaks their OS.
Someone actually documented there some of the things people that don't understand anything about init scripts, shell scripts or systemd actually do. That's the kind of horrors I see every time.
You don't even want to start thinking about the security implications of such things, especially since those people usually put setuid bits everywhere when their mess does'nt work.
Just like PulseAudio forced sanitizing lots of ALSA drivers, I guess systemd will at least force sanitizing init environments and weed out all these nonsense.
At least I can hope.
I do that since 15+ years. I'm sure most seasoned sysadmins do the same as soon as they encounter one init script bug that breaks their OS.
I think you are underestimating your relative skill level. I know some system admins who are capable of that, but the vast majority seem not to be. I would guess you are in the top 10% if not the top 2% in terms of skill level. I see your point that writing init scrips is hard, and systemd will reduce problems from less-competent init writers.
Just like PulseAudio forced sanitizing lots of ALSA drivers, I guess systemd will at least force sanitizing init environments and weed out all these nonsense. At least I can hope.
Yeah, recently is that the systemd argument has started drawing some very skilled people in to discuss what a good init system would look like. Here's one example. And of course, you've commented in some of the discussions in my journal, and I would like to think they are the work of a very skilled person too :)
One thing I've noticed is that people who favor systemd almost all favor the features of systemd. Those who oppose systemd almost all oppose because of architectural reasons, or implementation details. So theoretically both sides could come together if an architecturally sound init system were created with features people need.
"First they came for the slanderers and i said nothing."
ffs, init was 20k LOC systemd is now 100+ bins and 430k LOC.
These are not the same thing at all. These systemd LOC replaces init plus countless more daemons and Unix standard tools that you had to use in order to even boot to a usable shell. The tools that made some boot firmware larger and lead to things like busybox.
Before systemd you had a log file that was text and parsable using the commands that are core to unix (or specialized applications/services to injest them later), after systemd you have a binary log that mind you has code controlling it that can choose to destroy that log if it finds it is unreadable or corrupted.
What you say is just clueless FUD. After systemd, you still have the exact same log file available (which are not always text) with even more useful and accurate information than before systemd. At least I know I do still have them, better than before, because now I actually have the log with the complete kernel logs, which I never had before systemd, not even with the kludge of using dmesg.
I wonder what destroying corrupted or unreadable means, but sure enough systemd do nothing of this kind. The corrupted log is still there, it's just not displayed to you by default, but if reading corrupted or unreadable log is your (nonsense) thing, you can still do it with the journal.
Init was special purpose and streamlined to do one task well, systemd is coupled to auth, dbus, vm startup and shutdown, vm management, privilege escalation, ....
What is your point, nothing is mutually exclusive in that...
No one is complaining about the features of systemd, everyone is complaining about the design of those features that is reminiscent of MS architecture and design (that even MS has started to run away from). Poettering has stood in front of rooms full of people and flatly said he does not care about posix or unix he wants to build something new. He is -- hes building a monolithic userspace kernel and RH is using the init functionality to shoehorn itself into a controlling position.
You don't make any sense. What is a userspace kernel? Who is this everyone you're talking about? It sure enough is not "everyone" in the sense used by sane people.
What is reminiscent of MS architecture in systemd? Systemd is using specific Linux features which were not widely used at all by anybody, what is so reminiscent of MS architecture in Linux?
You people say stupid things without ever any specific example to make your point, you just sound like crazy people that don't know what they're talking about.
But that's why your an ignorant AC.
Because of the way systemd/XDG/pam/dbus are designed, the more he extends it the more other core bins on the system will need to integrate with it or rebuild functionality that has been displaced by it for no reason. It is a loss lead development and it will me Linux's loss in the long term.
Another MS shill.
Why has nobody written a tool to view the binary log? Just 'cause it's binary doesn't mean that it can't be done - does it? I'd think that someone would do this. Maybe I'm missing something here but this doesn't seem insurmountable. If I gotta do it myself then, well... You don't want that.
Somebody has already done that, though not sth as stupid ad reading the files. The reason you're not aware of this is because you listen to the clueless anti systemd people. rsyslog reads from the journal since months, there is just no validity to the complaints of people about the journal, as you can constrain it to memory if you want (stupid thing to do IMO) and have only your "text" (but not really) files if you want.
And journalctl reads the "binary" logs (which are mostly text actually, unless compressed) already.
You'll be better off listening to proponent of systemd if you want to go anywhere, instead of the countless FUD and BS spouted by anti systemd people.
Most of the time they are repeating completely false arguments or things that are wrong for years.
I use journalctl all the time. I also use systemd-analyze critical-chain too. I kind of, sort of, figured there was, indeed, a way to read these files that folks complain about - I mean, yeah, I do it with journalctl quite frequently. (If I'm not breaking something then I'm not learning anything.) It'd stand to reason that there's a way to make a reader just for these logs (if, for some reason, one can't do it with journalctl, et al).
"So long and thanks for all the fish."
The breaking change was cgroups. Or, if you like, the breaking change was that SysV scripts were trash. Either way, every system has discarded SysV init. Why? Well, it's technical. I'm not going to spoon feed you: go look up the issues. Ditching technical debt is always nasty, and systemd is playing nicer than its detractors have any idea. They are making the right decisions for the right reasons, and maintaining an external API (or actually several).
"I don't understand why this is happening. I think it's a conspiracy!" No, it's that you're an ignorant fool who is too lazy to do research. It would be one thing if you knew the issues and disagreed with the decisions made to fix them, but you're just an idiot with a keyboard at this point.
I think you are underestimating your relative skill level. I know some system admins who are capable of that, but the vast majority seem not to be. I would guess you are in the top 10% if not the top 2% in terms of skill level. I see your point that writing init scrips is hard, and systemd will reduce problems from less-competent init writers.
My point is that only the people with as much experience (not even skill, just experience) are able to even understand the issues.
Yeah, recently is that the systemd argument has started drawing some very skilled people in to discuss what a good init system would look like. Here's one example. And of course, you've commented in some of the discussions in my journal, and I would like to think they are the work of a very skilled person too :)
I actually appreciate these because they are from people that really understand what they're talking about, it's refreshing.
One thing I've noticed is that people who favor systemd almost all favor the features of systemd. Those who oppose systemd almost all oppose because of architectural reasons, or implementation details. So theoretically both sides could come together if an architecturally sound init system were created with features people need.
I agree with this, my problem with a lot of opponents to systemd is not the fact that they have a different opinion, it's just two things :
- most of the time they don't understand what they're talking about and are just following a trend;
- those that are knowledgeable don't make enough serious work done to make a valuable competition to systemd;
The worse thing is that I understand the genuine flaws the knowledgeable people are talking about. They are trade-offs I think the systemd devs are well aware of.
I find them acceptable, the others find them not acceptable. We're in the exact same situation of Linux vs Minix or GNU Hurd, XFree86 vs the rest, DBUS vs other IPC tools...
Some people got the work done, it's not perfect, but it allows to make a useful implementation that can be improved later.
Other people have legitimate complaints, but are not doing any serious work, or let go when they realize that their high standards implementation would require 10 times more work to make sth useful. It's the real life world we live in.
Most of the anti systemd people don't realize that the problems systemd tries to solve, knowledgeable people have tried to solve them inadequately since 2 decades if not more. And some problems kept getting in, like the dynamic nature of the Linux kernel, which in itself caused a lot of shitstorms with devfs and the like before udev settled. These were the most painful migrations due to Linux kernel changes I ever had to do on my own made systems, and distributions maintainers must have been at huge pain since then.
Separation of mechanism and policy is a good thing, but the problem is that a distribution HAS a policy to withstand, which made the mess of hugely incompatible init, which in itself is not a problems for distributions, but one from upstream projects.
Systemd tackled lots of problems like these, it made some kernel Linux features prominent and simple to use (features that were rarely used before, and still not used in other init systems), improving the kernel by showing buggy, insecure or inadequate features (of course, as nobody used them, nobody noticed), some of them being huge problems for years (like mtab handling). For all that and more things (like improved security by default) that have nothing to do with systemd features, I thank the systemd devs.
That busybox removed support for the journal is not really a problem though, as if systemd is used with a busybox system (that's what I do in my LiveCD), the busybox syslog is not even used, there was no point in doing that.
Systemd tackled lots of problems like these, it made some kernel Linux features prominent and simple to use (features that were rarely used before, and still not used in other init systems), improving the kernel by showing buggy, insecure or inadequate features (of course, as nobody used them, nobody noticed), some of them being huge problems for years (like mtab handling). For all that and more things (like improved security by default) that have nothing to do with systemd features, I thank the systemd devs.
Yeah, I think it's a mistake to claim Poettering is evil or that everything he's done is bad. Clearly he has done things that some people want, and from looking at the quality of his code, I would be happy to have him as a coworker because I think he's a fine programmer. I think a lot of his architecture and design decisions could be drastically improved, though.
BTW Udev is a Linux thing......have you had a chance to figure out how the BSDs handle dynamic device plugging? I've been meaning to look into that but haven't gotten around to it.
"First they came for the slanderers and i said nothing."