Re: Please more fish

[Russ Allbery]

Michael Gilbert  writes:
> On Sat, Nov 8, 2014 at 8:08 PM, Russ Allbery wrote:

>> And yet, I don't see how it could have been said better.  Thank you so
>> much for putting this into words.

> How can you possibly think no more need said?  You are one of four
> complicit in the act that finally pushed Joey over the edge [0].

[...]

If anyone reads this message and feels some urge to jump in and defend me
or argue with Michael, I would take it as a personal favor if you would
set that message aside unsent and put the energy into something positive,
like telling Joey how much you appreciate his work.

I don't want this to be taken as asking for criticism to be shut down, so
I'm not asking this of anyone who wants to agree with Michael.  If you
want to do that in public or private, please go ahead.  But I would
greatly appreciate not being the cause or motivation for another heated
argument on debian-devel, with anyone in the project, and I don't need the
public defense.

Thank you.

-- 
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/87vbmpyqq5@hope.eyrie.org

Re: Please more fish

[Michael Gilbert]

On Sat, Nov 8, 2014 at 10:53 PM, Russ Allbery wrote:
> I don't want this to be taken as asking for criticism to be shut down, so
> I'm not asking this of anyone who wants to agree with Michael.  If you
> want to do that in public or private, please go ahead.  But I would
> greatly appreciate not being the cause or motivation for another heated
> argument on debian-devel, with anyone in the project, and I don't need the
> public defense.

My message is intentional, and intentionally harsh.

The damage caused to the project by alienating Joey is astounding, and
the inability to recognize that even more so.

Best wishes,
Mike


-- 
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/CANTw=mp2--k_x3ffqm7dn1azjufb0nxsm0vjl37qhszdsk3...@mail.gmail.com

Re: Please more fish

[Russ Allbery]

Michael Gilbert  writes:
> On Sat, Nov 8, 2014 at 10:53 PM, Russ Allbery wrote:

>> I don't want this to be taken as asking for criticism to be shut down,
>> so I'm not asking this of anyone who wants to agree with Michael.  If
>> you want to do that in public or private, please go ahead.  But I would
>> greatly appreciate not being the cause or motivation for another heated
>> argument on debian-devel, with anyone in the project, and I don't need
>> the public defense.

> My message is intentional, and intentionally harsh.

I know, and I respect that, and I think that I understand where you're
coming from.  And I also greatly appreciate the passion and love for the
project that led you to say what you said.

> The damage caused to the project by alienating Joey is astounding, and
> the inability to recognize that even more so.

I'm sure that a lot of us are doing a lot of soul-searching right now.  I
certainly am.  Not all of that is going to immediately happen in public.
I respect what you're saying, and I fully support you saying it in public
if you feel that will be helpful.  I'm not going to respond to the
substance of what you're saying right now mainly because there are a lot
of things that I want to think about, and I don't believe thinking about
them in public is right for me.

This is not a request for you to stop.

I thought Zlatan's message was beautiful, and it really touched me, and I
wanted to say that.  It may have been better if I'd said that in private.

Please do not read that message as implying that his message is all that
needs to ever be said, or that it should be the end of any conversation,
or even that it's everything that I'm personally thinking.

-- 
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/87h9y9ypgy@hope.eyrie.org

Re: Please more fish

[Jonathan Dowland]

On Sat, Nov 08, 2014 at 08:20:29PM -0800, Russ Allbery wrote:
> I thought Zlatan's message was beautiful, and it really touched me, and I
> wanted to say that.  It may have been better if I'd said that in private.

No, such public appreciation messages are a pleasure to read. Please do not
refrain in future.


-- 
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/20141109195523.ge29...@chew.redmars.org

Please more fish (was: so long and thanks for all the fish)

[Michael Gilbert]

On Sat, Nov 8, 2014 at 8:08 PM, Russ Allbery wrote:
> zlatan writes:
>
>> In advance sorry for all spelling mistake that I will write as I am
>> writing from my phone and I am not a native English speaker.
>
> [...]
>
> And yet, I don't see how it could have been said better.  Thank you so
> much for putting this into words.

