Discussion:
Being part of a community and behaving
Bálint Réczey
2014-11-13 10:02:53 UTC
Permalink
Dear Josselin,

I have just noticed your blog post on planet.debian.org:
https://np237.livejournal.com/34598.html

I would like to ask you to resist the temptation of publishing similar posts.
It makes fun of part of our community which you are well aware of and
it also shows corpses which probably did not ring a bell in you.

None of those show good taste and by having it aggregated on
planet.debian.org it shows the whole project in bad light, too.

Thanks in advance,
Balint
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/CAK0OdpxmKyqxinUC+L+***@mail.gmail.com
Norbert Preining
2014-11-13 12:23:31 UTC
Permalink
Post by Bálint Réczey
https://np237.livejournal.com/34598.html
You lack any sense of humor, really!

Although I am a strong opponent of systemd, I had to laugh out loud
on that one, actually love it.

Sad to see people like you that are complete bare of any
acceptance for ironic, sarcastic humor.

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-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@auth.logic.tuwien.ac.at
Bálint Réczey
2014-11-13 12:58:23 UTC
Permalink
Hi Norbert,
Post by Norbert Preining
Post by Bálint Réczey
https://np237.livejournal.com/34598.html
You lack any sense of humor, really!
I clearly sensed the humor as I wrote in the part you cut.
Post by Norbert Preining
Although I am a strong opponent of systemd, I had to laugh out loud
on that one, actually love it.
Sad to see people like you that are complete bare of any
acceptance for ironic, sarcastic humor.
I love irony and sarcasm, but I don't think planet.debian.org is the
right place for the mentioned content.
9gag for sure.

Cheers,
Balint
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/CAK0OdpxUtKLt-K6E_YOBZkwNGQPHClN=qZhhyM19rqOv+***@mail.gmail.com
Jonathan Dowland
2014-11-13 20:09:27 UTC
Permalink
Post by Bálint Réczey
Post by Norbert Preining
acceptance for ironic, sarcastic humor.
I love irony and sarcasm, but I don't think planet.debian.org is the
right place for the mentioned content.
I'm afraid you misunderstand the purpose of planet Debian.
If you want an aggregator with more rules about content,
please set one up.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@chew.redmars.org
Florian Lohoff
2014-11-13 13:19:41 UTC
Permalink
Post by Norbert Preining
Post by Bálint Réczey
https://np237.livejournal.com/34598.html
You lack any sense of humor, really!
Although I am a strong opponent of systemd, I had to laugh out loud
on that one, actually love it.
Sad to see people like you that are complete bare of any
acceptance for ironic, sarcastic humor.
There are 2 parts of it. Its fun - but you can read between the lines.

I meanwhile see the systemd issue as a social problem within debian. There are
design issues which are REALLY controversial. In the past Debian did good by
delaying adoption of controversial technical issues e.g. devfs and waited in a
conservative way until dust settled and there was roughly a consensus.
Sometimes this lead to better approaches to see the light e.g. udev.

This has changed - Debian has changed.

It seems we need to rush in all interesting stuff without looking forward past
some months - Today systemd might be THE solution to some peoples problems. Is it
tomorrow? I doubt it.

Flo
--
Florian Lohoff ***@zz.de
Riku Voipio
2014-11-13 13:34:32 UTC
Permalink
Post by Florian Lohoff
I meanwhile see the systemd issue as a social problem within debian. There are
design issues which are REALLY controversial. In the past Debian did good by
delaying adoption of controversial technical issues e.g. devfs and waited in a
conservative way until dust settled and there was roughly a consensus.
Sometimes this lead to better approaches to see the light e.g. udev.
This has changed - Debian has changed.
It seems we need to rush in all interesting stuff without looking forward past
some months - Today systemd might be THE solution to some peoples problems. Is it
tomorrow? I doubt it.
Uhm, systemd was uploaded to debian first in 2010. Are you saying 4 years is
too much of a rush? What would be your view of a reasonable schedule?

Riku
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@afflict.kos.to
Florian Lohoff
2014-11-13 15:44:05 UTC
Permalink
Post by Riku Voipio
Post by Florian Lohoff
I meanwhile see the systemd issue as a social problem within debian. There are
design issues which are REALLY controversial. In the past Debian did good by
delaying adoption of controversial technical issues e.g. devfs and waited in a
conservative way until dust settled and there was roughly a consensus.
Sometimes this lead to better approaches to see the light e.g. udev.
This has changed - Debian has changed.
It seems we need to rush in all interesting stuff without looking forward past
some months - Today systemd might be THE solution to some peoples problems. Is it
tomorrow? I doubt it.
Uhm, systemd was uploaded to debian first in 2010. Are you saying 4 years is
too much of a rush? What would be your view of a reasonable schedule?
Released to our users in mid 2013 without most of the controversal bloat
we are talking about now.

Installation with either

You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!' ?]

or with

systemd can be installed alongside sysvinit and will not change the
behaviour of the system out of the box. This is intentional. To test
systemd, add:

init=/bin/systemd

How many users actually did this?

https://qa.debian.org/popcon-graph.php?packages=systemd

before 2014 and the begin of the debate - less than 1000

Less than 1000 while sysvinit beeing at 170k is 0.5%.

Compare that to the exim4 vs. postfix debate - We have postfix at 30K
constantly growing since 2007 and exim4 at 120K - thats 25% - And still we dont
switch to postfix by default.

I dont get it.

Flo
--
Florian Lohoff ***@zz.de
Hans
2014-11-13 17:05:40 UTC
Permalink
Post by Florian Lohoff
How many users actually did this?
I did! And aster not getting in serious trouble with it, I completely changed
to it.
Post by Florian Lohoff
https://qa.debian.org/popcon-graph.php?packag aes=systemd
before 2014 and the begin of the debate - less than 1000
Less than 1000 while sysvinit beeing at 170k is 0.5%.
Compare that to the exim4 vs. postfix debate - We have postfix at 30K
constantly growing since 2007 and exim4 at 120K - thats 25% - And still we
dont switch to postfix by default.
Yes, and this is the real freedom: choose whaterver software you want and take
all by default installed sopftware as a suggestion.

Populary-contest might change it from release to release, but you can use any
software you personally prefer. How cool is that?
Post by Florian Lohoff
I dont get it.
Me, too. Sigh.........
Post by Florian Lohoff
Flo
Hans
Olav Vitters
2014-11-13 13:36:30 UTC
Permalink
Post by Florian Lohoff
I meanwhile see the systemd issue as a social problem within debian. There are
design issues which are REALLY controversial. In the past Debian did good by
delaying adoption of controversial technical issues e.g. devfs and waited in a
conservative way until dust settled and there was roughly a consensus.
It has been around for multiple years across various distributions. I
don't think "waiting" is what you want? It is not by waiting things
automatically improve? At least the -devel and -vote discussions seem
low signal to noise. The more interesting stuff seems to happen in
bugreports and separate discussions.
Post by Florian Lohoff
Sometimes this lead to better approaches to see the light e.g. udev.
It seems we need to rush in all interesting stuff without looking forward past
some months - Today systemd might be THE solution to some peoples problems. Is it
tomorrow? I doubt it.
It has been talked about for at least 12 months or so, no?

Mostly curious about your view on above.
--
Regards,
Olav
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@bkor.dhs.org
Russ Allbery
2014-11-13 16:25:57 UTC
Permalink
Post by Florian Lohoff
I meanwhile see the systemd issue as a social problem within
debian. There are design issues which are REALLY controversial. In the
past Debian did good by delaying adoption of controversial technical
issues e.g. devfs and waited in a conservative way until dust settled
and there was roughly a consensus.
We waited two years, during which positions hardened, people got angrier
and angrier, and there were increasing demands to force the issue.
Serious question: how much longer were we realistically going to wait with
zero sign of forward progress?

What do you think we should have done instead? debian-devel was becoming
the standing debian-canonical-is-evil vs. debian-systemd-sucks standing
flamewar. (I think people are already forgetting the whole Canonical is
evil flamewar that was happening at the same time, with the same degree of
vitriol that is now being levelled at systemd.) Tons of influential,
respected project members were requesting that the TC make some sort of
decision. There was widespread relief at the time that we were just going
to pick something and be done with it.

That didn't happen, obviously. But don't lose sight of the fact that we
were already in a really bad place.
Post by Florian Lohoff
This has changed - Debian has changed.
It seems we need to rush in all interesting stuff without looking
forward past some months - Today systemd might be THE solution to some
peoples problems. Is it tomorrow? I doubt it.
If you think waiting two years to make a decision is rushing matters, I'm
not sure what your idea of moving slowly is.

I think people have an idealistic notion here that consensus will always
emerge eventually, and it's easy at this point in the process to
sugar-coat the past and forget how bad it was. Please, make a concerted
effort to put yourself into the mindset the project was in during the fall
of 2013. It's always easy to see, in hindsight, the cost of the option
that was taken; it's harder to see the cost of the option that was not
taken.

Personally, I strongly suspect that we could have waited until 2020 and
there still wouldn't be any consensus. And that has its own risk.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@hope.eyrie.org
Svante Signell
2014-11-13 16:55:59 UTC
Permalink
Post by Russ Allbery
Post by Florian Lohoff
I meanwhile see the systemd issue as a social problem within
debian. There are design issues which are REALLY controversial. In the
past Debian did good by delaying adoption of controversial technical
issues e.g. devfs and waited in a conservative way until dust settled
and there was roughly a consensus.
We waited two years, during which positions hardened, people got angrier
and angrier, and there were increasing demands to force the issue.
Serious question: how much longer were we realistically going to wait with
zero sign of forward progress?
The Canonical license arguments was maybe the tipping weight that pushed
Debian towards systemd, right.
Post by Russ Allbery
That didn't happen, obviously. But don't lose sight of the fact that we
were already in a really bad place.
Post by Florian Lohoff
This has changed - Debian has changed.
It seems we need to rush in all interesting stuff without looking
forward past some months - Today systemd might be THE solution to some
peoples problems. Is it tomorrow? I doubt it.
If you think waiting two years to make a decision is rushing matters,
I'm not sure what your idea of moving slowly is.
Isn't it so that systemd has changed a lot since the decision was made
in February this year, and the rate of changes will not stop. In the
meanwhile no stable API is defined and more and more functionality is
integrated in the systemd software, effectively shutting off
alternatives. When CoreOS is fully developed, there will a diminishing
market for other distributions.

Let's hope that Debian at least don't completely rules out (abandons)
alternate init systems. When things are seen in a perspective, a few
years from now, this might have saved Debian from disappearing (and even
obtain new desktop and server users coming from the
not-happy-with-systemd people).
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@G3620.my.own.domain
Ralf Jung
2014-11-13 17:58:30 UTC
Permalink
Hi,
Post by Svante Signell
Isn't it so that systemd has changed a lot since the decision was made
in February this year, and the rate of changes will not stop. In the
meanwhile no stable API is defined
<http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/>
Post by Svante Signell
and more and more functionality is
integrated in the systemd software, effectively shutting off
alternatives.
How does having yet another NTP client shut off existing NTP clients?
How does having yet another way to configure your network shut off
existing alternatives? Even syslog is still working! And so are cron and
lxc.
Post by Svante Signell
When CoreOS is fully developed, there will a diminishing
market for other distributions.
You seem to think that CoreOS will be so great that all users rush to
change there. That Debian would be unable to compete. I do not know what
you base this belief on, but I certainly think that Debian will continue
to stay relevant when yet another distribution emerges.

Kind regards
Ralf
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@ralfj.de
Thorsten Glaser
2014-11-14 11:43:20 UTC
Permalink
Post by Ralf Jung
How does having yet another NTP client shut off existing NTP clients?
https://github.com/systemd/systemd/commit/7b8b9686e050a2b19ed2a3686af187dff=
aab5c08

This is like MSDNAA: give away stuff for free (support xntpd=C2=B9)
to get people used to the drug (systemd), then remove their
ability to use anything else later.

=E2=91=A0 And nobody cares about OpenNTPD=E2=80=A6

bye,
//mirabilos
--=20
=C2=ABMyISAM tables -will- get corrupted eventually. This is a fact of life=
=2E =C2=BB
=E2=80=9Cmysql is about as much database as ms access=E2=80=9D =E2=80=93 =
=E2=80=9CMSSQL at least descends
from a database=E2=80=9D =E2=80=9Cit's a rebranded SyBase=E2=80=9D =E2=80=
=9CMySQL however was born from a
flatfile and went downhill from there=E2=80=9D =E2=80=93 =E2=80=9Cat least =
jetDB doesn=E2=80=99t claim to
be a database=E2=80=9D=09=E2=80=A3=E2=80=A3=E2=80=A3 Please, http://deb.li/=
mysql and MariaDB, finally die!
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@tglase.lan.tarent.de
Ralf Jung
2014-11-14 15:32:50 UTC
Permalink
Hi,
Post by Ralf Jung
How does having yet another NTP client shut off existing NTP clients?
https://github.com/systemd/systemd/commit/7b8b9686e050a2b19ed2a3686af187dffaab5c08
What do you think this commit does/announces? This is about removing
support from timedatectl to control other NTP clients. If you never used
"timedatectl set-ntp", this doesn't affect you at all.
This is not about removing support from systemd to start other NTP
services. "apt-get install ntpd" will continue to function to matter
what. Neither is it removing support for alternative implementations of
the timedated interface doing whatever they want.
There's obviously a con to such a change, but there's also a clear pro
from the maintenance perspective: less combinations to test.

So I stand by my question: How does adding yet another NTP client, (and
an implementation of a simple dbus interface that's tied to this
client), shut off existing NTP clients?

You may loose some of the desktop integration, but from your reaction to
the integration systemd is providing, that doesn't seem like it disturbs
you. And even that is only true until someone goes ahead and
re-implements the timedated interface.

Really, if all the energy that people put into complaining about systemd
and looking for proves to back their complaints (many of which are
certainly valid!) would be put into providing alternative
implementations of these interfaces that many desktop environments say
are really useful to them, the discussion could long be over. Nobody is
saying that implementing the logind interface is easy, but it's
certainly more sustainable than implementing the systemd-internal
interfaces systemd-logind is using, and running logind on top of that
(which, as far as I know [1], systemd-shim does). I've yet to see a
technical complaint about the *interfaces*, and that's really all Gnome
(and others) depend on.

[1]
<http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/debian-systemd-packaging-hoo-hah.html>

Kind regards
Ralf
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@ralfj.de
Thorsten Glaser
2014-11-14 15:46:31 UTC
Permalink
Post by Ralf Jung
Really, if all the energy that people put into complaining about systemd
and looking for proves to back their complaints (many of which are
certainly valid!) would be put into providing alternative
implementations of these interfaces that many desktop environments say
I *have* alternative implementations in the environment
on my Debian desktop:

=E2=80=A2 X (well, XFree86 in MirBSD=E2=80=A6)
=E2=80=A2 evilwm (laptop) / icewm (desktop)
=E2=80=A2 uxterm
=E2=80=A2 screen
=E2=80=A2 mksh
=E2=80=A2 jupp
=E2=80=A2 alpine
=E2=80=A2 openntpd
=E2=80=A2 inetutils-syslogd (currently)

So, no need for anything systemd-ish.

bye,
//mirabilos
--=20
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.=09-- Rob Pike in "Notes on Programming in C"
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@tglase.lan.tarent.de
Ralf Jung
2014-11-14 17:01:42 UTC
Permalink
Hi,
Post by Thorsten Glaser
Post by Ralf Jung
Really, if all the energy that people put into complaining about systemd
and looking for proves to back their complaints (many of which are
certainly valid!) would be put into providing alternative
implementations of these interfaces that many desktop environments say
I *have* alternative implementations in the environment
• X (well, XFree86 in MirBSD…)
• evilwm (laptop) / icewm (desktop)
• uxterm
• screen
• mksh
• jupp
• alpine
• openntpd
• inetutils-syslogd (currently)
I was specifically talking about interfaces (as in, dbus signatures),
not features. That would deal with the GNOME dependencies, which your
alternatives do not.
Post by Thorsten Glaser
So, no need for anything systemd-ish.
Well, even better for you :) . Then you are even less affected by what
the git commit you referenced announces, than I am.

Kind regards
Ralf
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@ralfj.de
Thorsten Glaser
2014-11-17 16:39:16 UTC
Permalink
Post by Ralf Jung
I was specifically talking about interfaces (as in, dbus signatures),
Meh=E2=80=A6 I don=E2=80=99t even have dbus installed at home. (It is, on t=
he work
system, due to=E2=80=A6 virt-manager and iceweasel(?).)
Post by Ralf Jung
Post by Thorsten Glaser
So, no need for anything systemd-ish.
=20
Well, even better for you :) . Then you are even less affected by what
the git commit you referenced announces, than I am.
Right. I just see a direction. After some years, you tend to
recognise certain =E2=80=9Chypes=E2=80=9D and trends=E2=80=A6

bye,
//mirabilos
--=20
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.=09-- Rob Pike in "Notes on Programming in C"
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@tglase.lan.tarent.de
Raphaël Halimi
2014-11-15 12:37:07 UTC
Permalink
Post by Ralf Jung
How does having yet another NTP client shut off existing NTP clients?
How does having yet another way to configure your network shut off
existing alternatives?
How does having yet another web browser integrated in the OS shut off
existing web browsers ? ;)
Post by Ralf Jung
Even syslog is still working!
No, it's not:

***@arche:~$ journalctl | grep Forwarding
nov. 10 20:14:34 arche systemd-journal[207]: Forwarding to syslog missed
42 messages.
nov. 14 01:02:44 arche systemd-journal[207]: Forwarding to syslog missed
1 messages.
nov. 14 01:25:31 arche systemd-journal[207]: Forwarding to syslog missed
2 messages.
nov. 14 01:26:36 arche systemd-journal[207]: Forwarding to syslog missed
2 messages.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762700

http://lists.freedesktop.org/archives/systemd-devel/2014-August/021897.html

I know it may be biased since I'm the reporter of the bug, but I'm tired
of reading that systemd replaces all those components smoothly.

It does not.

Now on the technical side, when I reported this bug I looked at the
source code. In a nutshell, the comment said "If syslog is too slow,
drop the message" (IIRC it was even more condescending, like "we don't
have to wait for this" or something). Really ? The very piece of code
which is supposed to talk to syslog... doesn't wait for syslog ?

So if one can't afford to have crippled logs, what's the solution ?
Getting rid of syslog completely by turning on persistence in journald,
and go with binary logs ? Thanks, but no thanks.

I think Florian really has a point: Debian has changed. I use Debian
since Slink and I can confidently say that there was a time when such
software would never have reached stable, let alone become the default.
In those days, we would have waited for the RHEL admins to do the
beta-testing in production environments (which excludes toys like Fedora
or Arch or whatever distro that "use systemd for several years now
without any hassle") before adopting this bloatware as the default init
system.
--
Raphaël Halimi
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@gmail.com
Dimitrios Chr. Ioannidis
2014-11-15 13:16:22 UTC
Permalink
On 15-11-2014 14:37, Raphaël Halimi wrote:
<snip>
Post by Raphaël Halimi
I think Florian really has a point: Debian has changed. I use Debian
since Slink and I can confidently say that there was a time when such
software would never have reached stable, let alone become the default.
In those days, we would have waited for the RHEL admins to do the
beta-testing in production environments (which excludes toys like Fedora
or Arch or whatever distro that "use systemd for several years now
without any hassle") before adopting this bloatware as the default init
system.
Those comments is exactly what I'm thinking for the last two weeks or
so.

Systemd project used distro's as a testbed and that will be fine if
debian
didn't join the "fun" but choosed to leave systemd in sid for as long as
it
proved to be stable enough and at the same time implemented a
alternative path to replace it.

Regards,
--
Dimitrios Chr. Ioannidis
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@nephelae.eu
Ralf Jung
2014-11-15 13:18:02 UTC
Permalink
Hi,
Post by Raphaël Halimi
Post by Ralf Jung
How does having yet another NTP client shut off existing NTP clients?
How does having yet another way to configure your network shut off
existing alternatives?
How does having yet another web browser integrated in the OS shut off
existing web browsers ? ;)
There's a difference between a browser popping into every kind of
launcher and starter and telling people it should be used; and something
like systemd-networkd that I wouldn't even know existed if I wouldn't
follow the news.
You have a point here. But I think that the case is different for
services that the average user hardly ever faces. People who do manual
network configuration beyond NetworkManager, are more than capable of
installing another suite for that if necessary (not that it looks like
/etc/network/interfaces will cease to function anytime soon). Everybody
else uses whatever Gnome/KDE/... provides and doesn't care how the magic
happens in the background.
Post by Raphaël Halimi
Post by Ralf Jung
Even syslog is still working!
[...]

Well, systemd has bugs, nobody doubts that. FWIW, I never saw this
happen on my machine.

Kind regards
Ralf
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@ralfj.de
Raphaël Halimi
2014-11-15 14:05:59 UTC
Permalink
Post by Ralf Jung
You have a point here. But I think that the case is different for
services that the average user hardly ever faces. People who do manual
network configuration beyond NetworkManager, are more than capable of
installing another suite for that if necessary (not that it looks like
/etc/network/interfaces will cease to function anytime soon). Everybody
else uses whatever Gnome/KDE/... provides and doesn't care how the magic
happens in the background.
That's precisely the point. If systemd is installed as default on every
jessie system, since it ships its own time syncing client, what's the
point of installing NTP (provided that the machine doesn't have to
provide time services to other hosts) ? That's exactly what a well-known
software company did to push its web browser by taking advantage of its
dominant position on the OS market. And that's what systemd is doing
with every component it intends to "offer" a replacement for.
Post by Ralf Jung
Post by Ralf Jung
Even syslog is still working!
[...]
Well, systemd has bugs, nobody doubts that. FWIW, I never saw this
happen on my machine.
If you already ditched syslog, it obviously won't happen... You wouldn't
be of such bad faith, would you ? ;)

Just kidding. More seriously, you avoided to comment on the real issues:
is it a good sign of code quality (for the whole project) if the piece
of code which is supposed to communicate with syslog doesn't even wait
for it to be ready ? And more importantly, is it the quality level that
Debian has accustomed us to ?

We're not talking of an optional Perl library that will be used in a 100
lines home-made script, but of the basic foundations that every
jessie(+x) systems will be built upon.

We're not talking of a small bug in a maintainer's script that can be
fixed in a an update during the freeze, but of a design choice in
upstream code that results in crippled logs for people who don't want
binary logs.

That's not like Debian (or at least the Debian we all know and love) to
adopt this kind of software as the default init system.
--
Raphaël Halimi
Ralf Jung
2014-11-15 14:40:28 UTC
Permalink
Hi,
Post by Raphaël Halimi
That's precisely the point. If systemd is installed as default on every
jessie system, since it ships its own time syncing client, what's the
point of installing NTP (provided that the machine doesn't have to
provide time services to other hosts) ? That's exactly what a well-known
software company did to push its web browser by taking advantage of its
dominant position on the OS market. And that's what systemd is doing
with every component it intends to "offer" a replacement for.
As I already mentioned, I think the issue is very different with a
browser vs. some low-level system component. Or would you say that the
fact that we force every user to use GNU libc is comparable?
What you say could also be read as a plea against any kind of
integration, as this integration naturally provides a "best" combination
of tools, and it will be harder to exchange some of them. I would argue
that this is a trade-off. Personally, I am happy to know that the
combination of tools that make up a part of the low-level system, has
been tested and designed in exactly this constellation - as opposed to
the giant exploding test matrix that results from supporting several
variants of each tool. I appreciate that others have other preferences,
and hence I think it is crucial that people can choose. Jessie is the
first Debian release that offers a choice of init systems.
Post by Raphaël Halimi
Post by Ralf Jung
[...]
Well, systemd has bugs, nobody doubts that. FWIW, I never saw this
happen on my machine.
If you already ditched syslog, it obviously won't happen... You wouldn't
be of such bad faith, would you ? ;)
Just to clarify, as you already suspected, I still have syslog
installed. ;-)
Post by Raphaël Halimi
is it a good sign of code quality (for the whole project) if the piece
of code which is supposed to communicate with syslog doesn't even wait
for it to be ready ? And more importantly, is it the quality level that
Debian has accustomed us to ?
I didn't read the code. Depending on where and how this happens, I can
understand that someone doesn't want to make a call that blocks
arbitrary long. So if you get a timeout, what else could you do?

I also find it hasty to judge systemd's code quality from a single
example. The analysis of Russ and several others suggest that actually,
systemd has a fairly high code quality. That's not something I can
comment on; but they do seem to be eager to get rid of old cruft (many
say, too eager), which certainly helps keeping your code clean.
Considering the age and complexity of the software, I am also impressed
how well it works. And finally, what I can comment on is the amount of
documentation, and that's outstanding. I assume there is some
correlation between well-organized, well-documented code and
well-written (user-facing) documentation.

Kind regards
Ralf
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@ralfj.de
Raphaël Halimi
2014-11-15 15:31:26 UTC
Permalink
Post by Ralf Jung
What you say could also be read as a plea against any kind of
integration, as this integration naturally provides a "best" combination
of tools, and it will be harder to exchange some of them. I would argue
that this is a trade-off. Personally, I am happy to know that the
combination of tools that make up a part of the low-level system, has
been tested and designed in exactly this constellation - as opposed to
the giant exploding test matrix that results from supporting several
variants of each tool.
I understand, and in fact, despite what I may sound like, I'm not
against this type of integration. On the only machine I have with
systemd installed (a sid desktop), I ditched ntp because, well, what's
the point of having two packages doing the same thing, if the one that's
already present does its job well ?

But the haste to integrate so many things in such a short amount of
time, the stubbornness (wontfix) that some upstream developers have
sometimes exhibited (not unlike Gnome upstream), or the piece of code I
saw (I'm not a developer, more a sysadmin, so I rarely dive into C code,
only for debugging purposes), all of this gives me a bad feeling about
systemd. And, did I mention that I *really* don't want binary logs ? :-P
Post by Ralf Jung
I didn't read the code. Depending on where and how this happens, I can
understand that someone doesn't want to make a call that blocks
arbitrary long. So if you get a timeout, what else could you do?
I don't know, like I said, I'm no developer. But the comment was clear
on the fact that the developer deliberately chose not to wait on the
syslog. For a piece of code which is supposed to feed the syslog, I find
that choice illogic, to say the least.
Post by Ralf Jung
I also find it hasty to judge systemd's code quality from a single
example. The analysis of Russ and several others suggest that actually,
systemd has a fairly high code quality. That's not something I can
comment on; but they do seem to be eager to get rid of old cruft (many
say, too eager), which certainly helps keeping your code clean.
Sorry, english isn't my native language so maybe I wasn't clear. I
didn't *judge* all of systemd's code to be of poor quality; but as for
the little piece I looked at, I have a bad hunch about it. And the
general "wontfix" attitude of the developers just add to that hunch.

But again, we pull away from my first point - as a sysadmin, what I can
see is that my systemd box has crippled text logs, and the point is
that's not worthy of the quality that we're all accustomed to, and which
made me choose Debian 15 years ago.

Regards,
--
Raphaël Halimi
Tollef Fog Heen
2014-11-15 15:53:00 UTC
Permalink
]] Raphaël Halimi
Post by Raphaël Halimi
Post by Ralf Jung
I didn't read the code. Depending on where and how this happens, I can
understand that someone doesn't want to make a call that blocks
arbitrary long. So if you get a timeout, what else could you do?
I don't know, like I said, I'm no developer. But the comment was clear
on the fact that the developer deliberately chose not to wait on the
syslog. For a piece of code which is supposed to feed the syslog, I find
that choice illogic, to say the least.
You have two choices: you can drop the oldest or the newest log entries
if syslog doesn't keep up. Apparently, you prefer to ditch the newest
ones, the code ditches the oldest ones.
Post by Raphaël Halimi
Post by Ralf Jung
I also find it hasty to judge systemd's code quality from a single
example. The analysis of Russ and several others suggest that actually,
systemd has a fairly high code quality. That's not something I can
comment on; but they do seem to be eager to get rid of old cruft (many
say, too eager), which certainly helps keeping your code clean.
Sorry, english isn't my native language so maybe I wasn't clear. I
didn't *judge* all of systemd's code to be of poor quality; but as for
the little piece I looked at, I have a bad hunch about it. And the
general "wontfix" attitude of the developers just add to that hunch.
Have you actually interacted with any systemd developers? Your
experience doesn't match mine at all.
Post by Raphaël Halimi
But again, we pull away from my first point - as a sysadmin, what I can
see is that my systemd box has crippled text logs, and the point is
that's not worthy of the quality that we're all accustomed to, and which
made me choose Debian 15 years ago.
How do you know that your old setup didn't lose logs too, but just
failed to record it?
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@xoog.err.no
Raphaël Halimi
2014-11-15 17:14:00 UTC
Permalink
Post by Tollef Fog Heen
You have two choices: you can drop the oldest or the newest log entries
if syslog doesn't keep up. Apparently, you prefer to ditch the newest
ones, the code ditches the oldest ones.
When did you read that I prefer to ditch any of them ?
Post by Tollef Fog Heen
Have you actually interacted with any systemd developers? Your
experience doesn't match mine at all.
No, but I read some bug reports, mailing lists, etc etc. And I saw a lot
of "wontfix", more than in other projects.
Post by Tollef Fog Heen
How do you know that your old setup didn't lose logs too, but just
failed to record it?
Of course I can't be sure, but the point isn't just the logging issue.
The point is that until now, systemd hasn't been tested in real huge
production environments. There are three big players in this segment:
RHEL, SLES, and Debian. RHEL7 was launched in June, SLES12 in October,
and only in the next months will we see what happens. Debian used to
wait carefully before integrating such new technologies at the heart of
the system. I don't consider that Fedora, OpenSuse or Arch are
enterprise-grade distros, so as far as I'm concerned, systemd is still a
new technology because the test in real production environments has
started only a few months ago with RHEL7, even if Fedora uses it since 2011.

Once again, to be clear: I may or may not like systemd, but my point is
not to tell if it's a good or bad choice for Debian; I'm just saying
that making it the default init system is too soon compared to the
conservative position that Debian has accustomed us to.
--
Raphaël Halimi
Svante Signell
2014-11-15 14:46:23 UTC
Permalink
Post by Raphaël Halimi
Post by Ralf Jung
How does having yet another NTP client shut off existing NTP clients?
How does having yet another way to configure your network shut off
existing alternatives?
How does having yet another web browser integrated in the OS shut off
existing web browsers ? ;)
Post by Ralf Jung
Even syslog is still working!
nov. 10 20:14:34 arche systemd-journal[207]: Forwarding to syslog missed
42 messages.
nov. 14 01:02:44 arche systemd-journal[207]: Forwarding to syslog missed
1 messages.
nov. 14 01:25:31 arche systemd-journal[207]: Forwarding to syslog missed
2 messages.
nov. 14 01:26:36 arche systemd-journal[207]: Forwarding to syslog missed
2 messages.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762700
http://lists.freedesktop.org/archives/systemd-devel/2014-August/021897.html
I know it may be biased since I'm the reporter of the bug, but I'm tired
of reading that systemd replaces all those components smoothly.
It does not.
Now on the technical side, when I reported this bug I looked at the
source code. In a nutshell, the comment said "If syslog is too slow,
drop the message" (IIRC it was even more condescending, like "we don't
have to wait for this" or something). Really ? The very piece of code
which is supposed to talk to syslog... doesn't wait for syslog ?
So if one can't afford to have crippled logs, what's the solution ?
Getting rid of syslog completely by turning on persistence in journald,
and go with binary logs ? Thanks, but no thanks.
One effect of having logs stored in binary format:
http://lists.freedesktop.org/archives/systemd-devel/2014-November/025203.html
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@gmail.com
Matthias Urlichs
2014-11-15 16:21:18 UTC
Permalink
Hi,
try this instead:

$ journalctl _SYSTEMD_UNIT=systemd-journald.service

which will (most likely) also show messages like "Suppressed 1927 messages
from /PATH/FOO.slice". You can then use

$ journalctl _SYSTEMD_SLICE=FOO.slice

to display the non-suppressed part of the spew that's responsible
for this overrun.
Post by Raphaël Halimi
nov. 10 20:14:34 arche systemd-journal[207]: Forwarding to syslog missed
42 messages.
Presumably, systemd is not capable of changing the speed of your syslog
daemon. So what would happen otherwise? If it's stdout/err logging, the
information would not have been logged at all (daemons redirect it to
/dev/null when backgrounding), or it'd have been tossed when sendmsg()
returns an error due to a full buffer. Or, if it's an intermittent problem
with syslog rather than message spew, the fact that you now have one pipe
to syslogd instead of N of them, each 4k big may be relevant.

Thus, the fix is
(a) increase the kernel buffer size of the pipe to syslog,
(b) increase the speed of your syslogd, (c) decrease that daemon's latency,
(d) teach whatever program logged so much to Not Do That, and/or
(e) decrease journald's RateLimitBurst= config variable so that
it doesn't overload your syslog. Oh yes,
(f) if your syslog still sync()s a log file after every message, tell it
to not Do That.

(a) should be a straightforward patch. (b) to (d) are not systemd's
problem. (e) defaults to 1000 in 30 seconds, which may be too much
for your syslog to keep up with.
Post by Raphaël Halimi
drop the message" (IIRC it was even more condescending, like "we don't
have to wait for this" or something). Really ? The very piece of code
which is supposed to talk to syslog... doesn't wait for syslog ?
Do you want to buffer an unbounded number of messages in RAM instead,
hoping that syslog will catch up eventually? Thanks, but no thanks.
(Implementing a _bounded_ message buffer in systemd doesn't make sense,
because you can get the exact same effect by simply doing (a), above.)
Post by Raphaël Halimi
So if one can't afford to have crippled logs, what's the solution ?
It's likely (though not certain) that your logs have been crippled in the
past, albeit in a different way, and you simply didn't notice because the
logging program didn't tell you. The standard syslog(3) code doesn't.
Post by Raphaël Halimi
Getting rid of syslog completely by turning on persistence in journald,
and go with binary logs ? Thanks, but no thanks.
Why not?

Seriously. I can do a whole lot more with this strange binary journal thing
than with a text file.

* All error messages from my web server setup, no matter which process
logged them?
One command.
* Get everything Joe User did last week (that resulted in a syslog entry)?
One command.
* Post-process some logs without writing fragile regexps which need to make
triple sure no random crap throws off your syslog parser?
Export the entries you need (and only these) as JSON.
* Want a logger that will NOT fill your whole disk with logs, no matter what?
No problem.
And you get all of this without sequentially scanning a couple of huge
syslog-written files with redundant data (just how many syslog files does a
WARN message from the kernel end up in?).

Yes, binary logs are somewhat less crash-proof. In theory. But in my
experience, a random crash which doesn't even sync() will also leave a big
fat spot of NULLs in the text log, so you don't have any useful information
about the crash in either case. And if it does sync successfully, well, the
text log will be OK, but so will be its binary counterpart.

Yes, this may sound fanboy-ish. But let me tell you, the simple fact is
that this evil buggy monolithic systemd stuff some people complain about
saves me a lot of time, not all of which I then spend on Debian mailing
lists fanboy-ing. :-P (I'm also somewhat too old to be called "boy". :-/ )

Besides, I'm not blind to the fact that not all is well in systemd land.
But that's a different topic.
--
-- Matthias Urlichs
Philip Hands
2014-11-15 21:51:29 UTC
Permalink
Post by Matthias Urlichs
Hi,
$ journalctl _SYSTEMD_UNIT=systemd-journald.service
which will (most likely) also show messages like "Suppressed 1927 messages
from /PATH/FOO.slice". You can then use
$ journalctl _SYSTEMD_SLICE=FOO.slice
to display the non-suppressed part of the spew that's responsible
for this overrun.
Post by Raphaël Halimi
nov. 10 20:14:34 arche systemd-journal[207]: Forwarding to syslog missed
42 messages.
Presumably, systemd is not capable of changing the speed of your syslog
daemon. So what would happen otherwise? If it's stdout/err logging, the
information would not have been logged at all (daemons redirect it to
/dev/null when backgrounding), or it'd have been tossed when sendmsg()
returns an error due to a full buffer. Or, if it's an intermittent problem
with syslog rather than message spew, the fact that you now have one pipe
to syslogd instead of N of them, each 4k big may be relevant.
Thus, the fix is
(a) increase the kernel buffer size of the pipe to syslog,
(b) increase the speed of your syslogd, (c) decrease that daemon's latency,
(d) teach whatever program logged so much to Not Do That, and/or
(e) decrease journald's RateLimitBurst= config variable so that
it doesn't overload your syslog. Oh yes,
(f) if your syslog still sync()s a log file after every message, tell it
to not Do That.
(a) should be a straightforward patch. (b) to (d) are not systemd's
problem. (e) defaults to 1000 in 30 seconds, which may be too much
for your syslog to keep up with.
How thoroughly refreshing to see some well reasoned sense talked about
systemd for a change.

I'm a total newbie to systemd. I've had it on my laptop for a few
weeks, and just installed it on an old laptop for a friend.

My brief exposure to journalctl (while diagnosing a hardware fault on
the second machine) pretty much instantly convinced me that it's a much
better way of doing things than having to rummage through a heap of text
files, some compressed, rotated on varying schedules etc, where you're
always left with the sneaking suspicion that the bit of data you need to
see is hiding in some other file that you've forgotten about, or has for
some reason simply never made it to a file.

If journald manages to do what it's designed to do then future Linux
sysadmins won't have to clog their brains up with this drivel. I look
forward to forgetting it, as I'm very happy to have forgotten the
contents of the sendmail book.

It's annoying to realise that we've all been putting up with this
slightly shoddy solution to the problem simply because it wasn't quite
painful enough to motivate anyone to fix it -- until now.

Of course, I've also come across things that I don't like about our
systemd setup, which may turn into a bug report once I have time to
confirm that I didn't simply screw up the install somehow -- of course
this subject has now become so sensitive on all sides that some people
will probably assume that I'm reporting such a bug because I hate
systemd, so I'll have to be really careful about the wording -- how
depressing this mess is.

Thanks again for providing a brief moment of sanity.

Let the chaos resume :-/

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
Don Armstrong
2014-11-17 01:34:36 UTC
Permalink
the systemd maintainers may have wanted to protect systemd users
tracking unstable from systemd-shim breakage.
This dependency change doesn't install systemd-shim if someone is
already using systemd-sysv. It only installs systemd-shim if someone has
already installed sysvinit-core instead of systemd-sysv.

[...]
If the bug hadn't been fixed and the release team tried removing
systemd-shim from jessie, I'd presume the tech ctte would've overruled
the RC-ness of the bug anyway.
Based on my current understanding of that bug, I would not have voted to
override the Release Team. Furthermore, considering that the maintainers
of systemd-shim did not alter the severity of that bug either, they
treated it as if it were RC as well.

I'm going to stop replying publicly to this thread;[1] if someone feels
strongly about this, and wants to further discuss the rationale, feel
free to discuss this on debian-***@lists.debian.org or similar.

1: Yes, I have my own RC bugs that I should be fixing instead of
complaining about motes elsewhere.
--
Don Armstrong http://www.donarmstrong.com

Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
the Ugly).
-- Matt Welsh
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@teltox.donarmstrong.com
The Wanderer
2014-11-16 22:34:58 UTC
Permalink
I would, for example, have classified the discussions / arguments
in the "systemd-sysv | systemd-shim" bug which appears to have
recently been resolved by TC decision as being an example of what I
thought was being referred to by the original "bitter rearguard
action" reference: fighting over the implementation details in an
attempt to maintain as much ground for non-systemd as possible.
I was really confused that this needed to go to the TC; from what I
could tell, it had no downside systems using systemd, and it made
things better on non-systemd systems. What was the downside of
making the change, and why did it have to go to the TC instead of
the maintainer simply accepting the patch?
My understanding (based on having read the early stages of the
two-or-three bugs on that subject) is that it has to do with the fact
that that there were at the time or recently had been bugs against
systemd-shim and/or its dependencies such that systemd-shim would
provide degraded functionality compared with systemd-sysv.

On that basis, I believe the maintainer's opinion was that it would
better serve the users to preferentially install the dependency which we
*know* will work (at least to a baseline), unless a request has been
made to do otherwise.

If that isn't correct, or if there was more to it than that, I'd be
interested to be corrected on that subject myself.
--
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
Bjørn Mork
2014-11-17 10:05:13 UTC
Permalink
This is what many still (retorically) wonder about: we the systemd
maintainers did not reject that change,
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;bug=746578
Please try to be less selective in your quoting: the issue was still
being discussed.
I see. So any systemd bug with a 'wontfix' tag is still considered open
for discussion? That's good to know. Thanks.


Bjørn
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@nemi.mork.no
Anthony Towns
2014-11-17 14:48:29 UTC
Permalink
Post by Bjørn Mork
This is what many still (retorically) wonder about: we the systemd
maintainers did not reject that change,
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;bug=746578
Please try to be less selective in your quoting: the issue was still
being discussed.
I see. So any systemd bug with a 'wontfix' tag is still considered open
for discussion? That's good to know. Thanks.
Isn't any (open) bug tagged wontfix still "open for discussion"? If you've
got new information, or a new approach that the maintainer might prefer,
you can post it to the bug and discuss it with the maintainer...

(That said, I didn't see any discussion in that bug from people listed
in the systemd Uploaders line other than Michael Biebl's complaint about
a systemd-shim bug two months after the wontfix tag was added. That
doesn't *look* like it was "still being discussed" to me. Maybe that
just means someone summarising irc/list discussions to the bug would
have been helpful)

Cheers,
aj
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@master.debian.org
Chris Bannister
2014-11-18 03:48:38 UTC
Permalink
Post by Anthony Towns
Post by Bjørn Mork
This is what many still (retorically) wonder about: we the systemd
maintainers did not reject that change,
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;bug=746578
Please try to be less selective in your quoting: the issue was still
being discussed.
I see. So any systemd bug with a 'wontfix' tag is still considered open
for discussion? That's good to know. Thanks.
Isn't any (open) bug tagged wontfix still "open for discussion"? If you've
got new information, or a new approach that the maintainer might prefer,
you can post it to the bug and discuss it with the maintainer...
It appears to be a misnomer then. I read 'wontfix' as "I'm not going to
to fix it as I don't see it as a bug."

Or am I confusing an open wontfix with a closed wontfix?
--
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the
oppressing." --- Malcolm X
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@tal
Ben Finney
2014-11-18 05:02:05 UTC
Permalink
[the ‘wontfix’ tag] appears to be a misnomer then. I read 'wontfix' as
"I'm not going to to fix it as I don't see it as a bug."
The official definition:

wontfix
This bug won't be fixed. Possibly because this is a choice between
two arbitrary ways of doing things and the maintainer and submitter
prefer different ways of doing things, possibly because changing the
behaviour will cause other, worse, problems for others, or possibly
for other reasons.

<URL:https://www.debian.org/Bugs/Developer#tags>

leaves open the question of whether the maintainer considers the
reported behaviour a bug. There is no necessary implication to that
effect.
--
\ “I got an answering machine for my phone. Now when someone |
`\ calls me up and I'm not home, they get a recording of a busy |
_o__) signal.” —Steven Wright |
Ben Finney
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@benfinney.id.au
Russ Allbery
2014-11-18 05:02:24 UTC
Permalink
Post by Chris Bannister
It appears to be a misnomer then. I read 'wontfix' as "I'm not going to
to fix it as I don't see it as a bug."
Or am I confusing an open wontfix with a closed wontfix?
Yeah, this is confusing as heck, and to make it worse, every Debian
maintainer has their own system. We don't have standardized detailed tag
meanings.

Personally (and this is also the pattern followed by Lintian and Policy
maintainers), I tag bugs wontfix but don't close them while I'm still open
to further discussion to change my mind. Then, I frequently forget to
remove the wontfix tag even after I've changed my mind. :/

Closed is another matter entirely -- that means I'm pretty sure the bug
report should just go away.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@hope.eyrie.org
Russ Allbery
2014-11-17 16:19:58 UTC
Permalink
Post by Bjørn Mork
I see. So any systemd bug with a 'wontfix' tag is still considered open
for discussion?
I can't speak to the maintenance practices of systemd maintainers, but if
the bug isn't open to discussion, I close it. I think that's fairly
common across Debian. If it's tagged wontfix but still open, that
generally means one of two things: either it's still open for discussion,
but the maintainers are indicating their current thinking on it, or it's
a commonly-reported false positive (from the maintainer's perspective) and
they're leaving it open so that people will see it in the bug list and see
that someone else already reported it.

In this particular case, it's going to be hard for someone who isn't
following the discussion closely to know which meaning was intended, so
probably better to read the thread or ask, rather than making an
assumption one way or the other.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@hope.eyrie.org
Philip Hands
2014-11-16 15:02:11 UTC
Permalink
The Wanderer <***@fastmail.fm> writes:
...
It is very tiresome that all this politicking seems likely to have
knock-on effects on our normal technical processes long after the
issues are settled.
Arguably, if the politicking is still going on, the issues are in some
important sense still not "settled"; even if/though they are in the
sense that a project decision has been made, that is not the only
possible or necessarily relevant sense of the word.
You miss my point.

The politicing will eventually end.

At that point the poor bastards that have been subjected to the game
playing will still be sensitive to the games for some time after that,
and may well end up seeing hidden agenda where none exist.

That's going to make it just a little harder to deal with bugs in that
area.

Add to that the fact that the current aggravation is already driving
people away from maintaining these packages, and from the project, and
From being as enthusiastic about other things in Debian, and you get a
significant chilling effect, which I'd suggest will continue for years.

People don't just put things on hold for a month or two. They find
something else to do, get enthusiastic about it, and don't come back.

I'm sure some of the vocal minority will be happy that less effort will
be available for working on the things that they hate. If so, they're
(unsurprisingly) being short-sighted. Removing effort from these areas
doesn't mean that they'll disapear in a puff of smoke -- it just means
that there will be less effort to spare for accomodating the special
requirements they've been screaming about.

I suppose that at least that means that there's a learning experience
available here -- not that I expect many to understand the lesson.

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
Ian Jackson
2014-11-17 17:12:04 UTC
Permalink
"Steve, as long as bugs like [1] are not fixed in systemd-shim, I'm not
going to make it the first alternative. Installing a half-broken logind
whould be a disservice to our users."
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746578#27
I'm sorry that the TC decision here has caused the social fallout that
it has. It's a shame that the init system many of our users are going
to be relying on will be lacking Tollef's excellent contributions.

But:

A criticism seems to be that the TC getting involved, or deciding, was
premature, because the systemd maintainers would have applied this
patch themselves if they had been asked nicely, or something ?

I think that after a refusal from the maintainers, with the bug tagged
wontfix, anyone is entitled to refer the matter to the TC. It has
often happened that someone has referred a bug to the TC and after
some discussion it turns out that the maintainers were convinced, and
made the proposed change.

Indeed, after the unequivocal messages from the systemd maintainers, I
think badgering them might have been inappropriate. If you don't like
a decision someone else has made, and it doesn't appear that there is
much more room for discussion, you should either live with the
decision, or escalate it. We would like to avoid browbeating.

During the discussion of the TC bug no-one from the systemd team
suggested that they might review their decision in the light of the
arguments that were presented in the TC. And indeed there is no
requirement that a maintainer should do so.

However, I think the TC is entitled to assume, during its
deliberations, that maintainers' previously stated decisions and
opinions continue to stand until the maintainers withdraw or
contradict them. (I think the TC is also entitled to assume that the
maintainers, once made aware that an issue has been referred to the
TC, will provide any technical input that they feel is necessary.)

As the TC discussions go through the various stages of fact-finding,
to tentative conclusions, to draft resolutions, the maintainers
continue to have the opportunity to see the facts and arguments being
presented in the discussion, and to avoid a formal decision by
providing a satisfactory solutions to the problem at hand.
The bug referenced as "[1]" above was #756076 which was set as grave on
18th September, with a fix developed upstream on the 5th Nov, which was
This seems to be a different question. The criticism here would be
that TC decision was technically incorrect, because at the time we
voted (or at least at the time we called for votes) #756076 was still
outstanding and ought to have been a blocker for changing the
dependencies ?

My understanding is that installing systemd-shim and indeed cgmanager
is supposed to be harmless under systemd. So while swapping the
dependencies would mean that some users who are going to be using
systemd would get cgmanager installed, cgmanager would not (by
default) be started, and those users would therefore not experience
#756076.

Therefore ISTM that #756076 was not a reason not to swap the
dependencies.

Serge Hallyn corroborates that here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755977#32
which we discussed here
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746578#239
which was immediately before the TC CFV.


Ian.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@chiark.greenend.org.uk
The Wanderer
2014-11-17 17:33:42 UTC
Permalink
Post by Ian Jackson
The bug referenced as "[1]" above was #756076 which was set as
grave on 18th September, with a fix developed upstream on the 5th
Nov, which was then uploaded to Debian on the same day (by Martin
This seems to be a different question. The criticism here would be
that TC decision was technically incorrect, because at the time we
voted (or at least at the time we called for votes) #756076 was
still outstanding and ought to have been a blocker for changing the
dependencies ?
My understanding is that installing systemd-shim and indeed
cgmanager is supposed to be harmless under systemd. So while
swapping the dependencies would mean that some users who are going to
be using systemd would get cgmanager installed, cgmanager would not
(by default) be started, and those users would therefore not
experience #756076.
Therefore ISTM that #756076 was not a reason not to swap the
dependencies.
My understanding is that the systemd maintainers' objection to swapping
the dependencies was not about what would happen to users who are
running systemd-sysv, but what would happen to users who are *not* -
that they felt that automatically switching people from sysvinit-core to
systemd-sysv was preferable to automatically giving them a
known-partially-broken configuration based on systemd-shim and
cgmanager.

Again, if that's not correct, I'd be interested to be corrected on that
point.
--
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
Theodore Ts'o
2014-11-17 23:24:16 UTC
Permalink
This is what many still (retorically) wonder about: we the systemd
maintainers did not reject that change,
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;bug=746578
Please try to be less selective in your quoting: the issue was still
being discussed.
May I gently suggest that tagging a bug "wontfix" has the unfortunate
tendency to perpetuate the perception that the systemd proponents
don't really care about any fallout that systemd might cause on the
rest of Debian --- ESPECIALLY if it's still "open for discussion?

Especially without any discussion or explanation by any other systemd
maintainer?

It may not be accurate, but right now, given the feeling of hurt on
all sides of the issue, a bit more communication instead of a blunt
"tags + wontfix" without any word of explanation might have
contributed to a more productive amount of discussion.

Best regards,

- Ted
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@thunk.org
Raphaël Halimi
2014-11-17 23:38:58 UTC
Permalink
Hi,

First of all, sorry in advance if the beginning of this post looks more
like a bug report discussion than a debian-devel post.
Post by Matthias Urlichs
$ journalctl _SYSTEMD_UNIT=systemd-journald.service
which will (most likely) also show messages like "Suppressed 1927 messages
from /PATH/FOO.slice". You can then use
$ journalctl _SYSTEMD_SLICE=FOO.slice
to display the non-suppressed part of the spew that's responsible
for this overrun.
(intentional disabling of word-wrapping just for the few lines of logs)

***@arche:~$ journalctl _SYSTEMD_UNIT=systemd-journald.service
-- Logs begin at lun. 2014-11-10 20:14:11 CET, end at lun. 2014-11-17 23:31:22 CET. --
nov. 10 20:14:11 arche systemd-journal[207]: Runtime journal is using 8.0M (max allowed 79.2M, trying to leave 118.8M free of 784.0M available → current limit 79.2M).
nov. 10 20:14:11 arche systemd-journal[207]: Runtime journal is using 8.0M (max allowed 79.2M, trying to leave 118.8M free of 784.0M available → current limit 79.2M).
nov. 10 20:14:11 arche systemd-journal[207]: Journal started
nov. 10 20:14:19 arche systemd-journal[207]: Runtime journal is using 8.0M (max allowed 79.2M, trying to leave 118.8M free of 783.3M available → current limit 79.2M).
nov. 10 20:14:34 arche systemd-journal[207]: Forwarding to syslog missed 42 messages.
nov. 14 01:02:44 arche systemd-journal[207]: Forwarding to syslog missed 1 messages.
nov. 14 01:25:31 arche systemd-journal[207]: Forwarding to syslog missed 2 messages.
nov. 14 01:26:36 arche systemd-journal[207]: Forwarding to syslog missed 2 messages.
nov. 15 18:22:24 arche systemd-journal[207]: Forwarding to syslog missed 9 messages.
nov. 15 18:22:54 arche systemd-journal[207]: Forwarding to syslog missed 3 messages.
nov. 16 22:27:37 arche systemd-journal[207]: Forwarding to syslog missed 1 messages.
nov. 16 22:28:13 arche systemd-journal[207]: Forwarding to syslog missed 1 messages.
nov. 17 15:13:45 arche systemd-journal[207]: Forwarding to syslog missed 18 messages.


As you can see, no syslog-filler slice to investigate in particular. I'm
quite happy though, because after you and Ben emitted the idea that I
may have ran with messed up logs long before I upgraded to systemd, I
was quite worried, even if it's a sid desktop that I moderately care
about (after all, if that's the case, it could happen on my production
servers as well); but the small number of missed messages (less than 50,
very different from the thousands you suspected) make me think that my
logs on this machine are a lot less likely to have been crippled for a
long time without my knowledge than both of you initially thought,
aren't they ?
Post by Matthias Urlichs
Post by Raphaël Halimi
drop the message" (IIRC it was even more condescending, like "we don't
have to wait for this" or something). Really ? The very piece of code
which is supposed to talk to syslog... doesn't wait for syslog ?
Do you want to buffer an unbounded number of messages in RAM instead,
hoping that syslog will catch up eventually? Thanks, but no thanks.
(Implementing a _bounded_ message buffer in systemd doesn't make sense,
because you can get the exact same effect by simply doing (a), above.)
Now for the interesting part (for debian-devel, anyway :) ). Maybe as a
sysadmin I lack some C arcane knowledge and it may sound like a silly
question to you, but why would that be such a bad idea ? Rsyslog (debian
default since lenny) does this; if it's configured to send messages to a
remote server via TCP, and if the server is unreachable for whatever
reason, it stores the messages in a buffer until they can be sent; it
even stores them to the disk if the case it's terminated. Why journald
using some more KB or MB of RAM to store the messages it couldn't forward in
time, and waiting for syslog to catch up, would be such a bad thing to do ?
Post by Matthias Urlichs
It's likely (though not certain) that your logs have been crippled in the
past, albeit in a different way, and you simply didn't notice because the
logging program didn't tell you. The standard syslog(3) code doesn't.
Like I said, it doesn't look that way (at least I hope it doesn't) but
correct me if I'm wrong.

Regards,
--
Raphaël Halimi
Ben Hutchings
2014-11-15 17:45:53 UTC
Permalink
Post by Raphaël Halimi
Post by Ralf Jung
How does having yet another NTP client shut off existing NTP clients?
How does having yet another way to configure your network shut off
existing alternatives?
How does having yet another web browser integrated in the OS shut off
existing web browsers ? ;)
Post by Ralf Jung
Even syslog is still working!
nov. 10 20:14:34 arche systemd-journal[207]: Forwarding to syslog missed
42 messages.
nov. 14 01:02:44 arche systemd-journal[207]: Forwarding to syslog missed
1 messages.
nov. 14 01:25:31 arche systemd-journal[207]: Forwarding to syslog missed
2 messages.
nov. 14 01:26:36 arche systemd-journal[207]: Forwarding to syslog missed
2 messages.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762700
http://lists.freedesktop.org/archives/systemd-devel/2014-August/021897.html
I know it may be biased since I'm the reporter of the bug, but I'm tired
of reading that systemd replaces all those components smoothly.
It does not.
Now on the technical side, when I reported this bug I looked at the
source code. In a nutshell, the comment said "If syslog is too slow,
drop the message" (IIRC it was even more condescending, like "we don't
have to wait for this" or something). Really ? The very piece of code
which is supposed to talk to syslog... doesn't wait for syslog ?
[...]

Unfortunately, syslog(3) has never guaranteed that messages actually end
up in the log (or are filtered out), nor does it return an error code.
Does the interposition of systemd-journald actually make it less
reliable? Or, are you annoyed because it called attention to this
unreliability whereas messages were previously dropped silently?

openlog(3) *does* provide an option to log to the console in case of
failure, however, and this presumably won't (and can't) be honoured by
systemd-journald if it loses messages later. I don't know whether this
option is widely used, or whether the fallback is actually useful in
practice.

Ben.
--
Ben Hutchings
Never put off till tomorrow what you can avoid all together.
Theodore Ts'o
2014-11-13 17:11:27 UTC
Permalink
Post by Russ Allbery
What do you think we should have done instead? debian-devel was becoming
the standing debian-canonical-is-evil vs. debian-systemd-sucks standing
flamewar. (I think people are already forgetting the whole Canonical is
evil flamewar that was happening at the same time, with the same degree of
vitriol that is now being levelled at systemd.)
That doesn't match my perception of the history; but part of this may
have been that the vitriol level escalated significantly once the TC
announced they were going involve itself in the debate, and it doesn't
look like it has gotten any better ever since.

That being said, I am sure that the TC got involved with the best
intentions, and most of the DD's involved in the discussions were all
united in their passion for wanting the best for Debian (even if they
agreed on very little else, at least on the systemd mail threads :-).

If only everyone could really internalize this belief; I think it
would make these discussions much less painful.
Post by Russ Allbery
I think people have an idealistic notion here that consensus will always
emerge eventually, and it's easy at this point in the process to
sugar-coat the past and forget how bad it was. Please, make a concerted
effort to put yourself into the mindset the project was in during the fall
of 2013. It's always easy to see, in hindsight, the cost of the option
that was taken; it's harder to see the cost of the option that was not
taken.
Personally, I strongly suspect that we could have waited until 2020 and
there still wouldn't be any consensus. And that has its own risk.
I have a different belief about the future, but (a) there was no way
to know whether things would have gotten worse back in Fall 2013, and
(b) there's no way any of us can know for sure what the future will
bring, or what would have happened if we had taken an alternate path.
All we can do is to go forward, as best as we can.

Because regardless of how this GR is settled, it doesn't really answer
the question about the use of all of the other pieces of systemd; or
at least, I don't think that any of the options are the equivalent of
a blank check adoption of systemd-*, whether it be systemd-networkd,
systemd-resolved, systemd-consoled, etc. And it sure would be nice if
we don't have the same amount of pain as each of these components get
proposed. (My personal hope is that if they are optional, as opposed
made mandatory because GNOME, network-manager, upower, etc. stops
working if you don't use the latest systemd-*, it won't be that bad
going forward.)

Regards,

- Ted
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@thunk.org
Carlos Alberto Lopez Perez
2014-11-13 17:20:33 UTC
Permalink
Post by Theodore Ts'o
And it sure would be nice if
we don't have the same amount of pain as each of these components get
proposed. (My personal hope is that if they are optional, as opposed
made mandatory because GNOME, network-manager, upower, etc. stops
working if you don't use the latest systemd-*, it won't be that bad
going forward.)
The last one that I read is that udev is going to stop working on
non-systemd systems:

http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
Brian May
2014-11-13 22:16:01 UTC
Permalink
Post by Carlos Alberto Lopez Perez
The last one that I read is that udev is going to stop working on
http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
I don't read anything in that post that says this.

Am guessing you a referring to the "Also note that at that point we intend
to move udev onto kdbus as transport, and get rid of the
userspace-to-userspace netlink-based tranport udev used so far" quote.

Which would suggest that udev might stop supporting the
userspace-to-userspace netlink-based transport in the future. However,
unless I am mistaken, I don't think this means it will no longer work on
non-systemd systems.
--
Brian May <***@microcomaustralia.com.au>
Svante Signell
2014-11-13 22:30:25 UTC
Permalink
On 14 November 2014 04:20, Carlos Alberto Lopez Perez
Which would suggest that udev might stop supporting the
userspace-to-userspace netlink-based transport in the future. However,
unless I am mistaken, I don't think this means it will no longer work
on non-systemd systems.
From an irc:(16:06:44) xxx: udevd starts very slowly without systemd...
any chance i can speed it up?

Things evolve with time....
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@G3620.my.own.domain
Brian May
2014-11-13 22:46:08 UTC
Permalink
Post by Svante Signell
From an irc:(16:06:44) xxx: udevd starts very slowly without systemd...
any chance i can speed it up?
Assuming that report is accurate, to me it sounds like a bug that should
get fixed, as opposed to a clear indication that udevd is going to stop
supporting non-systemd systems.
--
Brian May <***@microcomaustralia.com.au>
Svante Signell
2014-11-13 22:54:25 UTC
Permalink
From an irc:(16:06:44) xxx: udevd starts very slowly without
systemd...
any chance i can speed it up?
Assuming that report is accurate, to me it sounds like a bug that
should get fixed, as opposed to a clear indication that udevd is going
to stop supporting non-systemd systems.
The problem is that udevd is part of systemd, i.e. non-systemd systems
are not actively supported (and will not be in due time, I wonder
when?).
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@G3620.my.own.domain
Florian Lohoff
2014-11-15 17:04:40 UTC
Permalink
Hi,
Post by Brian May
Post by Svante Signell
From an irc:(16:06:44) xxx: udevd starts very slowly without systemd...
any chance i can speed it up?
Assuming that report is accurate, to me it sounds like a bug that should
get fixed, as opposed to a clear indication that udevd is going to stop
supporting non-systemd systems.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767363

There are other reports about 30 second delays on bootup
not yet linked to an absent systemd.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754987

which is already merged with

#755708, #755736, #756649, #760976, #763041

Open 4 months now ...

Flo
--
Florian Lohoff ***@zz.de
Holger Levsen
2014-11-15 17:12:20 UTC
Permalink
forcemerge 754987 767363
# not sure why you mail devel about this instead of merging the bugs...
thanks
Adam Borowski
2014-11-13 23:07:17 UTC
Permalink
Post by Svante Signell
From an irc:(16:06:44) xxx: udevd starts very slowly without systemd...
any chance i can speed it up?
This is #767363 aka #754987 aka ~1e38 others.

For now, you can
sed -i 's/allow-hotplug eth0/auto eth0/' /etc/network/interfaces
although there's a patch by Ben Hutchings that's said to work.
All praise Ben!
--
// 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-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@angband.pl
Svante Signell
2014-11-13 23:20:36 UTC
Permalink
Post by Adam Borowski
Post by Svante Signell
From an irc:(16:06:44) xxx: udevd starts very slowly without systemd...
any chance i can speed it up?
This is #767363 aka #754987 aka ~1e38 others.
For now, you can
sed -i 's/allow-hotplug eth0/auto eth0/' /etc/network/interfaces
although there's a patch by Ben Hutchings that's said to work.
All praise Ben!
Yes, all praise Ben. But your proposal is a workaround, not a solution,
if we are being strict :(
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@G3620.my.own.domain
Adam Borowski
2014-11-13 23:30:46 UTC
Permalink
Post by Svante Signell
Post by Adam Borowski
Post by Svante Signell
From an irc:(16:06:44) xxx: udevd starts very slowly without systemd...
any chance i can speed it up?
This is #767363 aka #754987 aka ~1e38 others.
For now, you can
sed -i 's/allow-hotplug eth0/auto eth0/' /etc/network/interfaces
although there's a patch by Ben Hutchings that's said to work.
All praise Ben!
Yes, all praise Ben. But your proposal is a workaround, not a solution,
if we are being strict :(
Yes it is, it makes sense only on desktops and servers. You see, there's a
reason we keep Ben around...
--
// 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-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@angband.pl
Vincent Bernat
2014-11-13 23:21:15 UTC
Permalink
Post by Svante Signell
Post by Brian May
Which would suggest that udev might stop supporting the
userspace-to-userspace netlink-based transport in the future. However,
unless I am mistaken, I don't think this means it will no longer work
on non-systemd systems.
From an irc:(16:06:44) xxx: udevd starts very slowly without systemd...
any chance i can speed it up?
Things evolve with time....
What an accurate bug report. Could you please stop the FUD?

From such a short statement, this could just be the "udevadm settle"
needed when the init does not handle events. It just waits for
everything to come here. With systemd, this is not needed since
everything is expected to react to various events.
--
panic ("No CPUs found. System halted.\n");
2.4.3 linux/arch/parisc/kernel/setup.c
Ben Hutchings
2014-11-13 23:15:34 UTC
Permalink
On 14 November 2014 04:20, Carlos Alberto Lopez Perez
The last one that I read is that udev is going to stop working on
http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
I don't read anything in that post that says this.
Am guessing you a referring to the "Also note that at that point we
intend to move udev onto kdbus as transport, and get rid of the
userspace-to-userspace netlink-based tranport udev used so far" quote.
Which would suggest that udev might stop supporting the
userspace-to-userspace netlink-based transport in the future. However,
unless I am mistaken, I don't think this means it will no longer work
on non-systemd systems.
They will need something else to configure kdbus, though.

I don't even know how initramfs-tools will continue working after that
point.

Ben.
--
Ben Hutchings
friends: People who know you well, but like you anyway.
Carlos Alberto Lopez Perez
2014-11-14 03:19:00 UTC
Permalink
Post by Brian May
Post by Carlos Alberto Lopez Perez
The last one that I read is that udev is going to stop working on
http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
I don't read anything in that post that says this.
Am guessing you a referring to the "Also note that at that point we intend
to move udev onto kdbus as transport, and get rid of the
userspace-to-userspace netlink-based tranport udev used so far" quote.
Which would suggest that udev might stop supporting the
userspace-to-userspace netlink-based transport in the future. However,
unless I am mistaken, I don't think this means it will no longer work on
non-systemd systems.
Once they replace the netlink transport with kdbus, udev will
effectively require kdbus to work.

And for kdbus to work (with the current implementation) some user space
daemon has to set up the system bus and configure it. This is not a
trivial task, and the only daemon that currently does that is systemd
(pid 1).
Bjørn Mork
2014-11-14 12:52:51 UTC
Permalink
Post by Brian May
Post by Carlos Alberto Lopez Perez
The last one that I read is that udev is going to stop working on
http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
I don't read anything in that post that says this.
Am guessing you a referring to the "Also note that at that point we intend
to move udev onto kdbus as transport, and get rid of the
userspace-to-userspace netlink-based tranport udev used so far" quote.
Which would suggest that udev might stop supporting the
userspace-to-userspace netlink-based transport in the future. However,
unless I am mistaken, I don't think this means it will no longer work on
non-systemd systems.
The next sentence after the one you quote is: "Unless the systemd-haters
prepare another kdbus userspace until then this will effectively also
mean that we will not support non-systemd systems with udev anymore
starting at that point."


Bjørn
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@nemi.mork.no
Russ Allbery
2014-11-13 18:04:00 UTC
Permalink
Post by Theodore Ts'o
That doesn't match my perception of the history; but part of this may
have been that the vitriol level escalated significantly once the TC
announced they were going involve itself in the debate,
Yes, we have very different recollections. My recollection is that the
vitriol level actually dropped quite a bit when the TC first started
getting involved, rose (but largely on the TC list) during the argument,
and fell considerably after the decision. Then started to rise again, and
now is worse than it was originally.
Post by Theodore Ts'o
That being said, I am sure that the TC got involved with the best
intentions, and most of the DD's involved in the discussions were all
united in their passion for wanting the best for Debian (even if they
agreed on very little else, at least on the systemd mail threads :-).
If only everyone could really internalize this belief; I think it
would make these discussions much less painful.
+1.
Post by Theodore Ts'o
I have a different belief about the future, but (a) there was no way to
know whether things would have gotten worse back in Fall 2013, and (b)
there's no way any of us can know for sure what the future will bring,
or what would have happened if we had taken an alternate path. All we
can do is to go forward, as best as we can.
In a sense, of course, this is true. However, what I'm trying to point
out is that we have a fundamental governance question facing us here.
What are we, as a project, going to do when we face a decision where the
project is strongly divided and all sides consider the opposing decision
to be a disaster?

Several people commenting here seem to still be stuck on trying to find
some solution that will make everyone happy. Maybe someone will find some
breakthrough, but I have to say that, over the past three years, we've cut
this problem from every different direction and failed to find this. Some
of the attempted compromises have actually made the problem worse. I am
highly dubious that some consensus position is going to emerge.
Post by Theodore Ts'o
Because regardless of how this GR is settled, it doesn't really answer
the question about the use of all of the other pieces of systemd; or at
least, I don't think that any of the options are the equivalent of a
blank check adoption of systemd-*, whether it be systemd-networkd,
systemd-resolved, systemd-consoled, etc.
Certainly not. Why would we ever say we were going to adopt all upstream
work without even looking at it? We don't do that in any other area of
the distribution.

But one thing that's making this discussion hard is the assumption that
people who *did* take a deep look at a particular component and decided to
use it knowing its advantages and weaknesses somehow were tricked or
fooled by a "marketing campaign" into doing so and didn't know what they
were doing. I find this insulting, and I suspect some of our upstreams
also find this insulting.

Many of the systemd components that you're talking about are, as I
understand it, emerging from work on building lightweight containers,
where it's nice to have an easy-to-deploy minimal stack that can bootstrap
out of nothing, providing just enough support to spawn a process in a
stripped-down, minimal container environment that doesn't need first-class
OS services. That may or may not be the right approach for containers; I
have no strong opinion, having not delved deeply into that space. It's
surely quite a stretch to think that we would adopt components written for
that environment as components on which to build a full-featured OS
installation unless they expand beyond that role and offer clear
advantages and compelling benefits over other components. Maybe they
will, maybe they won't.
Post by Theodore Ts'o
And it sure would be nice if we don't have the same amount of pain as
each of these components get proposed.
Indeed. Which is, among other things, going to require taking people's
arguments at face value and extending the assumption of good will that
people proposing technical solutions are doing so because they thought
about the problem and thought the solution was superior, not because of a
"marketing campaign."
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@hope.eyrie.org
Russ Allbery
2014-11-13 19:24:31 UTC
Permalink
Post by Russ Allbery
In a sense, of course, this is true. However, what I'm trying to point
out is that we have a fundamental governance question facing us here.
What are we, as a project, going to do when we face a decision where
the project is strongly divided and all sides consider the opposing
decision to be a disaster?
What ever happened to letting the system evolve naturally? Rather than
force change on the users, let the quality and utility of the software
the user *wants* to run manage the timetable to change the foundational
elements of the system.
This sounds great on the surface, but the general principle is hard to
apply to the current situation for a couple of reasons.

First, several of our upstreams have, from their perspective, already gone
through this natural evolution process and have landed on a new set of
software, which they are now requiring as a prerequisite. This is, in one
sense, a normal thing for upstreams to do. It happens all the time with
new shared libraries or new ABIs of existing shared libraries. However,
this time, it's rather unusual, since it's unusually hard (although not
completely impossible) to provide both the old and new mechanisms at the
same time. It's not unheard of, though; we have retired old stacks before
even though some users wanted to use them because they weren't supported
upstream. I'm remembering the last GNOME and KDE major release
transitions, for instance. (And, in the GNOME case, a team stepped up to
maintain a fork, and as a result the previous version is being
reintroduced in the archive under a different name.)

Again, you can have many different opinions about these decisions, and I
know people do, but the fact remains that the people who are making those
decisions are independent citizens of the free software community with the
right to make their own decisions. We don't get to tell them what to do;
it would be extremely rude of us to do so, not to mention completely
ineffective as we are not their bosses or owners. The alternative is what
it always is in free software: if you don't like a project direction and
can't convince the current maintainers that you're right, you either have
to put up enough resources to maintain a fork or live with it.

Second, our users are just as split as the developers are. Some users
have already gone through the process you describe and are eager for the
new software. Others are pretty leery or even actively opposed. If we
can maintain both in parallel, this is not a problem, but it seems like
everyone is dubious about the project's ability to maintain both, so one
side is arguing for investing our time into supporting sysvinit rather
than systemd, and the other side is arguing for investing our time into
supporting systemd instead of sysvinit, both making essentially zero-sum
tradeoff assumptions.

The question of whether we can support both as first-class citizens is
exactly one of the points of severe and apparently irreconcilable
disagreement. In particular, one group feels like we should effectively
force support for sysvinit as a prerequisite for having one's package
included in Debian or remaining in Debian, even for packages where both
upstream and Debian maintainer have already gone through the process you
describe and are ready to move on to something else, and without a clear
picture of who is going to be doing that work. And another group is
uninterested in continuing to support sysvinit beyond the jessie release,
because they don't believe the effort is warranted, are not interested
in doing the work, and are dubious that the resources to do so will
materialize.
Change from the status quo should be done when there is a compelling
reason to do so - and then with great care and consideration of the
consequences.
And there are lots of people in Debian who have gone through this thought
process and who believe that they are doing exactly this. And there are
lots of other people who disagree.

So, again, we return to the governance question. We're at loggerheads no
matter how you cut it, including the way that you're trying to cut it. Do
we wait for unanimity? Is that the right default decision?

Unanimity in a project of 1,000 people is a long time. If we waited for
unanimity, we'd still be shipping KDE 3. Would that have been the right
decision?
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@hope.eyrie.org
Russ Allbery
2014-11-13 21:39:52 UTC
Permalink
We do tell users of Debian what to do - that's part of the problem right
now. We told the users they will switch init systems, and a large
portion (or at least a vocal portion) don't want to.
Well, no, we didn't. We said that there would be a different default,
which is not the same thing. The project hasn't made a decision about
switching, and also, at present, sysvinit is still fully supported (modulo
the normal pre-release bugs).
The current systemd / GR issue would not be happening if the project had
not said the default init system shall be <init system>. Had the
project said we have the following init systems available: <list of init
systems> and let the other package dependencies drive the user's
selection then users would fell there was a little more choice in the
matter.
Right now, GNOME seems to be the primary driver for requiring systemd.
If you don't use a graphical environment, you don't need systemd but you
are forced to at least install it on a new build.
Various people were discussing the installer experience elsewhere, and
whether enough users care about this to warrant making a sysvinit install
an option directly in the installer. I don't think this is any sort of
fudamental decision we've already made; it's a debate over UI experiences.

In other words, I don't think this is anywhere near as central to the
argument as you seem to think. If I'm wrong, that's great news -- if all
of this argument could go away by just tweaking the installer UI, that
would be fantastic. But I'm dubious.
If there are two opposing sides, then there are two maintainers willing
to maintain the packages. If there are not, the package without a
maintainer looses by default.
Ah, see, I also believe this, which is exactly why I'm so upset about the
current GR. The proposed GR (the first option) is exactly about
overriding the normal practice that the package without a maintainer loses
by default, and about *forcing* the people who aren't using sysvinit to
work on maintaining it. This is one of the fundamental divisions in the
project right now.

Of course, proponents of it probably even disagrees with my
characterization of it, because we're *also* fundamentally disagreeing
over even what the proposed GR actually does.

It really is deep disagreements all the way down.
I don't recall Debian every saying we will support package <package>
forever and ever.
Exactly, and that's why some of us are aghast at a GR that basically says
that about sysvinit, except cast in terms to try to make it seem like
that's not what it actually says.
Waiting implies lack of movement - this is not what I was saying. I say
allow the natural evolution to play out. GNOME wants to require systemd
and someone packages systemd - great - allow it AS AN OPTION, NOT A
REQUIREMENT for all. Similarly with sysvinit - it has maintainers,
allow it as an option.
This means that you and I are basically in agreement, and I suspect you'll
find that you're basically in agreement with most of the people on the
systemd "side." That's pretty much the position that I've been arguing,
and the position that I believe the current GR is trying to reverse by
forcing GNOME, and every other package in Debian, to support sysvinit.

The only remaining thing about which we may disagree is that I think the
installer needs to pick *something* that gets installed by default, and
that the average user isn't going to care or know enough to pick
something. (I would like to see the inability to select sysvinit via such
install methods as debootstrap fixed before the release; I think that's
just a bug.)
The issue we should be tackling is not which init system to force on the
users, but the higher level "what is the minimum functionality and API a
init-system in its control file.
That sounds like a great discussion to have, from my perspective, and the
discussion that I was hoping we could have following the TC (and that I
was then unable to try to drive due to a lot of non-Debian life stuff on
my part). But I don't think that's the discussion that the GR is having,
or that most of the systemd arguments are focused on.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@hope.eyrie.org
Patrick Ouellette
2014-11-13 21:56:10 UTC
Permalink
Post by Russ Allbery
We do tell users of Debian what to do - that's part of the problem right
now. We told the users they will switch init systems, and a large
portion (or at least a vocal portion) don't want to.
Well, no, we didn't. We said that there would be a different default,
which is not the same thing. The project hasn't made a decision about
switching, and also, at present, sysvinit is still fully supported (modulo
the normal pre-release bugs).
By making it the new default, and causing apt-get dist-upgrade to install
systemd (which is what happened to one of my systems) in place of sysvinit
we most certainly are. Did the system implode in a fiery pool - no, but I
was forced to deal with the unexpected aftermath. There was some breakage,
and some things did not work as expected. (Sure, people would say
I shouldn't be following unstable or SID but then I wouldn't have development
environments.)

By not having a meta-package "init-system" provided by an actual package,
we are forcing anyone who upgrades to also change init systems unless they
take special precautions to not do so.

For the record, I really don't care about the init system per-say. I am
more annoyed with the systemd insistence on logging to binary files than
anything. Log files should be plain text.

Pat
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@flying-gecko.net
Matthias Klumpp
2014-11-13 22:06:08 UTC
Permalink
Post by Patrick Ouellette
Post by Russ Allbery
We do tell users of Debian what to do - that's part of the problem right
now. We told the users they will switch init systems, and a large
portion (or at least a vocal portion) don't want to.
Well, no, we didn't. We said that there would be a different default,
which is not the same thing. The project hasn't made a decision about
switching, and also, at present, sysvinit is still fully supported (modulo
the normal pre-release bugs).
By making it the new default, and causing apt-get dist-upgrade to install
systemd (which is what happened to one of my systems) in place of sysvinit
we most certainly are. Did the system implode in a fiery pool - no, but I
was forced to deal with the unexpected aftermath. There was some breakage,
and some things did not work as expected. (Sure, people would say
I shouldn't be following unstable or SID but then I wouldn't have development
environments.)
When upgrading your OS, you should *always* expect that you might have
to learn things - systemd is just one detail, but a lot of other
applications have changes too which force people to re-learn things
they took for granted before. So nothing new here...
Post by Patrick Ouellette
By not having a meta-package "init-system" provided by an actual package,
we are forcing anyone who upgrades to also change init systems unless they
take special precautions to not do so.
Previously on Debian, you didn't have any choice in init-systems:
Sysvinit was the only option.
Now, we provide a "init" metapackage, which ensures an init system is
installed. We make systemd default here and switch older installations
over to it currently. If you want to stick with a different
initsystem, you have the *choice* to choose any other one the "init"
package depends on, and even pre-select it on upgrade.
This should pretty much make everyone happy, those who care about
which PID1 they are running, and those who don't.
Post by Patrick Ouellette
For the record, I really don't care about the init system per-say. I am
more annoyed with the systemd insistence on logging to binary files than
anything. Log files should be plain text.
Rsyslog is srill installed by default (and I guess that won't change
soon), so you now have even better textlogs.
The binary logs are great for quick searching (just run systemctl
status on a service) and provide some extra benefits for working with
logs (I, for example, love the ability to group entries by priority),
but that's not something someone is forced to work with.

Cheers,
Matthias
--
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/CAKNHny9B14=D9DJBcoXN6a_8ex-***@mail.gmail.com
Patrick Ouellette
2014-11-13 22:25:33 UTC
Permalink
Post by Matthias Klumpp
Post by Patrick Ouellette
For the record, I really don't care about the init system per-say. I am
more annoyed with the systemd insistence on logging to binary files than
anything. Log files should be plain text.
Rsyslog is srill installed by default (and I guess that won't change
soon), so you now have even better textlogs.
The binary logs are great for quick searching (just run systemctl
status on a service) and provide some extra benefits for working with
logs (I, for example, love the ability to group entries by priority),
but that's not something someone is forced to work with.
Matthias,

I did not ask for evangelization about how wonderful binary logs are,
nor for a lesson on how to get the info out of systemd with the
systemctl command.

I am glad you like them and they work for you. For me they add another
level of obfuscation, a speed bump and a potential point of failure.
All of which are unnecessary. Cat <logfile>, more <logfile>
less <logfile>, grep <term> <logfile> -- all worked well and continue to
do so for my text file logs. Awk, emacs, vi, all work on them too.
My log management tools all expect my old plain text formatted logs.

If we can agree to disagree on this all is well. If you feel it necessary
to "convert me" or help me "see the light" then, well, we're going to have
a problem ;-)

Pat
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@flying-gecko.net
Matt Zagrabelny
2014-11-13 22:45:48 UTC
Permalink
Hi Pat,
Post by Patrick Ouellette
Post by Matthias Klumpp
Post by Patrick Ouellette
For the record, I really don't care about the init system per-say. I am
more annoyed with the systemd insistence on logging to binary files than
anything. Log files should be plain text.
That's a loaded statement.
Post by Patrick Ouellette
Post by Matthias Klumpp
Rsyslog is srill installed by default (and I guess that won't change
soon), so you now have even better textlogs.
I did not ask for evangelization about how wonderful binary logs are,
nor for a lesson on how to get the info out of systemd with the
systemctl command.
You shouldn't be surprised that there is dialogue surrounding it.

-m
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/CAOLfK3XTG3ZT-AQHaem+kbsS7OueuCiSwgYZoYt+T=2qpgdB=***@mail.gmail.com
Sam Hartman
2014-11-14 00:05:17 UTC
Permalink
Patrick> On Thu, Nov 13, 2014 at 11:06:08PM +0100, Matthias Klumpp wrote:

Patrick> I did not ask for evangelization about how wonderful binary
Patrick> logs are, nor for a lesson on how to get the info out of
Patrick> systemd with the systemctl command.

Patrick> I am glad you like them and they work for you. For me they
Patrick> add another level of obfuscation, a speed bump and a
Patrick> potential point of failure. All of which are
Patrick> unnecessary. Cat <logfile>, more <logfile> less <logfile>,
Patrick> grep <term> <logfile> -- all worked well and continue to do
Patrick> so for my text file logs. Awk, emacs, vi, all work on them
Patrick> too. My log management tools all expect my old plain text
Patrick> formatted logs.

I'm confused. Are you saying that cat <logfile> isn't working for you
with systemd on jessie?
I'm honestly asking for information here.
As best I can tell on my system everything that gets logged gets logged
to text log files.
Some of it also gets logged to the journal.

--Sam
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/00000149ab9e4869-9d59ba6d-53db-4de0-a43c-841cef1c93bc-***@email.amazonses.com
Patrick Ouellette
2014-11-14 01:39:21 UTC
Permalink
Post by Sam Hartman
I'm confused. Are you saying that cat <logfile> isn't working for you
with systemd on jessie?
I'm honestly asking for information here.
As best I can tell on my system everything that gets logged gets logged
to text log files.
Some of it also gets logged to the journal.
Sam,

I'm saying those things that logged to syslog now log to the journal, so
cat /var/log/syslog doesn't work because the output that used to go there is
redirected to the binary format journal file.

(Obvoiusly if a program manages its own logging, those are not affected by the
change.)

If the journal file is not supposed to be in a binary format, then my system
didn't get that configuration update....

Pat
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@flying-gecko.net
Paul Wise
2014-11-14 02:03:44 UTC
Permalink
Post by Patrick Ouellette
I'm saying those things that logged to syslog now log to the journal, so
cat /var/log/syslog doesn't work because the output that used to go there is
redirected to the binary format journal file.
journald forwards to rsyslog etc, which logs to /var/log/syslog so cat
/var/log/syslog etc still works.

Personally I have found journalctl much more flexible and useful than cat etc.
--
bye,
pabs

https://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/CAKTje6HF6Chq+NkGdtRcv0RZwORS=***@mail.gmail.com
Russ Allbery
2014-11-14 02:07:33 UTC
Permalink
Post by Patrick Ouellette
I'm saying those things that logged to syslog now log to the journal, so
cat /var/log/syslog doesn't work because the output that used to go
there is redirected to the binary format journal file.
If that's happening on your system, that's a bug. It's definitely not
happening on mine. Could you provide more information, such as an example
that's not in /var/log/syslog where you expect it but ended up in the
journal, and what program is involved?
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@hope.eyrie.org
Patrick Ouellette
2014-11-14 02:15:10 UTC
Permalink
Post by Russ Allbery
Post by Patrick Ouellette
I'm saying those things that logged to syslog now log to the journal, so
cat /var/log/syslog doesn't work because the output that used to go
there is redirected to the binary format journal file.
If that's happening on your system, that's a bug. It's definitely not
happening on mine. Could you provide more information, such as an example
that's not in /var/log/syslog where you expect it but ended up in the
journal, and what program is involved?
Since /var/log/syslog is empty, clearly there was an issue when my system
upgraded. I'll have to look into this to see what is going on.

(Kind of illustrates my point about another point of failure... No, I did
not plan or do this intentionally)


Pat
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@flying-gecko.net
Russ Allbery
2014-11-14 02:19:32 UTC
Permalink
Post by Patrick Ouellette
Since /var/log/syslog is empty, clearly there was an issue when my
system upgraded. I'll have to look into this to see what is going on.
(Kind of illustrates my point about another point of failure... No, I
did not plan or do this intentionally)
Ow. No, that's definitely a bug. I'd love to understand what happened
there, as that sounds like a pretty serious one. That is not expected
behavior.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@hope.eyrie.org
Russ Allbery
2014-11-14 02:53:09 UTC
Permalink
Post by Russ Allbery
Ow. No, that's definitely a bug. I'd love to understand what happened
there, as that sounds like a pretty serious one. That is not expected
behavior.
OK, so the system has syslog-ng installed. For what ever reason syslog-ng
is not starting automatically, but starts manually by systemctl.
syslog-ng version 3.5.6-2
systemd version 215-5+b1
Maybe some failure to sync status correctly? syslog-ng does ship with a
service file. What does:

systemctl status syslog-ng

say? Particularly the Loaded and Active fields should have some hint as
to what's going on that's preventing the service from starting
automatically.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@hope.eyrie.org
Cameron Norman
2014-11-14 02:57:45 UTC
Permalink
Post by Russ Allbery
Post by Russ Allbery
Ow. No, that's definitely a bug. I'd love to understand what happened
there, as that sounds like a pretty serious one. That is not expected
behavior.
OK, so the system has syslog-ng installed. For what ever reason syslog-ng
is not starting automatically, but starts manually by systemctl.
syslog-ng version 3.5.6-2
systemd version 215-5+b1
Maybe some failure to sync status correctly? syslog-ng does ship with a
systemctl status syslog-ng
say? Particularly the Loaded and Active fields should have some hint as
to what's going on that's preventing the service from starting
automatically.
Apparently this is a known issue, and another person has experienced
it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760426

Cheers,
--
Cameron Norman
Cameron Norman
2014-11-14 03:00:51 UTC
Permalink
El jue, 13 de nov 2014 a las 6:57 , Cameron Norman
Post by Cameron Norman
Post by Russ Allbery
Post by Russ Allbery
Ow. No, that's definitely a bug. I'd love to understand what happened
there, as that sounds like a pretty serious one. That is not expected
behavior.
OK, so the system has syslog-ng installed. For what ever reason syslog-ng
is not starting automatically, but starts manually by systemctl.
syslog-ng version 3.5.6-2
systemd version 215-5+b1
Maybe some failure to sync status correctly? syslog-ng does ship with a
systemctl status syslog-ng
say? Particularly the Loaded and Active fields should have some hint as
to what's going on that's preventing the service from starting
automatically.
Apparently this is a known issue, and another person has experienced
it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760426
Arg. I read to quickly; this appears to be something quite different.
Nevermind.

--
Cameron Norman
Gergely Nagy
2014-11-14 07:30:36 UTC
Permalink
Post by Russ Allbery
OK, so the system has syslog-ng installed. For what ever reason syslog-ng
is not starting automatically, but starts manually by systemctl.
syslog-ng version 3.5.6-2
systemd version 215-5+b1
Maybe some failure to sync status correctly? syslog-ng does ship with a
systemctl status syslog-ng
say? Particularly the Loaded and Active fields should have some hint as
to what's going on that's preventing the service from starting
automatically.
Cameron> Apparently this is a known issue, and another person has experienced
Cameron> it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760426

That and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769499 are
closely related, and will be fixed in the next syslog-ng upload (likely
early next week). I know how to fix both, but lacked the time to
implement said fixes so far.
--
|8]
Li, Fei OM/STS-ESD
2014-11-14 07:36:47 UTC
Permalink
Unsubscible
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@CN010089.schaeffler.com
Cameron Norman
2014-11-15 18:02:22 UTC
Permalink
On Thu, Nov 13, 2014 at 11:30 PM, Gergely Nagy
Post by Gergely Nagy
Post by Russ Allbery
OK, so the system has syslog-ng installed. For what ever reason syslog-ng
is not starting automatically, but starts manually by systemctl.
syslog-ng version 3.5.6-2
systemd version 215-5+b1
Maybe some failure to sync status correctly? syslog-ng does ship with a
systemctl status syslog-ng
say? Particularly the Loaded and Active fields should have some hint as
to what's going on that's preventing the service from starting
automatically.
Cameron> Apparently this is a known issue, and another person has experienced
Cameron> it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760426
That and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769499 are
closely related, and will be fixed in the next syslog-ng upload (likely
early next week). I know how to fix both, but lacked the time to
implement said fixes so far.
This is a great chance to use the 'newcomer' tag recently added as an
official tag. It is for relatively simple bugs that a fix is known
for, but the maintainer just does not have the time. Please do
consider it in the future!

Thanks,
--
Cameron Norman
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/CALZWFR+iWMJKEkSmo_=6YSF1-***@mail.gmail.com
Gergely Nagy
2014-11-17 06:17:44 UTC
Permalink
Cameron> Apparently this is a known issue, and another person has experienced
Cameron> it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760426
Post by Gergely Nagy
That and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769499 are
closely related, and will be fixed in the next syslog-ng upload (likely
early next week). I know how to fix both, but lacked the time to
implement said fixes so far.
Cameron> This is a great chance to use the 'newcomer' tag recently added as an
Cameron> official tag. It is for relatively simple bugs that a fix is known
Cameron> for, but the maintainer just does not have the time. Please do
Cameron> consider it in the future!

Sadly, no, it's not a great chance. The problem is not all that simple,
and sadly explaining in sufficient detail what the issue is (so that it
can be fixed by a newcomer) is more time and effort than fixing the bug
itself.

But I do know about the tag, and will use it for other issues, when it
is fitting.
--
|8]
Patrick Ouellette
2014-11-14 03:03:16 UTC
Permalink
Post by Russ Allbery
Maybe some failure to sync status correctly? syslog-ng does ship with a
systemctl status syslog-ng
say? Particularly the Loaded and Active fields should have some hint as
to what's going on that's preventing the service from starting
automatically.
● syslog-ng.service - System Logger Daemon
Loaded: loaded (/etc/systemd/system/syslog-ng.service; disabled)
Active: active (running) since Thu 2014-11-13 21:36:20 EST; 18min ago
Docs: man:syslog-ng(8)
Main PID: 13370 (syslog-ng)
CGroup: /system.slice/syslog-ng.service
└─13370 /usr/sbin/syslog-ng -F

So it claims the syslog-ng service is disabled.

Pat
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@flying-gecko.net
Russ Allbery
2014-11-14 03:13:12 UTC
Permalink
Post by Patrick Ouellette
● syslog-ng.service - System Logger Daemon
Loaded: loaded (/etc/systemd/system/syslog-ng.service; disabled)
Active: active (running) since Thu 2014-11-13 21:36:20 EST; 18min ago
Docs: man:syslog-ng(8)
Main PID: 13370 (syslog-ng)
CGroup: /system.slice/syslog-ng.service
└─13370 /usr/sbin/syslog-ng -F
So it claims the syslog-ng service is disabled.
My guess is failure to sync status properly at some point during the
upgrade process, so the fact the init system was enabled somehow didn't
translate into enabling the unit file. This is the work that
deb-systemd-helper is supposed to do.

systemctl enable syslog-ng should fix the problem on that system
permanently. It's going to be trickier to figure out where the problem
was introduced, sadly. :/

Now I'm wondering if some of the folks thinking that systemd implies
binary logging are getting bitten by the same bug that you're getting
bitten by and just didn't realize it wasn't intentional.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@hope.eyrie.org
Sam Hartman
2014-11-14 03:50:02 UTC
Permalink
package: syslog-ng-core
severity: important
version:3.3.5-4
justification: does not enable systemd unit.

syslog-ng-core's postinst does not enable its syslog unit.
I'm guessing that including systemd in the dh sequence is not quite
doing enough to actually turn it on.

Unfortunately dh-systemd is under-documented so I cannot tell where the
bug is but I bet an explicit call to dh_systemd_enable will make your
users happy.
Attached is the buggy postinst

#! /bin/sh

set -e

if [ "$1" = "triggered" ]; then
invoke-rc.d syslog-ng stop || exit $?
invoke-rc.d syslog-ng start || exit $?
exit 0
fi

dpkg-trigger register-syslog-ng-plugin

# Automatically added by dh_installinit
if [ -x "/etc/init.d/syslog-ng" ]; then
update-rc.d syslog-ng defaults 10 90 >/dev/null || exit $?
fi
# End automatically added section


exit 0
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/tslppcqmoet.fsf_-***@mit.edu
Cameron Norman
2014-11-14 02:52:12 UTC
Permalink
El jue, 13 de nov 2014 a las 6:15 , Patrick Ouellette
Post by Patrick Ouellette
Post by Patrick Ouellette
Post by Patrick Ouellette
I'm saying those things that logged to syslog now log to the
journal, so
Post by Patrick Ouellette
cat /var/log/syslog doesn't work because the output that used to
go
Post by Patrick Ouellette
there is redirected to the binary format journal file.
If that's happening on your system, that's a bug. It's definitely not
happening on mine. Could you provide more information, such as an example
that's not in /var/log/syslog where you expect it but ended up in the
journal, and what program is involved?
Since /var/log/syslog is empty, clearly there was an issue when my system
upgraded. I'll have to look into this to see what is going on.
(Kind of illustrates my point about another point of failure... No, I did
not plan or do this intentionally)
Apparently newer versions of systemd-journald do not forward to syslog
by default; that has to be explicitly configured (although rsyslog
already reads the journal and collects the logs). Not sure if 215 is
affected by that behavior, will have to look it up later. What syslog
implementation are you running?

Thanks,
--
Cameron Norman
Michael Biebl
2014-11-14 22:23:59 UTC
Permalink
Post by Cameron Norman
Apparently newer versions of systemd-journald do not forward to syslog
by default; that has to be explicitly configured (although rsyslog
already reads the journal and collects the logs). Not sure if 215 is
affected by that behavior, will have to look it up later. What syslog
implementation are you running?
The version of systemd-journald in Debian does forward all syslog
message and does *not* expect sysloggers to pull the messages from the
journal.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Sam Hartman
2014-11-14 02:40:16 UTC
Permalink
I think this is a bug.
On my system things get logged both to the journal and to
/var/log/syslog.
My understanding talking to systemd folks is that the behavior I'm
seeing is intended and that unless you went out of your way to
configure something different you should still see stuff logged to text
files.
So, you might want to ask on #debian-systemd and/or report a bug.

--Sam
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/00000149ac2c2d41-09d0ce56-a56f-4658-8bc5-853515c63387-***@email.amazonses.com
Russ Allbery
2014-11-14 00:40:23 UTC
Permalink
Post by Patrick Ouellette
By making it the new default, and causing apt-get dist-upgrade to
install systemd (which is what happened to one of my systems) in place
of sysvinit we most certainly are.
The point that I'm making is that those are two separate things. Yes,
both of those happened for jessie, but the only one the *project* decided
(via the TC) was the first one. The second was decided by some of the
maintenance teams involved, other people disagree, there's a big
discussion about that at present, and I don't think the state for the
release is settled at this point.
Post by Patrick Ouellette
By not having a meta-package "init-system" provided by an actual package,
Er:

Package: init
Source: init-system-helpers
Version: 1.21
Essential: yes
Installed-Size: 29
Maintainer: pkg-systemd-maintainers <pkg-systemd-***@lists.alioth.debian.org>
Architecture: amd64
Pre-Depends: systemd-sysv | sysvinit-core | upstart
Description-en: System-V-like init utilities - metapackage
This package is an essential metapackage which allows you to select from
three available init systems in Debian (systemd, sysvinit, upstart) while
ensuring that one of these is available on the system at all times.
Description-md5: e52554c23609041bfbca72fe27a132f9
Section: metapackages
Priority: required
Filename: pool/main/i/init-system-helpers/init_1.21_amd64.deb
Size: 4634
MD5sum: a3844c4fe9eef9e8976803cebc33ab68
SHA1: caad9e2284c37cd25ef7ca58e23d243a37d5cc24
SHA256: ff7cd1f757d5ab178c666892caa05559f8dce2817528ab677fe778655f70e11d

I don't think the nature of the problem is quite what you think it is.
Post by Patrick Ouellette
For the record, I really don't care about the init system per-say. I am
more annoyed with the systemd insistence on logging to binary files than
anything. Log files should be plain text.
I'm sorry that you've been misled about this. systemd logs as plain text
by default in Debian. In fact, the plain text logs are much better than
what we get from sysvinit, since they include stdout and stderr of
daemons.

That plain-text logging was replaced with binary logging is another piece
of inaccurate FUD that's been going around. At least on debian-user, this
information is being spread intentionally by trolls who know that it's a
lie, just to make people angry unnecessarily.
--
Russ Allbery (***@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@hope.eyrie.org
Svante Signell
2014-11-13 22:03:26 UTC
Permalink
Post by Russ Allbery
We do tell users of Debian what to do - that's part of the problem right
now. We told the users they will switch init systems, and a large
portion (or at least a vocal portion) don't want to.
Well, no, we didn't. We said that there would be a different default,
which is not the same thing. The project hasn't made a decision about
switching, and also, at present, sysvinit is still fully supported (modulo
the normal pre-release bugs).
See #765803. That bug report is about making the user aware of/alerted
to an init switch when upgrading, nothing else. And that issue has not
yet been resolved by the ctte, due to the GR. Hopefully when the GR
result is published, the ctte can decide on this. (assuming the outcome
is a non-gr issue? what happens if not?)
Post by Russ Allbery
Ah, see, I also believe this, which is exactly why I'm so upset about the
current GR. The proposed GR (the first option) is exactly about
overriding the normal practice that the package without a maintainer loses
by default, and about *forcing* the people who aren't using sysvinit to
work on maintaining it. This is one of the fundamental divisions in the
project right now.
Maybe I'm misunderstanding, but my interpretation is _not_ the above?
Ian?
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@G3620.my.own.domain
Michael Ole Olsen
2014-11-13 23:19:36 UTC
Permalink
It would be very cool if the debian installer had a listofpackages.txt

and that listofpackages.txt could be edited by the user

then we would be getting customized debian installs

some people would edit and tell it to auto install:
- zsh
- lilo instead of grub
- lukssetup (crypt thing)
- ext3 instead of ext4
- Xfree86 instead of Xorg
- systemX instead of systemY

etc. :-)

would be very cool if this was possible
it is hard to do everyone right in the installer

so most people will have to install afterwards

but not if this was possible

they could make their own perfect debian install cd
would be a sysadm's dream..

also the geeks dream


of course there is debootstrap too, but it would be cool if the debian installer could be made like this too
just dragdrop a list of installpackages.txt into base of debian install CD

then the CD finds that list and replaces grub with lilo in end of install if needed

and sysX with sysY if specificed in list


would be the ultimate customization, we would get wikis filled with packagelists for custom debian cds

the biggest problem is we would get nonsupported debian dists, could be a big problem
people claiming they use official debian, but then own packages in installer

still think it would be very cool... debootstrap can provide this, but debian installer can't do this easily

only if you are a debian programmer do you know how to do it probably...


until then I prefer to use debootstrap, I don't like to use the installer because it forces me to use certain packages
i.e. it installs grub and newest kernel for me, which I might not want
or it installs sysX instead of SysY

I know I am picky... and lazy

I do really like the ssh connection to the installer though....


this is just a last suggestion, would make perfect debian installers if this was possible

override all packages after end install if custompackages.txt exists in CD directory
of if it exists on a usbstick on the pc that gets automounted

unlimited configuration possibilities!

I could tell it to install an old kernel, a custom compiled kernel etc.

I often use custom kernels... would have to install those manually after installing as it is now


many sysadms use custom kernels they have compiled for debian themselves
as it is now they have to debootstrap or install normal debian dist
then copy it over afterwards

with this im suggesting they could make their own debian installer with their custom kernel on
custom bootloader etc.

custom kernel is ALSO just a simple .deb package to install!

lilo bootloader is too

so that listofpackages.txt should just contain .deb filenames to install after end of installation!


would be very unique to the debian installer if this was possible
all people would stop complaining, almost ;)


we would be getting :
debian-simplified
debian-for-sysadms
debian-for-geeks
debian-for-lilousers
debian-for-sysV-users

and many more custom installers (custompackage lists in wikis)
Post by Russ Allbery
We do tell users of Debian what to do - that's part of the problem right
now. We told the users they will switch init systems, and a large
portion (or at least a vocal portion) don't want to.
Well, no, we didn't. We said that there would be a different default,
which is not the same thing. The project hasn't made a decision about
switching, and also, at present, sysvinit is still fully supported (modulo
the normal pre-release bugs).
The current systemd / GR issue would not be happening if the project had
not said the default init system shall be <init system>. Had the
project said we have the following init systems available: <list of init
systems> and let the other package dependencies drive the user's
selection then users would fell there was a little more choice in the
matter.
Right now, GNOME seems to be the primary driver for requiring systemd.
If you don't use a graphical environment, you don't need systemd but you
are forced to at least install it on a new build.
Various people were discussing the installer experience elsewhere, and
whether enough users care about this to warrant making a sysvinit install
an option directly in the installer. I don't think this is any sort of
fudamental decision we've already made; it's a debate over UI experiences.
In other words, I don't think this is anywhere near as central to the
argument as you seem to think. If I'm wrong, that's great news -- if all
of this argument could go away by just tweaking the installer UI, that
would be fantastic. But I'm dubious.
If there are two opposing sides, then there are two maintainers willing
to maintain the packages. If there are not, the package without a
maintainer looses by default.
Ah, see, I also believe this, which is exactly why I'm so upset about the
current GR. The proposed GR (the first option) is exactly about
overriding the normal practice that the package without a maintainer loses
by default, and about *forcing* the people who aren't using sysvinit to
work on maintaining it. This is one of the fundamental divisions in the
project right now.
Of course, proponents of it probably even disagrees with my
characterization of it, because we're *also* fundamentally disagreeing
over even what the proposed GR actually does.
It really is deep disagreements all the way down.
I don't recall Debian every saying we will support package <package>
forever and ever.
Exactly, and that's why some of us are aghast at a GR that basically says
that about sysvinit, except cast in terms to try to make it seem like
that's not what it actually says.
Waiting implies lack of movement - this is not what I was saying. I say
allow the natural evolution to play out. GNOME wants to require systemd
and someone packages systemd - great - allow it AS AN OPTION, NOT A
REQUIREMENT for all. Similarly with sysvinit - it has maintainers,
allow it as an option.
This means that you and I are basically in agreement, and I suspect you'll
find that you're basically in agreement with most of the people on the
systemd "side." That's pretty much the position that I've been arguing,
and the position that I believe the current GR is trying to reverse by
forcing GNOME, and every other package in Debian, to support sysvinit.
The only remaining thing about which we may disagree is that I think the
installer needs to pick *something* that gets installed by default, and
that the average user isn't going to care or know enough to pick
something. (I would like to see the inability to select sysvinit via such
install methods as debootstrap fixed before the release; I think that's
just a bug.)
The issue we should be tackling is not which init system to force on the
users, but the higher level "what is the minimum functionality and API a
init-system in its control file.
That sounds like a great discussion to have, from my perspective, and the
discussion that I was hoping we could have following the TC (and that I
was then unable to try to drive due to a lot of non-Debian life stuff on
my part). But I don't think that's the discussion that the GR is having,
or that most of the systemd arguments are focused on.
--
--
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@rlogin.dk
Fabrice Aeschbacher
2014-11-14 07:56:53 UTC
Permalink
You can do this using a preseed file:

https://www.debian.org/releases/wheezy/amd64/apb.html.en

in particular:

d-i pkgsel/include string htop vim tree zsh

Cheers,
Fabrice
Post by Michael Ole Olsen
It would be very cool if the debian installer had a listofpackages.txt
and that listofpackages.txt could be edited by the user
then we would be getting customized debian installs
- zsh
- lilo instead of grub
- lukssetup (crypt thing)
- ext3 instead of ext4
- Xfree86 instead of Xorg
- systemX instead of systemY
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/CACfjVBa_uoq6_0NfPA5bsg+cc=dE7d=***@mail.gmail.com
Jonas Smedegaard
2014-11-14 10:29:13 UTC
Permalink
Hi Michael Ole,

Quoting Michael Ole Olsen (2014-11-14 00:19:36)
Post by Michael Ole Olsen
It would be very cool if the debian installer had a listofpackages.txt
and that listofpackages.txt could be edited by the user
then we would be getting customized debian installs
A list of _all_ packages would be too inflexible (would only be useful
for installing *exactly* same set of packages again, not a newer release
of Debian nor e.g. systems needing different hardware aid packages).
Post by Michael Ole Olsen
- zsh
- lilo instead of grub
- lukssetup (crypt thing)
- ext3 instead of ext4
- Xfree86 instead of Xorg
- systemX instead of systemY
This part is already supported by debian-installer:

dpkg-query -l 'task-*'

Above command (or other more refined ones targeting same pattern)
invoked right after end of install provides you the "tasks" that was
installed, either as explicit choice or automatic defaults.

Sure those tasks don't cover the exact areas that you list above, but
the _mechanism_ exists - inviting you and anyone else to collaborate
with the debian-installer team to improve it. If you cannot contribute
with actual code, then you can suggest your wishlist of tasks to others
- ideally on a wiki page instead of only by email :-)
Post by Michael Ole Olsen
of course there is debootstrap too, but it would be cool if the debian
installer could be made like this too just dragdrop a list of
installpackages.txt into base of debian install CD
What you describe here is what some of us are working on as the term
"Debian Pure Blend", and your method - install one system, dump list of
installed packages, and use that as [starting point for refining] a
reusable "system profile" sounds quite similar to how my plans for the
"Boxer" tool which I recently added to Debian:

With Boxer you(r geeky friend) defines a set of classes - like the
current task-* metapackages or maybe more finegrained - and then you(r
less geeky friends) can create recipes from those classes to either feed
debian-installer or execute as a shell script after installation (for
e.g. virtual hosts with root access but bootstrapped differently than
using debian-installer).

A future goal of Boxer is to abstract further so that non-geeky use is
to point Boxer to your profile at Facebook (or a decentralized
equivalent that includes a FOAF profile) and suggest classes to enable
based on your topics of interest. My social profile would tell that I
speak danish, english and german, and that I like Midnight Commander,
travelling by train and geocaching - yours would be different, leading
to a different Debian installation better tailored you. :-)
Post by Michael Ole Olsen
debian-simplified
debian-for-sysadms
debian-for-geeks
debian-for-lilousers
debian-for-sysV-users
and many more custom installers (custompackage lists in wikis)
Just as the defaults of Debian, Debian Pure Blends are inherently
subjective, as is your sample blends above: what does "simplified"
imply? Do "geeks" imply LILO or not? Do "lilousers" imply geeks or not?

Have a look at the metapackages for debian-for-schools (debian-edu-*),
debian-for-kids (junior-*), debian-for-chemists (schience-chemistry)
etc. to learn which choices the developers of those blends made.

Have a look at the recent metapackages for debian-for-designers
(design-desktop-*) and debian-for-parliamentarians (parl-desktop-*), and
inspect their source packages for which Boxer classes they include. do
a "git clone git://anonscm.debian.org/boxer/boxer-data" and check if the
recent classes added cover your needs - and suggest additions at
<boxer-***@lists.alioth.debian.org>.

I warmly recommend to discuss further at the Debian Pure Blend Team
list, and have already Cc'ed that list and hinted at replying there.


Regards,

- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private
Tobias Frost
2014-11-13 16:22:18 UTC
Permalink
Post by Norbert Preining
Post by Bálint Réczey
https://np237.livejournal.com/34598.html
You lack any sense of humor, really!
Although I am a strong opponent of systemd, I had to laugh out loud
on that one, actually love it.
Sad to see people like you that are complete bare of any
acceptance for ironic, sarcastic humor.
Sometimes, a joke is just inappropriate, regardless how funny it may seem.
Sometimes, a joke is better not made, regardless how funny it is.

We have enough bad karma these days, no need to pour gasoline on the fires.

I assume we're all adults after all.
Thanks.


:(
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@isengard.geekcommandos.com
Gunnar Wolf
2014-11-13 22:28:18 UTC
Permalink
Post by Tobias Frost
Post by Norbert Preining
Post by Bálint Réczey
https://np237.livejournal.com/34598.html
You lack any sense of humor, really!
Sometimes, a joke is just inappropriate, regardless how funny it may seem.
Sometimes, a joke is better not made, regardless how funny it is.
We have enough bad karma these days, no need to pour gasoline on the fires.
I assume we're all adults after all.
Thanks.
Thanks, Tobias. And thanks, Bálint. I agree with you. Humor in Debian
is most often funny and welcome. But this specific topic has gone so
bitter that any bit of attempted humor can be read as a personal
attack. Joss, I don't think you meant ill by posting this message, but
it could not have had any possitive replies anyway!
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@gwolf.org
Scott Kitterman
2014-11-16 15:16:58 UTC
Permalink
Post by Tobias Frost
Post by Tobias Frost
Sometimes, a joke is just inappropriate, regardless how funny it may
seem.
Post by Tobias Frost
Sometimes, a joke is better not made, regardless how funny it is.
We have enough bad karma these days, no need to pour gasoline on the
fires.
Civility ism after all, so important to free speech
(http://www.popehat.com/2014/09/06/u-c-berkeley-chancellor-nicholas-dirks-gets-free-speech-very-wrong/).
I mean, people have the right not to be offended
(http://rationalwiki.org/wiki/Freedom_of_speech#Right_not_to_be_offended).
Post by Tobias Frost
I assume we're all adults after all.
Including the ones doing the reading?
Seriously. You are free to feel the joke was in poor taste. My stake in
this particular game is not deep enough for me to think so, but taste
is
a matter of opinion.
Which is precisely the point. Taste is a matter of opinion. Limiting
speech to only the things everyone agree are in good taste greatly
limits the speech (see first link for in depth explanation of why). I
don't think I'd like this forum to regress to that point.
I'd say more, but I just feel like I'm repeating what the two links I
provided are saying. I suggest we do, indeed, act like adults. Please
try to refrain from jokes other will find offending. If you see such a
joke, please try to refrain from stirring the fire by saying it's
wrong.
Just, you know, be adults...
The cure for inappropriate speech is more speech. Calling people on things that are inappropriate or that cause problems in the project is exactly the right thing to do. "Refrain from stirring the fire by saying it's wrong" is backwards.

Scott K
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/3C9D6BD2-2276-4B57-AC62-***@kitterman.com
Matthias Urlichs
2014-11-16 16:24:05 UTC
Permalink
Hi,
Post by Scott Kitterman
The cure for inappropriate speech is more speech.
This sentence lacks a necessary ingredient, i.e. the adjective
"appropriate" in front of the last word.
--
-- Matthias Urlichs
Shachar Shemesh
2014-11-17 18:47:00 UTC
Permalink
Post by Scott Kitterman
The cure for inappropriate speech is more speech. Calling people on things that are inappropriate or that cause problems in the project is exactly the right thing to do.
I was trying to point out the futility of trying to ask people to show
restraint, as calling a (subjectively) innocent joke offensive is every
bit as offensive as the original joke.
Post by Scott Kitterman
"Refrain from stirring the fire by saying it's wrong" is backwards.
Over a decade ago I worked for a company I will not name. Suffice it to
say it is a company producing firewalls. In the course of debugging one
feature, I managed to create a RST storm. It is the same as an ACK
storm[1], only with RST packets.

The discussion here reminds me of those times.

I am not telling anyone to shut up. Everyone are free to criticize
whatever and wherever. I am merely suggesting that shutting up might be
a smarter course of action.

Of course, I'm sure there are those who will find my mail offensive, and
will be most prudent in letting me, and everyone else, know about it. As
such, I promise to henceforth accept my own advice. This is my last
email on this thread.

Shachar
1 -
http://security.stackexchange.com/questions/49827/how-are-ack-storms-created-and-whats-a-good-mitigation-strategy-for-them
Stig Sandbeck Mathisen
2014-11-17 17:29:44 UTC
Permalink
Please try to refrain from jokes other will find offending.
That joke is in very poor taste, sir.
--
Stig Sandbeck Mathisen
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@dagon.fnord.no
Cameron Norman
2014-11-15 18:01:12 UTC
Permalink
Post by Bálint Réczey
Dear Josselin,
https://np237.livejournal.com/34598.html
I would like to ask you to resist the temptation of publishing similar posts.
It makes fun of part of our community which you are well aware of and
it also shows corpses which probably did not ring a bell in you.
None of those show good taste and by having it aggregated on
planet.debian.org it shows the whole project in bad light, too.
I disliked the post because I felt like it would create an annoying
and circular discussion, possibly on debian-devel.

Well look what happened... we went through about 50 sometimes long
messages, and maybe (maybe!) five were useful (thinking about the
syslog-ng bug found).

Can we please stop? Active Debian developers are considering just
leaving -devel because of discussions like these.

Thanks,
--
Cameron Norman
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/CALZWFR+pec6=sPec4wmT0+JRTWdd5�wbkT16m4qEULm-***@mail.gmail.com
Chris Bannister
2014-11-17 14:13:23 UTC
Permalink
Post by Bálint Réczey
Dear Josselin,
https://np237.livejournal.com/34598.html
I would like to ask you to resist the temptation of publishing similar posts.
It makes fun of part of our community which you are well aware of and
it also shows corpses which probably did not ring a bell in you.
Skeletons are *not* corpses.
--
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the
oppressing." --- Malcolm X
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@tal
Continue reading on narkive:
Loading...