Earlier quoted context omitted.
I completely agree – but critical thinking involves something along the lines of "here are the things that I think are wrong, this is why I think they're wrong, this is how I think they could be solved." The answer "let's throw everything out" isn't that useful; likewise, dismissing the considered opinion of lots of people who have been doing this sort of thing for a while needs to be done with some rationality. An e…
Actually the answer is to be slightly more conservative with the approach. No one has to pick up systemd now for example. Leave it a year and see where it is. The technical merits will be obvious and the technical problems will also be. Moving all the chess pieces at once, which is what is happening is not productive, professional or a sign of experience.
Systemd redux: The end of Linux
181–190 of 464 posts
Re: Systemd redux: The end of Linux
#182Earlier quoted context omitted.
The status quo for such projects is to use Busybox, and I reckon it will continue for projects where systemd etc is too much.
Systemd is too much, but often busybox is not enough. Plus if everything starts conforming to systemd, busybox will have to become like systemd to stay compatible.
Also if busybox is not enough, a minimal systemd system will still be leaner and faster than the equivalent sysV system.
http://events.linuxfoundation.org/sites/events/files/slides/...
Re: Systemd redux: The end of Linux
#183Perhaps this is a controversial idea, but is this not just someone finally taking the tried and true Open Source "advice" to heart? That is, every time I've reported something is broken, wonky, doesn't work reliably, et cetera, I've been told, "Submit a patch.", "Write some code.", or worse, "Implement it yourself." Someone finally got fed up with the haphazard state of affairs in Linux-land. Fed up with the fragment…
Or go back to using windows for general use and software development which is in fact what I've done. It's amazingly sad after many years of being a strong linux supported but this has killed linux for me. I see no point in continuing to use it.
Re: Systemd redux: The end of Linux
#184Earlier quoted context omitted.
It hinges upon the fact that people are more likely to be vocal when they don't like something than when they do. Consider online reviews: are you more likely to review a product when it's worked fine as you expected or when it died a month after you got it? systemd has both good aspects (e.g. faster boot times and removal of the nasty nest of shell scripts) as well as bad ones (incredibly monolithic). There are argu…
"removal of the nasty nest of shell scripts" What one person finds nasty another may find sexy.
Re: Systemd redux: The end of Linux
#185Earlier quoted context omitted.
Then feel free to use shell based init. Meanwhile, there is a strong concensus in Linux distros that the maintainers thought shell scripts were not sexy, and systemd unit files were, and thus everyone has / is switching.
"Everyone" has not switched nor is "everyone" switching. Most distros are yes. Some are not. Personally I like shell scripts and plan to continue using them as long as feasible. They work, and when/if they don't, I can usually find out why. "Strong consensus" might be good argument for some people. I personally find it a fallacious appeal to popularity.
Re: Systemd redux: The end of Linux
#186Perhaps this is a controversial idea, but is this not just someone finally taking the tried and true Open Source "advice" to heart? That is, every time I've reported something is broken, wonky, doesn't work reliably, et cetera, I've been told, "Submit a patch.", "Write some code.", or worse, "Implement it yourself." Someone finally got fed up with the haphazard state of affairs in Linux-land. Fed up with the fragment…
I had no opinion on systemd until yesterday. In fact I had a glace or two at the code and it's pretty clean and I liked the rough objectives laid out. I installed CentOS 7 on a machine last night that we're replacing CentOS 6 on and was poked in the face with timedatectl and dbus problems for an entire hour, some of which were intermittent. Debugging these issues is a horrific pain. I lost 4 hours on it. I've never l…
Re: Systemd redux: The end of Linux
#187Earlier quoted context omitted.
All the more reason to be judicious in what new technologies are introduced. One of the huge benefits of the Unix/Linux, CLI, and Free Software traditions is that they tend to be very strongly preserving of established knowledge . Changes are incremental, usually additive, a reliance on scripting means that interfaces are unlikely to change, and new tools are very frequently drop-in replacements for old. As specific…
Exactly that. You know what's insanely great? When you watch this presentation video of 1978 at AT&T where Ken Thomson explains Unix and type some commands on his VT-52 and you think: all of this is still current knowledge, and all of his explanations still hold true. Just like celestial mechanics or Pythagorean theorems. We are heirs of this ancient wisdom and this is friggin good , this is culture .
Re: Systemd redux: The end of Linux
#188Can someone put in Layman's terms what the change entails and why it would be the end of Linux?
It's important to note that the blog post doesn't mean, "Linux is done for," but rather, "Linux is going to be a different kind of system than it has been historically." Some people think this is a good thing, and some think it is not. EDIT: I want to emphasize that I am trying to write this comment neutrally, not endorsing either side, so while my biases may sneak in, my intention is to be fair to both sides. Both s…
Re: Systemd redux: The end of Linux
#189Earlier quoted context omitted.
Actually the answer is to be slightly more conservative with the approach. No one has to pick up systemd now for example. Leave it a year and see where it is. The technical merits will be obvious and the technical problems will also be. Moving all the chess pieces at once, which is what is happening is not productive, professional or a sign of experience.
That's not the case though – systemd has been enabled by default by Fedora for three and a half years or so, and has been steadily adopted since then by most other major distros. Not everybody is moving at once, so why would waiting a year make any difference?
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_s...
A lot of the bug descriptions are quite scarily bad when you consider them in context such as "various loginctl commands not working" etc.
Re: Systemd redux: The end of Linux
#190Earlier quoted context omitted.
Are you really extrapolating from ONE data point? In some sense systemd is more stable in that it's fixing some longstanding bugs with sysvinit, but of course it will have some bugs of it own. If you don't want to deal with that, you could skip a release.
No it's not just one data point. This is the final straw to use the old phrase. After a few years of serious problems, our most recent being CIFS VFS problems causing panics and mounts locking up on CentOS 6.5, hard locks on RH certified hardware, power management hell and so much incredible churn with no progress and the sudden "fuck POSIX" approach, it paints a really bad picture of the current state of things. The…
Imagine you were an architect of buildings. Your day to day job is to design mundane strip malls and gas stations. You have building code on your side for much of the process. As long as you don't violate the regulation, you at worst can only make an inconvenient building, but not a dangerous one.
But imagine instead that you're building a large office building every six months, your clients demand you don't reuse any design principles on your future clients, and you not only lacked the building code, but also 1/4th of the heavy machine equipment, 1/2ths of the tools, and 3/4ths of the raw materials. I don't just mean you don't have them in stock, I mean nobody has invented them yet. And of the ones that have been invented, we don't even know all of their material properties, say nothing about what material properties we should be looking for. Will this particular bolt we are using with these particular cross beams hold up to the stresses placed on them? The answer is unknown, and I'm some cases unknowable.
It's really easy as a user to say, "they should have tested this more". While strictly true that more testing may have found your issues ahead of time (presuming the right tests were done), it is inefficient engineering to exhaustively test things. Even mechanical engineering bases a lot on statistical modeling, which will always, always have corner cases that don't match reality.
In the real world, people had to learn the hard way about things like lightning rods and sacrificial electrodes. They didn't come about from "testing during development". They came about from testing live, and seeing which buildings and boats did or did not burn down or sink. That's not bad engineering. That's just the nature of unknown problems.