How can you possibly think no more need said?  You are one of four
complicit in the act that finally pushed Joey over the edge [0].

The fire bell is ringing, and no one is getting out of bed.

The legitimacy of the technical committee has been entirely destroyed
by misguided acts over the last year.

The sad part is that this all would have been avoided if the
composition were more mindfulness of potential consequence to their
actions, especially in the face of some observers stating exactly that
during the process.

For the technical committee to regain any stasis of legitimacy, the
composition must change.  All those involved (both explicitly and
complicity) in the vote that caused Joey's suicide from Debian should
consider resigning in shame.

Even then,we need to reconsider the implicit danger of imbuing power
that can do so much damage to a potentially non-representative subset
of project members.

Best wishes,
Mike

[0] https://lists.debian.org/debian-ctte/2014/11/msg00045.html


-- 
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/CANTw=MO52GAMLEayYX5w6T2+uQqh4uqaopRsj220_kdT=yz...@mail.gmail.com

Re: Please more fish (was: so long and thanks for all the fish)

[Christoph Anton Mitterer]

On Sat, 2014-11-08 at 22:32 -0500, Michael Gilbert wrote: 
> You are one of four
> complicit in the act that finally pushed Joey over the edge [0].
Don't you think it goes a bit far to personally accusing some people of
this?
I guess Joey was long enough in the business to have known how to deal
with people he may have fought or disagreed with... and even if there
may have been something that gave the final spark for him to decide to
leave (there always must be, right?), it was likely no decision that
evolved out of wrath in one specific matter.

I'd think that if one has devoted so many years of one's own life into
some project, then such decision is very well made and evolved over some
long time.
Since after all, for someone who spend so much time for a project,
leaving it will actually mean a considerable chance of his life.


> The fire bell is ringing, and no one is getting out of bed.
Well that's probably a different topic, isn't it? As the recent
discussions have shown, there are many people who feel Debian goes the
wrong way in some fields - but I wouldn't make this all up to systemd.
I mean I have my concerns as well, mainly what happens to the BSDs, and
that I dislike the strong integration of systems that get too complex
(this always failed sooner or later)... but this is less the fault of
systemd itself, is it?
In the end it's quite easy: sysvinit has many deficiencies ans missing
feature, systemd is superior in all places.
The only thing *I* regret is that it's not really used to it's full
potential - i.e. in some places it rather seem we just try to rebuild
sysvinit in systemd, restricting ourselfs.
And for all people who are so unhappy with how GNOME develops,... well
I'm so either, but there are alternatives and as long as these can be
used, everything's fine.


But apart from these flame wars... giving personal responsibility to
someone seems really a bad way... if Debian starts engaging in that,
then it will really suffer terribly.


Actually I've just waited for it to happen, nevertheless it's kinda
disturbing.
Instead of further adding fuel to the fire, one should perhaps better
try to have people reconciling and maybe convince Joey to rescind from
leaving and remain in the project he spend so much time of is life for.


> The legitimacy of the technical committee has been entirely destroyed
> by misguided acts over the last year.
Well others would say that decisions had to be made, and the best that
was possible might have been done?


> All those involved (both explicitly and
> complicity) in the vote that caused Joey's suicide from Debian should
> consider resigning in shame.
"suicide"? o.O


> Even then,we need to reconsider the implicit danger of imbuing power
> that can do so much damage to a potentially non-representative subset
> of project members.
Quite often it also seems to be one of Debian's biggest issues, not to
have such leading people at least decide anything.



Cheers,
Chris. 


-- 
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/1415505472.4593.8.ca...@scientia.net

Re: Please more fish (was: so long and thanks for all the fish)

[Michael Gilbert]

On Sat, Nov 8, 2014 at 10:57 PM, Christoph Anton Mitterer wrote:
> On Sat, 2014-11-08 at 22:32 -0500, Michael Gilbert wrote:
>> You are one of four
>> complicit in the act that finally pushed Joey over the edge [0].
>
> Don't you think it goes a bit far to personally accusing some people of
> this?

