I should say up-front that I don't consider this to be a decisive issue,
but since it was raised and I did a bit of investigation, I wanted to
report my initial conclusions and see if I missed anything or got anything
wrong.
I did a quick code inspection of the code base for both upstart and
syste
Steve Langasek writes:
> While it's fair to note that Canonical is a smaller company with fewer
> resources than Red Hat, Canonical is certainly not the only company
> working on technologies that don't fit into systemd upstream's model.
> On the question of cgroup management for instance, while
Don Armstrong writes:
> Projects which have multiple components, each of which has different
> security/interface surfaces without stable defined interfaces, can lead
> to problems when one set of developers doesn't understand the security
> implications of the parts that they do not work on.
It
On Mon, 2013-12-02 at 15:32 -0800, Don Armstrong wrote:
> On Tue, 03 Dec 2013, Josselin Mouette wrote:
> > Le lundi 02 décembre 2013 à 13:41 -0700, Bdale Garbee a écrit :
> > > Josselin Mouette writes:
> > >
> > > > There are two implied assumptions here:
> > > > * that the same people ar
On Tue, 03 Dec 2013, Josselin Mouette wrote:
> Le lundi 02 décembre 2013 à 13:41 -0700, Bdale Garbee a écrit :
> > Josselin Mouette writes:
> >
> > > There are two implied assumptions here:
> > > * that the same people are developing all components;
> > > * that develolpers have th
On Mon, 02 Dec 2013, Bastian Blank wrote:
> On Sun, Dec 01, 2013 at 05:49:13PM -0800, Don Armstrong wrote:
> > Bastian: Would such a patch be acceptable in principle?
>
> After systemd was fixed, yes.
Can you let me know which part of systemd needed to be fixed? [What bug#
is this?]
Can you also
Le lundi 02 décembre 2013 à 13:41 -0700, Bdale Garbee a écrit :
> Josselin Mouette writes:
>
> > There are two implied assumptions here:
> > * that the same people are developing all components;
> > * that develolpers have the same attention to code quality and
> > security
Hi Michael,
On Mon, Dec 02, 2013 at 11:48:54PM +0100, Michael Stapelberg wrote:
> Hi Don,
> Don Armstrong writes:
> > I'd like to get this particular bug discussion restarted.
> Thanks for your mail.
> > From my understanding, a static, non generator version of
> > lvm2_activation_generator_sys
On Sun, Dec 01, 2013 at 11:11:43PM +0100, Sune Vuorela wrote:
> On Sunday 01 December 2013 21:50:49 Ian Jackson wrote:
> > This leads me to a question which I find myself asking, after reading
> > the systemd debate page:
> > If we were to adopt systemd as pid 1, which sections of the systemd
> >
On Sun, Dec 01, 2013 at 05:49:13PM -0800, Don Armstrong wrote:
> Bastian: Would such a patch be acceptable in principle?
After systemd was fixed, yes.
Bastian
--
Conquest is easy. Control is not.
-- Kirk, "Mirror, Mirror", stardate unknown
--
To UNSUBSCRIBE, email to debian-c
Hi Don,
Don Armstrong writes:
> I'd like to get this particular bug discussion restarted.
Thanks for your mail.
> From my understanding, a static, non generator version of
> lvm2_activation_generator_systemd_red_hat.c will allow for the
> activation of lvm2 after the addition of an lvm device by
Steve Langasek writes:
> On Mon, Dec 02, 2013 at 11:24:41AM -0800, Russ Allbery wrote:
>> They're fairly trivial ones, though, no? Maintaining a local patch to
>> change the paths in a systemd unit is certainly way less effort than
>> maintaining the whole unit. It's akin to changing the #! pat
On Mon, Dec 02, 2013 at 11:24:41AM -0800, Russ Allbery wrote:
> Steve Langasek writes:
> > Note that the original complaint in the samba upstream discussion was
> > about hard-coding of paths to system utilities, which a) is not portable
> > between distributions and b) contradicts Debian policy.
Hi Russ,
On Fri, Nov 01, 2013 at 08:11:38PM -0700, Russ Allbery wrote:
> Steve Langasek writes:
> > For the TC decision, what kind of information are you looking for about
> > the plans, beyond "the Ubuntu developers expect to need to address this
> > before upgrading from systemd logind 204 and
Josselin Mouette writes:
> There are two implied assumptions here:
> * that the same people are developing all components;
> * that develolpers have the same attention to code quality and
> security in all components they work on.
>
> I don’t think either of them applies to
Ian Jackson writes:
> Russ Allbery writes ("Re: Bug#727708: systemd (security) bugs"):
>> Another point here is that it's sounding like we'll be using a lot of
>> those services regardless, at least on systems that need them, which
>> means that their security track record and bug rate is somewha
Steve Langasek writes:
> Note that the original complaint in the samba upstream discussion was
> about hard-coding of paths to system utilities, which a) is not portable
> between distributions and b) contradicts Debian policy.
> So systemd upstream may support separate /usr, but that doesn't ch
On Mon, Dec 02, 2013 at 09:28:23AM +0100, Tollef Fog Heen wrote:
> ]] Ian Jackson
> > It's not clear to me from the discussion there exactly what systemd
> > upstream's position on this kind of thing is.
> > Can someone point us, for example, to a statement by the systemd
> > upstreams about the
Le lundi 02 décembre 2013 à 11:22 +, Ian Jackson a écrit :
> I don't think that's entirely true. I think it is fair to look at the
> security history of other parts of the same project as indicative
> regarding code quality.
There are two implied assumptions here:
* that the same peop
Russ Allbery writes ("Re: Bug#727708: systemd (security) bugs"):
> Another point here is that it's sounding like we'll be using a lot of
> those services regardless, at least on systems that need them, which means
> that their security track record and bug rate is somewhat irrelevant for
> this dis
]] Ian Jackson
> It's not clear to me from the discussion there exactly what systemd
> upstream's position on this kind of thing is.
>
> Can someone point us, for example, to a statement by the systemd
> upstreams about their support for separate /usr (or their non-support
> for it) ?
http://li
21 matches
Mail list logo
