Re: Re: piece of mind

[Matthias Urlichs]

Hi,

Josselin Mouette:
> Said otherwise, it is not possible to write a reliable service manager
> without integrating it to what happens in process #1. 
> 
s/is/was/. Today, you have prctl(PR_SET_CHILD_SUBREAPER) to declare
yourself as a pseudo-init to the processes you fork off -- that patch is
from Lennart, March 2012.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141025063925.gk24...@smurf.noris.de

Re: Re: piece of mind

[Cameron Norman]

On Fri, Oct 24, 2014 at 8:54 AM, Josselin Mouette  wrote:
> Jonathan de Boyne Pollard wrote:
> You know, or at least should know, as well as I that one can
> centralize the code to do all of those things, and abstract them out 
> of
> daemons into a service manager, without that service manager being
> process #1.
>
> I don’t know whether you are aware of how a UNIX system works, but you
> might not have heard of how orphan processes are managed.
>
> >From waitpid(2):
>If a parent process terminates, then its "zombie" children (if any) are
>adopted by init(8), which automatically performs a wait to  remove  the
>zombies.
>
> Said otherwise, it is not possible to write a reliable service manager
> without integrating it to what happens in process #1.

You certainly can if you use PRCTL_SET_CHILD_REAPER (only on Linux
3.4+ I think), or do not support forking daemons.

Both options are undesirable in different ways, but systemd already
requires the prctl so any alternative would not be any worse than
systemd in that respect.

--
Cameron Norman


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALZWFRJUX+Pq34Y-R=roYUigfPrZkT8g+m7OeCxoHeLCXWee=a...@mail.gmail.com

Re: piece of mind

[Russ Allbery]

Josselin Mouette  writes:
> Jonathan de Boyne Pollard wrote: 

> You know, or at least should know, as well as I that one can
> centralize the code to do all of those things, and abstract them
> out of daemons into a service manager, without that service
> manager being process #1.

> I don’t know whether you are aware of how a UNIX system works, but you
> might not have heard of how orphan processes are managed.

Jonathan certainly does.  :)

> Said otherwise, it is not possible to write a reliable service manager
> without integrating it to what happens in process #1.

There are some nice reliability features that you cannot implement without
making the service manager process 1.  However, that doesn't change
Jonathan's point, which is that people have been running process
management frameworks for at least 15 years withouot making them process
1.  I'm one of those people.  It mostly works.  I think systemd does a
*better* job, but it's clearly *possible* to do process management without
the help of process 1, and problems caused by that approach are relatively
rare.

There's really no need to oversell systemd's benefits here.  It made a set
of design decisions, which allows it to do some things better at the cost
of other tradeoffs.  There are lots of other systems out there that have
made other design tradeoffs.  None of these choices are "wrong" or
"right"; they're just different points in a tradeoff space.

The issue at the moment, at least from my perspective, is the extent to
which we, as a project, want to require all people packaging software for
the project to support multiple points in that tradeoff space as the price
for incorporating their software in the distribution.  One can be opposed
to setting that restriction on software included in the archive while
still acknowledging that there are multiple possible tradeoffs and some
people may prefer different ones and may want to work on making it
possible to choose them.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8761f9ctk4@hope.eyrie.org

Re: piece of mind

[Vincent Bernat]

 ❦ 24 octobre 2014 16:19 +0100, Jonathan de Boyne Pollard 
 :

> M. Wanderer was talking about process #1 in his message, M. Urlichs,
> which xe made synonymous with "the init system".  Your changing that
> to be the systemd package, in order to then knock that argument down,
> is a strawman.  You know, or at least should know, as well as I that
> one can centralize the code to do all of those things, and abstract
> them out of daemons into a service manager, without that service
> manager being process #1.  daemontools actually began (version 0.51
> dates from July 1997) as exactly a toolset to do this, with things
> like "svscan" and "svscanboot" coming a couple of years later.  In the
> intervening years we have seen daemontools-encore, freedt, s6, perp,
> runit, and nosh; all of which can do this. Several of them even come
> documented with instructions on how to run them under various process
> #1 programs.  daemontools, dating from when it did, had instructions
> for running under System V init and BSD init.  So does perp.  runit
> has a whole load of instructions at
> http://smarden.org/runit/useinit.html .  s6 has a whole load of
> instructions at http://skarnet.org/software/s6/s6-svscan-not-1.html .
> The dichotomy that you present as your challenge, that the choice is
> between having process #1 do all of this or having each individual
> daemon program do all of this, is a fallacious one, disproven by the
> existence of toolsets that allow for avoiding both, for some 17 years
> now.

All of them are relying on the fact that the monitored process won't
fork. They are therefore not able to handle readiness and
dependencies. Monitoring a PID without active pooling once it has
escaped with a fork _requires_ to be PID 1 (and this is still true with
PID namespaces).
-- 
printk("??? No FDIV bug? Lucky you...\n");
2.2.16 /usr/src/linux/include/asm-i386/bugs.h


signature.asc
Description: PGP signature

Re: Re: piece of mind

[Josselin Mouette]

Jonathan de Boyne Pollard wrote: 
You know, or at least should know, as well as I that one can 
centralize the code to do all of those things, and abstract them out of 
daemons into a service manager, without that service manager being 
process #1.  

I don’t know whether you are aware of how a UNIX system works, but you
might not have heard of how orphan processes are managed.

>From waitpid(2): 
   If a parent process terminates, then its "zombie" children (if any) are
   adopted by init(8), which automatically performs a wait to  remove  the
   zombies.

Said otherwise, it is not possible to write a reliable service manager
without integrating it to what happens in process #1. 