No accusation, just a statement of fact.  Four ctte members were
complicit in the vote [0] that catalyzed Joey's resignation.

>> The fire bell is ringing, and no one is getting out of bed.
>
> Well that's probably a different topic, isn't it? As the recent
> discussions have shown, there are many people who feel Debian goes the
> wrong way in some fields - but I wouldn't make this all up to systemd.

No, the fire is not systemd, it is the politicization of the project
via ctte and GR rather than patient evolution of the best technical
solution.

>> The legitimacy of the technical committee has been entirely destroyed
>> by misguided acts over the last year.
>
> Well others would say that decisions had to be made, and the best that
> was possible might have been done?

Sometimes the best decision is none at all.  It can sometimes take a
lot of time for the right solution to evolve, but that requires
patience, and the project seems to have lost that quality.  That is
why Joey is gone.

Best wishes,
Mike


-- 
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/CANTw=MP6-eb9_b3Q1E2kh+BJW7J_L+81Bz8o=mpaeav8bcx...@mail.gmail.com

Re: Please more fish (was: so long and thanks for all the fish)

[Christoph Anton Mitterer]

On Sat, 2014-11-08 at 23:30 -0500, Michael Gilbert wrote: 
> No accusation, just a statement of fact.  Four ctte members were
> complicit in the vote [0]
Well maybe I read that ruling wrong, but didn't it more or less say
"we're not deciding anything right now"?

