111–120 of 263 posts
Earlier quoted context omitted.
This. The FreeBSD rc system just works, is well documented and is small enough to understand by one person without too much effort.
Are there reasons why Linux couldn't just adopt it?
Out of confused mind.) There is no fundamental problem that it "solves" which other UNIXes presumably still does have. The problem does not exist. AIX, Solaris, *BSD and many old-school Linux guys will tell you that. Also, any old-school guy will tell you that a kitchen-sink, put-it-all-in design is a wrong way. btw, user processes supervision is a task of an OS kernel, which it handles via a bunch of specialized sys…
I'm pretty sure /sbin/init runs in userspace even on *BSDs and Solaris, and does process supervision.
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.
I also suspect you're running RH. Under Debian script lengths are typically quite short:
n: 104 sum: 13553 min: 8 max: 1246 mean: 130.317308 median: 99 sd: 138.595750
That outlier, by the way, is xprint, part of CUPS. Never had to touch it myself.
Quite a few of those lines are comments, and the basic structure is a set of start / stop / restart blocks.
Out of confused mind.) There is no fundamental problem that it "solves" which other UNIXes presumably still does have. The problem does not exist. AIX, Solaris, *BSD and many old-school Linux guys will tell you that. Also, any old-school guy will tell you that a kitchen-sink, put-it-all-in design is a wrong way. btw, user processes supervision is a task of an OS kernel, which it handles via a bunch of specialized sys…
btw, user processes supervision is a task of an OS kernel, which it handles via a bunch of specialized syscalls, not of some "man-in-the-middle" user-level daemons. I'm pretty sure /sbin/init runs in userspace even on *BSDs and Solaris, and does process supervision.
initscripts has nothing to do with /sbin/init, surprise?
Earlier quoted context omitted.
> To stuff everything in the init system, I'd argue, is bad design. You've slayed the straw man... ;-) systemd doesn't put everything in pid 1. It defines some mechanisms to orchestrate the whole thing that include pid 1.
Whether it's all in pid 1 or not is irrelevant. What matters is that it has a monolithic architecture, whereby breakage in any one part or their communication channels can bring down the whole system. This is not just a theoretical concern; it has REPEATEDLY happened.
I think systemd actually clears up a loot of stuff. As the article describes. The main thing that scares me is the binary loging format I can think of some benefits but mostly it just seams scary. I guess I will get go se later if the benifits outweighs the rest.
Am I the only one who's disgusted with this bloated, convoluted, dbus-dependent pile of crap? I mean, c'mon, binary log files? I'll pass, thanks. It replaces way more than it needed to. I prefer the BSD-style philosophy, nice, simple rc.conf, used to run Arch till it got infected with this garbage too. It slowly progressed away from it's BSD-style roots. So recently, I just gave up and moved to FreeBSD. Not a single…
It all depends on the use cases.
For me, FreeBSD is a no go given my desktop usage requirements.
Earlier quoted context omitted.
Are there reasons why Linux couldn't just adopt it?
There's nothing stopping a Linux distro doing this.... but It would be a step backwards: it is simpler, and does less stuff, so booting would be slower and some features are missing.
My BSD systems boot quickly enough for me.
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…