-- 
 .''`.Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1414166078.4673.474.camel@dsp0698014

Re: Re: piece of mind

[Jonathan de Boyne Pollard]

The Wanderer:

This is the problem. The init  system should not be providing

> "features" which other software might, post-boot and pre-shutdown,
> want to make use of.  (AFAIK sysvinit never did, and most - possibly
> all? - of the other init-system candidates don't either.) Such
> features should be provided separately, independent of what may
> happen to be running as PID 1.

Matthias Urlichs:

Please explain why it should  *not* provide these "features". Why

> should every daemon (or its startup script) re-implement the same
> code to put itself in the background, change UIDs, resource-limit
> and security-enhance (private /tmp) itself, when the same thing can
> be implemented once, so that I as a sysadmin (or my puppet script)
> don't have to learn ten separate ways of configuring that?

M. Wanderer was talking about process #1 in his message, M. Urlichs, 
which xe made synonymous with "the init system".  Your changing that to 
be the systemd package, in order to then knock that argument down, is a 
strawman.  You know, or at least should know, as well as I that one can 
centralize the code to do all of those things, and abstract them out of 
daemons into a service manager, without that service manager being 
process #1.  daemontools actually began (version 0.51 dates from July 
1997) as exactly a toolset to do this, with things like "svscan" and 
"svscanboot" coming a couple of years later.  In the intervening years 
we have seen daemontools-encore, freedt, s6, perp, runit, and nosh; all 
of which can do this. Several of them even come documented with 
instructions on how to run them under various process #1 programs.  
daemontools, dating from when it did, had instructions for running under 
System V init and BSD init.   So does perp.  runit has a whole load of 
instructions at http://smarden.org/runit/useinit.html .  s6 has a whole 
load of instructions at 
http://skarnet.org/software/s6/s6-svscan-not-1.html .  The dichotomy 
that you present as your challenge, that the choice is between having 
process #1 do all of this or having each individual daemon program do 
all of this, is a fallacious one, disproven by the existence of toolsets 
that allow for avoiding both, for some 17 years now.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/544a6df0.1050...@ntlworld.com

Re: piece of mind

[Axel Wagner]

Hi,

Thorsten Glaser  writes:
> This is rich. Especially in the copyleft-oriented GNU/Linux land.
> (That being said, the FSF is rather good at vendor lock-in as well.)

I'm afraid I don't understand your statement.

Best,

Axel Wagner


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/8761fbykod.fsf@rincewind.i-did-not-set--mail-host-address--so-tickle-me

Re: piece of mind

[Thorsten Glaser]

On Tue, 21 Oct 2014, Axel Wagner wrote:

> systemd in debian is: That the systemd-opponents want to take the
> freedom from other people (amongst other the gnome upstream and debian
  ^^^
> maintainers) to use the software they like in the way they like, by
> preventing them from depending on systemd.
   ^^

This is rich. Especially in the copyleft-oriented GNU/Linux land.
(That being said, the FSF is rather good at vendor lock-in as well.)

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1410220957450.32...@tglase.lan.tarent.de

Re: piece of mind

[Josselin Mouette]

Le mardi 21 octobre 2014 à 16:23 -0700, Cameron Norman a écrit :
> Also, I do not understand the log statement. Once again, Upstart can
> hook up a job's stdout/err to a file in /var/log/upstart/, but I am
> not exactly sure what was being said so maybe I missed the point.

I don’t understand how you can compare that nice hack with the ability
to gather all logging sources to a single place, *reliably* tagged by
service, integrated with service management and syslog, and that can be
queried in a fast way.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1413960594.12225.2.ca...@kagura.malsain.org

Re: piece of mind

[Russ Allbery]

The Wanderer  writes:

> At a glance at the sysvinit source, it doesn't look to me like
> /sbin/init itself does service management, in the "starting, stopping
> and monitoring services" form; at most, it seems to handle some subset
> of the "monitoring" part, in the form of noticing when something has
> died abnormally. (Which goes well beyond just services, when necessary.)

/etc/inittab is exactly starting, stopping, and monitoring services.  It's
just so bad of an implementation of the concept that people long ago
started layering another system on top and invoking it via /etc/inittab.
But I know folks who still use /etc/inittab instead of other things
layered on top precisely because it's more reliable to have PID 1 handle
the starting, stopping, and monitoring.  Even though sysvinit is missing
basically every feature that you would want from something that does this.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87wq7svjm9@hope.eyrie.org

Re: piece of mind

[The Wanderer]

On 10/21/2014 at 11:39 AM, Matthias Klumpp wrote:

> 2014-10-21 17:24 GMT+02:00 Robert Lemmen :
> 
>> hi matthias,
>> 
>> On Tue, Oct 21, 2014 at 04:35:20PM +0200, Matthias Urlichs wrote:

>>> first place. Having ten processes responsible for bits&pieces of
>>> what systemd-as-PID1 does instead of one isn't a benefit -- not
>>> if all you gain by that is nine additional processes.
>>> 
>>> "It's a big monolithic thing, and big monolithic things are bad
>>> and evil and non-Unix-y, so there!!1!" is not a valid argument.
>> 
>> but that's the thing, to some (e.g. me) ten separate processes that
>> each do a fairly small thing with understandable interfaces between
>> them is an *enormous* benefit over one bigger thing that does all
>> that in an integrated fashion. to the point that even if the one
>> big thing would have nice,additional features, I would still opt
>> for the decomposed one.
> 
> Well, you just now described systemd. The systemd project develops
> many small tools which do one thing ant interact together via
> defined interfaces.
> The init daemon is a bit more powerful that sysvinit, but it still
> only does what it is supposed to do: Starting, stopping and
> monitoring services. The other tools under the systemd umbrella do
> different things.

Is that really what the init daemon is supposed to do?

At a glance at the sysvinit source, it doesn't look to me like
/sbin/init itself does service management, in the "starting, stopping
and monitoring services" form; at most, it seems to handle some subset
of the "monitoring" part, in the form of noticing when something has
died abnormally. (Which goes well beyond just services, when necessary.)

From what I can see, it looks as if sysvinit's service management is
actually handled pretty much entirely by sysv-rc, which is not PID 1.

If that's correct, and if the systemd PID 1 binary handles service
management, then that's something it's doing which the init daemon
itself has not traditionally done. Which doesn't automatically mean that
it shouldn't, but which does seem to eliminate the argument that it
"only does what [the init daemon is] supposed to do".


Looking at the sysvinit source for this, and thinking about the
differences in relation to systemd, has led me to come up with some
ideas in regard to possible init-system-et-al. design which I think may
be interesting enough to be worth pursuing or at least discussing.
However, that discussion would cease entirely to be remotely on-topic
for debian-devel (even to whatever extent this entire thread isn't
already offtopic).

Any suggestions for a place where such discussion would be welcome or
at least acceptable, and where it would reach people who are
experienced with or at least interested in the design and
implementation of init systems? (I suspect that the systemd development
forums would satisfy the latter criterion but would not satisfy the
former.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: piece of mind

[Zbigniew Jędrzejewski-Szmek]

On Tue, Oct 21, 2014 at 05:12:56PM +0200, Svante Signell wrote:
> On Tue, 2014-10-21 at 16:03 +0200, Josselin Mouette wrote:
> > The Wanderer  wrote: 
> > This is the problem. The init system should not be providing 
> > "features"
> > which other software might, post-boot and pre-shutdown, want to 
> > make use
> > of. (AFAIK sysvinit never did, and most - possibly all? - of the 
> > other
> > init-system candidates don't either.) Such features should be 
> > provided
> > separately, independent of what may happen to be running as PID 1.
> > 
> > These features cannot exist separately. Quoting the systemd position
> > statement:
> > 
> > […] while it is true that a handful of trivial interfaces are not really
> > related to systemd (and could be split out if needed), most of these
> > features cannot be implemented without close integration to PID 1. It is
> > not possible to split the system cgroups arbitrator from the process
> > which starts services and sessions in cgroups. It is not possible to
> > ensure the relation of a log to a service if you do not have awareness
> > of how the service was launched. Et caetera. 
> 
> How is uselessd solving this then?

It's not. It simply breaks this functionality, and a lot of other
functionality.

(I just skimmed the useless.de.net page today, so I can give some more
examples, apart from the most obvious cgroups and integrated logging.

Based on the description:

- uselessd removes swap and mount units, simply calling mount and swapon 
directly.
This of course means that if the mount or swap is done by other means
the manager will not be aware of it. It probably also means that the
manager is not aware of alternative names for mount- and swap-points,
so if you say LABEL=... it will not know that /dev/dm-11 is the same thing.

- uselessd removes the integration with udev, so hardware activation is
probably gone

- uselessd simply calls fsck to do fsck, so checking of devices as they
appear and only if they are needed is also gone

... etc.)

Zbyszek


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141022020913.gl2...@in.waw.pl

Re: piece of mind

[Zbigniew Jędrzejewski-Szmek]

On Tue, Oct 21, 2014 at 04:23:39PM -0700, Cameron Norman wrote:
> El mar, 21 de oct 2014 a las 7:03 , Josselin Mouette
>  escribió:
> >The Wanderer  wrote:
> >This is the problem. The init system should not be
> >providing "features"
> >which other software might, post-boot and pre-shutdown,
> >want to make use
> >of. (AFAIK sysvinit never did, and most - possibly all? -
> >of the other
> >init-system candidates don't either.) Such features should
> >be provided
> >separately, independent of what may happen to be running
> >as PID 1.
> >
> >These features cannot exist separately. Quoting the systemd position
> >statement:
> >
> >[…] while it is true that a handful of trivial interfaces are not
> >really
> >related to systemd (and could be split out if needed), most of these
> >features cannot be implemented without close integration to PID 1.
> >It is
> >not possible to split the system cgroups arbitrator from the process
> >which starts services and sessions in cgroups. It is not possible to
> >ensure the relation of a log to a service if you do not have awareness
> >of how the service was launched. Et caetera.
> 
> Upstart can launch processes in cgroups using cgmanager since
> version 1.13. Few things are truly impossible with programming, and
> making certain functions be implemented independent of or outside of
> PID 1 does not come close to impossible.
> 
> Also, I do not understand the log statement. Once again, Upstart can
> hook up a job's stdout/err to a file in /var/log/upstart/, but I am
> not exactly sure what was being said so maybe I missed the point.
[Speaking as systemd developer] the way I understand the argument,
this is also a no-no, because the init system should not interfere with
logging in any way. So upstart violates this requirement too.

OTOH, just intercepting writes to stdout and stderr is not enough.
A lot (most?) daemons use syslog(), and journald uses the knowledge
of how PID1 arranges the cgroup layout to relate PIDs back to units
and annotates messages with service information. Without this integration
things like 'journalctl --unit=' would not work.

BTW., I've always wondered, but been to lazy to properly investigate.
how does upstart deal with rotation of those log files in
/var/log/upstart? Is it necessary to restart a daemon if it logs too
many lines?

Zbyszek


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141022021807.gm2...@in.waw.pl

Re: piece of mind

[Cameron Norman]

El mar, 21 de oct 2014 a las 7:03 , Josselin Mouette  
escribió:

The Wanderer  wrote:
This is the problem. The init system should not be providing 
"features"
which other software might, post-boot and pre-shutdown, want 
to make use
of. (AFAIK sysvinit never did, and most - possibly all? - of 
the other
init-system candidates don't either.) Such features should be 
provided
separately, independent of what may happen to be running as 
PID 1.


These features cannot exist separately. Quoting the systemd position
statement:

[…] while it is true that a handful of trivial interfaces are not 
really

related to systemd (and could be split out if needed), most of these
features cannot be implemented without close integration to PID 1. It 
is

not possible to split the system cgroups arbitrator from the process
which starts services and sessions in cgroups. It is not possible to
ensure the relation of a log to a service if you do not have awareness
of how the service was launched. Et caetera.


Upstart can launch processes in cgroups using cgmanager since version 
1.13. Few things are truly impossible with programming, and making 
certain functions be implemented independent of or outside of PID 1 
does not come close to impossible.


Also, I do not understand the log statement. Once again, Upstart can 
hook up a job's stdout/err to a file in /var/log/upstart/, but I am not 
exactly sure what was being said so maybe I missed the point.


Cheers,
--
Cameron

Re: piece of mind

[Adam Borowski]

[Sorry for slow response, testing this on one's main machine requires
dropping too much state...]  I should have CCed the bug earlier, doing this
now.

On Mon, Oct 20, 2014 at 08:37:04PM -0700, Cameron Norman wrote:
> > * the Utopia stack (restart, shutdown, suspend, hibernate, mounting USB
> >   drives, etc from GUI (with low-level tools like pm-utils working)).
> >   This is supposed to be handled by systemd-shim which doesn't currently
> >   work for me, but some folks report it being ok.
> 
> What versions (of shim and cgmgr) did you try it with? I thought these
> types of issues were fixed in Sid :/

I just retested, with current unstable (ie, 8-3 and 0.33-2).  Same results
as week ago (when shim was uploaded):

On lightdm screen, reboot/shutdown/etc are grayed out.
As a logged-in user:
* suspend/hibernate are _not_ grayed out (as they were some time ago), but
  show an error: "Failed to suspend session
  GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Permission denied"
* reboot/shutdown log me out instead, back to lightdm
I forgot to check mounting USB drives this time.


On the other hand, on a semi-fresh virtual machine (d-i beta 1), shim 8-3
started to work correctly.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141021231838.ga20...@angband.pl

Re: piece of mind

[Gunnar Wolf]

The Wanderer dijo [Tue, Oct 21, 2014 at 11:10:41AM -0400]:
> >>> Can you give an example of people doing that in case of systemd?
> >>> Because so far, everything I heard was similar to GNOME, where:
> >>> • systemd provided a feature.
> >> 
> >> This is the problem. The init system should not be providing
> >> "features" which other software might, post-boot and pre-shutdown,
> >> want to make use of.
> > 
> > Define "post-boot". What about socket activation? Or starting up my
> > database when the iSCSI link to the storage comes up, instead of
> > *whenever*? Or cleanly restarting my Apache heap-of-processes?
> 
> None of those things are done exclusively at boot / shutdown time, so
> they should not be done by the init system. If they are done at all,
> they should be done by something which can run and do them under any
> init system.

That's precisely the quid. We were used to having a passive init
system, and called "initialization" to the actions that happen upon
boot. All further state changes had to be monitored by, well, "state
monitoring daemons" (in a broad sense). But our computers are each
time less static than back in 1983.

That's the reason why most of us felt SysV had to be replaced with
something more adequate to our current reality. No, I'm not frankly
familiar with systemd (although I run it at two of my computers, but
I'm not yet familiar with its ways), but this argument has been
floating around for many years already. 

Fact is, state changes should often alter what's running. The example
you quote states the iSCSI link should be a dependency and a trigger
for the database activation. Is the network flaky? OK, the database
should shut down if it no longer has access to its backing store. Is
the iSCSI link back up? OK, the database should start answering
queries as soon as it's available. What does it take to make it
available? Well, for starters, it should be fsck'ed, as it was
forcibly unmounted (it fell out of existence).

Why shouldn't an init system take care of such operation? After all, I
configured "I want PostgreSQL to run on the server". Isn't that
enough?

Even more: If I ask my system, "why is PostgreSQL not running?", it
should clearly tell me, "the disks where it wants to reside do not
currently exist". Or even more: if I just ask the system, "how are you
feeling today?", I should be able to see (in red, bold letters)
anything that aches.

> (...)
> That isn't all you gain by it; you also gain the benefit of being able
> to use these features no matter which init system you're running. Which
> in turn helps avoid lock-in, and enable easier testing of (or migration
> to) alternatives, and prevent user surprise, and so forth.

Yes. But it would end up finally boiling up to having your favorite
init spawning nothing but this newfangled ultra-process-supervisor,
which would then start monitoring everything. That is, you'd have
whateverinit spawn a PID 2 process, which would... Perform precisely
systemd's tasks.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141021192012.gb83...@gwolf.org

Re: piece of mind

[Olav Vitters]

On Tue, Oct 21, 2014 at 10:14:35AM -0400, The Wanderer wrote:
> > These features cannot exist separately.
> 
> If that is the case, then they should not be provided at all.
> 
> That is a core disagreement here; the systemd upstream plainly rank
> those as features more valuable than either the principle(s) which
> is(/are) violated by having them be provided by PID 1 or the real-world
> consequences (in terms of other software depending on a particular init
> system) of providing them in PID 1, and other people invert those
> relative values.

You're advocating that some theory is more worthy than practical
benefits. Could you explain why?

-- 
Regards,
Olav


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141021180241.gb32...@bkor.dhs.org

Re: piece of mind

[Axel Wagner]

Hi,

The Wanderer  writes:
> This is the problem. The init system should not be providing "features"
> which other software might, post-boot and pre-shutdown, want to make use
> of. (AFAIK sysvinit never did, and most - possibly all? - of the other
> init-system candidates don't either.) Such features should be provided
> separately, independent of what may happen to be running as PID 1.

That is your opinion and you might well hold it, even if I disagree with
it. But this point has also been rehashed a thousand times and already
been answered as often, as you are well aware.

What makes your mail flamebait (look, it worked!) and make people
(me included, by the way) classify you as a troll, is that you
intentionally glossed over the point and instead started the millionth
discussion about the technical implementations of systemd, all of which
has been discussed and rediscussed ad infinitum. The point was:

If you don't like systemd, don't use it and stop stepping on people's
toes for wanting to use it. Even if they are the upstream of software
you want to use.

Don't forget, what the trigger for this millionth of discussions about
systemd in debian is: That the systemd-opponents want to take the
freedom from other people (amongst other the gnome upstream and debian
maintainers) to use the software they like in the way they like, by
preventing them from depending on systemd.

Best,

Axel Wagner


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/878uk9xqfm.fsf@rincewind.i-did-not-set--mail-host-address--so-tickle-me

Re: piece of mind

[Matthias Urlichs]

Hi,

The Wanderer:
> None of those things are done exclusively at boot / shutdown time, so
> they should not be done by the init system. If they are done at all,
> they should be done by something which can run and do them under any
> init system.
> 
The whole point of an init system is to start programs.

Do you honestly want to implement all of this twice -- once for "real"
startup+shutdown, and once for everything else? What do you do when the
line between the two gets more and more blurry?

> Because, since there is only one slot for PID 1 per system, having
> something depend on a feature that is provided by PID 1 breaks choice.

So if you want another init system, you implement that feature some other
way. Which is exactly what the systemd-shim authors are doing.

So what's the problem?

> Note that I (think I) would have no objection to providing such features
> both in PID 1 (for its own use) and in an init-system-independent
> external process, with PID 1 providing them for use by other things only
> if and as no external provider is available.

I can think of a bunch of problems you'd have to solve for this idea to
work. All of which just go away if you simply use the code in PID1. Which
you need anyway. Which is why the systemd people decided not to do that.

All this talk about generic $FEATUREs misses one crucial point: Exactly
which feature of systemd-as-PID1 would one want to move to a separate
process? And which second implementation would be a suitable replacement?

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: piece of mind

[Robert Lemmen]

hi matthias,

On Tue, Oct 21, 2014 at 05:39:49PM +0200, Matthias Klumpp wrote:
> Did you play around with systemd already?

not as much as would be ideal, but I have been running it on one
machine, adapted a few things that I run for starting, and trieid the
monitoring/restart. but really, my main concerns are fueled by pages
like this [0].

> Well, you just now described systemd. The systemd project develops
> many small tools which do one thing ant interact together via defined
> interfaces.
> The init daemon is a bit more powerful that sysvinit, but it still
> only does what it is supposed to do: Starting, stopping and monitoring
> services. The other tools under the systemd umbrella do different

ok, the way you put this sounds great, but let me contrast that with
the originall paragraph:

On Tue, Oct 21, 2014 at 04:35:20PM +0200, Matthias Urlichs wrote:
> [...]
> first place. Having ten processes responsible for bits&pieces of what
> systemd-as-PID1 does instead of one isn't a benefit -- not if all you
> gain by that is nine additional processes.

I don't quite see how these two paragraph line up. to me these seem to
be contradicting a bit...

The other point is what you expect from the interfaces between
components. In the paragraph towards the top you just say "defined", but
I am sure your quality requirements for an interface of that type are
higher than that. I would argue that the most important aspect is
compatibility across large range of versions of the interface, and a
looseness that allows either end of the interface to be (partially)
reimplemented in a different way. so for me "POSIX" is a well-defined,
stable interface (not without problems, mind you). "DBUS" means next to
nothing. 

There are a few symptoms that make me think that while an
interface may actually be defined in some way, it is so specific that
there really can only be a single implementation. In other words, what
should really be an optional part now becomes a mandatory part of the
implementation of the interface. For example, one of the core complaints
about systemd is the fact that it is linux-only. I understand that
cgroups is a nice facility, but if an init system can't start a process
without it, then it simply is far too specific (for my taste). Equally,
if my window manager has such specific and absolute requirements that
there is only a single init system that can start it, then something is
terribly amiss. it's just another process after all!

but note that I have nothing against anyone using systemd, or it being
supported in debian! what kinda rubs me the wrong way is intreoduction
of something new and shiny with the expectation that it is now everyone
else's job to make sure that the existing still works. The GR just says
that your package (with the exceptions) must not be specific to an init 
system. That seems to be a no-brainer to me, of course a normal package
must work independently of how or who started it! 

regards  robert

[0] http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

Re: piece of mind

[Matthias Klumpp]

2014-10-21 17:24 GMT+02:00 Robert Lemmen :
> hi matthias,
>
> On Tue, Oct 21, 2014 at 04:35:20PM +0200, Matthias Urlichs wrote:
>> [...]
>> first place. Having ten processes responsible for bits&pieces of what
>> systemd-as-PID1 does instead of one isn't a benefit -- not if all you gain
>> by that is nine additional processes.
>>
>> "It's a big monolithic thing, and big monolithic things are bad and evil
>> and non-Unix-y, so there!!1!" is not a valid argument.
>
> but that's the thing, to some (e.g. me) ten separate processes that each
> do a fairly small thing with understandable interfaces between them is
> an *enormous* benefit over one bigger thing that does all that in an
> integrated fashion. to the point that even if the one big thing would
> have nice,additional features, I would still opt for the decomposed
> one.
Well, you just now described systemd. The systemd project develops
many small tools which do one thing ant interact together via defined
interfaces.
The init daemon is a bit more powerful that sysvinit, but it still
only does what it is supposed to do: Starting, stopping and monitoring
services. The other tools under the systemd umbrella do different
things.
Did you play around with systemd already?
Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKNHny8Uh=+wC=8k60m1raifbh4ssbo-v8ky6usdblol6hd...@mail.gmail.com

Re: piece of mind

[Robert Lemmen]

hi matthias,

On Tue, Oct 21, 2014 at 04:35:20PM +0200, Matthias Urlichs wrote:
> [...]
> first place. Having ten processes responsible for bits&pieces of what
> systemd-as-PID1 does instead of one isn't a benefit -- not if all you gain
> by that is nine additional processes.
> 
> "It's a big monolithic thing, and big monolithic things are bad and evil
> and non-Unix-y, so there!!1!" is not a valid argument.

but that's the thing, to some (e.g. me) ten separate processes that each
do a fairly small thing with understandable interfaces between them is
an *enormous* benefit over one bigger thing that does all that in an
integrated fashion. to the point that even if the one big thing would
have nice,additional features, I would still opt for the decomposed
one.

obviously you have a different opinion and that is your good right, but
you have to accept that for a lot of people this *is* important. that's
why having the choice would be great!

regards  robert

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

Re: piece of mind

[Svante Signell]

On Tue, 2014-10-21 at 16:03 +0200, Josselin Mouette wrote:
> The Wanderer  wrote: 
> This is the problem. The init system should not be providing 
> "features"
> which other software might, post-boot and pre-shutdown, want to make 
> use
> of. (AFAIK sysvinit never did, and most - possibly all? - of the other
> init-system candidates don't either.) Such features should be provided
> separately, independent of what may happen to be running as PID 1.
> 
> These features cannot exist separately. Quoting the systemd position
> statement:
> 
> […] while it is true that a handful of trivial interfaces are not really
> related to systemd (and could be split out if needed), most of these
> features cannot be implemented without close integration to PID 1. It is
> not possible to split the system cgroups arbitrator from the process
> which starts services and sessions in cgroups. It is not possible to
> ensure the relation of a log to a service if you do not have awareness
> of how the service was launched. Et caetera. 

How is uselessd solving this then?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1413904376.15088.21.ca...@g3620.my.own.domain

Re: piece of mind

[The Wanderer]

On 10/21/2014 at 10:35 AM, Matthias Urlichs wrote:

> Hi,
> 
> The Wanderer:
> 
>>> Can you give an example of people doing that in case of systemd?
>>> Because so far, everything I heard was similar to GNOME, where:
>>> • systemd provided a feature.
>> 
>> This is the problem. The init system should not be providing
>> "features" which other software might, post-boot and pre-shutdown,
>> want to make use of.
> 
> Define "post-boot". What about socket activation? Or starting up my
> database when the iSCSI link to the storage comes up, instead of
> *whenever*? Or cleanly restarting my Apache heap-of-processes?

None of those things are done exclusively at boot / shutdown time, so
they should not be done by the init system. If they are done at all,
they should be done by something which can run and do them under any
init system.

> Please explain why it should *not* provide these "features". Why
> should every daemon (or its startup script) re-implement the same
> code to put itself in the background, change UIDs, resource-limit
> and security-enhance (private /tmp) itself,when the same thing can
> be implemented once, so that I as a sysadmin (or my puppet script)
> don't have to learn ten separate ways of configuring that?

I never said every daemon, et cetera, should reimplement those things.
They shouldn't.

Those things should be implemented centrally, in something which can
work irrespective of the current init system. (Barring possibly a
hypothetical init system which actively tries to prevent it from working.)

> There are a bunch of things systemd can do which sys5rc can't do. Why
> is it a "design flaw" to provide these in the way that's easiest to
> implement, and therefore (presumably) least buggy?

Because, since there is only one slot for PID 1 per system, having
something depend on a feature that is provided by PID 1 breaks choice.
(This is an overly simplistic answer, but I've spent half an hour
writing possible more-detailed responses to this so far, and none of
them seem both accurate and unlikely to be misconstrued.)

Note that I (think I) would have no objection to providing such features
both in PID 1 (for its own use) and in an init-system-independent
external process, with PID 1 providing them for use by other things only
if and as no external provider is available. (In fact, if I'm
understanding things correctly, systemd itself used to do it that way
with cgroups management until the kernel upstream decided that having
multiple cgroups managers running at once was broken design and would
not be supported.)

Something vaguely like that is what seems to be being worked towards
(with some current success) by the systemd-shim project, which is
something of a kludge, and will inevitably be chasing whatever interface
changes systemd upstream chooses to make. It would be better design to
decide to provide that separate implementation as part of the main
project itself (in terms of maintenance, not necessarily of
integration), rather than as a third-party backfill.

>> The decision to incorporate such features into systemd is IMO the
>> design flaw which leads to the problems to which people object.
>> That decision was made by the systemd developers
> 
> for a couple of reasonably good reasons. You might want to debate
> the validity of these reasons and the difficulty of doing it some
> other way, assuming that there's a tangible benefit of doing it
> another way in the first place. Having ten processes responsible for
> bits&pieces of what systemd-as-PID1 does instead of one isn't a
> benefit -- not if all you gain by that is nine additional processes.

That isn't all you gain by it; you also gain the benefit of being able
to use these features no matter which init system you're running. Which
in turn helps avoid lock-in, and enable easier testing of (or migration
to) alternatives, and prevent user surprise, and so forth.

> "It's a big monolithic thing, and big monolithic things are bad and
> evil and non-Unix-y, so there!!1!" is not a valid argument.

And it's not an argument I'm making, at least not at present.

I'm not aware of what those reasons are, unless you're referring to the
points referenced in the systemd position statement which Josselin
quoted. My response to that is that "do it this way" vs. "do it some
other way" ignores the possibility of "don't do it at all", which may be
the correct choice in some cases.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: piece of mind

[Matthias Urlichs]

Hi,

Neil Williams:
> A relation of a log to a service is mere configuration - a conffile is
> all that is needed for that example.
> 
No it's not. You need code which captures all of a daemon's output (and its
children -- stdout+stderr+syslog), separately from any other daemon, and
log it in a way that's attributable to that daemon. Even if logged by some
randomly-named process which this daemon started.

Whichever code is responsible for starting that daemon needs to set that
up. Then it needs to either read the output itself, or forward the file
descriptors to some logger program.

The current way of haphazardly logging to $RANDOM_SYSLOG_FILE and/or
/dev/null (guess what daemonization does to standard error, and guess what
you no longer need to do when your server runs under systemd) is a waste of
time. I want to figure out what the *censored* is wrong with $DAEMON,
not where it logs to (or how to convince it to do so in the first place).

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141021150642.ge24...@smurf.noris.de

Re: piece of mind

[Alessio Treglia]

Hi,

On Tue, Oct 21, 2014 at 3:44 PM, Ondřej Surý  wrote:
> Norbert, could you please stop your aggressive behaviour against other
> people on this list? Sadly, you are not very funny with these remarks.

Come on Ondřej, that was just sarcastic to me.
The CoC is a good thing, though such attitude to educate others about
politeness and courtesy is getting ridiculous.

Cheers.

-- 
Alessio Treglia  | www.alessiotreglia.com
Debian Developer | ales...@debian.org
Ubuntu Core Developer|  quadris...@ubuntu.com
0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAMHuwowjdFircbs7mzjWC7OdhbC-W0MzDs=3M97sCMZ=wvg...@mail.gmail.com

Re: piece of mind

[Ansgar Burchardt]

On 10/21/2014 04:43 PM, Martin Read wrote:
> On 21/10/14 15:32, Ansgar Burchardt wrote:
>> It did not work, yes. That's why, for example, fail2ban can be used by
>> local users to deny access to other users[1].
> 
> With that said, if that fact *actually matters*, you probably have
> other, worse problems.

Like students having remote access to computers in a lab? :)

Having to assume local users (be they system users or real users) do not
do stupid things seems wrong on a multi user system.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/544674b0.7040...@43-1.org

Re: piece of mind

[Thorsten Glaser]

Ondřej, could you please stop your aggressive behaviour against other
people on this list? Sadly, you are not very helpful with these remarks.
Repeatedly.

Thanks,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1410211650180.10...@tglase.lan.tarent.de

Re: piece of mind

[Ondřej Surý]

On Tue, Oct 21, 2014, at 16:13, Norbert Preining wrote:
> On Tue, 21 Oct 2014, Josselin Mouette wrote:
> > not possible to split the system cgroups arbitrator from the process
> > which starts services and sessions in cgroups. It is not possible to
> > ensure the relation of a log to a service if you do not have awareness
> > of how the service was launched. Et caetera. 
> 
> And surely that didn't work the last 20 years ... 
> 
> Only because the "Wanderer" is a troll, doesn't mean that everything
> he says is wrong.

Norbert, could you please stop your aggressive behaviour against other
people on this list? Sadly, you are not very funny with these remarks.

Thanks,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1413902683.598952.181564081.0ddf4...@webmail.messagingengine.com

Re: piece of mind

[Martin Read]

On 21/10/14 15:32, Ansgar Burchardt wrote:

It did not work, yes. That's why, for example, fail2ban can be used by
local users to deny access to other users[1].


With that said, if that fact *actually matters*, you probably have 
other, worse problems.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54467111.1030...@zen.co.uk

Re: piece of mind

[Matthias Urlichs]

Hi,

The Wanderer:
> > Can you give an example of people doing that in case of systemd?
> > Because so far, everything I heard was similar to GNOME, where:
> > • systemd provided a feature.
> 
> This is the problem. The init system should not be providing "features"
> which other software might, post-boot and pre-shutdown, want to make use
> of.

Define "post-boot". What about socket activation? Or starting up my
database when the iSCSI link to the storage comes up, instead of
*whenever*? Or cleanly restarting my Apache heap-of-processes?

Please explain why it should *not* provide these "features".
Why should every daemon (or its startup script) re-implement the same
code to put itself in the background, change UIDs, resource-limit and
security-enhance (private /tmp) itself, when the same thing can be
implemented once, so that I as a sysadmin (or my puppet script) don't have
to learn ten separate ways of configuring that?

There are a bunch of things systemd can do which sys5rc can't do. Why is it
a "design flaw" to provide these in the way that's easiest to implement,
and therefore (presumably) least buggy?

> The decision to incorporate such features into systemd is IMO the design
> flaw which leads to the problems to which people object. That decision
> was made by the systemd developers

for a couple of reasonably good reasons. You might want to debate the
validity of these reasons and the difficulty of doing it some other way,
assuming that there's a tangible benefit of doing it another way in the
first place. Having ten processes responsible for bits&pieces of what
systemd-as-PID1 does instead of one isn't a benefit -- not if all you gain
by that is nine additional processes.

"It's a big monolithic thing, and big monolithic things are bad and evil
and non-Unix-y, so there!!1!" is not a valid argument.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141021143520.gd24...@smurf.noris.de

Re: piece of mind

[Neil Williams]

On Tue, 21 Oct 2014 16:03:10 +0200
Josselin Mouette  wrote:

> The Wanderer  wrote: 
> This is the problem. The init system should not be providing
> "features" which other software might, post-boot and pre-shutdown,
> want to make use of. (AFAIK sysvinit never did, and most - possibly
> all? - of the other init-system candidates don't either.) Such
> features should be provided separately, independent of what may
> happen to be running as PID 1.
> 
> These features cannot exist separately. Quoting the systemd position
> statement:
> 
> […] while it is true that a handful of trivial interfaces are not
> really related to systemd (and could be split out if needed), most of
> these features cannot be implemented without close integration to PID
> 1. It is not possible to split the system cgroups arbitrator from the
> process which starts services and sessions in cgroups. It is not
> possible to ensure the relation of a log to a service if you do not
> have awareness of how the service was launched. Et caetera. 
> 

"not possible" is always an intolerably extreme position in software.

"Not currently possible" is very common, "not supported", "not easily
possible", "not practical", "not convenient" or "not without potentially
compromising security" are common too but all are open to new ideas and
new implementations. Security itself is a spectrum and many use cases
merit lower security to gain convenience, many other use cases have a
perfectly sane reason to require security at the cost of (nearly all)
convenience.

It is always possible to push an interface between two 'rigid' free
software components - it might not be secure in some forms and there
may be latency but to say that a method of software A interacting with
software B is "not possible" is a wild exaggeration and extremely
short-sighted. Who knows what will become possible in the future? It is
an error for any software project to state that the position of the
project on any one matter is that the software to implement the
solution to a problem is "not possible".

A relation of a log to a service is mere configuration - a conffile is
all that is needed for that example.

Any software, currently possible or not, is just a SMOP after all...

(Note: In common with a lot of us, I don't have time to work on any
other software than the load I have currently... but that does *not*
preclude someone else joining the effort and doing some of it. It is
not currently possible for me to take on more software development but
it is not impossible.)

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



signature.asc
Description: PGP signature

Re: piece of mind

[Ansgar Burchardt]

On 10/21/2014 04:13 PM, Norbert Preining wrote:
> On Tue, 21 Oct 2014, Josselin Mouette wrote:
>> not possible to split the system cgroups arbitrator from the process
>> which starts services and sessions in cgroups. It is not possible to
>> ensure the relation of a log to a service if you do not have awareness
>> of how the service was launched. Et caetera. 
> 
> And surely that didn't work the last 20 years ... 

It did not work, yes. That's why, for example, fail2ban can be used by
local users to deny access to other users[1].

If logging information includes additional information, you could make
fail2ban only block users if the log messages about failed logins come
from the SSH service.

Ansgar

  [1]



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54466e81.3060...@43-1.org

Re: piece of mind

[The Wanderer]

On 10/21/2014 at 10:13 AM, Norbert Preining wrote:

> On Tue, 21 Oct 2014, Josselin Mouette wrote:
> 
>> not possible to split the system cgroups arbitrator from the
>> process which starts services and sessions in cgroups. It is not
>> possible to ensure the relation of a log to a service if you do not
>> have awareness of how the service was launched. Et caetera.
> 
> And surely that didn't work the last 20 years ...

I believe the argument is that it didn't work reliably, or as well as it
could have and as they argue that it should. And I can see their point,
although I don't know whether I necessarily believe it holds.

> Only because the "Wanderer" is a troll, doesn't mean that everything
> he says is wrong.

I object to being characterized as a troll. I'm not trying to stir
things up or incite a furor or the like, nor am I posting to cause a
reaction for my own amusement, nor am I saying controversial or hostile
or otherwise flamebait-y things regardless of whether or not I actually
believe them, or anything along those lines.

I've actively refrained from commenting in many systemd-related threads,
here and elsewhere, when I felt that I did not have anything relevant or
useful to say, and/or when I felt that my contribution would not help
anything. It's possible that my contribution won't help anything here
either, but I judged that it was at least close enough to be worth the
risk.

Now, if you wanted to classify me as "posting flamebait" in this
specific instance, I'd have much less ground on which to refute that -
though doing so was not my goal, and I do think that even some things
which are valuable contributions to a discussion can also be classified
as flamebait. But "posting flamebait" and "being a troll" are very
different things.

(Even independent of its being used to refer to me, I don't like to see
a useful and specific term being broadened into less-useful generality
like that.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: piece of mind

[Norbert Preining]

On Tue, 21 Oct 2014, Josselin Mouette wrote:
> not possible to split the system cgroups arbitrator from the process
> which starts services and sessions in cgroups. It is not possible to
> ensure the relation of a log to a service if you do not have awareness
> of how the service was launched. Et caetera. 

And surely that didn't work the last 20 years ... 

Only because the "Wanderer" is a troll, doesn't mean that everything
he says is wrong.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141021141316.ga...@auth.logic.tuwien.ac.at

Re: piece of mind

[The Wanderer]

On 10/21/2014 at 10:03 AM, Josselin Mouette wrote:

> The Wanderer  wrote:
> 
>> This is the problem. The init system should not be providing
>> "features" which other software might, post-boot and pre-shutdown,
>> want to make use of. (AFAIK sysvinit never did, and most - possibly
>> all? - of the other init-system candidates don't either.) Such
>> features should be provided separately, independent of what may
>> happen to be running as PID 1.
> 
> These features cannot exist separately.

If that is the case, then they should not be provided at all.

That is a core disagreement here; the systemd upstream plainly rank
those as features more valuable than either the principle(s) which
is(/are) violated by having them be provided by PID 1 or the real-world
consequences (in terms of other software depending on a particular init
system) of providing them in PID 1, and other people invert those
relative values.

> Quoting the systemd position statement:
> 
> […] while it is true that a handful of trivial interfaces are not
> really related to systemd (and could be split out if needed), most of
> these features cannot be implemented without close integration to PID
> 1. It is not possible to split the system cgroups arbitrator from the
> process which starts services and sessions in cgroups. It is not
> possible to ensure the relation of a log to a service if you do not
> have awareness of how the service was launched. Et caetera.

I am aware of this statement.

I am not convinced that this is necessarily true, but even if it is,
that simply means that the decision should have been to not implement
those features at all rather than to implement them with integration to
PID 1.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: piece of mind

[Josselin Mouette]

The Wanderer  wrote: 
This is the problem. The init system should not be providing "features"
which other software might, post-boot and pre-shutdown, want to make use
of. (AFAIK sysvinit never did, and most - possibly all? - of the other
init-system candidates don't either.) Such features should be provided
separately, independent of what may happen to be running as PID 1.

These features cannot exist separately. Quoting the systemd position
statement:

[…] while it is true that a handful of trivial interfaces are not really
related to systemd (and could be split out if needed), most of these
features cannot be implemented without close integration to PID 1. It is
not possible to split the system cgroups arbitrator from the process
which starts services and sessions in cgroups. It is not possible to
ensure the relation of a log to a service if you do not have awareness
of how the service was launched. Et caetera. 

-- 
 .''`.Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1413900190.4673.249.camel@dsp0698014

