[gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Mark David Dumlao]

https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign

Not sure if I read that just right... but since nobody is doing cgroup
management besides systemd, in practice the cgroups implementation in
Linux wasn't very consistent. So since systemd is doing it, their work
is helping shape the kernel's cgroups api?

Interesting...
-- 
This email is:    [ ] actionable   [x] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Daniel Campbell]

On 10/17/2013 11:27 PM, Mark David Dumlao wrote:
> https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign
> 
> Not sure if I read that just right... but since nobody is doing cgroup
> management besides systemd, in practice the cgroups implementation in
> Linux wasn't very consistent. So since systemd is doing it, their work
> is helping shape the kernel's cgroups api?
> 
> Interesting...
> 

From my perspective it looks like systemd developers are trying to push
their ideas into the kernel, almost like they intend to merge systemd
*with* the kernel. If systemd is the only implementation of cgroups and
their developers are working on cgroup support in the kernel, it spells
calamity given their history of evangelism and zealotry.

I truly wish I understood why a single userland program and its
developers are being given the keys to an entire subsystem of the
kernel. Their changes to udev have proven to be a headache for users,
and the kernel is held to a much higher standard of stability and
interoperability. In addition, the top-level developers of systemd (and
GNOME, and the now-deprecated consolekit/polkit/udisks/etc) are employed
by a for-profit company (Red Hat), which has a vested interest in
shaping Linux as a platform. They and other corporations cannot be
trusted with stuff like this...

I'd like to see what Linus has to say about this if/when he finds out.
He's not impressed with Sievers or Poettering. Personally I'd like to
see them ostracized from the community and contained to their own
distro, where they belong.

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Volker Armin Hemmann]

Am 19.10.2013 17:02, schrieb Daniel Campbell:
> On 10/17/2013 11:27 PM, Mark David Dumlao wrote:
>> https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign
>>
>> Not sure if I read that just right... but since nobody is doing cgroup
>> management besides systemd, in practice the cgroups implementation in
>> Linux wasn't very consistent. So since systemd is doing it, their work
>> is helping shape the kernel's cgroups api?
>>
>> Interesting...
>>
> >From my perspective it looks like systemd developers are trying to push
> their ideas into the kernel, almost like they intend to merge systemd
> *with* the kernel. 

from what I read in the article cgroups are a mess and are cleaned up
anyway. The only real user of cgroups at the moment is systemd.
Others are welcome to make use of cgroups too. But in the current state
nobody blames them for not jumping in.

> If systemd is the only implementation of cgroups and
> their developers are working on cgroup support in the kernel, it spells
> calamity given their history of evangelism and zealotry.

well, going over some old ml threads on fedora mailing lists all I could
find was that Poettering and Sievers DID listen and DID make changes if
the demand was high enough.

Sure, I dislike systemd. Sure what happened with udev was a dick move.
But their 'zealotry' is a lot less developed than the zealotry of those
who exploded about using an 'init-thingy' in the future.

>
> I truly wish I understood why a single userland program and its
> developers are being given the keys to an entire subsystem of the
> kernel. 
they aren't.

> Their changes to udev have proven to be a headache for users,

yes? which ones?

> and the kernel is held to a much higher standard of stability and
> interoperability. In addition, the top-level developers of systemd (and
> GNOME, and the now-deprecated consolekit/polkit/udisks/etc) are employed
> by a for-profit company (Red Hat), which has a vested interest in
> shaping Linux as a platform. They and other corporations cannot be
> trusted with stuff like this...

hm, Redhat is one of the companies investing the most money into linux
kernel, userland, graphics... if you 'don't trust them' you are pretty
much 20 years too late.

>
> I'd like to see what Linus has to say about this if/when he finds out.
> He's not impressed with Sievers or Poettering. Personally I'd like to
> see them ostracized from the community and contained to their own
> distro, where they belong.
>
so much about zealotry.

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Daniel Campbell]

On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote:
> Am 19.10.2013 17:02, schrieb Daniel Campbell:
>> On 10/17/2013 11:27 PM, Mark David Dumlao wrote:
>>> https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign
>>>
>>> Not sure if I read that just right... but since nobody is doing cgroup
>>> management besides systemd, in practice the cgroups implementation in
>>> Linux wasn't very consistent. So since systemd is doing it, their work
>>> is helping shape the kernel's cgroups api?
>>>
>>> Interesting...
>>>
>> >From my perspective it looks like systemd developers are trying to push
>> their ideas into the kernel, almost like they intend to merge systemd
>> *with* the kernel. 
> 
> from what I read in the article cgroups are a mess and are cleaned up
> anyway. The only real user of cgroups at the moment is systemd.
> Others are welcome to make use of cgroups too. But in the current state
> nobody blames them for not jumping in.
No complaints here in improving something, but consider the source is
all I'm saying.

> 
>> If systemd is the only implementation of cgroups and
>> their developers are working on cgroup support in the kernel, it spells
>> calamity given their history of evangelism and zealotry.
> 
> well, going over some old ml threads on fedora mailing lists all I could
> find was that Poettering and Sievers DID listen and DID make changes if
> the demand was high enough.
> 
> Sure, I dislike systemd. Sure what happened with udev was a dick move.
> But their 'zealotry' is a lot less developed than the zealotry of those
> who exploded about using an 'init-thingy' in the future.
>
I'd say their zealotry is less loud and more persistent. Their way is
best, UNIX (and its philosophy) is outmoded, people are thinking 30
years behind where we are, etc etc etc. Those who have separate /usr and
blame systemd for pushing them to use an initramfs aren't seeing the
real problem (upstreams not putting things where they belong, FHS no
longer *really* being worked on, generally just the filesystem being
played with like a toy)

>>
>> I truly wish I understood why a single userland program and its
>> developers are being given the keys to an entire subsystem of the
>> kernel. 
> they aren't.
Of the people who have committed to the cgroup subsystem of the kernel,
how many are not members of the systemd, GNOME, or Red Hat projects?
I'll let that speak for itself.

> 
>> Their changes to udev have proven to be a headache for users,
> 
> yes? which ones?
Persistent NIC naming, for starters. The former maintainer's idea to
merge with systemd (which was influenced by Mr. Poettering in the first
place) when the two are completely separate pieces of software that do
two completely different jobs, and various other troubles with udev >
175 that one can Google for and find tons of results.
> 
>> and the kernel is held to a much higher standard of stability and
>> interoperability. In addition, the top-level developers of systemd (and
>> GNOME, and the now-deprecated consolekit/polkit/udisks/etc) are employed
>> by a for-profit company (Red Hat), which has a vested interest in
>> shaping Linux as a platform. They and other corporations cannot be
>> trusted with stuff like this...
> 
> hm, Redhat is one of the companies investing the most money into linux
> kernel, userland, graphics... if you 'don't trust them' you are pretty
> much 20 years too late.
Investing money does not make them any more qualified or deserving of
making decisions. Red Hat is not the sole user of Linux. They should
consider themselves lucky that they are even able to profit from
something that's free.

You're right, though. They've been around for a while, and I've never
trusted them or any other corporate interest in *nix. There's always a
catch when dealing with a business.

> 
>>
>> I'd like to see what Linus has to say about this if/when he finds out.
>> He's not impressed with Sievers or Poettering. Personally I'd like to
>> see them ostracized from the community and contained to their own
>> distro, where they belong.
>>
> so much about zealotry.
> 
> 
When a tumor is growing, if you cannot excise it, you must make its
environment so harsh that it recedes. I have strong opinions, but I
don't go around shoving my software in peoples' faces or tell people
they're wrong to not use my software. Even Linus, who's known for his
ego, wouldn't cross that line.

If I'm a zealot of anything, it's freedom of choice.

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Samuli Suominen]

On 20/10/13 09:34, Daniel Campbell wrote:
> On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote:
>> Am 19.10.2013 17:02, schrieb Daniel Campbell:
>>> On 10/17/2013 11:27 PM, Mark David Dumlao wrote:
>>>> https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign
>>>>
>>>> Not sure if I read that just right... but since nobody is doing cgroup
>>>> management besides systemd, in practice the cgroups implementation in
>>>> Linux wasn't very consistent. So since systemd is doing it, their work
>>>> is helping shape the kernel's cgroups api?
>>>>
>>>> Interesting...
>>>>
>>> >From my perspective it looks like systemd developers are trying to push
>>> their ideas into the kernel, almost like they intend to merge systemd
>>> *with* the kernel. 
>> from what I read in the article cgroups are a mess and are cleaned up
>> anyway. The only real user of cgroups at the moment is systemd.
>> Others are welcome to make use of cgroups too. But in the current state
>> nobody blames them for not jumping in.
> No complaints here in improving something, but consider the source is
> all I'm saying.
>
>>> If systemd is the only implementation of cgroups and
>>> their developers are working on cgroup support in the kernel, it spells
>>> calamity given their history of evangelism and zealotry.
>> well, going over some old ml threads on fedora mailing lists all I could
>> find was that Poettering and Sievers DID listen and DID make changes if
>> the demand was high enough.
>>
>> Sure, I dislike systemd. Sure what happened with udev was a dick move.
>> But their 'zealotry' is a lot less developed than the zealotry of those
>> who exploded about using an 'init-thingy' in the future.
>>
> I'd say their zealotry is less loud and more persistent. Their way is
> best, UNIX (and its philosophy) is outmoded, people are thinking 30
> years behind where we are, etc etc etc. Those who have separate /usr and
> blame systemd for pushing them to use an initramfs aren't seeing the
> real problem (upstreams not putting things where they belong, FHS no
> longer *really* being worked on, generally just the filesystem being
> played with like a toy)
>
>>> I truly wish I understood why a single userland program and its
>>> developers are being given the keys to an entire subsystem of the
>>> kernel. 
>> they aren't.
> Of the people who have committed to the cgroup subsystem of the kernel,
> how many are not members of the systemd, GNOME, or Red Hat projects?
> I'll let that speak for itself.
>
>>> Their changes to udev have proven to be a headache for users,
>> yes? which ones?
> Persistent NIC naming, for starters. The former maintainer's idea to
> merge with systemd (which was influenced by Mr. Poettering in the first
> place) when the two are completely separate pieces of software that do
> two completely different jobs, and various other troubles with udev >
> 175 that one can Google for and find tons of results.

I can't find anything that would be true. Can you point out some?
A lot of FUD[1] and outright lies coming from people, who, for example,
don't like systemd.

