Slashdot Mirror
Ubuntu 15.04 Released, First Version To Feature systemd
jones_supa writes: The final release of Ubuntu 15.04 is now available. A modest set of improvements are rolling out with this spring's Ubuntu. While this means the OS can't rival the heavy changelogs of releases past, the adage "don't fix what isn't broken" is clearly one 15.04 plays to. The headline change is systemd being featured first time in a stable Ubuntu release, which replaces the inhouse UpStart init system. The Unity desktop version 7.3 receives a handful of small refinements, most of which aim to either fix bugs or correct earlier missteps (for example, application menus can now be set to be always visible). The Linux version is 3.19.3 further patched by Canonical. As usual, the distro comes with fresh versions of various familiar applications.
Then it's simple.
"We changed everything."
No wonder it was short.
Hopefully they'll dump unity and go back to gnome shell as the default. Unity is completely unnecessary bit of technological desktop hubris.
Its like asking whether you'd preferred to be mauled by a rottweiler or a pitbull.
Both are just change for changes sake and neither bring much new to the table. Sure the scripts for init could get messy but they worked, everyone was familliar with them and if no major issues have cropped up since 1991 (or 1970 for unix) then its a fair bet its a reliable sub system.
But no , the "Not Invented Here" meme popped up its ugly head again and some know it alls decided they could reinvent the wheel better. Well so far the jury is still out on that.
oh, and double fuck beta too.
Ubuntu Linux 15.04 is NOT the first release of Ubuntu Linux to include the clusterfsck called systemd. I have it installed as part of an update to Ubuntu Linux 14.04. It has even infected prior versions running in VMs on my computer causing the performance to degrade to early 1990s era PC. Incredible!
CAPTCHA: miseries (oh so appropriate)
Systemd, eh? I predict that this thread will be filled with sensible and rational comments.
Personally, I'm not a fan. It's overly complex to the point of being nearly undebuggable which makes it much harder to fix than the older system. Frankly it's also written by Pottering and given the awful experience I've had in the past and still sometimes have with PulseAudio, I don't really trust it. It's fine to have PA crap itself and require a restart (well, kind of annoying in the middle of watching TV, but survivable). I rather hope he's written systemd somewhat better.
I know the distribution makers like it because packaging stuff is easier, but the end user experience (the end user being me) is IME inferior. But I care about debuggability, hackability and simplicity over having a very heavily intetegrated desktop "experience".
SJW n. One who posts facts.
"We've adopted it on an increasingly large scale and we are seeing the rewards already."
List them. And be specific - no vague handwaving waffle please.
/...reads headline.......this crap again???...... goes back to work
All I'm going to say here, is that I'm not beholden to 1 dist or another at this point. Nor am I 'committed', to Linux. There are alternatives. Nothing is off the table at this point!
I know how much Slashdot loves Systemd and Ubuntu. Pairing them together? Wonderful. Can't wait to see your responses!
I struggled to get away but it held me down. it kept saying "systemd-modules-load.service loaded failed failed Load Kernel Modules" while it thrusted in and out. Why did this happen to me? Why!?!?!
Welcome to the party Canonical :)
One more requirement: explain how to debug/trace exactly what systemd is doing without recompiling systemd and adding specific printf() statements everywhere.
Because that's what's missing from systemd at the moment.
sounds made up. well I've switched to openbsd and I can tell you I haven't looked back. it is rock solid and the security stuff they have built in is darn impressive. as far as I'm concerned systemd=high complexity=high chance of serious exploits
Fools rush in where Angels fear to tread.
The world is coming down.
At least the world of Free Software that was so close to my heart for the last 15+ years.
The simplicity of U--nix has reached the EOL. So has modularity.
Welcome, to new shores, the new U--s, full of mischievous monolithic blocks that accompany us from after PID 1 to shutdown and start our daemons, log us on, guide, lead, help, protect our systems and its users throughout the lifespan of their sessions. And beyond. From cradle to the grave - from boot to halt.
This is not my world any longer.
the adage "don't fix what isn't broken" is clearly one 15.04 plays to.
Uh huh...
systemd [...] replaces the inhouse UpStart init system.
Hmm.
systemd is Roko's Basilisk.
Can't wait for the vulnerabilities I found and gave to some nice hacker friends to hit systemd right as it's hitting 'prime time' and beats it back into obscurity.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
Systemd? No thanks.
Chas - The one, the only.
THANK GOD!!!
Systemd? Has it spawned Satan yet?
In the last year and a half I have tried several different Linux desktops to run on a small form factor Dell pc connected to my TV via HDMI.
I settled on Ubuntu for a variety of reasons and was reasonably pleased with it.
However, after a few weeks things started to go wrong.
Errors, lockups and other things cropped up that started to really get old.
I read forum posts, blogs, "kb" articles to fix the various issues I had with Ubuntu.
Eventually I wiped it and reloaded it, and the same sorts of problems came back.
I was ready to install Windows when I read someone mention Linux Mint.
So I gave that a try.
Like a cool spring breeze on a warm afternoon, Linux Mint was refreshing and met all my needs without problems.
To this day I wonder why Mint works so well when Ubuntu Desktop was such a POS.
We play the game with the bravery of being out of range
Sure you post as AC!
Nobody takes you serious with this statement of yours. Not that OpenBSD has anything to be said against it. But OpenBSD is not a desktop-everyday-OS. Only an AC could declare it as such.
If I upgrade, will all the "phone home" processes to Canonical that I've disabled still stay disabled? 'cause my packet sniffer caught at least a couple of pings a minute before the purge. Same goes for all the Amazon / Cloud stuff. I hope that crap stays off my machine.
if I had mod points, I'd mod you as troll.
its not the 'basement dwellers' - those guys have zero experience in unix, given that they are alive less than 20 years, usually, and they know only what they've learned during the obama years and not much before that.
the rest of us who have used and managed unix since the 80's have to dump WHAT WORKED WELL and move to some new shit that clearly has issues, does not fit in or belong very well and is being forced on us.
see, the value of a craftsman is in his knowledge and experience of his tools. some people spend decades learning how to use their tools and work in their trade and the time shows; experience is worth having and paying for!
what happened now: some newbie decided the old way was not good enough and decided to change it all out, for no good reason at all (I have not yet seen a good reason to reinvent a wheel that has been working for longer than most of you have been ALIVE). faster startup is not a reason; this isn't a media player and linux still does not startup in 3 seconds or less, so what's the point of 'faster startup' when its really not fast enough to justify this forklift upgrade of sorts?
basically, the linux distros have been 'google-fucked'. I use that term to mean that some young snotnose didn't have anything better to do with his time and decided to royally break things and redo them, just because he thought it was a 'good idea'. but clearly didn't think it all the way thru and just wanted it because he just wanted it! typical google style; break things and trash all the old history of how things WERE done because, well, we just CANT LEAVE WORKING THINGS ALONE!
--
"It is now safe to switch off your computer."
So posting in a thread about a feature he does not like is somehow looking back at the systems? So once you change systems you cannot ever look or post on the previous techs threads or you are looking back?
When you cant win, ad hominem.
I would prefer to answaer to a non AC...but then. sysdig or dtrace
For some reason, they're stuck at Squid 3.3.8 which is two years old. squidGuard is very recent, 1.5-4, to the point that it isn't compatible with the squid 3.3.x branch. It's broken out of the box and they don't work together. Changelog says the squid base is now 3.4 for squidGuard, but they package squid 3.3.8... I had a config working on 14.10 with squid 3.3.8 and squidGuard 1.5-2. Spin it up in 15.04 and copy the conf files over and I get a "ERROR: URL-rewrite produces invalid request: GET ERR HTTP1.1" error. Pffft!
I have not read a single time desktop above.
I guess you post in slashdot because being an idiot in real life is not enough for you?
I actually found systemd reporting, status and analysis tools pretty verbose compared to the corresponding system V init scripts.
What kind of bug did you try to catch ?
> journalctl -f
Which simply does not help. systemd doesn't usually save stderr so the journal is more often than not useless for troubleshooting. If you had actually used systemd, you'd realize those guys don't grok UNIX. They simply don't get it. They don't understand why stderr is so important. Instead, they just toss it away. If you had actually used systemd, instead of just trolling, you'd realize why it is fundamentally broken.
systemd service files are far less complex that the stack of init scripts need on top of system V init. The status and reporting is incomparably better than anything before it.
I don't care about systemd (i understand some of the criticism, but not the "riot" against it, usually from people that don't understand any of the criticism...) - i care about the Unity desktop... so much that i change it immediately to Gnome Classic !
Antisthenes: "Wisdom begins by examining the words/names." - excuse my English, i am (slightly...) better with my Greek!
Of the pointless Linux churn. I switched to NetBSD. Couldn't be happier.
What more debug do you need that other inits are providing?
System V init scripts don't have a policy against syslog and stdout. If a process outputs to stderr with a standard init script, then you see it on the screen. You can debug problems. With systemd's policy against stderr, it is swallowed and not shown on the screen and not logged. It is simply sent to /dev/null. The creator of systemd admitted he doesn't get the concept of stderr. It is an important one, and his policy makes it nearly impossible to debug startup problems. That is why systemd is useless for systems with nontrivial startup scripts, which is exactly what it is being sold as solving so that makes it broken by design. It does not do what it is being sold to do.
Here's a script that reproduces this flaw in systemd that was originally posted to a systemd bug that was of course deleted and ignored:
# cat
CentOS Linux release 7.0.1406 (Core)
# cat /etc/systemd/system/broken_systemd.service
[Unit]
Description=Broken systemd example
After=network.target
[Service]
User=root
Group=root
ExecStart=/root/broken_systemd.sh
[Install]
WantedBy=multi-user.target
EOF
# cat /root/broken_systemd.sh
#!/bin/bash
echo "Example systemd service"
echo "Error that should not be thrown away" >&2
exit 1
EOF
# chmod +x /root/broken_systemd.sh
# systemctl start broken_systemd ; echo $?
0
# journalctl -u broken_systemd
Feb 12 17:59:32 redhat7test systemd[1]: Started Broken systemd example.
Feb 12 17:59:32 redhat7test systemd[1]: broken_systemd.service: main process exited, code=exited, status=1/FAILURE
Feb 12 17:59:32 redhat7test systemd[1]: Unit broken_systemd.service entered failed state.
> journalctl -f
Which simply does not help. systemd doesn't usually save stderr so the journal is more often than not useless for troubleshooting. If you had actually used systemd, you'd realize those guys don't grok UNIX. They simply don't get it. They don't understand why stderr is so important. Instead, they just toss it away. If you had actually used systemd, instead of just trolling, you'd realize why it is fundamentally broken.
You didn't use systemd either : it has step by step execution, debug option which is very verbose, emergency shell, debug shell (on vt9), all of this off the top of my head.
Besides, systemd is not based on Unix, it's heavily tied to the Linux kernel, the same Linux kernel that already doesn't grok UNIX if you want to go that way.
Actually, systemd uses a lot of Linux features not present on Unix. If you wanted to complain, you'd have complained about Linux primarily.
systemd would not even be possible on any Unix, that's why portability of systemd to other Unix was thrown away.
So posting in a thread about a feature he does not like is somehow looking back at the systems? So once you change systems you cannot ever look or post on the previous techs threads or you are looking back?
No, once you said "I am not looking back", and then you come to a thread of the thing you weren't supposed to be looking at, I call you on your BS.
Besides, this serves no purpose at all, this doesn't help people in the thread, and doesn't help him either.
I see a poor person looking for validation because of his/her insecurity of having changed OS, which doesn't help his/her cause actually.
I'll never understand why Unity gets so much hate, I actually like it. My only complaint is the stupid 'search' feature that you're forced to use when you want to find something that's not in the dock. Even though I've managed to filter out all the Amazon crap, it's still slow as molasses (and I'm running a Core i7 with 6GB of RAM). Other than that I've been pretty happy with Ubuntu and Unity although I've considered moving to Mint and using a 3rd party dock of some sort (Cairo or Docky) to mimic the Unity dock.
I can't really weigh in on the Systemd vs Upstart debate since I'm not enough of a power user to really have it affect me. I suppose the only thing that comes to mind is that the 'If it's not broke, don't fix it' argument has merit, it can also hold back innovation. Change is scary, but it's not always bad (although sometimes it does go horribly wrong). This sort of reminds me of when Apple went from 13 to 16 sector disks or even the whole CP/M vs DOS debate.
And anything but portable to other operating systems. We also have an example above of systemd ignoring output to stderr. Not cool.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
Who keeps modding these posts up? Using "journalctl -f" to view output from stderr to debug why daemons aren't starting is a feature I use often as part of my job. If there was ever a version of systemd that didn't log stderr, it was a short lived bug.
"Not looking back" is a colloquial phrase indicating that one is happy with a decision they have made. It on no way implies that they have decided to scrub their life of all trace of something they used to do or use.
But a nuanced understanding of what people say is beyond a blunt intellect like yours.
Holy shit, INI files? This really is the PHP of init systems....
For a server administrator SystemD brings a bag of neat management features.
For a desktop user SystemD quietly does its job in the background without interfering with the usage of the computer.
What fucking idiot modded this informative?
Apr 24 10:52:06 u1504 systemd[1]: Starting Broken systemd example...
Apr 24 10:52:06 u1504 systemd[1]: Started Broken systemd example.
Apr 24 10:52:06 u1504 broken_systemd.sh[31375]: Example systemd service
Apr 24 10:52:06 u1504 broken_systemd.sh[31375]: Error that should not be thrown away
Apr 24 10:52:06 u1504 systemd[1]: broken_systemd.service: main process exited, code=exited, status=1/FAILURE
Apr 24 10:52:06 u1504 systemd[1]: Unit broken_systemd.service entered failed state.
This is still a problem with the most recent version of Red Hat. It's running:
$ systemctl --version
systemd 208
+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ
Not only does Poettering ignore users, he is also ignoring his employer. He works for Red Hat, and these serious bugs are not being fixed.
# cat /etc/systemd/system/broken_systemd.service
[Unit]
Description=Broken systemd example
After=network.target
[Service]
User=root
Group=root
ExecStart=/root/broken_systemd.sh
[Install]
WantedBy=multi-user.target
EOF
Note that you are using the default Type=simple, where systemd considers the program started as soon as the child process has execve()d. So the exit code of systemctl start will naturally be 0, because Type=simple by definition doesn't wait for the process.
Depending on what you want to achieve, you will want to set a different Type=. For example, if you set Type=oneshot, systemctl start will return a proper error exit code (because it will wait for the process to finish before considering the unit's status).
But even in your example, when the process exits later on, the unit's status (see systemctl status or systemctl --failed) will be considered failed, because then systemd will detect the error exit.
This is all nothing new and documented.
# journalctl -u broken_systemd
Feb 12 17:59:32 redhat7test systemd[1]: Started Broken systemd example.
Feb 12 17:59:32 redhat7test systemd[1]: broken_systemd.service: main process exited, code=exited, status=1/FAILURE
Feb 12 17:59:32 redhat7test systemd[1]: Unit broken_systemd.service entered failed state.
I don't know about RHEL7, never useed that, but on Debian 8 your exact unit gives me the following (anonymized) output:
DATE TIME HOSTNAME broken_systemd.sh[PID]: Example systemd service
DATE TIME HOSTNAME broken_systemd.sh[PID]: Error that should not be thrown away
DATE TIME HOSTNAME systemd[1]: broken_systemd.service: main process exited, code=exited, status=1/FAILURE
DATE TIME HOSTNAME systemd[1]: Unit broken_systemd.service entered failed state.
And in contrast to sysvinit, where the output of init scripts might flash on the console before being replaced by something else (too fast to see), systemd actually logs them and they are now available for later viewing. I consider the handling of stdout/stderr of services by systemd a huge step up compared to sysvinit - I've seen TONS of init scripts that start daemons with >/dev/null 2>&1 or so, because otherwise the daemon would clutter the console with messages, and those messages just got thrown away before. Now they can actually be logged.
You mean the example that's a FUCKING BLATANT LIE? Try it yourself before spreading FUD.
Thank goodness 14.04 LTS is going to be supported for another 4 years. And it comes in a MATE variant.
There are systemd haters who just think the design is fundamentally broken. There are others who just don't want to have to deal with an immature, buggy system for years upon end. By putting it into a distro as popular as Ubuntu, there's going to be a ton of practical fallout, where more and more people hit the corner cases and experience system crashes, many of which are directly the result of systemd bugs. Now, if Canonical are really smart (who knows), they'll be logging these crashes and make it easy to push stack traces upstream.
Eventually, the bugs will be worked out, and all we'll be arguing about is the architecture.
You're clearly getting recalcritant in your dotage. SysV init was unportable (esp. between distros) and unmaintainable, and founded upon bad hacks like pidfiles. Systemd is fundamentally not about faster boot, that's just a strawman you've set up. The road to systemd began with a need for process tracking. To work well, this has to be done in cooperation with the kernel, and such projects have a long history: cgroups are merely the most recent / most successful. I'd give you a history lesson, gramps, but you should probably either give this one up for want of intellect, or get it from the horse's mouth.
I really don't care of any others operating system since at least 20 years. Fine for me. There still have system V init, and system V init is still running on Linux. What the problem ? Linus didn't ask others OS before making system calls that are unique to Linux. Why systemd (or any applications for that matter) should be prevented to use them ?
Remember me how the Node.js team reacted to my proposition to use Linux timerfd to improve the repeatable timer precision: there removed the repeatable timer from the API because Windows would have nothing to match the Linux timerfd precision.
Will systemd increase or reduce performance? I cant get any straight answers out of the gigantic whinefest that is the systemd controversy.
Do not look at laser with remaining good eye.
I think this is the same problem that stumped Red Hat's support for a while when we first upgraded to 7. MongoDB refuses to start after an unclean shutdown. It detects that by placing its PID in a file named mongod.lock on start and then clearing the PID on clean shutdown. When you start MongoDB with the lock file in place, it gives you an immediate and clear error message on stderr that this is the problem. When starting with systemd, because it swallows stderr and syslog messages, there is no indication whatsoever what is causing it to not start. There is nothing in the journal or the console. systemd hides the information you need. Instead of taking thirty seconds to fix this problem, it took us most of a day and required using strace to see the stderr output that systemd hides.
Even worse is trying to troubleshoot SELinux-related problems. SELinux is very sophisticated so anything that hides stderr or deletes syslog messages makes life very difficult.
In the past, I would install the release of Ubuntu a month before it was officially released.
Now, I'm sticking with 14.04, and will likely next try Devuan when released.
I updated from 14.10 to 15.04 last night but now I'm getting some weird errors on the start up screen. Stuff like 'sse/media not found', 'ssf/media not found', 'ssg/media not found'. It keeps going on like that for a bit but it eventually boots into Ubuntu. It looks like the system is looking for non-existant drives or something, but I'm not sure how to fix that.
Ubuntu seems to become unstable after updating. The last few times I've updated to the newest version I had weird errors on boot up, but none of them ever seemed to affect the functionality of the system. It makes me wonder how well they test the update feature, or do they think that everyone is going to do a fresh install each time?
I did try it, and reproduced the his results on Fedora 21.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
was of course deleted and ignored:
And that is the even bigger problem with systemd. Ignoring exit statuses, deleting stderr, and swallowing syslog messages are all bad, but those are problems that can be fixed if Poettering would start listening to people that have much more experience with UNIX especially wrt managing servers. But since he, as Linus Torvalds has pointed out several times, ignores users and bug complaints, this problem will most likely not be fixed. It is a flaw in the culture of systemd. As so often happens in organizations, the culture at the top filters down all of the way to the product in the end. The product so often mirrors the leaders.
You are reaching and making yourself look stupid.
Great test script. It demonstrates the flaws in systemd very clearly.
Now imagine instead of troubleshooting a simple problem where the exit status is ignored, trying to debug an SELinux problem. That is nearly impossible with systemd. When Red Hat 6 was released, it took me about three weeks to get our entire application stack working on the new version. Most of the problems were due to the fact we store files in nonstandard places which causes SELinux to block access. With Red Hat 7, it took two people more than four months to get everything working. That's more than ten times as long. systemd, despite hiring guys with 20+ years experience and having expensive support contracts with Red Hat, took more than ten times as long to get work as without something that ignores syslog messages, stderr, and exit statuses.
systemd makes the lives of professional sysadmins a living hell.
I posted that to reddit! Posting that got my account banned. The guys at /r/linux hate people that understand UNIX. They hate us. They ban people if they show they understand concepts like stderr. They don't understand stderr, syslog, or exit statuses so they lash out and attack people that do. They're proud of their ignorance, and that is why they love systemd. It is down at their level.
I like my all log files to be all text.
Nice attempt to blame the victim. Poettering works for Red Hat, and it is still a bug with the version of systemd he ships with the newest version of Red Hat. Maybe it is fixed in some alpha version that no one uses, but in the real world, the journal is useless since it doesn't log stderr and often drops syslog messages.
It is trivial to reproduce this serious problem with systemd. Pick any script in /usr/lib/systemd/*.service:
# append --broken to ExecStart line
vi
systemctl stop named
systemctl start named
Notice that the exit status from the start is 0. That is broken.
Also, look at the journal using "journalctl -u named" to see that the output doesn't log the expected error "named: unknown option '--'". It is not logged. That makes it very difficult to find the problem with the startup script.
It is obvious that Poettering simply doesn't grasp how important stderr and exit statuses are for those of us that manage servers. He comes from the background of an end-user that cares about things like sound cards. That is why he has spent so much of his career working with sound cards. Start-up scripts are something that he obviously doesn't understand.
With systemd's policy against stderr, it is swallowed and not shown on the screen and not logged.
A lot of this criticism is coming from AC.
I tested your script on CentOS 7 and Fedora 21 a moment ago. Both logged your "Error that should not be thrown away" to both the journal and to the syslog messages file. Both detected that the service failed, and did not "throw away" its exit status.
And as another user pointed out, the old init system did not save stderr to the logs. systemd is an improvement in this aspect.
http://www.linuxmint.com/
https://www.youtube.com/c/BrendaEM
These are getting modded up because morons like you are failing at reading comprehension.
We need to see what *systemd* is doing. We know that we can see what the controlled processes are doing. Which unit files is systemd using? Which environment variables are being set prior to the controlled process execution? As far as I'm aware journalctl doesn't output this information.
There is a specific issue with setting static IP addresses on a CoreOS image that results in systemd deciding to execute both the DHCP and static IP address unit files in parallel - a clear race condition on startup. The best way to have figured this out would be for systemd to emit exactly what it's doing and when it's doing it. There seems to be no facility for this; in fact, looking over the systemd sources suggests that there aren't even any logging statements to enable to trace this sort of problem.
We have now Ubuntu (and other distributions) full of bugs like this:
https://bugs.launchpad.net/ubuntu/+source/mosh/+bug/1446982
https://bugzilla.redhat.com/show_bug.cgi?id=1141137
When will these be fixed and what their impact will be?
Also, look at the journal using "journalctl -u named" to see that the output doesn't log the expected error "named: unknown option '--'". It is not logged
I don't know what to tell you, AC. You're wrong. I test every "example" of systemd problems that ACs post in this thread and they're all wrong. systemd logs daemon stderr to both the journal and to the syslog messages file.
I disagree, and therefore I am correct. Check MATE.
I know that was a stupid pun, but I promise I had a real point to prove. Unity is fantastic for people who's preferences may not mirror your own.
There is a specific issue with setting static IP addresses on a CoreOS image that results in systemd deciding to execute both the DHCP and static IP address unit files in parallel - a clear race condition on startup.
What are you talking about? systemd doesn't set up network interfaces.
Do you mean that you can start both NetworkManager and the "network" service? Because in that case, both of them use the same configuration files for an interface (/etc/sysconfig/network-scripts/ifcfg-), so an interface can't have BOTH DHCP and static addresses. The network service also detects whether NetworkManager is handling an interface and will not configure it if so.
Finally, NetworkManager provides much better logging of its process than the network service does. If you want to debug the latter, you'd do it basically the same way you always have. "set -x" in the ifup scripts and look at the logs (which you have now with systemd, and did not in the past).
system did not save stderr to the logs. systemd is an improvement in this aspect.
But how is hiding stderr and not logging it an improvement? At least with Sys V init scripts I had a chance of seeing the error message on the terminal. With systemd, I'm left in the dark unless I use strace to see the output strings that systemd is swallowing.
Well, I also tried it and could not reproduce those results on either Fedora 21 or CentOS 7. Both systems logged stderr to both the journal and the syslog messages file.
The old init system did not log stderr. If you didn't see an error printed to a tty, it was lost. systemd is actually an improvement in exactly the aspect that ACs complain about through this thread.
Services are easily manageable.
A bunch of us who actually manage systems tend to disagree.
Hundreds of DOS ini files, having to compile things instead of just modding a script, and not being able to step through a startup or shutdown process is not what we all consider easily manageable.
If it really were easily manageable, it would not have caught so much flak.
Sometimes you're the octopus, sometimes you're the girl.
I suffered through Ubuntu Unity on my laptop for one month until I did sudo apt-get install xubuntu-desktop. I wonder what'll break in a year once I upgrade from what amounts to Xubuntu 14.04 LTS to 16.04.
I switched to arch Linux about a year ago which comes with systemd and I have to say I absolutely love it. Before services and logs were always confusing. Is there a start up script? Had it been converted to an upstart job? Where are the log files? Etc. Once you learn how to use systemctl and journalctl there no more mystery... You always know where to look. Just my 2c.
If it ain't broke, don't fix it.
Because stderr isn't being hidden under systemd. It's logged to both the journal and the syslog messages file.
1) What did they break this time that won't get fixed for several releases?
2) What did they finally fix that has been broken for several releases?
You didn't use systemd either : it has step by step execution, debug option which is very verbose, emergency shell, debug shell (on vt9), all of this off the top of my head.
Oh my, I want to step through 3000 steps manually before I get to my program of interest, and I also want to see 1000 lines of spurious crap for things I don't care about.
Besides, systemd is not based on Unix, ... that's why portability of systemd to other Unix was thrown away.
That sound you hear is a collective sigh of relief mingled with drives spinning up as new downloads of various Unix flavors start in earnest.
The cesspool just got a check and balance.
Lying troll detected -- systemd does, unlike sysvinit, save stderr to the journal.
Watch this Heartland Institute video
You lie, troll. That works as documented in all versions of systemd in use.
Watch this Heartland Institute video
Soon the only advantage will be that one does not have to pay for Ubuntu. Other than that, it's becoming as obnoxious, dogmatic, intrusive and controlling as Windows.
Systemd is the least of my concern. As a business user who wants a reliable desktop environment, I still struggle with 15.04 due to its inability to work with multiple monitors and a docking station. Customization of Unity is also a pain the rear, as it is nearly impossible to get a theme that works with all the aspects of the graphical interface.Finally, you know things are off to a wrong start when you have to disable the Amazon shenanigans.
1) Systemd works great on the several machines I've tried, from an 8 year old home-built rig to my newer ThinkPad Carbon 2. Booting and shutting down are lightning quick.
Unity specific:
2) Place an option for Click-to-Minimize with the taskbar. This fundamental feature shouldn't require Unity-Tweak-Tools.
3) Get rid of the ugly boxes around the taskbar icons: https://askubuntu.com/question...
4) Really a new icon set is needed. Yes there are some great ones out there, which again seems to require Unity-Tweak-Tools e.g.: http://www.noobslab.com/2015/0...
5) Why not just include Unity-Tweak-Tools and call it Advanced or something, since basically everything requires it.
6) The Unity top bar is not useful. Honestly Windows 7 and newer has more efficient use of space since the taskbar, notifications and clock are all on the same bar. All it all it's a nice enough UI though.
7) After just the few tweaks above, I think Unity is excellent and no problems using it over any other Linux DE/WM.
I don't know what all the fuss is about. If you approach it with an open mind it makes perfect sense.
The unreasonable spoilt tubby pasty basement dwellers who spew poison over systemd need to live in the real world for a while.
We've adopted it on an increasingly large scale and we are seeing the rewards already.
Ah, a nebulous reference to 'rewards'...
remind me again, is there an official physical church where one can go worship, or are you all still at the early 'where two or three gather in Poettering's name..' stage?
Don't know about your job, years of running init rarely needed to debug or check why/if/when daemons aren't starting. on production systems. with users. with usb thingies. with eth failover.
Honestly, you fucking seriously mean to say THE FIRST PROCESS STARTED UPON BOOT NEEDS DEBUGGING and claim systemd is an improvement?!?!?
Hello Lennart, meet software deployment 101;
shit follows.
I can't tell if you are stupid or just a troll but I'll respond anyways. One of Systemds improvements is that it handles process (apache etc)reloads. One advantage to this, is that things are now restarted in the exact same environment (path, variables, CWD etc) as when the system is booting. The next advantage is that networking restart no longer needs to be run with nohup when done remotely, it just works now instead of dropping the interface and then dying.
This means that if say, a webdev or a junior admin makes a typo in a daemon and it fails to start you can now just use journalctl to see the output that previously went to console.
Less often(usually when I'm doing the initial setup), are things like iscsi, glusterfs etc that choked hard under the old init system and still need a bit (although easier) tweaking with systemd.
are marked as a troll by the systemd fanbois. This is the core, as Linus pointed out, problem with systemd. They ignore bug reports. I was able to reproduce the problem on version 208, which is the newest version with Lennart Poettering's distribution, Red Hat 7.
"I don't have a fucking clue and hope to bluff my way out"
Nice try. No cigar. Not even a butt end.
was of course deleted and ignored:
And that is the even bigger problem with systemd.
No, it's a big problem with your insanity.
This bug, since it doesn't exist, was never reported.
Watch this Heartland Institute video
And the more information you hide from the hapless user, the more 'modern' you are. systemd may be the most ill designed major OS component I've seen in a long time.
DIAF.
[vagrant@localhost system]$ sudo systemctl start broken_systemd; echo $?
0
[vagrant@localhost system]$ sudo journalctl -u broken_systemd
-- Logs begin at Fri 2015-04-24 20:19:20 UTC, end at Fri 2015-04-24 20:30:46 UTC. --
Apr 24 20:30:41 localhost.localdomain systemd[1]: Starting Broken systemd example...
Apr 24 20:30:41 localhost.localdomain systemd[1]: Started Broken systemd example.
Apr 24 20:30:41 localhost.localdomain broken_systemd.sh[3928]: Example systemd service
Apr 24 20:30:41 localhost.localdomain broken_systemd.sh[3928]: Error that should not be thrown away
Apr 24 20:30:41 localhost.localdomain systemd[1]: broken_systemd.service: main process exited, code=exited, status=1/FAILURE
Apr 24 20:30:41 localhost.localdomain systemd[1]: Unit broken_systemd.service entered failed state.
I think this is the same problem that stumped Red Hat's support for a while when we first upgraded to 7. MongoDB refuses to start after an unclean shutdown. It detects that by placing its PID in a file named mongod.lock on start and then clearing the PID on clean shutdown. When you start MongoDB with the lock file in place, it gives you an immediate and clear error message on stderr that this is the problem. When starting with systemd, because it swallows stderr and syslog messages, there is no indication whatsoever what is causing it to not start. There is nothing in the journal or the console.
And, as I've already pointed out: http://slashdot.org/comments.pl?sid=6953777&cid=49050025
This is a bug in the mongodb init script, it directs stderr to /dev/null.
If the mongodb init script sends stderr to /dev/null how can systemd log it to the journal?
Watch this Heartland Institute video
But you have to agree, the reason why you could find this bug was that it was a script which you could easily read through and debug line by line.
I think it has systemd IIRC too. I'll not upgrade mine to it for a while.
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
Sorry - where did initd log stderr to again?
I have Slackware running just fine on an old Macbook Pro, and my photo editing system is going to be upgraded to Slack soon as well.
And then there is my main home use machine which currently runs Mint, the Ubuntu derivative that used to fix most of the problems in Ubuntu: that will be upgraded before long as well.
Not really worried about Ubuntu 15- it will never get closer to a computer I have to deal with than a link on a webpage.
At work we have BEEN using Ubuntu 10.04 LTS for everything and are currently rolling out 12.04.
We are already discussing what we replace Ubuntu with if sanity has not returned to Canonical by the time 12.04 is EOL.
I can find the bug in an overly complex init script, yes. If they had a simple systemd unit there would be no bug to find.
(I found the bug in the init script in 10 minutes, the GP claims it took his crew of elite developers and Redhat support a whole day. Either he is an idiot or he is lying -- I suspect both).
Watch this Heartland Institute video
They release a major update while 14.04 is supposed to be LTS = Long time support (3 years, 15.04 is 1 year). Some bugs have been fixed in 14.10 (and 15.04) that are still live on 14.04. Annoying.
Slashdot, fix the reply notifications... You won't get away with it...
I am switching away from Mint 17.1 to either Kubuntu 14.10 or Windows 7 because of the numerous bugs and frustrations Mint has offered me.
Comment removed based on user account deletion
Now the real questions: Did anyone ever fix the bug in NetworkManager that caused it to turn off the network on exit without bothering to check if anyone was using it? Did anyone ever fix the bug in SystemD that made it incapable of resolving the dependency order of NFS? Does Lennart just hate iSCSI and network filesystems and everyone who uses them?
Why spend so much effort defending something broken? It seems like if the same amount of time was spent working on fixing systemd, then people wouldn't be complaining so often about these serious issues. By ignoring bug reports with good reproduction steps, you're proving Linus correct that systemd ignores bugs.
I've had to to train all of my junior admins on how to use strace. That took me quite a bit of time, and it takes them a lot of time to go through the huge log files that creates just to find the error string that systemd swallowed. I don't dispute that systemd is better when you have complex dependencies, but it sucks when a unit won't start and it gives you no clue as to why.
I'll also admit that the binary logs are very nice. Being able to look at just the specific unit you care about is very nice. Also, "systemd-analyze blame" is awesome. I was able to quickly find the troublesome services that were causing slow boot times on several servers, but until the other problems are fixed, systemd causes more problems than it solves.
Time to debunk many of the lies.
1. Modularity. It isn't. See --user.
2. Mature? Look at mailing list to see it isn't.
3. Logging is a fucking joke. Lennart is a seriously dumb cunt who seriously things http and json are better for logging than syslog. I'm not even making that up.
4. Secure? No fucking way.
5. Not portable? Who even cares when systemd doesn't even run on linux in most cases. Think phone tablet embedded non glibc. The biggest use case for linux already excludes systemd.
All the proported benefits are pointless when design decisions are taken by a luddite who's use case is differs from everyone else. Eg lennarts laptop vs the server use case.
Man hostnamectl. Go on. Do it.
I fucking lolled at lennart's laptop. Who needs this other way to give a nice windows style name to your laptop?
Proof that the person Doing the job is far from the best, most qualified person for the job.
This lennart cunt does not get linux or Unix.
That's the trouble with linux developers these days. They only use linux for work. Otherwise they use Apple products. And sit there playing with their pathetic, tiny, penises, high fiving themselves on how they are turning linux into os x.
For a first quick reference, this is how you would do it on *BSD (the interface being xyz0):
printf 'up\n192.168.1.42/24 media autoselect\n' >/etc/ifconfig.xyz0
printf 'defaultroute=(gateway addr)' >>/etc/rc.conf
I also faintly remember how to do that on non-systemd Linux, for instance in Debian it's adding 2-3 lines to /etc/network/interfaces.
So far, so good. Now, let's see how this is done when systemd is involved, the following is copypasted right from the Arch wiki
Persistent configuration on boot using systemd
/etc/conf.d/net-conf-interface
/usr/local/bin/net-up.sh
/usr/local/bin/net-down.sh
/usr/local/bin/net-{up,down}.sh
/etc/systemd/system/network@.service
First create a configuration file for the systemd service, replace interface with the proper network interface name:
address=192.168.1.2
netmask=24
broadcast=192.168.1.255
gateway=192.168.1.1
Create a network start script:
#!/bin/bash
ip link set dev "$1" up
ip addr add ${address}/${netmask} broadcast ${broadcast} dev "$1"
[[ -z ${gateway} ]] || {
ip route add default via ${gateway}
}
Network stop script:
#!/bin/bash
ip addr flush dev "$1"
ip route flush dev "$1"
ip link set dev "$1" down
Make both scripts executable:
# chmod +x
systemd service file:
[Unit]
Description=Network connectivity (%i)
Wants=network.target
Before=network.target
BindsTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device
[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=/etc/conf.d/net-conf-%i
ExecStart=/usr/local/bin/net-up.sh %i
ExecStop=/usr/local/bin/net-down.sh %i
[Install]
WantedBy=multi-user.target
Enable and start the unit network@interface, replacing interface with the name of your interface.
Source
/. wouldn't let me comment without it
/var/run directory, which may not be writable very early in the boot sequence, and which is erased a little later in the boot sequence. We therefore avoid writing to the file until we believe it's safe to do so. We also assume that it's reasonable to always append to the file, never truncating it. Optional argument $1 may be "OK" to report that writing to the log file is expected to be safe from now on, or "FORCE" to force writing to the log file even if it may be unsafe. Returns a non-zero status if messages could not be written to the file. rc_postprocess Post-process the output from the rc_real_work() function. For each line of input, we have to decide whether to print t
Hilarious, right? It's so simple! And it totally does away with those pesky shell script, yet in order to do something as simple as configuring a static IP, the user is told to create two shell scripts, apart from the systemd "unit file" and the file that contains the actual address.
At that point I nuked the machine and called myself lucky for not having to cope with this shit.
Your comment has too few characters per line (currently 24.9).
Please ignore everything below;
The log file is expected to reside in the
CLI paste? paste.pr0.tips!
> systemd doesn't set up network interfaces.
As of version 209, networkd does. I used it for both static address and bridging setup. As of version 215, it adds a DHCP server. That change caused major grief for us when a junior admin upgraded systemd, and the server suddenly started answering DHCP requests with wrong values. That took us a couple of hours to find while our network was mostly down for employees because who in the heck expects a server that doesn't have a DHCP server installed to start acting as a DHCP server?
Fortunately, Red Hat is still on version 208 so the systemd-created network problems don't exist yet for most people.
If you had correctly used Type=oneshot, you wouldn't have been in the dark and would have seen this on the terminal:
# systemctl start broken_systemd
Job for broken_systemd.service failed. See 'systemctl status broken_systemd.service' and 'journalctl -xn' for details.
# systemctl status broken_systemd -l
broken_systemd.service - Broken systemd example
Loaded: loaded (/etc/systemd/system/broken_systemd.service; disabled)
Active: failed (Result: exit-code) since Sat 2015-04-25 07:53:07 SAST; 26s ago
Process: 7880 ExecStart=/root/broken_systemd.sh (code=exited, status=1/FAILURE)
Main PID: 7880 (code=exited, status=1/FAILURE)
Apr 25 07:53:07 HOST broken_systemd.sh[7880]: Example systemd service
Apr 25 07:53:07 HOST broken_systemd.sh[7880]: Error that should not be thrown away
Apr 25 07:53:07 HOST systemd[1]: broken_systemd.service: main process exited, code=exited, status=1/FAILURE
Apr 25 07:53:07 HOST systemd[1]: Failed to start Broken systemd example.
Apr 25 07:53:07 HOST systemd[1]: Unit broken_systemd.service entered failed state.
Just because sysvinit couldn't do anything useful with stderr from a one-short service (and leave it to the controlling terminal to do something with it) doesn't mean systemd shouldn't. Logging it, and informing the user that the job didn't start and where to see more information is much more useful.
I've had to to train all of my junior admins on how to use strace. That took me quite a bit of time, and it takes them a lot of time to go through the huge log files that creates just to find the error string that systemd swallowed. I don't dispute that systemd is better when you have complex dependencies, but it sucks when a unit won't start and it gives you no clue as to why.
You may have been better off reading systemd.service(5), but junior admins should be taught how to use strace regardless ...
I think part of the problem is that sysvinit is basically feature-less, and for a running system actually does nothing (it is initscripts that does this), and so people are used to just having the entire system run by scripts with no useful features (e.g.doing something different with stderr than leaving it to the controlling terminal, letting the current user pollute the environment and thus never have consistent starting of services etc. etc.).
" I want to step through 3000 steps manually before I get to my program of interest," - what are those 3000 steps?
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
thats probably more down to your lack of experience with systemd than with systemd itself (if its true, i don;t tend to believe ACs). better get reading about systemd and its capabilities
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
look up how to use "journalctl", i'm sure even you could use it
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Finally we're back where we were before Ubuntu upended everything with upstart. We have one init system across major distros. Except now it solves all sorts of issues that were problematic on sysvinit.
Great to see we can make progress and solve problems, even if it takes an astonishing amount of wailing and gnashing of teeth. (You'd think half Slashdot was born before 1960 and learned some traditional UNIX before there even was a Linux, the way they carry on whenever anything changes).
I did try it, and reproduced the his results on Fedora 21.
That's very interesting, you're the first non-ac to report this.
Care to show me exactly what you did?
If you took the recipe given by the ac:
It is trivial to reproduce this serious problem with systemd. Pick any script in /usr/lib/systemd/*.service:
Then maybe you missed the fact that systemd doesn't re-read unit files for existing services, you have to do a "systemctl reload" after stopping the service and before restarting it. (You should have got a message warning you of this, but many people seem to misunderstand the message).
Watch this Heartland Institute video
"shit" does happen. What is interesting about the whole systemd thing is that there are a class of people, all posting AC, why lie about what happens.
I'd love to know why. I can understand that people don't like some software, but why would they flat out lie about what that software does?
How do I know these claims are lies? Because they are all posted AC, because nobody has ever claimed to have reported these defective behaviours as bugs, because I can't reproduce them even when using exactly the same environments and commands as the claimant.
Watch this Heartland Institute video
Well, there is probably a lot of even more complicated methods.
Now if you just need a simple static address I would suggest to use systemd-networkd: https://wiki.archlinux.org/ind...
I hope this one is simple enough for your use case.
you have to do a "systemctl reload" after stopping the service and before restarting it.
Sorry, I mean "systemctl daemon-reload" of course.
Watch this Heartland Institute video
Well, there is probably a lot of even more complicated methods.
I'm sorry to hear it.
Now if you just need a simple static address I would suggest to use systemd-networkd: https://wiki.archlinux.org/ind...
Oh, neat. So instead of writing two scripts (all w/ bashisms), a configuration file and a unit file, the "next best" way is to run yet another 13.000-lines C program (cat src/network/network[cd]*.[ch] | wc -l).
I can't even tell if you're trolling or just a good example of demonstrating what's wrong with systemd mindset.
I hope this one is simple enough for your use case.
No, it's not; and more to the point, I don't have a real "use case". As said:
The other day I had a spare machine sitting around [.........] [and then] I nuked [it]
You see, I already have two good solutions and this little experimental journey into the Arch world just made clear that if I hadn't moved to the BSDs back in the day, I'd do it now. Thanks, though.
CLI paste? paste.pr0.tips!
Comment removed based on user account deletion
I just updated my laptop and HTPC from 14.10. My first impressions: start/shutdown are insanely faster. I don't know exactly what the fuss is about with systemd, but this far I have only seen a positive change user experience wise.
Now if you just need a simple static address I would suggest to use systemd-networkd: https://wiki.archlinux.org/ind...
Oh, neat. So instead of writing two scripts (all w/ bashisms), a configuration file and a unit file, the "next best" way is to run yet another 13.000-lines C program (cat src/network/network[cd]*.[ch] | wc -l).
I can't even tell if you're trolling or just a good example of demonstrating what's wrong with systemd mindset.
I don't understand you, really. The procedure you mentioned was the bare minimum if you don't want to use any helper scripts or applications and is almost identical to what you need with system V init to get the same functionality: the configuration file and the two scripts are absolutely not related to systemd at all. The difference is that with system V init you need to write a script with a start) and stop) method while with systemd you have to write a service file. At the end this is exactly the same number of files, so what your problem ?
systemd-networkd is only an alternative. Personally I largely prefer C code over scripts, mainly because C code projects tend to be adopted by many distributions while scripts tend to remain specific to each distribution. The systemd vs system V story is an very good illustration of this difference.
You see, I already have two good solutions and this little experimental journey into the Arch world just made clear that if I hadn't moved to the BSDs back in the day, I'd do it now. Thanks, though.
So why did you post on a Ubuntu systemd specific discussion if you use *BSD and have only tried Arch ? AFAIK Debian still provides support for /etc/network/interfaces with systemd so basically nothing changed for the users.
I'm trying to get desktop to run under ESXi 5, and it is less than cooperative so far. Anyone else having issues with this?
Now if you just need a simple static address I would suggest to use systemd-networkd: https://wiki.archlinux.org/ind...
Oh, neat. So instead of writing two scripts (all w/ bashisms), a configuration file and a unit file, the "next best" way is to run yet another 13.000-lines C program (cat src/network/network[cd]*.[ch] | wc -l).
I can't even tell if you're trolling or just a good example of demonstrating what's wrong with systemd mindset.
I don't understand you, really. The procedure you mentioned was the bare minimum if you don't want to use any helper scripts or applications
Except for the mentioned helper scripts and the whole bloated infrastructure of systemd, sure.
and is almost identical to what you need with system V init to get the same functionality: the configuration file and the two scripts are absolutely not related to systemd at all.
How aren't they related to systemd? I'm not following, I think.
The difference is that with system V init you need to write a script with a start) and stop) method while with systemd you have to write a service file. At the end this is exactly the same number of files, so what your problem ?
So you see how pointless it is?
systemd-networkd is only an alternative. Personally I largely prefer C code over scripts, mainly because C code projects tend to be adopted by many distributions while scripts tend to remain specific to each distribution. The systemd vs system V story is an very good illustration of this difference.
Disclaimer: I have a ton of experience in C; i really like the language. But would you please think of debugability? Quickly analyzing and fixing a bug in a script means editing that script. Fixing a bug in a component that is written in C, means a) identifying what part failed in the first place, checking out the entire project, getting it to compile (which tends to include a ton of build time dependencies), of course don't forget to compile with debug symbols. Then either install the debug version, which sucks, or put it somewhere else and hope the part you're fixing doesn't use the non-debug version. And that is even ignoring the actual effort about fixing the actual bug...
A shell script? add a ``set -x'' to find out what's going wrong, edit to fix, which is usually no problem for someone who knows their shell.
You see, I already have two good solutions and this little experimental journey into the Arch world just made clear that if I hadn't moved to the BSDs back in the day, I'd do it now. Thanks, though.
So why did you post on a Ubuntu systemd specific discussion if you use *BSD and have only tried Arch ? AFAIK Debian still provides support for /etc/network/interfaces with systemd so basically nothing changed for the users.
Perhaps because I had some impressions with a journey into the systemd world to share? I do manage a few hundred Debian machines at work, so i'm not a complete stranger in the linux world.
Why do you put whitespace in front of question marks?
CLI paste? paste.pr0.tips!
1) The procedure you mentioned precisely do not use any helper script. This why it take 4 files, exactly the same amount of file on system V init.
2) The /usr/local/bin/net-up.sh and /usr/local/bin/net-down.sh are absolutely not related to systemd at all. You will use exactly the same scripts with system V init if you don't use helper scripts. The fact that this 2 scripts use a configuration file is neither relater to systemd.
3) Yes this is pointless to compare systemd over system V init by showing an example that is nothing related to systemd.
4) I also claim to have ton of experience in C. From the distribution maintainers point of view, scripts or C applications are exactly the same problem: when there have to fix something, there need to publish a new package, the fact that it require a compilation is a detail, especially given how ubiquitous is a C compiler on a maintainer machine. Well written scripts or C applications must log debug messages to help tracing problems. Now take a look at the reality: there is very few scripts that are well written, mainly because the authors assume that it's easy to read the script. On the contrary many C applications a well written because the authors know that the users will have nothing to show in case of a problem. The 'set -x' is not a magic trick that allow to find any problem a stack of scripts might have. The dependencies problem of the init scripts is one of them.
5) Because I usually wrote French and in that language we put a whitespace in front of question marks. I did not notice that it's not the same in English. http://fr.wikipedia.org/wiki/P...
1) The procedure you mentioned precisely do not use any helper script. This why it take 4 files
...two of which are helper scripts...
, exactly the same amount of file on system V init.
Not quite, but whatever.
2) The /usr/local/bin/net-up.sh and /usr/local/bin/net-down.sh are absolutely not related to systemd at all. You will use exactly the same scripts with system V init if you don't use helper scripts.
...except for those two helper scripts, yes... They are /not/ required in sysvinit. There's nothing to stop you from doing something like that on system V, but the canonical way would be to do that in the init script. So regarless of whether the helper scripts are an unrelated or an integral part of systemd, using systemd in Arch for the highly complex use-case "static IP address" apparently means one way or another, they have to appear. Stop trying to excuse that away.
The fact that this 2 scripts use a configuration file is neither relater to systemd.
Sure, there's nothing wrong with a configuration file. What you're trying to say here, not so sure.
3) Yes this is pointless to compare systemd over system V init by showing an example that is nothing related to systemd.
I don't even know what to reply to this ... odd ... statement. I'll grant you the benefit of the doubt and assume you live in some twisted sort of parallel universe where 'nothing related' means 'entirely related' or so..
4) I also claim to have ton of experience in C. From the distribution maintainers point of view, scripts or C applications are exactly the same problem: when there have to fix something, there need to publish a new package
You're missing the point. I wasn't talking about the point of view of distro maintainers, but the case when you, a sysadmin, first encounter a problem with a script or program. Please, with that in mind, reconsider that part of what i wrote.
, the fact that it require a compilation is a detail, especially given how ubiquitous is a C compiler on a maintainer machine. Well written scripts or C applications must log debug messages to help tracing problems. Now take a look at the reality: there is very few scripts that are well written, mainly because the authors assume that it's easy to read the script. On the contrary many C applications a well written because the authors know that the users will have nothing to show in case of a problem. The 'set -x' is not a magic trick that allow to find any problem a stack of scripts might have. The dependencies problem of the init scripts is one of them.
(I mostly agree with this, but it's beside the point)
5) Because I usually wrote French and in that language we put a whitespace in front of question marks. I did not notice that it's not the same in English.
Fair enough. So a twisted parallel universe it indeed is! (just kidding)
CLI paste? paste.pr0.tips!
1) The procedure you mentioned precisely do not use any helper script. This why it take 4 files
...two of which are helper scripts...
No, by definition helper scripts must already be part of the distribution.
, exactly the same amount of file on system V init.
Not quite, but whatever.
Exactly the same amount, if you don't use the system V init helper scripts.
2) The /usr/local/bin/net-up.sh and /usr/local/bin/net-down.sh are absolutely not related to systemd at all. You will use exactly the same scripts with system V init if you don't use helper scripts.
...except for those two helper scripts, yes... They are /not/ required in sysvinit. There's nothing to stop you from doing something like that on system V, but the canonical way would be to do that in the init script.
At least you recognize that (almost) the same procedure will apply to system V init if someone don't want to use his helper script. Please understand that the normal way to configure a simple static IP address with systemd is to use either systemd-networkd or the distribution specific file to do this like /etc/network/interfaces in Debian.
So regarless of whether the helper scripts are an unrelated or an integral part of systemd, using systemd in Arch for the highly complex use-case "static IP address" apparently means one way or another, they have to appear. Stop trying to excuse that away.
The fact that Arch Linux don't provides anything is strange. Think what would be the usability of a system V init without all the scripts on top of it. This is not an excuse, others distributions that use systemd simply don't require the procedure you mentioned, and event Arch document how to use systemd-networkd for a simple static IP.
The fact that this 2 scripts use a configuration file is neither relater to systemd.
Sure, there's nothing wrong with a configuration file. What you're trying to say here, not so sure.
Simply: this is not because of systemd.
3) Yes this is pointless to compare systemd over system V init by showing an example that is nothing related to systemd.
I don't even know what to reply to this ... odd ... statement. I'll grant you the benefit of the doubt and assume you live in some twisted sort of parallel universe where 'nothing related' means 'entirely related' or so..
You have perfectly understand me. You find, maybe by hazard, a very strange and unusual procedure to setup a static IP interface. The procedure use a systemd service file to call two scripts that use a configuration file and you make it a point about claiming that systemd require too complex procedure for a such simple static IP configuration. Now think is you have found the same procedure that use a system V init /etc/init.d/* script to call the very exact same scripts that use the very exact same configuration file, I beat that you will instantaneously found this procedure too complex because you can simply configure a static IP by just edit an already existing configuration file dedicated for this purpose in you distribution of choice.
4) I also claim to have ton of experience in C. From the distribution maintainers point of view, scripts or C applications are exactly the same problem: when there have to fix something, there need to publish a new package
You're missing the point. I wasn't talking about the point of view of distro maintainers, but the case when you, a sysadmin, first encounter a problem with a script or program. Please, with that in mind, reconsider that part of what i wrote
No, by definition helper scripts must already be part of the distribution.
I completely disagree, but I wasn't aware of that there's an accepted definition. Mind sharing the source?
[...] system V init helper scripts.
I'd hesitate to call the sysV init scripts "helper" scripts, because they are the central mechanism (apart from lil' init itself). The "central element" of systemd are the parts witten in C, of which there (apart form init itself) is no such equivalent in system V init.
You have perfectly understand me. You find, maybe by hazard, a very strange and unusual procedure to setup a static IP interface. The procedure use a systemd service file to call two scripts that use a configuration file and you make it a point about claiming that systemd require too complex procedure for a such simple static IP configuration.
No. I knew you'd bring up something like this, but, no.
The manual way to configure an interface is one execution of the ifconfig(8) program (or whatever is currently hip in the linux world). This is the part that has to be "learned"; you have to remember that the program's name is ifconfig, and that it accepts an interface name, followed by an address family, followed by an address. Or else, that there's a man page. That's the "hard" part, and it's the same (modulo constant NIH-ing of the interface configuration programs due to what probably is an underlying design flaw) on both sysVinit and systemd machines
Now, system V runs that command in a shell script and that's it. If now you feel like objecting "but it means i need to learn the shell!", then here's the important piece you're missing: If you're using a unix-like OS, and you don't know how to handle a shell, then there's your problem. It's the primary user interface. It's not only for running init scripts but provides a direct value for almost every other task imaginable.
Now, in systemd, one has to additionally learn systemd. It doesn't mean you can forget your shell. It does mean, however, that you have to invest significant time to understand and learn the huge piece of shit that is systemd. Apart from professional sysadmins, whose time would be better spent administering their systems, I don't realistically see anyone else going to do that. It's video tutorials and just-do-this-special-trick wiki articles all the way.
Speaking of, is proper documentation at least theoretically available now?
Sysadmin are not the only users of Linux. Real sysadmin already known that leading distributions support the usual way of configuring a static IP address even with systemd. Proactive sysadmin already have learned systemd and are ready to manage it if it's not already the case. There is just a noise from a minority of 'sysadmin' that are neither maintainers, nor proactive, nor willing accepting that systemd will not be the end of the universe, and so frustrated that there can only wrote there distress in the forums.
Hahahahah.
CLI paste? paste.pr0.tips!
1) What's wrong calling a helper script a script that help you to do something in a more simple way? Now if it's not from you the script came from something else. In the context of this discussion this is from the distribution.
2) It's not the central part of system V init. The most obvious prof of this is that each distribution family have a different set of helpers scripts. Just take a look at the reality:
https://packages.debian.org/je...
https://packages.debian.org/je...
https://packages.debian.org/je...
If you list the source patch archive http://http.debian.net/debian/... you will see that ALL the initscripts are Debian specific and not part of the original sysvinit http://http.debian.net/debian/... .
Configuring the network is not the same in Fedora an in Debian. On of the long term goal of systemd is to normalize the situation.
3) The problem is to configure an interface automatically when the system boot. In most distribution the users don't even have to use the real command to setup the interface to do this. And you are completely wrong about your ifconfig and script theory: the vast majority of network interfaces are today setup by a dhcp client, or an application like NetworkManager according to DBUS messages coming for example from a GUI application, all written in C or C++, or maybe something other, but for certain shell scripts play a marginal role here. The shell is NOT the primary interface for the vast majority of the users, sysadmin is not the dominant specie in the Linux world.
4) Systemd is really simpler to learn that shell script. I switched some months ago to systemd and found all the documentation is needed in the usual man pages. I took me less than 1 hour to learn the basic commands and I was able to convert the custom part of the system less than one day.
5) You can laugh as you want, this will not change the reality: /etc/network/interfaces with systemd.
* Sysadmins are a minority of Linux users.
* Distributions like Debian support
* There are sysadmin already using systemd.
* To date there is no enough maintainers against systemd to have successfully make an serious alternative available and ready to use by the distribution.
* Systemd transition is now done by Fedora, Ubuntu and Debian and there are still there.
* Still, a lot of forum get post from 'sysadmin' complaining.
1) What's wrong calling a helper script a script that help you to do something in a more simple way? Now if it's not from you the script came from something else. In the context of this discussion this is from the distribution.
I was asking for a source on your definition, not for you repeating your belief.
2) It's not the central part of system V init. The most obvious prof of this is that each distribution family have a different set of helpers scripts.
Okay, init scripts are not a central part of the sysV init system. Today i learned. (Hint: init scripts /are/ the central element, conceptually, of system V init.)
3) The problem is to configure an interface automatically when the system boot. In most distribution the users don't even have to use the real command to setup the interface to do this. And you are completely wrong about your ifconfig and script theory: the vast majority of network interfaces are today setup by a dhcp client, or an application like NetworkManager according to DBUS messages coming for example from a GUI application, all written in C or C++, or maybe something other, but for certain shell scripts play a marginal role here.
I suggest you practice reading comprehension, because you're so utterly missing the point, it's not even funny anymore. Hint: I claimed nothing about any of the straw man you're tearing down here. In particular I didn't suggest that users ought to ifconfig manually, or configure there IPs statically. If your attention span is too short to just read and follow the reasoning in order to understand what point i was trying to make, i can't help you.
sysadmin is not the dominant specie in the Linux world.
Another straw man, I didn't claim any of this. But now that you say it, yes, they actually are. People running linux at home essentially are their own sysadmins, people who run linux at work tend to rely on a sysadmin to do all the adminstrative crap for them.
The shell is NOT the primary interface for the vast majority of the users, sysadmin is not the dominant specie in the Linux world.
It being ignored by users does not mean it's not the primary user interface anymore. You simply cannot completely admin/fix your system with a shiny GUI. So strictly speaking, the shell is the *only* real user interface.
4) Systemd is really simpler to learn that shell script.
I'm starting to wonder whether you're missing the point on purpose, or whether it's actual bad reading comprehension. I'll repeat myself, once more: Learning systemd helps you at doing systemd-specific stuff. Learning shell helps you at using your OS. Those two things have a large difference in scope of applicability.
* Sysadmins are a minority of Linux users.
Yet, they are fully exposed to all the shitstorm, and their job is to shield the users from that. So quite an important minority, if at all.
* Distributions like Debian support /etc/network/interfaces with systemd.
So what?
* There are sysadmin already using systemd.
So what? There are even more sysadmins running Windows networks and big monolothic "networking appliances"
* To date there is no enough maintainers against systemd to have successfully make an serious alternative available and ready to use by the distribution.
That's only if you're ignoring existing solutions.
* Systemd transition is now done by Fedora, Ubuntu and Debian and there are still there.
So what? Also, what does "there are still there" mean?
* Still, a lot of forum get post from 'sysadmin' complaining.
Yes. Do you really believe this would be the case if there was nothing wrong with systemd?
Note that all questions are of rhetorical nature, i'm not going to feed you any more.
CLI paste? paste.pr0.tips!
1) This is my definition is the context of this discussion. If you don't like it we can agree to name it differently. This will not change the reality that the procedure you mentioned did not use the usual infrastructure found on distribution to setup a static IP address.
2) Fine that we agree on this. But system V init in a C code that do exec(). The fact that it's usually a script is not required by system V init. But the main problem is not really script vs binary, the main problem is precisely the lack of normalization because anything on top of the bare minimal original system V init code is distribution specific.
3) The fact is that on most leading modern Linux distribution, this is not a script that call a command that setup the IP address of a network interface, because there use the NetworkManager package. Again you might not like it, but this will not change this reality. If you think that I don't understand your point, please try a least to repeat it. Actually you only deny some point.
4) Certainly not the system administrator according to http://training.linuxfoundatio... . I don't see the point calling a user system administrator regarding network operation when there simply let the dhcp client automatically configure an interface. Nor in the case where there select a SSID and enter a key. Nor when there use the NetworkManager GUI to select the Manual method on the IPv4 tab of an interface. In all those examples there is no scripts and no command involved.
5) It's perfectly possible to manage a very large number network situations with NetworkManager GUI without using any shell, script, or command. This is the primary interface for most of the users, including myself, even after working for years in a company that build routers. As a side note, this kind of GUI was all the customers constantly asked for, liked and used. Only the engineer and support used command to verify the state of the system. In the embedded systems I build today, the customer ask to configure the network from a web UI that push the configuration on a SQL database on the target, to illustrate how far is you idea of script and command.
6) Agree on the fact that scripts cover a more generic knowledge. Sadly this is not so useful on a system that use less and less scripts. I understand that you regret this evolution, but as the complexity of the system increase, scripts that are different in each distributions have reach a limit for many maintainers. Thing could have been different if the original system V init package would have normalized the script stack early. There failed to do that, now the time is probably over for them as systemd not only normalize the situation across the distributions but also bring a lot of new features on the table.
7) I wonder what's your work environment to be exposed to such 'shitstorm'. I have see time to time worker having to ask there superior to have the right to install a Linux system, but I never see the network administrator complaining.
8) All the last points is to show that your laugh are strange because all points can be independently verified true. There is no rhetorical nature in any of them, this is just a list of facts.
Okay i said i would not continue feeding you, but here's one last bite:
1) which is irrelevant to the topic because i picked the 'do it manually' example just for the purposes of illustrating how knowing the shell is useful in a generic way, while knowing systemd does not. Stop pretending that i had proposed everybody ran ifconfig to do things manually. If you really think that was the gist of my statement, then you must have missed the point (which is odd because you agreed with it that particular part later on)
I cannot really parse 2), especially the first sentence, but i agree that "normalization" (which i take for 'writing POSIX shell scripts instead of stuff riddled with bashisms') might have been a good idea, but then again, this is linux and the distro diversity is, apparently, a feature. (you can see the (rough) concept working very well on the BSDs (which don't do system V init, but rc is also script-driven (with configuration separate))).
3-5: Hilariously naive. This is all assuming that everything works, which is circular reasoning of the most ridiculous kind in a discussion directly related to the question whether things do or do not work. When something fails, you better hope that your GUI allows you to fix it, because if it doesn't, or if the GUI itself fails, you're left with the shell. I don't see how you can deny that that is the primary user interface.
6. Yeah, we call this 'integration' and 'feature creep'. It's a direct conflict with the principles that have led unix to its current success. We've seen how the integrated way turns out to work on other platforms. If you're in for a car analogy, this is like trying to tell bikers that they really ought to add another set of wheels, and replace their handlebar with a steering wheel, because it works so well with their cars.
7. the 'shitstorm' is implicit in the trouble and apparent pointlessness of 'just-because' migrating a larger set of computers to use the shiny new system. you might be used to just installing using a live cd and after that it more or less works, but in a bigger (and at my workplace that isn't even big, a mere ~200 machines) setup it's not that simple. (to get ahead of the obvious response: yes, installation, configuration etc is completely automated, the workload is not the installation itself, but ensuring "everything" the users are exposed to continues to work as expected. fixing a dozen self-maintained patches to components which have been upgraded (yes, we always submit the patches upstream, some maintainers don't care). I don't even want to imagine what would happen if the servers were linux based, too. For comparison, the one Linux server that we do have (for automated installation of the desktops, nightly maintenance etc) needs more hand-holding than basically the remaining two dozen BSD servers need combined. The former's uptime tends to be measured in days, the latters' in years...
8. I think I know better which of *my* questions are of rhetorical nature and which are actual questions, because, you know, i'm the one typing them. Or did reading comprehension get into your way again?
CLI paste? paste.pr0.tips!
1) So you admit to have purposely chosen the procedure that use shell scripts only to complain that it, err... use 2 shell scripts???
2) Diversity is an advantage up to the point where the added complexity is not too big. Sometimes it better to normalize to a common parts to simplify.
3) While making a good an complete enough GUI is fare from simple, this don't imply that this is impossible. NetworkManager is now mature enough to be used in a very large use case. This is the primary user interface for a lot of users. Most of them don't have a clue about shell script, so it's impossible to say to them that a shell script is there primary user interface. This is very factual: nor users, nor NetworkManager use script. I can only concede that commands in a shell (no script) are a possible fallback solution in case of problem impossible to solve with the GUI. But I disagree that a possible fallback that most users will never use is defined as a primary user interface.
6) Linux is not so UNIX anymore in the sense that it integrate more and more features compared than any others UNIX kernel. More and more Linux syscalls are not related to any UNIX standards. This is a new world emerging from UNIX but not bound to it anymore. Goodbye to anyone that like to stay with the UNIX way. This can make a lot of sens for some situations, and nobody will prevent them to do so. This is there respectable choice, and there could make an effort to respect the choice of others that want to follow the Linux way, unbound to the UNIX limitations. udev and systemd are required evolution steps to solve problems that have found no better solution using the UNIX traditional way.
7) Then I don't understand why you still use a Linux machine if BSD is so better for you. Really strange that your uptime is so small. I usually only reboot for hardware maintenance. One of the Linux servers actually show a uptime of 2121 days has soft RAID-1 and several virtual machines running on it. I plan to change it this year because some hardware parts are over 10 years old, but from the software point of view it run just fine.
8) As you have said to me 'Hahahahaha'...
1) God dammit, no. I give up trying to explain this to you since it looks like you're intentionally trying to miss the point.
2) That statement is meaningless and pulled out of your ass.
3) So there are two interfaces, one allows you to do some stuff, the other allows you to do all stuff, including fixing the first mentioned interface. BTW I'm not saying that a shell script is the primary interface, but that the shell is. The command line shell in particular. Do you understand the difference? (Rhetorical question; clearly you don't otherwise you wouldn't say something as ridiculous).
6) Yes, no shit, linux is not unix. That doesn't invalidate my point that the success came from adhering to the unix philosophy. There are already successful OSs that adhere to the opposite, so trying to turn linux into one is futile and stupid.
7) What in the actual fuck makes you believe I'd run Linux machine other than at work? I've made it clear 2 or 3 times, seeing how much you're missing or skipping here, is this language barrier?
You're not rebooting for security related fixes to the kernel or core components like libc? That figures.
8) The fact that this makes you laugh only shows that there really must be some sort of language barrier...
CLI paste? paste.pr0.tips!
8) Yes there is kind of language barrier as I usually speak French. Now the fact that you react with so much emotions and use rhetorical question don't help either our mutual understanding.
We obviously have each confidence in a different model of what the architecture of a distribution must look like. Probably that the use case we assume each for our analysis are very different too, and that could explain why we have some contradictions. If for you the shell very important, for me this is not the case.
3) I don't want to open an other conflict but I do observe that the leading Linux distributions make effort to make users able to manage there machine as much as possible without required to display a shell to the users. This story is about Ubuntu first release with systemd, a distribution that is popular for peoples that have no clue about the shell. On this distribution a typical user will let NetworkManager try to configure the network automatically as much as possible, and if a manual setting is to be enter, the user most likely will do it using the NetworkManager GUI. The Arch procedure you looked at is hard to fit in the same users context.
6) I don't think that Linux try to adhere to the opposite of the 'unix philosophy' and I don't observe that shell scripts play an important role in unix outside of the stack on top of system V init. After all, a lot of unix tools are written in C. I also don't think that the distributions make futile and stupid choice especially regarding the challenge of the experience there try to give to users without any shell knowledge.
7) I referred to you text: "the one Linux server that we do have (for automated installation of the desktops, nightly maintenance etc) needs more hand-holding than basically the remaining two dozen BSD servers need combined." I still wonder why you use Linux for this particular task if Linux cause so much problem for you and that you are happy with BSD.
Anyone with a more qualified opinion want to chime in as to whether it's worth it to go for the 'CUTTING EDGE' version 15 for a guy using 14.04 atm? I am using this machine for some light gaming, word processing, internet & basic software development
I do observe that the leading Linux distributions make effort to make users able to manage there machine as much as possible without required to display a shell to the users.
Yes, that's basically been (at least) ubuntu's goal ever since it was first released. And, in my eyes, that's pretty pointless an idea, because running a GUI-only Linux gives you the worst of both worlds: GUIs that look and feel somewhat "bolted on", don't integrate nice with the system (due to the fundamental mismatch of paradigms) and are prone to frequent and major hiccups ranging from "just a short lag" to crash-and-burn. While getting the shit end of the GUI landscape (both Microsoft and Apple have that part worked out *much* better), you're also missing out on the efficiency and flexibility offered by the shell and the standard toolset. So what's left?
Ah right, a ton of free GUI programs a few of which even remotely usable (though generally inferior to their commercial counterparts). So, honestly, I don't get it. The use-case for GUI-only Linux, that is. To put it as a car analogy, it's as if you'd buy a shiny new car, then put in reverse and from then on completely ignore the gearbox, because reverse kind of works and it still takes you everywhere with 20 km/h. Only in the rare occasions where you accidentally break your rear window from reversing into something, you'd for a short moment shift into a forward-gear to get you out of the mess, then continue reversing.
This story is about Ubuntu first release with systemd, a distribution that is popular for peoples that have no clue about the shell. On this distribution a typical user will let NetworkManager try to configure the network automatically as much as possible, and if a manual setting is to be enter, the user most likely will do it using the NetworkManager GUI. The Arch procedure you looked at is hard to fit in the same users context.
Yes, that's right.
6) I don't think that Linux try to adhere to the opposite of the 'unix philosophy' and I don't observe that shell scripts play an important role in unix outside of the stack on top of system V init.
I've just sampled a few Linux machines i have access to (running debian stable and -oldstable, respectively), a quick look at /bin, /sbin, /usr/bin and /usr/sbin turned up around 300 shell scripts completely unrelated to system V init. Most of them simply don't have a .sh extension so when listing the directory they don't stand out. YMMV, would be interesting to see if that number goes down on systemd-enabled distros to see if your statement is true or not.
After all, a lot of unix tools are written in C.
Yes, but don't forget that "programs" are the building-blocks of shell scripts; it's one level of abstraction higher. The tools itself are written in C for good reasons (efficiency, mainly), the shell itself too, of course. It would be quite difficult to come up with the standard toolset completely written in shell, including the shell itself :)
7) I referred to you text: "the one Linux server that we do have (for automated installation of the desktops, nightly maintenance etc) needs more hand-holding than basically the remaining two dozen BSD servers need combined." I still wonder why you use Linux for this particular task if Linux cause so much problem for you and that you are happy with BSD.
The purpose of this server is to deal with all the desktop/office machines which run Linux. One half of the user base are (mostly surprisingly computer-illiterate) mathematicians, the other half is entirely computer-illiterate non-scientific personnel; secretarians, a janitor, etc. They're all expecting computers that work, are GUI-only driven, and, obviously, they're users, not root. Since it's quite a number of users, we discover quite a numb
CLI paste? paste.pr0.tips!
I understand that you find the GUI-only Linux ubuntu's goal pointless, but at the same time I read that you have many users asking for precisely this kind of systems. While your are doing the admin work instead of them within the company, it's logical that those peoples will select a distribution with GUI outside of the company related work. After all when those people use a smartphone, a router or a TV, all potentially running Linux, there don't expect to see anything other than GUI.
If we talk about the admin work, it's not fair to count /usr/*. On a typical Debian Jessie I have: /bin/* /sbin/* | egrep ELF | wc -l /bin/* /sbin/* | egrep script | wc -l
file
233
file
36
And a majority of the scripts are just to make usual commands work on compressed files. So I still hold my claim that the admin work outside of system V init stack is not essentially based on scripts. Far from that actually, and to push this to the limit, just look at the busybox project. I have not verified, but I suspect that a machine with systemd and busybox could be close the be usable for simple tasks without any shell interpreter. Actually I think there is still some binary that expect a shell evaluation at some point, but this is probably doable to work around them.
But as you have noticed, using command on a shell don't imply shell script. The NetworkManager project for example is split into different parts, essentially: 1) the daemon, 2) the CLI, 3) the GUI. This allow to make some clean implementation not related to the preference of the user/admin regarding the CLI or GUI. This also help to make the GUI a relatively simple project that only query data, display them, allow fill form and send them. With this kind of project, you can use CLI and script if you want, as you can use GUI if you want. The trend is to apply this design to more and more parts of the systems, and systemd is a way to go forward in that direction. Personally I would like to also see a Web and SQL interfaces for all of those parts as this is basically what my customers are asking for.
If I understand you correctly your BSD boxs don't run the same kind of applications as the Linux box, so it's not fair to compare the stability of a GUI application by the kernel or distribution where it is executed. You don't have to reboot to update the libc and you are free to decide if you like to update you kernel depending on the risk that apply to your situation. BSD kernel are released less often it seem, this don't make it less buggy as your RAID experience has show, but simply a consequence that his community of developers is smaller than Linux.. I really wonder what you can find so unstable in the Linux kernel because it's rock stable for me even on embedded systems where the workload and driver set is quite different to anything usually tested in the cycle of a kernel release.
If we talk about the admin work, it's not fair to count /usr/*. On a typical Debian Jessie I have:
file /bin/* /sbin/* | egrep ELF | wc -l
233
file /bin/* /sbin/* | egrep script | wc -l
36
I don't understand why it wouldn't be fair to count /usr. There's no clean separation between what goes into /*bin and what goes into /usr/*bin in Linux; you find many elementary programs in /usr for twisted, for historical and for essentially no particular reason. Even having /usr be a separate partition is not recommended anymore, unless you're into building your own initrd (which non-admins wouldn't ever do, by (your) definition).
And a majority of the scripts are just to make usual commands work on compressed files. So I still hold my claim that the admin work outside of system V init stack is not essentially based on scripts. Far from that actually, and to push this to the limit, just look at the busybox project. I have not verified, but I suspect that a machine with systemd and busybox could be close the be usable for simple tasks without any shell interpreter.
Wow, hold on. Realize what you're saying, please. You're not exactly going to click on the programs provided by busybox in a GUI, are you? Or most of the other programs for that matter. /only/ make sense in a shell, and by extension, are get used in scripts. Why provide busybox at all, otherwise??
It's the very point of busybox to provide a set of programs which
NetworkManager [...] is split into different parts, essentially: 1) the daemon, 2) the CLI, 3) the GUI.
Okay, I wasn't aware of that split. If it's indeed a clean separation, then it's not so bad, indeed.
I would like to also see a Web and SQL interfaces for all of those parts as this is basically what my customers are asking for.
*vomits*
If I understand you correctly your BSD boxs don't run the same kind of applications as the Linux box, so it's not fair to compare the stability of a GUI application by the kernel or distribution where it is executed.
Not sure how a GUI application is related here, FAI clearly is not a GUI and the Linux server obviously doesn't run X11. ;)).
But you're right, it was an unfair comparison, let's see:
The Linux server run: a) PXE/thttpd for network booting, b) nightly cronjobs to do maintenance on the desktops, c) a Debian repository.
The BSD servers are: fileserver, redundant mailservers (smtp(s)/pop3(s)/imap(s)), redundant nameservers, DHCP, httpd, sshd, redundant LDAP, print server, a captive portal for one of three wireless networks, firewalls, NAT gateways, svn server, you-name-it. Probably a few other common services that currently don't come to mind. Essentially a full-fledged, rather traditional production network, with amazing availability. (You know, the kind of thing people mistakenly believe "the cloud" to provide
So, unfair a comparison indeed, but not really the way you meant it, i guess.
You don't have to reboot to update the libc
Don't be ridiculous. Every userspace process directly or indirectly uses libc, so yes, instead of rebooting you could indeed manually stop all the services and kill all remaining tasks until the system is essentially single-user, and then get all the services going again. But no, only a complete idiot would actually do that. For all practical purposes, it would equal a reboot (and underlines my point of high degrees of hand-holding)
and you are free to decide if you like to update you kernel depending on the risk that apply to your situation.
Sure, but there's only one policy here that makes sense, and it equally applies to all
CLI paste? paste.pr0.tips!
dpkg --get-selections | wc -l
3423
dpkg -L $(dpkg-query -Wf '${Architecture;-20}${Priority;-40}${Package}:${Architecture}\n' | egrep "all|amd64" | cut -b21- | egrep "required|important" | cut -b41-) | grep "/usr/s*bin/.*" | xargs file | egrep " script, " | wc -l
56
And 17 of them are perl scripts. The rest are mostly not so used commands. So I still hold my claim that the admin work outside of system V init stack is not essentially based on scripts.
I mentioned busybox to show that binary commands is enough to admin a box (outside of system V init), not about a supposed busybox GUI.
I have see a lot of Linux boxes with load like the one you describes on your BSD box, this is not impressive at all. Now, did your Linux kernel really crash ? I understand that you reboot for each libc or kernel update, this is your choice, but certainly not a stability problem.
About the libc update, you might find more simple to just reboot, but again this is your choice, not a stability problem. Now in case of libc upgrade, how did you do with your BSD boxes ? Or the BSD libc is so perfect that no upgrade is required ? Hint: https://www.freebsd.org/securi...
You call me ridicule, but I largely prefer restarting some services on a remote machine., and even more when the machine also act as a NFS server, or a router, or a firewall, or have virtual machines. It's a choice, and I will not call you ridicule for your own choice.
If you are so conservative to reboot each boxes as soon as a libc or kernel upgrade exists, then I wonder how your BSD boxes could have uptime a "few orders of magnitude less shitty".
I do tests on the system I deliver, and my customers do tests too, I just say that this is tests not usually done in the cycle of a kernel release [by the kernel maintainers] (last part added for you understanding).
You can't usually buy the systems we design as there are not for consumers. What I can tell you is that we have build systems where conformity to part of aerospace, or railway, or automotive, or civil engineering standards are required. Nothing highly critical, but still with a good chunk of audit and conformity tests. Customers are happy enough with our work to allow, to setup our own company 4 years ago.
But I would like to remain you the this discussion is about the fact hat Ubuntu has released his first version with systemd :-)
I still hold my claim that the admin work outside of system V init stack is not essentially based on scripts.
And I still call bullshit because scripts are every admin's (and that doesn't even stop with systemd) best and most valuable tool. I don't presume you're seriously going to claim that even admins could completely forgo of the shell? Or would want to do that in the first place? (Hint: automation). If a sys- and network admin entirely using GUIs to do their job is what you imagine, then you're so far away from reality, it's not even funny anymore...
I mentioned busybox to show that binary commands [are] enough to admin a box
And what do you think is the execution environment for literally every single of those tools? Seriously if you were even slower, you'd go backwards.
I have see[n] a lot of Linux boxes with load[s] like the one you describe[d] on your BSD box[es], this is not impressive at all.
That wasn't mean to impress, i was merely responding to your claim about unfair comparisons. Nice try, but it would help if you would consider the parts you reply to in their actual context, instead of trying to create and tear down straw men like this.
Now, did your Linux kernel really crash[]?
Yes, I've seen uncountable instances of linux panicing.
I understand that you reboot for each libc or kernel update, this is your choice, but certainly not a stability problem.
I didn't say the reboots required by updates were a stability problem; they are an availability problem, however.
About the libc update, you might find [it] simple[r] to just reboot, but again this is your choice, not a stability problem. Now in case of libc upgrade[s], [what] [do] you do with your BSD boxes[]? Or [is] the BSD libc [] so perfect that no upgrades [are] required[]? Hint: https://www.freebsd.org/securi...
Hint: It's not FreeBSD, and Hint: if the BSD servers receive a libc update that fixes a security issue we're affected by, then the server gets rebooted. Not that i hadn't already said that in the post before.
You call me ridicul[ous], but I largely prefer restarting some services
if it's a libc fix, "some" services will not cut it.
It's a choice, and I will not call you ridicul[ous] for your own choice.
Well if you choose to go for a reboot-less libc security upgrade just to keep uptime (yet losing availability), then i'd actually ridicule you for that, because it'd be a moronic waste of time. If you get paid by the hour, maybe.
If you are so conservative to reboot each box[] as soon as a libc or kernel upgrade [appears], then I wonder how your BSD boxes could have uptime[s] a "few orders of magnitude less shitty".
See above.
aerospace, or railway, or automotive, or civil engineering standards
So, let's assume you're designing some aerospace-grade embedded system, linux based no less. Would you make it use systemd? Why not?
But I would like to rem[ind] you th[at] this discussion is about the fact [t]hat Ubuntu has released [their] first version with systemd :-)
Sure. Let's see how it works out.
CLI paste? paste.pr0.tips!
The fact that a sysadmin use a shell command interpreter did not imply that the command he call are shell script. I think that I have show enough prove that shell scripts are not as essential outside of system V init as you used to claim. Now, this don't prevent anyone to use a shell to get a CLI and to write some scripts if he like to do so. You seem to forget that the maintainers decision to switch to systemd is not to remove power to the users, but to make the maintainers work more easy and reliable across multiples systems. I never stated that sysadmin should be forced to use GUI, and projects like systemd or NetworkManaged take care to provides very good CLI, so I don't understand how stressed you are about the systemd architecture.
About the comparison between Linux and BSD kernel, you still failed to explain why your BSD boxes can't do the work you are so angry to run on Linux boxes. At some point you have to admit that the Linux box do something that your BSD boxes can't do. You never explain the part of the Linux kernel that cause the supposed crash, and I am very curious about this because triggering a kernel crash is usually not so easy.
A reboot for a upgrade will not affect to much the availability because it only affect the users for a minute or so, contrary to a stability problem like crash that could affect the users as long as someone take to reset the machine. So I think we can at least agree that the upgrade on Linux is no affecting your operation more that your BSD boxes. It you really have a particular problem with your Linux boxes, than must be something as severe as a kernel crash, not because of upgrade. And if you can really crash a up-to-date Linux kernel so often, then you must see a clear pattern of the subsystem that cause the crash.
I suspect hat your BSD are in fact netBSD. If this is the case this apply to them: http://www.netbsd.org/support/...
Restarting services take less time than rebooting (especially with systemd), this is less risky on a remote machine, and this affect the availability far less than a reboot because many services are capable to handle restart very fast, and others services are unaffected. In industrial systems there are situation where we just want to upgrade some part of the system while still let running others realtime parts unaffected. You might be in a context where you can just reboot, but there exists others contexts with more constrains than in your environment. You can ignore this fact, as you can continue to insult me, this will simply change nothing to the reality of the facts. And no, our company don't charge per hour.
I would be more than happy to design any futures systems with systemd into it. I delivered my first design with systemd last week and given the success I see no reason to go backward. A mission/life critical aerospace system with not use a Linux kernel anyway. But for less critical functions, even in aerospace, this could done. In fact there is already exists systems running Linux in aerospace environment, it's not hard to find on the internet.
The fact that a sysadmin use[s] a shell command interpreter d[oes] not imply that the command[s] he call[s] are shell script[s].
So your idea of a sysadmin is someone who keeps typing the same commands over and over again, every day or week, rather than automating them in a script? Good grief.
I think that I have show[n] enough pro[of] that shell scripts are not as essential outside of system V init as you [] claim.
So you don't understand what a proof is, besides not having a faint clue of real-world systems administration. Duly noted.
Now, this do[es]n't prevent anyone [fr]o[m] us[ing] a shell to get a CLI [lol what] and to write some scripts if [they] like to do so. You seem to forget that the maintainers['] decision to switch to systemd is not to remove power [fr]o[m] the users, but to make the maintainers['] work [] eas[ier]
Ah, okay, maybe that's the issue then. Because so far i had assumed systemd would provide immediate benefits to the users, because that's kind of what a million pimply-faced systemd fanboys claim.
s[o] I don't understand how stressed you are about the systemd architecture.
I thought i had made that clear. Anyway, the recent 3-4 comments were more about shell scripting in general than about systemd in particular.
About the comparison between Linux and BSD kernel, you still fail[] to explain why your BSD boxes can't do the work you are so angry to run on Linux boxes.
You clearly are a complete idiot and not paying attention, if you would actually follow this moronic discussion you'd have ran across:
I'd love to have them run *BSDs, but since they're even less meant for the 'GUI-only desktop' use case, the amount of work required to support that would require more than four admins (good ones of which are hard enough to find for linux already).
A reboot for a upgrade will not affect [???] the availability because it only affect[s] the users for a minute or so
Thanks for another demonstration of how all your sysadmin "knowledge" is purely theoretical and pulled out of your ass. Read this.
So I think we can at least agree that the upgrade on Linux is no[t] affecting your operation more that your BSD boxes.
That's only because the Linux server sits around idle unless it's 4am or an office machine is reinstalling.
And if you can really crash a[n] up-to-date Linux kernel so often, then you must see a clear pattern of the subsystem that cause[s] the crash.
I have already realized you're not paying attention, or mentally incapable of doing so, that was in a timespan of at least 5 years. And when talking about "Linux machines i've seen crashing", I'm not specifically referring to that one particular single FAI server. That's not to say that it hadn't had its share of problems, but the bulkload of Linux machines i've seen panicing happened in private contexts. I'm still not sure if you're seriously trying to say that Linux would be free of problems. But you're a troll or a raging zealot, so whatever.
I suspect hat your BSD are in fact netBSD. If this is the case this apply to them: http://www.netbsd.org/support/...
I (obviously) know that p age, and had you cared to actually take a look at it, most of those SAs are userspace related, and we have evaluated every kernel-related one for whether it affects us or not. The user-accessible ssh login gateway was affected to some, and subsequently got rebooted.
Why am i explaining this to an armchair sysadmin?
Restarting services take[s] less time than rebooting (especially with systemd), this is less risky on a remote machine, and
CLI paste? paste.pr0.tips!
You can use shell scripts to automate your work if you like and use systemd commands into your scripts without any problems. The point is that systemd don't require scripts to work and is not based on scripts, as for the large majority of commands used for basic administration. You can keep trying to avoid to recognize the reality of the facts by just saying that I an idiot or ignorant., this again and again does not change the facts.
Yes systemd provides benefits to the users. What I have say id that systemd don't remove power to the users.
No, you have not make clear what real and factual problem systemd might have for your. You have show a poor knowledge of what systemd really is actually and you react with far too much emotions to be able to generate a simple list of facts.
4 more admins to support the same workload on the BSD box compared to a Linux box? Not really efficient. I understand why Linux make you so angry...
If you like definition: http://en.wikipedia.org/wiki/A... Clearly restarting a services take less time than a reboot, and a crash that require a manual reset is the work case. If you reboot like you like to do, the fact that the machine is idle or full loaded will change nothing. You still fail to provides real facts that explain why you find Linux so inferior compared to BSD.
You have say many time that BSD is superior to Linux (by order of magnitude), but you allay failed to prove your claim. Now you are spanning the time and includes private use into the context. Just saying that something is crap is not going to convince anyone, especially if after so many messages you are still incapable to details a single factual example.
What prevent you to do the same security management on Linux as you do on BSD? This do not depend on the OS, nor on systemd / sysvinit. A libc security fix very rarely affect the security of all the processes in a system. Free to you to degrade the availability of the servers by rebooting them if you want, but again this has nothing to do with Linux or systemd. And for your knowledge: Debian and Ubuntu automatically restart systemd/sysvinit in case of libc upgrade (and the services listed as affected). It's not a mental challenge to verify this fact. The procedure you describes seem to imply that netBSD is not able to do the same.
Yes this is a success because multiples devices was tested across very different operating conditions transitions, and systemd not only did fully work as expected, but this was a pleasure to operate remotely since all the status and management are more simple and coherent than with sysvinit. I named all the custom applications with the same prefix, so a simple 'systemctl status prefix*' show everything at once.
You still show irrational stress about systemd. The reality is that all majors distributions have adopted it, so yes it will go into embedded systems, and yes it will go into aerospace environment over time but certainly not into critical grade application (nor sysvinit anyway).
Bye,
4 more admins to support the same workload on the BSD box compared to a Linux box? Not really efficient. I understand why Linux make you so angry...
Try reading instead of gibbering like a drooling idiot. That was not about supporting a linux server, but supporting a desktop GUI-only installation base for clueless users, you clueless twat.
CLI paste? paste.pr0.tips!
I have read you, and I have not used the word "server" in the context of this "4 admins more" paragraph. I have perfectly understand that you are talking about your users that you fail to convince to use BSD as you fail to convince me to use BSD. Despite all your angry comments about Linux and systemd, at some point you should have to agree that actual Linux distribution bring a more usable system for for more users than BSD. Wherever you dislike this situation will change absolutely nothing.
Easy escape of all others point?
Easy escape of all others point?
I don't feel like wasting more time with you by deciphering your incoherent gibberish and giving long-ish answers just to find you aren't reading them anyway.
CLI paste? paste.pr0.tips!
How about you go fuck yourself? Fucking idiot...