Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
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
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
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?
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?
On 2013-10-20 9:14 PM, Mark David Dumlao madum...@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?
On Mon, Oct 21, 2013 at 5:55 PM, Tanstaafl tansta...@libertytrek.org wrote: On 2013-10-20 9:14 PM, Mark David Dumlao madum...@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?
On 2013-10-21 6:11 AM, Mark David Dumlao madum...@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?
On Mon, Oct 21, 2013 at 6:27 PM, Tanstaafl tansta...@libertytrek.org wrote: On 2013-10-21 6:11 AM, Mark David Dumlao madum...@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?
On 2013-10-21 6:48 AM, Mark David Dumlao madum...@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?
On Oct 21, 2013 7:01 PM, Tanstaafl tansta...@libertytrek.org wrote: On 2013-10-21 6:48 AM, Mark David Dumlao madum...@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.
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On 2013-10-21 7:10 AM, Mark David Dumlao madum...@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?
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?
Am 21.10.2013 11:55, schrieb Tanstaafl: On 2013-10-20 9:14 PM, Mark David Dumlao madum...@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?
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?
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?
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
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
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?
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
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
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
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
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?
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?
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?
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
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
On 2013-10-20 9:02 AM, Samuli Suominen ssuomi...@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?
On 20/10/13 17:01, Tanstaafl wrote: On 2013-10-20 9:02 AM, Samuli Suominen ssuomi...@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?
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?
On 2013-10-20 6:52 AM, Daniel Campbell li...@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?
On Oct 20, 2013 10:44 PM, Tanstaafl tansta...@libertytrek.org wrote: On 2013-10-20 6:52 AM, Daniel Campbell li...@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.
Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
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 waltd...@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?
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?
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?
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.
[gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?
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