[1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt

I know for a fact udev-208 is a full replacement for udev-171 in terms
that both work on same kernels, same libcs, and so forth. That's why
171 is no longer in Portage, because it's completely useless from users
(and developers) point of view.

Adjusting some configs and enabling some kernel options that have been
around for a long time is just part of normal maintenance process,
that's what we have admins for.

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Daniel Campbell]

On 10/20/2013 02:37 AM, Samuli Suominen wrote:
> 
> On 20/10/13 09:34, Daniel Campbell wrote:
>> On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote:
>>> Am 19.10.2013 17:02, schrieb Daniel Campbell:
>>>> On 10/17/2013 11:27 PM, Mark David Dumlao wrote:
>>>>> https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign
>>>>>
>>>>> Not sure if I read that just right... but since nobody is doing cgroup
>>>>> management besides systemd, in practice the cgroups implementation in
>>>>> Linux wasn't very consistent. So since systemd is doing it, their work
>>>>> is helping shape the kernel's cgroups api?
>>>>>
>>>>> Interesting...
>>>>>
>>>> >From my perspective it looks like systemd developers are trying to push
>>>> their ideas into the kernel, almost like they intend to merge systemd
>>>> *with* the kernel. 
>>> from what I read in the article cgroups are a mess and are cleaned up
>>> anyway. The only real user of cgroups at the moment is systemd.
>>> Others are welcome to make use of cgroups too. But in the current state
>>> nobody blames them for not jumping in.
>> No complaints here in improving something, but consider the source is
>> all I'm saying.
>>
>>>> If systemd is the only implementation of cgroups and
>>>> their developers are working on cgroup support in the kernel, it spells
>>>> calamity given their history of evangelism and zealotry.
>>> well, going over some old ml threads on fedora mailing lists all I could
>>> find was that Poettering and Sievers DID listen and DID make changes if
>>> the demand was high enough.
>>>
>>> Sure, I dislike systemd. Sure what happened with udev was a dick move.
>>> But their 'zealotry' is a lot less developed than the zealotry of those
>>> who exploded about using an 'init-thingy' in the future.
>>>
>> I'd say their zealotry is less loud and more persistent. Their way is
>> best, UNIX (and its philosophy) is outmoded, people are thinking 30
>> years behind where we are, etc etc etc. Those who have separate /usr and
>> blame systemd for pushing them to use an initramfs aren't seeing the
>> real problem (upstreams not putting things where they belong, FHS no
>> longer *really* being worked on, generally just the filesystem being
>> played with like a toy)
>>
>>>> I truly wish I understood why a single userland program and its
>>>> developers are being given the keys to an entire subsystem of the
>>>> kernel. 
>>> they aren't.
>> Of the people who have committed to the cgroup subsystem of the kernel,
>> how many are not members of the systemd, GNOME, or Red Hat projects?
>> I'll let that speak for itself.
>>
>>>> Their changes to udev have proven to be a headache for users,
>>> yes? which ones?
>> Persistent NIC naming, for starters. The former maintainer's idea to
>> merge with systemd (which was influenced by Mr. Poettering in the first
>> place) when the two are completely separate pieces of software that do
>> two completely different jobs, and various other troubles with udev >
>> 175 that one can Google for and find tons of results.
> 
> I can't find anything that would be true. Can you point out some?
> A lot of FUD[1] and outright lies coming from people, who, for example,
> don't like systemd.
> 
> [1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt
> 
> I know for a fact udev-208 is a full replacement for udev-171 in terms
> that both work on same kernels, same libcs, and so forth. That's why
> 171 is no longer in Portage, because it's completely useless from users
> (and developers) point of view.
> 
> Adjusting some configs and enabling some kernel options that have been
> around for a long time is just part of normal maintenance process,
> that's what we have admins for.
> 

Do you know the design consequences of opt-in versus opt-out? I'll keep
this short: When evolving a codebase, new behavior for core parts of the
system should not be pushed or forced on users. If you must, keep the
old behavior around as a default and allow users to try the new thing by
explicitly opting in. The new naming in whichever udev started the mess
did it the exact opposite (and wrong) way.

While editing and updating configs is a normal part of system
maintenance, turning a system on its head and screwing it out of network
accessibility until the new default is reversed (by means of a `kernel`
line in GRUB, requiring a reboot) is straight-up wrong design.
Conversely, keeping old behavior, even for systems that *do* have
multiple NICs, will at least be functional (for one of the NICs, anyway)
until they set the option to get their expected behavior sorted out.
Multi-NIC systems are less common than single-NIC systems, and that
alone should've been enough motivation to leave old behavior as default,
with the new behavior a simple config switch away.

The way the new behavior was introduced may have led users of single-NIC
systems to believe that the old way was broken, when as demonstrated
through past use, works *just fine* for single-NIC machines. It was
*multi-NIC* use that wasn't as predictive and needed the fix, not
*single*. It's basically using poor design/defaults decisions to smear
existing technology dishonestly. Technical propaganda, so to speak.

My beef with that decision is separate from my disdain for the decision
to merge it with systemd, which is only mildly related to why I dislike
systemd, but that's irrelevant.

As for FUD, I see no reason to get personal. If you insist, we can take
a look at which Gentoo package(s) you maintain that are related to the
topic and ask ourselves if you are any less biased.

---

Getting back to the original topic, cgroups sound like a pretty neat
idea that other init systems could benefit from. If the systemd guys are
willing to work on that subsystem for themselves, are they also
interested in seeing what other init systems would want from cgroups?
Certainly there's more room for development and/or standardization on an
API instead of a single project having all the influence. I think their
presence and activity with cgroups could be beneficial if policed by
another init system project that's not trying to infect every Linux distro.

tldr version: opt-out design is bad, the accusation of FUD is moot since
you maintain udev for Gentoo, and I think work on cgroups (by systemd
people) could be good if they're not the only people working on it and
calling the shots.

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Volker Armin Hemmann]

Am 20.10.2013 08:34, schrieb Daniel Campbell:
> hm, Redhat is one of the companies investing the most money into linux
> kernel, userland, graphics... if you 'don't trust them' you are pretty
> much 20 years too late.
> Investing money does not make them any more qualified or deserving of
> making decisions. Red Hat is not the sole user of Linux. They should
> consider themselves lucky that they are even able to profit from
> something that's free.
>
> You're right, though. They've been around for a while, and I've never
> trusted them or any other corporate interest in *nix. There's always a
> catch when dealing with a business.
>

'have been around for a while' - replace that with 'are financing more
core developers than anybody else'.

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Samuli Suominen]

On 20/10/13 12:24, Daniel Campbell wrote:
> On 10/20/2013 02:37 AM, Samuli Suominen wrote:
>> On 20/10/13 09:34, Daniel Campbell wrote:
>>> On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote:
>>>> Am 19.10.2013 17:02, schrieb Daniel Campbell:
>>>>> On 10/17/2013 11:27 PM, Mark David Dumlao wrote:
>>>>>> https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign
>>>>>>
>>>>>> Not sure if I read that just right... but since nobody is doing cgroup
>>>>>> management besides systemd, in practice the cgroups implementation in
>>>>>> Linux wasn't very consistent. So since systemd is doing it, their work
>>>>>> is helping shape the kernel's cgroups api?
>>>>>>
>>>>>> Interesting...
>>>>>>
>>>>> >From my perspective it looks like systemd developers are trying to push
>>>>> their ideas into the kernel, almost like they intend to merge systemd
>>>>> *with* the kernel. 
>>>> from what I read in the article cgroups are a mess and are cleaned up
>>>> anyway. The only real user of cgroups at the moment is systemd.
>>>> Others are welcome to make use of cgroups too. But in the current state
>>>> nobody blames them for not jumping in.
>>> No complaints here in improving something, but consider the source is
>>> all I'm saying.
>>>
>>>>> If systemd is the only implementation of cgroups and
>>>>> their developers are working on cgroup support in the kernel, it spells
>>>>> calamity given their history of evangelism and zealotry.
>>>> well, going over some old ml threads on fedora mailing lists all I could
>>>> find was that Poettering and Sievers DID listen and DID make changes if
>>>> the demand was high enough.
>>>>
>>>> Sure, I dislike systemd. Sure what happened with udev was a dick move.
>>>> But their 'zealotry' is a lot less developed than the zealotry of those
>>>> who exploded about using an 'init-thingy' in the future.
>>>>
>>> I'd say their zealotry is less loud and more persistent. Their way is
>>> best, UNIX (and its philosophy) is outmoded, people are thinking 30
>>> years behind where we are, etc etc etc. Those who have separate /usr and
>>> blame systemd for pushing them to use an initramfs aren't seeing the
>>> real problem (upstreams not putting things where they belong, FHS no
>>> longer *really* being worked on, generally just the filesystem being
>>> played with like a toy)
>>>
>>>>> I truly wish I understood why a single userland program and its
>>>>> developers are being given the keys to an entire subsystem of the
>>>>> kernel. 
>>>> they aren't.
>>> Of the people who have committed to the cgroup subsystem of the kernel,
>>> how many are not members of the systemd, GNOME, or Red Hat projects?
>>> I'll let that speak for itself.
>>>
>>>>> Their changes to udev have proven to be a headache for users,
>>>> yes? which ones?
>>> Persistent NIC naming, for starters. The former maintainer's idea to
>>> merge with systemd (which was influenced by Mr. Poettering in the first
>>> place) when the two are completely separate pieces of software that do
>>> two completely different jobs, and various other troubles with udev >
>>> 175 that one can Google for and find tons of results.
>> I can't find anything that would be true. Can you point out some?
>> A lot of FUD[1] and outright lies coming from people, who, for example,
>> don't like systemd.
>>
>> [1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt
>>
>> I know for a fact udev-208 is a full replacement for udev-171 in terms
>> that both work on same kernels, same libcs, and so forth. That's why
>> 171 is no longer in Portage, because it's completely useless from users
>> (and developers) point of view.
>>
>> Adjusting some configs and enabling some kernel options that have been
>> around for a long time is just part of normal maintenance process,
>> that's what we have admins for.
>>
> Do you know the design consequences of opt-in versus opt-out? I'll keep
> this short: When evolving a codebase, new behavior for core parts of the
> system should not be pushed or forced on users. If you must, keep the
> old behavior around as a default and allow users to try the new thing by
> explicitly opting in. The new naming in whichever udev started the mess
> did it the exact opposite (and wrong) way.


It's not forced upon you. You received a news item that had instructions
on howto assign names you want, like lan0, internet1, wireless3, and so
forth.
And it also described howto turn off udev from completely renaming the
devices, to keep kernel assigned names.
What they did was they dropped the *broken* feature called 'persistent
rule_generator' which never worked correctly, and in
race conditions still flipped eth0 <-> eth1 around -- that was a
*security* flaw that *needed* to go.
It would have gone even without providing the alternative of providing
biosdevname -like new name optionality to the users.
Kernel and kernel drivers are designed in a way it's not supported to
flip in-place kernel names and udev tried to workaround that.

https://www.kernel.org/doc/htmldocs/device-drivers/API-device-rename.html

>
> While editing and updating configs is a normal part of system
> maintenance, turning a system on its head and screwing it out of network
> accessibility until the new default is reversed (by means of a `kernel`
> line in GRUB, requiring a reboot) is straight-up wrong design.

Again, that's why you received a warning beforehand in form of portage
news item, portage news postinst message,
and a updated gentoo handbook plus gentoo wiki. There was no such
breakage as you described, unless you were
stupid enough (sorry, no offense intended) to upgrade something related
in the boot process without reading the relavent
information.

> Conversely, keeping old behavior, even for systems that *do* have
> multiple NICs, will at least be functional (for one of the NICs, anyway)
> until they set the option to get their expected behavior sorted out.
> Multi-NIC systems are less common than single-NIC systems, and that
> alone should've been enough motivation to leave old behavior as default,
> with the new behavior a simple config switch away.
>
> The way the new behavior was introduced may have led users of single-NIC
> systems to believe that the old way was broken, when as demonstrated
> through past use, works *just fine* for single-NIC machines. It was

And when those single network adapter users enable one of many virtual
drivers that create eth*, or attach removable
network device that creates eth* the bug would have been brought up.
So no, it was never safe to use in-place in-kernel renaming even on
single NIC systems.

> *multi-NIC* use that wasn't as predictive and needed the fix, not
> *single*. It's basically using poor design/defaults decisions to smear
> existing technology dishonestly. Technical propaganda, so to speak.
>
> My beef with that decision is separate from my disdain for the decision
> to merge it with systemd, which is only mildly related to why I dislike
> systemd, but that's irrelevant.
>
> As for FUD, I see no reason to get personal. If you insist, we can take
> a look at which Gentoo package(s) you maintain that are related to the
> topic and ask ourselves if you are any less biased.
>

If you are hinting I'm someway favouring systemd, or udev for that
matter, you couldn't be more wrong. I use OpenRC, and I maintain
ConsoleKit/udev
out of necessity (because someone has to). I deal with facts, I have no
favouritism to any direction.
In contrast, I also maintain a bunch of software that allows people to
*skip* whole freedesktop.org stack (ConsoleKit, PolicyKit and so forth)
like pmount,
pmount-gui and such for minimal systems.

> ---
>
> Getting back to the original topic, cgroups sound like a pretty neat
> idea that other init systems could benefit from. If the systemd guys are
> willing to work on that subsystem for themselves, are they also
> interested in seeing what other init systems would want from cgroups?
> Certainly there's more room for development and/or standardization on an
> API instead of a single project having all the influence. I think their
> presence and activity with cgroups could be beneficial if policed by
> another init system project that's not trying to infect every Linux distro.
>
> tldr version: opt-out design is bad, the accusation of FUD is moot since
> you maintain udev for Gentoo, and I think work on cgroups (by systemd
> people) could be good if they're not the only people working on it and
> calling the shots.
>

There is nothing stopping from sane patches entering the Linux tree that
would go in favour of OpenRC cgroups support, it's just that there are
almost no people working on it.
Like I said, code matters, complaining doesn't.

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Daniel Campbell]

