Message: previous - next
Month: September 2014

Re: [trinity-users] systemd and sysvinit, a question

From: "Timothy Pearson" <kb9vqf@...>
Date: Thu, 18 Sep 2014 15:38:19 -0500
Hash: SHA224

> Am Donnerstag, 18. September 2014 schrieb Curt Howland:
>> On Thu, Sep 18, 2014 at 12:21 PM, Mike Bird <mgb-trinity@...>
>> wrote:
>> > Gnu/Linux probably does need a new init, and something along the
>> > lines of the core 1% of systemd with optional cgroups support would
>> > be a good approach.
>> Just like X, sysvinit was proclaimed in need of replacement many years
>> ago, for many reasons.
>> The problem is that the functionality of these packages has been built
>> over time to answer particular problems. Any new system is going to
>> have to go through exactly the same process, the slow evolution of
>> "Gee, I didn't think anyone used it for that."
>> Sysvinit allowed for parallel boot without changing "everything". And
>> it's especially good at being able to change pretty much any single
>> component without a reboot.
>> This kind of flexibility will, I believe, turn out to be more
>> important than the systemd developers believe it to be.
>> I will echo that, being just a user, I am happy to use whatever works.
>> > I thank Tim and Sl�vek and others for making TDE optionally work
>> > with systemd without depending upon systemd - unlike Debian where
>> > systemd proponents are frantically changing packages to unnecessarily
>> > require systemd.
>> Indeed. Thank you.
>> Curt-
> Just some system-rafiness from debian jessie:
> Logfiles are binary. So you can't simply boot with a live disto and look
> at the logfiles. Better even, there are no persistent logfiles by default.
> Well, who would care to look at logfiles, anyway?
> systemd/logind/journald/networkd/usersession share PID 1. Great, if
> somthing there goes haywire you have to reboot the system, 'cause you
> cannot kill one of these processes individually. On the other hand, who
> would ever have a system running more than a week, now that it's booting
> so fast? Well, and for the Windows user we have implemented the "reboot
> after upgrade"-feature at last. Now isn't that great?
> Maybe these points are of no value for desktop users, but it's essential
> in my business that systems run reliably and can quite well be fixed
> remotely. That's not the case with systemd any more. It's diametrically to
> unix philosophy. It's more like "One Ring to rule them all, One Ring to
> find them, One Ring to bring them all and in the darkness bind them" than
> "Freedom of choice"
> If systemd will become mandatory on Debian I already see myself packing
> things up and move to an other Unix land. Well, hopefully TDE will work on
> FreeBSD or OpenBSD then :-)
> Nik

I don't see how they could get away with this on servers; uptime is
typically measured in hundreds of days here and is only interrupted when a
kernel update is required (e.g. when upgrading to another Debian/Ubuntu

TDE will not intentionally introduce a hard dependency on systemd;
personally I hate the DBUS design and implementation and have avoided it
wherever possible.  Even the new hardware library can have all
DBUS-related code disabled (albeit with some loss in functionality).

Version: GnuPG v1.4.9 (GNU/Linux)