Re: piece of mind

[The Wanderer]

On 10/20/2014 at 01:50 PM, Axel Wagner wrote:

> Hi Thorsten,
> 
> Thorsten Glaser  writes:
>> 
>>> "If you don't want to use my software on general principles, go
>>> away and write your own. Do not bother me."
>>> 
>>> This principle is hardly specific to systemd.
>> 
>> Yes, but other upstreams at least agree to not step on the toes of
>> people who wish to use other software.
> 
> Can you give an example of people doing that in case of systemd?
> Because so far, everything I heard was similar to GNOME, where:
> • systemd provided a feature.

This is the problem. The init system should not be providing "features"
which other software might, post-boot and pre-shutdown, want to make use
of. (AFAIK sysvinit never did, and most - possibly all? - of the other
init-system candidates don't either.) Such features should be provided
separately, independent of what may happen to be running as PID 1.

The decision to incorporate such features into systemd is IMO the design
flaw which leads to the problems to which people object. That decision
was made by the systemd developers, and is the core reason why blaming
systemd upstream for the problems that result from

> • Software A's upstream decided they wanted to use it, because it made
>   their life easier.

is arguably (but IMO often) legitimate.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: piece of mind

[Cameron Norman]

On Mon, Oct 20, 2014 at 6:43 AM, Adam Borowski  wrote:
> On Mon, Oct 20, 2014 at 08:35:05AM +0200, Christoph Biedl wrote:
>> * consider skipping jessie altogether in the hope jessie+1 will
>> provide alternatives or, at least has a systemd where development
>> speed went down significantly.
>
> That's backwards -- it's the future that's at risk, jessie is a fine release
> with just a handful of breakages that still might be fixed before it's out.
>
> Stuff I know that's broken with non-systemd:
> * the Utopia stack (restart, shutdown, suspend, hibernate, mounting USB
>   drives, etc from GUI (with low-level tools like pm-utils working)).
>   This is supposed to be handled by systemd-shim which doesn't currently
>   work for me, but some folks report it being ok.

What versions (of shim and cgmgr) did you try it with? I thought these
types of issues were fixed in Sid :/

Thanks,
--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALZWFRLKjJ+mX3eUsU7jeaAc=35ZxPxB27=6xyy32zgyuop...@mail.gmail.com

Re: piece of mind

[Axel Wagner]

Hi Thorsten,

Thorsten Glaser  writes:
>> "If you don't want to use my software on general principles, go away and
>>  write your own. Do not bother me."
>> 
>> This principle is hardly specific to systemd.
>
> Yes, but other upstreams at least agree to not step on the
> toes of people who wish to use other software.

Can you give an example of people doing that in case of systemd? Because
so far, everything I heard was similar to GNOME, where:
• systemd provided a feature.
• Software A's upstream decided they wanted to use it, because it made
  their life easier.
• systemd-opponent X wanted to use Software A, telling Software A's
  upstream they therefore can not depend on systemd.
• sytsemd-opponent X accuses systemd-upstream of stuffing systemd down
  their throats.

Or, also commonly known:
• systemd provides an init-system.
• Distribution B decides freely and using their usual process, that they
  want to migrate to systemd.
• systemd-opponent Y wants to use distribution B, telling distribution
  B's developers, they therefore can not use systemd.
• systemd-opponent Y accuses systemd-upstream of stuffing systemd down
  their throats.


I saw a lot of stepping on the toes of people who wish to use other
software than oneself, on this list in particular. In most (if not all)
cases it where the toes of various DE-upstreams or systemd-maintainers.

Best,

Axel Wagner


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/87iojehbqb.fsf@rincewind.i-did-not-set--mail-host-address--so-tickle-me

Re: piece of mind

[Alessio Treglia]

On Mon, Oct 20, 2014 at 7:35 AM, Christoph Biedl
 wrote:
> * sit and watch the things happen they don't agree with at all, things

That's not true, literally ***it can't be true***

It is in clear view that the _majority_ agrees, and every single of us
*must* fall under one of the categories listed above by Mr. Urlichs.
How dare you question that?

Cheers.

-- 
Alessio Treglia  | www.alessiotreglia.com
Debian Developer | ales...@debian.org
Ubuntu Core Developer|  quadris...@ubuntu.com
0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/camhuwow-kqoq4vkdjyjpjtj79na2juh508cscy7tcneluhz...@mail.gmail.com

Re: piece of mind

[Paul Wise]

On Mon, Oct 20, 2014 at 2:35 PM, Christoph Biedl wrote:

>   Debian installations I have at least three serious issues that prevent
>   systemd based systems from booting or being usable¹.

Are you willing to file bug reports about these issues?

https://www.debian.org/Bugs/Reporting

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6FxBfSiA-LrKeR4s8b0TZRMswMPgJ97q=8kzxkezn8...@mail.gmail.com

Re: piece of mind

[Thorsten Glaser]

On Mon, 20 Oct 2014, Matthias Urlichs wrote:

> Christoph Biedl:
> > - upstream shows little respect for people who object systemd
> 
> Why should they?

Because not doing that is asocial.

> "If you don't want to use my software on general principles, go away and
>  write your own. Do not bother me."
> 
> This principle is hardly specific to systemd.

Yes, but other upstreams at least agree to not step on the
toes of people who wish to use other software.

Good example: shell maintainers have discussed together and
decided, a year or two, that $PS1 should generally not be
“export”ed, because of differences between shells, but rather
be set in the various shells’ ~/.*rc files. Shell developers
(Chet, David and me, and sometimes zsh people) occasionally
proactively talk to each other, to possibly agree (or respect‐
fully disagree) about various features, or to discuss bugs,
or something like that.

bye,
//mirabilos
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1410201737090.7...@tglase.lan.tarent.de

Re: piece of mind

[Matthias Urlichs]

Hi,

Christoph Biedl:
> - upstream shows little respect for people who object systemd

Why should they?

"If you don't want to use my software on general principles, go away and
 write your own. Do not bother me."

This principle is hardly specific to systemd.

>   I have at least three serious issues that prevent
>   systemd based systems from booting or being usable¹.
> 
Which Debian bug numbers? Are they marked RC?

> In my personal environment, nine of ten people oppose, most of them
> unsure, some seriously concerned. Especially after they gave it a try.

Both sides can play this game. In my environment, people get annoyed when
they need to do admin work on Wheezy systems because the get used to all
the features which systemd provides. Tangible benefits. Which in my book
trump assertions of "vendor lock-in" (how is that possible, anyway? it's
free software!) and more-or-less unspecific concerns.

> Those who are in favour do this in a strong fashion that bystanders
> could easily take as "fanboy".

Yes I am a fan of systemd. I *like* a whole lot of the features it provides
and I do NOT want to re-implement the lot of them in each and every sys5rc
shell script. The only reason I don't tell you every time exactly which
features these are is that we've gone round on this multiple times, half a
year ago, on this list and off, and I'm tired of repeating myself – and
everybody else is (probably) tired of reading yet another list of features
somebody didn't know they missed until they had a system which provides
them.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: piece of mind

[Adam Borowski]

On Mon, Oct 20, 2014 at 08:35:05AM +0200, Christoph Biedl wrote:
> * consider skipping jessie altogether in the hope jessie+1 will
> provide alternatives or, at least has a systemd where development
> speed went down significantly.

That's backwards -- it's the future that's at risk, jessie is a fine release
with just a handful of breakages that still might be fixed before it's out.

Stuff I know that's broken with non-systemd:
* the Utopia stack (restart, shutdown, suspend, hibernate, mounting USB
  drives, etc from GUI (with low-level tools like pm-utils working)).
  This is supposed to be handled by systemd-shim which doesn't currently
  work for me, but some folks report it being ok.
* udev waiting 30 seconds during boot
with the whole rest being fine.  There might be more among things I don't
use, but if there was something grave, we'd hear it during the flamewars.

_I_ don't really know how to fix those.  In the case they aren't fixed
before release, and all those "fork Debian" folks turn out to be all wind,
what I would do is to make a repository with the last working version of
regressed packages (usually from a few months before now).  This is an easy
solution that lets you enjoy all the goodness of the rest of jessie.


As of the future, things look bleak if the GR fails, but it's not like
there's no hope.  For example, systemd might get chopped up into parts --
like uselessd (use-less-d or useless-d?) that would allow using the good
stuff (no boilerplate in init scripts) while retaining sanity elsewhere.
Or something else might happen.  I'm looking at openrc but its current
state doesn't look that great.  Fortunately, the freeze will serve as half
a year timeout with no big flamage expected.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141020134351.ga27...@angband.pl

Re: piece of mind

[Christoph Biedl]

Matthias Urlichs wrote...

> We don't do a GR among our users. We do that among Debian
> members/maintainers/developers/take-your-pick.
> 
> Of those, most …
> * are perfectly happy with the TC's decision
> * can live with it
> * are unhappy, but think that to continue discussing this is way worse
>   than biting the bullet and getting on with actual work
>   * you do know that we plan to release Jessie sometime this decade,
> right?
> * are disillusioned about it all and decided to stand aside

* sit and watch the things happen they don't agree with at all, things
that were not at all difficult to forsee one and two years ago. In
feelings that switch between amusement, bewilderment, and sheer
horror. And sometimes confusion whether their position is perhaps the
one of grumpy old people who object _any_ change just because things
are considered good enough the way they are right now. Or rather the
one of those who have seen a lot of changes in the past and learned
the hard way they usually cause a lot of anger and surprisingly little
improvement, so in general they are better avoided at all. Staying
with the present quirky situation might be uncomfortable but at least
it's familiar.

Since in short

- never in Debian before there has been a change that intrusive, and
  also that controversial
- systemd slowly changed from "default" to "de-facto only" init system
- systemd grew from the sysv-provided feature set to something that
  eats more and more components of a Linux system, being everything
  but unix philosophy.
- this is is fast-moving target, and no one has an idea where it will
  evolve into. So people who advocated systemd one year 2013 opted for
  an idea not for the systemd that will enter jessie.
- *many* other components require adjustment, and it just happens
- upstream shows little respect for people who object systemd
- double vendor lock-in, both upstream and Debian. Read: Runing not pure
  Debian installations I have at least three serious issues that prevent
  systemd based systems from booting or being usable¹.

* consider skipping jessie altogether in the hope jessie+1 will
provide alternatives or, at least has a systemd where development
speed went down significantly.

* or prepare moving away from Debian.

> Judging by the last couple of months, the rest appears to number <6 people.

In my personal environment, nine of ten people oppose, most of them
unsure, some seriously concerned. Especially after they gave it a try.
Those who are in favour do this in a strong fashion that bystanders
could easily take as "fanboy". Surprisingly enough, there's no "I can
take it or leave it".

Christoph

¹ All the requirements found in
  
  are met, so this list is incomplete.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1413786...@msgid.manchmal.in-ulm.de

Re: piece of mind (Re: Moderated posts?)

[Cameron Norman]

On Thu, Oct 16, 2014 at 3:02 AM, Martin Read  wrote:
> On 15/10/14 23:01, Adam Borowski wrote:
>>
>> shim doesn't appear to work, at least for me.  To get basic functionality
>> like shutdown from GUI, suspend or mounting USB drives, I needed to
>> downgrade the whole Utopia stack to their last working versions.
>
>
> Out of interest, what's the bug number?

757348 (merged with 754850, 758746)
757698
747821
760281
759745 (assigned to gdm3 currently)
and possibly 741698 (assigned to lightdm currently, IIRC)

I think most of these bugs have been fixed with the recent releases of
cgmanager and systemd-shim, just waiting for maintainers to verify and
close them. (as well as for those version to make it to testing in a
week or so)

Cheers,
--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALZWFR+WjXfRV4Hi7EQ=43=p9rtmgors+odtvjyan8vo9jh...@mail.gmail.com

Re: piece of mind (Re: Moderated posts?)

[Matthias Urlichs]

[ answered on -user only ]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141016125024.gc17...@smurf.noris.de

Re: piece of mind (Re: Moderated posts?)

[Florian Lohoff]

On Mon, Oct 13, 2014 at 10:29:11AM +0200, Matthias Urlichs wrote:
> Hi,
> 
> lee:
> > I'm sure we could find quite a few supporters for having a GR amongst
> > the users (here).
> 
> We don't do a GR among our users. We do that among Debian
> members/maintainers/developers/take-your-pick.
> 
> Of those, most …
> * are perfectly happy with the TC's decision
> * can live with it
> * are unhappy, but think that to continue discussing this is way worse
>   than biting the bullet and getting on with actual work
>   * you do know that we plan to release Jessie sometime this decade,
> right?
> * are disillusioned about it all and decided to stand aside
 ^^^

I am that. I dont like the systemd approach - i have lived 20 years
in a different linux ecosystem - i had loads of trouble with the last thing of
lennart so thanks - Evolution instead of revolution.

> 
> Judging by the last couple of months, the rest appears to number <6 people.

* Have not yet bitten by the systemd issue.

Honestly i have not installed a new debian release in the past until months 
after
the release. With a couple of hundret systems to admin you are not hurrying for
the next release.

So the masses of users have not yet even heard of systemd, nor have experienced 
it.

So my guess is that the big uproar from the sysadmins comes 3-6 Month after 
release.

Flo
-- 
Florian Lohoff f...@zz.de


signature.asc
Description: Digital signature

Re: piece of mind (Re: Moderated posts?)

[Martin Read]

On 15/10/14 23:01, Adam Borowski wrote:

shim doesn't appear to work, at least for me.  To get basic functionality
like shutdown from GUI, suspend or mounting USB drives, I needed to
downgrade the whole Utopia stack to their last working versions.


Out of interest, what's the bug number?


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543f97a6.9050...@zen.co.uk

Re: piece of mind (Re: Moderated posts?)

[Adam Borowski]

On Wed, Oct 15, 2014 at 01:49:43PM -0400, Joey Hess wrote:
> Thorsten Glaser wrote:
> > On Mon, 13 Oct 2014, Joey Hess wrote:
> > 
> > > Only thing I don't understand is why so few votes for systemd-shim out
> > > of the group who has it installed.
> > 
> > Maybe noatime? That’s probably popular on desktops. “vote” does
> > not really say much, anyway.
> 
> I doubt noatime has been popular for years, we have relatime.

relatime is almost as broken as atime.  Among other reasons, on a typical
system it adds multiple gigabytes of unique data to every cow snapshot.
Thus if you want btrfs backups, noatime is a must.

> systemd-shim getting pulled in on systems where it's not needed seems
> the most reasonable explanation. Which leaves the number of shim users
> quite small, compared with the number of systemd users.

shim doesn't appear to work, at least for me.  To get basic functionality
like shutdown from GUI, suspend or mounting USB drives, I needed to
downgrade the whole Utopia stack to their last working versions.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015220124.ga22...@angband.pl

Re: piece of mind (Re: Moderated posts?)

[Joey Hess]

Thorsten Glaser wrote:
> On Mon, 13 Oct 2014, Joey Hess wrote:
> 
> > Only thing I don't understand is why so few votes for systemd-shim out
> > of the group who has it installed.
> 
> Maybe noatime? That’s probably popular on desktops. “vote” does
> not really say much, anyway.

I doubt noatime has been popular for years, we have relatime.
And if it were, there should be a similar or larger gap between
the installed and vote lines for other packages, which is not the case.

systemd-shim getting pulled in on systems where it's not needed seems
the most reasonable explanation. Which leaves the number of shim users
quite small, compared with the number of systemd users.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: piece of mind (Re: Moderated posts?)

[Thorsten Glaser]

On Mon, 13 Oct 2014, Joey Hess wrote:

> Only thing I don't understand is why so few votes for systemd-shim out
> of the group who has it installed.

Maybe noatime? That’s probably popular on desktops. “vote” does
not really say much, anyway.

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1410151608550.30...@tglase.lan.tarent.de

Re: piece of mind (Re: Moderated posts?)

[The Wanderer]

On 10/14/2014 at 04:15 PM, Olav Vitters wrote:

> On Sun, Oct 12, 2014 at 06:18:01PM +0200, lee wrote:
> 
>> Considering that the users are Debians' priority, couldn't this
>> issue be a case in which significant concerns from/of the users
>> about an issue might initiate a GR?  Wouldn't it speak loudly for
>> Debian and its ways and for what it stands for, or used to stand
>> for, if it was established procedure that issues arising
>> significant concerns amongst the users can lead to a GR?
>> 
>> I'm sure we could find quite a few supporters for having a GR
>> amongst the users (here).  And after all, we're all kinda stuck in
>> the same boat.  A GR might have the potential to make the gap
>> between users and devs/maintainers a lot smaller.  Otherwise, this
>> gap will only continue to become wider and wider.
> 
> Debian is known for focussing a lot on focussing on quality.
> Upgrading from one version to the next is expected to be utterly
> smooth. Any bug encountered is exceptional.

Definitions of what constitutes "utterly smooth" may vary, however.


The "should upgrading from wheezy to jessie automatically switch the
init system to systemd, unless the admin has taken some sufficiently
clear action to prevent it?" question is one possible example. One side
of that debate seems to think that a properly smooth upgrade requires
that such an automatic switch take place (because otherwise the init
system doesn't get upgraded to what would be put in place by a new
install, so the upgrade can't be said to have actually completed);
another seems to think that a properly smooth upgrade requires that such
an automatic switch *not* take place (because of the chance of breaking
existing local configuration, among possibly other things).


For another example: some time ago, on debian-devel, the question arose
of whether it's reasonable to expect people to reboot promptly after
installing e.g. a new kernel, or a new init system. While of course you
can't expect to gain any functionality advantage from the
newly-installed software until the reboot in those cases, it still seems
reasonable to me to expect that no previously-existing functionality
will be *lost* in the window between such an upgrade and the next reboot.

However, at least one of the systemd Debian maintainers stated in that
discussion that while having a "keep going as normal and reboot at
leisure" scenario work smoothly would be nice, he does not consider it a
hard requirement. (The functionality at hand apparently included, but
was not necessarily limited to, power-management functionality - such as
the "reboot" button. I think that particular piece of functionality may
have been addressed since then, but the larger principle still exists.)

I think that for such a scenario to not work would place the upgrade
outside the bounds of what constitutes "utterly smooth", and I would
consider any such functionality loss to be a bug - quite possibly an RC
bug. The maintainer in question, at least, does not appear to think
that; he does appear to agree that it would be a bug, but a minor one at
best. Thus, definitions vary, Q.E.D..

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: piece of mind (Re: Moderated posts?)

[Olav Vitters]

On Sun, Oct 12, 2014 at 06:18:01PM +0200, lee wrote:
> Considering that the users are Debians' priority, couldn't this issue be
> a case in which significant concerns from/of the users about an issue
> might initiate a GR?  Wouldn't it speak loudly for Debian and its ways
> and for what it stands for, or used to stand for, if it was established
> procedure that issues arising significant concerns amongst the users can
> lead to a GR?
> 
> I'm sure we could find quite a few supporters for having a GR amongst
> the users (here).  And after all, we're all kinda stuck in the same
> boat.  A GR might have the potential to make the gap between users and
> devs/maintainers a lot smaller.  Otherwise, this gap will only continue
> to become wider and wider.

Debian is known for focussing a lot on focussing on quality. Upgrading
from one version to the next is expected to be utterly smooth. Any bug
encountered is exceptional. While in some other distributions an upgrade
might sometimes result in problems or is not even really supported very
well, Debian has a great focus on ensuring that the stable release is
utterly stable.

If you encounter problems there are known ways to have a great deal of
influence: file bugs and ensure that they're blocking the release of
Debian. AFAIK the criteria for when something can block the release of
the stable version is pretty broad, though I might be mistaken.

You can file bugs for both systemd, as well as the integration of other
init systems. Though uncertain if others would be considered to block
the release. If you encounter bugs in the support of others and they're
not considered as "blocking the release", then maybe good to start a
thread about that. I'm guessing you'll have a good chance to ensure that
those bugs are looked at and maybe exceptions made if need be.

However, if your argument is that "systemd against the users' will",
or that you have no influence. Then 1) whatever, I'd argue the opposite
and 2) you have, see above. Positive attitude helps.