And even if that decision would be the sole reason for Joey to leave
(which I don't know whether it is, but I'd guess it's probably not)...
the tech-ctte member probably decide to their best knowledge.
And especially they cannot, nor should say, make their decision based on
the fear that otherwise XYZ might leave.
And I'm absolutely *not* implying that this happened here - but since
you accuse the tech-ctte (or some of it's members) to be responsible for
Joey to leave, it probably needed to be said.


> No, the fire is not systemd, it is the politicization of the project
> via ctte and GR rather than patient evolution of the best technical
> solution.
And you really believe that this would have been ever solved by
evolution? I strongly doubt.
You see how some people insist on sysvinit these days - sometimes (not
always) it looks they'd only do so to be against systemd.
You also see how many people were in favour of upstart - and I doubt
that Shuttleworth would have basically killed the project as he did
(quite quickly) after the decision, though he could have prevented so
many useless fights from happening in Debian... o.O

All of these systems were capable of booting a Linux,... and you really
think one of them would have won sooner or later by technical evolution?
I doubt. The technical superior system was IMHO rather clear from the
beginning,... and it were political reasons that prevented it from
winning immediately.


> >> The legitimacy of the technical committee has been entirely destroyed
> >> by misguided acts over the last year.
> >
> > Well others would say that decisions had to be made, and the best that
> > was possible might have been done?
> 
> Sometimes the best decision is none at all.
Sometimes,... but in many other cases it's also the worst choice.
We have so many things that would have never come true if not a single
decision in favour of them would have been made.
Basically everything which spans more than a few (unrelated) packages
needs this.

Look at the controversial proposals for some security things I've made
in the past,... I usually had the feeling that people in principle
agreed that it would be a good thing to take action there, but since all
of them require quite some work in many fields and no decision was made,
nothing of these will ever be solved.


> It can sometimes take a
> lot of time for the right solution to evolve, but that requires
> patience, and the project seems to have lost that quality.
This can however also mean that we always stand still, and just pursue
the evolutions that others made.
Never wondered why things like systemd or upstart didn't originate in
Debian?

Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Please more fish (was: so long and thanks for all the fish)

[Michael Gilbert]

On Sun, Nov 9, 2014 at 12:01 AM, Christoph Anton Mitterer wrote:
> On Sat, 2014-11-08 at 23:30 -0500, Michael Gilbert wrote:
>> No accusation, just a statement of fact.  Four ctte members were
>> complicit in the vote [0]
>
> Well maybe I read that ruling wrong, but didn't it more or less say
> "we're not deciding anything right now"?
>
> And even if that decision would be the sole reason for Joey to leave

Please actually read Joey's message to understand his concern, which
is not at all about content or systemd, but the harmful actions of
some project members and the complicity of others in those actions
over some significant time now.

Best wishes,
Mike


-- 
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/CANTw=mmlzugz44byvimaog9c4j-0prqfz_i6tksgzqacogs...@mail.gmail.com

Re: Please more fish (was: so long and thanks for all the fish)

[The Wanderer]

On 11/08/2014 at 10:57 PM, Christoph Anton Mitterer wrote:

> In the end it's quite easy: sysvinit has many deficiencies ans
> missing feature, systemd is superior in all places.


On 11/09/2014 at 12:01 AM, Christoph Anton Mitterer wrote:

> All of these systems were capable of booting a Linux,... and you
> really think one of them would have won sooner or later by technical
> evolution? I doubt. The technical superior system was IMHO rather
> clear from the beginning,... and it were political reasons that
> prevented it from winning immediately.

If you're *trying* to turn this into yet another systemd flamewar
thread, you're certainly using the right sort of rhetoric.


On 11/09/2014 at 01:28 AM, Michael Gilbert wrote:

> Please actually read Joey's message to understand his concern, which
> is not at all about content or systemd, but the harmful actions of
> some project members and the complicity of others in those actions
> over some significant time now.

Agreed. (Or IHO harmful, at least - I'm not taking a position on that
myself, not least because I probably haven't seen most of the actions in
question.)

-- 
   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: Please more fish (was: so long and thanks for all the fish)

[Josselin Mouette]

Le samedi 08 novembre 2014 à 23:30 -0500, Michael Gilbert a écrit : 
> No, the fire is not systemd, it is the politicization of the project
> via ctte and GR rather than patient evolution of the best technical
> solution.

You are definitely right. However, I think we would all appreciate if
you could be less antagonistic about it. Especially against the person
in the CTTE who has been spending the most time digging actual technical
solutions.

The harm is done. The question is: how can we improve our
decision-making process?

-- 
 .''`.  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/1415538543.25061.5.camel@tomoyo

Re: Please more fish (was: so long and thanks for all the fish)

[Ralf Jung]

Hi,

On 09/11/14 07:28, Michael Gilbert wrote:
> On Sun, Nov 9, 2014 at 12:01 AM, Christoph Anton Mitterer wrote:
>> On Sat, 2014-11-08 at 23:30 -0500, Michael Gilbert wrote:
>>> No accusation, just a statement of fact.  Four ctte members were
>>> complicit in the vote [0]
>>
>> Well maybe I read that ruling wrong, but didn't it more or less say
>> "we're not deciding anything right now"?
>>
>> And even if that decision would be the sole reason for Joey to leave
> 
> Please actually read Joey's message to understand his concern, which
> is not at all about content or systemd, but the harmful actions of
> some project members and the complicity of others in those actions
> over some significant time now.

Please forgive my naiveness, but I do not understand what you are saying
here. Now, I am just an "informed outsider" of this discussion, so maybe
that was actually intentional. But I agree with Christoph that it looks
to me like the decision in this case was not to have a decision. Also,
five CTTE members agreed on that, so I don't understand where you got
your number 4 from.
I read Joey's message over and over without getting any more clues. He
said the CTTE has "Decided it should make a decision", which it seems to
me it did not. So I probably misunderstood something more fundamental here.

Maybe you were intentionally vague, then please just disregard this
message. I don't want to heat the discussion, just understand.

Kind regards
Ralf


-- 
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/545f83d3.90...@ralfj.de

Re: Please more fish (was: so long and thanks for all the fish)

[Michael Gilbert]

On Sun, Nov 9, 2014 at 10:10 AM, Ralf Jung wrote:
> I read Joey's message over and over without getting any more clues. He
> said the CTTE has "Decided it should make a decision", which it seems to
> me it did not. So I probably misunderstood something more fundamental here.

Read all of #762194 very carefully.  Note that no technical
disagreement existed between project members, it was initiated by a
committee member pushing a particular agenda with no consideration
about his own conflict of interest, a technical solution that would
have avoided mediation by the committee was in progress, no
substantive thought or discussion occurred, and finally rubber
stamping without any forethought to potential consequence (except from
Steve).

Yes, the Debian constitution right now allows the TC to misbehave like
that.  That is part of the constitutional crisis at hand.

The TC power needs to be reigned in.  Their actions should be limited
solely to disagreement mediation, and only when that doesn't involve a
conflict of interest pertaining to one of the TC members, and only
when all other attempts at reconciliation have tried and failed.

Best wishes,
Mike


-- 
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/CANTw=MMpLLnnekz8c2w35sc=rzudvvg+9ytxvt_qni797is...@mail.gmail.com

Re: Please more fish (was: so long and thanks for all the fish)

[Adam Borowski]

On Sun, Nov 09, 2014 at 12:54:39PM -0500, Michael Gilbert wrote:
> On Sun, Nov 9, 2014 at 10:10 AM, Ralf Jung wrote:
> > I read Joey's message over and over without getting any more clues. He
> > said the CTTE has "Decided it should make a decision", which it seems to
> > me it did not. So I probably misunderstood something more fundamental here.
> 
> Read all of #762194 very carefully.  Note that no technical
> disagreement existed between project members, it was initiated by a
> committee member pushing a particular agenda with no consideration
> about his own conflict of interest

I don't understand why a member of TC should be disallowed to raise issues
for the TC to discuss.  Do you say that if, formally, the submitter would be
any other of numerous people who see problems in replacing working inits by
systemd, it would be perfectly ok, but if Ian did this this is no longer
allowed?

I see a choir of voices shaming Ian for "abusing the constitution".  Yet it
turns out it's you who's picking on a formality rather than the problem at
hand.

And the issue in #762194 is distinct than #727708 and the GR:
#727708: what should be the default init system?
#762194: should existing installations be changed?
GR: can packages be tied to an init system?

None of the above gives an answer to the other two.
Thus, the issue Ian raised is valid.  And since changing the init system on
existing installations is an important _technical_ problem, it is in scope
for the CTTE.

Bottom line: Ian did nothing wrong.

-- 
// 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/20141109181953.ga22...@angband.pl

Re: Please more fish (was: so long and thanks for all the fish)

[Adam D. Barratt]

On 2014-11-09 18:19, Adam Borowski wrote:

And since changing the init system on
existing installations is an important _technical_ problem, it is in 
scope

for the CTTE.


Where does the constitution make "important technical problems" in scope 
for the tech committee? (Not being awkward, but there's a reason that 
they're explicitly chartered to make decisions _as a point of last 
resort_.)


Regards,

Adam


--
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/2ec0e5d4aa41bd836ea2d3d82db8b...@mail.adsl.funky-badger.org

Re: Please more fish (was: so long and thanks for all the fish)

[Simon Richter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On 09.11.2014 04:57, Christoph Anton Mitterer wrote:

> In the end it's quite easy: sysvinit has many deficiencies ans
> missing feature, systemd is superior in all places.

- From your perspective.

I can completely understand why we (and that includes me) want systemd
as a default: it gives the best possible integration of desktop
components possible.

However, there are use cases where systemd does not work because of
software design choices that, again, are in the best interest of its
users.

This is a common pattern in software development. When designing a
complex system, you have two extremes:

1. A system that covers all use cases by building a minimal framework
and letting users fill in the rest via a scripting language.

2. An elaborate system that simplifies use for the majority of cases,
uses a descriptive language for configuration, and falls flat for any
case that is out of scope.

Neither approach is inherently "better" than the other, but they can
be better suited for particular applications, and the choice which to
use is up to the user.

The vast majority of software in the world can be compiled by invoking
a compiler on all source files, and passing the compiler output to a
linker. With that knowledge, we can create a simple build system that
needs nothing but the name of the project, whether it is a program or
a library and a list of dependencies.

- From the point of view of an application developer, this is the best
thing since sliced bread. Comparing

- ---
SOURCES = foo.c bar.c
OBJECTS = $(SOURCES:.c=.o)
DEPENDS = $(SOURCES:.c=.d)

PREFIX = /usr/local

foo: $(OBJECTS)
$(CC) -o $@ $^

%.o: %.c
$(CC) -MD -MF $*.d -c $<

%.d:
touch $@

clean:
$(RM) foo *.o *.d

install: foo
$(INSTALL) -d $(DESTDIR)$(PREFIX)/bin
$(INSTALL) foo $(DESTDIR)$(PREFIX)/bin/

- -include $(DEPENDS)
- ---

with the much shorter

- ---
bin_PROGRAMS = foo
foo_SOURCES = foo.c bar.c
- ---

I think it is immediately clear which one is preferable. However, I
doubt you'd get far trying to move the Linux kernel to automake, as it
has additional requirements that cannot be represented in this way,
and extending automake to handle these is a herculean task.

> The only thing *I* regret is that it's not really used to it's
> full potential - i.e. in some places it rather seem we just try to
> rebuild sysvinit in systemd, restricting ourselfs.

The systemd architecture is, in my opinion, similar to automake.

There is a descriptive language with lots of keywords, which allows
you to do a lot of cool stuff easily, and at the same time, it is
possible to leave the framework behind for missing functionality, with
the same results for complexity and potential for error.

The blog post[1] by joeyh about his alarm clock illustrates this,
however you can already see that the framework is at its limits here,
as it is necessary to run the job with root permissions so it can use
an external tool to call back into the framework and inhibit lid
switch handling while the job is running.

At this point, I have to start asking questions:

1. What does "inhibit" mean? Will it ignore the events or just delay
processing?

2. Is this behavior guaranteed, or is that an implementation detail?

3. Does this have security implications, like a lid switch event not
being delivered to the screensaver?

4. Does this mean that other jobs will not start if they depend on the
lid switch being open, when the lid was opened while the alarm clock
was playing?

5. Is there a mechanism to be exempted from inhibit states?

6. If the events are queued, will similar events be coalesced, and
will obsolete events be dropped?

7. Why "inhibit handling the lid switch"? Wouldn't it be better to
have a mechanism to effect what we really want to do, stopping the
system from going to sleep, rather than assuming that the reason the
system would want to go back to sleep is the closed lid switch?

The alarm clock example already escalated into a round of Cambridge
Standard Five Cards Mao, with the condition of a rule being fulfilled
leading to a temporary change of the rules. Managing this at a system
level is a pure nightmare, especially when third party packages and
local policies come into the mix as well.

Restricting ourselves to a conservative default policy without any
assumptions thus sounds sensible to me. One such assumption is whether
we're running on a server, desktop or laptop system, which basically
limits us to starting programs on conditions because we cannot really
define a one-size-fits-all power policy.

   Simon

[1]
https://joeyh.name/blog/entry/a_programmable_alarm_clock_using_systemd/

Re: Please more fish (was: so long and thanks for all the fish)

[Игорь Пашев]

2014-11-10 0:38 GMT+03:00 Simon Richter :
> automake

With autotools one can always use plain shell code in configure.ac and
plain make in Makefile.am ;-)


-- 
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/call-q8zejcqrokhyk0gxsczk+p6oz7ft8ro3jlawlkucmle...@mail.gmail.com

Re: Please more fish (was: so long and thanks for all the fish)

[Joey Hess]

Michael Gilbert wrote:
> How can you possibly think no more need said?  You are one of four
> complicit in the act that finally pushed Joey over the edge [0].
> 
> [0] https://lists.debian.org/debian-ctte/2014/11/msg00045.html

Please take that message with a pound of salt. I was upset when I wrote
it, it's probably not accurate, and I've left[1] for reasons that are
much more broadly structural, and are certianly not the fault of the
technical committee, or indeed of any one person.

-- 
see shy jo

[1] Almost. Still need to orphan git-annex, git-repair, and github-backup.
 #768516: (O: etckeeper -- store /etc in git, mercurial, bzr or darcs)
 #768518: (O: mpdtoys -- small command line tools and toys for MPD)
 #768520: (O: liblingua-en-words2nums-perl - convert English text to numbers)
 #768525: (O: jetring)
 #768527: (O: pdmenu -- simple console menu program)
 #768528: (O: ticker)
 #768529: (O: moreutils -- additional Unix utilities)
 #768530: (O: filters)


signature.asc
Description: Digital signature

Re: Please more fish (was: so long and thanks for all the fish)

[Christoph Anton Mitterer]

On Sun, 2014-11-09 at 18:12 -0400, Joey Hess wrote: 
> I've left[1]

+

>Almost.

So you still could (and perhaps should[0]) reconsider not to leave
Debian.
Guess you've read the lists and saw how many people were emotionally hit
and upset about this.

(well I think it's worth a try ^^)

Cheers,
Chris.


[0] Even though I don't believe you just randomly decided to leave in
the first place.


smime.p7s
Description: S/MIME cryptographic signature

Re: Please more fish (was: so long and thanks for all the fish)

[Christoph Anton Mitterer]

On Sun, 2014-11-09 at 22:38 +0100, Simon Richter wrote: 
> I can completely understand why we (and that includes me) want systemd
> as a default: it gives the best possible integration of desktop
> components possible.
I even think it's best on a server (that means, if it was used as it
could be)...

With sysvinit it was basically not possible to make any guarantees, e.g.
like start XYZ only when firewall rules were successfully loaded, at
least not in a systematic fashion.
Or things like: When iptables rules are reloaded, stop fail2ban before,
restart it afterwards.

Unforunately, even if systemd would support such nice things, nothing of
this is deployed to the masses,... which is also why I wrote, that it
sometimes feels as if we'd only try to map sysvinit into systemd.


> However, there are use cases where systemd does not work because of
> software design choices that, again, are in the best interest of its
> users.
Well I guess that goes back into the init-system discussion ^^

That being said, I personally would welcome, if it was policy that it's
not allowed to require a specific init-system (unless specifically
related software).

> This is a common pattern in software development. When designing a
> complex system, you have two extremes:
> 
> 1. A system that covers all use cases by building a minimal framework
> and letting users fill in the rest via a scripting language.
... which, especially in the complex cases, often lead to just more
problems...

I mean it's of course nice to be able to edit the init-scripts, add
debug output, or adapt something to one's own very personal need.
But often this also just means that either one isn't doing things right
in the first place OR that the init script wasn't generically
configurable enough.



> 2. An elaborate system that simplifies use for the majority of cases,
> uses a descriptive language for configuration, and falls flat for any
> case that is out of scope.
> 
> Neither approach is inherently "better" than the other, but they can
> be better suited for particular applications, and the choice which to
> use is up to the user.
Which is why I'm definitely in favour of init-system diversity.


> I think it is immediately clear which one is preferable. However, I
> doubt you'd get far trying to move the Linux kernel to automake, as it
> has additional requirements that cannot be represented in this way,
> and extending automake to handle these is a herculean task.
Well I for the matter always hated autotools... (perhaps one should
lobby Linus for CMake? ;) )...

I think: an init-system shouldn't be programming,... one could always
see that this basic idea is somehow broken, when programs (shell
scripts) need to go to /etc,... and when people realised that this
causes only troubles, they've started trying to make them generic enough
to handle all cases and configurable via /etc/default/*


> The systemd architecture is, in my opinion, similar to automake.
Well, in a way, surely... but then one need to question: Should an init
system be a universal programming language or should it be a
systematised framework to boot the system, start software and perhaps
manage all this after boot.

And *I* don't think it should be a universal programming language.
In most cases where I've ever needed to manipulate init-scripts and
doing "advanced" things, like not only starting one apache http but
several, running as different user and that like (which is IIRC nowadays
even supported by the init script, at least partially), one could also
simply say, that the original init script was simply not powerful enough
and should have been implemented better in the first place, to avoid any
need to manipulate it.

And speaking of things like autotools,... I'd also say that the world
has mostly just benefit from systematising build procedures.


> Restricting ourselves to a conservative default policy without any
> assumptions thus sounds sensible to me. One such assumption is whether
> we're running on a server, desktop or laptop system, which basically
> limits us to starting programs on conditions because we cannot really
> define a one-size-fits-all power policy.
Uhm, I absolutely agree with that,... but I don' think it's a problem of
systemd per se - it's rather a problem of how it's used/configured.

Unfortunately the general direction seems to be to assume a single user
PC or even tablet,... which is why we have default settings like: mount
a USB stick if plugged in, or what I recently found in
virt-manager/libvirt/spice,... forward any usb stick plugged in
automatically to guest VMs.

But these problems aren't inherent to systemd or polkit,... it's rather
bad default decisions being made by people who have only their won usage
scenario in mind.

This is one of the main reasons why I got more and more of a gnome and
utopia-stuff critic.


I also think it's potentially dangerous when systemd upstrem tries to
"revolutionise" more and more things, which go far beyond any 

Re: Please more fish (was: so long and thanks for all the fish)

[Anthony Towns]

Hey Joey,

On Sun, Nov 09, 2014 at 06:12:13PM -0400, Joey Hess wrote:
> Please take that message with a pound of salt. I was upset when I wrote
> it, it's probably not accurate, and I've left[1] for reasons that are
> much more broadly structural, and are certianly not the fault of the
> technical committee, or indeed of any one person.

I wonder if you could describe what you think made Debian of '96
awesome? I miss reading inspiring manifestos of how things are meant to
work in a hypothetical perfect world that makes everyone happy.

(For me, I'd say what was cool about Debian back in that day was it
was "an anarchic collaboration that's doing cool, useful things with
software". When I think about it, I usually conclude that Debian still
wins because everything else interesting seems way more structured
(ie, either corporate or benevolent dictator), but maybe if I like
"anarchic" then the collaboration should be more ad-hoc anyway, and
existing structures aren't relevant...)

> [1] Almost. Still need to orphan git-annex, git-repair, and github-backup.
>  #768516: (O: etckeeper -- store /etc in git, mercurial, bzr or darcs)

Planning on staying involved with those as upstream?

FWIW, you might want to consider retaining your DDship despite orphaning
everything, dropping any roles, unsubscribing from any mailing lists,
seceding from the constitution, etc. There's not much obligation in
keeping the account, and if you find yourself using some package that
needs a bug fix, being able to do an NMU is handy (presuming you're not
switching to a different distro, anyway). At least, I haven't had anyone
begrudge me keeping my account while not doing anything much.

(Also, can we contact your ego or superego directly via email too?)

Cheers,
aj


-- 
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/20141110140124.ga9...@master.debian.org

Re: Please more fish (was: so long and thanks for all the fish)

[Amaya]

Christoph Anton Mitterer wrote:
> So you still could (and perhaps should[0]) reconsider not to leave
> Debian.
> Guess you've read the lists and saw how many people were emotionally
> hit and upset about this.

Joey, I beg you too. Please reconsider.
Still, if it's not fun anymore by all means run away as fast as you can,
but if this still can be fixed, let's try to.

I've told you privately how we met, maybe I didn't tell you how much it
meant to me (in a Debian inspiration way), so doing publicly so now.
It's just awful to see you go like this.

-- 
 .''`.The world breaks everyone, and afterward, some are
: :' :strong at the broken places.- Ernest Hemingway
`. `'   
  `-Proudly running Debian GNU/Linux


-- 
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/20141110153122.GK21507@aenima