91–100 of 464 posts
Can someone put in Layman's terms what the change entails and why it would be the end of Linux?
TL;DR systemd is winning the developer mind share. Things being built like Gnome which require SystemD thus most things will need systemd.
Earlier quoted context omitted.
Server admins have so much new technology to learn and play with to stay relevant. If they feel like learning systemd is a chore, they might be in the wrong business.
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…
The ignorance in this post runs deep . For example: Speaking of zones and Solaris, if that’s an option for you it’s probably the best of breed stack right now. Does the author have no idea what's going on with Solaris? Hint: Nothing. Nothing is going on with Solaris, because Oracle doesn't care about Solaris. They closed the source, and now push out the occasional minor update from on high for their enterprise custom…
One thing I've realized about the Linux community through all this systemd flame warring is how unbelievably conservative a large subsection of it is. There's this huge so-called "neckbeard" continent that views anything architecturally beyond the 1980s as a huge affront to Unix. IMHO I kind of shrug at this, since Unix was never really all that great to begin with. Unix won because the only commercially viable and w…
Well, here's the basic deal. If we're talking about common servers, common desktop, etc then systemd is an excellent replacement. It covers the base of users quite well. But lets say you are building a highly specialized application. You are going to be making quite a few customizations which are far more manageable through a shell scripting environment than by customizing a bunch of binaries. I assume that Redhat is…
Perhaps 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 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 lost that much time on a system function before. This is not what I expected and there is no way I could possibly introduce that to our production environment.
I think that might why people are slightly sensitive to it.
Yes you're exactly right, but replacing something with something less stable, more complicated and more difficult to debug isn't a rational or good engineering. I'm sure many people will be fed up with systemd much quicker than what was already there.
Not impressed with a community which pushes this as stable, quality software. Voting with my feet: FreeBSD is being trialled instead. WhatsApp throwing a million dollars at it draws a lot of valuable attention and puts it in the business's mindset.
Choice is as much of a valuable aspect of open source too...
>single parent hierarchy for namespaces Predictably, all the blame is laid at systemd's feet. The current churn is happening, because all of Linux's core developers (kernel and user space) are wanting that change...to push the envelope. For example, the current change in CGroup's namespaces are because kernel is mandating that the current cgroup access mechanism be deprecated. They want a single writer to Cgroups. Sy…
You mean this Kay Sievers? http://www.theregister.co.uk/2014/04/05/torvalds_sievers_dus... - It's basically the buddy of Lennart at Red Hat - at least that is my impression from far away.. systemd may be nice but it's coming from Redhat and cgroups are changed due to because systemd folks wanted it that way as far as I followed that debate...
Earlier quoted context omitted.
I'm not sure what you're saying here. If you want to avoid using a particular piece of software, but need to adhere to its API, you're going to either reimplement parts of it, or use someone else's reimplementation. There's really no way around that. It's a fundamental problem shared by all software.
Exactly. I'm (obliquely) affirming your argument that the commonly thrown-around excuse of "you don't need systemd, you just need something that implements its DBus interfaces" is a distinction without a difference.
However, I would argue that it's far easier for an end-user to drop in a replacement for a DBUS API implementation than it is to drop in a replacement for a C/C++ API implementation. So... there's that, I guess. :/
Perhaps 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…
Where I think the systemd-naysayers have a valid point is around the tight coupling that has been introduced, and is still being introduced, between systemd and various other components of a fully functional Linux system.
To take your "just submit a patch" example - say N years from now I'm unhappy with some aspect of how systemd works. I can submit a patch, or I can rewrite that whole component from scratch. However, it's entirely possible that the piece I'm unhappy with is so tightly coupled to the rest of systemd that I can't rewrite one component of it without rewriting the rest of systemd, or convincing the systemd maintainers to accept my rewrite and bake it in as the new "official" version of that component.
Where I think the criticism of systemd is valid is that the idea of modularity has taken a backseat, and the APIs between the different components of systemd haven't been very well-thought-out. The informal spec is "whatever systemd does today is correct", which of course destroys any sort of interoperability.
And by way of full disclosure, I'm an Arch user, and run systemd on 4 systems I use everyday - home desktop, home server, work desktop, work laptop. Whatever else I have to say about its design, I use it every day, and actually like the parts of it that I use. eg, the boot time for my desktop is stupidly fast, and if I want to know about some log message, I just run journalctl. I no longer care whether the foo daemon uses syslog, or writes to its own /var/log/foo.log that I should set up rotation for, or handles its own rotation as /var/log/foo/2014-11-20.log, and so on.
And just to play devil's advocate with my own position - there's a certain point where tight coupling makes sense. Linux kernel modules, for example, are tightly coupled to the Linux kernel, and don't work unmodified when compiled against a *BSD or Solaris kernel.
Earlier quoted context omitted.
It's so terrible (literally the devil incarnate, sacrifice your offspring now) that it's already been adopted by: - Arch Linux - Fedora/RHEL - openSUSE/SLES - Mageia - NixOS - CoreOS - Sabayon - Debian and Ubuntu in the near future > Everything I read about SystemD is negative. Negative on the technology, negative on the people who created it. Nothing positive. There's a vocal group that seem to think it's some Red H…
Well, in fairness, I did have a RH chap tell me to my face several weeks ago that Linux needs to replicate the Windows registry model and stop using the /etc text file approach. So I have a certain sympathy for the idea of Red Hat conspiracy (what is a company anyway but a conspiracy to produce work & products for hire?).
I don't hate the registry... I'm just not in a hurry to see Linux adopt it. What's so bad about /etc/app/config or ~/.config/app/config? It works in pretty much every platform (though the paths may be slightly different). Windows does have both roaming and local data directories, which can be pretty nice (if you don't bloat them).