-- 
Regards,
Olav


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141014201530.ga32...@bkor.dhs.org

Re: piece of mind (Re: Moderated posts?)

[Axel Wagner]

Hi,

The Wanderer  writes:
> Unfortunately, not everyone - or even everyone who would be willing to
> provide such feedback, or even actively interested in doing so - is
> going to install that.

Luckily, popcon is opt-in anyway, so this has no effect whatsoever on
it's quality as a data source.

Best,

Axel Wagner


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/87vbnmh1ga.fsf@rincewind.i-did-not-set--mail-host-address--so-tickle-me

Re: piece of mind (Re: Moderated posts?)

[Don Armstrong]

On Tue, 14 Oct 2014, Ian Jackson wrote:
> I think in future we should probably make a habit of posting something
> to d-d-a when there is a GR proposal.

If the proposer thinks posting to d-d-a is a good idea, then they should
just do it. Any DD can, after all.

They should ideally point out the issue, and set follow up directly to
-vote. Perhaps just adding a note to
https://www.debian.org/vote/howto_proposal suggesting that as a
possibility would be enough.

-- 
Don Armstrong  http://www.donarmstrong.com

It seems intuitively obvious to me, which means that it might be wrong
 -- Chris Torek


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141014145719.gh23...@teltox.donarmstrong.com