On 10/20/2013 04:55 AM, Samuli Suominen wrote:
> 
> On 20/10/13 12:24, Daniel Campbell wrote:
>> On 10/20/2013 02:37 AM, Samuli Suominen wrote:
>>> On 20/10/13 09:34, Daniel Campbell wrote:
>>>> On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote:
>>>>> Am 19.10.2013 17:02, schrieb Daniel Campbell:
>>>>>> On 10/17/2013 11:27 PM, Mark David Dumlao wrote:
>>>>>>> https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign
>>>>>>>
>>>>>>> Not sure if I read that just right... but since nobody is doing cgroup
>>>>>>> management besides systemd, in practice the cgroups implementation in
>>>>>>> Linux wasn't very consistent. So since systemd is doing it, their work
>>>>>>> is helping shape the kernel's cgroups api?
>>>>>>>
>>>>>>> Interesting...
>>>>>>>
>>>>>> >From my perspective it looks like systemd developers are trying to push
>>>>>> their ideas into the kernel, almost like they intend to merge systemd
>>>>>> *with* the kernel. 
>>>>> from what I read in the article cgroups are a mess and are cleaned up
>>>>> anyway. The only real user of cgroups at the moment is systemd.
>>>>> Others are welcome to make use of cgroups too. But in the current state
>>>>> nobody blames them for not jumping in.
>>>> No complaints here in improving something, but consider the source is
>>>> all I'm saying.
>>>>
>>>>>> If systemd is the only implementation of cgroups and
>>>>>> their developers are working on cgroup support in the kernel, it spells
>>>>>> calamity given their history of evangelism and zealotry.
>>>>> well, going over some old ml threads on fedora mailing lists all I could
>>>>> find was that Poettering and Sievers DID listen and DID make changes if
>>>>> the demand was high enough.
>>>>>
>>>>> Sure, I dislike systemd. Sure what happened with udev was a dick move.
>>>>> But their 'zealotry' is a lot less developed than the zealotry of those
>>>>> who exploded about using an 'init-thingy' in the future.
>>>>>
>>>> I'd say their zealotry is less loud and more persistent. Their way is
>>>> best, UNIX (and its philosophy) is outmoded, people are thinking 30
>>>> years behind where we are, etc etc etc. Those who have separate /usr and
>>>> blame systemd for pushing them to use an initramfs aren't seeing the
>>>> real problem (upstreams not putting things where they belong, FHS no
>>>> longer *really* being worked on, generally just the filesystem being
>>>> played with like a toy)
>>>>
>>>>>> I truly wish I understood why a single userland program and its
>>>>>> developers are being given the keys to an entire subsystem of the
>>>>>> kernel. 
>>>>> they aren't.
>>>> Of the people who have committed to the cgroup subsystem of the kernel,
>>>> how many are not members of the systemd, GNOME, or Red Hat projects?
>>>> I'll let that speak for itself.
>>>>
>>>>>> Their changes to udev have proven to be a headache for users,
>>>>> yes? which ones?
>>>> Persistent NIC naming, for starters. The former maintainer's idea to
>>>> merge with systemd (which was influenced by Mr. Poettering in the first
>>>> place) when the two are completely separate pieces of software that do
>>>> two completely different jobs, and various other troubles with udev >
>>>> 175 that one can Google for and find tons of results.
>>> I can't find anything that would be true. Can you point out some?
>>> A lot of FUD[1] and outright lies coming from people, who, for example,
>>> don't like systemd.
>>>
>>> [1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt
>>>
>>> I know for a fact udev-208 is a full replacement for udev-171 in terms
>>> that both work on same kernels, same libcs, and so forth. That's why
>>> 171 is no longer in Portage, because it's completely useless from users
>>> (and developers) point of view.
>>>
>>> Adjusting some configs and enabling some kernel options that have been
>>> around for a long time is just part of normal maintenance process,
>>> that's what we have admins for.
>>>
>> Do you know the design consequences of opt-in versus opt-out? I'll keep
>> this short: When evolving a codebase, new behavior for core parts of the
>> system should not be pushed or forced on users. If you must, keep the
>> old behavior around as a default and allow users to try the new thing by
>> explicitly opting in. The new naming in whichever udev started the mess
>> did it the exact opposite (and wrong) way.
> 
> 
> It's not forced upon you. You received a news item that had instructions
> on howto assign names you want, like lan0, internet1, wireless3, and so
> forth.
> And it also described howto turn off udev from completely renaming the
> devices, to keep kernel assigned names.
> What they did was they dropped the *broken* feature called 'persistent
> rule_generator' which never worked correctly, and in
> race conditions still flipped eth0 <-> eth1 around -- that was a
> *security* flaw that *needed* to go.
> It would have gone even without providing the alternative of providing
> biosdevname -like new name optionality to the users.
> Kernel and kernel drivers are designed in a way it's not supported to
> flip in-place kernel names and udev tried to workaround that.
> 
> https://www.kernel.org/doc/htmldocs/device-drivers/API-device-rename.html
> 

Like I mentioned in a prior e-mail, the change didn't affect me when it
was pushed, and doesn't affect me now. I did recently have to reinstall
Gentoo, however (note, going from testing to stable isn't fun ;p), and
noticed it when I found Gentoo ships with systemd-udev instead of eudev.
I got the new naming and had to do some work to go back to what should
be normal behavior. My `kernel` line remains with that switch in effect,
but I'm not sure if eudev requires that flag to keep default behavior.
Had udev's defaults been left alone, I wouldn't have had to go through
any trouble to migrate back to eudev beyond the unmerge and emerge
that's expected as part of a switch. That's where the design flaw rears
its ugly head. I could see opposition to my view if I was trying to do
something that the software simply wasn't designed to do, like cook my
breakfast for me. Regardless, I was speaking purely from a design
perspective; I succeeded in solving the problem (mostly) on my own, so
no issues there.

Perhaps the next time I need to install Gentoo, I'll find a way to get
eudev on there before even the first proper boot and avoid the problem
altogether.

>>
>> While editing and updating configs is a normal part of system
>> maintenance, turning a system on its head and screwing it out of network
>> accessibility until the new default is reversed (by means of a `kernel`
>> line in GRUB, requiring a reboot) is straight-up wrong design.
> 
> Again, that's why you received a warning beforehand in form of portage
> news item, portage news postinst message,
> and a updated gentoo handbook plus gentoo wiki. There was no such
> breakage as you described, unless you were
> stupid enough (sorry, no offense intended) to upgrade something related
> in the boot process without reading the relavent
> information.
I'm pleased to know news was issued and rescind my statement on that.
Most likely, I skimmed the item, saw "udev", and moved onto the next
item, since I knew it didn't apply to my system. That was quite a while
ago, wasn't it?

> 
>> Conversely, keeping old behavior, even for systems that *do* have
>> multiple NICs, will at least be functional (for one of the NICs, anyway)
>> until they set the option to get their expected behavior sorted out.
>> Multi-NIC systems are less common than single-NIC systems, and that
>> alone should've been enough motivation to leave old behavior as default,
>> with the new behavior a simple config switch away.
>>
>> The way the new behavior was introduced may have led users of single-NIC
>> systems to believe that the old way was broken, when as demonstrated
>> through past use, works *just fine* for single-NIC machines. It was
> 
> And when those single network adapter users enable one of many virtual
> drivers that create eth*, or attach removable
> network device that creates eth* the bug would have been brought up.
> So no, it was never safe to use in-place in-kernel renaming even on
> single NIC systems.
Perhaps it's because I never used virtual network devices, but I never
had any issue out of default kernel names. As a NIC setup gets more
complex, I agree that something more robust should be used. I don't
agree that enps* or whatever are the way to do it, but that's bikeshed.

> 
>> *multi-NIC* use that wasn't as predictive and needed the fix, not
>> *single*. It's basically using poor design/defaults decisions to smear
>> existing technology dishonestly. Technical propaganda, so to speak.
>>
>> My beef with that decision is separate from my disdain for the decision
>> to merge it with systemd, which is only mildly related to why I dislike
>> systemd, but that's irrelevant.
>>
>> As for FUD, I see no reason to get personal. If you insist, we can take
>> a look at which Gentoo package(s) you maintain that are related to the
>> topic and ask ourselves if you are any less biased.
>>
> 
> If you are hinting I'm someway favouring systemd, or udev for that
> matter, you couldn't be more wrong. I use OpenRC, and I maintain
> ConsoleKit/udev
> out of necessity (because someone has to). I deal with facts, I have no
> favouritism to any direction.
> In contrast, I also maintain a bunch of software that allows people to
> *skip* whole freedesktop.org stack (ConsoleKit, PolicyKit and so forth)
> like pmount,
> pmount-gui and such for minimal systems.
> 
So you maintain them, but don't necessarily follow or agree with their
goals/sentiments/designs? Does that ever create problems for you when
trying to test systemd/udev on revbumps and whatnot? Do systemd
proponents wonder why you don't use what you maintain? Honestly curious;
I assumed that if you maintain something, you use it. Perhaps I was wrong.

>> ---
>>
>> Getting back to the original topic, cgroups sound like a pretty neat
>> idea that other init systems could benefit from. If the systemd guys are
>> willing to work on that subsystem for themselves, are they also
>> interested in seeing what other init systems would want from cgroups?
>> Certainly there's more room for development and/or standardization on an
>> API instead of a single project having all the influence. I think their
>> presence and activity with cgroups could be beneficial if policed by
>> another init system project that's not trying to infect every Linux distro.
>>
>> tldr version: opt-out design is bad, the accusation of FUD is moot since
>> you maintain udev for Gentoo, and I think work on cgroups (by systemd
>> people) could be good if they're not the only people working on it and
>> calling the shots.
>>
> 
> There is nothing stopping from sane patches entering the Linux tree that
> would go in favour of OpenRC cgroups support, it's just that there are
> almost no people working on it.
> Like I said, code matters, complaining doesn't.
> 
Okay, let's say the systemd guys start work on the cgroup subsystem,
things are moving along well, systemd support is basically done, works
well, etc. Someone goes in to try and get support for their init system
as well, and their code does something more than the systemd guys or
it's something they disagree with. Argument ensues, and because the
systemd guys started the work first and decided on things without
outside influence, they block the other init system from improving
cgroups for their particular needs.

My suggestion for them to not work on it alone is to prevent the above
situation from happening. Arguments over implementations happen all the
time, and given how aggressive systemd/udev changes have been pushed,
what's stopping them from preventing other init systems from taking
advantage of cgroups? If they make the changes in the cgroups kernel
code and other init systems use cgroups but cannot change the cgroup
kernel code (because their patches were rejected, for example), then
systemd effectively controls other init systems; at least when they
choose to use cgroups.

I wish I could say the odds of it happening were very low, but I'm not
really sure. What have they done to earn trust?

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Daniel Campbell]

On 10/20/2013 04:24 AM, Volker Armin Hemmann wrote:
> Am 20.10.2013 08:34, schrieb Daniel Campbell:
>> hm, Redhat is one of the companies investing the most money into linux
>> kernel, userland, graphics... if you 'don't trust them' you are pretty
>> much 20 years too late.
>> Investing money does not make them any more qualified or deserving of
>> making decisions. Red Hat is not the sole user of Linux. They should
>> consider themselves lucky that they are even able to profit from
>> something that's free.
>>
>> You're right, though. They've been around for a while, and I've never
>> trusted them or any other corporate interest in *nix. There's always a
>> catch when dealing with a business.
>>
> 
> 'have been around for a while' - replace that with 'are financing more
> core developers than anybody else'.
> 
That's less reason to trust, not more. That's like citing the popularity
of something as proof of its quality, when oftentimes it's the exact
opposite that's true.

So they spend a lot of money hiring developers. The more important
question is what is their agenda? What do they tell those developers to
*make*? You don't hire people without a business plan in mind.

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Volker Armin Hemmann]

