Paul Tagliamonte wrote:
On Fri, Oct 25, 2013 at 01:40:55PM +0200, Olav Vitters wrote:
I don't see this happening, at all. When the GNOME release team is asked
for a solution we make *concrete* decisions: use X, or Y or maybe try
and support both. If you want to influence these decisions, I
Russ Allbery wrote:
Bastien beudart bastienbeud...@gmail.com writes:
It seems that the tech committee is composed of two well known ubuntu
developers. Isn't that biased? I mean do you see them voting against
upstart, I know that the decision should be based around technical
facts, but
Jonathan Dowland wrote:
Whilst I think you have honourable intentions in referring this to tech-ctte,
I can't help but think it's premature.
The systemd maintainers have never said that they believe systemd is ready to
be the default init nor whether they could handle supporting it if the
Colin Watson wrote:
I've done some work on Upstart itself and a good deal more designing
subsystems around it; no doubt that experience will have a bearing on my
vote. The other Technical Committee members will also surely bring
relevant experience of one kind or another to the table, as
Scott Kitterman wrote:
Unless there's some kind of disclosure policy for everyone involved in the
any
technical discussion around Debian,
CTTE decisions are quite distinct from any technical discussion.
I think it's silly to claim Steve and
Colin are inherently unable to separate what's
Brian May wrote:
As much as I would like to see systemd as the default in Debian (and
have switched to it on my Desktops), I see two show stopper issues:
* Needs to work (somehow) with other applications (including not in
Debian) that need to manage cgroups. In Debian this would include
Thomas Goirand wrote:
We've been reading again and again from systemd supporters that it's
modular, and that we can use only a subset of it if we like. Now, we're
reading a very different thing: that it's modular *but* we need to
re-implement every bit of it so that the modularity becomes
Russ Allbery wrote:
Christoph Anton Mitterer cales...@scientia.net writes:
In sid, gnome-settings-daemon depends now on systemd.
I'm missing a key bit of context here. Does gnome-settings-daemon just
require that systemd be installed? Or does it require that the init
system be systemd?
Steve Langasek wrote:
On Thu, Oct 24, 2013 at 09:47:52AM +1100, Brian May wrote:
If Gnome depends on gnome-settings-daemon, which now depends on systemd,
this might be a worrying trend, as non-Linux kernels don't support systemd.
Well, that's one more reason the init system and the dbus
Steve Langasek wrote:
On Thu, Oct 24, 2013 at 02:21:25AM +0200, Matthias Klumpp wrote:
2013/10/24 Steve Langasek vor...@debian.org:
[...]
If Gnome depends on gnome-settings-daemon, which now depends on systemd,
this might be a worrying trend, as non-Linux kernels don't support
Steve M. Robbins wrote:
On September 21, 2013 09:04:23 PM Bernhard R. Link wrote:
The whole point of undefined behaviour in C is that the
compiler/implementor/... does not have to care.
I strongly suspect the whole point of undefined behaviour is simply that at
least two parties on the
Russ Allbery wrote:
Kay Sievers k...@vrfy.org writes:
Hmm, why would upgrades break?
The old file would still be there, rename the devices (if you keep the
patch to swap names, which upstream does not support any more), and take
precedence over tht new names; the old rules file would
Ansgar Burchardt wrote:
In comparison the changing part of unstable:
$ du -shc dists/unstable/*/{binary-*,source,Contents*.gz} | tail -1
665Mtotal
So having two dinstall runs per day compared to four would reduce the
amount of changes by roughly 1.3 GB per day. Mirrors also
Ben Hutchings wrote:
But you don't actually want that behaviour. You cannot assume anything
about the order in which net devices are created and therefore you still
need rules for persistent names unless your machines have only one
Ethernet(-like) interface (the usual VM case).
You'll need
brian m. carlson wrote:
On Mon, Jul 22, 2013 at 07:17:04PM +0300, Uoti Urpala wrote:
If you don't do development, and nobody sharing your views does either,
then there's a limit to the extent you can choose your direction just by
refusing to follow those that do develop things further. You
brian m. carlson wrote:
On Mon, Jul 22, 2013 at 02:59:20AM +0300, Uoti Urpala wrote:
Whether your argument was honest or not, I think it was a bad one. OK,
perhaps you have concerns about the philosophy behind systemd and where
that might take it in the future. Such philosophy issues
The Wanderer wrote:
On 07/21/2013 05:04 PM, Josselin Mouette wrote:
Le samedi 20 juillet 2013 à 19:21 -0400, The Wanderer a écrit :
Making the switch away from the entrenched sysvinit is visibly very
difficult, at least as a social matter, even in the environment we
have. systemd et al.,
Scott Kitterman wrote:
On Friday, July 19, 2013 06:35:48 PM John Paul Adrian Glaubitz wrote:
On 07/19/2013 06:12 PM, Mathieu Parent wrote:
systemd is used regulardly on about 1200 popcon submiters, upstart
on about 600 (this is even less than 100 from 2013-07-04, but what
happened!).
Russ Allbery wrote:
John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes:
Popcon however speaks a completely different language:
http://qa.debian.org/popcon.php?package=upstart
http://qa.debian.org/popcon.php?package=systemd
Currently 64 counted installations for upstart
Steve Langasek wrote:
You misunderstand me. I'm not upset about anything - I'm merely pointing
out that Lennart is an unreliable source where claims of
production-readiness are concerned. Ubuntu may have fallen for his
silver-tongued sales pitch back in 2007, but there's no reason Debian
David Weinehall wrote:
OK, I'll instead quote what Linus wrote in the link I posted:
The version 2 of the License, or (at your option) any later
version language in the GPL copying file is not - and has never
been - part of the actual License itself. It's part of the
As far
David Weinehall wrote:
On Fri, Jul 05, 2013 at 04:14:57PM +0300, Uoti Urpala wrote:
[snip]
a post from Alan Cox explaining this. I don't see why you would post
your link again in full quote after that without explaining why you
still thought Linus wasn't wrong.
I posted it fully because
Michael Stapelberg wrote:
Ondřej Surý ond...@sury.org writes:
I still think you should also update the table with information if the
library is actually used in PID 1 (or in forked process) as hmh suggested:
It would be best to enhance
Daniel Pocock wrote:
It was also demonstrated with Windows 7 that users could be tricked by
web sites that simply dimmed the background of the browser window - so
it is not a perfect solution and I would personally prefer to see users
referred to initiate su or sudo on their own.
Initiate su
Thomas Goirand wrote:
On 06/11/2013 02:23 AM, Henrique de Moraes Holschuh wrote:
On Mon, 10 Jun 2013, Thomas Goirand wrote:
Then which component would you install, and activate by default? Which
component will you make only installable if the user decides to do it
actively (for example
Russ Allbery wrote:
There's really no reason to have something like an /etc/default setting
for that, the way there is for the rsyncd init script. You can just edit
that directly (well, it's systemd, so you have to copy it into /etc and
make a new version and then won't know if anything about
Zygmunt Krynicki wrote:
W dniu sob, cze 1, 2013 o 12:52 ,nadawca John Paul Adrian Glaubitz
glaub...@physik.fu-berlin.de napisał:
On 06/01/2013 12:24 PM, Vincent Bernat wrote:
I don't know how systemd behaves in this way (so this is not
something to hold against upstart),
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
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
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
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
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.
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
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
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
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
Lucas Nussbaum wrote:
I went through the various init systems threads again during the last
few days. My understanding of the consensus so far is the following:
- Both systemd and upstart bring many useful features, and are a
clear improvement over sysvinit.
Yes, both are an improvement
Josselin Mouette wrote:
Hi10p is a useless hack that makes videos unreadable with hardware
acceleration. I wouldn’t recommend using it in the general case. The
The useless hack part is false. 10-bit H264 is a clear improvement in
video compression for some types of videos. Existing hardware
Bill Allombert wrote:
On Sat, Apr 27, 2013 at 08:55:28AM +0200, Ondřej Surý wrote:
P.S.: You still haven't answered my questions in the previous email. I
don't think they are unreasonable.
Let start with the beginning:
I became the maintainer of libjpeg62 in November 2001, the package
Helmut Grohne wrote:
On Sat, Apr 20, 2013 at 04:44:08AM +0300, Uoti Urpala wrote:
3) P runs a script using system interpreter X, and depends on the
interpreter environment supporting functionality provided by Q.
Q needs to work for the arch matching installed version of X.
P (all
Helmut Grohne wrote:
You point out a limitation that I'd consider to be a feature. My
proposal requires that every package has a single set of running
architectures that has to apply to all code contained.
Should that set of running architectures be just architecture?
I think that after
Helmut Grohne wrote:
Barring any mistakes this appears like a possible solution to the
problem. Did you spot anything obviously wrong? Any example where you
don't see how to work it out?
It seems correct at first glance, but not enough to solve all the issues
mentioned. Currently existing
Samuel Thibault wrote:
Uoti Urpala, le Mon 01 Apr 2013 05:12:46 +0300, a écrit :
Distributions that make latest
software available are necessary for free software development.
Again, that's one of the things experimental is for.
It is not. You can't reasonably install things from
Neil McGovern wrote:
On Mon, Apr 01, 2013 at 02:38:51PM +0300, Uoti Urpala wrote:
It is unreasonable to tell the users and upstreams that Debian is
going to keep users on a known inferior version by default for a long
time, just in case more testing is needed to discover problems
Philipp Kern wrote:
On Sun, Mar 31, 2013 at 12:33:46PM -0500, Dirk Eddelbuettel wrote:
I cannot influence the R release cycle which happens within our freeze. As
have a few previous R releases, and none of those created any trouble.
Thanks for trading the R release cycle with Debian's and
Neil Williams wrote:
On Mon, 01 Apr 2013 00:48:08 +0300
Uoti Urpala uoti.urp...@pp1.inet.fi wrote:
Philipp Kern wrote:
Thanks for trading the R release cycle with Debian's and for delaying the
IMO it's important to remember that it's fundamentally the release team
that is at fault
Scott Kitterman wrote:
If I'm reading you correctly, you seem to believe that creating the release
is
somehow the release team's job. It's not. The job belongs to all of us.
No, that's not what I'm saying. But I think the release team is
primarily responsible for the policies that harm the
Russ Allbery wrote:
Adam Borowski kilob...@angband.pl writes:
There are two ways to design a system:
* a monolithic well-integrated system, granting features and efficiency at
the cost of portability and hackability
* the traditional Unix way, with a stress on replaceable tools that
Petter Reinholdtsen wrote:
When /usr/ is a LVM partition, this block LVM from being
shut down, and leave /usr/ in a dirty state and LVM not properly shut
down before poweroff.
Why would this be harder to support than having / itself on LVM? Or are
you saying the latter need not be supported?
Russ Allbery wrote:
John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes:
Yes, I do accept vocals against systemd, but only if these are actually
valid arguments. Because I want software development to be driven on
technical merits and not on sympathies against or for certain
Russ Allbery wrote:
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
Russ Allbery wrote:
Free software is a social activity. The past history of qmail should
be informative here (or, for that matter, both gcc and glibc, which had
to go through disruptive forks to sort out long-term issues
Andrej N. Gritsenko wrote:
John Paul Adrian Glaubitz has written on Friday, 30 November, at 1:04:
Absolutely true. And this is actually why I don't understand so many
people get so emotional when it comes to software like systemd or
Pulse-Audio.
Well, without any emotions. In last 2
Russ Allbery wrote:
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
Would you expect anyone who thinks such activity is not useful to help
with it? This would seem to lead to the absurd conclusion that
expressing a negative view/evaluation of anything would always be just
noise, regardless
Chow Loong Jin wrote:
On 30/11/2012 10:16, Uoti Urpala wrote:
However, current PulseAudio is still quite buggy. But I wouldn't place
Is it, really? I haven't noticed any major issues with Pulseaudio in the past
couple of years running Ubuntu. That and sound has worked out of the box
Steve Langasek wrote:
Pretty sure you have this backwards. The decision to implement upstart and
use it in Ubuntu was a technical [corrected] one. The decision to NIH a
dependency-based init system and then try to strongarm everyone into using
it by breaking compatibility was the political
Steve Langasek wrote:
On Thu, Oct 25, 2012 at 05:17:10PM +0800, Thomas Goirand wrote:
On 10/25/2012 02:48 AM, Steve Langasek wrote:
On Thu, Oct 25, 2012 at 01:57:12AM +0800, Thomas Goirand wrote:
I remember when I started a thread about 6 months ago,
willing to take over maintainership of
Marc Haber wrote:
Amen. I find it derogatory towards the people spending months of their
private time to make exotic ports work to call their work toy ports.
There are people who use their time doing things like hopping across a
continent on one foot. That is a lot of work, but it's not
Simon Paillard wrote:
On Sat, Jul 21, 2012 at 09:25:50PM +0300, Uoti Urpala wrote:
So at least in this case the biggest performance problem by far is the
inappropriate use of fsync() or other disk synchronization primitives,
and CPU use for unpacking is pretty much irrelevant.
Though
Joey Hess wrote:
Hideki Yamane wrote:
I tested as well, and sometimes decompression with xz is so slw,
it takes 6-8 times than default gz.
I was just watching your DebConf presentation Lets shrink Debian
package archive and I think there you said decompression with xz was
between
brian m. carlson wrote:
On Sat, Jul 21, 2012 at 09:25:50PM +0300, Uoti Urpala wrote:
So at least in this case the biggest performance problem by far is the
inappropriate use of fsync() or other disk synchronization primitives,
and CPU use for unpacking is pretty much irrelevant.
My
Wouter Verhelst wrote:
I don't think compiling C code has been CPU bound since before I was
born (and I was born in the late 70s, so that's quite a while). C++ is a
different matter, but still.
Bullshit. GCC uses a lot of CPU unless you compile without optimization,
and is surprisingly slow
Guillem Jover wrote:
By definition a binNMU cannot produce a source package anyway, so I
fail to see the point in this artifical need to distinguish “source”
and “binary” changelogs through different files, AFAIR I already
Why artificial? Isn't it a completely natural and consistent view to
that doesn't help your credibility.
Do you dismiss the theory (confirmed by Uoti Urpala test script) that
tmpfs+swap INCREASE number of writes and are hence bad for SSD?
I think what the script shows is that there can be significant problems
using tmpfs to hold large amounts of data, even if you have
Serge wrote:
2012/6/10 Uoti Urpala wrote:
You've posted blatantly false claims. If you post claims like 1+1
equals 2 because the moon is made of cheese, then you're a moron, even
if 1+1 does equal 2.
(I like this example :)) It could be, it's impossible to know everything
in the world
Goswin von Brederlow wrote:
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
I haven't read the relevant kernel code, but that doesn't match the
behavior I see. Reading a large file from tmpfs and then allocating
memory results in large swap writes every time, even if the newly
allocated
Goswin von Brederlow wrote:
Le vendredi 25 mai 2012 à 16:01 +0300, Uoti Urpala a écrit :
There is one significant difference though. When you read data back to
memory from swap, the kernel does not remember that it already exists on
disk; when the data is evicted from memory again
Steve Langasek wrote:
On Thu, May 31, 2012 at 06:15:47PM +0200, Bernd Zeimetz wrote:
Especially do I fail to understand why a member of the TC, who took part
in such discussions before
(https://lists.debian.org/debian-devel/2006/05/msg00457.html to name an
example), and encouraged people
Serge wrote:
you eat cache memory. Meaning, you store /tmp files in cache even when
they're not used, so kernel cannot use that memory to store some useful
files. This increases I/O and makes the system slower.
The tmpfs files will be written to swap if they aren't accessed much and
the kernel
Josselin Mouette wrote:
Files which are written on a regular filesystem stay on memory. This is
called the buffer cache. Whenever they are not used and/or the system
needs to reclaim memory, they are trashed.
Files which are written on a tmpfs stay on memory. Whenever they are not
used and/or
Philip Hands wrote:
The traditional Debian approach to /etc is largely self documenting, to
the extent that one can generally walk into a site cold and (having
established that they have decent backups) cheerfully do an upgrade on
their Debian servers without anything breaking (I do this
George Danchev wrote:
On Thursday 10 May 2012 00:22:11 Uoti Urpala wrote:
Steve McIntyre wrote:
No, really - please *do* do this. The fact that a lot of the software
coming out of RedHat development seems to be designed solely for their
use, including working around the missing/broken
Marco d'Itri wrote:
On May 10, Bjørn Mork bj...@mork.no wrote:
Agree. Copying a large set of default policies into /etc just because
they *can* be overridden is not user friendly. And it does not make the
defaults any more configuration either. It just hides important local
changes
Don Armstrong wrote:
On Thu, 10 May 2012, Uoti Urpala wrote:
You're pretty much just saying that dpkg and helpers like ucf have
implemented better functionality than rpm. I don't see how that's
relevant to the discussion.
The reason why it is relevant is because
I don't see how
George Danchev wrote:
On Thursday 10 May 2012 19:53:18 Uoti Urpala wrote:
The reason why most old applications do not follow that approach (at
least not yet) is pretty obvious: their authors never considered it.
etc-overrides-lib semantics have only become a seriously considered
Don Armstrong wrote:
On Thu, 10 May 2012, Uoti Urpala wrote:
I don't see how the following would make this comparison with rpm
relevant.
This is debian-devel, and we're talking about configuration file
handling in Debian, which makes ucf and dpkg relevant.
Yes, ucf and dpkg are relevant
George Danchev wrote:
On Thursday 10 May 2012 21:46:41 Uoti Urpala wrote:
I don't see how the following would make this comparison with rpm relevant.
It was a comparison of the packaging system facilities to handle upgrades of
the configuration files of the applications. This was initially
Don Armstrong wrote:
On Thu, 10 May 2012, Ben Hutchings wrote:
In the etc-overrides-lib model, program defaults and local
configuration are effectively being merged every time the program
starts.
This seems to assume that the program would always read both. systemd
unit files don't work
Tollef Fog Heen wrote:
]] Philipp Kern
You will not, however, get a conffile update prompt when the system
file changes (e.g. to update your own local copy to incorporate the
fix).
This is something I'm pondering if we should handle in either a systemd
trigger or a tool that packages
Roger Leigh wrote:
Can't we just do things the Debian way, and just provide them directly
as conffiles in /etc? It's nice that systemd provides its mechanism
to symlink/include the units provided elsewhere, but is this either
necessary or desirable on a Debian system?
Not having the files in
Gergely Nagy wrote:
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
Not having the files in /etc by default does have technical advantages.
It's easier to see what is local non-default configuration. Original
default file is always available in a known location (and very easy to
revert
Steve McIntyre wrote:
Josh Triplett wrote:
Marco d'Itri wrote:
The more I think about it, the more I suspect that the correct solution
would be to just symlink /lib/udev/rules.d/ to /etc/udev/rules.d/ and so
on.
Please don't. As a user, I find it highly preferable for packages to
Steve McIntyre wrote:
Uoti Urpala wrote:
Who's the one choosing his preferred configuration format based on the
limitations of his preferred packaging system here? Hint: it's not Red
Hat.
*yawn*
When you've got something constructive to add to Debian development,
let us know. Until
Dmitry Nezhevenko wrote:
On Mon, Apr 30, 2012 at 01:49:57AM +0300, Uoti Urpala wrote:
Marco d'Itri wrote:
- configuration files in /etc/ overriding configuration files in /lib/,
to work around the inferior configuration files handling of RPM
I'm not convinced that the traditional
Dmitry Nezhevenko wrote:
On Mon, Apr 30, 2012 at 02:44:42PM +0300, Uoti Urpala wrote:
Wrong. Any program behavior change may require changing custom
configuration, but such changes need not be accompanied by changes in
the default configuration file. Currently dpkg lacks any mechanism
George Danchev wrote:
It is entirely possible to manage configuration files from dpkg's
maintainerscripts (postinst on 'configure' stage, and resp. postrm) as
you find fit,
or by means of ucf, and possibly in combination with debconf.
One can ship a bunch of configuration files in
Roger Leigh wrote:
One of the definining characteristics of the Linux ecosystem, including
Debian, has been that the system has been made up of a set of loosely-
coupled compoments with well-defined interfaces. This is in stark
contrast to, e.g. Windows, MacOS and other proprietary systems,
Marco d'Itri wrote:
I am on friendly terms with many Red Hat people, but it is a fact that
they take design decisions which are aligned with the needs of RHEL
and these needs are often far from what is good for other distributions.
- configuration files in /etc/ overriding configuration
Russ Allbery wrote:
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
Russ Allbery wrote:
+pie causes a fairly ordinary regular binary (gnubg) to die with a bus
error immediately upon execution. If someone could figure out why and
whether it's a general class of problems or something
Russ Allbery wrote:
+pie causes a fairly ordinary regular binary (gnubg) to die with a bus
error immediately upon execution. If someone could figure out why and
whether it's a general class of problems or something peculiar to that
code, I'd be feeling more optimistic about enabling PIE more
Russ Allbery wrote:
Josselin Mouette j...@debian.org writes:
I’ve not seen many people interested specifically in upstart in this
discussion, apart from Canonical employees.
For the record, I'm interested specifically in upstart because I think
that alignment with Ubuntu is a major win
Russ Allbery wrote:
Samuel Thibault sthiba...@debian.org writes:
It is apparently trying to be a *Linux* standard, being adopted by all
distributions.
That's not at all clear to me. It seems more to be trying to be a good
init system used by Fedora, and beyond that it's left to people to
Martin Wuertele wrote:
* Uoti Urpala uoti.urp...@pp1.inet.fi [2012-03-23 19:44]:
IMO your [Steve Langasek's] upstart advocacy and anti-systemd FUD
crosses the line between having your own opinions and having your
own facts.
There was neither FUD nor advocacy in Steves mail and no hostile
Steve Langasek wrote:
The current state of upstart in Debian is a reflection of the upstart
maintainers' respect for Debian and desire to not destabilize the
distribution by triggering an avalanche of package conversions that could
quickly take us past the point of no return for bit rot of our
Steve Langasek wrote:
There are also complications to using cgroups, in that suddenly any service
that needs to be able to spawn long-running processes that outlive the
service has to start caring about cgroups - both so that they survive the
service being shut down from the outside, and so
Bernhard R. Link wrote:
While there might be some problems originating from some architecture,
but most problems you will see and people claim to be problems specific
to fringe architectures are actual bugs in the program you just do not
*yet* see on your usual pet architectures. And some more
Steve Langasek wrote:
If no one's measured it, then converting scripts to C programs to
avoid the added exec() calls is premature optimization. If the only
You keep repeating the same FUD. Again, avoiding shell is not just an
optimization, much less a premature one. Also, if I understand the
Goswin von Brederlow wrote:
Steve Langasek vor...@debian.org writes:
/etc/default/* files. The options here are all fairly poor:
Option 2 is also bad. There is a reason why we have /etc/default instead
of setting the options in the init.d scripts directly. Most importantly
the init.d
1 - 100 of 137 matches
Mail list logo