Re: piece of mind (Re: Moderated posts?)

[The Wanderer]

On 10/13/2014 at 01:01 PM, Henrique de Moraes Holschuh wrote:

> On Mon, 13 Oct 2014, Matthias Urlichs wrote:
> 
>> In any case, users _do_ have a say. They can force their systems to
>> remain on sys5 init, or switch to a different distro if that should
>> also turn out
> 
> Which, I should add, is something we measure if the user installs 
> popularity-contest and opts-in to its measurements.
> 
> http://popcon.debian.org/

Unfortunately, not everyone - or even everyone who would be willing to
provide such feedback, or even actively interested in doing so - is
going to install that.

In my case, I don't install popcon because it pollutes the
tab-completion namespace for 'popd' in a root shell. That interferes
with my workflow to the point that I've reluctantly decided to just not
install popcon - with the unfortunate side effect that my package
preferences don't get counted in this kind of statistics.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: piece of mind (Re: Moderated posts?)

[Jonathan Dowland]

On Tue, Oct 14, 2014 at 11:11:35AM +0100, Ian Jackson wrote:
> I think in future we should probably make a habit of posting something
> to d-d-a when there is a GR proposal.

Yep, liw made the same point on -project in response to a thread I started
there on this subject. I still feel we don't adequately document where GRs
should be announced. As things stand, we should probably amend [1], assuming
there is no strenuous objection. I'll at least raise the bug.