Am 20.10.2013 12:52, schrieb Daniel Campbell:
> On 10/20/2013 04:24 AM, Volker Armin Hemmann wrote:
>> Am 20.10.2013 08:34, schrieb Daniel Campbell:
>>> hm, Redhat is one of the companies investing the most money into linux
>>> kernel, userland, graphics... if you 'don't trust them' you are pretty
>>> much 20 years too late.
>>> Investing money does not make them any more qualified or deserving of
>>> making decisions. Red Hat is not the sole user of Linux. They should
>>> consider themselves lucky that they are even able to profit from
>>> something that's free.
>>>
>>> You're right, though. They've been around for a while, and I've never
>>> trusted them or any other corporate interest in *nix. There's always a
>>> catch when dealing with a business.
>>>
>> 'have been around for a while' - replace that with 'are financing more
>> core developers than anybody else'.
>>
> That's less reason to trust, not more. That's like citing the popularity
> of something as proof of its quality, when oftentimes it's the exact
> opposite that's true.
>
> So they spend a lot of money hiring developers. The more important
> question is what is their agenda? What do they tell those developers to
> *make*? You don't hire people without a business plan in mind.
>
>
without Redhat, there would be no linux. gnu software would be massively
lacking and X would be without drivers.

So calm down.

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Daniel Campbell]

On 10/20/2013 06:02 AM, Volker Armin Hemmann wrote:
> Am 20.10.2013 12:52, schrieb Daniel Campbell:
>> On 10/20/2013 04:24 AM, Volker Armin Hemmann wrote:
>>> Am 20.10.2013 08:34, schrieb Daniel Campbell:
>>>> hm, Redhat is one of the companies investing the most money into linux
>>>> kernel, userland, graphics... if you 'don't trust them' you are pretty
>>>> much 20 years too late.
>>>> Investing money does not make them any more qualified or deserving of
>>>> making decisions. Red Hat is not the sole user of Linux. They should
>>>> consider themselves lucky that they are even able to profit from
>>>> something that's free.
>>>>
>>>> You're right, though. They've been around for a while, and I've never
>>>> trusted them or any other corporate interest in *nix. There's always a
>>>> catch when dealing with a business.
>>>>
>>> 'have been around for a while' - replace that with 'are financing more
>>> core developers than anybody else'.
>>>
>> That's less reason to trust, not more. That's like citing the popularity
>> of something as proof of its quality, when oftentimes it's the exact
>> opposite that's true.
>>
>> So they spend a lot of money hiring developers. The more important
>> question is what is their agenda? What do they tell those developers to
>> *make*? You don't hire people without a business plan in mind.
>>
>>
> without Redhat, there would be no linux. gnu software would be massively
> lacking and X would be without drivers.
> 
> So calm down.
> 
Linux was created and released in 1991, built with GNU tools. Red Hat
didn't come along until 1993. Linux and GNU would both still be here;
their quality without Red Hat involvement is speculative at best.

I maintain that motives matter more than money and that they (motives)
should continually be audited, especially when receiving contributions
from a company. They may already be; I don't know.

Re: drivers, do you expect me to believe Red Hat is responsible for
every X11 driver out there? How many of this list?[1] What of radeon and
nouveau? nvidia's own driver? xf86-input-wacom (and linuxwacom)[2]? I'm
sure Red Hat has contributed plenty to X11, but your statement is
flat-out false.

[1]: http://www.usinglinux.org/x11-drivers/
[2]: http://sourceforge.net/apps/mediawiki/linuxwacom/

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Samuli Suominen]

