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 incl
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
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 w
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
Russ Allbery wrote:
> Bastien beudart 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 that is not in
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 decisio
Russ Allbery wrote:
> Christoph Anton Mitterer 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?
>
> The systemd
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 e
Steve Langasek wrote:
> On Thu, Oct 24, 2013 at 02:21:25AM +0200, Matthias Klumpp wrote:
> > 2013/10/24 Steve Langasek :
> > > [...]
> > >> 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
> > >> syst
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 d
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 partie
Russ Allbery wrote:
>Kay Sievers 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 just no
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
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 foll
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 fut
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. syste
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
> > >
Russ Allbery wrote:
> John Paul Adrian Glaubitz 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 versus 1604 count
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:
> 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 w
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
A
Michael Stapelberg wrote:
> Ondřej Surý 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
> >> http://people.debian.org/~stapelberg/docs/systemd-depe
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
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.
Initi
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 ab
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
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 reasonab
Marc Haber wrote:
> On Sat, 01 Jun 2013 12:42:33 +0200, John Paul Adrian Glaubitz
> 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.
Why wo
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 us
Zygmunt Krynicki wrote:
> W dniu sob, cze 1, 2013 o 12:52 ,nadawca John Paul Adrian Glaubitz
> 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), but there are so many
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
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
Russ Allbery wrote:
> Uoti Urpala 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
>
Marc Haber wrote:
> On Thu, 30 May 2013 17:07:08 +0200, Matthias Klumpp
> 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
Matthias Klumpp wrote:
> 013/5/30 Marco d'Itri :
> > On May 30, Mathieu Parent 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 som
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 tha
Mathieu Parent wrote:
> 2013/5/30 Marco d'Itri :
> > 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. But
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
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 improveme
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 p
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:
> 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 i
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 pa
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
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
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 t
Neil Williams wrote:
> On Mon, 01 Apr 2013 00:48:08 +0300
> Uoti Urpala 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 rele
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
Russ Allbery wrote:
> Adam Borowski 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 do only
> >
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?
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
Russ Allbery wrote:
> Uoti Urpala 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
> >
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 l
Russ Allbery wrote:
> Uoti Urpala 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
Russ Allbery wrote:
> John Paul Adrian Glaubitz 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 people
> > neither the s
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 politica
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 main
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 part
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 p
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 p
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
>
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 t
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 co
an't yourself tell the valid arguments apart from the crackpot
claims 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 the
Goswin von Brederlow wrote:
> Uoti Urpala 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 ne
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
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; whe
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 kern
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 an
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 re
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 w
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
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 dpk
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
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
Marco d'Itri wrote:
> On May 10, Bjørn Mork 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 and ma
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
> > &g
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 construc
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
Gergely Nagy wrote:
> Uoti Urpala 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
>
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
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 tha
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 /usr
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. Cur
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
>
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
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
Russ Allbery wrote:
> Uoti Urpala 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 cla
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 mo
Russ Allbery wrote:
> Josselin Mouette 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 for Deb
Russ Allbery wrote:
> Samuel Thibault 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 make up
> th
Martin Wuertele wrote:
> * Uoti Urpala [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 Steve
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
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
Goswin von Brederlow wrote:
> Steve Langasek 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 scripts can be up
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
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
1 - 100 of 137 matches
Mail list logo
