Lisi, the Debian vote, as far as I am aware, actually included all currently available options. In other words upstart and systemd were not the only choices available. The thing is 4 TC members (Canonical employees) voted for what they know, the other 4 voted for systemd (I personally think it was a deliberate vote against Canonical control) and that then left the chairmans vote which, as we know, went systemd (I also believe Garbee voted systemd to vote against Canonical control). I have read the discussion and I will try to find the actual vote, in order to see if my recollection is correct, and I will reply again if I am wrong to clarify things.

On 19 September 2014 06:38, Timothy Pearson <kb9vqf@pearsoncomputing.net> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224

> Am Donnerstag, 18. September 2014 schrieb Curt Howland:
>> On Thu, Sep 18, 2014 at 12:21 PM, Mike Bird <mgb-trinity@yosemite.net>
>> 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
version).

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).

Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iFYEARELAAYFAlQbQrsACgkQLaxZSoRZrGFV1ADfbno97D6EPgSdTJgTJxI7leds
cjLrDi5bgeJDjQDgqNgeUXLs8Ew4R3/JbEzj/nqJR7rO9tNvxY1G5g==
=nIFO
-----END PGP SIGNATURE-----


---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net
For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net
Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/
Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting