On Sun, Jun 02, 2013 at 11:10:38AM +0200, Tollef Fog Heen wrote:
Since you repeat this claim: over the last year and a bit, systemd has
seen 21 releases. I agree this is quite a lot, but it's hardly twice a
week.
The number of Linux releases over the samer period is only about half that,
]] Salvo Tomaselli
In data sabato 01 giugno 2013 22.02.25, Uoti Urpala ha scritto:
So, to sum it up: Upstream systemd is ready for production and suitable
to be chosen as the default Debian init.
Can you back up your claim somehow?
Could we please not be having this discussion at this
FWIW, I happen to agree with Marc. Having everything in /etc makes it
*much* clearer what the actual current configuration is; it also means
that if the defaults change on upgrade, your environment doesn't
suddenly start acting differently or inconsistently.
If we want everything that makes
Le samedi 01 juin 2013 à 11:56 +0200, Marc Haber a écrit :
On Fri, 31 May 2013 14:08:01 +0200, Josselin Mouette j...@debian.org
I disagree with this claim. The wheezy release for kfreebsd is a joke,
and we should end it with jessie unless there are real users.
I find the way you're
Le samedi 01 juin 2013 à 11:59 +0200, Marc Haber a écrit :
Before saying things like that, please file a GR removing the
universal from Debian's claim.
Silly me. I thought “universal” was meant about usage, like the ability
to run the same OS on a supercomputer, a toaster, a smartphone and a
On 06/02/2013 04:25 PM, Josselin Mouette wrote:
Le samedi 01 juin 2013 à 11:59 +0200, Marc Haber a écrit :
Before saying things like that, please file a GR removing the
universal from Debian's claim.
Silly me. I thought “universal” was meant about usage, like the ability
to run the same OS on
On 02-06-13 16:09, Stuart Prescott wrote:
FWIW, I happen to agree with Marc. Having everything in /etc makes it
*much* clearer what the actual current configuration is; it also means
that if the defaults change on upgrade, your environment doesn't
suddenly start acting differently or
On Sat, Jun 01, 2013 at 03:39:44PM +0200, Salvo Tomaselli wrote:
They release twice a week or so. That is another sign of a software you
shouldn't rely on too much
You mean like, say, the Linux kernel?
Regards: David
--
/) David Weinehall t...@debian.org /) Rime on my window (\
On Sat, 1 Jun 2013 21:26:32 +0200, Ond?ej Surý ond...@sury.org
wrote:
We have removed archs from release archs and moved them to ports and nobody
claimed we are less universal.
I did. I still think it is a pity that we removed them.
Greetings
Marc
--
-- !!
On 2. 6. 2013, at 23:00, Marc Haber mh+debian-de...@zugschlus.de wrote:
On Sat, 1 Jun 2013 21:26:32 +0200, Ond?ej Surý ond...@sury.org
wrote:
We have removed archs from release archs and moved them to ports and nobody
claimed we are less universal.
I did. I still think it is a pity that
On Fri, 31 May 2013 14:08:01 +0200, Josselin Mouette j...@debian.org
wrote:
Le jeudi 30 mai 2013 à 22:25 +0200, Marc Haber a écrit :
Do you actually run a kernel other than Linux
Actually no, but it is a pleasure to see Debian move towards this
freedom with every new release.
I disagree
On Fri, 31 May 2013 16:33:22 +0200, m...@linux.it (Marco d'Itri) wrote:
On May 31, Jeff Epler jep...@unpythonic.net wrote:
The idea that somehow users of non-linux kernels don't matter or don't
even exist as debian users is one of the most frustrating bits of this
whole thread.
I'm sorry for
]] Roger Lynn
I prefer to be notified of changes to configuration files during upgrades so
that I know which configurations need updating, rather than just hoping that
the old config will work with the updated package and missing out on any new
options silently introduced in a master
On 06/01/2013 11:59 AM, Marc Haber wrote:
Before saying things like that, please file a GR removing the
universal from Debian's claim.
Calm down. Debian has been called universal long before the arrival
of the non-Linux kernels. And, in fact, Marco and Joss have a point
that if hardly anyone
You have the context wrong here. considering systemd as a default init
is too vague.
Wikipedia says: A default, in computer science, refers to a setting or a value
automatically assigned to a software application, computer program or device,
outside of user intervention.
What's vague about
On Sat, 01 Jun 2013 12:42:33 +0200, John Paul Adrian Glaubitz
glaub...@physik.fu-berlin.de wrote:
What's the point in doing that work
when, in the end, hardly anyone is using it?
Freedom. It is not free to take away freedom just because too few
people have chosen to exercise freedom.
Greetings
On 06/01/2013 04:48 PM, Marc Haber wrote:
On Sat, 01 Jun 2013 12:42:33 +0200, John Paul Adrian Glaubitz
glaub...@physik.fu-berlin.de wrote:
What's the point in doing that work
when, in the end, hardly anyone is using it?
Freedom. It is not free to take away freedom just because too few
people
Salvo Tomaselli wrote:
You have the context wrong here. considering systemd as a default init
is too vague.
Wikipedia says: A default, in computer science, refers to a setting or a
value
automatically assigned to a software application, computer program or device,
outside of user
Ondřej Surý
On 1. 6. 2013, at 11:59, Marc Haber mh+debian-de...@zugschlus.de wrote:
On Fri, 31 May 2013 16:33:22 +0200, m...@linux.it (Marco d'Itri) wrote:
On May 31, Jeff Epler jep...@unpythonic.net wrote:
The idea that somehow users of non-linux kernels don't matter or don't
even exist
On 1. 6. 2013, at 16:48, Marc Haber mh+debian-de...@zugschlus.de wrote:
On Sat, 01 Jun 2013 12:42:33 +0200, John Paul Adrian Glaubitz
glaub...@physik.fu-berlin.de wrote:
What's the point in doing that work
when, in the end, hardly anyone is using it?
Freedom. It is not free to take away
On 30-05-13 22:36, Uoti Urpala wrote:
Russ Allbery wrote:
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
Marc Haber wrote:
And it is still completely inferior even to dpkg-conffile handling,
which has huge wishes left open as well.
False. The message you replied to already listed advantages
Marc Haber wrote:
On Sat, 01 Jun 2013 12:42:33 +0200, John Paul Adrian Glaubitz
glaub...@physik.fu-berlin.de wrote:
What's the point in doing that work
when, in the end, hardly anyone is using it?
Freedom. It is not free to take away freedom just because too few
people have chosen to
On Sat, Jun 01, 2013 at 09:44:05PM +0200, Wouter Verhelst wrote:
FWIW, I happen to agree with Marc. Having everything in /etc makes it
*much* clearer what the actual current configuration is; it also means
that if the defaults change on upgrade, your environment doesn't
suddenly start acting
On Sat, 2013-06-01 at 22:57 +0300, Uoti Urpala wrote:
Marc Haber wrote:
On Sat, 01 Jun 2013 12:42:33 +0200, John Paul Adrian Glaubitz
glaub...@physik.fu-berlin.de wrote:
Why would kFreeBSD particularly matter for freedom? As opposed to any
other random piece of software?
Debian
In data sabato 01 giugno 2013 22.02.25, Uoti Urpala ha scritto:
So, to sum it up: Upstream systemd is ready for production and suitable
to be chosen as the default Debian init.
Can you back up your claim somehow?
You mixed up these two things (you also talked
about use in Fedora, which
Wouter Verhelst wrote:
On 30-05-13 22:36, Uoti Urpala wrote:
While there is room for reasonable disagreement about the relative
benefits of different configuration setups, completely inferior even to
dpkg-conffile handling is not part of any reasonable disagreement. That
claim is simply
Svante Signell wrote:
On Sat, 2013-06-01 at 22:57 +0300, Uoti Urpala wrote:
Debian regularly removes old buggy packages that few people use. Are you
saying that is wrong, and for the sake of freedom people should be given
the ability to keep installing them even if few actually want to? If
On Sun 02 Jun 2013 01:12:43 Uoti Urpala wrote:
Also, these issues were already covered in the thread a year ago (and
your post doesn't look like you'd have understood the arguments
there but disagreed).
Your quality advocacy work for upstart is almost as good as Rob Weir's
incessant efforts
On Fri, May 31, 2013 at 01:44:12AM +0300, Uoti Urpala wrote:
Steve Langasek wrote:
I can't speak to other distributions, but in Debian, the systemd maintainers
are in no position to decide that Debian will agree to rewrite its
Focusing on position to decide seems less than constructive.
I
On Thu, May 30, 2013 at 01:59:02PM -0700, Steve Langasek wrote:
I can't speak to other distributions, but in Debian, the systemd maintainers
are in no position to decide that Debian will agree to rewrite its
system-level integration code (which works quite well already,
I meant more that:
-
On Thu, May 30, 2013 at 10:26:37PM +0200, Marc Haber wrote:
Of course it won't. Upstream and Red Hat have shown many times that
they just don't care.
I've already replied with various examples before refuting this.
--
Regards,
Olav
--
To UNSUBSCRIBE, email to
Le jeudi 30 mai 2013 à 22:25 +0200, Marc Haber a écrit :
Do you actually run a kernel other than Linux
Actually no, but it is a pleasure to see Debian move towards this
freedom with every new release.
I disagree with this claim. The wheezy release for kfreebsd is a joke,
and we should end
Helmut Grohne wrote:
On Fri, May 31, 2013 at 01:44:12AM +0300, Uoti Urpala wrote:
Steve Langasek wrote:
I can't speak to other distributions, but in Debian, the systemd
maintainers
are in no position to decide that Debian will agree to rewrite its
Focusing on position to decide
On Fri, May 31, 2013 at 02:08:01PM +0200, Josselin Mouette wrote:
I disagree with this claim. The wheezy release for kfreebsd is a joke,
and we should end it with jessie unless there are real users.
What makes me other than a real user? Perhaps some users of Debian
are more equal^Wreal than
On Thu, May 30, 2013 at 09:05:50PM +0200, Olav Vitters wrote:
Do you actually run a kernel other than Linux and is anything other than
Linux usable? I can understand it is not nice, but feels like the other
options are bitrotting anyway.
Yes and yes. Wheezy kfreebsd amd64 is dandy for server
2013/5/31 Jeff Epler jep...@unpythonic.net:
Yes and yes. Wheezy kfreebsd amd64 is dandy for server and OK for some
minor graphical desktop stuff (opengl is not in a good state right now,
at least with nvidia hardware: nouveau is no-go due to not having kernel
support and proprietary won't
On May 31, Jeff Epler jep...@unpythonic.net wrote:
The idea that somehow users of non-linux kernels don't matter or don't
even exist as debian users is one of the most frustrating bits of this
whole thread.
I'm sorry for the three kfreebsd users, but sometimes reality sucks.
Pretending that
On Fri, May 31, 2013 at 08:53:07AM -0500, Jeff Epler wrote:
The idea that somehow users of non-linux kernels don't matter or don't
even exist as debian users is one of the most frustrating bits of this
whole thread.
I was just curious, not suggesting. I also asked this on an IRC channel
and
On 05/28/2013 02:37 PM, Helmut Grohne wrote:
On Mon, May 27, 2013 at 09:13:44AM +0200, Ond??ej Surý wrote:
I would be quite happy to write service files for two (systemd, upstart) or
three (systemd, upstart, openrc) of those in all my packages[*], if it
stops the endless flamewar here. I would
On 31. 5. 2013, at 15:53, Jeff Epler jep...@unpythonic.net wrote:
The idea that somehow users of non-linux kernels don't matter or don't
even exist as debian users is one of the most frustrating bits of this
whole thread.
I would happily support any non-linux kernel arch in form of integrating
Thomas Goirand z...@debian.org writes:
On 05/28/2013 02:37 PM, Helmut Grohne wrote:
My major point here was precisely that you are *not* done with just
writing the service/job descriptions/scripts for all those init
systems. You'd likely have to patch every single daemon to enable the
On Fri, May 31, 2013 at 06:12:38PM +0200, Ondřej Surý wrote:
On 31. 5. 2013, at 15:53, Jeff Epler jep...@unpythonic.net wrote:
The idea that somehow users of non-linux kernels don't matter or don't
even exist as debian users is one of the most frustrating bits of this
whole thread.
I
On Fri, May 31, 2013 at 06:12:38PM +0200, Ondřej Surý wrote:
That doesn't mean the toys are not important (...all work and no
play...), they are, but they must not stop the inovation. And as we
have sacrificed niche architecture and made them non-release, we must
be also prepared to do the
On Fri, May 31, 2013 at 04:45:49PM +0300, Uoti Urpala wrote:
This
is more true for the socket activation API that systemd could have
reasonably adopted from upstart, but chose not to do.
Didn't systemd actually have a socket activation API before upstart? I
don't remember exactly, but
On Fri, 2013-05-31 at 08:59 -0500, Jeff Epler wrote:
On Fri, May 31, 2013 at 02:08:01PM +0200, Josselin Mouette wrote:
I disagree with this claim. The wheezy release for kfreebsd is a joke,
and we should end it with jessie unless there are real users.
What makes me other than a real user?
Ah, sorry wrong book: Animal farm, by the same author George Orwell: :)
1984 is about big brother watching you. (of course both very recommended
these days)
On Fri, 2013-05-31 at 21:06 +0200, Svante Signell wrote:
On Fri, 2013-05-31 at 08:59 -0500, Jeff Epler wrote:
On Fri, May 31, 2013 at
On Fri, 2013-05-31 at 16:33 +0200, Marco d'Itri wrote:
On May 31, Jeff Epler jep...@unpythonic.net wrote:
The idea that somehow users of non-linux kernels don't matter or don't
even exist as debian users is one of the most frustrating bits of this
whole thread.
I'm sorry for the three
On 30/05/13 16:30, Matthias Klumpp wrote:
2013/5/30 Marco d'Itri m...@linux.it:
The /etc/ /lib/ /usr/lib/ split with files overriding each other,
invented because RPM systems do not prompt the user on package upgrades
and Red Hat does not support upgrading to the next major release.
Well,
Dear upstart developers,
debian-devel@l.d.o has been talking about socket activation interfaces.
The technical differences are nicely summarized:
On Fri, May 31, 2013 at 08:53:52PM +0200, Zbigniew J??drzejewski-Szmek wrote:
But chronology is less important then the technical differences between
On Fri, 31.05.13 23:31, Helmut Grohne (hel...@subdivi.de) wrote:
debian-devel@l.d.o has been talking about socket activation interfaces.
The technical differences are nicely summarized:
On Fri, May 31, 2013 at 08:53:52PM +0200, Zbigniew J??drzejewski-Szmek wrote:
But chronology is less
On Wed, May 29, 2013 at 09:10:41PM +0200, Wouter Verhelst wrote:
This kind of madness is precisely described here:
http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html
[zillionth link to linux is not about choice mail]
Because it's a very good read, still years later. It
This is stockholm syndromish - because Debian is held behind times by
lack of decision making, we start finding good things in being behind.
Do you realize that fedora is the beta version for red hat? They use the
community to get free testing for their commercial product.
Personally as a
On 2013-05-30, Riku Voipio riku.voi...@iki.fi wrote:
By switching early we can affect how a piece of software will evolve.
Is there something you would like to change in systemd? Now it still
probably possible - 2 years from now it has shipped in RHEL, and books
will have been written about it
On Wed, 29 May 2013 21:10:41 +0200, Wouter Verhelst
wou...@debian.org wrote:
At Debian, traditionally we support more than one choice (at least for a
while), until the community at large decides that option X is the best
one (and then we drop support for all the other options). The downside
of
On Thu, 30 May 2013 11:46:51 +0300, Riku Voipio riku.voi...@iki.fi
wrote:
By switching early we can affect how a piece of software will evolve.
This is the case with software that has a cooperative upstream.
systemd's upstream is known not to be.
Greetings
Marc
--
On Thu, 30 May 2013 11:38:22 +0200, Salvo Tomaselli wrote:
I have tried systemd, and I like the approach it has, and in a few years
I believe it has potential. But... using it to restart my computer i
need to do an hard reset (and think of how happy would I be if my
computer had been a server
Marc Haber mh+debian-de...@zugschlus.de writes:
On Thu, 30 May 2013 11:46:51 +0300, Riku Voipio riku.voi...@iki.fi
wrote:
By switching early we can affect how a piece of software will evolve.
This is the case with software that has a cooperative upstream.
systemd's upstream is known not to
On Thu, May 30, 2013 at 12:22:34PM +0200, Marc Haber wrote:
This is the case with software that has a cooperative upstream.
systemd's upstream is known not to be.
I've seen as well as attended various conferences where systemd was
explained. There have also been various systemd specific events.
On Thu, May 30, 2013 at 12:21:33PM +0200, Marc Haber wrote:
The init system case is special because supporting another init script
system will most probably mean that all packages delivering an init
script ($ ls /etc/init.d/ | wc -l = 116 on my small notebook system)
will have to adapt. This
On May 30, Gergely Nagy alger...@balabit.hu wrote:
I never quite understood why people seem to think systemd upstream is
uncooperative (well, apart from the whole non-linux porting deal, where
their stance is completely understandable too). My experience so far
There is also the kill features
(I'm afraid to feed the troll)
2013/5/30 Marco d'Itri m...@linux.it:
On May 30, Gergely Nagy alger...@balabit.hu wrote:
I never quite understood why people seem to think systemd upstream is
uncooperative (well, apart from the whole non-linux porting deal, where
their stance is completely
Salvo Tomaselli wrote:
I have tried systemd, and I like the approach it has, and in a few years I
believe it has potential. But... using it to restart my computer i need to do
an hard reset (and think of how happy would I be if my computer had been a
server in a rack on the other side of
Mathieu Parent wrote:
2013/5/30 Marco d'Itri m...@linux.it:
and the invent a new a configuration files scheme because it better
suits RPM and Red Hat policies deal.
Do you have an example?
I think he's referring to the etc-overrides-lib semantics that systemd
uses for configuration files.
On Thu, May 30, 2013 at 04:50:15PM +0300, Uoti Urpala wrote:
Do you have any reason at all to believe that these were problems with
systemd, rather than problems in Debian configuration or mostly
independent bugs in other software that happened to trigger under
systemd?
Whether or not systemd
On May 30, Mathieu Parent math.par...@gmail.com wrote:
(I'm afraid to feed the troll)
Hint: before accusing somebody of trolling it is a good idea to find out
who he is.
There is also the kill features Red Hat does not care about deal,
Do you have an example?
Persistent naming of network
2013/5/30 Marco d'Itri m...@linux.it:
On May 30, Mathieu Parent math.par...@gmail.com wrote:
(I'm afraid to feed the troll)
Hint: before accusing somebody of trolling it is a good idea to find out
who he is.
I apologize.
--
Mathieu
--
To UNSUBSCRIBE, email to
2013/5/30 Marco d'Itri m...@linux.it:
On May 30, Mathieu Parent math.par...@gmail.com wrote:
[···]
There is also the kill features Red Hat does not care about deal,
Do you have an example?
Persistent naming of network interfaces.
... is entirely optional, and can be disabled if someone
Jonathan Dowland wrote:
On Thu, May 30, 2013 at 04:50:15PM +0300, Uoti Urpala wrote:
Do you have any reason at all to believe that these were problems with
systemd, rather than problems in Debian configuration or mostly
independent bugs in other software that happened to trigger under
On Thu, 30 May 2013 17:07:08 +0200, Matthias Klumpp m...@debian.org
wrote:
So, this is not really RHEL specific, and some other non-RH software
also has this scheme of storing config files.
And it is still completely inferior even to dpkg-conffile handling,
which has huge wishes left open as
On Thu, 30 May 2013 14:16:53 +0200, Olav Vitters o...@vitters.nl
wrote:
On Thu, May 30, 2013 at 12:21:33PM +0200, Marc Haber wrote:
The init system case is special because supporting another init script
system will most probably mean that all packages delivering an init
script ($ ls
On Thu, May 30, 2013 at 04:35:07PM +0200, Marco d'Itri wrote:
On May 30, Mathieu Parent math.par...@gmail.com wrote:
Do you have an example?
The /etc/ /lib/ /usr/lib/ split with files overriding each other,
invented because RPM systems do not prompt the user on package upgrades
and Red Hat
Matthias Klumpp wrote:
013/5/30 Marco d'Itri m...@linux.it:
On May 30, Mathieu Parent math.par...@gmail.com wrote:
[···]
There is also the kill features Red Hat does not care about deal,
Do you have an example?
Persistent naming of network interfaces.
... is entirely optional, and can
Marc Haber wrote:
On Thu, 30 May 2013 17:07:08 +0200, Matthias Klumpp m...@debian.org
wrote:
So, this is not really RHEL specific, and some other non-RH software
also has this scheme of storing config files.
And it is still completely inferior even to dpkg-conffile handling,
which has huge
On 05/30/2013 03:10 AM, Wouter Verhelst wrote:
I think it makes perfect sense for us to support systemd, openrc, and
upstart, at least for the time being; I doubt we'll continue supporting
all three options until the end of times, but we don't have to do that.
I very much like the idea to give
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
Marc Haber wrote:
And it is still completely inferior even to dpkg-conffile handling,
which has huge wishes left open as well.
False. The message you replied to already listed advantages over
dpkg-conffile handling. This was also already discussed
On 30-05-13 19:53, Thomas Goirand wrote:
On 05/30/2013 04:46 PM, Riku Voipio wrote:
While we are busy maintaining multiple indirection layers to
support user choice
I don't think this is what Wouter was talking about (eg, he never said
we should leave this as a choice to the user). He's
On Thu, May 30, 2013 at 06:27:13PM +0200, Marc Haber wrote:
On Thu, 30 May 2013 14:16:53 +0200, Olav Vitters o...@vitters.nl
wrote:
On Thu, May 30, 2013 at 12:21:33PM +0200, Marc Haber wrote:
The init system case is special because supporting another init script
system will most probably
On Thu, 30 May 2013 21:05:50 +0200, Olav Vitters o...@vitters.nl
wrote:
On Thu, May 30, 2013 at 06:27:13PM +0200, Marc Haber wrote:
And I am also opposing changes that will help in dropping the
universal out of Debian's claim.
Do you actually run a kernel other than Linux
Actually no, but it
On Fri, 31 May 2013 01:53:01 +0800, Thomas Goirand z...@debian.org
wrote:
Though, I'm really not sure that if Debian decides to adopt Systemd now,
rather than a bit later, it will influence its development, or change
anything at all upstream.
Of course it won't. Upstream and Red Hat have shown
Russ Allbery wrote:
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
Marc Haber wrote:
And it is still completely inferior even to dpkg-conffile handling,
which has huge wishes left open as well.
False. The message you replied to already listed advantages over
dpkg-conffile handling. This
On Thu, May 30, 2013 at 09:05:50PM +0200, Olav Vitters wrote:
The goal is to make the boot more standard across distributions. So no
unneeded differences in some configuration files, systemd conf files
which are generic enough to be included upstream, etc.
In the current state, each
Steve Langasek wrote:
I'm assuming you're talking here about things like /etc/default/locale and
/etc/default/keyboard, which systemd upstream fails to handle.
I can't speak to other distributions, but in Debian, the systemd maintainers
are in no position to decide that Debian will agree to
On 27-05-13 21:56, Josselin Mouette wrote:
Le lundi 27 mai 2013 à 09:13 +0200, Ondřej Surý a écrit :
I would be quite happy to write service files for two (systemd,
upstart) or three (systemd, upstart, openrc) of those in all my
packages[*], if it stops the endless flamewar here. I would also
On Mon, May 27, 2013 at 09:13:44AM +0200, Ond??ej Surý wrote:
I would be quite happy to write service files for two (systemd, upstart) or
three (systemd, upstart, openrc) of those in all my packages[*], if it
stops the endless flamewar here. I would also be happy to have the
requirement to
On Sun, May 26, 2013 at 10:27:53PM +, brian m. carlson wrote:
At the risk of adding another level of indirection, we could add a
meta-init format that can generate an appropriate file for any of these.
Are you aware of http://wiki.debian.org/MetaInit (packages metainit and
dh-metainit)?
2013/5/27 brian m. carlson sand...@crustytoothpaste.net:
At the risk of adding another level of indirection, we could add a
meta-init format that can generate an appropriate file for any of these.
http://xkcd.com/927/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a
On Sun, May 26, 2013 at 10:29 PM, Helmut Grohne hel...@subdivi.de wrote:
I find it depressing to see four init/rc systems, of which three are
mutually incompatible in every single possible aspect.
Just my two cents.
I would be quite happy to write service files for two (systemd, upstart) or
Hi,
On 27/05/13 at 09:13 +0200, Ondřej Surý wrote:
On Sun, May 26, 2013 at 10:29 PM, Helmut Grohne hel...@subdivi.de wrote:
I find it depressing to see four init/rc systems, of which three are
mutually incompatible in every single possible aspect.
Just my two cents.
I would be
Well,
each init system has it's proponents, so they can provide support (in form
of patches) for those tightly-tied package.
E.g. adopt an approach similar to our archs, setup some criteria[*] for
supporting the init system and either it can keep up and fullfil the
criteria or it won't and we
On Mon, May 27, 2013 at 08:38:44AM +0200, Helmut Grohne wrote:
On Sun, May 26, 2013 at 10:27:53PM +, brian m. carlson wrote:
At the risk of adding another level of indirection, we could add a
meta-init format that can generate an appropriate file for any of these.
Are you aware of
Игорь Пашев pashev.i...@gmail.com writes:
2013/5/27 brian m. carlson sand...@crustytoothpaste.net:
At the risk of adding another level of indirection, we could add a
meta-init format that can generate an appropriate file for any of
these.
http://xkcd.com/927/
Also:
All problems in
Ondřej Surý ond...@sury.org writes:
I would be quite happy to write service files for two (systemd, upstart)
or three (systemd, upstart, openrc) of those in all my packages[*], if
it stops the endless flamewar here. I would also be happy to have the
requirement to support two (or three) of
On Mon, May 27, 2013 at 8:30 PM, Russ Allbery r...@debian.org wrote:
Ondřej Surý ond...@sury.org writes:
I would be quite happy to write service files for two (systemd, upstart)
or three (systemd, upstart, openrc) of those in all my packages[*], if
it stops the endless flamewar here. I
Le lundi 27 mai 2013 à 09:13 +0200, Ondřej Surý a écrit :
I would be quite happy to write service files for two (systemd,
upstart) or three (systemd, upstart, openrc) of those in all my
packages[*], if it stops the endless flamewar here. I would also be
happy to have the requirement to
❦ 27 mai 2013 08:38 CEST, Helmut Grohne hel...@subdivi.de :
At the risk of adding another level of indirection, we could add a
meta-init format that can generate an appropriate file for any of these.
Are you aware of http://wiki.debian.org/MetaInit (packages metainit and
dh-metainit)? That
On Sat, May 25, 2013 at 10:42:09PM +0800, Thomas Goirand wrote:
On 05/23/2013 03:14 PM, Helmut Grohne wrote:
I partly disagree here. A good reason to reimplement part of systemd is
to have a portable subset of its functionality. This could be part of
the answer to the question of what to do
On Sun, May 26, 2013 at 10:29:25PM +0200, Helmut Grohne wrote:
I find it depressing to see four init/rc systems, of which three are
mutually incompatible in every single possible aspect.
At the risk of adding another level of indirection, we could add a
meta-init format that can generate an
On 05/23/2013 03:14 PM, Helmut Grohne wrote:
On Thu, May 23, 2013 at 07:16:18AM +0200, Zbigniew J??drzejewski-Szmek wrote:
Providing a conversion script which recreates all of systemd
functionality would basically mean reimplemting a big part of
systemd in shell. Providing an interpeter would
* Helmut Grohne:
* supervision/service restart/heartbeat
sysv simply does not provide this functionality.
Actually, it does, through /etc/inittab. But this capability is
rarely used.
Curiously, Fedora doesn't use systemd's service restart functionality
much, either. (By default, systemd
2013/5/23 Helmut Grohne hel...@subdivi.de:
* stdout/stderr to syslog redirection
This is possibly implementable, but needs more than a line of shell.
In Solaris SMF each service has its own log file with SMF messages
*and* all stdout/stderr
pashev@bok:~$ find /var/log/svc/
/var/log/svc/
1 - 100 of 106 matches
Mail list logo