On 20/10/13 13:47, Daniel Campbell wrote:
> On 10/20/2013 04:55 AM, Samuli Suominen wrote:
>> On 20/10/13 12:24, Daniel Campbell wrote:
>>> On 10/20/2013 02:37 AM, Samuli Suominen wrote:
>>>> On 20/10/13 09:34, Daniel Campbell wrote:
>>>>> On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote:
>>>>>> Am 19.10.2013 17:02, schrieb Daniel Campbell:
>>>>>>> On 10/17/2013 11:27 PM, Mark David Dumlao wrote:
>>>>>>>> https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign
>>>>>>>>
>>>>>>>> Not sure if I read that just right... but since nobody is doing cgroup
>>>>>>>> management besides systemd, in practice the cgroups implementation in
>>>>>>>> Linux wasn't very consistent. So since systemd is doing it, their work
>>>>>>>> is helping shape the kernel's cgroups api?
>>>>>>>>
>>>>>>>> Interesting...
>>>>>>>>
>>>>>>> >From my perspective it looks like systemd developers are trying to push
>>>>>>> their ideas into the kernel, almost like they intend to merge systemd
>>>>>>> *with* the kernel. 
>>>>>> from what I read in the article cgroups are a mess and are cleaned up
>>>>>> anyway. The only real user of cgroups at the moment is systemd.
>>>>>> Others are welcome to make use of cgroups too. But in the current state
>>>>>> nobody blames them for not jumping in.
>>>>> No complaints here in improving something, but consider the source is
>>>>> all I'm saying.
>>>>>
>>>>>>> If systemd is the only implementation of cgroups and
>>>>>>> their developers are working on cgroup support in the kernel, it spells
>>>>>>> calamity given their history of evangelism and zealotry.
>>>>>> well, going over some old ml threads on fedora mailing lists all I could
>>>>>> find was that Poettering and Sievers DID listen and DID make changes if
>>>>>> the demand was high enough.
>>>>>>
>>>>>> Sure, I dislike systemd. Sure what happened with udev was a dick move.
>>>>>> But their 'zealotry' is a lot less developed than the zealotry of those
>>>>>> who exploded about using an 'init-thingy' in the future.
>>>>>>
>>>>> I'd say their zealotry is less loud and more persistent. Their way is
>>>>> best, UNIX (and its philosophy) is outmoded, people are thinking 30
>>>>> years behind where we are, etc etc etc. Those who have separate /usr and
>>>>> blame systemd for pushing them to use an initramfs aren't seeing the
>>>>> real problem (upstreams not putting things where they belong, FHS no
>>>>> longer *really* being worked on, generally just the filesystem being
>>>>> played with like a toy)
>>>>>
>>>>>>> I truly wish I understood why a single userland program and its
>>>>>>> developers are being given the keys to an entire subsystem of the
>>>>>>> kernel. 
>>>>>> they aren't.
>>>>> Of the people who have committed to the cgroup subsystem of the kernel,
>>>>> how many are not members of the systemd, GNOME, or Red Hat projects?
>>>>> I'll let that speak for itself.
>>>>>
>>>>>>> Their changes to udev have proven to be a headache for users,
>>>>>> yes? which ones?
>>>>> Persistent NIC naming, for starters. The former maintainer's idea to
>>>>> merge with systemd (which was influenced by Mr. Poettering in the first
>>>>> place) when the two are completely separate pieces of software that do
>>>>> two completely different jobs, and various other troubles with udev >
>>>>> 175 that one can Google for and find tons of results.
>>>> I can't find anything that would be true. Can you point out some?
>>>> A lot of FUD[1] and outright lies coming from people, who, for example,
>>>> don't like systemd.
>>>>
>>>> [1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt
>>>>
>>>> I know for a fact udev-208 is a full replacement for udev-171 in terms
>>>> that both work on same kernels, same libcs, and so forth. That's why
>>>> 171 is no longer in Portage, because it's completely useless from users
>>>> (and developers) point of view.
>>>>
>>>> Adjusting some configs and enabling some kernel options that have been
>>>> around for a long time is just part of normal maintenance process,
>>>> that's what we have admins for.
>>>>
>>> Do you know the design consequences of opt-in versus opt-out? I'll keep
>>> this short: When evolving a codebase, new behavior for core parts of the
>>> system should not be pushed or forced on users. If you must, keep the
>>> old behavior around as a default and allow users to try the new thing by
>>> explicitly opting in. The new naming in whichever udev started the mess
>>> did it the exact opposite (and wrong) way.
>>
>> It's not forced upon you. You received a news item that had instructions
>> on howto assign names you want, like lan0, internet1, wireless3, and so
>> forth.
>> And it also described howto turn off udev from completely renaming the
>> devices, to keep kernel assigned names.
>> What they did was they dropped the *broken* feature called 'persistent
>> rule_generator' which never worked correctly, and in
>> race conditions still flipped eth0 <-> eth1 around -- that was a
>> *security* flaw that *needed* to go.
>> It would have gone even without providing the alternative of providing
>> biosdevname -like new name optionality to the users.
>> Kernel and kernel drivers are designed in a way it's not supported to
>> flip in-place kernel names and udev tried to workaround that.
>>
>> https://www.kernel.org/doc/htmldocs/device-drivers/API-device-rename.html
>>
> Like I mentioned in a prior e-mail, the change didn't affect me when it
> was pushed, and doesn't affect me now. I did recently have to reinstall
> Gentoo, however (note, going from testing to stable isn't fun ;p), and
> noticed it when I found Gentoo ships with systemd-udev instead of eudev.

Yep, no plans on changing the default sys-fs/udev to anything else, no
reason to.

> I got the new naming and had to do some work to go back to what should
> be normal behavior. My `kernel` line remains with that switch in effect,
> but I'm not sure if eudev requires that flag to keep default behavior.
> Had udev's defaults been left alone, I wouldn't have had to go through
> any trouble to migrate back to eudev beyond the unmerge and emerge
> that's expected as part of a switch. That's where the design flaw rears
> its ugly head. I could see opposition to my view if I was trying to do
> something that the software simply wasn't designed to do, like cook my
> breakfast for me. Regardless, I was speaking purely from a design
> perspective; I succeeded in solving the problem (mostly) on my own, so
> no issues there.
>
> Perhaps the next time I need to install Gentoo, I'll find a way to get
> eudev on there before even the first proper boot and avoid the problem
> altogether.

It's true that sys-fs/eudev restored the *broken* rule_generator from
old sys-fs/udev, you can get it by USE="rule-generator".
But it's lot saner to keep using sys-fs/udev and just write custom rules
to rename interfaces based on MACs to like lan*, internet*
so all in all, currently, using sys-fs/eudev doesn't make sense unless
you are experimenting/developing for it.
For single NIC system, as you mentioned, you can just keep using
sys-fs/udev and use the kernel net.ifnames=0 parameter to keep
the interface at eth0.
Maybe there will be some differences in future that makes eudev
worthwhile, but that remains to be seen.

>>> *multi-NIC* use that wasn't as predictive and needed the fix, not
>>> *single*. It's basically using poor design/defaults decisions to smear
>>> existing technology dishonestly. Technical propaganda, so to speak.
>>>
>>> My beef with that decision is separate from my disdain for the decision
>>> to merge it with systemd, which is only mildly related to why I dislike
>>> systemd, but that's irrelevant.
>>>
>>> As for FUD, I see no reason to get personal. If you insist, we can take
>>> a look at which Gentoo package(s) you maintain that are related to the
>>> topic and ask ourselves if you are any less biased.
>>>
>> If you are hinting I'm someway favouring systemd, or udev for that
>> matter, you couldn't be more wrong. I use OpenRC, and I maintain
>> ConsoleKit/udev
>> out of necessity (because someone has to). I deal with facts, I have no
>> favouritism to any direction.
>> In contrast, I also maintain a bunch of software that allows people to
>> *skip* whole freedesktop.org stack (ConsoleKit, PolicyKit and so forth)
>> like pmount,
>> pmount-gui and such for minimal systems.
>>
> So you maintain them, but don't necessarily follow or agree with their
> goals/sentiments/designs? Does that ever create problems for you when
> trying to test systemd/udev on revbumps and whatnot? Do systemd
> proponents wonder why you don't use what you maintain? Honestly curious;
> I assumed that if you maintain something, you use it. Perhaps I was wrong.

Well, there is also the difference of liking something and using it for
myself at home and then using something
at work because it's just the quickest and cleanest way of achieving
something.
But of course I test everything boot related before committing them to
users. ;-)
There is really no conflict, I'm luckily in a position where I have
access to hundreds of systems.
But also that, what you said, it's possible to maintain something
without using it, that is to be determined package-by-package basis.

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Tanstaafl]

On 2013-10-20 9:02 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> On 20/10/13 13:47, Daniel Campbell wrote:
>> Like I mentioned in a prior e-mail, the change didn't affect me when it
>> was pushed, and doesn't affect me now. I did recently have to reinstall
>> Gentoo, however (note, going from testing to stable isn't fun ;p), and
>> noticed it when I found Gentoo ships with systemd-udev instead of eudev.

> Yep, no plans on changing the default sys-fs/udev to anything else, no
> reason to.

To be clear - you are saying that the new default init system for a new 
gentoo install is systemd?

When did this happen? I thought that OpenRC was still the default?

>> Perhaps the next time I need to install Gentoo, I'll find a way to get
>> eudev on there before even the first proper boot and avoid the problem
>> altogether.

> It's true that sys-fs/eudev restored the *broken* rule_generator from
> old sys-fs/udev, you can get it by USE="rule-generator".
> But it's lot saner to keep using sys-fs/udev and just write custom rules
> to rename interfaces based on MACs to like lan*, internet*
> so all in all, currently, using sys-fs/eudev doesn't make sense unless
> you are experimenting/developing for it.

The problem with this is, what happens if (or maybe *when*?) the systemd 
maintainers make a change that then breaks udev for anything but systemd?

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Samuli Suominen]

On 20/10/13 17:01, Tanstaafl wrote:
> On 2013-10-20 9:02 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
>> On 20/10/13 13:47, Daniel Campbell wrote:
>>> Like I mentioned in a prior e-mail, the change didn't affect me when it
>>> was pushed, and doesn't affect me now. I did recently have to reinstall
>>> Gentoo, however (note, going from testing to stable isn't fun ;p), and
>>> noticed it when I found Gentoo ships with systemd-udev instead of
>>> eudev.
>
>> Yep, no plans on changing the default sys-fs/udev to anything else, no
>> reason to.
>
> To be clear - you are saying that the new default init system for a
> new gentoo install is systemd?

No, I'm saying the default /dev manager in Gentoo has been sys-fs/udev
and will be sys-fs/udev

>
> When did this happen? I thought that OpenRC was still the default?

It is.

>
>>> Perhaps the next time I need to install Gentoo, I'll find a way to get
>>> eudev on there before even the first proper boot and avoid the problem
>>> altogether.
>
>> It's true that sys-fs/eudev restored the *broken* rule_generator from
>> old sys-fs/udev, you can get it by USE="rule-generator".
>> But it's lot saner to keep using sys-fs/udev and just write custom rules
>> to rename interfaces based on MACs to like lan*, internet*
>> so all in all, currently, using sys-fs/eudev doesn't make sense unless
>> you are experimenting/developing for it.
>
> The problem with this is, what happens if (or maybe *when*?) the
> systemd maintainers make a change that then breaks udev for anything
> but systemd?
>

That's a bridge we will cross when there is a bridge to be crossed, but
from top of my head:
We will maintain a minimal patchset that reverts the offending code.

As in, that's nothing to be worried about before it happens.

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Samuli Suominen]

On 20/10/13 17:01, Tanstaafl wrote:
>
>> It's true that sys-fs/eudev restored the *broken* rule_generator from
>> old sys-fs/udev, you can get it by USE="rule-generator".
>> But it's lot saner to keep using sys-fs/udev and just write custom rules
>> to rename interfaces based on MACs to like lan*, internet*
>> so all in all, currently, using sys-fs/eudev doesn't make sense unless
>> you are experimenting/developing for it.
>
> The problem with this is, what happens if (or maybe *when*?) the
> systemd maintainers make a change that then breaks udev for anything
> but systemd?
>

To continue my previous reply. That has already happened once. That's
why we implemented /dev tmpfiles.d support for OpenRC 0.12, that's why
>=sys-apps/kmod-15
is now requiring >=sys-apps/openrc-0.12.
So it's case-by-case basis.

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Tanstaafl]

On 2013-10-20 6:52 AM, Daniel Campbell <lists@sporkbox.us> wrote:
> So they spend a lot of money hiring developers. The more important
> question is what is their agenda? What do they tell those developers to
> *make*? You don't hire people without a business plan in mind.