[1] https://www.debian.org/vote/howto_proposal


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141014124109.ga28...@chew.redmars.org

Re: piece of mind (Re: Moderated posts?)

[Ian Jackson]

Didier 'OdyX' Raboud writes ("Re: piece of mind (Re: Moderated posts?)"):
> Le mardi, 14 octobre 2014, 01.13:48 Wookey a écrit :
> > I'm just pointing out that interested people, who are moderately
> > well-involved, really did miss that a GR was attempted.
> 
> For the record, I don't disagree; I'm just saying that the GR call was 
> on the right list and that I think that the project's documented 
> expectation is that those interested in GR calls should have been 
> following -vote, as documented on our website:
> 
>   https://lists.debian.org/2644371.u0TgOhpbrd@gyllingar

Indeed.

I think in future we should probably make a habit of posting something
to d-d-a when there is a GR proposal.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21564.63191.410031.84...@chiark.greenend.org.uk

Re: piece of mind (Re: Moderated posts?)

[Didier 'OdyX' Raboud]

Le mardi, 14 octobre 2014, 01.13:48 Wookey a écrit :
> I'm just pointing out that interested people, who are moderately
> well-involved, really did miss that a GR was attempted.

For the record, I don't disagree; I'm just saying that the GR call was 
on the right list and that I think that the project's documented 
expectation is that those interested in GR calls should have been 
following -vote, as documented on our website:

https://lists.debian.org/2644371.u0TgOhpbrd@gyllingar

Cheers,
OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/3544854.5pQuf1ujCs@gyllingar

Re: piece of mind (Re: Moderated posts?)

[Joey Hess]

Joey Hess wrote:
> A small percentage of server users are avoiding swiching to systemd,
> although that group looks to still be shrinking somewhat.

Of course, not many people use unstable/testing for servers, so we don't
really know much from popcon yet about whether server admins will go for
systemd. People installing unstable/testing desktops at this point might
also tend to be more open to experimentation and so more open to using
systemd than stable users.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: piece of mind (Re: Moderated posts?)

[Ian Jackson]

Philip Hands writes ("Re: piece of mind (Re: Moderated posts?)"):
> I'm completely astonished that Ian is willing to suggest that four more
> people pledging support for it at this stage would be enough for him to
> attempt CPR on its putrid corpse.

You put me in an awkward position.  My email was an attempt to get
this discussion shut down on -devel, where it is off-topic and a total
waste of energy.

