Re: OT: Open letter to the Linux World
On Fri, Apr 10, 2015 at 4:20 PM, Aaro Koskinen wrote: > Hi, > > On Wed, Apr 08, 2015 at 07:37:15PM -0500, Rob Landley wrote: >> Heck, the FSF's entire "It's GNU Linux, Dammit! Call it by its proper >> name: GNU/Linux/dammit" campaign is seriously irritating, and part of >> what I was doing with busybox was trying to create a linux development >> system without a single gnu package in it (busybox, uclibc, tinycc) >> capable of rebuilding itself under itself, and then ask Stallman "I >> know you're going to insist this isn't a Linux system but a >> GNU/Linux/Dammit system, I'd just like you to try to explain _how_." >> (Preferably capturing this on video.) > > What was the result of this work? http://landley.net/aboriginal/about.html My old self-hosting system was 7 packages: linux, busybox, uClibc, gmake, gcc, binutils, and bash. The new one I'd like to do is 4 packages: linux, toybox, musl, and qcc. Right now, I'm focusing on getting toybox to 1.0 as fast as possible, then I worry about other stuff. > Did you manage to build a self-hosting system? Yeah, but it's still using a gcc toolchain. (The last gplv2 release of gcc, binutils, and make, circa 2006.) I was going to replace it with http://landley.net/code/tinycc (and then http://landley.net/code/qcc). The idea was to take my tcc fork and make it a multiplexer like busybox (so it could run as cc, ld, strip, as, and so on depending on what name you called it under; one binary with lots of symlinks to it). The qcc idea was to rip out tcc's code generator and replace it with QEMU's tcg (tiny code generator), so you'd turn the compiler behind http://bellard.org/tcc/tccboot.html (I.E. this already _built_ a working kernel at one point, albeit with a lot of cheating that I was working to fix) and make it support all the targets qemu does, leveraging qemu's developer base to keep them well-supported. _AND_ I got permission to BSD license his tcc code, and qemu's tcg is already BSD licensed, so that fixes the license problem. But I got distracted by toybox (the history is https://lwn.net/Articles/478308/ then https://www.youtube.com/watch?v=SGmtP5Lg_t0 then https://lwn.net/Articles/629362/ and I'm currently dealing with merging http://lists.landley.net/pipermail/toybox-landley.net/2015-April/004024.html and yes that's the Android Core maintainer posting to the toybox list). So I've been kinda busy with other things of late. :) These days I'm waiting for llvm to mature, but a month or two back somebody picked up my qcc idea (combine tinycc's front end with tcg's back end to get a simple bsd licensed C99 compiler that supports a lot of targets) and actually started seriously working on it. So at this point I'm looking to contribute to _his_ project. (I'd link to him but I'm in japan at the moment and those files are back in texas. Ping me after the 20th if you're still curious.) > What implementation of "make" did you use to build the kernel? I plan on writing my own, but it's a bit down on the todo list. For qcc it was going to be one of the multiplexer commands like nm and objdump. Maybe I should implement it in toybox instead, but it's not in the 1.0 roadmap at http://landley.net/toybox/roadmap.html and I'm not adding more stuff to that until _after_ the release. (Well not that I have to implement, somebody wants to send me a command already written I'll certainly look at it...) I note that the hard part with getting the kernel to build with tinycc was actually the more obscure binutils things. When I was trying to get my tinycc fork to build the kernel (without using any parts of gcc or binutils) one of the first things that failed was generating a header file that did either nm or objdump -d on a binary (I forget which) and ran the result through sed to generate a header file with structure offsets. Tinycc had an assembler but not a disassembler, you see... These days I'm waiting for http://ellcc.org and similar to bear fruit. For the linker they're either using http://lld.llvm.org but the musl-cross toolchain is using https://github.com/sabotage-linux/libelf-compat and before they were using https://fedorahosted.org/releases/e/l/elfutils/ and I still haven't had a chance to look at the LLVM toolchain AOSP is building. It's all up in the air right now as everybody works to clean up after the "career limiting move" that was GPLv3. The android guys are using their own weird make setup (the Android.mk files), and they tell me they have a brand new build tool to replace make that they're they're porting the AOSP build to, which I should go take a look at and maybe come up to speed on. But really, I wrote my own "sed" and made Linux From Scratch build with it, and then did it AGAIN from scratch under a different license. I'm partway through writing my own shell for toybox and am supporting bash syntax in it. Writing my own make that handles gmake stuff packages actually use isn't that much harder if it comes to it. (But as with init systems,
Re: OT: Open letter to the Linux World
Hi, On Wed, Apr 08, 2015 at 07:37:15PM -0500, Rob Landley wrote: > Heck, the FSF's entire "It's GNU Linux, Dammit! Call it by its proper > name: GNU/Linux/dammit" campaign is seriously irritating, and part of > what I was doing with busybox was trying to create a linux development > system without a single gnu package in it (busybox, uclibc, tinycc) > capable of rebuilding itself under itself, and then ask Stallman "I > know you're going to insist this isn't a Linux system but a > GNU/Linux/Dammit system, I'd just like you to try to explain _how_." > (Preferably capturing this on video.) What was the result of this work? Did you manage to build a self-hosting system? What implementation of "make" did you use to build the kernel? A. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
Hi, On Wed, Apr 08, 2015 at 07:37:15PM -0500, Rob Landley wrote: Heck, the FSF's entire It's GNU Linux, Dammit! Call it by its proper name: GNU/Linux/dammit campaign is seriously irritating, and part of what I was doing with busybox was trying to create a linux development system without a single gnu package in it (busybox, uclibc, tinycc) capable of rebuilding itself under itself, and then ask Stallman I know you're going to insist this isn't a Linux system but a GNU/Linux/Dammit system, I'd just like you to try to explain _how_. (Preferably capturing this on video.) What was the result of this work? Did you manage to build a self-hosting system? What implementation of make did you use to build the kernel? A. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On Fri, Apr 10, 2015 at 4:20 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: Hi, On Wed, Apr 08, 2015 at 07:37:15PM -0500, Rob Landley wrote: Heck, the FSF's entire It's GNU Linux, Dammit! Call it by its proper name: GNU/Linux/dammit campaign is seriously irritating, and part of what I was doing with busybox was trying to create a linux development system without a single gnu package in it (busybox, uclibc, tinycc) capable of rebuilding itself under itself, and then ask Stallman I know you're going to insist this isn't a Linux system but a GNU/Linux/Dammit system, I'd just like you to try to explain _how_. (Preferably capturing this on video.) What was the result of this work? http://landley.net/aboriginal/about.html My old self-hosting system was 7 packages: linux, busybox, uClibc, gmake, gcc, binutils, and bash. The new one I'd like to do is 4 packages: linux, toybox, musl, and qcc. Right now, I'm focusing on getting toybox to 1.0 as fast as possible, then I worry about other stuff. Did you manage to build a self-hosting system? Yeah, but it's still using a gcc toolchain. (The last gplv2 release of gcc, binutils, and make, circa 2006.) I was going to replace it with http://landley.net/code/tinycc (and then http://landley.net/code/qcc). The idea was to take my tcc fork and make it a multiplexer like busybox (so it could run as cc, ld, strip, as, and so on depending on what name you called it under; one binary with lots of symlinks to it). The qcc idea was to rip out tcc's code generator and replace it with QEMU's tcg (tiny code generator), so you'd turn the compiler behind http://bellard.org/tcc/tccboot.html (I.E. this already _built_ a working kernel at one point, albeit with a lot of cheating that I was working to fix) and make it support all the targets qemu does, leveraging qemu's developer base to keep them well-supported. _AND_ I got permission to BSD license his tcc code, and qemu's tcg is already BSD licensed, so that fixes the license problem. But I got distracted by toybox (the history is https://lwn.net/Articles/478308/ then https://www.youtube.com/watch?v=SGmtP5Lg_t0 then https://lwn.net/Articles/629362/ and I'm currently dealing with merging http://lists.landley.net/pipermail/toybox-landley.net/2015-April/004024.html and yes that's the Android Core maintainer posting to the toybox list). So I've been kinda busy with other things of late. :) These days I'm waiting for llvm to mature, but a month or two back somebody picked up my qcc idea (combine tinycc's front end with tcg's back end to get a simple bsd licensed C99 compiler that supports a lot of targets) and actually started seriously working on it. So at this point I'm looking to contribute to _his_ project. (I'd link to him but I'm in japan at the moment and those files are back in texas. Ping me after the 20th if you're still curious.) What implementation of make did you use to build the kernel? I plan on writing my own, but it's a bit down on the todo list. For qcc it was going to be one of the multiplexer commands like nm and objdump. Maybe I should implement it in toybox instead, but it's not in the 1.0 roadmap at http://landley.net/toybox/roadmap.html and I'm not adding more stuff to that until _after_ the release. (Well not that I have to implement, somebody wants to send me a command already written I'll certainly look at it...) I note that the hard part with getting the kernel to build with tinycc was actually the more obscure binutils things. When I was trying to get my tinycc fork to build the kernel (without using any parts of gcc or binutils) one of the first things that failed was generating a header file that did either nm or objdump -d on a binary (I forget which) and ran the result through sed to generate a header file with structure offsets. Tinycc had an assembler but not a disassembler, you see... These days I'm waiting for http://ellcc.org and similar to bear fruit. For the linker they're either using http://lld.llvm.org but the musl-cross toolchain is using https://github.com/sabotage-linux/libelf-compat and before they were using https://fedorahosted.org/releases/e/l/elfutils/ and I still haven't had a chance to look at the LLVM toolchain AOSP is building. It's all up in the air right now as everybody works to clean up after the career limiting move that was GPLv3. The android guys are using their own weird make setup (the Android.mk files), and they tell me they have a brand new build tool to replace make that they're they're porting the AOSP build to, which I should go take a look at and maybe come up to speed on. But really, I wrote my own sed and made Linux From Scratch build with it, and then did it AGAIN from scratch under a different license. I'm partway through writing my own shell for toybox and am supporting bash syntax in it. Writing my own make that handles gmake stuff packages actually use isn't that much harder if it comes to it. (But as with init systems, it's a ways
Re: OT: Open letter to the Linux World
On Thu, Apr 9, 2015 at 2:37 AM, Rob Landley wrote: > On Wed, Apr 8, 2015 at 8:12 AM, Denys Vlasenko > wrote: > But systemd has no clear goals, no specification, the single > implementation is a moving target... it's basically a microsoft > product. I think the actual goal is to control everything. To satisfy the control freak. And yes, it is the M$ way of seeing things. > i thought we'd moved _on_ from the days of "this site optimized for > internet explorer", but systemd is that all over again. Linux is all > about modularity where you swap out openssh for libressh (or dropbear) > and swap out xfree86 for x.org and swap out glibc for eglibc (or > uclibc or musl) and you have at least a fighting chance to make it > work. Unfortunately, the systemd developers take the suggestion that > you might want to keep the option of doing that open as some sort of > personal attack. Yes. They want you to use their stuff, and in their way. > I don't care what they're doing. I don't want to _have_ to care what > they're doing. I want a description of the problem space from which I > can write a new implementation. If I can't even reverse engineer such > a thing because it's still too much of a moving target several years > into the project, then what they're doing is crazy and I refuse to get > any of it on me. > >> Not the quality of the code. Not the desire to fix some >> old design problems of SystemV-style init. > > I'm still unclear on what problem they were actually trying to solve. > > (In my defense, _they_ seem unclear. We're way beyond Zawinski's law > here...) > >> Code quality is good. The goals are legitimate. > > 1) Not really, but that's beside the point. 2) What _are_ the goals? > They keep changing... The _stated_ goal, initially, was a better service, a daemon babysitter. It is a legitimate goal because "industry standard" one, SysV, leaves a lot to be desired. But then it suddenly started having unrelated functionality added to it. Again. And again. >> The problem is: the author is a control freak. > > I don't care. Honestly don't care. > > My problem is the blank incomprehension on their part when I go "If I > were to clone a minimal subset of systemd in busybox or toybox, where > would I start reading?" and they can't fit in their head the idea that > anybody would _want_ to do that, and if they think I'm serious they > feel threatened and start changing stuff faster. Yes. You are agreeing with me: they are control freaks. > I don't care about the personality of the developers behind the > project. I don't want to use their code, I want to write a new one. I only care to the extent necessary to figure out how, and whether it is possible, to cooperate with the people on the project. It's possible to cooperate even with people with whom you have lots of disagreements in details. When someone's core desire is to make you use _their_ code, and not being able to switch parts with reasonable expenditure of time/effort, it is not possible for me. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On Thu, Apr 9, 2015 at 2:37 AM, Rob Landley r...@landley.net wrote: On Wed, Apr 8, 2015 at 8:12 AM, Denys Vlasenko vda.li...@googlemail.com wrote: But systemd has no clear goals, no specification, the single implementation is a moving target... it's basically a microsoft product. I think the actual goal is to control everything. To satisfy the control freak. And yes, it is the M$ way of seeing things. i thought we'd moved _on_ from the days of this site optimized for internet explorer, but systemd is that all over again. Linux is all about modularity where you swap out openssh for libressh (or dropbear) and swap out xfree86 for x.org and swap out glibc for eglibc (or uclibc or musl) and you have at least a fighting chance to make it work. Unfortunately, the systemd developers take the suggestion that you might want to keep the option of doing that open as some sort of personal attack. Yes. They want you to use their stuff, and in their way. I don't care what they're doing. I don't want to _have_ to care what they're doing. I want a description of the problem space from which I can write a new implementation. If I can't even reverse engineer such a thing because it's still too much of a moving target several years into the project, then what they're doing is crazy and I refuse to get any of it on me. Not the quality of the code. Not the desire to fix some old design problems of SystemV-style init. I'm still unclear on what problem they were actually trying to solve. (In my defense, _they_ seem unclear. We're way beyond Zawinski's law here...) Code quality is good. The goals are legitimate. 1) Not really, but that's beside the point. 2) What _are_ the goals? They keep changing... The _stated_ goal, initially, was a better service, a daemon babysitter. It is a legitimate goal because industry standard one, SysV, leaves a lot to be desired. But then it suddenly started having unrelated functionality added to it. Again. And again. The problem is: the author is a control freak. I don't care. Honestly don't care. My problem is the blank incomprehension on their part when I go If I were to clone a minimal subset of systemd in busybox or toybox, where would I start reading? and they can't fit in their head the idea that anybody would _want_ to do that, and if they think I'm serious they feel threatened and start changing stuff faster. Yes. You are agreeing with me: they are control freaks. I don't care about the personality of the developers behind the project. I don't want to use their code, I want to write a new one. I only care to the extent necessary to figure out how, and whether it is possible, to cooperate with the people on the project. It's possible to cooperate even with people with whom you have lots of disagreements in details. When someone's core desire is to make you use _their_ code, and not being able to switch parts with reasonable expenditure of time/effort, it is not possible for me. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On Wed, Apr 8, 2015 at 8:12 AM, Denys Vlasenko wrote: > On Tue, Aug 12, 2014 at 9:38 PM, Christopher Barry > wrote: >> So why would very smart people who love and use Linux want to create or >> embrace such a creepy 'Master of All' daemon? Ostensibly, it's for the >> reasons they say, as I mentioned at the top. But partially I think it's >> from a lack of experience. Not a lack as in programming hours, but a >> lack as in time on the Planet. Intelligence alone is not a substitute >> for life experience and, yes I'll say it, wisdom. There's no manual for >> wisdom. Implementing systemd by distros is not a wise move for them over >> the long term. It will, in fact, be their ultimate undoing. >> >> Partially it's the larger-than-life egos of the people involved. Has >> anyone actually read what Poettering says about things? Wow. This guy >> is obviously convinced he has all the answers for everyone. Traditional >> ideas about simplicity and freedom are quaint, but have no real place >> in a 'modern' OS. Look, he's just smarter than you, so get over it and >> move aside. He knows what's best, and he has it under control. How old >> is this guy anyway? 12 or so? He's a fucking tool (IMHO). > > Yes, this is *exactly* the problem with systemd. Not to me. I responded to systemd the way I responded to udev, "that's too complicated, lemme see if I can clone a subset of it". In busybox this resulted in mdev, so you had an alternate implementation that did the same thing and could swap between them. (This lead to me butting heads with Greg KH and Kay Sievers on more than one occasion, because they were convinced sysfs was a private export from their kernel software to their userspace software which nobody else would ever use and they could force upgrades on both sides in lockstep. And they continued to act this way even after Linus chewed them out about it, but I worked around it and moved on.) But systemd has no clear goals, no specification, the single implementation is a moving target... it's basically a microsoft product. Remember the days when the *.doc file format was "what microsoft offices produces and is capable of consuming", and the staroffice guys went to GREAT LENGTHS to reverse engineer it made possible only by the fact that Microsoft went years between releases so they had time to work out what the office 6 format was before office 7 came out, and so on. Same for the Excel file format being "what microsoft's implementation produces and consumes is correct by definition, every strange corner case bug of that one magic implementation _is_ the spec and there is no other." Samba reverse engineered windows NT's network protocols the same way, producing a giant "if it's this version, do this. If it's this versino, do this. Avoid doing this because it bluescreens this specific version of NT for no apparent reason..." i thought we'd moved _on_ from the days of "this site optimized for internet explorer", but systemd is that all over again. Linux is all about modularity where you swap out openssh for libressh (or dropbear) and swap out xfree86 for x.org and swap out glibc for eglibc (or uclibc or musl) and you have at least a fighting chance to make it work. Unfortunately, the systemd developers take the suggestion that you might want to keep the option of doing that open as some sort of personal attack. I don't care what they're doing. I don't want to _have_ to care what they're doing. I want a description of the problem space from which I can write a new implementation. If I can't even reverse engineer such a thing because it's still too much of a moving target several years into the project, then what they're doing is crazy and I refuse to get any of it on me. > Not the quality of the code. Not the desire to fix some > old design problems of SystemV-style init. I'm still unclear on what problem they were actually trying to solve. (In my defense, _they_ seem unclear. We're way beyond Zawinski's law here...) > Code quality is good. The goals are legitimate. 1) Not really, but that's beside the point. 2) What _are_ the goals? They keep changing... > The problem is: the author is a control freak. I don't care. Honestly don't care. We used cdrecord for years from a solaris bigot who openly insulted linux in the README, Openssl's maintainer wasn't that much happier about Linux (until he needed money), put up with xfree86's insular development for a couple _decades_ before that maintainer finally went over the line. Heck, the FSF's entire "It's GNU Linux, Dammit! Call it by its proper name: GNU/Linux/dammit" campaign is seriously irritating, and part of what I was doing with busybox was trying to create a linux development system without a single gnu package in it (busybox, uclibc, tinycc) capable of rebuilding itself under itself, and then ask Stallman "I know you're going to insist this isn't a Linux system but a GNU/Linux/Dammit system, I'd just like you to try to explain _how_." (Preferably
Re: OT: Open letter to the Linux World
On Tue, Aug 12, 2014 at 9:38 PM, Christopher Barry wrote: > So why would very smart people who love and use Linux want to create or > embrace such a creepy 'Master of All' daemon? Ostensibly, it's for the > reasons they say, as I mentioned at the top. But partially I think it's > from a lack of experience. Not a lack as in programming hours, but a > lack as in time on the Planet. Intelligence alone is not a substitute > for life experience and, yes I'll say it, wisdom. There's no manual for > wisdom. Implementing systemd by distros is not a wise move for them over > the long term. It will, in fact, be their ultimate undoing. > > Partially it's the larger-than-life egos of the people involved. Has > anyone actually read what Poettering says about things? Wow. This guy > is obviously convinced he has all the answers for everyone. Traditional > ideas about simplicity and freedom are quaint, but have no real place > in a 'modern' OS. Look, he's just smarter than you, so get over it and > move aside. He knows what's best, and he has it under control. How old > is this guy anyway? 12 or so? He's a fucking tool (IMHO). Yes, this is *exactly* the problem with systemd. Not the quality of the code. Not the desire to fix some old design problems of SystemV-style init. Code quality is good. The goals are legitimate. The problem is: the author is a control freak. I don't mean this to be an insult, it's my honest assessment of his personality. He wants to control everything. And I am convinced he is knowingly lying about it. He pretends that he wants to add stuff to systemd to improve this or that aspect of the user's experience, but in reality he just wants to "privatize" more and more of the OS to his project. He probably understands that this is not a right thing to do, that modularity is a good thing, but it conflicts with his character, so he won't split up the projects into independent subprojects. (Say, a semi-recent addition to systemd, the logging daemon, HAD TO BE a separate tool) I no longer think that talking to Lennart about this is useful. I and other people tried. It doesn't work. I am just waiting for a sufficient number of people to get pissed off, fork the project, and bring sanity to it, which in this case means splitting it up into modular bits, and probably dropping some parts. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On Tue, Aug 12, 2014 at 9:38 PM, Christopher Barry christopher.r.ba...@gmail.com wrote: So why would very smart people who love and use Linux want to create or embrace such a creepy 'Master of All' daemon? Ostensibly, it's for the reasons they say, as I mentioned at the top. But partially I think it's from a lack of experience. Not a lack as in programming hours, but a lack as in time on the Planet. Intelligence alone is not a substitute for life experience and, yes I'll say it, wisdom. There's no manual for wisdom. Implementing systemd by distros is not a wise move for them over the long term. It will, in fact, be their ultimate undoing. Partially it's the larger-than-life egos of the people involved. Has anyone actually read what Poettering says about things? Wow. This guy is obviously convinced he has all the answers for everyone. Traditional ideas about simplicity and freedom are quaint, but have no real place in a 'modern' OS. Look, he's just smarter than you, so get over it and move aside. He knows what's best, and he has it under control. How old is this guy anyway? 12 or so? He's a fucking tool (IMHO). Yes, this is *exactly* the problem with systemd. Not the quality of the code. Not the desire to fix some old design problems of SystemV-style init. Code quality is good. The goals are legitimate. The problem is: the author is a control freak. I don't mean this to be an insult, it's my honest assessment of his personality. He wants to control everything. And I am convinced he is knowingly lying about it. He pretends that he wants to add stuff to systemd to improve this or that aspect of the user's experience, but in reality he just wants to privatize more and more of the OS to his project. He probably understands that this is not a right thing to do, that modularity is a good thing, but it conflicts with his character, so he won't split up the projects into independent subprojects. (Say, a semi-recent addition to systemd, the logging daemon, HAD TO BE a separate tool) I no longer think that talking to Lennart about this is useful. I and other people tried. It doesn't work. I am just waiting for a sufficient number of people to get pissed off, fork the project, and bring sanity to it, which in this case means splitting it up into modular bits, and probably dropping some parts. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On Wed, Apr 8, 2015 at 8:12 AM, Denys Vlasenko vda.li...@googlemail.com wrote: On Tue, Aug 12, 2014 at 9:38 PM, Christopher Barry christopher.r.ba...@gmail.com wrote: So why would very smart people who love and use Linux want to create or embrace such a creepy 'Master of All' daemon? Ostensibly, it's for the reasons they say, as I mentioned at the top. But partially I think it's from a lack of experience. Not a lack as in programming hours, but a lack as in time on the Planet. Intelligence alone is not a substitute for life experience and, yes I'll say it, wisdom. There's no manual for wisdom. Implementing systemd by distros is not a wise move for them over the long term. It will, in fact, be their ultimate undoing. Partially it's the larger-than-life egos of the people involved. Has anyone actually read what Poettering says about things? Wow. This guy is obviously convinced he has all the answers for everyone. Traditional ideas about simplicity and freedom are quaint, but have no real place in a 'modern' OS. Look, he's just smarter than you, so get over it and move aside. He knows what's best, and he has it under control. How old is this guy anyway? 12 or so? He's a fucking tool (IMHO). Yes, this is *exactly* the problem with systemd. Not to me. I responded to systemd the way I responded to udev, that's too complicated, lemme see if I can clone a subset of it. In busybox this resulted in mdev, so you had an alternate implementation that did the same thing and could swap between them. (This lead to me butting heads with Greg KH and Kay Sievers on more than one occasion, because they were convinced sysfs was a private export from their kernel software to their userspace software which nobody else would ever use and they could force upgrades on both sides in lockstep. And they continued to act this way even after Linus chewed them out about it, but I worked around it and moved on.) But systemd has no clear goals, no specification, the single implementation is a moving target... it's basically a microsoft product. Remember the days when the *.doc file format was what microsoft offices produces and is capable of consuming, and the staroffice guys went to GREAT LENGTHS to reverse engineer it made possible only by the fact that Microsoft went years between releases so they had time to work out what the office 6 format was before office 7 came out, and so on. Same for the Excel file format being what microsoft's implementation produces and consumes is correct by definition, every strange corner case bug of that one magic implementation _is_ the spec and there is no other. Samba reverse engineered windows NT's network protocols the same way, producing a giant if it's this version, do this. If it's this versino, do this. Avoid doing this because it bluescreens this specific version of NT for no apparent reason... i thought we'd moved _on_ from the days of this site optimized for internet explorer, but systemd is that all over again. Linux is all about modularity where you swap out openssh for libressh (or dropbear) and swap out xfree86 for x.org and swap out glibc for eglibc (or uclibc or musl) and you have at least a fighting chance to make it work. Unfortunately, the systemd developers take the suggestion that you might want to keep the option of doing that open as some sort of personal attack. I don't care what they're doing. I don't want to _have_ to care what they're doing. I want a description of the problem space from which I can write a new implementation. If I can't even reverse engineer such a thing because it's still too much of a moving target several years into the project, then what they're doing is crazy and I refuse to get any of it on me. Not the quality of the code. Not the desire to fix some old design problems of SystemV-style init. I'm still unclear on what problem they were actually trying to solve. (In my defense, _they_ seem unclear. We're way beyond Zawinski's law here...) Code quality is good. The goals are legitimate. 1) Not really, but that's beside the point. 2) What _are_ the goals? They keep changing... The problem is: the author is a control freak. I don't care. Honestly don't care. We used cdrecord for years from a solaris bigot who openly insulted linux in the README, Openssl's maintainer wasn't that much happier about Linux (until he needed money), put up with xfree86's insular development for a couple _decades_ before that maintainer finally went over the line. Heck, the FSF's entire It's GNU Linux, Dammit! Call it by its proper name: GNU/Linux/dammit campaign is seriously irritating, and part of what I was doing with busybox was trying to create a linux development system without a single gnu package in it (busybox, uclibc, tinycc) capable of rebuilding itself under itself, and then ask Stallman I know you're going to insist this isn't a Linux system but a GNU/Linux/Dammit system, I'd just like you to try to explain _how_. (Preferably
Re: OT: Open letter to the Linux World
Am 07.09.2014 01:44, schrieb Lennart Sorensen: So why C++ then if you care about making the code easy to make safe when there are clearly even better options. Why not OCAML or Erlang or one of the other much more robust languages that don't contain all the dangers of C? I would choose Prolog. ;) I don't have to provide an answer because I'm not one of those which have gone out to change this critical part of many systems. My concerns are that C is one of the worst languages for that. I'm not saying that C++ would be the best solution. But I'm pretty sure it would have been a much better solution than C. That means I haven't spend much time (around zero) to think about what an init-replacement has to do and how it would be done best. I'm just very concerned about what happens there. So here are just some thoughts: - Why do you call OCAML or Erlang more robust? Many problems in other languages just aren't well known because they are only used by a few people which don't tell you bad things about the language they've choosen. ;) - Can you achieve all goals with just using OCAML or another language? My experience is that in almost all of those "very well designed languages", you are reaching very often some limits or problems which are very ugly to solve, if it's possible at all to solve them. - How many people do you know which can program (and review) that language? - How robust are the compilers/interpreters? How are they maintained? What happens if you find a bug in the compiler/interpreter? But, as said above, I don't have to provide a solution because I'm not the one who has gone out to change PID 1 into something more complicated. ;) Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On Sat, Sep 06, 2014 at 10:01:29PM +0200, Alexander Holler wrote:
> I've brought up the critics about using C in a critical and very
> security sensitive piece of software in userland, so I've decided a
> bit more explanations might make sense.
>
> First, as you don't seem to have noticed or you don't know or you
> ignore the difference, let me repeat that this thread is about a
> piece of SW which runs in userland. So, please, keep away with any
> comments from Linus where he talks about kernelspace. I'm pretty
> sure he knows the difference.
>
> Now let me bring up a very small piece of code which you can find in
> a similiar fashion in almost every piece of software which gets in
> contact with strings. And not just in one place or function, but in
> dozens or even hundred of places (inline, not in functions) in one
> project.
>
> First in C++:
>
> void foo_bar(const std::string& foo, const std::string& bar,
> std::string& foobar)
> {
> foobar = foo + bar;
> }
>
> For those which don't know C++, this concatenates the two strings
> named foo and bar and puts the result into foobar.
>
> Now an example how you would have to do that in C:
>
> char *foo_bar(const char *foo, const char *bar)
> {
> char *foobar = malloc(strlen(foo) + strlen(bar));
>
> strcpy(foobar, foo);
> strcat(foobar, bar);
>
> return foobar;
> }
>
> Do you see the difference and spot all the problems?
>
> First I've though about not posting the answer to see the response,
> but that would just have ended up with a lot of people calling me a
> fool and/or assuming I can't write proper C. And it bears the
> problem that some inexperienced people might copy and paste and use
> it.
>
> So at first: THE ABOVE EXAMPLE IN C IS BROKEN.
>
> The very first problem is that foobar is allocated with the wrong
> size, because it doesn't take care of the terminating null byte. A
> very common problem already found at uncountable places.
>
> But there are several more problems:
>
> - What happens if foo or bar isn't terminated with a null byte?
>
> - What happens if malloc fails?
>
> - Who is the owner of foo, bar and/or foobar? Does the caller still
> owns foo and bar afterwards? Will the caller own foobar? (That means
> who is repsonsible to free foo, bar and foobar if they aren't used
> anymore).
>
> So now we extend the above C example:
>
> char *foo_bar(const char *foo, const char *bar)
> {
> char *foobar;
>
> if (!foo || !bar)
> return NULL;
>
> foobar = malloc(strlen(foo) + strlen(bar) + 1);
>
> if (!foobar)
> return NULL;
>
> strcpy(foobar, foo);
> strcat(foobar, bar);
>
> return foobar;
> }
>
> This has still some problems. First, the caller has to check if
> foo_bar() hasn't returned NULL. A very common bug already found in
> uncountable places too.
>
> Next, there is still the unsolvable problem about what happens if
> foo or bar isn't terminated with a null byte (in other words they
> aren't C strings).
> So you have to check all callers up to the source of foo and bar to
> be sure the program doesn't crash in the possible far far away place
> called foo_bar().
>
> And still no comment about ownership. That means someone who just
> looks at the prototype or sees a call of foo_bar() somewhere has no
> idea about the ownership of foo, bar and the returned foobar without
> a comment.
>
> So just this very simple functionality about string handling in C
> already contains several still open questions and is 17 lines long
> which have to be reviewed very carefull (e.g. to not miss the
> off-by-one bug).
> Compare this with the 4 lines in C++ which are almost impossible to
> do or to use wrong.
>
> And, again, this thread is about a piece of software which runs with
> process ID 1, wants to control the whole system and owns all
> permissions to modify the system in almost every possible way. It
> doesn't run as some user with restricted permissions or in chroot
> or something similar. Some parts might do, but for sure not all
> (read again the above "far far away").
>
> And now some stats. I've just checked out systemd:
>
> git grep -E "strcat|strncat|strcpy|strncpy|strlen" | wc -l
> 570
>
> git grep -E "strcat|strncat|strcpy|strncpy|memcpy|strlen" | wc -l
> 850
>
> Ok, not every of those places might be part of pid 1. And several
> places are trivial calls like strlen("ATTR"), but it gives an idea
> about how many places do exist in systemd which might contain a
> problem wich isn't trivial to spot.
>
> And regardless how clever and experienced these people are which are
> writing this piece of software, everyone is prone to do e.g. such an
> off-by-one bug.
> Maybe he writes the piece of code after having worked 12 hours,
> maybe he got interrupted while writing the code and continued it a
> day later, maybe it's full moon or maybe his last meal wasn't like
> it should have been.
>
> Whatever.
>
> This means,
Re: OT: Open letter to the Linux World
Am 05.09.2014 08:31, schrieb Alexander Holler:
Am 04.09.2014 21:18, schrieb Rob Landley:
What's actually wrong with C++ at a language design level.
Short version:
OMG.
It's better than C. In almost every aspect. Stop. Nothing else. Of
course, if you want to write something like systemd in Python, Perl,
Pascal, Modula or Erlang, feel free to so. And if you want more security
bugs, feel free to still use C for string handling instead of
std::string, Or still write your sorted list for every structure (or
just don't and go the slow way, because you don't find the time to do it
right in C). And ...
You don't have to understand how templates do work to use e.g.
std::string. Other people do hard stuff for you. So don't panic.
I've brought up the critics about using C in a critical and very
security sensitive piece of software in userland, so I've decided a bit
more explanations might make sense.
First, as you don't seem to have noticed or you don't know or you ignore
the difference, let me repeat that this thread is about a piece of SW
which runs in userland. So, please, keep away with any comments from
Linus where he talks about kernelspace. I'm pretty sure he knows the
difference.
Now let me bring up a very small piece of code which you can find in a
similiar fashion in almost every piece of software which gets in contact
with strings. And not just in one place or function, but in dozens or
even hundred of places (inline, not in functions) in one project.
First in C++:
void foo_bar(const std::string& foo, const std::string& bar,
std::string& foobar)
{
foobar = foo + bar;
}
For those which don't know C++, this concatenates the two strings named
foo and bar and puts the result into foobar.
Now an example how you would have to do that in C:
char *foo_bar(const char *foo, const char *bar)
{
char *foobar = malloc(strlen(foo) + strlen(bar));
strcpy(foobar, foo);
strcat(foobar, bar);
return foobar;
}
Do you see the difference and spot all the problems?
First I've though about not posting the answer to see the response, but
that would just have ended up with a lot of people calling me a fool
and/or assuming I can't write proper C. And it bears the problem that
some inexperienced people might copy and paste and use it.
So at first: THE ABOVE EXAMPLE IN C IS BROKEN.
The very first problem is that foobar is allocated with the wrong size,
because it doesn't take care of the terminating null byte. A very common
problem already found at uncountable places.
But there are several more problems:
- What happens if foo or bar isn't terminated with a null byte?
- What happens if malloc fails?
- Who is the owner of foo, bar and/or foobar? Does the caller still owns
foo and bar afterwards? Will the caller own foobar? (That means who is
repsonsible to free foo, bar and foobar if they aren't used anymore).
So now we extend the above C example:
char *foo_bar(const char *foo, const char *bar)
{
char *foobar;
if (!foo || !bar)
return NULL;
foobar = malloc(strlen(foo) + strlen(bar) + 1);
if (!foobar)
return NULL;
strcpy(foobar, foo);
strcat(foobar, bar);
return foobar;
}
This has still some problems. First, the caller has to check if
foo_bar() hasn't returned NULL. A very common bug already found in
uncountable places too.
Next, there is still the unsolvable problem about what happens if foo or
bar isn't terminated with a null byte (in other words they aren't C
strings).
So you have to check all callers up to the source of foo and bar to be
sure the program doesn't crash in the possible far far away place called
foo_bar().
And still no comment about ownership. That means someone who just looks
at the prototype or sees a call of foo_bar() somewhere has no idea about
the ownership of foo, bar and the returned foobar without a comment.
So just this very simple functionality about string handling in C
already contains several still open questions and is 17 lines long which
have to be reviewed very carefull (e.g. to not miss the off-by-one bug).
Compare this with the 4 lines in C++ which are almost impossible to do
or to use wrong.
And, again, this thread is about a piece of software which runs with
process ID 1, wants to control the whole system and owns all permissions
to modify the system in almost every possible way. It doesn't run as
some user with restricted permissions or in chroot or something
similar. Some parts might do, but for sure not all (read again the above
"far far away").
And now some stats. I've just checked out systemd:
git grep -E "strcat|strncat|strcpy|strncpy|strlen" | wc -l
570
git grep -E "strcat|strncat|strcpy|strncpy|memcpy|strlen" | wc -l
850
Ok, not every of those places might be part of pid 1. And several places
are trivial calls like strlen("ATTR"), but it gives an idea about how
many places
Re: OT: Open letter to the Linux World
Am 05.09.2014 08:31, schrieb Alexander Holler:
Am 04.09.2014 21:18, schrieb Rob Landley:
What's actually wrong with C++ at a language design level.
Short version:
OMG.
It's better than C. In almost every aspect. Stop. Nothing else. Of
course, if you want to write something like systemd in Python, Perl,
Pascal, Modula or Erlang, feel free to so. And if you want more security
bugs, feel free to still use C for string handling instead of
std::string, Or still write your sorted list for every structure (or
just don't and go the slow way, because you don't find the time to do it
right in C). And ...
You don't have to understand how templates do work to use e.g.
std::string. Other people do hard stuff for you. So don't panic.
I've brought up the critics about using C in a critical and very
security sensitive piece of software in userland, so I've decided a bit
more explanations might make sense.
First, as you don't seem to have noticed or you don't know or you ignore
the difference, let me repeat that this thread is about a piece of SW
which runs in userland. So, please, keep away with any comments from
Linus where he talks about kernelspace. I'm pretty sure he knows the
difference.
Now let me bring up a very small piece of code which you can find in a
similiar fashion in almost every piece of software which gets in contact
with strings. And not just in one place or function, but in dozens or
even hundred of places (inline, not in functions) in one project.
First in C++:
void foo_bar(const std::string foo, const std::string bar,
std::string foobar)
{
foobar = foo + bar;
}
For those which don't know C++, this concatenates the two strings named
foo and bar and puts the result into foobar.
Now an example how you would have to do that in C:
char *foo_bar(const char *foo, const char *bar)
{
char *foobar = malloc(strlen(foo) + strlen(bar));
strcpy(foobar, foo);
strcat(foobar, bar);
return foobar;
}
Do you see the difference and spot all the problems?
First I've though about not posting the answer to see the response, but
that would just have ended up with a lot of people calling me a fool
and/or assuming I can't write proper C. And it bears the problem that
some inexperienced people might copy and paste and use it.
So at first: THE ABOVE EXAMPLE IN C IS BROKEN.
The very first problem is that foobar is allocated with the wrong size,
because it doesn't take care of the terminating null byte. A very common
problem already found at uncountable places.
But there are several more problems:
- What happens if foo or bar isn't terminated with a null byte?
- What happens if malloc fails?
- Who is the owner of foo, bar and/or foobar? Does the caller still owns
foo and bar afterwards? Will the caller own foobar? (That means who is
repsonsible to free foo, bar and foobar if they aren't used anymore).
So now we extend the above C example:
char *foo_bar(const char *foo, const char *bar)
{
char *foobar;
if (!foo || !bar)
return NULL;
foobar = malloc(strlen(foo) + strlen(bar) + 1);
if (!foobar)
return NULL;
strcpy(foobar, foo);
strcat(foobar, bar);
return foobar;
}
This has still some problems. First, the caller has to check if
foo_bar() hasn't returned NULL. A very common bug already found in
uncountable places too.
Next, there is still the unsolvable problem about what happens if foo or
bar isn't terminated with a null byte (in other words they aren't C
strings).
So you have to check all callers up to the source of foo and bar to be
sure the program doesn't crash in the possible far far away place called
foo_bar().
And still no comment about ownership. That means someone who just looks
at the prototype or sees a call of foo_bar() somewhere has no idea about
the ownership of foo, bar and the returned foobar without a comment.
So just this very simple functionality about string handling in C
already contains several still open questions and is 17 lines long which
have to be reviewed very carefull (e.g. to not miss the off-by-one bug).
Compare this with the 4 lines in C++ which are almost impossible to do
or to use wrong.
And, again, this thread is about a piece of software which runs with
process ID 1, wants to control the whole system and owns all permissions
to modify the system in almost every possible way. It doesn't run as
some user with restricted permissions or in chroot or something
similar. Some parts might do, but for sure not all (read again the above
far far away).
And now some stats. I've just checked out systemd:
git grep -E strcat|strncat|strcpy|strncpy|strlen | wc -l
570
git grep -E strcat|strncat|strcpy|strncpy|memcpy|strlen | wc -l
850
Ok, not every of those places might be part of pid 1. And several places
are trivial calls like strlen(ATTR), but it gives an idea about how
many places do exist in
Re: OT: Open letter to the Linux World
On Sat, Sep 06, 2014 at 10:01:29PM +0200, Alexander Holler wrote:
I've brought up the critics about using C in a critical and very
security sensitive piece of software in userland, so I've decided a
bit more explanations might make sense.
First, as you don't seem to have noticed or you don't know or you
ignore the difference, let me repeat that this thread is about a
piece of SW which runs in userland. So, please, keep away with any
comments from Linus where he talks about kernelspace. I'm pretty
sure he knows the difference.
Now let me bring up a very small piece of code which you can find in
a similiar fashion in almost every piece of software which gets in
contact with strings. And not just in one place or function, but in
dozens or even hundred of places (inline, not in functions) in one
project.
First in C++:
void foo_bar(const std::string foo, const std::string bar,
std::string foobar)
{
foobar = foo + bar;
}
For those which don't know C++, this concatenates the two strings
named foo and bar and puts the result into foobar.
Now an example how you would have to do that in C:
char *foo_bar(const char *foo, const char *bar)
{
char *foobar = malloc(strlen(foo) + strlen(bar));
strcpy(foobar, foo);
strcat(foobar, bar);
return foobar;
}
Do you see the difference and spot all the problems?
First I've though about not posting the answer to see the response,
but that would just have ended up with a lot of people calling me a
fool and/or assuming I can't write proper C. And it bears the
problem that some inexperienced people might copy and paste and use
it.
So at first: THE ABOVE EXAMPLE IN C IS BROKEN.
The very first problem is that foobar is allocated with the wrong
size, because it doesn't take care of the terminating null byte. A
very common problem already found at uncountable places.
But there are several more problems:
- What happens if foo or bar isn't terminated with a null byte?
- What happens if malloc fails?
- Who is the owner of foo, bar and/or foobar? Does the caller still
owns foo and bar afterwards? Will the caller own foobar? (That means
who is repsonsible to free foo, bar and foobar if they aren't used
anymore).
So now we extend the above C example:
char *foo_bar(const char *foo, const char *bar)
{
char *foobar;
if (!foo || !bar)
return NULL;
foobar = malloc(strlen(foo) + strlen(bar) + 1);
if (!foobar)
return NULL;
strcpy(foobar, foo);
strcat(foobar, bar);
return foobar;
}
This has still some problems. First, the caller has to check if
foo_bar() hasn't returned NULL. A very common bug already found in
uncountable places too.
Next, there is still the unsolvable problem about what happens if
foo or bar isn't terminated with a null byte (in other words they
aren't C strings).
So you have to check all callers up to the source of foo and bar to
be sure the program doesn't crash in the possible far far away place
called foo_bar().
And still no comment about ownership. That means someone who just
looks at the prototype or sees a call of foo_bar() somewhere has no
idea about the ownership of foo, bar and the returned foobar without
a comment.
So just this very simple functionality about string handling in C
already contains several still open questions and is 17 lines long
which have to be reviewed very carefull (e.g. to not miss the
off-by-one bug).
Compare this with the 4 lines in C++ which are almost impossible to
do or to use wrong.
And, again, this thread is about a piece of software which runs with
process ID 1, wants to control the whole system and owns all
permissions to modify the system in almost every possible way. It
doesn't run as some user with restricted permissions or in chroot
or something similar. Some parts might do, but for sure not all
(read again the above far far away).
And now some stats. I've just checked out systemd:
git grep -E strcat|strncat|strcpy|strncpy|strlen | wc -l
570
git grep -E strcat|strncat|strcpy|strncpy|memcpy|strlen | wc -l
850
Ok, not every of those places might be part of pid 1. And several
places are trivial calls like strlen(ATTR), but it gives an idea
about how many places do exist in systemd which might contain a
problem wich isn't trivial to spot.
And regardless how clever and experienced these people are which are
writing this piece of software, everyone is prone to do e.g. such an
off-by-one bug.
Maybe he writes the piece of code after having worked 12 hours,
maybe he got interrupted while writing the code and continued it a
day later, maybe it's full moon or maybe his last meal wasn't like
it should have been.
Whatever.
This means, every piece of code in that piece of software has to be
reviewed multiple times (reviewers aren't perfect too), and, as long
as the software
Re: OT: Open letter to the Linux World
Am 07.09.2014 01:44, schrieb Lennart Sorensen: So why C++ then if you care about making the code easy to make safe when there are clearly even better options. Why not OCAML or Erlang or one of the other much more robust languages that don't contain all the dangers of C? I would choose Prolog. ;) I don't have to provide an answer because I'm not one of those which have gone out to change this critical part of many systems. My concerns are that C is one of the worst languages for that. I'm not saying that C++ would be the best solution. But I'm pretty sure it would have been a much better solution than C. That means I haven't spend much time (around zero) to think about what an init-replacement has to do and how it would be done best. I'm just very concerned about what happens there. So here are just some thoughts: - Why do you call OCAML or Erlang more robust? Many problems in other languages just aren't well known because they are only used by a few people which don't tell you bad things about the language they've choosen. ;) - Can you achieve all goals with just using OCAML or another language? My experience is that in almost all of those very well designed languages, you are reaching very often some limits or problems which are very ugly to solve, if it's possible at all to solve them. - How many people do you know which can program (and review) that language? - How robust are the compilers/interpreters? How are they maintained? What happens if you find a bug in the compiler/interpreter? But, as said above, I don't have to provide a solution because I'm not the one who has gone out to change PID 1 into something more complicated. ;) Regards, Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
Am 04.09.2014 21:18, schrieb Rob Landley: What's actually wrong with C++ at a language design level. Short version: OMG. It's better than C. In almost every aspect. Stop. Nothing else. Of course, if you want to write something like systemd in Python, Perl, Pascal, Modula or Erlang, feel free to so. And if you want more security bugs, feel free to still use C for string handling instead of std::string, Or still write your sorted list for every structure (or just don't and go the slow way, because you don't find the time to do it right in C). And ... You don't have to understand how templates do work to use e.g. std::string. Other people do hard stuff for you. So don't panic. Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
Am 04.09.2014 21:18, schrieb Rob Landley: What's actually wrong with C++ at a language design level. Short version: OMG. It's better than C. In almost every aspect. Stop. Nothing else. Of course, if you want to write something like systemd in Python, Perl, Pascal, Modula or Erlang, feel free to so. And if you want more security bugs, feel free to still use C for string handling instead of std::string, Or still write your sorted list for every structure (or just don't and go the slow way, because you don't find the time to do it right in C). And ... You don't have to understand how templates do work to use e.g. std::string. Other people do hard stuff for you. So don't panic. Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On Thu, Sep 4, 2014 at 1:33 PM, Alexander Holler wrote: >>> Hmm, a sane and maintainable solution would use C++ with which people >>> don't >>> have to manually build lists or hashes for every structure like in the >>> kernel (generic programming done right). So you won't find much kernel >>> developers there. ;) >>> >> >> Seriously Dude? >> >> Have you tried it? I was using c++ before during and after the stl was >> standardised >> and the memories of the resulting induced self hair pulling still >> gives me the shivers. >> Try writing a real time kernel with full c++ support. You have to >> provide the entire c++ >> runtime in the kernel! >> >> I still do a little c++ programming when i am forced to but its only >> in small pieces. >> Ill go crazy otherwise. > > > I've started to use C++ when only precompilers (to translate C++ to C) were > available. That was long before the STL was standardised. What's actually wrong with C++ at a language design level. Short version: http://lwn.net/Articles/504751/ Long version (parts 1, 2, 3): http://landley.net/notes-2011.html#16-03-2011 http://landley.net/notes-2011.html#19-03-2011 http://landley.net/notes-2011.html#20-03-2011 Seriously, saying C++ is a good language because it contains the whole of C is like saying a mud pie is a good beverage because it contains an entire glass of water. Do you honestly think this is the first time this topic has come up? http://harmful.cat-v.org/software/c++/linus Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
Am 04.09.2014 20:27, schrieb Rogelio Serrano: On Mon, Aug 18, 2014 at 7:15 PM, Alexander Holler wrote: Am 13.08.2014 11:00, schrieb Borislav Petkov: On Wed, Aug 13, 2014 at 10:27:56AM +0200, Peter Zijlstra wrote: And the thing is; we're all very busy so we tend to take the 'easy' way out for things like this; but wholesale switching all my machines is indeed painful, and I'm not liking. Right, I think kernel people will gladly jump on a sane solution devoid of that kids-jerking-off-on-linux-desktop-just-for-the-fun-of-it situation if someone would present them with one. So, if someone would come up and do a sane init design without the jerking off, kernel people would jump on that in a heartbeat. Someone might even start getting patches from them too. ^^Hint^^ ^^hint^^. :-) Hmm, a sane and maintainable solution would use C++ with which people don't have to manually build lists or hashes for every structure like in the kernel (generic programming done right). So you won't find much kernel developers there. ;) Seriously Dude? Have you tried it? I was using c++ before during and after the stl was standardised and the memories of the resulting induced self hair pulling still gives me the shivers. Try writing a real time kernel with full c++ support. You have to provide the entire c++ runtime in the kernel! I still do a little c++ programming when i am forced to but its only in small pieces. Ill go crazy otherwise. I've started to use C++ when only precompilers (to translate C++ to C) were available. That was long before the STL was standardised. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On Mon, Aug 18, 2014 at 7:15 PM, Alexander Holler wrote: > Am 13.08.2014 11:00, schrieb Borislav Petkov: > >> On Wed, Aug 13, 2014 at 10:27:56AM +0200, Peter Zijlstra wrote: >>> >>> And the thing is; we're all very busy so we tend to take the 'easy' >>> way out for things like this; but wholesale switching all my machines >>> is indeed painful, and I'm not liking. >> >> >> Right, I think kernel people will gladly jump on a sane solution devoid >> of that kids-jerking-off-on-linux-desktop-just-for-the-fun-of-it >> situation if someone would present them with one. So, if someone would >> come up and do a sane init design without the jerking off, kernel people >> would jump on that in a heartbeat. Someone might even start getting >> patches from them too. ^^Hint^^ ^^hint^^. >> >> :-) > > > Hmm, a sane and maintainable solution would use C++ with which people don't > have to manually build lists or hashes for every structure like in the > kernel (generic programming done right). So you won't find much kernel > developers there. ;) > Seriously Dude? Have you tried it? I was using c++ before during and after the stl was standardised and the memories of the resulting induced self hair pulling still gives me the shivers. Try writing a real time kernel with full c++ support. You have to provide the entire c++ runtime in the kernel! I still do a little c++ programming when i am forced to but its only in small pieces. Ill go crazy otherwise. > Regards, > > Alexander Holler > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
Am 04.09.2014 19:58, schrieb Austin S Hemmelgarn: On 2014-09-04 13:29, Alexander Holler wrote: Am 04.09.2014 16:36, schrieb Austin S Hemmelgarn: On 2014-09-04 06:16, Alexander Holler wrote: It's a myth that C++ ends up in bigger code than C. At least in my experience. Especially when the latest additions to C++ are in effect (like the move-semantics in C++11 I like quiet a lot and which you get almost for free (by changing nothing) when you use the STL). Thread support is now also standardized (in C++11), quiet nice to use. Assuming you are writing in a standalone environment (no standard libraries), then yes, your code will usually be about the same size (unless you go way overboard with the object-oriented stuff); but the runtime is larger in almost all non-standalone environments, and there are some cases that code does end up larger in C++. A lot of 'Clean C' (stuff written so that it compiles correctly as C, C++ and Objective C) that I have seen seems to end up larger (by about 4-6%) when built as C++ (although it usually does much worse as Objective C). There are always corner cases and I never would use some "Clean C" code to compare sizes of C and C++. There is a whole lot of stuff you just can't, shouldn't or wouldn't do when using C instead of C++. And just throwing in some numbers without any explanation about features (like exceptions), optimizations and so on you've enabled for the tests you used to get those numbers, doesn't work. ;) I can't really comment on what you mean with "standalone environment" or "non-standalone environment", as I don't know what you mean with that. But if several programms share e.g. the stuff which is in libstdc++. you'll get a lot of size back when compared with C-only programms where everyone invents the wheel again and again. By standalone environment, I mean no libraries, no libc[++], no external dependencies, and in the case of a lot of kernel programming, no built-ins. A OS kernel HAS to be written like that, and it's easier to do that in C than C++. I doubt that you have ever looked at any source code for Windows drivers, but Windows is written in C++, and they still are just as mind-numbingly insane as some of the poorly maintained, vendor originated Linux drivers. I've seen drivers for Windows and for OS2/2 and DOS and FreeBSD and ... But throwing the ball back, did you know that all Arduino SW is in C++? ;) Not all C is like the Linux kernel, and in fact, if you use Linux, probably more than half of your user-space programs were written in C. They use dynamic linking just like C++ programs (but often with less complex symbol mangling). This thread isn't about the kernel, but some userspace program which does quiet a lot and which wants to do even more. I've just used one example I did in the kernel space to explain what I miss when I'm using or having to use C instead of C++. I do understand why the Linux kernel is (still) in C and don't want to start a discussion about that. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On 2014-09-04 13:29, Alexander Holler wrote: > Am 04.09.2014 16:36, schrieb Austin S Hemmelgarn: >> On 2014-09-04 06:16, Alexander Holler wrote: >>> >>> It's a myth that C++ ends up in bigger code than C. At least in my >>> experience. Especially when the latest additions to C++ are in effect >>> (like the move-semantics in C++11 I like quiet a lot and which you get >>> almost for free (by changing nothing) when you use the STL). Thread >>> support is now also standardized (in C++11), quiet nice to use. > >> Assuming you are writing in a standalone environment (no standard >> libraries), then yes, your code will usually be about the same size >> (unless you go way overboard with the object-oriented stuff); but the >> runtime is larger in almost all non-standalone environments, and there >> are some cases that code does end up larger in C++. A lot of 'Clean C' >> (stuff written so that it compiles correctly as C, C++ and Objective C) >> that I have seen seems to end up larger (by about 4-6%) when built as >> C++ (although it usually does much worse as Objective C). > > There are always corner cases and I never would use some "Clean C" code > to compare sizes of C and C++. There is a whole lot of stuff you just > can't, shouldn't or wouldn't do when using C instead of C++. > > And just throwing in some numbers without any explanation about features > (like exceptions), optimizations and so on you've enabled for the tests > you used to get those numbers, doesn't work. ;) > > I can't really comment on what you mean with "standalone environment" or > "non-standalone environment", as I don't know what you mean with that. > But if several programms share e.g. the stuff which is in libstdc++. > you'll get a lot of size back when compared with C-only programms where > everyone invents the wheel again and again. By standalone environment, I mean no libraries, no libc[++], no external dependencies, and in the case of a lot of kernel programming, no built-ins. A OS kernel HAS to be written like that, and it's easier to do that in C than C++. I doubt that you have ever looked at any source code for Windows drivers, but Windows is written in C++, and they still are just as mind-numbingly insane as some of the poorly maintained, vendor originated Linux drivers. Not all C is like the Linux kernel, and in fact, if you use Linux, probably more than half of your user-space programs were written in C. They use dynamic linking just like C++ programs (but often with less complex symbol mangling). smime.p7s Description: S/MIME Cryptographic Signature
Re: OT: Open letter to the Linux World
Am 04.09.2014 16:36, schrieb Austin S Hemmelgarn: On 2014-09-04 06:16, Alexander Holler wrote: It's a myth that C++ ends up in bigger code than C. At least in my experience. Especially when the latest additions to C++ are in effect (like the move-semantics in C++11 I like quiet a lot and which you get almost for free (by changing nothing) when you use the STL). Thread support is now also standardized (in C++11), quiet nice to use. Assuming you are writing in a standalone environment (no standard libraries), then yes, your code will usually be about the same size (unless you go way overboard with the object-oriented stuff); but the runtime is larger in almost all non-standalone environments, and there are some cases that code does end up larger in C++. A lot of 'Clean C' (stuff written so that it compiles correctly as C, C++ and Objective C) that I have seen seems to end up larger (by about 4-6%) when built as C++ (although it usually does much worse as Objective C). There are always corner cases and I never would use some "Clean C" code to compare sizes of C and C++. There is a whole lot of stuff you just can't, shouldn't or wouldn't do when using C instead of C++. And just throwing in some numbers without any explanation about features (like exceptions), optimizations and so on you've enabled for the tests you used to get those numbers, doesn't work. ;) I can't really comment on what you mean with "standalone environment" or "non-standalone environment", as I don't know what you mean with that. But if several programms share e.g. the stuff which is in libstdc++. you'll get a lot of size back when compared with C-only programms where everyone invents the wheel again and again. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On 2014-09-04 06:16, Alexander Holler wrote: > > It's a myth that C++ ends up in bigger code than C. At least in my > experience. Especially when the latest additions to C++ are in effect > (like the move-semantics in C++11 I like quiet a lot and which you get > almost for free (by changing nothing) when you use the STL). Thread > support is now also standardized (in C++11), quiet nice to use. Assuming you are writing in a standalone environment (no standard libraries), then yes, your code will usually be about the same size (unless you go way overboard with the object-oriented stuff); but the runtime is larger in almost all non-standalone environments, and there are some cases that code does end up larger in C++. A lot of 'Clean C' (stuff written so that it compiles correctly as C, C++ and Objective C) that I have seen seems to end up larger (by about 4-6%) when built as C++ (although it usually does much worse as Objective C). smime.p7s Description: S/MIME Cryptographic Signature
Re: OT: Open letter to the Linux World
Am 04.09.2014 09:54, schrieb Peter Zijlstra: On Mon, Aug 18, 2014 at 08:15:45PM +0200, Alexander Holler wrote: Hmm, a sane and maintainable solution would use C++ with which people don't have to manually build lists or hashes for every structure like in the kernel (generic programming done right). So you won't find much kernel developers there. ;) Troll a lot do you? ;-) Not really. I just hate all the stuff which is necessary in C when I e.g. want a sorted list, map or set for whatever structure I have the need for. I had fun doing so 30 years ago, when I started to learn C, but now it's just tiring. E.g. for the dependency based initialization order with DT I would have liked it to have a list (or map or set) of strings (sorted) in order to find a driver by name (fast). In C++ it would need something < 10 lines of source and I would be able to change the sorting algorithm from list to map(hash) or similiar by changing a few lines. Doing so in C is just a pain. Not to speak about all the possible errors when implementing the stuff in C again and again. Ok, the kernel provides some macros for lists, but e.g. they can be found only in the kernel (which means many people don't know or remember how to use them) and are by far not that flexible. While I like C++ (and quite a number of kernel people can in fact write C++ no problem) we can have a long debate about whether the STL is in fact 'done right' :-) Up to now I haven't seen something really better. Of course, there are a lot of other programming languages which do make it easy to use lists, maps and similiar, but none of them is as fast and portable as C++ while still allowing to do low-level things (if necessary). Also, I don't think init (as in PID-1) should be a large program, and therefore writing it in C would be entirely reasonable. It's a myth that C++ ends up in bigger code than C. At least in my experience. Especially when the latest additions to C++ are in effect (like the move-semantics in C++11 I like quiet a lot and which you get almost for free (by changing nothing) when you use the STL). Thread support is now also standardized (in C++11), quiet nice to use. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On Mon, Aug 18, 2014 at 08:15:45PM +0200, Alexander Holler wrote: > > Hmm, a sane and maintainable solution would use C++ with which people don't > have to manually build lists or hashes for every structure like in the > kernel (generic programming done right). So you won't find much kernel > developers there. ;) > Troll a lot do you? ;-) While I like C++ (and quite a number of kernel people can in fact write C++ no problem) we can have a long debate about whether the STL is in fact 'done right' :-) Also, I don't think init (as in PID-1) should be a large program, and therefore writing it in C would be entirely reasonable. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On Thu, Sep 4, 2014 at 1:33 PM, Alexander Holler hol...@ahsoftware.de wrote: Hmm, a sane and maintainable solution would use C++ with which people don't have to manually build lists or hashes for every structure like in the kernel (generic programming done right). So you won't find much kernel developers there. ;) Seriously Dude? Have you tried it? I was using c++ before during and after the stl was standardised and the memories of the resulting induced self hair pulling still gives me the shivers. Try writing a real time kernel with full c++ support. You have to provide the entire c++ runtime in the kernel! I still do a little c++ programming when i am forced to but its only in small pieces. Ill go crazy otherwise. I've started to use C++ when only precompilers (to translate C++ to C) were available. That was long before the STL was standardised. What's actually wrong with C++ at a language design level. Short version: http://lwn.net/Articles/504751/ Long version (parts 1, 2, 3): http://landley.net/notes-2011.html#16-03-2011 http://landley.net/notes-2011.html#19-03-2011 http://landley.net/notes-2011.html#20-03-2011 Seriously, saying C++ is a good language because it contains the whole of C is like saying a mud pie is a good beverage because it contains an entire glass of water. Do you honestly think this is the first time this topic has come up? http://harmful.cat-v.org/software/c++/linus Rob -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On Mon, Aug 18, 2014 at 08:15:45PM +0200, Alexander Holler wrote: Hmm, a sane and maintainable solution would use C++ with which people don't have to manually build lists or hashes for every structure like in the kernel (generic programming done right). So you won't find much kernel developers there. ;) Troll a lot do you? ;-) While I like C++ (and quite a number of kernel people can in fact write C++ no problem) we can have a long debate about whether the STL is in fact 'done right' :-) Also, I don't think init (as in PID-1) should be a large program, and therefore writing it in C would be entirely reasonable. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
Am 04.09.2014 09:54, schrieb Peter Zijlstra: On Mon, Aug 18, 2014 at 08:15:45PM +0200, Alexander Holler wrote: Hmm, a sane and maintainable solution would use C++ with which people don't have to manually build lists or hashes for every structure like in the kernel (generic programming done right). So you won't find much kernel developers there. ;) Troll a lot do you? ;-) Not really. I just hate all the stuff which is necessary in C when I e.g. want a sorted list, map or set for whatever structure I have the need for. I had fun doing so 30 years ago, when I started to learn C, but now it's just tiring. E.g. for the dependency based initialization order with DT I would have liked it to have a list (or map or set) of strings (sorted) in order to find a driver by name (fast). In C++ it would need something 10 lines of source and I would be able to change the sorting algorithm from list to map(hash) or similiar by changing a few lines. Doing so in C is just a pain. Not to speak about all the possible errors when implementing the stuff in C again and again. Ok, the kernel provides some macros for lists, but e.g. they can be found only in the kernel (which means many people don't know or remember how to use them) and are by far not that flexible. While I like C++ (and quite a number of kernel people can in fact write C++ no problem) we can have a long debate about whether the STL is in fact 'done right' :-) Up to now I haven't seen something really better. Of course, there are a lot of other programming languages which do make it easy to use lists, maps and similiar, but none of them is as fast and portable as C++ while still allowing to do low-level things (if necessary). Also, I don't think init (as in PID-1) should be a large program, and therefore writing it in C would be entirely reasonable. It's a myth that C++ ends up in bigger code than C. At least in my experience. Especially when the latest additions to C++ are in effect (like the move-semantics in C++11 I like quiet a lot and which you get almost for free (by changing nothing) when you use the STL). Thread support is now also standardized (in C++11), quiet nice to use. Regards, Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On 2014-09-04 06:16, Alexander Holler wrote: It's a myth that C++ ends up in bigger code than C. At least in my experience. Especially when the latest additions to C++ are in effect (like the move-semantics in C++11 I like quiet a lot and which you get almost for free (by changing nothing) when you use the STL). Thread support is now also standardized (in C++11), quiet nice to use. Assuming you are writing in a standalone environment (no standard libraries), then yes, your code will usually be about the same size (unless you go way overboard with the object-oriented stuff); but the runtime is larger in almost all non-standalone environments, and there are some cases that code does end up larger in C++. A lot of 'Clean C' (stuff written so that it compiles correctly as C, C++ and Objective C) that I have seen seems to end up larger (by about 4-6%) when built as C++ (although it usually does much worse as Objective C). smime.p7s Description: S/MIME Cryptographic Signature
Re: OT: Open letter to the Linux World
Am 04.09.2014 16:36, schrieb Austin S Hemmelgarn: On 2014-09-04 06:16, Alexander Holler wrote: It's a myth that C++ ends up in bigger code than C. At least in my experience. Especially when the latest additions to C++ are in effect (like the move-semantics in C++11 I like quiet a lot and which you get almost for free (by changing nothing) when you use the STL). Thread support is now also standardized (in C++11), quiet nice to use. Assuming you are writing in a standalone environment (no standard libraries), then yes, your code will usually be about the same size (unless you go way overboard with the object-oriented stuff); but the runtime is larger in almost all non-standalone environments, and there are some cases that code does end up larger in C++. A lot of 'Clean C' (stuff written so that it compiles correctly as C, C++ and Objective C) that I have seen seems to end up larger (by about 4-6%) when built as C++ (although it usually does much worse as Objective C). There are always corner cases and I never would use some Clean C code to compare sizes of C and C++. There is a whole lot of stuff you just can't, shouldn't or wouldn't do when using C instead of C++. And just throwing in some numbers without any explanation about features (like exceptions), optimizations and so on you've enabled for the tests you used to get those numbers, doesn't work. ;) I can't really comment on what you mean with standalone environment or non-standalone environment, as I don't know what you mean with that. But if several programms share e.g. the stuff which is in libstdc++. you'll get a lot of size back when compared with C-only programms where everyone invents the wheel again and again. Regards, Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On 2014-09-04 13:29, Alexander Holler wrote: Am 04.09.2014 16:36, schrieb Austin S Hemmelgarn: On 2014-09-04 06:16, Alexander Holler wrote: It's a myth that C++ ends up in bigger code than C. At least in my experience. Especially when the latest additions to C++ are in effect (like the move-semantics in C++11 I like quiet a lot and which you get almost for free (by changing nothing) when you use the STL). Thread support is now also standardized (in C++11), quiet nice to use. Assuming you are writing in a standalone environment (no standard libraries), then yes, your code will usually be about the same size (unless you go way overboard with the object-oriented stuff); but the runtime is larger in almost all non-standalone environments, and there are some cases that code does end up larger in C++. A lot of 'Clean C' (stuff written so that it compiles correctly as C, C++ and Objective C) that I have seen seems to end up larger (by about 4-6%) when built as C++ (although it usually does much worse as Objective C). There are always corner cases and I never would use some Clean C code to compare sizes of C and C++. There is a whole lot of stuff you just can't, shouldn't or wouldn't do when using C instead of C++. And just throwing in some numbers without any explanation about features (like exceptions), optimizations and so on you've enabled for the tests you used to get those numbers, doesn't work. ;) I can't really comment on what you mean with standalone environment or non-standalone environment, as I don't know what you mean with that. But if several programms share e.g. the stuff which is in libstdc++. you'll get a lot of size back when compared with C-only programms where everyone invents the wheel again and again. By standalone environment, I mean no libraries, no libc[++], no external dependencies, and in the case of a lot of kernel programming, no built-ins. A OS kernel HAS to be written like that, and it's easier to do that in C than C++. I doubt that you have ever looked at any source code for Windows drivers, but Windows is written in C++, and they still are just as mind-numbingly insane as some of the poorly maintained, vendor originated Linux drivers. Not all C is like the Linux kernel, and in fact, if you use Linux, probably more than half of your user-space programs were written in C. They use dynamic linking just like C++ programs (but often with less complex symbol mangling). smime.p7s Description: S/MIME Cryptographic Signature
Re: OT: Open letter to the Linux World
Am 04.09.2014 19:58, schrieb Austin S Hemmelgarn: On 2014-09-04 13:29, Alexander Holler wrote: Am 04.09.2014 16:36, schrieb Austin S Hemmelgarn: On 2014-09-04 06:16, Alexander Holler wrote: It's a myth that C++ ends up in bigger code than C. At least in my experience. Especially when the latest additions to C++ are in effect (like the move-semantics in C++11 I like quiet a lot and which you get almost for free (by changing nothing) when you use the STL). Thread support is now also standardized (in C++11), quiet nice to use. Assuming you are writing in a standalone environment (no standard libraries), then yes, your code will usually be about the same size (unless you go way overboard with the object-oriented stuff); but the runtime is larger in almost all non-standalone environments, and there are some cases that code does end up larger in C++. A lot of 'Clean C' (stuff written so that it compiles correctly as C, C++ and Objective C) that I have seen seems to end up larger (by about 4-6%) when built as C++ (although it usually does much worse as Objective C). There are always corner cases and I never would use some Clean C code to compare sizes of C and C++. There is a whole lot of stuff you just can't, shouldn't or wouldn't do when using C instead of C++. And just throwing in some numbers without any explanation about features (like exceptions), optimizations and so on you've enabled for the tests you used to get those numbers, doesn't work. ;) I can't really comment on what you mean with standalone environment or non-standalone environment, as I don't know what you mean with that. But if several programms share e.g. the stuff which is in libstdc++. you'll get a lot of size back when compared with C-only programms where everyone invents the wheel again and again. By standalone environment, I mean no libraries, no libc[++], no external dependencies, and in the case of a lot of kernel programming, no built-ins. A OS kernel HAS to be written like that, and it's easier to do that in C than C++. I doubt that you have ever looked at any source code for Windows drivers, but Windows is written in C++, and they still are just as mind-numbingly insane as some of the poorly maintained, vendor originated Linux drivers. I've seen drivers for Windows and for OS2/2 and DOS and FreeBSD and ... But throwing the ball back, did you know that all Arduino SW is in C++? ;) Not all C is like the Linux kernel, and in fact, if you use Linux, probably more than half of your user-space programs were written in C. They use dynamic linking just like C++ programs (but often with less complex symbol mangling). This thread isn't about the kernel, but some userspace program which does quiet a lot and which wants to do even more. I've just used one example I did in the kernel space to explain what I miss when I'm using or having to use C instead of C++. I do understand why the Linux kernel is (still) in C and don't want to start a discussion about that. Regards, Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On Mon, Aug 18, 2014 at 7:15 PM, Alexander Holler hol...@ahsoftware.de wrote: Am 13.08.2014 11:00, schrieb Borislav Petkov: On Wed, Aug 13, 2014 at 10:27:56AM +0200, Peter Zijlstra wrote: And the thing is; we're all very busy so we tend to take the 'easy' way out for things like this; but wholesale switching all my machines is indeed painful, and I'm not liking. Right, I think kernel people will gladly jump on a sane solution devoid of that kids-jerking-off-on-linux-desktop-just-for-the-fun-of-it situation if someone would present them with one. So, if someone would come up and do a sane init design without the jerking off, kernel people would jump on that in a heartbeat. Someone might even start getting patches from them too. ^^Hint^^ ^^hint^^. :-) Hmm, a sane and maintainable solution would use C++ with which people don't have to manually build lists or hashes for every structure like in the kernel (generic programming done right). So you won't find much kernel developers there. ;) Seriously Dude? Have you tried it? I was using c++ before during and after the stl was standardised and the memories of the resulting induced self hair pulling still gives me the shivers. Try writing a real time kernel with full c++ support. You have to provide the entire c++ runtime in the kernel! I still do a little c++ programming when i am forced to but its only in small pieces. Ill go crazy otherwise. Regards, Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
Am 04.09.2014 20:27, schrieb Rogelio Serrano: On Mon, Aug 18, 2014 at 7:15 PM, Alexander Holler hol...@ahsoftware.de wrote: Am 13.08.2014 11:00, schrieb Borislav Petkov: On Wed, Aug 13, 2014 at 10:27:56AM +0200, Peter Zijlstra wrote: And the thing is; we're all very busy so we tend to take the 'easy' way out for things like this; but wholesale switching all my machines is indeed painful, and I'm not liking. Right, I think kernel people will gladly jump on a sane solution devoid of that kids-jerking-off-on-linux-desktop-just-for-the-fun-of-it situation if someone would present them with one. So, if someone would come up and do a sane init design without the jerking off, kernel people would jump on that in a heartbeat. Someone might even start getting patches from them too. ^^Hint^^ ^^hint^^. :-) Hmm, a sane and maintainable solution would use C++ with which people don't have to manually build lists or hashes for every structure like in the kernel (generic programming done right). So you won't find much kernel developers there. ;) Seriously Dude? Have you tried it? I was using c++ before during and after the stl was standardised and the memories of the resulting induced self hair pulling still gives me the shivers. Try writing a real time kernel with full c++ support. You have to provide the entire c++ runtime in the kernel! I still do a little c++ programming when i am forced to but its only in small pieces. Ill go crazy otherwise. I've started to use C++ when only precompilers (to translate C++ to C) were available. That was long before the STL was standardised. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
Am 13.08.2014 11:00, schrieb Borislav Petkov: On Wed, Aug 13, 2014 at 10:27:56AM +0200, Peter Zijlstra wrote: And the thing is; we're all very busy so we tend to take the 'easy' way out for things like this; but wholesale switching all my machines is indeed painful, and I'm not liking. Right, I think kernel people will gladly jump on a sane solution devoid of that kids-jerking-off-on-linux-desktop-just-for-the-fun-of-it situation if someone would present them with one. So, if someone would come up and do a sane init design without the jerking off, kernel people would jump on that in a heartbeat. Someone might even start getting patches from them too. ^^Hint^^ ^^hint^^. :-) Hmm, a sane and maintainable solution would use C++ with which people don't have to manually build lists or hashes for every structure like in the kernel (generic programming done right). So you won't find much kernel developers there. ;) Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
Am 13.08.2014 11:00, schrieb Borislav Petkov: On Wed, Aug 13, 2014 at 10:27:56AM +0200, Peter Zijlstra wrote: And the thing is; we're all very busy so we tend to take the 'easy' way out for things like this; but wholesale switching all my machines is indeed painful, and I'm not liking. Right, I think kernel people will gladly jump on a sane solution devoid of that kids-jerking-off-on-linux-desktop-just-for-the-fun-of-it situation if someone would present them with one. So, if someone would come up and do a sane init design without the jerking off, kernel people would jump on that in a heartbeat. Someone might even start getting patches from them too. ^^Hint^^ ^^hint^^. :-) Hmm, a sane and maintainable solution would use C++ with which people don't have to manually build lists or hashes for every structure like in the kernel (generic programming done right). So you won't find much kernel developers there. ;) Regards, Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On Fri, Aug 15, 2014 at 3:59 AM, Vlad Glagolev wrote: > Now what do we see? Complete degradation of Linux-like ecosystem. I'm Nah, lots of embedded guys value simplicity and a modular design where you can swap actually out parts. Check out the musl-libc.org mailing list for example. Those mailing lists are the place for this sort of thing, this isn't. Way back when I wrote mdev instead of accepting udev, and I plan to do some kind of "lunchd" in toybox (loosely based on launchd but not crazy stuff like xml config files) as part of my project to make android self-hosting, which I gave a talk about last year: video: http://youtu.be/SGmtP5Lg_t0 outline: http://landley.net/talks/celf-2013.txt Keep in mind that mainframes and minicomputers got kicked up into the server space by the PC, and now smartphones are kicking the PC up there. The fight between Amazon's PC cloud and IBM big iron servers is exactly the same fight IBM's mainframes and DEC's minicomputers fought 25 years ago. Last time DEC lost, this time IBM is losing, but it doesn't matter to the rest of us. Plug your phone into a USB hub, add a USB keyboard, USB mouse, and USB to VGA (or with USB3 a USB to HDMI) adapter, and you've got the hardware of a development workstation. The software side we're working on, but it won't be the current pile of PC userspace for the same reason the PC didn't run MVS or VMS. Technological disruption goes _upmarket_, not down. Android has a no GPL in userspace policy, so nothing systemd does has any impact on the _billion_ seat android market. Among other things, if a company adds GPL software to Android they violate the Android trademark licensing guidelines and can't call the result "android". But toybox is public domain, musl is BSD licensed, they can add _our_ stuff no problem. Fighting over the desktop market in 2014 is like Unix fighting over the minicomputer and RISC workstation market in 1994. It doesn't _matter_. Sure the modern equivalent of cobol programmers will make plenty of money servicing entrenched fortune 500 fossils in that space, but the rest of us can ignore it and focus on what will replace it instead. And that's highly unlikely to include a GPL'd systemd. Busybox predates android and they're _still_ not using it. Good luck waiting them out... Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On Fri, Aug 15, 2014 at 3:59 AM, Vlad Glagolev stea...@tiberian.ru wrote: Now what do we see? Complete degradation of Linux-like ecosystem. I'm Nah, lots of embedded guys value simplicity and a modular design where you can swap actually out parts. Check out the musl-libc.org mailing list for example. Those mailing lists are the place for this sort of thing, this isn't. Way back when I wrote mdev instead of accepting udev, and I plan to do some kind of lunchd in toybox (loosely based on launchd but not crazy stuff like xml config files) as part of my project to make android self-hosting, which I gave a talk about last year: video: http://youtu.be/SGmtP5Lg_t0 outline: http://landley.net/talks/celf-2013.txt Keep in mind that mainframes and minicomputers got kicked up into the server space by the PC, and now smartphones are kicking the PC up there. The fight between Amazon's PC cloud and IBM big iron servers is exactly the same fight IBM's mainframes and DEC's minicomputers fought 25 years ago. Last time DEC lost, this time IBM is losing, but it doesn't matter to the rest of us. Plug your phone into a USB hub, add a USB keyboard, USB mouse, and USB to VGA (or with USB3 a USB to HDMI) adapter, and you've got the hardware of a development workstation. The software side we're working on, but it won't be the current pile of PC userspace for the same reason the PC didn't run MVS or VMS. Technological disruption goes _upmarket_, not down. Android has a no GPL in userspace policy, so nothing systemd does has any impact on the _billion_ seat android market. Among other things, if a company adds GPL software to Android they violate the Android trademark licensing guidelines and can't call the result android. But toybox is public domain, musl is BSD licensed, they can add _our_ stuff no problem. Fighting over the desktop market in 2014 is like Unix fighting over the minicomputer and RISC workstation market in 1994. It doesn't _matter_. Sure the modern equivalent of cobol programmers will make plenty of money servicing entrenched fortune 500 fossils in that space, but the rest of us can ignore it and focus on what will replace it instead. And that's highly unlikely to include a GPL'd systemd. Busybox predates android and they're _still_ not using it. Good luck waiting them out... Rob -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
Hello, On Wed, Aug 13, 2014 at 1:08 AM, Christopher Barry wrote: > > > What is intelligence? Not exactly the spook kind, but rather what is > the definition of intelligence in humans? This is pretty good: > http://en.wikipedia.org/wiki/Intelligence#Definitions > Do you want to see bigger picture ? Ideal intelligent application software: 1. Software which can automatically add/modify/delete functions. 2. Software which can automatically fix bugs. Ideal intelligent operating software: 1. Software which can automatically add/modify/delete hardware. 2. Software which can automatically add/modify/delete drivers. 3. Software which can automatically add/modify/delete service packs. 4. Software which can automatically add/modify/delete functions. 5. Software which can automatically fix bugs. Thanks, -- Jaswinder Singh. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On Friday 15 August 2014, Vlad Glagolev wrote: >This is a problem, which is silently ignored by those who HAS to defend >OSS' freedom. But politics (related to stuff they get a lot of money >from) of companies like RedHat isn't that white and fluffy for users, >because THEY started this chaos of perverting the UNIX philosophy. >I noticed that when they announced a brand new strategy with obfuscation >of kernel patches, so it would be damn hard for their opponents (aka >the rest of the world) to understand what these patches exactly do. [0] > >My road with Linux started in good old 2002-2003 with 3-disc RedHat >distro. You know why? Because once my irc-friend told me: "Here's a new >operating system: it's free, open-sourced and primarily -- you can >redraw everything in it (speaking of UI)". I formatted my HDD with >win2k that night. Because it was what I had been looking for -- >operating system with a total freedom. And everything you need was only >time and brains. I tried some binary distros and have discovered >they're not for me -- not much freedom enough (I needed to keep my >system clean and small without a ton of dependencies I would never >use). Source-based distros have saved me. I'm talking about those which >aren't known to 99% of Linux community (except Gentoo, ofc.) -- Source >Mage, Lunar, T2. LFS is a bit hard to maintain on >2 machines on a >yearly basis, you know. > >Now what do we see? Complete degradation of Linux-like ecosystem. I'm >not talking about Linux kernel itself, because it's going the right way >(mostly because of its head). But I'm talking about those who made >Linux what it is now. About initial developers of userland stuff, >which is (and really was) VERY fragmented. And now we see a couple of >companies (companies, indeed, not people; because yes, Linux is a >really gainful thingy, who would have ever thought like that 15 years >ago?) who wants to defragment it, like what we did with filesystems on >Windows in good old days to make it work faster. Now someone strives to >exactly the same aim -- to rake a lot of money faster than it happens >now. > >Have you ever thought what spheres will be affected? Hosting companies, >corporations migrating to Linux from billion m$ contracts (at least we >see this tendency here in Russia, in Germany and across the Europe). >I will quote IgnorantGuru to show you what will happen soon: > >"In open source, you can’t lock people out of the code like you can in >Windows. But you can make the system so complex that no one can control >it at a lower level without being a developer with lots of time to >spare. I think ultimately that’s what this is about. And the systemd >tool stack will likely eventually be used for DRM and other restrictive >technologies (just as HAL was)." [1] > >"I think it’s safe to say that any spirit of freedom and diversity >that once drove Linux is dead. The new people entering the realm of >development in Linux are just Windows developers looking for a larger >base and more money, or simply corporate whores tearing it apart for >short-sighted, malicious goals (which they themselves understand very >poorly). They care not for any of the principles that made Linux what >it is, or was. > >So Linux has been lost because the community has failed to protect it >and help it grow. And this isn’t just about toolkits – the infection >goes deep into the kernel, udev, the init system, and other areas. In >the next few years any remaining GNU Linux users who even know what a >principle is, will need to find a new home." [2] > >exhaustively enough, right? > >Do you think that everyone will happily run to buy yet another >subscription from RedHat? Then how is it different from Windows? >Because it's open-sourced? To whom? To RedHat employees? Meh. > >I'm not against RedHat, I'm against politics they follow. And I feel its >disruptive effect on many people across mailing lists, forums, irc, >etc. -- everything that links people who created tools for >essential existence of this company! > >There are a lot of standards that describe UNIX-like arch like POSIX, >FHS, etc. Where are all those distro-builders who refuse to see them? >Busy in race adapting yet another systemd version while reading gdbm >traces of it? Very useful time-spending. > >Thank you, Christopher. At least there are people who see this >idiocracy under the right angle. > >Because everything depends on human resources, personally I see the only >one way to keep high-quality and yet easily maintained Linux distros >afloat: support distros with strict policies and rules preventing >the worms like systemd from infiltration and gnawing from inside out. >Linux community needs yet another dot-com boom in Linux distros -- like >Ubuntu that changed (or helped to change) the world. > >It is time to implement the protocols themselves, not to write a train >of RFCs for them. Otherwise we would have no choice for VRRP. >Because the real enemy is close and.. remember,
Re: OT: Open letter to the Linux World
This is a problem, which is silently ignored by those who HAS to defend OSS' freedom. But politics (related to stuff they get a lot of money from) of companies like RedHat isn't that white and fluffy for users, because THEY started this chaos of perverting the UNIX philosophy. I noticed that when they announced a brand new strategy with obfuscation of kernel patches, so it would be damn hard for their opponents (aka the rest of the world) to understand what these patches exactly do. [0] My road with Linux started in good old 2002-2003 with 3-disc RedHat distro. You know why? Because once my irc-friend told me: "Here's a new operating system: it's free, open-sourced and primarily -- you can redraw everything in it (speaking of UI)". I formatted my HDD with win2k that night. Because it was what I had been looking for -- operating system with a total freedom. And everything you need was only time and brains. I tried some binary distros and have discovered they're not for me -- not much freedom enough (I needed to keep my system clean and small without a ton of dependencies I would never use). Source-based distros have saved me. I'm talking about those which aren't known to 99% of Linux community (except Gentoo, ofc.) -- Source Mage, Lunar, T2. LFS is a bit hard to maintain on >2 machines on a yearly basis, you know. Now what do we see? Complete degradation of Linux-like ecosystem. I'm not talking about Linux kernel itself, because it's going the right way (mostly because of its head). But I'm talking about those who made Linux what it is now. About initial developers of userland stuff, which is (and really was) VERY fragmented. And now we see a couple of companies (companies, indeed, not people; because yes, Linux is a really gainful thingy, who would have ever thought like that 15 years ago?) who wants to defragment it, like what we did with filesystems on Windows in good old days to make it work faster. Now someone strives to exactly the same aim -- to rake a lot of money faster than it happens now. Have you ever thought what spheres will be affected? Hosting companies, corporations migrating to Linux from billion m$ contracts (at least we see this tendency here in Russia, in Germany and across the Europe). I will quote IgnorantGuru to show you what will happen soon: "In open source, you can’t lock people out of the code like you can in Windows. But you can make the system so complex that no one can control it at a lower level without being a developer with lots of time to spare. I think ultimately that’s what this is about. And the systemd tool stack will likely eventually be used for DRM and other restrictive technologies (just as HAL was)." [1] "I think it’s safe to say that any spirit of freedom and diversity that once drove Linux is dead. The new people entering the realm of development in Linux are just Windows developers looking for a larger base and more money, or simply corporate whores tearing it apart for short-sighted, malicious goals (which they themselves understand very poorly). They care not for any of the principles that made Linux what it is, or was. So Linux has been lost because the community has failed to protect it and help it grow. And this isn’t just about toolkits – the infection goes deep into the kernel, udev, the init system, and other areas. In the next few years any remaining GNU Linux users who even know what a principle is, will need to find a new home." [2] exhaustively enough, right? Do you think that everyone will happily run to buy yet another subscription from RedHat? Then how is it different from Windows? Because it's open-sourced? To whom? To RedHat employees? Meh. I'm not against RedHat, I'm against politics they follow. And I feel its disruptive effect on many people across mailing lists, forums, irc, etc. -- everything that links people who created tools for essential existence of this company! There are a lot of standards that describe UNIX-like arch like POSIX, FHS, etc. Where are all those distro-builders who refuse to see them? Busy in race adapting yet another systemd version while reading gdbm traces of it? Very useful time-spending. Thank you, Christopher. At least there are people who see this idiocracy under the right angle. Because everything depends on human resources, personally I see the only one way to keep high-quality and yet easily maintained Linux distros afloat: support distros with strict policies and rules preventing the worms like systemd from infiltration and gnawing from inside out. Linux community needs yet another dot-com boom in Linux distros -- like Ubuntu that changed (or helped to change) the world. It is time to implement the protocols themselves, not to write a train of RFCs for them. Otherwise we would have no choice for VRRP. Because the real enemy is close and.. remember, Adam: everybody lies © [0] http://lwn.net/Articles/430098/ [1] http://igurublog.wordpress.com/2014/02/02/ubuntu-to-dump-nautilus-wants-your-input/
Re: OT: Open letter to the Linux World
This is a problem, which is silently ignored by those who HAS to defend OSS' freedom. But politics (related to stuff they get a lot of money from) of companies like RedHat isn't that white and fluffy for users, because THEY started this chaos of perverting the UNIX philosophy. I noticed that when they announced a brand new strategy with obfuscation of kernel patches, so it would be damn hard for their opponents (aka the rest of the world) to understand what these patches exactly do. [0] My road with Linux started in good old 2002-2003 with 3-disc RedHat distro. You know why? Because once my irc-friend told me: Here's a new operating system: it's free, open-sourced and primarily -- you can redraw everything in it (speaking of UI). I formatted my HDD with win2k that night. Because it was what I had been looking for -- operating system with a total freedom. And everything you need was only time and brains. I tried some binary distros and have discovered they're not for me -- not much freedom enough (I needed to keep my system clean and small without a ton of dependencies I would never use). Source-based distros have saved me. I'm talking about those which aren't known to 99% of Linux community (except Gentoo, ofc.) -- Source Mage, Lunar, T2. LFS is a bit hard to maintain on 2 machines on a yearly basis, you know. Now what do we see? Complete degradation of Linux-like ecosystem. I'm not talking about Linux kernel itself, because it's going the right way (mostly because of its head). But I'm talking about those who made Linux what it is now. About initial developers of userland stuff, which is (and really was) VERY fragmented. And now we see a couple of companies (companies, indeed, not people; because yes, Linux is a really gainful thingy, who would have ever thought like that 15 years ago?) who wants to defragment it, like what we did with filesystems on Windows in good old days to make it work faster. Now someone strives to exactly the same aim -- to rake a lot of money faster than it happens now. Have you ever thought what spheres will be affected? Hosting companies, corporations migrating to Linux from billion m$ contracts (at least we see this tendency here in Russia, in Germany and across the Europe). I will quote IgnorantGuru to show you what will happen soon: In open source, you can’t lock people out of the code like you can in Windows. But you can make the system so complex that no one can control it at a lower level without being a developer with lots of time to spare. I think ultimately that’s what this is about. And the systemd tool stack will likely eventually be used for DRM and other restrictive technologies (just as HAL was). [1] I think it’s safe to say that any spirit of freedom and diversity that once drove Linux is dead. The new people entering the realm of development in Linux are just Windows developers looking for a larger base and more money, or simply corporate whores tearing it apart for short-sighted, malicious goals (which they themselves understand very poorly). They care not for any of the principles that made Linux what it is, or was. So Linux has been lost because the community has failed to protect it and help it grow. And this isn’t just about toolkits – the infection goes deep into the kernel, udev, the init system, and other areas. In the next few years any remaining GNU Linux users who even know what a principle is, will need to find a new home. [2] exhaustively enough, right? Do you think that everyone will happily run to buy yet another subscription from RedHat? Then how is it different from Windows? Because it's open-sourced? To whom? To RedHat employees? Meh. I'm not against RedHat, I'm against politics they follow. And I feel its disruptive effect on many people across mailing lists, forums, irc, etc. -- everything that links people who created tools for essential existence of this company! There are a lot of standards that describe UNIX-like arch like POSIX, FHS, etc. Where are all those distro-builders who refuse to see them? Busy in race adapting yet another systemd version while reading gdbm traces of it? Very useful time-spending. Thank you, Christopher. At least there are people who see this idiocracy under the right angle. Because everything depends on human resources, personally I see the only one way to keep high-quality and yet easily maintained Linux distros afloat: support distros with strict policies and rules preventing the worms like systemd from infiltration and gnawing from inside out. Linux community needs yet another dot-com boom in Linux distros -- like Ubuntu that changed (or helped to change) the world. It is time to implement the protocols themselves, not to write a train of RFCs for them. Otherwise we would have no choice for VRRP. Because the real enemy is close and.. remember, Adam: everybody lies © [0] http://lwn.net/Articles/430098/ [1] http://igurublog.wordpress.com/2014/02/02/ubuntu-to-dump-nautilus-wants-your-input/ [2]
Re: OT: Open letter to the Linux World
On Friday 15 August 2014, Vlad Glagolev wrote: This is a problem, which is silently ignored by those who HAS to defend OSS' freedom. But politics (related to stuff they get a lot of money from) of companies like RedHat isn't that white and fluffy for users, because THEY started this chaos of perverting the UNIX philosophy. I noticed that when they announced a brand new strategy with obfuscation of kernel patches, so it would be damn hard for their opponents (aka the rest of the world) to understand what these patches exactly do. [0] My road with Linux started in good old 2002-2003 with 3-disc RedHat distro. You know why? Because once my irc-friend told me: Here's a new operating system: it's free, open-sourced and primarily -- you can redraw everything in it (speaking of UI). I formatted my HDD with win2k that night. Because it was what I had been looking for -- operating system with a total freedom. And everything you need was only time and brains. I tried some binary distros and have discovered they're not for me -- not much freedom enough (I needed to keep my system clean and small without a ton of dependencies I would never use). Source-based distros have saved me. I'm talking about those which aren't known to 99% of Linux community (except Gentoo, ofc.) -- Source Mage, Lunar, T2. LFS is a bit hard to maintain on 2 machines on a yearly basis, you know. Now what do we see? Complete degradation of Linux-like ecosystem. I'm not talking about Linux kernel itself, because it's going the right way (mostly because of its head). But I'm talking about those who made Linux what it is now. About initial developers of userland stuff, which is (and really was) VERY fragmented. And now we see a couple of companies (companies, indeed, not people; because yes, Linux is a really gainful thingy, who would have ever thought like that 15 years ago?) who wants to defragment it, like what we did with filesystems on Windows in good old days to make it work faster. Now someone strives to exactly the same aim -- to rake a lot of money faster than it happens now. Have you ever thought what spheres will be affected? Hosting companies, corporations migrating to Linux from billion m$ contracts (at least we see this tendency here in Russia, in Germany and across the Europe). I will quote IgnorantGuru to show you what will happen soon: In open source, you can’t lock people out of the code like you can in Windows. But you can make the system so complex that no one can control it at a lower level without being a developer with lots of time to spare. I think ultimately that’s what this is about. And the systemd tool stack will likely eventually be used for DRM and other restrictive technologies (just as HAL was). [1] I think it’s safe to say that any spirit of freedom and diversity that once drove Linux is dead. The new people entering the realm of development in Linux are just Windows developers looking for a larger base and more money, or simply corporate whores tearing it apart for short-sighted, malicious goals (which they themselves understand very poorly). They care not for any of the principles that made Linux what it is, or was. So Linux has been lost because the community has failed to protect it and help it grow. And this isn’t just about toolkits – the infection goes deep into the kernel, udev, the init system, and other areas. In the next few years any remaining GNU Linux users who even know what a principle is, will need to find a new home. [2] exhaustively enough, right? Do you think that everyone will happily run to buy yet another subscription from RedHat? Then how is it different from Windows? Because it's open-sourced? To whom? To RedHat employees? Meh. I'm not against RedHat, I'm against politics they follow. And I feel its disruptive effect on many people across mailing lists, forums, irc, etc. -- everything that links people who created tools for essential existence of this company! There are a lot of standards that describe UNIX-like arch like POSIX, FHS, etc. Where are all those distro-builders who refuse to see them? Busy in race adapting yet another systemd version while reading gdbm traces of it? Very useful time-spending. Thank you, Christopher. At least there are people who see this idiocracy under the right angle. Because everything depends on human resources, personally I see the only one way to keep high-quality and yet easily maintained Linux distros afloat: support distros with strict policies and rules preventing the worms like systemd from infiltration and gnawing from inside out. Linux community needs yet another dot-com boom in Linux distros -- like Ubuntu that changed (or helped to change) the world. It is time to implement the protocols themselves, not to write a train of RFCs for them. Otherwise we would have no choice for VRRP. Because the real enemy is close and.. remember, Adam: everybody lies آ© [0] http://lwn.net/Articles/430098/ [1]
Re: OT: Open letter to the Linux World
Hello, On Wed, Aug 13, 2014 at 1:08 AM, Christopher Barry christopher.r.ba...@gmail.com wrote: What is intelligence? Not exactly the spook kind, but rather what is the definition of intelligence in humans? This is pretty good: http://en.wikipedia.org/wiki/Intelligence#Definitions Do you want to see bigger picture ? Ideal intelligent application software: 1. Software which can automatically add/modify/delete functions. 2. Software which can automatically fix bugs. Ideal intelligent operating software: 1. Software which can automatically add/modify/delete hardware. 2. Software which can automatically add/modify/delete drivers. 3. Software which can automatically add/modify/delete service packs. 4. Software which can automatically add/modify/delete functions. 5. Software which can automatically fix bugs. Thanks, -- Jaswinder Singh. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On 12/08/14 01:38 PM, Christopher Barry wrote: What is intelligence? Not exactly the spook kind, but rather what is the definition of intelligence in humans? This is pretty good: http://en.wikipedia.org/wiki/Intelligence#Definitions By most accounts, the self-appointed and arguably too influential creators and thinkers of the day around the 'One Linux' idea fit the definition of intelligent people - at least in the technical realm. And their messages are pretty compelling: * Simplify cross-distro development. * Enable faster boot times. * Enable an on-demand, event driven architecture, similar to 'Modern' Operating Systems. * Bring order and control to subsystems that have had as many different tools as there were distros. All seemingly noble goals. All apparently come from a deep desire to contribute and make things better. Almost anyone could argue that these intelligent people thought hard about these issues, and put an enormous amount of effort into a solution to these problems. Unfortunately, the solution they came up with, as you may have guessed by now, is 'systemd'. While not new, it's grotesque impact has finally reached me and I must speak to it publicly. So, what is systemd? Well, meet your new God. You may have been praying at the alter of simplicity, but your religion is being deprecated. It likely already happened without your knowledge during an upgrade of your Linux box. systemd is the all knowing, all controlling meta-deity that sees all and supervises all. It's the new One Master Process that aspires to control everything it can - and it's already doing a lot. It's what init would look like if it were a transformer on steroids. It's complicated, multi-faceted, opaque, and supremely powerful. I had heard about systemd a few years back, when upstart and some other init replacements I can't remember were showing up on the scene. And while it seemed mildly interesting, I was not in favor of using it, nor any of them for that matter. init was working just fine for me. init was simple and robust. While configuration had it's distro-specific differences, it was often these differences that made one pick the distro to use in the first place, and to stay with that distro. The tools essentially *were* the distro. I just dist-upgraded to Jessie, and voila - PID 1 was suddenly systemd. What a clusterfuck. You might want to send this to a mailing list that's remotely relevant, like perhaps a Debian one. Though I wouldn't expect a very productive response there either, since you neglected to include any reasons behind your rant other than "they changed it, now it sucks". -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
Hello, On Wed, Aug 13, 2014 at 3:27 AM, Peter Zijlstra wrote: > On Tue, Aug 12, 2014 at 11:07:05PM +0100, Måns Rullgård wrote: >> Steven Rostedt writes: >> >> > Nice rant, I sympathize with you (just complaining about this on G+). >> >> Made my day. >> >> > I'm just waiting for Linus to get pissed enough to write his own init >> > routine. Maybe he'll call it "Boot Init Through Computer Hardware". >> >> The trouble is that most of the heavy-weight kernel developers don't >> seem to care at all about what goes on in userspace. > > Well, I know for a fact that quite a number do; but so far most people > who care have been able to steer clear of this trainwreck so we did. > > I'm about to switch all my machines to Gentoo (from Debian) because that > will indeed allow you to build a distro without much of this nonsense > in -- because as has been eloquently said; you simply don't need this > fucking shite to run a 'normal' machine. > > And the thing is; we're all very busy so we tend to take the 'easy' way > out for things like this; but wholesale switching all my machines is > indeed painful, and I'm not liking. Another solution here which is more similar to Debian than Gentoo, is Alpine (http://www.alpinelinux.org). Alpine is a distribution which takes a lot of design cues from Debian (although we do use OpenRC). The typical user experience when using the alpine package management tools is easy for Debian users to understand, being modeled on the apt package manager. Another interesting detail is that we have adopted musl libc recently, and are working on glibc binary compatibility where it matters - the non-free flash player is already working here, and nvidia/fglrx are interesting targets as well. We feel that our usage of musl libc allows for improved security of the entire distribution, as musl's simplified implementation of standard library features has a much lower attack surface, and indeed a common observation is that many applications behave more robustly on Alpine (using musl) than other distributions they are developing against. At present, there are no plans to adopt systemd there, and systemd would need to be radically different than it is now to even be considered as the init system. The main blockers for systemd on Alpine are believed to be permanent: - systemd intentionally uses non-standard extensions to glibc - systemd components cannot be safely split up to reduce installation footprint - systemd has too much attack surface on PID 1 (d-bus, etc.) - kdbus support could be reasonably implemented without systemd - alpine does not wish to be 'forced' into adopting systemd through applications using systemd-exclusive APIs It should also be mentioned that Alpine is lightweight by default. This has been a goal that Debian in many ways has strayed from over the years. An empty LXC container with an alpine install in it, but no deployed applications, only takes approximately 3 megabytes of disc. Debian takes many orders of magnitude more now. William -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
Am Mittwoch, 13. August 2014, 10:57:01 schrieb Måns Rullgård: > Martin Steigerwald writes: > > Am Mittwoch, 13. August 2014, 10:27:56 schrieb Peter Zijlstra: > >> On Tue, Aug 12, 2014 at 11:07:05PM +0100, Måns Rullgård wrote: > >> > Steven Rostedt writes: > >> > > Nice rant, I sympathize with you (just complaining about this on G+). > >> > > >> > > >> > > >> > Made my day. > >> > > >> > > >> > > >> > > I'm just waiting for Linus to get pissed enough to write his own init > >> > > routine. Maybe he'll call it "Boot Init Through Computer Hardware". > >> > > >> > > >> > > >> > The trouble is that most of the heavy-weight kernel developers don't > >> > seem to care at all about what goes on in userspace. > >> > >> > >> > >> Well, I know for a fact that quite a number do; but so far most people > >> who care have been able to steer clear of this trainwreck so we did. > >> > >> > >> > >> I'm about to switch all my machines to Gentoo (from Debian) because that > >> will indeed allow you to build a distro without much of this nonsense > >> in -- because as has been eloquently said; you simply don't need this > >> fucking shite to run a 'normal' machine. > >> > >> > >> > >> And the thing is; we're all very busy so we tend to take the 'easy' way > >> out for things like this; but wholesale switching all my machines is > >> indeed painful, and I'm not liking. > > > > Just for record: > > > > Debian continues and will (for now and supposedly Jessie lifetime) > > continue to work without systemd as PID 1 using systemd-shim and > > cgmanager. > > For now. Non-systemd configurations will receive little testing, if > any. Once enough breakage accumulates, someone will issue an ultimatum > for dropping such support entirely unless those who complain fix > everything within an unreasonably short time. Obviously most things > will remain broken, because those who opposed systemd are not package > maintainers and have other jobs to do, and non-systemd support will be > removed. I expect this to happen in unstable/testing within 18 months. I usually do not engage in predictions of the future, you know… my crystal ball has holidays. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
Am Mittwoch, 13. August 2014, 11:52:13 schrieb Peter Zijlstra: > On Wed, Aug 13, 2014 at 11:37:28AM +0200, Martin Steigerwald wrote: > > That all said: I believe that any feedback like this is best served on > > systemd-devel mailing list – maybe in an attempt to express it in a > > somewhat polite, yet also direct way. Instead of on LKML, debian-user, > > debian-devel and you name it what other mailinglists. Cause that would > > increase the chance of upstream noticing it. > > I think most people have given up on talking to them entirely. I > certainly have. And yes, its a popular subject for bitchin' about. And I > realize that bitchin' won't fix thing at all, but we all need to vent > our frustration somewhere. I understand and symphatize with that. I have given up on giving feedback to PulseAudio upstream as well for now. I just try to avoid it, but now Skype required skype 4.3. I don´t use Skype at the moment, but I support a close family member who does, and well… I hope it will just work. Or its Google Hangout or at some point a free as in freedom *and* easy alternative I am not yet aware of. I read systemd-devel and I think there are quite sane discussions, but I believe if I bring up general feedback to systemd or question certain things about it… well… I feel reluctant about it at least. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: OT: Open letter to the Linux World
Martin Steigerwald writes: > Am Mittwoch, 13. August 2014, 10:27:56 schrieb Peter Zijlstra: >> On Tue, Aug 12, 2014 at 11:07:05PM +0100, Måns Rullgård wrote: >> > Steven Rostedt writes: >> > > Nice rant, I sympathize with you (just complaining about this on G+). >> > >> > Made my day. >> > >> > > I'm just waiting for Linus to get pissed enough to write his own init >> > > routine. Maybe he'll call it "Boot Init Through Computer Hardware". >> > >> > The trouble is that most of the heavy-weight kernel developers don't >> > seem to care at all about what goes on in userspace. >> >> Well, I know for a fact that quite a number do; but so far most people >> who care have been able to steer clear of this trainwreck so we did. >> >> I'm about to switch all my machines to Gentoo (from Debian) because that >> will indeed allow you to build a distro without much of this nonsense >> in -- because as has been eloquently said; you simply don't need this >> fucking shite to run a 'normal' machine. >> >> And the thing is; we're all very busy so we tend to take the 'easy' way >> out for things like this; but wholesale switching all my machines is >> indeed painful, and I'm not liking. > > Just for record: > > Debian continues and will (for now and supposedly Jessie lifetime) > continue to work without systemd as PID 1 using systemd-shim and > cgmanager. For now. Non-systemd configurations will receive little testing, if any. Once enough breakage accumulates, someone will issue an ultimatum for dropping such support entirely unless those who complain fix everything within an unreasonably short time. Obviously most things will remain broken, because those who opposed systemd are not package maintainers and have other jobs to do, and non-systemd support will be removed. I expect this to happen in unstable/testing within 18 months. > That all said: I believe that any feedback like this is best served on > systemd-devel mailing list – maybe in an attempt to express it in a > somewhat polite, yet also direct way. Instead of on LKML, debian-user, > debian-devel and you name it what other mailinglists. Cause that would > increase the chance of upstream noticing it. This discussion is not aimed at systemd developers. We already know they don't give a hoot. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On Wed, Aug 13, 2014 at 11:37:28AM +0200, Martin Steigerwald wrote: > > Also I think: > > martin@merkaba:~> ls -l /sbin/init > -rwxr-xr-x 1 root root 40648 Aug 3 21:01 /sbin/init > martin@merkaba:~> ls -l /bin/systemd > lrwxrwxrwx 1 root root 20 Aug 6 13:41 /bin/systemd -> /lib/systemd/systemd > martin@merkaba:~> ls -l /lib/systemd/systemd > -rwxr-xr-x 1 root root 1084816 Aug 6 13:42 /lib/systemd/systemd > > martin@merkaba:~> apt list 2>&1 | egrep "(^systemd/|sysvinit-core)" > systemd/unstable,now 208-7 amd64 [installed] > sysvinit-core/unstable,now 2.88dsf-53.3 amd64 [installed,automatic] > > is highly worrying. A one MiB binary as PID 1? Really? Yeah, utterly insane. PID 1 should not be doing these things; no single process should do as much as systemd does, PID 1 least of all. pgpilTjsoP3LT.pgp Description: PGP signature
Re: OT: Open letter to the Linux World
On Wed, Aug 13, 2014 at 11:37:28AM +0200, Martin Steigerwald wrote: > That all said: I believe that any feedback like this is best served on > systemd-devel mailing list – maybe in an attempt to express it in a somewhat > polite, yet also direct way. Instead of on LKML, debian-user, debian-devel > and > you name it what other mailinglists. Cause that would increase the chance of > upstream noticing it. I think most people have given up on talking to them entirely. I certainly have. And yes, its a popular subject for bitchin' about. And I realize that bitchin' won't fix thing at all, but we all need to vent our frustration somewhere. pgpkiF5q8jdNt.pgp Description: PGP signature
Re: OT: Open letter to the Linux World
Am Mittwoch, 13. August 2014, 10:27:56 schrieb Peter Zijlstra: > On Tue, Aug 12, 2014 at 11:07:05PM +0100, Måns Rullgård wrote: > > Steven Rostedt writes: > > > Nice rant, I sympathize with you (just complaining about this on G+). > > > > Made my day. > > > > > I'm just waiting for Linus to get pissed enough to write his own init > > > routine. Maybe he'll call it "Boot Init Through Computer Hardware". > > > > The trouble is that most of the heavy-weight kernel developers don't > > seem to care at all about what goes on in userspace. > > Well, I know for a fact that quite a number do; but so far most people > who care have been able to steer clear of this trainwreck so we did. > > I'm about to switch all my machines to Gentoo (from Debian) because that > will indeed allow you to build a distro without much of this nonsense > in -- because as has been eloquently said; you simply don't need this > fucking shite to run a 'normal' machine. > > And the thing is; we're all very busy so we tend to take the 'easy' way > out for things like this; but wholesale switching all my machines is > indeed painful, and I'm not liking. Just for record: Debian continues and will (for now and supposedly Jessie lifetime) continue to work without systemd as PID 1 using systemd-shim and cgmanager. And no: Debian didn´t make the choice easily or without discussion. I believe this to be the most controversial decision inside the Debian project and of the Tech CTTE in a decade or so, *after* tons over tons of discussion before. But one part of the decision is that Debian will continue to support other init systems at the moment. Its still being discussed in about all major Debian mailing lists up to now popping up every now and then. I am not completely opposed to quite some ideas within systemd, but what really upsets me most in this is the "I know it better than you, go away!" kind of attitude I also experienced with PulseAudio developers who just give a damn about my use case of wanting to start music playback on one X11 session and then switch to another session and *continue* to listen to that music. Just as one example where I ran into problems with PulseAudio I can just get rid of with an easy apt-get purge of it. And yes, this is where I think wisdom is missing and the ability to accept constructive criticism is missing. Not all use cases are the same, its that simple. Its the attitude of knowing best for others without willing to accept feedback and discuss things that I am fed up with totally. If it doesn´t fit into my own agenda, I don´t care, go away. This kind of attitude is not likely to help in the long time. And I think its exactly this attitude that contributes *a lot* to the polarity around systemd. If people would get the impression that systemd upstream acts *sane* and in a *cooperative* way instead of *forcing* things I think there would be lot less resentment about it. One can have different oppinions about the tone on this mailing list at times, but so far I never found anyone so stubborn not even to let a feedback sink in before responding on a regular basis. But I think for systemd developers some kind of feedback ridicules their world view by an amount that they just iptable -j DROP it before even receiving it. They may still answer it, but also that sometimes to my perception without even having received the feedback first. That said, systemd in Debian works for me mostly, except some issues with mounting NFS at the workstation at work. But I will keep sysvinit-core installed for the time being. That all said: I believe that any feedback like this is best served on systemd-devel mailing list – maybe in an attempt to express it in a somewhat polite, yet also direct way. Instead of on LKML, debian-user, debian-devel and you name it what other mailinglists. Cause that would increase the chance of upstream noticing it. BTW I am still using KDE / Plasma and last I looked on GNOME (in Debian Wheezy) I just thought "Oh my god" and knowing that GNOME also insists on PulseAudio, I will continue with a desktop environment that leaves me choice. KDE developers invented Phonon for a reason. One reason is to be independent of any insanity going on in the lower layers of multimedia handling. Same thing with Solid. I think meanwhile they rely on systemd-logind, cause ConsoleKit is unmaintained, but at least they do not depend directly on it. I really hope this will stay this way and they continue to abstract all systemd use away so that in case systemd will not work out in the long term, they can adapt easily. For any account: Depending on a particular init system in a desktop environment is a *bug*. And no way of intelligent arguing around this is likely going to convince me of the opposite. Also I think: martin@merkaba:~> ls -l /sbin/init -rwxr-xr-x 1 root root 40648 Aug 3 21:01 /sbin/init martin@merkaba:~> ls -l /bin/systemd lrwxrwxrwx 1 root root 20
Re: OT: Open letter to the Linux World
Peter Zijlstra writes: > On Wed, Aug 13, 2014 at 10:24:58AM +0100, Måns Rullgård wrote: >> Beware, even Gentoo will pull in systemd, if in a dormant state, unless >> you are very careful. > > Right so I've not tried yet (busy see), but I meant to remove all the > *Kit and other nonsense from the USE flags. The safest way to avoid it by adding it to package.mask, then adjust USE flags until nothing conflicts. I do the same with dbus for good measure. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On Wed, Aug 13, 2014 at 10:24:58AM +0100, Måns Rullgård wrote: > Beware, even Gentoo will pull in systemd, if in a dormant state, unless > you are very careful. Right so I've not tried yet (busy see), but I meant to remove all the *Kit and other nonsense from the USE flags. I don't need GNOME so that shouldn't pull it in either. And from what I understood they have their own udev fork. And I suppose its OpenBSD to the rescue: http://www.openbsdfoundation.org/gsoc2014.html#systemd which is of course entirely ironic. pgpRb6mG60zqP.pgp Description: PGP signature
Re: OT: Open letter to the Linux World
Peter Zijlstra writes: > On Tue, Aug 12, 2014 at 11:07:05PM +0100, Måns Rullgård wrote: >> Steven Rostedt writes: >> >> > Nice rant, I sympathize with you (just complaining about this on G+). >> >> Made my day. >> >> > I'm just waiting for Linus to get pissed enough to write his own init >> > routine. Maybe he'll call it "Boot Init Through Computer Hardware". >> >> The trouble is that most of the heavy-weight kernel developers don't >> seem to care at all about what goes on in userspace. > > Well, I know for a fact that quite a number do; but so far most people > who care have been able to steer clear of this trainwreck so we did. > > I'm about to switch all my machines to Gentoo (from Debian) because that > will indeed allow you to build a distro without much of this nonsense > in -- because as has been eloquently said; you simply don't need this > fucking shite to run a 'normal' machine. Beware, even Gentoo will pull in systemd, if in a dormant state, unless you are very careful. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On Wed, Aug 13, 2014 at 10:27:56AM +0200, Peter Zijlstra wrote: > And the thing is; we're all very busy so we tend to take the 'easy' > way out for things like this; but wholesale switching all my machines > is indeed painful, and I'm not liking. Right, I think kernel people will gladly jump on a sane solution devoid of that kids-jerking-off-on-linux-desktop-just-for-the-fun-of-it situation if someone would present them with one. So, if someone would come up and do a sane init design without the jerking off, kernel people would jump on that in a heartbeat. Someone might even start getting patches from them too. ^^Hint^^ ^^hint^^. :-) -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On Tue, Aug 12, 2014 at 11:07:05PM +0100, Måns Rullgård wrote: > Steven Rostedt writes: > > > Nice rant, I sympathize with you (just complaining about this on G+). > > Made my day. > > > I'm just waiting for Linus to get pissed enough to write his own init > > routine. Maybe he'll call it "Boot Init Through Computer Hardware". > > The trouble is that most of the heavy-weight kernel developers don't > seem to care at all about what goes on in userspace. Well, I know for a fact that quite a number do; but so far most people who care have been able to steer clear of this trainwreck so we did. I'm about to switch all my machines to Gentoo (from Debian) because that will indeed allow you to build a distro without much of this nonsense in -- because as has been eloquently said; you simply don't need this fucking shite to run a 'normal' machine. And the thing is; we're all very busy so we tend to take the 'easy' way out for things like this; but wholesale switching all my machines is indeed painful, and I'm not liking. pgpKzOqpHWwhg.pgp Description: PGP signature
Re: OT: Open letter to the Linux World
On Tue, Aug 12, 2014 at 11:07:05PM +0100, Måns Rullgård wrote: Steven Rostedt rost...@goodmis.org writes: Nice rant, I sympathize with you (just complaining about this on G+). Made my day. I'm just waiting for Linus to get pissed enough to write his own init routine. Maybe he'll call it Boot Init Through Computer Hardware. The trouble is that most of the heavy-weight kernel developers don't seem to care at all about what goes on in userspace. Well, I know for a fact that quite a number do; but so far most people who care have been able to steer clear of this trainwreck so we did. I'm about to switch all my machines to Gentoo (from Debian) because that will indeed allow you to build a distro without much of this nonsense in -- because as has been eloquently said; you simply don't need this fucking shite to run a 'normal' machine. And the thing is; we're all very busy so we tend to take the 'easy' way out for things like this; but wholesale switching all my machines is indeed painful, and I'm not liking. pgpKzOqpHWwhg.pgp Description: PGP signature
Re: OT: Open letter to the Linux World
On Wed, Aug 13, 2014 at 10:27:56AM +0200, Peter Zijlstra wrote: And the thing is; we're all very busy so we tend to take the 'easy' way out for things like this; but wholesale switching all my machines is indeed painful, and I'm not liking. Right, I think kernel people will gladly jump on a sane solution devoid of that kids-jerking-off-on-linux-desktop-just-for-the-fun-of-it situation if someone would present them with one. So, if someone would come up and do a sane init design without the jerking off, kernel people would jump on that in a heartbeat. Someone might even start getting patches from them too. ^^Hint^^ ^^hint^^. :-) -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
Peter Zijlstra pet...@infradead.org writes: On Tue, Aug 12, 2014 at 11:07:05PM +0100, Måns Rullgård wrote: Steven Rostedt rost...@goodmis.org writes: Nice rant, I sympathize with you (just complaining about this on G+). Made my day. I'm just waiting for Linus to get pissed enough to write his own init routine. Maybe he'll call it Boot Init Through Computer Hardware. The trouble is that most of the heavy-weight kernel developers don't seem to care at all about what goes on in userspace. Well, I know for a fact that quite a number do; but so far most people who care have been able to steer clear of this trainwreck so we did. I'm about to switch all my machines to Gentoo (from Debian) because that will indeed allow you to build a distro without much of this nonsense in -- because as has been eloquently said; you simply don't need this fucking shite to run a 'normal' machine. Beware, even Gentoo will pull in systemd, if in a dormant state, unless you are very careful. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On Wed, Aug 13, 2014 at 10:24:58AM +0100, Måns Rullgård wrote: Beware, even Gentoo will pull in systemd, if in a dormant state, unless you are very careful. Right so I've not tried yet (busy see), but I meant to remove all the *Kit and other nonsense from the USE flags. I don't need GNOME so that shouldn't pull it in either. And from what I understood they have their own udev fork. And I suppose its OpenBSD to the rescue: http://www.openbsdfoundation.org/gsoc2014.html#systemd which is of course entirely ironic. pgpRb6mG60zqP.pgp Description: PGP signature
Re: OT: Open letter to the Linux World
Peter Zijlstra pet...@infradead.org writes: On Wed, Aug 13, 2014 at 10:24:58AM +0100, Måns Rullgård wrote: Beware, even Gentoo will pull in systemd, if in a dormant state, unless you are very careful. Right so I've not tried yet (busy see), but I meant to remove all the *Kit and other nonsense from the USE flags. The safest way to avoid it by adding it to package.mask, then adjust USE flags until nothing conflicts. I do the same with dbus for good measure. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
Am Mittwoch, 13. August 2014, 10:27:56 schrieb Peter Zijlstra: On Tue, Aug 12, 2014 at 11:07:05PM +0100, Måns Rullgård wrote: Steven Rostedt rost...@goodmis.org writes: Nice rant, I sympathize with you (just complaining about this on G+). Made my day. I'm just waiting for Linus to get pissed enough to write his own init routine. Maybe he'll call it Boot Init Through Computer Hardware. The trouble is that most of the heavy-weight kernel developers don't seem to care at all about what goes on in userspace. Well, I know for a fact that quite a number do; but so far most people who care have been able to steer clear of this trainwreck so we did. I'm about to switch all my machines to Gentoo (from Debian) because that will indeed allow you to build a distro without much of this nonsense in -- because as has been eloquently said; you simply don't need this fucking shite to run a 'normal' machine. And the thing is; we're all very busy so we tend to take the 'easy' way out for things like this; but wholesale switching all my machines is indeed painful, and I'm not liking. Just for record: Debian continues and will (for now and supposedly Jessie lifetime) continue to work without systemd as PID 1 using systemd-shim and cgmanager. And no: Debian didn´t make the choice easily or without discussion. I believe this to be the most controversial decision inside the Debian project and of the Tech CTTE in a decade or so, *after* tons over tons of discussion before. But one part of the decision is that Debian will continue to support other init systems at the moment. Its still being discussed in about all major Debian mailing lists up to now popping up every now and then. I am not completely opposed to quite some ideas within systemd, but what really upsets me most in this is the I know it better than you, go away! kind of attitude I also experienced with PulseAudio developers who just give a damn about my use case of wanting to start music playback on one X11 session and then switch to another session and *continue* to listen to that music. Just as one example where I ran into problems with PulseAudio I can just get rid of with an easy apt-get purge of it. And yes, this is where I think wisdom is missing and the ability to accept constructive criticism is missing. Not all use cases are the same, its that simple. Its the attitude of knowing best for others without willing to accept feedback and discuss things that I am fed up with totally. If it doesn´t fit into my own agenda, I don´t care, go away. This kind of attitude is not likely to help in the long time. And I think its exactly this attitude that contributes *a lot* to the polarity around systemd. If people would get the impression that systemd upstream acts *sane* and in a *cooperative* way instead of *forcing* things I think there would be lot less resentment about it. One can have different oppinions about the tone on this mailing list at times, but so far I never found anyone so stubborn not even to let a feedback sink in before responding on a regular basis. But I think for systemd developers some kind of feedback ridicules their world view by an amount that they just iptable -j DROP it before even receiving it. They may still answer it, but also that sometimes to my perception without even having received the feedback first. That said, systemd in Debian works for me mostly, except some issues with mounting NFS at the workstation at work. But I will keep sysvinit-core installed for the time being. That all said: I believe that any feedback like this is best served on systemd-devel mailing list – maybe in an attempt to express it in a somewhat polite, yet also direct way. Instead of on LKML, debian-user, debian-devel and you name it what other mailinglists. Cause that would increase the chance of upstream noticing it. BTW I am still using KDE / Plasma and last I looked on GNOME (in Debian Wheezy) I just thought Oh my god and knowing that GNOME also insists on PulseAudio, I will continue with a desktop environment that leaves me choice. KDE developers invented Phonon for a reason. One reason is to be independent of any insanity going on in the lower layers of multimedia handling. Same thing with Solid. I think meanwhile they rely on systemd-logind, cause ConsoleKit is unmaintained, but at least they do not depend directly on it. I really hope this will stay this way and they continue to abstract all systemd use away so that in case systemd will not work out in the long term, they can adapt easily. For any account: Depending on a particular init system in a desktop environment is a *bug*. And no way of intelligent arguing around this is likely going to convince me of the opposite. Also I think: martin@merkaba:~ ls -l /sbin/init -rwxr-xr-x 1 root root 40648 Aug 3 21:01 /sbin/init martin@merkaba:~ ls -l /bin/systemd lrwxrwxrwx 1 root root 20 Aug 6 13:41 /bin/systemd
Re: OT: Open letter to the Linux World
On Wed, Aug 13, 2014 at 11:37:28AM +0200, Martin Steigerwald wrote: That all said: I believe that any feedback like this is best served on systemd-devel mailing list – maybe in an attempt to express it in a somewhat polite, yet also direct way. Instead of on LKML, debian-user, debian-devel and you name it what other mailinglists. Cause that would increase the chance of upstream noticing it. I think most people have given up on talking to them entirely. I certainly have. And yes, its a popular subject for bitchin' about. And I realize that bitchin' won't fix thing at all, but we all need to vent our frustration somewhere. pgpkiF5q8jdNt.pgp Description: PGP signature
Re: OT: Open letter to the Linux World
On Wed, Aug 13, 2014 at 11:37:28AM +0200, Martin Steigerwald wrote: Also I think: martin@merkaba:~ ls -l /sbin/init -rwxr-xr-x 1 root root 40648 Aug 3 21:01 /sbin/init martin@merkaba:~ ls -l /bin/systemd lrwxrwxrwx 1 root root 20 Aug 6 13:41 /bin/systemd - /lib/systemd/systemd martin@merkaba:~ ls -l /lib/systemd/systemd -rwxr-xr-x 1 root root 1084816 Aug 6 13:42 /lib/systemd/systemd martin@merkaba:~ apt list 21 | egrep (^systemd/|sysvinit-core) systemd/unstable,now 208-7 amd64 [installed] sysvinit-core/unstable,now 2.88dsf-53.3 amd64 [installed,automatic] is highly worrying. A one MiB binary as PID 1? Really? Yeah, utterly insane. PID 1 should not be doing these things; no single process should do as much as systemd does, PID 1 least of all. pgpilTjsoP3LT.pgp Description: PGP signature
Re: OT: Open letter to the Linux World
Martin Steigerwald mar...@lichtvoll.de writes: Am Mittwoch, 13. August 2014, 10:27:56 schrieb Peter Zijlstra: On Tue, Aug 12, 2014 at 11:07:05PM +0100, Måns Rullgård wrote: Steven Rostedt rost...@goodmis.org writes: Nice rant, I sympathize with you (just complaining about this on G+). Made my day. I'm just waiting for Linus to get pissed enough to write his own init routine. Maybe he'll call it Boot Init Through Computer Hardware. The trouble is that most of the heavy-weight kernel developers don't seem to care at all about what goes on in userspace. Well, I know for a fact that quite a number do; but so far most people who care have been able to steer clear of this trainwreck so we did. I'm about to switch all my machines to Gentoo (from Debian) because that will indeed allow you to build a distro without much of this nonsense in -- because as has been eloquently said; you simply don't need this fucking shite to run a 'normal' machine. And the thing is; we're all very busy so we tend to take the 'easy' way out for things like this; but wholesale switching all my machines is indeed painful, and I'm not liking. Just for record: Debian continues and will (for now and supposedly Jessie lifetime) continue to work without systemd as PID 1 using systemd-shim and cgmanager. For now. Non-systemd configurations will receive little testing, if any. Once enough breakage accumulates, someone will issue an ultimatum for dropping such support entirely unless those who complain fix everything within an unreasonably short time. Obviously most things will remain broken, because those who opposed systemd are not package maintainers and have other jobs to do, and non-systemd support will be removed. I expect this to happen in unstable/testing within 18 months. That all said: I believe that any feedback like this is best served on systemd-devel mailing list – maybe in an attempt to express it in a somewhat polite, yet also direct way. Instead of on LKML, debian-user, debian-devel and you name it what other mailinglists. Cause that would increase the chance of upstream noticing it. This discussion is not aimed at systemd developers. We already know they don't give a hoot. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
Am Mittwoch, 13. August 2014, 11:52:13 schrieb Peter Zijlstra: On Wed, Aug 13, 2014 at 11:37:28AM +0200, Martin Steigerwald wrote: That all said: I believe that any feedback like this is best served on systemd-devel mailing list – maybe in an attempt to express it in a somewhat polite, yet also direct way. Instead of on LKML, debian-user, debian-devel and you name it what other mailinglists. Cause that would increase the chance of upstream noticing it. I think most people have given up on talking to them entirely. I certainly have. And yes, its a popular subject for bitchin' about. And I realize that bitchin' won't fix thing at all, but we all need to vent our frustration somewhere. I understand and symphatize with that. I have given up on giving feedback to PulseAudio upstream as well for now. I just try to avoid it, but now Skype required skype 4.3. I don´t use Skype at the moment, but I support a close family member who does, and well… I hope it will just work. Or its Google Hangout or at some point a free as in freedom *and* easy alternative I am not yet aware of. I read systemd-devel and I think there are quite sane discussions, but I believe if I bring up general feedback to systemd or question certain things about it… well… I feel reluctant about it at least. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: OT: Open letter to the Linux World
Am Mittwoch, 13. August 2014, 10:57:01 schrieb Måns Rullgård: Martin Steigerwald mar...@lichtvoll.de writes: Am Mittwoch, 13. August 2014, 10:27:56 schrieb Peter Zijlstra: On Tue, Aug 12, 2014 at 11:07:05PM +0100, Måns Rullgård wrote: Steven Rostedt rost...@goodmis.org writes: Nice rant, I sympathize with you (just complaining about this on G+). Made my day. I'm just waiting for Linus to get pissed enough to write his own init routine. Maybe he'll call it Boot Init Through Computer Hardware. The trouble is that most of the heavy-weight kernel developers don't seem to care at all about what goes on in userspace. Well, I know for a fact that quite a number do; but so far most people who care have been able to steer clear of this trainwreck so we did. I'm about to switch all my machines to Gentoo (from Debian) because that will indeed allow you to build a distro without much of this nonsense in -- because as has been eloquently said; you simply don't need this fucking shite to run a 'normal' machine. And the thing is; we're all very busy so we tend to take the 'easy' way out for things like this; but wholesale switching all my machines is indeed painful, and I'm not liking. Just for record: Debian continues and will (for now and supposedly Jessie lifetime) continue to work without systemd as PID 1 using systemd-shim and cgmanager. For now. Non-systemd configurations will receive little testing, if any. Once enough breakage accumulates, someone will issue an ultimatum for dropping such support entirely unless those who complain fix everything within an unreasonably short time. Obviously most things will remain broken, because those who opposed systemd are not package maintainers and have other jobs to do, and non-systemd support will be removed. I expect this to happen in unstable/testing within 18 months. I usually do not engage in predictions of the future, you know… my crystal ball has holidays. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
Hello, On Wed, Aug 13, 2014 at 3:27 AM, Peter Zijlstra pet...@infradead.org wrote: On Tue, Aug 12, 2014 at 11:07:05PM +0100, Måns Rullgård wrote: Steven Rostedt rost...@goodmis.org writes: Nice rant, I sympathize with you (just complaining about this on G+). Made my day. I'm just waiting for Linus to get pissed enough to write his own init routine. Maybe he'll call it Boot Init Through Computer Hardware. The trouble is that most of the heavy-weight kernel developers don't seem to care at all about what goes on in userspace. Well, I know for a fact that quite a number do; but so far most people who care have been able to steer clear of this trainwreck so we did. I'm about to switch all my machines to Gentoo (from Debian) because that will indeed allow you to build a distro without much of this nonsense in -- because as has been eloquently said; you simply don't need this fucking shite to run a 'normal' machine. And the thing is; we're all very busy so we tend to take the 'easy' way out for things like this; but wholesale switching all my machines is indeed painful, and I'm not liking. Another solution here which is more similar to Debian than Gentoo, is Alpine (http://www.alpinelinux.org). Alpine is a distribution which takes a lot of design cues from Debian (although we do use OpenRC). The typical user experience when using the alpine package management tools is easy for Debian users to understand, being modeled on the apt package manager. Another interesting detail is that we have adopted musl libc recently, and are working on glibc binary compatibility where it matters - the non-free flash player is already working here, and nvidia/fglrx are interesting targets as well. We feel that our usage of musl libc allows for improved security of the entire distribution, as musl's simplified implementation of standard library features has a much lower attack surface, and indeed a common observation is that many applications behave more robustly on Alpine (using musl) than other distributions they are developing against. At present, there are no plans to adopt systemd there, and systemd would need to be radically different than it is now to even be considered as the init system. The main blockers for systemd on Alpine are believed to be permanent: - systemd intentionally uses non-standard extensions to glibc - systemd components cannot be safely split up to reduce installation footprint - systemd has too much attack surface on PID 1 (d-bus, etc.) - kdbus support could be reasonably implemented without systemd - alpine does not wish to be 'forced' into adopting systemd through applications using systemd-exclusive APIs It should also be mentioned that Alpine is lightweight by default. This has been a goal that Debian in many ways has strayed from over the years. An empty LXC container with an alpine install in it, but no deployed applications, only takes approximately 3 megabytes of disc. Debian takes many orders of magnitude more now. William -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On 12/08/14 01:38 PM, Christopher Barry wrote: What is intelligence? Not exactly the spook kind, but rather what is the definition of intelligence in humans? This is pretty good: http://en.wikipedia.org/wiki/Intelligence#Definitions By most accounts, the self-appointed and arguably too influential creators and thinkers of the day around the 'One Linux' idea fit the definition of intelligent people - at least in the technical realm. And their messages are pretty compelling: * Simplify cross-distro development. * Enable faster boot times. * Enable an on-demand, event driven architecture, similar to 'Modern' Operating Systems. * Bring order and control to subsystems that have had as many different tools as there were distros. All seemingly noble goals. All apparently come from a deep desire to contribute and make things better. Almost anyone could argue that these intelligent people thought hard about these issues, and put an enormous amount of effort into a solution to these problems. Unfortunately, the solution they came up with, as you may have guessed by now, is 'systemd'. While not new, it's grotesque impact has finally reached me and I must speak to it publicly. So, what is systemd? Well, meet your new God. You may have been praying at the alter of simplicity, but your religion is being deprecated. It likely already happened without your knowledge during an upgrade of your Linux box. systemd is the all knowing, all controlling meta-deity that sees all and supervises all. It's the new One Master Process that aspires to control everything it can - and it's already doing a lot. It's what init would look like if it were a transformer on steroids. It's complicated, multi-faceted, opaque, and supremely powerful. I had heard about systemd a few years back, when upstart and some other init replacements I can't remember were showing up on the scene. And while it seemed mildly interesting, I was not in favor of using it, nor any of them for that matter. init was working just fine for me. init was simple and robust. While configuration had it's distro-specific differences, it was often these differences that made one pick the distro to use in the first place, and to stay with that distro. The tools essentially *were* the distro. I just dist-upgraded to Jessie, and voila - PID 1 was suddenly systemd. What a clusterfuck. You might want to send this to a mailing list that's remotely relevant, like perhaps a Debian one. Though I wouldn't expect a very productive response there either, since you neglected to include any reasons behind your rant other than they changed it, now it sucks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
Steven Rostedt writes: > Nice rant, I sympathize with you (just complaining about this on G+). Made my day. > I'm just waiting for Linus to get pissed enough to write his own init > routine. Maybe he'll call it "Boot Init Through Computer Hardware". The trouble is that most of the heavy-weight kernel developers don't seem to care at all about what goes on in userspace. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On Tue, Aug 12, 2014 at 04:21:29PM -0400, Steven Rostedt wrote: > > Nice rant, I sympathize with you (just complaining about this on G+). +1. Nicely written, Christopher. > I'm just waiting for Linus to get pissed enough to write his own init > routine. Maybe he'll call it "Boot Init Through Computer Hardware". Whatever it is, it will be sane and actually doing only what's needed to do. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
Nice rant, I sympathize with you (just complaining about this on G+). I'm just waiting for Linus to get pissed enough to write his own init routine. Maybe he'll call it "Boot Init Through Computer Hardware". Of course he'll have to make that an acronym. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
Nice rant, I sympathize with you (just complaining about this on G+). I'm just waiting for Linus to get pissed enough to write his own init routine. Maybe he'll call it Boot Init Through Computer Hardware. Of course he'll have to make that an acronym. -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On Tue, Aug 12, 2014 at 04:21:29PM -0400, Steven Rostedt wrote: Nice rant, I sympathize with you (just complaining about this on G+). +1. Nicely written, Christopher. I'm just waiting for Linus to get pissed enough to write his own init routine. Maybe he'll call it Boot Init Through Computer Hardware. Whatever it is, it will be sane and actually doing only what's needed to do. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
Steven Rostedt rost...@goodmis.org writes: Nice rant, I sympathize with you (just complaining about this on G+). Made my day. I'm just waiting for Linus to get pissed enough to write his own init routine. Maybe he'll call it Boot Init Through Computer Hardware. The trouble is that most of the heavy-weight kernel developers don't seem to care at all about what goes on in userspace. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