Well, once I understood their (Redhat's) motivation, which was/is 
enterprise/cloud/vm oriented (which is why they were so concerned about 
parallelism for startup, etc) - I dropped the conspiracy theory aspect 
of it all... it actually does make sense in that context.

And as long as Linus is at the helm of kernel development, I'm not too 
worried about the systemd guys doing too much damage there - I just 
can't see him letting it happen.

If I were the type to worry just for the sake of worrying, I'd be 
wondering what may happen down the road, if Linus were to suddenly lose 
interest in kernel development (for whatever reason) and walk away from 
it - who/what would take over the reins? But that would be pointless...

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Mark David Dumlao]

[-- Attachment #1: Type: text/plain, Size: 1683 bytes --]

On Oct 20, 2013 10:44 PM, "Tanstaafl" <tanstaafl@libertytrek.org> wrote:
>
> On 2013-10-20 6:52 AM, Daniel Campbell <lists@sporkbox.us> wrote:
>>
>> So they spend a lot of money hiring developers. The more important
>> question is what is their agenda? What do they tell those developers to
>> *make*? You don't hire people without a business plan in mind.
>
>
> Well, once I understood their (Redhat's) motivation, which was/is
enterprise/cloud/vm oriented (which is why they were so concerned about
parallelism for startup, etc) - I dropped the conspiracy theory aspect of
it all... it actually does make sense in that context.
>
> And as long as Linus is at the helm of kernel development, I'm not too
worried about the systemd guys doing too much damage there - I just can't
see him letting it happen.
>
> If I were the type to worry just for the sake of worrying, I'd be
wondering what may happen down the road, if Linus were to suddenly lose
interest in kernel development (for whatever reason) and walk away from it
- who/what would take over the reins? But that would be pointless...
>

Linus isnt actually actively developing the kernel nowadays. Mostly he just
merges commits from his "trusted lieutenants" in charge of various
subsystems. The notion of Linus as being at the helm is mostly just a
convenient fiction that corporate culture (and by extension, the media) -
which is used to "strong leadership" - uses to make sense of open source
development.

That's partly why he finds it funny when people take his flames too
seriously, as if they were Word of God.

If he took were cut down by a sith lord, most likely morton's tree would
seamlessly be the new upstream.

[-- Attachment #2: Type: text/html, Size: 2004 bytes --]

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Walter Dnes]

On Sun, Oct 20, 2013 at 05:03:51PM +0300, Samuli Suominen wrote

> That's a bridge we will cross when there is a bridge to be crossed, but
> from top of my head:
> We will maintain a minimal patchset that reverts the offending code.
> 
> As in, that's nothing to be worried about before it happens.

  That's not always possible, e.g. GNOME 3.8.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Daniel Campbell]

On 10/20/2013 09:34 PM, Walter Dnes wrote:
> On Sun, Oct 20, 2013 at 05:03:51PM +0300, Samuli Suominen wrote
> 
>> That's a bridge we will cross when there is a bridge to be crossed, but
>> from top of my head:
>> We will maintain a minimal patchset that reverts the offending code.
>>
>> As in, that's nothing to be worried about before it happens.
> 
>   That's not always possible, e.g. GNOME 3.8.
> 
I think that's an exception to the rule. I mean, upstream deliberately
chose to depend on systemd/logind and whatnot. In such a situation
there's literally no way to fix it without a fork, and I doubt Gentoo as
an organization is interested in that.

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Samuli Suominen]

On 21/10/13 05:34, Walter Dnes wrote:
> On Sun, Oct 20, 2013 at 05:03:51PM +0300, Samuli Suominen wrote
>
>> That's a bridge we will cross when there is a bridge to be crossed, but
>> from top of my head:
>> We will maintain a minimal patchset that reverts the offending code.
>>
>> As in, that's nothing to be worried about before it happens.
>   That's not always possible, e.g. GNOME 3.8.
>

Yes, but it was Gentoo Gnome Teams decision to keep packaging Gnome
after they (I mean, GNOME upstream) introduced systemd hard dependency
instead of switching to eg. MATE, or helping out with Xfce, etc, and
sticking to the distribution default (OpenRC)
And then it's yours (I mean, users) decision to keep on using Gnome
despite of it

As we were talking about core, like kernel and part of the userland boot
process, I'm just trying to say that Gnome is not important part of the
core system, it's just one of the desktops among others, despite of it's
past (and current) popularity

Now I have to admit I'm biased, I used to use GNOME 2.x in past but I've
been with Xfce for years now, so I can only imagine what hardcore GNOME
users think of all this,
if the same thing happened to Xfce, I'd very very much pissed off -- to
a point I'd rip out whole systemd support out of the code and package it
with limited functionality
rather than introducing systemd harddep

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Samuli Suominen]

On 21/10/13 08:31, Daniel Campbell wrote:
> On 10/20/2013 09:34 PM, Walter Dnes wrote:
>> On Sun, Oct 20, 2013 at 05:03:51PM +0300, Samuli Suominen wrote
>>
>>> That's a bridge we will cross when there is a bridge to be crossed, but
>>> from top of my head:
>>> We will maintain a minimal patchset that reverts the offending code.
>>>
>>> As in, that's nothing to be worried about before it happens.
>>   That's not always possible, e.g. GNOME 3.8.
>>
> I think that's an exception to the rule. I mean, upstream deliberately
> chose to depend on systemd/logind and whatnot. In such a situation
> there's literally no way to fix it without a fork, and I doubt Gentoo as
> an organization is interested in that.
>

well said

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Tanstaafl]

On 2013-10-20 9:14 PM, Mark David Dumlao <madumlao@gmail.com> wrote:
> Linus isnt actually actively developing the kernel nowadays. Mostly he
> just merges commits from his "trusted lieutenants" in charge of various
> subsystems. The notion of Linus as being at the helm is mostly just a
> convenient fiction that corporate culture (and by extension, the media)
> - which is used to "strong leadership" - uses to make sense of open
> source development.

I know all that, but he does have the final word on merges still, right? 
Which is the most important aspect of the point at hand...

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Mark David Dumlao]

On Mon, Oct 21, 2013 at 5:55 PM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 2013-10-20 9:14 PM, Mark David Dumlao <madumlao@gmail.com> wrote:
>>
>> Linus isnt actually actively developing the kernel nowadays. Mostly he
>> just merges commits from his "trusted lieutenants" in charge of various
>> subsystems. The notion of Linus as being at the helm is mostly just a
>> convenient fiction that corporate culture (and by extension, the media)
>> - which is used to "strong leadership" - uses to make sense of open
>> source development.
>
>
> I know all that, but he does have the final word on merges still, right?
> Which is the most important aspect of the point at hand...
>

I doubt he actually has the time to read every line of code submitted
to the kernel, being that in 2008, it was running at 6000+ lines /
changes per day and it's only gotten faster.

Again, most of kernel development is very largely self-organizing.
There are of course, rally points around some personalities, but it's
an exaggeration of trust to rely on Linus to be the gatekeeper for
political decisions. Especially since he famously dislikes getting
involved in politics.

http://www.youtube.com/watch?v=L2SED6sewRw

tldr: if the maintainer of some subsystem agrees, it's probably in. It
takes a lot of trust to get to become a maintainer.

-- 
This email is:    [ ] actionable   [x] fyi        [ ] social
Response needed:  [ ] yes          [ ] up to you  [x] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Tanstaafl]

On 2013-10-21 6:11 AM, Mark David Dumlao <madumlao@gmail.com> wrote:
> I doubt he actually has the time to read every line of code submitted
> to the kernel,

That isn't what I meant at all...

What he *does* have the power to do, though, is if someone was able to 
sneak in something outrageously bad that caused breakage, he would rip 
it out at its roots, and probably make sure that whoever was responsible 
for it getting in was either properly chastised (if it was 
unintentional), or

> tldr: if the maintainer of some subsystem agrees, it's probably in. It
> takes a lot of trust to get to become a maintainer.

that trust would be lost, maybe for good.

And by the way, it is this trust that you speak of that is one of the 
main reasons why I'm not worried about this. Linus has good people 
around him, and none of them would allow something like it to happen either.

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Mark David Dumlao]

On Mon, Oct 21, 2013 at 6:27 PM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 2013-10-21 6:11 AM, Mark David Dumlao <madumlao@gmail.com> wrote:
>>
>> I doubt he actually has the time to read every line of code submitted
>> to the kernel,
>
>
> That isn't what I meant at all...
>
> What he *does* have the power to do, though, is if someone was able to sneak
> in something outrageously bad that caused breakage, he would rip it out at
> its roots, and probably make sure that whoever was responsible for it
> getting in was either properly chastised (if it was unintentional), or
>

Again. This power is overstated and overtrusted. As for "rip it out at
its roots" he has no ability to do that, only refuse to merge it in
his tree. But that's only if he bothers to read it. With all the other
stuff he's working on, he signs off less commits than all the other
maintainers do.

The news sites love making a big deal of him flaming this or that
developer or company, but I can't remember that ever stopping anyone
from doing what they wanted.

>
>> tldr: if the maintainer of some subsystem agrees, it's probably in. It
>> takes a lot of trust to get to become a maintainer.
>
>
> that trust would be lost, maybe for good.
>
> And by the way, it is this trust that you speak of that is one of the main
> reasons why I'm not worried about this. Linus has good people around him,
> and none of them would allow something like it to happen either.
>

I'm just explaining your overstatement of "trust" and I don't know
what this "something like this" is referring to. Obviously "broken
changes" isn't something to commit and is embarassing. But if you're
talking about Lennart-FUD, I will point you to
/usr/src/linux/doc/ManagementStyle

"""
Btw, another way to avoid a decision is to plaintively just whine "can't
we just do both?" and look pitiful.  Trust me, it works.  If it's not
clear which approach is better, they'll eventually figure it out.  The
answer may end up being that both teams get so frustrated by the
situation that they just give up.
"""

That's kind of the official kernel stance on "future of kernel
development" bla bla bla. If it's maintainable, they merge it, because
you can't really tell if one approach is going to "win" until it later
does.

-- 
This email is:    [ ] actionable   [ ] fyi        [ ] social
Response needed:  [ ] yes          [ ] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [ ] none

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Tanstaafl]

On 2013-10-21 6:48 AM, Mark David Dumlao <madumlao@gmail.com> wrote:
> Again. This power is overstated and overtrusted. As for "rip it out at
> its roots" he has no ability to do that, only refuse to merge it in
> his tree.