But your response, using phrases like `dead horse', invites me to list
what I see as continuing provocations (by the victorious camp) which
in my mind make the need for a GR, along the lines proposed by Matthew
earlier in the year, perhaps even more urgent than before.

I'm well aware that I lost the (fixed) vote and that I'm in a minority
and that some of the principles I care about are going to be trampled
into the dust.  There's no need to rub it in quite so much.

Ian.
(still bitter)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21564.29421.257584.313...@chiark.greenend.org.uk

Re: piece of mind (Re: Moderated posts?)

[Wookey]

+++ Didier 'OdyX' Raboud [2014-10-13 17:33 +0200]:
> I really don't buy the argument that "the GR proposal was too quiet to 
> be noticed by 6+ people". I mean: the proposition happened to be in the 
> middle of the post-TC decision wave, on the mailing lists where it 
> belonged. The people who cared about the whole "default init for Debian" 
> question _were_ following and contributing to these various lists. I'm 
> therefore claiming that the people who missed the GR proposal were not 
> sufficiently interested (otherwise they would've been subscribed to 
> either -vote or -project, where these proposals belong). 

I might well have supported a GR (depending exactly what it said), but
I'm not on -vote or -project (yes, I probably should be), so I didn't
notice that one was proposed. (I was also very busy trying to do
actual work). I was a little surprised that all that angst failed to
generate a GR. Turn out that in fact it did.

> Doing this now despite the fact that the GR didn't reach its 6 seconds, 
> 7 months ago, will lead to an incredibly bigger waste of time, just when 
> we're about to freeze testing.
> 
> The GR train passed…

At this point I'm inclined to agree. 

I'm just pointing out that interested people, who are moderately
well-involved, really did miss that a GR was attempted.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141014001348.gk19...@stoneboat.aleph1.co.uk

Re: piece of mind (Re: Moderated posts?)

[Ansgar Burchardt]

Joey Hess  writes:
> Yes we do: sysvinit-core systemd-sysv systemd-shim
>
> https://qa.debian.org/popcon-graph.php?packages=sysvinit-core+systemd-sysv+systemd-shim&show_installed=on&show_vote=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
[...]
> Only thing I don't understand is why so few votes for systemd-shim out
> of the group who has it installed.

Maybe people who have systemd-shim installed but use systemd as their
init system? As far as I understand systemd-shim should not be doing
anything in this case, thus get no vote.

But then I would have expected the number of people using it to be
higher, maybe I'm missing something.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87d29v1rbd@deep-thought.43-1.org

Re: piece of mind (Re: Moderated posts?)

[Joey Hess]

Henrique de Moraes Holschuh wrote:
> Right now it is the "defaults" effect, because Debian stable is included in
> the report.  We don't have a "testing + unstable" report.

Yes we do: sysvinit-core systemd-sysv systemd-shim

https://qa.debian.org/popcon-graph.php?packages=sysvinit-core+systemd-sysv+systemd-shim&show_installed=on&show_vote=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

Seems pretty unambiguous: We are rapidly converging to most sysvinit users
also using systemd-shim -- those are desktop users who don't want systemd.
That population of hold-outs is decreasing somewhat rapidly too.
A small percentage of server users are avoiding swiching to systemd,
although that group looks to still be shrinking somewhat.

Also, comparing installed vs vote shows that quite a lot of systems have
had systemd installed but not rebooted into it yet. How much has the
(debian) systemd bug report rate gone up in the past month, as its
number of users has skyrocketed, I wonder?

Only thing I don't understand is why so few votes for systemd-shim out
of the group who has it installed.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: piece of mind (Re: Moderated posts?)

[Philip Hands]

Miles Fidelman  writes:

> Didier 'OdyX' Raboud wrote:
>> I really don't buy the argument that "the GR proposal was too quiet to
>> be noticed by 6+ people". I mean: the proposition happened to be in the
>> middle of the post-TC decision wave, on the mailing lists where it
>> belonged. The people who cared about the whole "default init for Debian"
>> question _were_ following and contributing to these various lists. I'm
>> therefore claiming that the people who missed the GR proposal were not
>> sufficiently interested (otherwise they would've been subscribed to
>> either -vote or -project, where these proposals belong). I'm also
>> thankful that the proposer limited his proposal to these lists (I'd have
>> considered a spread of the call over -devel, -user or other lists an
>> abuse).
>>
>>
>
> Actually - I'd contest that, for four reasons:
>
> - as I've previously noted - the major impacts of systemd are being 
> (going to be) felt by sysadmins and upstream developers - who don't 
> necessarily follow debian-devel all that closely -- or have input
>
> - the actual GR call for vote was buried on debian-vote - immediately 
> jumped on regarding wording and procedural discussions

Nonsense.

It was cross-posted on debian-project, and constituted almost half of
the list traffic in March:

  https://lists.debian.org/debian-project/2014/03/threads.html#0

it also bled onto debian-user more than once.

> - actual discussion of the GR on -devel was completely swamped by all 
> the other discussion of systemd
>
> - folks have just now pointed to the -project list --- this is the first 
> I've ever heard of that list

OK, so you missed the memo about a GR.

... but AFAICS you don't have a vote, so it seems to me this lack of
knowledge could have no significant impact on your life.  Unless the
lost opportunity to shout from the sidelines is deeply galling to you,
which it seems it may be.

Even if you had a vote, and even if you'd known about the GR and had
seconded it, and even if the other people who have expressed similar
sentiments all had votes, and all seconded the GR, and it had therefore
clawed its way over the first minuscule hurdle that it actually fell at,
this horse it clearly dead and it would be best if people stopped
beating it.

I'm completely astonished that Ian is willing to suggest that four more
people pledging support for it at this stage would be enough for him to
attempt CPR on its putrid corpse.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


pgpEeVNd1WakG.pgp
Description: PGP signature

Re: piece of mind (Re: Moderated posts?)

[Didier 'OdyX' Raboud]

Le lundi, 13 octobre 2014, 12.23:00 Miles Fidelman a écrit :
> Didier 'OdyX' Raboud wrote:
> > I really don't buy the argument that "the GR proposal was too quiet
> > to be noticed by 6+ people".
> 
> Actually - I'd contest that, for four reasons:
> 
> - as I've previously noted - the major impacts of systemd are being
> (going to be) felt by sysadmins and upstream developers - who don't
> necessarily follow debian-devel all that closely -- or have input

Mind you, most if not all of the CTTE are both sysadmins and upstream 
developers, and I'd go as far as saying that most of DDs are either too.

> - the actual GR call for vote was buried on debian-vote - immediately
> jumped on regarding wording and procedural discussions

Yes, and? There was a proposal on -vote, which could have been followed 
by seconds, totally ignoring the side-discussions. Don't expect 
launching a GR about a) overriding a Debian body; b) the default init 
system to be a quiet ride.

> - actual discussion of the GR on -devel was completely swamped by all
> the other discussion of systemd

My feeling is that the swamping happened because some people disagreeing 
with the CTTE vote vented a lot of frustration through whining and 
complaining instead of focusing their energy to formulate a concrete 
proposal for a GR.

We're talking about finding _6_ seconds, so I'd only buy this argument 
if the threshold was 50 (or so) and we'd have only found a dozen 
seconds.

OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2605439.lZGhNDzrLW@gyllingar

Re: piece of mind (Re: Moderated posts?)

[Jeroen Dekkers]

At Mon, 13 Oct 2014 13:23:16 -0400,
Miles Fidelman wrote:
> 
> Henrique de Moraes Holschuh wrote:
> > On Mon, 13 Oct 2014, Matthias Urlichs wrote:
> >> In any case, users _do_ have a say. They can force their systems to remain
> >> on sys5 init, or switch to a different distro if that should also turn out
> > Which, I should add, is something we measure if the user installs
> > popularity-contest and opts-in to its measurements.
> >
> > http://popcon.debian.org/
> >
> 
> which sure seems to reinforce the popularity of sysvinit
> 
> 18sysvinit   697126 583755 44903 63528  4940
> 19imagemagick671330 54630 97400 59765 459535
> 20pam664835 424521 161793 74475  4046
> 21evolution-data-server  661614 129835 138891 91065 301823
> 22perl   642831 412336 121683 76726 32086
> 23systemd630568 287748 54129 57693 230998
> 
> 
> Then again, how much of that is simply an artifact of default
> initialization, vs. by choice, is unclear.

Comparing those source packages is just comparing the previous
essential sysvinit package against udev. If you want a better picture
you should look at systemd-sysv versus sysvinit-core:

2335  systemd-sysv   19845 14413   925  4504 3 (Debian 
Systemd Maintainers)
4623  sysvinit-core   5634  4866   576   191 1 (Debian 
Sysvinit Maintainers)

Sysvinit-core was introduced in jessie and systemd-sysv conflicts with
sysvinit-core. Systemd-sysv is also available in wheezy, but there are
24486 reports from the popcon version 1.61 (testing/unstable) which
means only about 1000 of the systemd-sysv installs seem to be from
wheezy. So a big majority of the testing/unstable users don't seem to
have a problem with systemd, just like a majority of the DDs don't
have a problem with systemd or else we would already have had a GR.

It would be nice if the minority which doesn't like systemd would just
accept that systemd is the default init system in jessie and that the
majority of developers and users don't seem to have any problem with
that.

Kind regards,

Jeroen Dekkers


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87wq83lt6p.wl%jer...@dekkers.ch

Re: piece of mind (Re: Moderated posts?)

[Ansgar Burchardt]

Hi,

[ Please followup on -user@, there is no need to have this on two
  lists. ]

Miles Fidelman  writes:
> Henrique de Moraes Holschuh wrote:
>> http://popcon.debian.org/
>
> which sure seems to reinforce the popularity of sysvinit
>
> 18sysvinit   697126 583755 44903 63528  4940

Not really: sysvinit is the (only) supported init system in (old)stable
which is also included in the result.

But in Jessie the init part is provided by the new sysvinit-core
package. So we can compare the installation numbers of systemd-sysv and
sysvinit-core to see what people have installed in Jessie.

As [1] shows the majority of Jessie users have migrated to systemd,
probably as an effect of GNOME starting to depend on it (around May
2014) and the new init package (around June 2014).

Ansgar

  [1] 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87y4sjon24@deep-thought.43-1.org

Re: piece of mind (Re: Moderated posts?)

[Henrique de Moraes Holschuh]

On Mon, 13 Oct 2014, Miles Fidelman wrote:
> Henrique de Moraes Holschuh wrote:
> >On Mon, 13 Oct 2014, Matthias Urlichs wrote:
> >>In any case, users _do_ have a say. They can force their systems to remain
> >>on sys5 init, or switch to a different distro if that should also turn out
> >Which, I should add, is something we measure if the user installs
> >popularity-contest and opts-in to its measurements.
> >
> >http://popcon.debian.org/
> 
> which sure seems to reinforce the popularity of sysvinit

...

> Then again, how much of that is simply an artifact of default
> initialization, vs. by choice, is unclear.

Right now it is the "defaults" effect, because Debian stable is included in
the report.  We don't have a "testing + unstable" report.

"Statistics per popularity-contest releases" gives you an approximate
breakdown of what is in the "all" report, I think.

We will only have decent data on this about six months after jessie becomes
stable.  But it will be useful nonetheless.

Being able to filter reports to consider only those from testing+unstable
might make it more useful at the shorter term, though.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141013175522.gb20...@khazad-dum.debian.net

Re: piece of mind (Re: Moderated posts?)

[Miles Fidelman]

Henrique de Moraes Holschuh wrote:

On Mon, 13 Oct 2014, Matthias Urlichs wrote:

In any case, users _do_ have a say. They can force their systems to remain
on sys5 init, or switch to a different distro if that should also turn out

Which, I should add, is something we measure if the user installs
popularity-contest and opts-in to its measurements.

http://popcon.debian.org/



which sure seems to reinforce the popularity of sysvinit

18sysvinit   697126 583755 44903 63528  4940
19imagemagick671330 54630 97400 59765 459535
20pam664835 424521 161793 74475  4046
21evolution-data-server  661614 129835 138891 91065 301823
22perl   642831 412336 121683 76726 32086
23systemd630568 287748 54129 57693 230998


Then again, how much of that is simply an artifact of default 
initialization, vs. by choice, is unclear.




--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543c0a84.1080...@meetinghouse.net

Re: piece of mind (Re: Moderated posts?)

[Henrique de Moraes Holschuh]

On Mon, 13 Oct 2014, Matthias Urlichs wrote:
> In any case, users _do_ have a say. They can force their systems to remain
> on sys5 init, or switch to a different distro if that should also turn out

Which, I should add, is something we measure if the user installs
popularity-contest and opts-in to its measurements.

http://popcon.debian.org/

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141013170138.ga20...@khazad-dum.debian.net

Re: piece of mind (Re: Moderated posts?)

[Matthias Klumpp]

2014-10-13 18:23 GMT+02:00 Miles Fidelman :
> Didier 'OdyX' Raboud wrote:
>>
>> I really don't buy the argument that "the GR proposal was too quiet to
>> be noticed by 6+ people". I mean: the proposition happened to be in the
>> middle of the post-TC decision wave, on the mailing lists where it
>> belonged. The people who cared about the whole "default init for Debian"
>> question _were_ following and contributing to these various lists. I'm
>> therefore claiming that the people who missed the GR proposal were not
>> sufficiently interested (otherwise they would've been subscribed to
>> either -vote or -project, where these proposals belong). I'm also
>> thankful that the proposer limited his proposal to these lists (I'd have
>> considered a spread of the call over -devel, -user or other lists an
>> abuse).
>>
>>
>
> Actually - I'd contest that, for four reasons:
>
> - as I've previously noted - the major impacts of systemd are being (going
> to be) felt by sysadmins and upstream developers - who don't necessarily
> follow debian-devel all that closely -- or have input
>
> - the actual GR call for vote was buried on debian-vote - immediately jumped
> on regarding wording and procedural discussions
You do understand that we have procedured at Debian to handle stuff
like GR proposals, right? And that procedure involves posting to
debian-vote, so doing that was the right thing to do.


> - actual discussion of the GR on -devel was completely swamped by all the
> other discussion of systemd
That's why it was posted to -vote, where it belonged to.

> - folks have just now pointed to the -project list --- this is the first
> I've ever heard of that list - and I note that it is not even listed on
> https://lists.debian.org/users.html or https://lists.debian.org/devel.html
> -- only on the full list of lists, where it's buried without a description
> of what it's for
Debian Developers know of this (or at least should know of these lists
and subscibe to the ones they are interested in). Since we are
building the distribution and have to carry the additional work our
decisions cause, it's good to follow well-established procedures. That
was done here, and the attempt has failed.
If users notice these project-internal things is not really a concern
- for users we write release notes, and encourage involvement in
discussions about the subject (or even explicitly request feedback).
So, there is really nothing wrong or broken here, everything works as it should.
And the thing we have to do now is to make Jessie as good as possible,
and the systemd transition as painless and bug-free as possible. And
of course, also document what people need to do if they want sysvinit
instead of systemd.
Cheers,
Matthias



-- 
I welcome VSRE emails. See http://vsre.info/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caknhny8jefmhuhieco_bnvncmorq-28znd3fe3socdakhw3...@mail.gmail.com

Re: piece of mind (Re: Moderated posts?)

[Miles Fidelman]

Didier 'OdyX' Raboud wrote:

I really don't buy the argument that "the GR proposal was too quiet to
be noticed by 6+ people". I mean: the proposition happened to be in the
middle of the post-TC decision wave, on the mailing lists where it
belonged. The people who cared about the whole "default init for Debian"
question _were_ following and contributing to these various lists. I'm
therefore claiming that the people who missed the GR proposal were not
sufficiently interested (otherwise they would've been subscribed to
either -vote or -project, where these proposals belong). I'm also
thankful that the proposer limited his proposal to these lists (I'd have
considered a spread of the call over -devel, -user or other lists an
abuse).




Actually - I'd contest that, for four reasons:

- as I've previously noted - the major impacts of systemd are being 
(going to be) felt by sysadmins and upstream developers - who don't 
necessarily follow debian-devel all that closely -- or have input


- the actual GR call for vote was buried on debian-vote - immediately 
jumped on regarding wording and procedural discussions


- actual discussion of the GR on -devel was completely swamped by all 
the other discussion of systemd


- folks have just now pointed to the -project list --- this is the first 
I've ever heard of that list - and I note that it is not even listed on 
https://lists.debian.org/users.html or 
https://lists.debian.org/devel.html -- only on the full list of lists, 
where it's buried without a description of what it's for


Miles Fidelman


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543bfc64.4050...@meetinghouse.net

Re: piece of mind (Re: Moderated posts?)

[Didier 'OdyX' Raboud]

I really don't buy the argument that "the GR proposal was too quiet to 
be noticed by 6+ people". I mean: the proposition happened to be in the 
middle of the post-TC decision wave, on the mailing lists where it 
belonged. The people who cared about the whole "default init for Debian" 
question _were_ following and contributing to these various lists. I'm 
therefore claiming that the people who missed the GR proposal were not 
sufficiently interested (otherwise they would've been subscribed to 
either -vote or -project, where these proposals belong). I'm also 
thankful that the proposer limited his proposal to these lists (I'd have 
considered a spread of the call over -devel, -user or other lists an 
abuse).

Le lundi, 13 octobre 2014, 16.15:02 Ian Jackson a écrit :
> If four other DDs send me and Matthew Vernon private email to say that
> they would support a GR on this subject, I will restart this
> conversation on -project.

Doing this now despite the fact that the GR didn't reach its 6 seconds, 
7 months ago, will lead to an incredibly bigger waste of time, just when 
we're about to freeze testing.

The GR train passed…

Cheers,
OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/17667995.ybzVghadep@gyllingar

Re: piece of mind (Re: Moderated posts?)

[Ian Jackson]

Miles Fidelman writes ("Re: piece of mind (Re: Moderated posts?)"):
> In reading through the archives, I have to say that the GR proposal was 
> both buried in all the broader discussion of systemd, rather long and 
> convoluted reading, and not well publicized.

If four other DDs send me and Matthew Vernon private email to say that
they would support a GR on this subject, I will restart this
conversation on -project.

Until a total of six DDs want a GR, we should drop this topic.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21563.60534.190732.528...@chiark.greenend.org.uk

Re: piece of mind (Re: Moderated posts?)

[Miles Fidelman]

Matthias Urlichs wrote:

Hi,

Miles Fidelman:

Judging by the last couple of months, the rest appears to number <6 people.

A lot more than that, by my count.


Then the question is why almost all of these "lot more" people did not
second the GR proposal.


Well... as a couple of people have now pointed out, at least some people 
didn't know about it.


In reading through the archives, I have to say that the GR proposal was 
both buried in all the broader discussion of systemd, rather long and 
convoluted reading, and not well publicized.


I do wonder what would happen if a clearly worded proposal (e.g., start 
with "maintain systemv init as the default system" or "require that 
packages not depend on systemd running as PID1") were well publicized, 
today.






Those who are most impacted are sys admins of servers, and upstream
developers - the two communities most impacted, but that seem to have no say
in the matter.


Correct. So? Debian consists of its members, i.e. people working (in
whatever capacity) on Debian itself. _Using_ a distribution does not
in itself constitute working on it. Neither does work on an Upstream package.


Given a policy that stresses the primacy of users, it disturbs me that 
the technical committee and "members" don't seem to be paying any attention.


And... if a platform's technical leadership doesn't care about those who 
develop for that platform, that concerns me as well.


If you want to change that and include users and/or Upstream developers in
our constituency more directly, you're free to go ahead and draft/discuss
a GR for that. (I might even support it.)


Given that I have servers to run, and a full-time job that has nothing 
to do with that set of responsibilities -- I'm putting my efforts into:

- stretching out the lifetime of my current Debian installations
- looking for a new platform to migrate to

Somehow, neither of these seems like a great investment of time:
- wading through every single dependency that systemd might impact
- politicking (especially as I'm NOT a Debian developer eligible to 
propose or vote on GRs) - and this debacle has convinced me it's not 
worth becoming one




In any case, users _do_ have a say. They can force their systems to remain
on sys5 init, or switch to a different distro if that should also turn out
to be unsatisfactory. Likewise, upstream developers can refuse to include
unit files or systemd-supporting tidbits (like socket activation) in their
source code.


It sure would be interesting to survey folks on this.  I expect I'm not 
the only one busily looking for an exit.


Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543be5d2.1070...@meetinghouse.net

Re: piece of mind (Re: Moderated posts?)

[Matthias Urlichs]

Hi,

Miles Fidelman:
> >Judging by the last couple of months, the rest appears to number <6 people.
> 
> A lot more than that, by my count.
> 
Then the question is why almost all of these "lot more" people did not
second the GR proposal.

> Those who are most impacted are sys admins of servers, and upstream
> developers - the two communities most impacted, but that seem to have no say
> in the matter.
> 
Correct. So? Debian consists of its members, i.e. people working (in
whatever capacity) on Debian itself. _Using_ a distribution does not
in itself constitute working on it. Neither does work on an Upstream package.

If you want to change that and include users and/or Upstream developers in
our constituency more directly, you're free to go ahead and draft/discuss
a GR for that. (I might even support it.)

But please don't just do this in the context of yet another attempt to
express dissatisfaction with the fact that our TC chose systemd:
if you do, I do not think you'll achieve anything except more annoyance
about the fact that we're discussing this *again*, and further regression
to a discussion climate where each&every mention of systemd automatically
raises hackles on both "sides".

Which will do any number of things, but not improve Debian.
And that's, ostensibly, what we're all here for.

In any case, users _do_ have a say. They can force their systems to remain
on sys5 init, or switch to a different distro if that should also turn out
to be unsatisfactory. Likewise, upstream developers can refuse to include
unit files or systemd-supporting tidbits (like socket activation) in their
source code.

Fact is that the vast majority of them don't. There has been no huge outcry
among Fedora users about switching to systemd, for example. So, frankly,
there doesn't seem to be a need to maufacture one here.

I'm not accusing you of doing so, mind you, but sometimes that is what
these repeated attempts to warm up Debian's systemd discussion look like.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141013140643.gn3...@smurf.noris.de

Re: piece of mind (Re: Moderated posts?)

[Thorsten Glaser]

On Mon, 13 Oct 2014, Neil Williams wrote:

> > (I did not have the chance to Second the GR proposal
> > because I was not even aware that there *was* one.)
> 
> https://lists.debian.org/debian-vote/
> 
> Same procedure as previous calls for GR: debian-vote mailing list. If

Yeah, surprise, I don’t read every list. I haven’t been
that long with Debian to know about previous votes, except
DPL elections. I’m subscribed to about the bare minimum,
and only occasionally look into others. And d-vote wasn’t
mentioned in the “welcome” eMail either.

OK, I probably should have done more research myself.
But for that, I would still have needed to know that
I should do that.

Meh, anyway.

bye,
//mirabilos
-- 
This space for rent.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1410131514490.28...@tglase.lan.tarent.de

Re: piece of mind (Re: Moderated posts?)

[Neil Williams]

On Mon, 13 Oct 2014 14:21:45 +0200
Thorsten Glaser  wrote:

> On Mon, 13 Oct 2014, Miles Fidelman wrote:
> 
> > Those who are most impacted are sys admins of servers, and upstream
> > developers
> 
> I’m both, and I joined Debian to try to make an impact…
> 
> > - the two communities most impacted, but that seem to have no say
> > in the matter.
> 
> … but even then, am drowned by the masses.
> 
> (I did not have the chance to Second the GR proposal
> because I was not even aware that there *was* one.)

https://lists.debian.org/debian-vote/

Same procedure as previous calls for GR: debian-vote mailing list. If
it had received some public seconds, it would have had a wider
announcement and a listing on https://www.debian.org/vote/

https://lists.debian.org/debian-vote/2014/03/msg0.html

After a lot of discussion, resulting in:

https://lists.debian.org/debian-vote/2014/03/msg00188.html
https://lists.debian.org/debian-vote/2014/03/msg00189.html
"Withdrawal of Proposal"

Lack of support for the GR (from those entitled to vote upon the GR)
was the declared reason for withdrawal.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



signature.asc
Description: PGP signature

Re: piece of mind (Re: Moderated posts?)

[Charles Plessy]

Le Mon, Oct 13, 2014 at 02:21:45PM +0200, Thorsten Glaser a écrit :
> 
> … but even then, am drowned by the masses.

No, you are drowning the masses under your emails, that is different.

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141013122644.gb3...@falafel.plessy.net

Re: piece of mind (Re: Moderated posts?)

[Thorsten Glaser]

On Mon, 13 Oct 2014, Miles Fidelman wrote:

> Those who are most impacted are sys admins of servers, and upstream developers

I’m both, and I joined Debian to try to make an impact…

> - the two communities most impacted, but that seem to have no say in the
> matter.

… but even then, am drowned by the masses.

(I did not have the chance to Second the GR proposal
because I was not even aware that there *was* one.)

bye,
//mirabilos
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1410131420190.28...@tglase.lan.tarent.de

Re: piece of mind (Re: Moderated posts?)

[Miles Fidelman]

Matthias Urlichs wrote:

Hi,

lee:

I'm sure we could find quite a few supporters for having a GR amongst
the users (here).

We don't do a GR among our users. We do that among Debian
members/maintainers/developers/take-your-pick.


Which does kind of lead back to the question of what's the point of a 
social contract that says users and their needs are the priority.



Of those, most …
* are perfectly happy with the TC's decision
* can live with it
* are unhappy, but think that to continue discussing this is way worse
   than biting the bullet and getting on with actual work
   * you do know that we plan to release Jessie sometime this decade,
 right?
* are disillusioned about it all and decided to stand aside

Judging by the last couple of months, the rest appears to number <6 people.



A lot more than that, by my count.

Also.. it occurs to me that another constituency, that is probably not 
well represented, are upstream developers.


Those who are most impacted are sys admins of servers, and upstream 
developers - the two communities most impacted, but that seem to have no 
say in the matter.


Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543bbe9c.5030...@meetinghouse.net

Re: piece of mind (Re: Moderated posts?)

[Matthias Urlichs]

Hi,

lee:
> I'm sure we could find quite a few supporters for having a GR amongst
> the users (here).

We don't do a GR among our users. We do that among Debian
members/maintainers/developers/take-your-pick.

Of those, most …
* are perfectly happy with the TC's decision
* can live with it
* are unhappy, but think that to continue discussing this is way worse
  than biting the bullet and getting on with actual work
  * you do know that we plan to release Jessie sometime this decade,
right?
* are disillusioned about it all and decided to stand aside

Judging by the last couple of months, the rest appears to number <6 people.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: piece of mind (Re: Moderated posts?)

[Bas Wijnen]

[Moving this to -project, where it belongs; please follow up only
there, not on -user or -devel.]

On Sun, Oct 12, 2014 at 06:18:01PM +0200, lee wrote:
> Why doesn't Debian just do a GR on this issue?

Because for a GR, a member of Debian has to request it and it needs to
be seconded by at least 5 other members (constitution 4.2.1, 4.2.7).
This has not happened.

> It would be interesting to see what the devs/maintainers would vote for,
> and it might give everyone quite a bit a of re-assurance and
> piece-of-mind.

Given that there have not been 6 members asking for this vote, I don't
see a lot of unrest.

> Considering that the users are Debians' priority, couldn't this issue be
> a case in which significant concerns from/of the users about an issue
> might initiate a GR?

No. Debian is a very elitist organization.  The members decide what to
do, and nobody else does.  As a whole we rule over our users with
enlightened absolutism.  The main difference with rulers of countries is
that our users can go away more easily. ;-)

Debian is extremely democratic for its members, but it is utterly
undemocratic for its users.  And there's nothing wrong with that, IMO.

> Wouldn't it speak loudly for Debian and its ways and for what it
> stands for, or used to stand for, if it was established procedure that
> issues arising significant concerns amongst the users can lead to a
> GR?

I'll speak for myself here: I don't really care about the init system.
I am unhappy with the emotions that this debate is causing, but I'm not
very interested in the technical parts.  From what I see on the mailing
lists, it seems that a few users are very unhappy and they keep bringing
this up.  But if this would be a big issue for many people, then there
should be no problem finding 6 members to start a GR (our members are
users, too).  That still hasn't happened, so I conclude that it isn't a
big issue.

> I'm sure we could find quite a few supporters for having a GR amongst
> the users (here).  And after all, we're all kinda stuck in the same
> boat.  A GR might have the potential to make the gap between users and
> devs/maintainers a lot smaller.  Otherwise, this gap will only continue
> to become wider and wider.

There are many members.  If you can't manage to convince 6 of them, we
don't consider it a big issue.  You may disagree, but that's Debian's
rules.

Thanks,
Bas


signature.asc
Description: Digital signature

piece of mind (Re: Moderated posts?)

[lee]

Jonathan Dowland  writes:

> The tech-ctte exploration was extremely thorough, entirely transparent and I
> cannot think of any example of a more transparent decision making process in
> any other Linux community.  Not only that, but the entire decision could be
> overridden by a GR, which *any* developer could raise, at any time (and still
> can). And the eventual outcome wasn't "there will be one init system", which
> would be *considerably* easier for the project to manage, but that we support
> *multiple* init systems! A tremendously more complex task. Red Hat aren't 
> doing
> that. Fedora aren't doing that. Ubuntu aren't doing that.

Why doesn't Debian just do a GR on this issue?

It would be interesting to see what the devs/maintainers would vote for,
and it might give everyone quite a bit a of re-assurance and
piece-of-mind.

Perhaps just having a GR would ignore the established way of initiating
one and having it would create a case of precedence.  I don't see how
that would be a problem, even less so since switching to a different
init system is, AFAIK, unprecedented in Debian.

Perhaps this is an issue for which to decide about the established ways
are not sufficient.

Considering that the users are Debians' priority, couldn't this issue be
a case in which significant concerns from/of the users about an issue
might initiate a GR?  Wouldn't it speak loudly for Debian and its ways
and for what it stands for, or used to stand for, if it was established
procedure that issues arising significant concerns amongst the users can
lead to a GR?

I'm sure we could find quite a few supporters for having a GR amongst
the users (here).  And after all, we're all kinda stuck in the same
boat.  A GR might have the potential to make the gap between users and
devs/maintainers a lot smaller.  Otherwise, this gap will only continue
to become wider and wider.


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8738atz2m6@yun.yagibdah.de