61–70 of 263 posts
The reason people use UNIX-like systems is because they work reliably. In order to make a complex system work reliably, it needs to be easily fixed. In order to fix a system, a person needs to understand it as well as be able to make a change in it. And in order to understand a system, it helps very much if that system is straightforward and lucidly verbose. I hope systemd will live or die on its merits; I fear that…
Earlier quoted context omitted.
The biggest problem with dropping the syslog protocol altogether is that there's a huge amount of other stuff that speaks syslog. Things like networking gear use it for the same purposes as a normal *nix box, and getting them to switch is going to be like pulling teeth. With your particular case, I'd say you should look at rsyslog and/or syslog-ng. Both of them have backends that talk with actual databases, so you ca…
Well, journald has syslog compatibility layer and can talk syslog, so supporting any existing software is not an issue. It doesn't speak syslog by itself, so it probably can't forward logs to another networked syslog server, but I don't see anything that prevents implementing this, if necessary. The point is, journald also introduces a new protocol that's oriented at logging structured data. This way it not just prov…
I've seen more than my fair share of journald corrupting its own log due to unclean shutdowns. If I'm going to be grepping the journald log file anyway to reconstruct it (possible, but not easy, since journalctl is useless here), then why bother using it at all? It fails at the very task it was built for.
Disclaimer: I develop uselessd, probably have a warped mindset from being a Luddite who values transparency, and evil stuff like that. The author of this piece makes the classic mistake of equating the init system as the process manager and process supervisor. These are, in fact, all separate stages. The init system runs as PID 1 and strictly speaking, the sole responsibility is to daemonize, reap its children, set t…
The dead simple rc.conf file seems so much nicer than the stuff I was dealing with in the entire world of Linux-based systems, like going back to the way Arch used to be when I really liked it.
Earlier quoted context omitted.
This init process debate has brought out one of the worst elements of people in the FOSS community: treating some FOSS technology as an extension of their identity. Let's keep some perspective here. We are literally just talking about an init system. There are many others you can use. systemd is not taking away your freedom in any meaningful sense of the word "freedom". Debates should be about the technical merits of…
> systemd is not taking away your freedom in any meaningful sense of the word "freedom" This is absolutely incorrect. We're to the point where certain software packages (GNOME comes to mind) are requiring hard dependencies on it. I was just today reading about some incompatibility that arises if your kernel is set up with no IPv6 support which is explicitly caused by systemd. (To which the response from the systemd f…
If you think freedom is the ability to run only the code you want, the only way you're ever going to get freedom is by writing everything from scratch. Software will never be exactly the way you want it to be unless you write it yourself.
Most software depends on other software. That's just how things work. GNOME is particularly bad offender for that - it installed apache for some reason last time I used it. But GNOME also does a lot of things I don't really need it to do. Maybe someone else uses those features, and that's OK. You can switch DE if you really don't like systemd that much. But if you don't, that's not denying you your freedom - you made a decision about the benefits and drawbacks of a product, and decided to use that product.
Nobody really says how systemd only took over for political reasons, there's just random posts on forums that make claims and link to some dude's podcast. There's really no reason to believe that the systemd people are malicious.
I think systemd is the wrong choice for debian/ubuntu. But there's no reason to badmouth people about it and say hurtful things. Just use something else.
We often criticise systemd for being too bloated, and making it hard to write a drop in replacement. I totally agree with this line of thought. However, in my mind it has made several awesome things possible. My boot time got dramatically shorter when I adopted it thanks to parallelization. Besides, daemons have now simple and robust service definitions. Sys V had become a mess! Lastly, lightweight containers are the…
> Lastly, lightweight containers are the real-deal for small development tasks (not for production!). I've come across this sentiment a few times in the last month, but I haven't yet heard an explanation other than "VMs are battle-tested and containers might leak data to each other". Is there something more that I'm missing? Why aren't containers a good idea to use in production?
Earlier quoted context omitted.
Simple scripts? Have you looked at the shit in /etc/init.d in a modern linux distribution? $ wc -l * | sort -n | tail 274 exim4 286 apache2 290 dnsmasq 298 nfs-common 350 clamav-freshclam 364 udev 386 checkroot.sh 420 clamav-daemon 465 clamav-milter 9893 total If you look into these, you'll find tons of near-duplicate code between scripts, and frequently every script reinvents the wheel in one way or another.
The comment makes more sense if you substitute "familiar" for "simple," a tactic I use a lot while reading arguments like these.
Earlier quoted context omitted.
Classic sysvinit or BSD-style init doesn't rely upon this sort of functionality at all. Just some simple scripts. No need to complicate it any further. A few signals are all that are needed.
Simple scripts? Have you looked at the shit in /etc/init.d in a modern linux distribution? $ wc -l * | sort -n | tail 274 exim4 286 apache2 290 dnsmasq 298 nfs-common 350 clamav-freshclam 364 udev 386 checkroot.sh 420 clamav-daemon 465 clamav-milter 9893 total If you look into these, you'll find tons of near-duplicate code between scripts, and frequently every script reinvents the wheel in one way or another.
Earlier quoted context omitted.
What's wrong with old good Unix pipes?
The don't solve race conditions in peers trying to locate each other (surprisingly difficult). They don't solve a standardized marshaling format. They don't come with an implementation to integrate with main loops for event polling. They don't handle authentication (well, sort of). They have an inherent vulnerability in FD passing where you can cause the peer to lock up. You can get into deadlock situations in your m…
There's only one PID 1 - it would not be hard to locate its UNIX domain socket.
> They don't solve a standardized marshaling format.
Fair point.
> They don't come with an implementation to integrate with main loops for event polling.
They're file descriptors so they work with select, poll, etc.
> They have an inherent vulnerability in FD passing where you can cause the peer to lock up.
Please elaborate. There's nothing inherently vulnerable with FD passing. In fact, dbus relies on it so if you can't make FD passing secure then you can't make dbus secure either.
> You can get into deadlock situations in your messaging code if you aren't really careful about message sizes and when you order poll in/poll out.
I think you're overstating the difficulty of doing this correctly.
> They aren't introspect-able to see what the peer supports.
I for one am OK with PID 1 not being introspectable.
> They make it super easy to not maintain ABI.
It's quite possible to maintain ABI compatibility, but still, how much of a moving target should PID 1's ABI be anyways?
dbus is a great solution for normal applications, but PID 1 is special. The generality provided by dbus is unnecessary. PID 1 should not be servicing requests from ordinary users, so any security concerns with using UNIX domain sockets directly are moot. If there are certain actions, such as shutdown, that need to be triggered from non-root users, then there should be a separate, unprivileged, process that listens on dbus, implements authorization logic, and then relays the command to PID 1 over a UNIX domain socket using a very simple and easily-audited interface. That's good security and reliability engineering.
The reason people use UNIX-like systems is because they work reliably. In order to make a complex system work reliably, it needs to be easily fixed. In order to fix a system, a person needs to understand it as well as be able to make a change in it. And in order to understand a system, it helps very much if that system is straightforward and lucidly verbose. I hope systemd will live or die on its merits; I fear that…
It is interesting looking at how differing linux distributions approach this problem as well as things like connection management. Many do seem to be moving towards things like systemd. Angstrom Linux for the BeagleBone even bundled something called connman for managing network connections. Attempting to navigate the path of systemd plus connman to get networking to work the way I wanted was a pain. Some of the more…
Also, it's being rapidly iterated and there isn't a PPA for Ubuntu, which sucks.
Earlier quoted context omitted.
> systemd is not taking away your freedom in any meaningful sense of the word "freedom" This is absolutely incorrect. We're to the point where certain software packages (GNOME comes to mind) are requiring hard dependencies on it. I was just today reading about some incompatibility that arises if your kernel is set up with no IPv6 support which is explicitly caused by systemd. (To which the response from the systemd f…
If there's one thing I've learned about FOSS, it's that everyone is looking for an excuse to fork things. Linux will never develop a monoculture - because someone can and will fork it. How many distributions are there? desktop environments? Package managers? Text editors and IDEs? And even zooming out of linux, there's openBSD, freeBSD, etc; If you start yelling about monoculture, isn't sysv init the worst offender f…
You're kidding, right?
http://lists.freedesktop.org/archives/systemd-devel/2014-May...
http://linuxfr.org/nodes/86687/comments/1249943
http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01327.html
The systemd people and Lennart in particular are very open about their contempt for anything that isn't Linux + systemd and their intent to shove whatever they want down everybody's throats regardless of bugs or breakage, and blame everyone but themselves for what their shit breaks.
This can't be dressed up as anything but malicious.