Which I believe is a much bigger deal than you seem to think.

> But that's only if he bothers to read it. With all the other
> stuff he's working on, he signs off less commits than all the other
> maintainers do.

<sigh> irrelevant, because I was talking about something that was 
discovered *after* it was merged... obviously, if something is merged 
that creates a problem (or loud complaints, or whatever), at *that* 
point he will certainly take the time to 'read it' and decide if there 
is anything to it...

> The news sites love making a big deal of him flaming this or that
> developer or company, but I can't remember that ever stopping anyone
> from doing what they wanted.

Lol... really? You don't consider him rejecting a patch, whether or not 
it is rejected 'nicely' or not - 'stopping' said dev from 'doing what 
they wanted (ie, get their patch merged)?

Anyway, it really doesn't matter, so no reason to continue this 
discussion...

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Mark David Dumlao]

[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]

On Oct 21, 2013 7:01 PM, "Tanstaafl" <tanstaafl@libertytrek.org> wrote:
>
> On 2013-10-21 6:48 AM, Mark David Dumlao <madumlao@gmail.com> wrote:
>>
>> Again. This power is overstated and overtrusted. As for "rip it out at
>> its roots" he has no ability to do that, only refuse to merge it in
>> his tree.
>
>
> Which I believe is a much bigger deal than you seem to think.
>
>
>> But that's only if he bothers to read it. With all the other
>> stuff he's working on, he signs off less commits than all the other
>> maintainers do.
>
>
> <sigh> irrelevant, because I was talking about something that was
discovered *after* it was merged... obviously, if something is merged that
creates a problem (or loud complaints, or whatever), at *that* point he
will certainly take the time to 'read it' and decide if there is anything
to it...
>

Read the management style doc. Seriously, it describes the kernel's outlook
on mistakes.

Ostracization and talk of severing limbs like cancer tumors, as is often
brought up by tinfoilers here, is not how it works. Code talks. Bad, hard
to maintain code is its own insult.

[-- Attachment #2: Type: text/html, Size: 1450 bytes --]

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Tanstaafl]

On 2013-10-21 7:10 AM, Mark David Dumlao <madumlao@gmail.com> wrote:
> Read the management style doc. Seriously, it describes the kernel's
> outlook on mistakes.

My main point wasn't about 'mistakes' and you know it, so please stop 
being so obtuse.

> Ostracization and talk of severing limbs like cancer tumors, as is often
> brought up by tinfoilers here, is not how it works. Code talks. Bad,
> hard to maintain code is its own insult.

You mean like the code that Lennart and company often write (intentional 
or not)?

What are people called who use terms like 'tinfoilers' to try to 
discredit legitimate complaints or facts?

Anyway, we're way OT now, so this will be my last post on the subject so 
feel free to 'get in the last word' if it makes you feel better.

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Volker Armin Hemmann]

Am 20.10.2013 13:18, schrieb Daniel Campbell:
> On 10/20/2013 06:02 AM, Volker Armin Hemmann wrote:
>> Am 20.10.2013 12:52, schrieb Daniel Campbell:
>>> On 10/20/2013 04:24 AM, Volker Armin Hemmann wrote:
>>>> Am 20.10.2013 08:34, schrieb Daniel Campbell:
>>>>> hm, Redhat is one of the companies investing the most money into linux
>>>>> kernel, userland, graphics... if you 'don't trust them' you are pretty
>>>>> much 20 years too late.
>>>>> Investing money does not make them any more qualified or deserving of
>>>>> making decisions. Red Hat is not the sole user of Linux. They should
>>>>> consider themselves lucky that they are even able to profit from
>>>>> something that's free.
>>>>>
>>>>> You're right, though. They've been around for a while, and I've never
>>>>> trusted them or any other corporate interest in *nix. There's always a
>>>>> catch when dealing with a business.
>>>>>
>>>> 'have been around for a while' - replace that with 'are financing more
>>>> core developers than anybody else'.
>>>>
>>> That's less reason to trust, not more. That's like citing the popularity
>>> of something as proof of its quality, when oftentimes it's the exact
>>> opposite that's true.
>>>
>>> So they spend a lot of money hiring developers. The more important
>>> question is what is their agenda? What do they tell those developers to
>>> *make*? You don't hire people without a business plan in mind.
>>>
>>>
>> without Redhat, there would be no linux. gnu software would be massively
>> lacking and X would be without drivers.
>>
>> So calm down.
>>
> Linux was created and released in 1991, built with GNU tools. Red Hat
> didn't come along until 1993. Linux and GNU would both still be here;
> their quality without Red Hat involvement is speculative at best.

no, it is not. Several of the most important Kernel devs are or were
Redhat developers.

So you just showed that you have no clue at all. You should stop right
there.

> I maintain that motives matter more than money and that they (motives)
> should continually be audited, especially when receiving contributions
> from a company. They may already be; I don't know.
>
> Re: drivers, do you expect me to believe Red Hat is responsible for
> every X11 driver out there?
no, but they paid a lot of developers working on several drivers.

For example David Airlie is employed by Redhat.

Look him up.


>  How many of this list?[1] What of radeon and

radeon? David Airlie again.

> nouveau? nvidia's own driver? xf86-input-wacom (and linuxwacom)[2]? I'm
> sure Red Hat has contributed plenty to X11, but your statement is
> flat-out false.

nope. Your statements lack any connection to reality.

since you like links, think about this one for a while:

https://www.linux.com/learn/tutorials/560928-counting-contributions-who-wrote-linux-32
http://www.linuxfoundation.org/news-media/announcements/2012/04/linux-foundation-releases-annual-linux-development-report

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Volker Armin Hemmann]

Am 21.10.2013 11:55, schrieb Tanstaafl:
> On 2013-10-20 9:14 PM, Mark David Dumlao <madumlao@gmail.com> wrote:
>> Linus isnt actually actively developing the kernel nowadays. Mostly he
>> just merges commits from his "trusted lieutenants" in charge of various
>> subsystems. The notion of Linus as being at the helm is mostly just a
>> convenient fiction that corporate culture (and by extension, the media)
>> - which is used to "strong leadership" - uses to make sense of open
>> source development.
>
> I know all that, but he does have the final word on merges still,
> right? Which is the most important aspect of the point at hand...
>
> .
>

and when he goes in, he chooses the most trickiest parts of the kernel
(vfs).

Just go to any lkml archive and search for his threads with Al Viro.

Scary.

Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Daniel Campbell]

On 10/21/2013 03:33 PM, Volker Armin Hemmann wrote:
> Am 20.10.2013 13:18, schrieb Daniel Campbell:
>> On 10/20/2013 06:02 AM, Volker Armin Hemmann wrote:
>>> Am 20.10.2013 12:52, schrieb Daniel Campbell:
>>>> On 10/20/2013 04:24 AM, Volker Armin Hemmann wrote:
>>>>> Am 20.10.2013 08:34, schrieb Daniel Campbell:
>>>>>> hm, Redhat is one of the companies investing the most money into linux
>>>>>> kernel, userland, graphics... if you 'don't trust them' you are pretty
>>>>>> much 20 years too late.
>>>>>> Investing money does not make them any more qualified or deserving of
>>>>>> making decisions. Red Hat is not the sole user of Linux. They should
>>>>>> consider themselves lucky that they are even able to profit from
>>>>>> something that's free.
>>>>>>
>>>>>> You're right, though. They've been around for a while, and I've never
>>>>>> trusted them or any other corporate interest in *nix. There's always a
>>>>>> catch when dealing with a business.
>>>>>>
>>>>> 'have been around for a while' - replace that with 'are financing more
>>>>> core developers than anybody else'.
>>>>>
>>>> That's less reason to trust, not more. That's like citing the popularity
>>>> of something as proof of its quality, when oftentimes it's the exact
>>>> opposite that's true.
>>>>
>>>> So they spend a lot of money hiring developers. The more important
>>>> question is what is their agenda? What do they tell those developers to
>>>> *make*? You don't hire people without a business plan in mind.
>>>>
>>>>
>>> without Redhat, there would be no linux. gnu software would be massively
>>> lacking and X would be without drivers.
>>>
>>> So calm down.
>>>
>> Linux was created and released in 1991, built with GNU tools. Red Hat
>> didn't come along until 1993. Linux and GNU would both still be here;
>> their quality without Red Hat involvement is speculative at best.
> 
> no, it is not. Several of the most important Kernel devs are or were
> Redhat developers.
> 
> So you just showed that you have no clue at all. You should stop right
> there.
I do "have a clue", but there is logically no way to say, for sure, that
Linux and GNU would be worse off without Red Hat's existence. Why?
Because we only know what happened _with_ their existence. The assertion
can't be validated or even tested without somehow going back in time and
preventing Red Hat from forming. It's an empty assertion.

> 
>> I maintain that motives matter more than money and that they (motives)
>> should continually be audited, especially when receiving contributions
>> from a company. They may already be; I don't know.
>>
>> Re: drivers, do you expect me to believe Red Hat is responsible for
>> every X11 driver out there?
> no, but they paid a lot of developers working on several drivers.
> 
> For example David Airlie is employed by Redhat.
> 
> Look him up.
> 
The "no" is all I need to see. You said "X would be without drivers". So
unless Red Hat employees wrote every line of the X driver code
(unlikely) or produced every single X driver available (proven false),
the assertion is false.
> 
>>  How many of this list?[1] What of radeon and
> 
> radeon? David Airlie again.
> 
>> nouveau? nvidia's own driver? xf86-input-wacom (and linuxwacom)[2]? I'm
>> sure Red Hat has contributed plenty to X11, but your statement is
>> flat-out false.
> 
> nope. Your statements lack any connection to reality.
> 
> since you like links, think about this one for a while:
> 
> https://www.linux.com/learn/tutorials/560928-counting-contributions-who-wrote-linux-32
> http://www.linuxfoundation.org/news-media/announcements/2012/04/linux-foundation-releases-annual-linux-development-report
> 
> 

My statements reflect the truth that Red Hat contributed to, but did not
single-handedly *build*, the GNU/Linux operating system. Without their
existence, there's no proof that the same drivers (X11 or otherwise)
wouldn't be written by some other people. Like I said, speculative at
best. On both sides.

Your links truthfully reflect that Red Hat contributes the most changes
of any company. A majority of something does not magically make it
perfect or good or whatever other mythical ideal one can conjure.

