Debate Over Systemd Exposes the Two Factions Tugging At Modern-day Linux 863
walterbyrd (182728) sends this article about systemd from Paul Venezia, who writes:
In discussions around the Web in the past few months, I've seen an overwhelming level of support of systemd from Linux users who run Linux on their laptops and maybe a VPS or home server. I've also seen a large backlash against systemd from Linux system administrators who are responsible for dozens, hundreds, or thousands of Linux servers, physical and virtual. ... The release of RHEL 7 has brought the reality of systemd to a significant number of admins whose mantra is stability over all else and who perhaps had not waded into the choppier waters of Fedora or Debian unstable to work with systemd before it arrived in RHEL.
How about we hackers? (Score:5, Insightful)
I know quite a few of us in hacker culture who hate the fact tha systemd does not feel UNIXy at all. It breaks practically every principle of the UNIX philosophy. Reminds me of working with windows, and that is never fun.
Re: How about we hackers? (Score:4, Insightful)
FYI the Linux kernel does not follow the unix philosophy either, the GNU Hurd does!
Re: (Score:3, Funny)
Is that actually usable in any kind of production environment?
Re: How about we hackers? (Score:5, Funny)
That's exactly the point.
Re: (Score:3)
FYI the Linux kernel does not follow the unix philosophy either, the GNU Hurd does!
speaking of corrections:
to a significant number of admins whose mantra is stability over all else
should read:
Re: How about we hackers? (Score:5, Insightful)
That's right, Linux is monolithic, but on the other hand--and this is a crucial difference--Linus is hugely concerned about preventing breakage. Of all the large packages I use, the kernel is the one that gives me the least worry when it comes to upgrade time.
L. Poettering, on the other hand, seems to relish in breaking things. He sure isn't big on commiserating with people whose systems his code has broken.
Re: How about we hackers? (Score:3, Insightful)
The rule Linus repeats over and over is "Don't break user space". Love your observation and point.
I am personality of the following mindset, I think init could be cleaner. I think the ideal replacement would be a simple replacement of init functionality, not a huge suite, with tie ins to logging, etc. So while I was excited about the prospect of systemd when I heard about it, the reality is not exactly what I had hoped.
That said, I do have this view point. I'm not willing to put in the time to work on b
Re: How about we hackers? (Score:5, Insightful)
Yeah, I've done a fair bit of time as sysadmin of several networks AND enjoy the cool stuff that comes with change and improvement in hardware and software over time.
Systemd no doubt will have growing pains associated with it, but I still remember the "growing pains" associated with kernel 2.0 (the first multiprocessor kernel) and issues with resource locking and ever so much more. Anybody want to assert that this wasn't worth it, that "single core/single processor systems were good enough for my granddad, so they are good enough for me"? Server environment or not?
Decisions like this are always about cost/benefit, risk, long term ROI. And the risks are highly exaggerated. I'm pretty certain that one will be able to squeeze system down to a slowly varying or unvarying configuration that is very conservative and stable as a rock, even with systemd. I -- mostly -- managed it with kernels that "could" decide to deadlock on some resource, and when the few mission critical exceptions to this appeared, they were aggressively resolved on the kernel lists and rapidly appeared in the community. The main thing is the locking down of the server configurations to avoid the higher risk stuff, and aggressive pursuit of problems that arise anyway, which is really no different than with init, or with Microsoft, or with Apple, or with BSD, or...
But look at the far-side benefits! Never having to give up a favorite app as long as some stable version of it once existed? That is awesome. Dynamical provisioning, possibly even across completely different operating systems? The death of the virtual machine as a standalone, resource-wasteful appliance? Sure, there may well be a world of pain between here and there, although I doubt it -- humans will almost certainly keep the pain within "tolerable" thresholds as the idea is developed, just as they did with all of the other major advances in all of the other major releases of all of the major operating systems. Change is pain, but changes that "wreck everything" are actually rare. That's what alpha/beta/early implementation are for, and we know how to use them to confine this level of pain to a select group of hacker masochists who thrive on it.
On that day, maybe just maybe, systemd will save their ass, keep them from having to replace some treasured piece of software and still be able to run on the latest hardware with up to date kernels and so on.
I've been doing Unix (with init) for a very long time at this point. I have multiple books on the Unix architecture and how to use systems commands to write fully complex software, and have written a fair pile of software using this interface. It had the advantage of simplicity and scalability. It had the disadvantage of simplicity and scalability, as the systems it runs on grew ever more complex.
Everybody is worried about "too much complexity", but Unix in general and linux in particular long, long ago passed the threshold of "insanely complex". Linux (collectively) is arguably one of the most complex things ever build by the human species. The real question is whether the integrated intelligence of the linux community is up to the task of taming the idea of systemd to where it is a benefit, not a cost, to where it enables (eventually) the transparent execution of any binary from any system on a systemd-based system, with fully automated provisioning of the libraries as needed in real time as long as they are not encumbered legally and are available securely from the net.
We deal with that now, of course, and it is so bloody complex and limiting that it totally sucks. People are constantly forced to choose between upgrading the OS/release/whatever and losing a favorite app or (shudder) figuring out how to rebuild it, in place, on the new release -- if that is even possible.
I'll suffer a bit -- differently, of course -- now in the mere hope that in five years I can run "anything" on whatever system I happen to be using and have it -- just work.
rgb
Re: (Score:3, Insightful)
What Red Hat does is between them and their customers, plain and simple. People can complain about freedom of choice all they want (hint, you still have it), and you, as an experienced admin, are free to plot your own course.
I don't believe Red Hat has made this move on RHEL 7 in error. I think they have a pretty good handle on their customers and their needs. From what I can see on the RHEL lists that have many professional admins, there's been no hue and cry, no sky falling, etc.
I'm not quite sure what
Re:How about we hackers? (Score:5, Insightful)
init systems pre-systemd hardly did just one thing and hardly did it well.
Someone else doing something wrong isn't a justification to also do something wrong.
Uh, I guess that's a messed up way to say "two wrongs don't make a right?"
Re:How about we hackers? (Score:4, Insightful)
And since nothing is ever perfect this works as a nice nonspecific excuse to oppose any change at all.
Re: (Score:3)
It really doesn't. It disqualifies one (rather stupid) justification for doing something, leaving a billion other ones to be used.
Re:How about we hackers? (Score:5, Insightful)
If systemd is so very very wrong then people wouldn't use it right? Certainly no major distro will go out of their way to adopt something wrong.
systemd solves problems that are mostly associated with systems that have users who log in directly using a GUI. Most major distros have a strong "desktop" following, and as such, are interested in systemd.
Unfortunately, for the vast majority of systems that run just fine without the need to notify logged in users that a USB device has been hot-plugged, systemd doesn't offer much compared to the learning curve required to figure it out without documentation. In addition, the systemd environment (since it's not just one program) has bugs, and unlike older programs where the bugs and failures are known and can generally be worked around, this is not the case for systemd.
Re:How about we hackers? (Score:5, Insightful)
I manage several hundred servers and I would love faster boot times. Nothing worse than wasting my time waiting for a machine to come back online.
It's these kinds of statements that show no knowledge of what part of the boot is the OS and what part is the hardware that make me cry about the current state of system administrators. If a significant time of your wait is for the OS to load, then you've configured your server wrong or are using toy hardware.
By far the largest amount of time taken in boot for servers is the hardware checks. For VMs, boot times are already less than 15 seconds, even including the "hardware check", so that's no big deal.
And, for systems that get rebooted once ever 3 months or so, even a minute isn't really a big deal. The only time I really care about boot times are when I'm running through a lot of reboots on the same system, which is usually only when it is first installed and I'm doing hardware config.
Re:How about we hackers? (Score:5, Insightful)
I shouldn't be forced to suggest improvements on systemd. I shouldn't be forced to deal with it at all. It's a wannabe core system service. IT needs to prove itself first.
The champions of mindless change are the ones that need to prove their point. They have perverted the normal rules of rhetoric when they demand that it's the conservative voices that need to justify themselves.
It's those that demand change that need to justify themselves. This is basic, standard change control doctrine. So it's not surprising that you see an alleged rift between those that manage other people's expensive systems and "everyone else".
Although I am skeptical of the notion that "laptop users" even care.
As a desktop user, I am certainly not clamouring for an init replacement.
It's about the single least of my worries.
Re: How about we hackers? (Score:5, Interesting)
Or we have learned that you can't argue with Red Hat. As a company we have decided against upgrading to RHEL 7 because of systemd, and likely will be migrating to FreeBSD when it is no longer supported.
I'm waiting for our research team to get bored and start finding holes in systemd
Re:How about we hackers? (Score:5, Interesting)
As for the unix philosophy, init systems pre-systemd hardly did just one thing and hardly did it well.
Every time I see stuff like this I simply laugh. Having worked with *nix for over 30 years I have never had init "not work well" or "not work" as people try and claim. This is 30 years, with at least 8 brands of *nix, and more servers than I can count any longer (ranging from 1CPU to 128CPU E10K/F15K, so my opinion is not based on limited experience).
Systemd is not going to be any better, than Sun's SMF. SMF added nothing over init, except for some sales guy got to tell everyone how great it was. Maybe systemd is going to be worse though... at least SMF was script hackable as long as you could parse and edit XML, and that is not really possible with systemd (last I checked). And in that net zero gain, what did all of the Sun customers get? Lots and lots of costs to develop new scripts and new monitoring tools because SMF was different (not because monitoring was broken). Meanwhile anything that was important stayed out of SMF and went to legacy mode "init" scripts anyway since we could be extremely granular and detailed in a startup
Re:How about we hackers? (Score:5, Interesting)
I have similar length and breadth of experience of Unix systems and to be fair, I have seen init break but only once and it was when I broke it myself. I forgot to put an & and the end of a "sleep 20000 /dev/tty10" while trying to keep a serial line to a printer working properly. Next re-boot hung the machine but I was able to guess what the problem was.
When I first saw SMF break I had absolutely no clue why I couldnt ssh into the machine nor where to start looking. It was when I discovered that sshd startup was dependent on utmp being available which depended on filesystem mounting being successful that I knew for sure that systemd style init was nothing I wanted.
For me, scanning through /etc/inittab and being able to see exactly what is going on in the initialisation stage is the essence of Unix. Even this is sadly being slowly broken even before the utterly pointless systemd was born.
Re: (Score:3)
>and if you have to take services offline anyway, you may as well reboot
Depends on the nature of the services you run. There is no reason to blow away all your cached memory if you don't need to. That said, understanding your dependencies is important.
Re: (Score:3)
Please stop. Ive been at this game a very long time. It took very little time to determine what was wrong and to fix it.
My point was that I couldnt ssh in because a filesystem was corrupt and had to use the console. That is stupid as well as very time consuming and expensive in the high security environment in which these systems live.
I see the logic of course. utmp is updated when you log in with ssh so sshd depends on utmp and having utmp requires having a file system to put it on so there is a dependenc
Re: (Score:3)
In other words are those configuration files going to get replaced every time an upgrade is installed?
Probably not. Red Hat's RPM package manager normally creates an ".rpmnew" file if the existing config file has been changed. When that's insufficient, the old config file becomes an ".rpmsave" file. Manual mods to init scripts however... that's why the /etc/sysconfig directory exists.
Or, almost as bad, is the user going to have to trudge through screens and screens of diffs every time updates are installed in order to pick which differences are customizations to keep and which are part of the upgrade?
THAT, alas, is something I've been doing for years.
Re:How about we hackers? (Score:4, Insightful)
"As for the unix philosophy, init systems pre-systemd hardly did just one thing and hardly did it well."
What are you talking about!?! my rc.httpd starts/stops apache, period... my rc.ntpd starts/stops ntpd, period... I could go on.
"How does systemd remind you of windows? Have you actually *used* either in a system administration capacity?'
YES, yes I have. Windows with it's registry and svchost reminds me ALOT of systemd.
Re:How about we hackers? (Score:4, Insightful)
And as a result, when you do /etc/init.d/apache stop, apache stops. When you do /etc/init.d/apache start, (drumroll please), apacghe starts. Just exactly what he said.
Honestly, some of the individual rc scripts have become too clever by half. When it becomes too much, I replace it with one that has about 10 simple lines in it and it works great.
But if you find it all too much, answer a question no systemd proponant has yet managed to answer, why not start with the parallel startup in wheezy and add a helper app that runs the daemon in a cgroup and sticks around to manage it? Just stick that in the script like:
...
start) /sbin/manage start apache ;;
stop) /sbin/manage stop apache ;;
You could even do something like /sbin/manage waitfor nfs start apache
All the advantages, none of the problems presented by systemd. When starting, manage could register on dbus as well if desired. The desktop people could use that and the old school people could safely ignore it. Done right, manage need not freak out if dbus isn't running.
Any reason other than failure to force systemd on the world why that shouldn't make both camps happy?
Re:How about we hackers? (Score:5, Informative)
And as a result, when you do /etc/init.d/apache stop, apache stops. When you do /etc/init.d/apache start, (drumroll please), apacghe starts. Just exactly what he said.
That is exactly what systemd does, without all the hacks of the script. And with systemd I can finally be sure if Apache started or not, and I can put a dependency to (for example) mysqld, because most web sites are using MySQL as database. All of that is not possible without major hacks in Sysvinit.
Like "/usr/bin/systemctl apache start"?
add a helper app that runs the daemon in a cgroup and sticks around to manage it?
That is exactly what systemd is, but it does per default for all services. You can still use script hackery if you want to.
Re: (Score:3)
Re:How about we hackers? (Score:5, Interesting)
As I've said on many occasions, I've had race conditions completely stop boot scripts in their tracks before (pre-upstart RHEL). Any talk of a binary log is a red herring, plain and simple.
Saying, on many occasions, that you cannot manage and modify your startup scripts by hand for boot problem prevention, hardly qualify you as an adviser on system management issues.
Re: (Score:3)
Wow what? Linux needs to be hand coddled for managing starting up of services? What is this, the late 80s? Clearly such a system is not ready for prime time.
Ok I'm being a bit facetious and will likely be marked troll for it, but I am at least partially serious. Why the hell do I need to hand manage some 180 line long startup scripts for my computer to simply boot up when the power comes on? The arcane way of managing the startup and shutdown is on my top 10 pet peeves of the Unix world.
Re:How about we hackers? (Score:5, Insightful)
As for the unix philosophy, init systems pre-systemd hardly did just one thing and hardly did it well.
Are you sure you are using it correctly. Whilst fussy, init is hardly complicated - perhaps you are thinking of rc?
How does systemd remind you of windows?
I think the binary log files is a good start.
Have you actually *used* either in a system administration capacity?
Yes, we've been testing systemd in-house extensively. It has compelling feature that I like (unit files are a big improvement) however the monolithic approach is a turn off. If it was a replacement for rc, I'd back it, however as a replacement for initd it is not.
Whilst there is much pontificating about systemd, I think it is great for desktop systems however I can't see many enterprise deployments using it, it's just not ready for prime time. risk==downtime==2am working==no way
I don't care if you call me a holdout. I know how to make systemd do what I want because I use it. Init is still simpler and more robust because while you see the blocking/slow startup as a problem, most experienced admins see it as init advertising what is wrong.
systemd solves a problem that isn't really there.
Re:How about we hackers? (Score:5, Insightful)
I haven't used it, but the whole thing feels like it's being adopted en-masse by a large number of distributions when it is still essentially a new program and new way of doing things. Sure, experimental stuff is nice, but it should be experimental. Try it out for a few years before rolling it out to everyone. It feels like "boots fast" is being used to nullify all objections to it.
Re: (Score:3)
Exactly - keep it in Fedora and Ubuntu for a while before migrating it to the systems that need stability.
Who knows what annoyance are lurking in there.
Re: (Score:3, Interesting)
Why are binary log files such a big issue? First, Linux already is using binary log files in wtmp, secondly, you can still use text log files in systemd, and third, you can see binary log files just as well as text files. Because there is actually no difference between binary files and text files.
https://wiki.archlinux.org/ind... [archlinux.org]
# journalctl -b | grep NetworkManager
Re:How about we hackers? (Score:5, Insightful)
Re:How about we hackers? (Score:5, Informative)
> From what I can see on the RHEL lists that have many professional admins, there's been no hue and cry, no sky falling, etc.
Dude,
I don't know about you, but I admin about 400 odd servers, we've got about 40,000 globally. I've still got RHEL 4 boxes (Soon to be decomm'ed) Only some (5 - 10) of the boxes I built last year are RHEL 6. Everything else is RHEL 5 still. It works, I've no need to go above that for our purposes.
Now, I've got some new re-purposed boxes that I've started building with RHEL 7, and I've just started dropping myself into systemd.
Changing the startup scripts of *every* vendors application out there? No commercial applications are setup for systemd, this is going to be a loooooooooooooooong drawn out process to make this work.
RHEL 7 is brand new, very few people have started using it, the customers haven't had a chance to comment on it yet.
Re:How about we hackers? (Score:4, Informative)
Init scripts work just fine in systemd, and will for as long as there are init scripts. So vendors and apps *can* provide systemd service definition files, but they don't have to. It's backwards compatible just like upstart was in RHEL6. So no there's not a loooooooooong drawn out process to make it work. I'm running a debian box right now with systemd and everything is still in init scripts.
Re:How about we hackers? (Score:5, Informative)
Another reason for the systemd hate is the fact that it's been brought in by the back door. I dislike MariaDB for much the same reason.
Re: (Score:3)
Re: How about we hackers? (Score:3)
Indeed. People keep saying this and never what they were.
Re: How about we hackers? (Score:4, Insightful)
If it wasn't booting, then there is some sort of error message. Or no error message just a hang maybe! But no, that's never what anyone feels is "worth" mentioning. Just "it broke". I'm sure in debugging init script problems they would've supplied exactly the same information. Or you know, not, because it's extremely unlikely their system was locking up completely.
OK. I'll tell you what it did to me. Completely hung the booting process. Was some sort of filesystem error that would have simply blipped by on sysV and been fixable after booting. And, for that matter, it likely got logged. IN A BINARY LOG. THAT REQUIRED A BOOTED COMPATIBLE OS TO READ.
Mind you, I like the concept of systemctl. I just think it needs polish. It's journalctl that I loathe with every fiber of my being because I learned to despise binary logs when I was inflicted with mainframes and OS/2. The only reason I don't loathe the Windows Event Recorder is probably because I don't do the free-form log search and manipulation functions that I do in Linux when I'm running Windows.
I don't want an extra program injected into my log analysis functions.
I don't want to have to be restricted to only being able to interpret logs if they are on or can be transported to a functioning system with similar log tools.
I don't want to wake up one day and discover that critical logs can no longer be read because the binary file format specification has changed and I don't have a compatible decoding program.
I don't want the logs for everything to be all lumped together the way that unrelated application options are lumped together in the Windows Registry. There's a time and a place for consolidated log files - even binary ones - just not in my critical daily operations.
In short, I DO NOT WANT JOURNALCTL.
I'm not saying this because I don't like the concept. I'm saying it because I've already had it pushed on me and I don't like the practice.
Re:How about we hackers? (Score:5, Informative)
At this time it hangs on:
systemd[1]: Failed to run event loop: Invalid argument
systemd[1]: Failed to run mainloop: Invalid argument
systemd-logind[123]: Failed to enable subscription: Message did not receive a reply (timeout by message bus)
systemd-logind[123]: Failed to fully start up daemon: Connection timed out
The last time, at least a few months ago, I solved it by downgrading systemd from version 208 or so to the previous version. In the last update (of the rest of the system) dhcpd, sshd and probably others stopped working so I decided to update systemd as well and got the error above. The distro is Archlinux ARM.
My x86_64 installs work flawlessly, except sometimes when a program segfaults and journald decides to take a core for itself for a few minutes.
Re:How about we hackers? (Score:5, Insightful)
365 days without a security patch. Does uptime make you more money than protecting your customer data?
Most of my servers are behind firewalls with no incoming connections through the Internet. And, yes, uptime matters when we're doing something more critical than serving funny cat videos.
Re:How about we hackers? (Score:5, Funny)
personally it's a big pet peeve when my funny cat server is down for maintenance.
Re:How about we hackers? (Score:5, Insightful)
Re: (Score:3)
This isn't windows, I can do security updates without rebooting. There are occasionally security updates to the kernel, but not all of them need to be addressed immediately on all systems. A good admin knows which is which. There is a system to update a running kernel as well. Personally I find that all too fiddly and so prefer to reboot when a kernel update is required.
But note, if the update only affects a module, it may be feasible to rmmod and insmod that module alone.
Re:How about we hackers? (Score:5, Informative)
365 days without a security patch. Does uptime make you more money than protecting your customer data?
FFS. What makes you think a server needs to reboot for patches? Your extensive Windows administration experience?
UNIX/Linux servers need to reboot for a kernel patch. Very rarely (maybe never?) should a system need to reboot for anything other than a kernel patch. The number of recent packages aside from the kernel that require this is growing and a stunningly distrubing trend (mostly related to systemd).
Now, when must a kernel patch be applied? When a security patch is applied that affects something exploitable from one of your publicly accessible services.
An example, bind running inside a chroot jail and an exploit that requires access to a file or handle outside the jail != kernel patch and reboot.
A kernel patch for a local privilege escalation exploitable as www user with apache listening publicly = patch the kernel and reboot.
See the difference? There have been probably hundreds of local privesc exploits since I started working with Linux that just did not apply, and we very safely ignored the patch. When one matters, it is applied and we reboot. I've had specialty boxes that went multiple years without the need to reboot. We are on two commercial grids with battery and generator power available. I reboot when necessary, but have 6 9's of uptime (discounting planned outages) and the reason it's only 6 is hardware failure. It's 5 9's *INCLUDING* the planned outages across about 150 servers.
Now, I actually support systemd. But a few things seriously turn me off about it.
1) It is almost viral in what it demands, incorporates, and forces to be installed.
2) It doesn't appear to be well planned, documented, or tested.
3) There's a lot of scary shit in the bugtracker [freedesktop.org] that is still unresolved or even assigned (some more than a year old).
Now, I accept that systemd and the 1000 required subpackages (udev, dbus, avahi, the QRcode enabled http server, journactl, etc.) are under development and alpha software. I don't understand why my production servers are supposed to migrate there now. Fix the broken crap and we'll talk, but again - my fucking notebook stopped resolving without a reboot after a non-kernel patch. Fuck that in production. Message clear?
Re: (Score:3)
Are you sure? Why did you reboot to fix heartbleed? Why not stop, update, and then start the affected services?
I have some very old binaries (compiled static) that still work just fine. Other than a recentish foobar in glibc that finds older kernels unsettle it's delicate sensibilities (someone needs to lose a finger...) I haven't seen much trouble with careful mixing and matching.
Re: (Score:3)
Re: (Score:3)
SysAdmin !== Programmer
No, that was the 20th Century. We're now Lean. So SysAdmin == Programmer == DBA == Network Administrator == Janitor
Re: (Score:3)
We were here first, YOU fork it.
Failing that, there are at least two approaches in the works to fork it if necessary. One would fork Debian, the other is uselessd to fork systemd into something a bit less pernicious.
Re:How about we hackers? (Score:5, Informative)
Firstly using a pid files is an utterly stupid idea and quite frankly, anybody who can not see that when they first think of them or read about them should not be an admin on any critical systems. However, much as I like init, init doesnt do pids more elegantly, it doesnt do them at all. The kernel does that by kindly telling init when one of its children has died and arranging for it to be able tell what the pid was.
init doesnt do much at all and thats why it works so well. It simply takes whatever run level you want, reads through /etc/inittab to see what jobs to start for that run level and starts them. It then re-starts them if it gets a child death signal and /etc/inittab said respawn. Simplicity itself even though most Unixes now break it by having it start one job that handles everything else. Im guessing the one problem with init is that it cant handle a process that forks and then exits and maybe thats the reason /etc/inittab is dying. Shame.
I also think the kernel handing orphaned processes over to init is cheating a bit but I like it :)
Re:How about we hackers? (Score:4, Informative)
It's actually hard to find something that inittab can actually do well.
Re:How about we hackers? (Score:4, Insightful)
Is there no middle road between init/inittab and systemd? Why the abrupt change over in a short period of time with a program that hasn't been time tested and comes with a lot of objections? Are there ways to make incremental changes towards the goals that systemd has?
Re:How about we hackers? (Score:5, Interesting)
Persistent arent you.
You are correct that the /etc/inittab has no notion of dependencies but you do and thats the key.
I can certainly see that whole S021startsomething.sh is a bit of an ugly hack but its a workable hack. If the dependency thing is such a problem for you why not have a simple dependency file that something reads and describes dependencies and perhaps what to do when dependencies are not met. You can easily implement something like that with the current model. Cant see why you need to over engineer a behemoth just to solve that? Personally Ive never broken a system because a service started when a dependency had failed but I have found myself unable to log in to a Solaris box because one filesystem didnt mount.
I have never seen gigabytes of logs filled with output of failing daemons and have never missed crucial logs in a start up session. If you have then perhaps you need to review your own policies.
Are you sure? (Score:5, Interesting)
I've seen an overwhelming level of support of systemd from Linux users who run Linux on their laptops and maybe a VPS or home server
I haven't seen an overwhelming support anywhere. Most people who run Linux on their laptops say, "meh, as long as it boots."
This article is a LOT better than the previous one by the same author [slashdot.org]. He makes his point clearly, that he doesn't like SystemD, as a sysadmin he doesn't want binary log files etc; but if someone else feels like they need systemD, maybe there should be a fork to make place for those people. It's a fairly kind, open attitude. Maybe we should have more of that around here.
Re:Are you sure? (Score:5, Insightful)
Re: (Score:3)
I'm looking at PC-BSD [pcbsd.org] as a way to jump-start myself into FreeBSD. The desktop is not too bad, but I'm as yet unsure whether all my tools will run there or not, though.
BTW, I take exception to the attempt to draw a dividing line between desktop and server use. There are lots of us who use Linux on the desktop because we're doing software, Web, or other development, or work that's related to it.
Re: (Score:3)
Re: (Score:3)
Is there scope for a less intrusive fork of SystemD? Something that does not replace such a large number of well-established daemons?
Part of my concern is about SystemD is the scope for bugs. All the daemons that are replaced by SystemD have years of development under teams of developers. Can one expect a re-write of all these daemons by a small team with no history of working on these applications to be anywhere near free of bugs?
Re:Are you sure? (Score:5, Informative)
Is there scope for a less intrusive fork of SystemD?
OpenRC + Init [wikipedia.org] seems to be the commonly referenced replacement. UselessD seems to be a more reactionary replacement, which is also often mentioned [darknedgy.net]. I still can't see what's wrong with init scripts :)
Can one expect a re-write of all these daemons by a small team with no history of working on these applications to be anywhere near free of bugs?
Not likely.
Re:Are you sure? (Score:5, Informative)
"ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole=, ForwardToWall= Control whether log messages received by the journal daemon shall be forwarded to a traditional syslog daemon, to the kernel log buffer (kmsg), to the system console, or sent as wall messages to all logged-in users. These options take boolean arguments. If forwarding to syslog is enabled but no syslog daemon is running, the respective option has no effect. By default, only forwarding wall is enabled. These settings may be overridden at boot time with the kernel command line options "systemd.journald.forward_to_syslog=", "systemd.journald.forward_to_kmsg=", "systemd.journald.forward_to_console=" and "systemd.journald.forward_to_wall=". When forwarding to the console, the TTY to log to can be changed with TTYPath=, described below."
Re: (Score:3)
If it's supposed to be an init system, it has no business trying to replace either, no matter how bad they may be.
Re:Are you sure? (Score:5, Informative)
- there is a link on words "an overwhelming level of support of systemd from Linux users" - and that prompted me to click on that link (in clear violation of /. codex) because I was hoping to see who are these people that overwhelmingly support systemd? (apart from Lennart himself, that is).
All I got was a blog by Paul Venezia claiming that there is "an overwhelming level of support of systemd from Linux users". The links proving that claim are suspiciously missing. The blog itself seem to be be more on the skeptical side too.
So unless I see an overwhelming level of support of systemd from someone that matters and someone who knows what he talks about, then I'm not inclined to take that statement at face value.
Re:Are you sure? (Score:5, Insightful)
Debian, Ubuntu, Redhat, Fedora, Suse, all switching to systemd. Those distributions together represent the vast majority of Linux users. To say that systemd does not have an overwhelming support, is just idiotic.
Re:Are you sure? (Score:5, Insightful)
So an overwhelming level of support by linux users, or an overwhelming level of support by the distribution developers? Was there a vote taken that I missed?
Re:Are you sure? (Score:4)
Microsoft are "depended" on their users, but it didn't stop them producing Windows 8.
There are plenty of other examples out there, if you think for just a moment.
Re: (Score:3)
Just because a vendor choose to use something it doesn't mean their users are overwhelmingly supporting it. Usually it just means the users are stuck with the vendors choice.
Re:Are you sure? (Score:4)
There's something else different about systemd - the dreams of monocultuer by its proponents.
There are some other near-monocultures in Linux - glibc, xorg, gcc, etc. But I don't see glibc people trying to stamp out uclibc, nor did I ever see xorg people trying to stamp out svgalib, etc. As for gcc, there is what appears to be healthy competition with llvm, and I see no significant politicking there, either.
We have Postfix, Courier, Exim, sendmail, etc. They all coexist, and they all try to be best for someone's needs.
There may be some other near-monocultures in Linux, but nowhere but systemd is anyone insisisting on becoming THE monoculture, and working to tie everything possible into their monoculture.
Re:Are you sure? (Score:4, Insightful)
And you don't have to modify vi to edit their config files. That's one of the things that worries me - systemd needs modifications to all manner of other things.
Poettering : software == Monsanto : farming.
Re:Are you sure? (Score:5, Informative)
Debian already stated that they would not go with systemd,
I think you might want to [wikipedia.org] check again [zdnet.com]. Ironically, for all the claims that SystemD is for a better desktop experience, Ubuntu was the last one to enable SystemD. Not sure what to think about that. I think the reality is that SystemD makes life easier for distro builders, not for users, and that is why it has won.
I'll be watching this one close, wondering if Redhat will have to come out with a fancy option to support systemd with an option for init.
I'm really interested in seeing that too.
Re:Are you sure? (Score:5, Insightful)
I think the reality is that SystemD makes life easier for distro builders, not for users, and that is why it has won.
I think this is the underlying cause as to why the old guard are upset, and what a lot of the lawn-invaders don't really understand. It's not really about systemd.
Linux used to be our system. It was unashamedly by hackers for hackers. The user was king because the user was a hacker and Linux built by like minded users. If there was something that sucked to set up or sucked to use it wouldn't win out because why would anyone want to make a system worse for themselves. Furthermore the builders were derived from all walks of hackerdom. Some were distro builders, some web developers, some kernel hackers and so on and so forth.
For systemd, I don't even know if there's much wrong with it. But it is indicative of a deeper rift. Linux systems are now primarily build by professional distro builders and they don't do much on Linux except build distros day to day. And the vast influx of corporate money means that it's getting harder and harder (though not impossible yet) to avoid its effects.
The end result is that Linux is no longer the ultimate hacker system, made by techies for techies. It used to be uncompromisingly awesome by the standards of the time for such people.
Now compromises have had to be made, and the old guard are feeling the effects of the change. This amazing system which once you could bend to your will in any way imaginable is beginning to approach the type of opaque black box that they fought so hard to escape.
That's the problem. Systemd is just yet another instance where it bubbles to the surface.
Re: (Score:3)
Re:Are you sure? (Score:5, Insightful)
Number of executables which can parse systemd journal log files: 1
Number of executables which can parse traditional log files: >10000
Single points of failure are rarely a good idea.
Re: (Score:3, Insightful)
Re: (Score:3)
Yes because I'm sure the literally microseconds of lag (I mean maybe, there's a lot of assumptions in that statement) is a problem compared to, I don't know, the 100s of milliseconds it takes to flush anything to disk. Presuming it gets there, because if the system goes down, it's unlikely anything gets written out of any memory buffer.
Then of course there's the byte overhead of all those characters rather then concise binary files, so there's a bandwidth cost too.
But it's pretty obvious you don't actually
Re:Are you sure? (Score:4, Insightful)
Oh and don't bother if you're not a regex guru too.
Look, I'm sorry, but if you don't know regexes, then you really don't have any business being a system administrator. I certainly wouldn't hire you.
Non-system Admin Here (Score:4, Interesting)
I use LMDE on three laptops. I don't support systemd. Ignoring the technical arguments, it's been forced down people throats and that alone should be enough for people to step back and halt it's adoption.
That aside, will people please stop this constant masturbation about startup times? There are way, way, way more important things to deal with than edging out a few more seconds. Systemd provides me with no perceivable gains. I don't sit down, press the power button, then stare at the screen until I can log-in, then wait again for the desktop to load. I press the power button, plug-in the laptop, take out my mouse, manager whatever papers I'm going to use, etc... and then log-in. When I had a desktop, I almost never rebooted it. Startup times matters even less on desktops.
However, systemd does provide me perceivable losses. Time spent arguing over systemd could have been spent making everything else better. Systemd removes options, that while I'm not doing anything with at the moment, I like the ability to choose in the future. There are way too many instances of previously good companies/projects suddenly fucking over it's users (of which systemd is becoming an example of in and of itself). I prefer not being locked into something. Systemd didn't present itself as an option, it demanded that it be a requirement.
Personally, I find it crazy that Microsoft and other large software companies are doing more to support scripting while somehow the linux community is being dragged into less and less scripting. (article mentions desktop users don't want to know how to script anything). We need more scripting not less. I'd love to be able to pull out the couple commands I use that are buried in menus and place them as buttons on the menu bar. I don't want an AI to do it for me, I want to take my common commands and make them easier to navigate to and execute or completely automate them.
Re: (Score:3)
That aside, will people please stop this constant masturbation about startup times?
Let's be honest, startup time matters. You want your desktop to boot fast, you want your laptop to boot fast, you want your server to boot fast. We don't always get what we want, and especially in the server room people found ways to deal with a slow boot. It's not what they want, though.
Problem is, switching from bash scripts to systemD isn't going to make you go any faster. Bash scripts were designed for systems with clock speeds of single-digit megahertz. On a modern system, spawning a dozen is hardly
Re: (Score:3)
I dont think input validation is any less of an issue with a binary. You could argue that at least with a script everybody can see if its doing something stupid.
Re: (Score:3)
Time spent arguing over systemd could have been spent making everything else better.
See, I'm reading these comments and I'm not sure what to make of all the arguing. In my experience, it's not uncommon for Linux/Unix users to simply have a stubborn streak, and to oppose new solutions simply because it's not the same as the old solution that they're used to. Or... let me rephrase that. It's more that, for any new solution you suggest, I expect there to be a vocal contingent that will oppose it. I expect that even if the solutions were to be, without a doubt, superior.
Not only that, but
Administrators dislike constraint based systems (Score:5, Informative)
Administrators dislike constraint based systems.
This should surprise no one. One of the problems with a constraint based system is that you don't control the precise ordering of things.
This doesn't bother the Debian folks, because their build system is a constraint based system. If they have a package to install which has dependencies, they don't control the actual build order of the dependencies, or of their dependencies, and so on. Turtles all the way down. You do an apt-get install foo, and it's going to try to build subcomponents when they become available to try to build. And if they fail to build, they don't care: they "try again later", in case something that happens later satisfies the dependency that wasn't satisfied the first time around.
This is very disturbing to system administrators, who like things to be both orderly and predictable. All dependencies should be mapped out, known, and explicit. If something gets tried now, and fails, the correct response isn't "We'll try again later!", it's "Stop! Someone fix this fucking thing, it's obviously broken".
The build system is not deterministic; if there are two components, and one has a subdependency on some X of "at least version N", and another has a subdependency on X of "at least version N+2", then depending on the vagaries of network overhead, it's possible that half your code gets built with version N and the other half gets built with N+2, and things break. Things breaking is in fact far more acceptable to a system administrator than "things act weird", and "things act weird" is at least deterministic for a given build instance, and far, far, more preferable than "things sometimes work and sometimes don't".
So system administrators dislike Debian for large system installations. And they dislike systemd for starting things up and shutting things down.
A desktop system is far, far more forgiving: "It's not working; I'll just reboot!". As long as things "mostly work", then things are great! "Look! It's as good as Windows!".
Note that launchd in Mac OS X has many of the same problems as systemd; it's also a constraint based system. It's somewhat worse, in that it insists on controlling file descriptors and sockets and Mach ports for the things it starts - which means you have to rewrite a lot of at least the startup code in most Open Source software to tolerate being run by something that opens the files and sockets that it expects to do itself. But that's just a lot of make-work, and people who are paid to do work are paid because it's not something they'd be willing to do voluntarily, for free, and that's what they're exchanging for the money they are getting in exchange for putting up with that part of the job.
Unlike the people making things work with launchd, though, the people expected to make things work with systemd aren't being paid. And so systemd represents make-work and change for chage's sake, which doesn't sit well with volunteers.
--
So yeah, a lot of people find systemd annoying. Kirk McKusick once accused "vnode" as being "the structure that's taken over the kernel"; in Linux, systemd is fast becoming "the program that's taken over user space".
How this will all play out, I don't know, but don't expect it to be resolved any time soon, given the dichotomy between the philosophies of the stakeholders involved.
Re: Administrators dislike constraint based system (Score:5, Insightful)
Whether one dislikes systemd or not isn't necessarily because of what it does or doesn't do. The issue for many people (myself included) is simply that it's a monolith that keeps trying to grow larger in an "open" world that was meant to stand for a certain amount of platform agnosticism and component independence.
I realise that systemd can make life easier for some more novice users but to be true to the spirit of the open source community I would expect it to be optional where it can be so. When it starts to intrude into critical areas and make itself mandatory in some releases, that bothers me. It makes me think that the whole business is a sneaky attempt to subvert the Linux kernel and eventually take control of Linux as a whole.
Re: (Score:3)
It is, and this ridiculous claim that it's not so because it's not a singular binary is as telling as it is tedious.
Worse yet, it's a monolith that's ousted EMACS as the poster child for feeping creaturism.
This is bullshit (Score:3, Informative)
Systemd articles have become the new Slashdot clickbait. It seems every freakin' day there's another "discussion" about that unholy abortion.
And apps while we're at it (Score:5, Insightful)
It's not just the init, it's also the applications that are being infected with Lennart-ware, e.g. gnumeric. It's a great spreadsheet, but recently it's been picking up various egregious hard-coded dependancies that simply don't make sense. This occurs mostly via GTK, which seems to pull in a significant chunk of GNOME.
I run a minimalist Gentoo desktop, and I notice when additional dependancies are dragged in. The past year or 2 has seen goffice, ghostscript, harfbuzz, dbus, and various other crap become hard-coded dependancies for gnumeric. It was not necessary a couple of years ago. If I had several million dollars, I'd hire a bunch of progragrammers to port gnumeric from being dependant on GTK to being dependant on FLTK (Fast Light ToolKit) http://www.fltk.org/ [fltk.org] Some of the money would go to ongoing maintenance.
Another few million dollars, and I'd like to hire a team to hack and slash away at Firefox. I was around when "Phoenix" was forked as a lightweight alternative to the Mozilla web-browser. I savoured that promise. That promise has been dashed into the ground, with a Firefox that's bigger, heavier, and slower than the original Mozilla ever was. Time for a new fork.
I want GNU-Linu-x, not GNOME-Lenna-x
Re: (Score:3)
Are you such narzistic ass that wants to dictate the developers of free software which libraries they dare to use?
If Gnome, KDE, Gnumeric, or who ever wants to use systemd for whatever reasons, it is the choice of those developers. If you don't like it, you are free to fork those projects.
benefits vs risks (Score:5, Informative)
Systemd has it's downsides. The real downside is that you have so much complex code running as root. most other complaints can be dealt with.
Binary logfiles: You're not supposed to keep important log files on the local machine. Send them to your central logging facility where they are stored in a database. If the machine is still running, you can use the appropriate tools to look at the binary log files for debug. All your logging, stats and alerting should be centralized anyway.
Doesn't feel unixy: Get with the times. It's scriptable and tweakable more than ever. Just get used to the way it works.
Solution looking for a problem: Just not true, see the benefits.
Systemd is one of the options to solve some problems that have been pestering unix for a long time.
Dependency in services: Systemd can restart all dependencies on a service in the right sequence if you have to meddle with one part of a stack
long startup times: Systemd has the possibility to start up things in parallel. No long waits for earlier systems that your service doesn't depend on. Mostly useful for mobile users, but HA systems benefit too due to shorter maintenance downtime
Location/circumstances specific profiles: Depending on where you are and what kind of facilities you have available, your system can "adapt" by changing power profiles, network connectivity, firewalling and whatnot. Primary benefits are for mobile users, but servers changing load depending on things like overheating, having to run on UPS power and such are also quite useful.
Systemd isn't the only project that wants to work this way. Upstart is another one that at least wants to deal with the startup concurrency and dependency problems of classical init. Sun (Oracle) Solaris SMF is also a good example of this line of thinking.
While you can have doubts about the amount of complex code and forks to 3rd party code done by systemd while running as root, I don't think it's useful to complain that someone moved your cheese and took away the init scripts you used to use in the old days. Once you figure out how to work with the new tools, you'll find it's way more tweakable and controllable than classical init. If in the end you choose for init or a different alternative, that's up to you, but at least investigate and educate yourself, before you start complaining with arguments that just aren't true.
Re: (Score:3)
It's scriptable and tweakable more than ever.
And this is the problem: there's so much misinformation. The old RC scripts were bash scripts. You could literally hack them to do anything at all. There's nothing more tweakable than having the source code right there in fromt of you.
Re: (Score:3, Informative)
What about systemd trying to do too much? Ie, someone earlier said it was great that systemd did ntp and dhcp, which seems ridiculous to me; if those services had problems then get better services, don't just wrap them up into systemd. Were those written as examples of systemd services to be emulated, or do the systemd devs really think it's their job to subsume services?
Interesting problem; if systemd had taken existing sNTP and DHCP clients, modified them so they fitted the systemd user case, the systemd developers would have been accused of "subsuming" other projects.
I think it is important to understand why systemd made a sNTPv4 and a DHCP client; in both cases it was user requests, and it was all about OS containers. Most sNTP and DHCP clients are made for stand alone systems, but the OS container density on a system is between 10 to 100 times that of a system running
Why not fork/wrap systemd to make it more sane? (Score:3)
Let's start by saying that the death threats against Lennart Poettering are ridiculous and should not be tolerated.
That being said, the design of systemd confuses me. It seems ripe for all manner of stability and security problems. As I understand it, it bundles a large number of services into a single process, which takes place of the init daemon. That's guaranteed to cause all kinds of system crashes.
What I don't get is why it isn't split up into multiple processes. All the same functionality could be provided by having a simple core init daemon that loads a set (perhaps a small set) of child processes. It wouldn't take longer to load. The services and behavior would be identical. But it would be a lot more stable, because a child process could be restarted if it crashes, keeping init to a bare minimum.
What's even more surprising is that someone with some sense hasn't done exactly that: Make a wrapper for the systemd build that patches a few things and just compiles it differently, into a slightly larger number of binaries. This way, we can benefit from the unification of services, while maintaining stability, and Poettering would have to be intentionally self-destructive to try to keep breaking that wrapper every release.
Re: (Score:3)
That being said, the design of systemd confuses me. It seems ripe for all manner of stability and security problems. As I understand it, it bundles a large number of services into a single process, which takes place of the init daemon. That's guaranteed to cause all kinds of system crashes.
What I don't get is why it isn't split up into multiple processes. All the same functionality could be provided by having a simple core init daemon that loads a set (perhaps a small set) of child processes. It wouldn'
Re:It's about control (Score:5, Insightful)
How so? Systemd has removed my ability to start and stop services?
How would a package mess with systemd's configuration? It's readily apparently no clue about systemd. Hint, it's no different than it was before. A package drops its own service definition file in a directory (sound familiar?). That's it. It's no different in this area than any other init system. If the file is bad, the service just won't start. Just as it was before. Runlevels or targets are defined the same way: with simple symlinks. Really in this aspect, systemd is no different than upstart or plain old system v init.
This post is one example why the debate gets so heated. People like you post stuff that's only nearly half true, without knowing anything about systemd, except the name of one of the authors. FUD plain and simple. A technical debate is fine, but you've got to actually know what you're talking about before you start debating. So far I've seen zero technical debate on this site regarding systemd. Certainly no one is willing to own up to the flaws in traditional init that have led to systemd's development. It's extremely disheartening to see this kind of irrational fear instead of technical discussion.
Re:Misplaced (Score:5, Insightful)
I wouldn't say that it's wrong - a system administrator expects a system to be up and running for maybe a decade with little effort. Major changes in how the system platform is designed causes headache because it costs time, both to re-learn and to re-document a large number of procedures.
As long as you use the standard services on a server it's no problem with Systemd, but when you use a number of tailor-made suites on that server you are getting more and more headache when you introduce a new structure of managing the startup.
Re: (Score:3)
No, it does not. Problems happen mostly on reboot and on changes. The system administrator already has these ironed out with the existing init system. Any major change will give years of new and surprising problems.
Re:Misplaced (Score:5, Insightful)
IMO you have no clue what you are talking about. There is no way to make "managing a cluster of servers a breeze", it will always be difficult. You can make debugging problems almost impossibly by too much automation though.
Re:Not true. There's a different division (Score:4, Insightful)
The shell is never going to be irrelevant (except for idiots) and no one is worried that the month they spent learning bash is wasted now. Seriously your post has got to be the dumbest thing I've heard or read in this whole debate. Seriously, you think 20 year unix->linux veterans are daunted by the idea of "learning systemd"? Christ boy, think about it, these are people that have had to become overnight experts on some thing, like dozens of times, and they still do it on a regular basis.
People that are older, smarter, and wiser than YOU realize that the basic concept of systemd is just fucked.
Are you one of those kids that thinks knowing Puppet is a skill?
Re:Not true. There's a different division (Score:4, Insightful)
Seriously, you think 20 year unix->linux veterans are daunted by the idea of "learning systemd"?
Yep. That's exactly what I've witnessed. Most systemd haters haven't even used it.
Re:Not true. There's a different division (Score:5, Interesting)
Actually, most of the new sysadmins who join my team do not get taught by crusty old sysadmins but learn by themselves. Every single one of them chooses to use a init script to start something up when given the choice though.
And, why would I need a portable init script for forking a daemon with or without a limited capability set and why would I want to do it in five lines when I can do it with one that everybody can clearly understand in /etc/inittab?
I have no problem with control groups. They provide features that have been more or less provided for in several different ways before and are a handy feature but killing daemons reliably has not been a problem for the forty or so years before cgroups came along.
You seem to believe these crusty old unix admins with years of experience have nothing to teach you so Im gad you dont work on critical systems but I urge you to re-consider your outlook. It will save you a lot of trouble in all aspects of your life.
Regards
Re: (Score:3)
You really do not know what you are talking about. People with a lot of experience can judge the merit of a thing by looking at a description of it. People like you do not even know that is possible.
Re:Not true. There's a different division (Score:5, Insightful)
Your'e close - the split is indeed between the older Unix types and people that just want to be "users", but you need to recalibrate where their relative positions. Those of us that are against being forced to use[1] systemd see this in a different light. As computers became inexpensive over the last decade, a new generation of younger people joined the Linux community. They were young an inexperience, and often made well-known mistakes in their software. Thats was ok - we were all n00bs at first, and many of us tried to gently nudge the inexperience developeers in useful directions. Very few listened, and have now decided that anything "old" is bad.
Listening to those that came before you is important, if you want to avoid making the same mistakes. A lot of those lessons are collected under what many refer to as the "Unix Philosophy". Mostly, that "philosophy" is jsut a handful of tricks that make maintainance saner. A lot of the stuff that people claim is "overcomplicated", "messy" or an "archaic design" is such an "ugly" state for a reason, and those messy bits are bugfixes. The nice ideal design we all starty with rarely fits exactly when we introduce it to the problems and unforseen circumstances in the real world. That ugly spaghetti-code-style hack that seems to ignore and bypass the "correct" way? That is probably a bug fix, and by removing it you probably reintroduce the bug.
You call us luddites, but heed our warning at your own peril. Some bugs and bad designs have happened before, and a key reason why we don't like systemd is that it makes one of the worst mistakes you can ever make when designing software: it throws out the supposedly "old" or "ugly" parts. I suggest readoing Joel Spolsky's famous essay on this topic: [joelonsoftware.com]
Systemd is still at the early stage, where it can get away with this kind of bad design, but as more and more people start to use it and the never-ending list of Real World Problems starts to creep in, the systemd developers - and the distros that joined them - are goign to have one nasty mess on their ihands. It is going to be a nightmare to all of the bugfixes and real-world mess that was thrown away because it was "old".
We tried to warn them, and were labeled luddites.
Well, as B5's Londo Mollari put it:
Re:Not true. There's a different division (Score:4, Interesting)
The argument goes both ways.
New is not always better does not imply that old is not always better either. There have been some amazing examples of throwing away the old and replacing with new to large improvement (just think of the change in network stack between the older Windows kernels and Windows 7, or the change in driver design). A new implementation of the same system is not likely to be bug free first go, but it has every chance of being good, and can quickly grow to become a nice stable foundation.
While this is all great it really has nothing to do with the topic here. Systemd is not a re-write of anything. It's a fundamental change in the operating philosophy of the OS. The "old" folk are being ignored because systemd has nothing in the unix world to which it can be compared, and that raises a never ending triad of ignorant posts claiming it is an init system which does too much.
But worst of all the criticism is not at all constructive, it isn't at all pointing out bugs or complaining about re-writing working functionality. From what I've seen it seems to be entirely a case of "it's different and so it must be bad", and THAT is what gets people labelled as luddites.
Re: (Score:3)