On 15/06/12 04:03, Brian K. White wrote:
I've been saying the same thing for a couple years.
I'm still here because the pain of switching is high in my case, and the pain of having a mixed environment is high too, and I am skilled enough to take almost anything and make it workable myself and hide any problems from my developers and customers.
But if I was switching from SCO Open Server _today_ instead of 7 or more years ago, I don't know if I'd choose Suse today (any suse). It's a different product with different prospects and no predictability at all any more. I'm not necessarily saying it's going down the tubes. It may become fine. I'm saying there is no basis to predict that today. Back when I chose opensuse, at that time there was a pretty consistent history of progress and quality assurance and version-to-version stability in how things worked, if you include "suse" before "opensuse" had that name.
So for now I just continue to deal with it. Sometime, maybe not even before 12.2 comes out I will probably start installing 12.1 after I establish a good reproducible and reliable install procedure for reverting systemd, because I have too many things that _I Need_ that _don't work_ with systemd.
Now I could probably figure out some way to get things all working in systemd, and rewrite all my spec files and sys admin notes and internal company knowledgebase docs for systemd, even hack some programs I don't even have the source for by wrapping them in wrapper scripts or ld preload tricks, but why should I assume the burden of doing all that? Who's going to pay my company for all that time? What benefit do I get to say we are getting for the investment? Our stuff already works the way we want it, so, ??? I'd do a lot of work just to retain functionality we already have? I can't sell that even if I was deranged enough to want to.
Also there is this. Recently on the rsync bugzilla someone posted a bug because rsync exits with exit values other than 0 in some situations that are not errors. These exit values are documented and perfectly reasonable. But, systemd does not allow for _anything_ but 0=ok, everything else = failure, which screws up systemd stopping/starting the service sometimes. Systemd says rsync is wrong and should change that behavior. The behavior is documented, has been the same for decades, predates systemd by decades, and is within the designed intended use of exit values in programs since exit values even existed. Yet systemd, instead of realising that such a narrow assumption is a bug, once again decides the rest of the world is wrong and systemd is right. That tells me that I do not want to invest any time adapting anything to systemd, because it's too much of a one way street. Systemd will not adapt to provide me with a powerful tool that can handle any possible situation, systemd requires me to adapt everything else to get it to work at all, or live without anything I can't adapt.
That is not why I run a unix-like OS.
I run a unix-like OS because it is flexible and I can configure it to do whatever unpredictable unusual _I_ need it to do. Unix is not a machine that does a job, it's a tool box that you build any machine you might need to do any job you might need.
Systemd, at least until it changes it's stance, and especially when you remember it's aiming to take over at least the jobs of cron and udev as well, is only good for more narrowly defined systems like embedded systems and appliances, Android, and typical desktops. The logical extension of the systemd path is to include the kernel, systemd and busybox all in one binary, and that's you're entire OS, all else is user/application. Sure it would be fast and efficient. And a neat experiment. And a handy system-on-a-stick for some special cases. And useless for me.
12.2? who knows. If it's still relatively simple to block systemd and keep sysv init in 12.2 then I'll probably end up still using suse during 12.2. Then again who knows, because systemd is just one example not the only issue.
And the devs here don't want to hear any of this. And that's just another part of the problem.
CLAP! CLAP! CLAP! Bravo! Very well put, Brian! I chose SuSE way back when for exactly the same reasons you state in para 3 above. BC -- Using openSUSE 12.1 x86_64 KDE 4.8.3 and kernel 3.4.2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org