The links prove that Red Hat guides a lot of the changes. Taking a look
at the pdf[1] from 2012, Red Hat's contribution percentage, compared to
other companies, is rather high (11.9%, p.10). Almost double the next
highest contributor (Novell, at 6.4%). Why would a company invest that
much effort into something open and free if there was no agenda, no
business plan, no grander scheme or vision?

I'm sure some of their work is good. Nothing's all bad or all good. But
a company should not be trusted simply because they throw money at
something or have the most people working on something compared to other
companies. That's reason to be *suspicious*. A business does not throw
money at something unless they plan on capitalizing on it in some way.

[1]: http://go.linuxfoundation.org/who-writes-linux-2012

[gentoo-user] Re: systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Steven J. Long]

Daniel Campbell wrote:
> Do you know the design consequences of opt-in versus opt-out? I'll keep
> this short: When evolving a codebase, new behavior for core parts of the
> system should not be pushed or forced on users. If you must, keep the
> old behavior around as a default and allow users to try the new thing by
> explicitly opting in. The new naming in whichever udev started the mess
> did it the exact opposite (and wrong) way.

Good luck with that argument; you have to bear in mind Gentoo devs are
mostly fresh out of Uni (or still in it.) They're not very experienced iow,
as a rule, apart from in Gentoo ebuilds and making the tree work together,
which is all we ask of them. Oh and usually Java from Uni; they typically
have a snobbery about shell as well (and doesn't it show) which is quite
amusing when one considers their implementation language.

(No this is not to the topic per se: it's a wider point that I had to
repeat to someone recently, who apparently found the insight very useful.
So I put it out there for other users, or those to come.

I have zero interest in arguing the toss with anyone: you're welcome to
your opinion, that's mine. You ain't gonna change it, so don't bother
trying. Feel free to rant amongst yourselves. ;)

The point is that this is actually why Gentoo is a very good place for a
"developer" to cut hir teeth: they learn from the other users when they
install, and usually come up through the forums, where if you've ever
been to OTW, the difference between a personal attack and criticism of
someone's work is blatantly obvious. Further they have to run any major
design ideas past that same experienced user-base, who had the rough
edges knocked off ages ago, and simply want it to work for everyone.

They don't always see it like that, ofc, but I for one remember thinking
much dumber things. [1]

> The way the new behavior was introduced may have led users of single-NIC
> systems to believe that the old way was broken, when as demonstrated
> through past use, works *just fine* for single-NIC machines. It was
> *multi-NIC* use that wasn't as predictive and needed the fix, not
> *single*. It's basically using poor design/defaults decisions to smear
> existing technology dishonestly. Technical propaganda, so to speak.

Even more amusing when you consider that the original race that was so
terrible it justified breaking the machines of those it was supposedly
in aid of, as well as those of people who had zero use for it, yet were
apparently the target market, was in fact implemented by the same set
of "early userspace experts" who put themselves forward as such 5 years
previously.

I personally have no words to describe such a situation beyond "idiocy".

> Getting back to the original topic, cgroups sound like a pretty neat
> idea that other init systems could benefit from. If the systemd guys are
> willing to work on that subsystem for themselves, are they also
> interested in seeing what other init systems would want from cgroups?

This is actually what I posted about: I know qnikst already implemented
a large chunk of functionality in openrc and was concerned about the
"proposed changes" mainly because as usual it was a grand statement of
intent, with little in the way of coherent content. But we're spitting in
the wind: you can't expect amateurs who've backed themselves into a
corner, full of ego-attachment to their "work", to ever admit it's crap,
or that they fscked-up. Certainly not based on the record of this team.

> Certainly there's more room for development and/or standardization on an
> API instead of a single project having all the influence. I think their
> presence and activity with cgroups could be beneficial if policed by
> another init system project that's not trying to infect every Linux
> distro.

Yes one would think before embarking on such a venture they'd at least
take a look at other things that also run on Linux in the same domain, such
as s6, runit or openrc. But no, systemd is allowed to take them over, but
no consideration can be given to those use-cases, because "this is only
about cgroups." It's orthogonal, maan.

You're not alone; careful though as you just get labelled a "hater" even
when you've tried your damndest to collaborate with the "other side" (who
are the only ones even interested in "sides") only to come up against
groupthink, double-speak, and monkeys flinging poo.

"You're not with us so you *must* be against us!"

"No. We just do not care."

"Ah you is haterz."

"Bye then; enjoy the kool-aid."

[1] http://www.iusedtobelieve.com/
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-user] Re: systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Daniel Campbell]

On 10/23/2013 05:51 PM, Steven J. Long wrote:
> Daniel Campbell wrote:
>> Do you know the design consequences of opt-in versus opt-out? I'll keep
>> this short: When evolving a codebase, new behavior for core parts of the
>> system should not be pushed or forced on users. If you must, keep the
>> old behavior around as a default and allow users to try the new thing by
>> explicitly opting in. The new naming in whichever udev started the mess
>> did it the exact opposite (and wrong) way.
> 
> Good luck with that argument; you have to bear in mind Gentoo devs are
> mostly fresh out of Uni (or still in it.) They're not very experienced iow,
> as a rule, apart from in Gentoo ebuilds and making the tree work together,
> which is all we ask of them. Oh and usually Java from Uni; they typically
> have a snobbery about shell as well (and doesn't it show) which is quite
> amusing when one considers their implementation language.
> 
> (No this is not to the topic per se: it's a wider point that I had to
> repeat to someone recently, who apparently found the insight very useful.
> So I put it out there for other users, or those to come.
> 
> I have zero interest in arguing the toss with anyone: you're welcome to
> your opinion, that's mine. You ain't gonna change it, so don't bother
> trying. Feel free to rant amongst yourselves. ;)
I know you said you won't argue about it, and that's fine. I'm not sure
how fair it is to broadly denigrate the Gentoo devs, though. There are
so many, with varying levels of experience, specialty, and education,
that it would be difficult to put them into a neat label box. Among all
the distributions out there that run Linux as the kernel, I think Gentoo
is probably the most compatible in terms of choices. They do a good job
of making sure OpenRC, sysv, systemd, runit, and others are possible on
Gentoo. Perhaps you know more about some of the devs than I, though. I'm
just a user who aspires to become an official developer to learn more
about it.

> 
> The point is that this is actually why Gentoo is a very good place for a
> "developer" to cut hir teeth: they learn from the other users when they
> install, and usually come up through the forums, where if you've ever
> been to OTW, the difference between a personal attack and criticism of
> someone's work is blatantly obvious. Further they have to run any major
> design ideas past that same experienced user-base, who had the rough
> edges knocked off ages ago, and simply want it to work for everyone.
> 
> They don't always see it like that, ofc, but I for one remember thinking
> much dumber things. [1]
Well, the udev behavior I was discussing isn't really the fault of
Gentoo devs. It was just the default for udev, as shipped by upstream.
My guess is the devs decided to opt for the default so those who planned
on using the new behavior (and/or GNOME 3.8) wouldn't have to do
additional configuration... at the expense of everyone else having to if
they wanted to retain the net.ifnames behavior. They were screwed no
matter what, really. Had the systemd/udev guys not created the new
behavior, Gentoo's devs wouldn't have had to make a decision that they
knew wouldn't please everyone.

> 
>> The way the new behavior was introduced may have led users of single-NIC
>> systems to believe that the old way was broken, when as demonstrated
>> through past use, works *just fine* for single-NIC machines. It was
>> *multi-NIC* use that wasn't as predictive and needed the fix, not
>> *single*. It's basically using poor design/defaults decisions to smear
>> existing technology dishonestly. Technical propaganda, so to speak.
> 
> Even more amusing when you consider that the original race that was so
> terrible it justified breaking the machines of those it was supposedly
> in aid of, as well as those of people who had zero use for it, yet were
> apparently the target market, was in fact implemented by the same set
> of "early userspace experts" who put themselves forward as such 5 years
> previously.
> 
> I personally have no words to describe such a situation beyond "idiocy".
Pretty much agreed. Self-proclaiming as an expert has such an air of
egotism it's hard to take it seriously.

> 
>> Getting back to the original topic, cgroups sound like a pretty neat
>> idea that other init systems could benefit from. If the systemd guys are
>> willing to work on that subsystem for themselves, are they also
>> interested in seeing what other init systems would want from cgroups?
> 
> This is actually what I posted about: I know qnikst already implemented
> a large chunk of functionality in openrc and was concerned about the
> "proposed changes" mainly because as usual it was a grand statement of
> intent, with little in the way of coherent content. But we're spitting in
> the wind: you can't expect amateurs who've backed themselves into a
> corner, full of ego-attachment to their "work", to ever admit it's crap,
> or that they fscked-up. Certainly not based on the record of this team.
Agreed. To this day, "PulseAudio" is still synonymous with "my sound
doesn't work" for some people, even though Mr. Poettering no longer
works on it (to my knowledge).

I actually think some of the ideas in both PA and systemd have merit,
but the implementations are so far off base or so ambitious that it
becomes an all-or-nothing decision instead of the usual "micromanaging"
or "piecemeal" package choosing that most of us (I assume) are
accustomed to. So instead of making one decision at a time, choosing a
package of Poettering's means you're committing to more than one
decision. His aren't the only packages like it; one could run the same
argument for other projects that try to do a bit too much for one package.
> 
>> Certainly there's more room for development and/or standardization on an
>> API instead of a single project having all the influence. I think their
>> presence and activity with cgroups could be beneficial if policed by
>> another init system project that's not trying to infect every Linux
>> distro.
> 
> Yes one would think before embarking on such a venture they'd at least
> take a look at other things that also run on Linux in the same domain, such
> as s6, runit or openrc. But no, systemd is allowed to take them over, but
> no consideration can be given to those use-cases, because "this is only
> about cgroups." It's orthogonal, maan.
> 
> You're not alone; careful though as you just get labelled a "hater" even
> when you've tried your damndest to collaborate with the "other side" (who
> are the only ones even interested in "sides") only to come up against
> groupthink, double-speak, and monkeys flinging poo.
> 
> "You're not with us so you *must* be against us!"
> 
> "No. We just do not care."
> 
> "Ah you is haterz."
> 
> "Bye then; enjoy the kool-aid."
> 
> [1] http://www.iusedtobelieve.com/
> 
To be fair, I lack the experience and knowledge in the problem domain to
collaborate with whoever plans on hacking cgroups. I'm just concerned
that other init systems may become locked out of cgroup functionality
until/unless they use an API that requires them to adopt a software
architecture/design similar to systemd's. It's dangerous, to me, to let
ambitious people work on core parts of a large project. They can't be
trusted to remain neutral to all userland software that may depend on it.

Nice link, btw. :)