[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ale] [Fwd: Advertising on ale.org] - OT MS vs Apple vs Linux/UNIX
On Sat, Sep 12, 2015 at 04:31:42PM -0400, Steve Litt wrote:
> That is exactly, 100% precisely what I'm saying, Soloman. Every piece
> of software should keep to its problem domain scope, and not subsume
> the functionality of wide-ranging other software that already do it
I think you and I have rather different defintions of "already doing it
well" -- "I'm used to it" is not the same thing.
In this particular case, systemd has precisely two required components,
systemd-pid1 and systemd-journald. From systemd's persepective,
absolutely everything else is optional and can be replaced.
Now specific linux distributions may or may not make it easy to replace
its use of specific systemd components, but that's always been the case
(distribution "differentiation" and all that) and isn't really systemd's
> What I described in the preceding paragraph has always been the belief
> of Linux (and Unix before it). Perhaps the new breed thinks otherwise.
> That's fine, just don't make your software almost impossible to
> replace, for those of us who do believe in small tools that do a
> specific task.
Post-systemd, that task is as difficult as it was pre-systemd. (Yes,
I've done this before in the process of building embedded distros meant
for Wifi access points -- and believe me if systemd was an option ten
years ago I'd have chosen it in a heartbeat. It would have saved
literally months of effort!)
> > 1) udev is independent. Use of it does not require use of systemd,
> > and if you can show the udev developers otherwise, they will treat it
> > as a bug report and correct it.
> OK, I'll do just that, the next time I alt-init anything. Of course,
> because installing udev on a systemd distro pulls in systemd, I'll also
> have to hand compile it. If I have problems, I'll submit a bug report.
That's the distro's fault, not systemd's. Then again, udev has been a
core package for mainstream distros for far longer than systemd has been
around, so I'm not sure why you'd even be manually installing it.
> > 3) What does systemd have to do with intramfs, other than systemd
> > often being physically present on one?
> You really don't know?
> Systemd doesn't just let the initramf' /init script run and fire
> off the hard disk's /sbin/init. It gets in with the initramfs and does
> stuff. Other people can describe it exactly, but it messes with
You're going to have to be more descriptive than "does stuff", beause
from systemd's own documentation, it won't touch intramfs unless
explicitly told to do so.
So, blame your distribution for choosing to use systemd's features to
simplify their bootup and restart processes..
> Systemd likewise uses /initramfs for shutdown.
Again, only if requested, but even then... so what? A whole lot of
other stuff is utilized upon a (clean) system shutdown.
Solomon Peachy pizza at shaftnet dot org
Delray Beach, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 155 bytes
Desc: not available