Re: [DNG] We Must be Prepared ....
Le 24/06/2015 03:20, Jude Nelson a écrit : Looks like Linus weighed in. I found the whole conversation thread interesting. http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05492.html -Jude Thanks for this enjoyable link, Jude! Looks like the destination of the message is GKH : I trust you because, in fact, I expect you won't insist to merge crap. :-) If GKH decided to merge crap, he would leave immediately the list of trusted submaintainers. Some new IPC tools have been introduced in the Linux kernel these years and I know some people disaprove this trend. But, at least the ones I know of are rather good in my opinion because they move IPC towards the I/O system: signalfd and eventfd. If kdbus ends up merged in the kernel, I expect it'll be properly amended to be a useful general-purpose messaging facility. Nothing we should be afraid of. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
On Tue, Jun 23, 2015 at 09:20:37PM -0400, Jude Nelson wrote: Looks like Linus weighed in. I found the whole conversation thread interesting. http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05492.html Yes, it is definitely interesting. The most scary thing is the emergence in that thread same of the argument: ...we can't actually ship a kernel.org kernel that will fail to boot with Fedora Rawhide or Arch AUR or whatever unless kdbus=0 is set on the kernel command line., even in the form of a critic towards strict requirements imposed by systemd. This is what let me think that kdbus will most probably be merged into the kernel sometime soon, unless systemd developers unexpectedly decide to refrain from their insane way of pushing things forward, whatever the cost. But this is something is not going to happen, I am afraid. We probably can't do much more than hoping for the best, unfortunately... HND KatolaZ -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
On 24/06/15 21:33, KatolaZ wrote: On Tue, Jun 23, 2015 at 09:20:37PM -0400, Jude Nelson wrote: Looks like Linus weighed in. I found the whole conversation thread interesting. http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05492.html Yes, it is definitely interesting. The most scary thing is the emergence in that thread same of the argument: ...we can't actually ship a kernel.org kernel that will fail to boot with Fedora Rawhide or Arch AUR or whatever unless kdbus=0 is set on the kernel command line., even in the form of a critic towards strict requirements imposed by systemd. But that's been proven bunkum because systemd won't use kdbus if it's not there. It's Lennarts bluff. If distro's break, then it's their stupid fault for drinking at Lennarts fountain. This is what let me think that kdbus will most probably be merged into the kernel sometime soon, unless systemd developers unexpectedly decide to refrain from their insane way of pushing things forward, whatever the cost. But this is something is not going to happen, I am afraid. Linus will call Lennart's bluff on this and not ship kdbus until it's good and ready if that ever happens. I suspect that Linus's comments about trust in GKH is as much more a warning to GKH then a vote of confidence and certainly isn't a vote to pull in kdbus without review. It also serves to give the other kernel dev's a kick in the pants to do a proper review which will no doubt weed out the big issues. Linus won't knowingly let shit in his kernel not even for GKH. If GKH ask's again for a pull prematurely Linus will likely give him the same treatment as he gave Kay Sievers. In other words this is Linus's way of deflecting another flamewar and putting the focus on facts and code whilst putting a few people in their place. We won't see kdbus in 4.2 and probably not 4.3 either. By 4.4 it will most likely have grown some real legs and become generically useful or be a dead duck. -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
Looks like Linus weighed in. I found the whole conversation thread interesting. http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05492.html -Jude On Sat, Jun 20, 2015 at 5:28 PM, KatolaZ kato...@freaknet.org wrote: On Sat, Jun 20, 2015 at 08:15:01PM +0200, Didier Kryn wrote: [cut] I think a new generation of programmers has been comitted to maintain and evolve Linux. They have strong technical skills but haven't been taught well enough - or not at all - the philosohy of UNIX. They have fun with Linux; they love writing daemons and using the IPC toolbox and they happily write daemons to replace the security features provided by good old file-permissions. They just don't realize the damage they are causing. They are professionals and they don't care the DIY guy who isn't as skilled as them. Or...we are just blind cavemen, trying do keep alive a zombie that lives only in our memories and has evolved into something else, while we were busy flaming about the last flavours of Ubuntu? I just think it's not a matter of skill (unix has never ever been just a matter of skill), but rather a problem of bad attitude towards other peers, their work and their contributions. And good attitude towards peers is what has allowed the community around Linux to come along in these years. Without good attitude, what was once a community will slowly -but inexorably- become just a chit-chatty crowd, in which speaking louder than your peers would be far more important than having anything interesting to say at all. Well, I'd better stop here, and avoid the usual boring auntie's rant... HND KatolaZ -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
Le 20/06/2015 11:06, James Powell a écrit : Then this without a doubt is clear evidence that kdbus is in fact a systemd proprietary IPC. Has anyone heard of any software otherwise that will use kdbus at all, even in the least? Lennart is desperate to get kdbus in, but is making a critical error in judgment with this. No distribution has ever added software to the kernel that has been 3rd party via patch, or has limited function, other than Gentoo that maintains a patch for OpenRC. ZFSOnLinux has never been allowed, neither has Reiser4, or any other non-vanilla code, nor any code from Linux-next. No package developer in their right mind would do such a lascivious addition to the kernel, nor would dare to. OK, kdbus is required eagerly by systemd developpers. So what? Don't you think normal that such an important and critical thread of software development finds that it misses some service that only the kernel can provide efficiently? Isn't it normal that the kernel team examines seriously the request and eventualy provides that service? This kdbus feature, if we don't want to use it, we don't use it. It may even be optional and you can disable it when compiling the kernel if the mere availability of this system-call irritates you. It may also happen that other applications than systemd make use of kdbus for their own needs. From a bad thing (systemd) could hapen good things. For example, systemd-infected distros are now forced to include both sysvinit and systemd init files if they pretend to continue sysvinit support. They may consider some day doing what we are discussing in another thread: providing init packages for every daemon. Or devising a generic description of daemon dependencies and invocation method, which would allow to use universal start/stop/reload scripts. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
Le 20/06/2015 12:11, Martin Steigerwald a écrit : Am Freitag, 19. Juni 2015, 11:16:12 schrieb Jude Nelson: Whelp, looks like kdbus in systemd is no longer optional (but to be fair, its use can be disabled at runtime, and won't be used anyway if kdbus isn't present in the kernel). Announcement: http://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html Sorry, missed that as I wrote my post a minute ago. It is exactly this attitude and this approach that I feel uneasy about. Instead of humbly waiting and working towards having kdbus accepted to the kernel, systemd developers seem to use any means to create pressure to have it included eventually. So, IIUC, it's in systemd-build that kdbus is no longer compile-time optional*;*in kernel it's an optional module. I admit, though, that Poettering is putting high pressure to freedesktop and to the distros. But for now they can leave with their module and don't need the agreement of the kernel team. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
On Sat, Jun 20, 2015 at 02:06:26AM -0700, James Powell wrote: Then this without a doubt is clear evidence that kdbus is in fact a systemd proprietary IPC. Has anyone heard of any software otherwise that will use kdbus at all, even in the least? Lennart is desperate to get kdbus in, but is making a critical error in judgment with this. No distribution has ever added software to the kernel that has been 3rd party via patch, or has limited function, other than Gentoo that maintains a patch for OpenRC. ZFSOnLinux has never been allowed, neither has Reiser4, or any other non-vanilla code, nor any code from Linux-next. No package developer in their right mind would do such a lascivious addition to the kernel, nor would dare to. Yes, but no other software had ever managed to sweep sysvinit and invade all the existing distributions in less than two years, swallowing almost all the existing low-level OS services in a single hairball of code, before systemd arrived... Despite I trust kernel developers, I believe that the inclusion of kdbus in the kernel will be only a matter of time. I really hope I will be proven wrong this time, though. HND KatolaZ -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
Then this without a doubt is clear evidence that kdbus is in fact a systemd proprietary IPC. Has anyone heard of any software otherwise that will use kdbus at all, even in the least? Lennart is desperate to get kdbus in, but is making a critical error in judgment with this. No distribution has ever added software to the kernel that has been 3rd party via patch, or has limited function, other than Gentoo that maintains a patch for OpenRC. ZFSOnLinux has never been allowed, neither has Reiser4, or any other non-vanilla code, nor any code from Linux-next. No package developer in their right mind would do such a lascivious addition to the kernel, nor would dare to. Sent from my Windows Phone From: Arnt Gulbrandsenmailto:a...@gulbrandsen.priv.no Sent: 6/19/2015 10:23 AM To: dng@lists.dyne.orgmailto:dng@lists.dyne.org; Clarke Sideroadmailto:clarke.sider...@gmail.com Subject: Re: [DNG] We Must be Prepared It does not make the kernel systems, but its presence might make some poorly written program think systems is present. But poor code assumes things all the time, so really it will not make a difference. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
But kdbus hasn't proven itself in regular usage, except only by systemd. Where are the figures for kdbus with other D-Bus using software and services? I don't believe there are any, and if kdbus has been touted so much to be the perfect successor to D-Bus, why aren't other packages making headway to make their packages kdbus compliant to test the viability of kdbus? The one benefit we could get out of this are distributions waking up and saying no to including non-mainstream kernel code, and berating Lennart for wanting or requiring non-vanilla code. Most distributions only have traditionally included patches to fix known kernel issues, but anything else has been classed as forbidden. If anything Lennart may have put the metaphorical knife to the throat of systemd without realizing it. Sent from my Windows Phone From: Didier Krynmailto:k...@in2p3.fr Sent: 6/20/2015 2:49 AM To: dng@lists.dyne.orgmailto:dng@lists.dyne.org Subject: Re: [DNG] We Must be Prepared Le 20/06/2015 11:06, James Powell a écrit : Then this without a doubt is clear evidence that kdbus is in fact a systemd proprietary IPC. Has anyone heard of any software otherwise that will use kdbus at all, even in the least? Lennart is desperate to get kdbus in, but is making a critical error in judgment with this. No distribution has ever added software to the kernel that has been 3rd party via patch, or has limited function, other than Gentoo that maintains a patch for OpenRC. ZFSOnLinux has never been allowed, neither has Reiser4, or any other non-vanilla code, nor any code from Linux-next. No package developer in their right mind would do such a lascivious addition to the kernel, nor would dare to. OK, kdbus is required eagerly by systemd developpers. So what? Don't you think normal that such an important and critical thread of software development finds that it misses some service that only the kernel can provide efficiently? Isn't it normal that the kernel team examines seriously the request and eventualy provides that service? This kdbus feature, if we don't want to use it, we don't use it. It may even be optional and you can disable it when compiling the kernel if the mere availability of this system-call irritates you. It may also happen that other applications than systemd make use of kdbus for their own needs. From a bad thing (systemd) could hapen good things. For example, systemd-infected distros are now forced to include both sysvinit and systemd init files if they pretend to continue sysvinit support. They may consider some day doing what we are discussing in another thread: providing init packages for every daemon. Or devising a generic description of daemon dependencies and invocation method, which would allow to use universal start/stop/reload scripts. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
On Sat, Jun 20, 2015 at 12:11:12PM +0200, Martin Steigerwald wrote: Am Freitag, 19. Juni 2015, 11:16:12 schrieb Jude Nelson: Whelp, looks like kdbus in systemd is no longer optional (but to be fair, its use can be disabled at runtime, and won't be used anyway if kdbus isn't present in the kernel). Announcement: http://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html Sorry, missed that as I wrote my post a minute ago. It is exactly this attitude and this approach that I feel uneasy about. Instead of humbly waiting and working towards having kdbus accepted to the kernel, systemd developers seem to use any means to create pressure to have it included eventually. And you will see that they will have it included in the kernel, as they have had systemd accepted as the default init in any existing GNU/Linux distribution. I still have problems understanding why this is happening, and maybe a caveman like me will never get through it, but this is how things work in this community nowadays. And that's exactly why I have now also problems recognising this as *my* community HND KatolaZ -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
On Sat, Jun 20, 2015 at 12:07:59PM +0200, Martin Steigerwald wrote: Am Donnerstag, 18. Juni 2015, 12:29:57 schrieb Marlon Nunes: The job of keeping kernel development moving isn't so much about technical know-how these days, he said. Running the core of arguably the world's most important operating system is now about being trusted and being available. GREG (AKA GREG KROAH HARTMAN) IS THE OBVIOUS NUMBER TWO. HE COULD TAKE IT UP, and then there are a couple of other people. Linus Torvalds Guy, that's the guy who wants by all means, kdbus in the kernel. That's the systemd guy in the linux kernel community. http://www.theregister.co.uk/2015/06/17/now_i_can_die_happy_what_linus_did nt_iquitei_say/ In the light of * kdbus support is no longer compile-time optional. It is now always built-in. However, it can still be disabled at runtime using the kdbus=0 kernel command line setting, and that setting may be changed to default to off, by specifying --disable-kdbus at build-time. Note though that the kernel command line setting has no effect if the kdbus.ko kernel module is not installed, in which case kdbus is (obviously) also disabled. We encourage all downstream distributions to begin testing kdbus by adding it to the kernel images in the development distributions, and leaving kdbus support in systemd enabled. Lennart Poettering: [systemd-devel] [ANNOUNCE] systemd v221 http://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html I sure hope that kernel developers still review kdbus carefully and do not give in to any downstream pressure by distros. There is a precedent here (to the extend precedents have any relevance). Google requested kernel deatures for Android, and Linus refused. Only once Google changed the specs significantly were Googles changes admitted. I don't know what the Googles initial proposals were, or how they were changed (I hope they were in the direction of security and despecialization), but this does suggest that the kernel developers have some sense. There is still the question is whether Redhat has more influence by being a more traditional-looking Linux-based OS. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
On Sat, Jun 20, 2015 at 12:07:59PM +0200, Martin Steigerwald wrote: Am Donnerstag, 18. Juni 2015, 12:29:57 schrieb Marlon Nunes: The job of keeping kernel development moving isn't so much about technical know-how these days, he said. Running the core of arguably the world's most important operating system is now about being trusted and being available. GREG (AKA GREG KROAH HARTMAN) IS THE OBVIOUS NUMBER TWO. HE COULD TAKE IT UP, and then there are a couple of other people. Linus Torvalds Guy, that's the guy who wants by all means, kdbus in the kernel. That's the systemd guy in the linux kernel community. http://www.theregister.co.uk/2015/06/17/now_i_can_die_happy_what_linus_did nt_iquitei_say/ In the light of * kdbus support is no longer compile-time optional. It is now always built-in. However, it can still be disabled at runtime using the kdbus=0 kernel command line setting, and that setting may be changed to default to off, by specifying --disable-kdbus at build-time. Note though that the kernel command line setting has no effect if the kdbus.ko kernel module is not installed, in which case kdbus is (obviously) also disabled. We encourage all downstream distributions to begin testing kdbus by adding it to the kernel images in the development distributions, and leaving kdbus support in systemd enabled. Does this mean that kdbus support is not compiled into Poeterring's kernel? Is this effectively a kernel fork? -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
Clarke Sideroad writes: I hoping the Kernel Developers as a combined whole would see the bigger Linux picture well beyond the desktop. I can't see the Kernel being made to swallow something that would poison the whole multifaceted structure in the way that the various distros swallowed the, just another init, what's all the fuss about?, ever expanding systemd. Can you imagine the kernel supporting anything that is a problem for its biggest user? http://bit.ly/1ocxYwI Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
On 06/19/2015 02:59 AM, Arnt Gulbrandsen wrote: Clarke Sideroad writes: I hoping the Kernel Developers as a combined whole would see the bigger Linux picture well beyond the desktop. I can't see the Kernel being made to swallow something that would poison the whole multifaceted structure in the way that the various distros swallowed the, just another init, what's all the fuss about?, ever expanding systemd. Can you imagine the kernel supporting anything that is a problem for its biggest user? http://bit.ly/1ocxYwI Android initially just grabbed kernel and forked off. I suppose you are right the Kernel Developers did go through the hassle of luring Google back into the fold and the relationship gets positive press for both. In that light it does seem unlikely that they would forego all that, just to please the Poetterites. Clarke ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
On Thu, 18 Jun 2015, Jude Nelson wrote: The reason they're working on kdbus at all is because they have discovered that it's costly to pipe a lot of data between dbus endpoints reminds me of the time we had some momentum to have vloopback into Linux. or even before that, the times Geert Knorr put together video4linux 1 and then 2... at those times, Alan Cox wipped us hard in the multimedia camp, because of keeping bloat out of the kernel, despite those patches did have a relevant use in the industry... now I wonder, if Alan Cox and some other wise mentors Linux hasn't mentioned, will be reasonable allies against the systemd avalanche. I was from the we are young and we want innovation camp back at that time and can personally relate to the need of some kdbus features in the Linux kernel, but it must be seen how that is accomplished. The real problem in systemd is not the innovation that it brings, but the method, or attitude, of fencing off from competition by lacking documentation and intertwining all components. I think the Linux Foundation should institute a technical anti-trust commission to marshall such take-over attempts out of the kernel. I that would be in place, with a reasonable policy about documentation and versioning and changes being negotiated rather than imposed unilaterally, then most of my fears about systemd/Linux would vanish. ciao -- Denis Jaromil Roio, Dyne.org Think ( Do) Tank We are free to share code and we code to share freedom Web: https://j.dyne.org Contact: https://j.dyne.org/c.vcf GPG: 6113 D89C A825 C5CE DD02 C872 73B3 5DA5 4ACB 7D10 Confidential communications: https://keybase.io/jaromil signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
Whelp, looks like kdbus in systemd is no longer optional (but to be fair, its use can be disabled at runtime, and won't be used anyway if kdbus isn't present in the kernel). Announcement: http://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html -Jude On Fri, Jun 19, 2015 at 10:06 AM, Clarke Sideroad clarke.sider...@gmail.com wrote: On 06/19/2015 02:59 AM, Arnt Gulbrandsen wrote: Clarke Sideroad writes: I hoping the Kernel Developers as a combined whole would see the bigger Linux picture well beyond the desktop. I can't see the Kernel being made to swallow something that would poison the whole multifaceted structure in the way that the various distros swallowed the, just another init, what's all the fuss about?, ever expanding systemd. Can you imagine the kernel supporting anything that is a problem for its biggest user? http://bit.ly/1ocxYwI Android initially just grabbed kernel and forked off. I suppose you are right the Kernel Developers did go through the hassle of luring Google back into the fold and the relationship gets positive press for both. In that light it does seem unlikely that they would forego all that, just to please the Poetterites. Clarke ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
I'm not worried. Linus won't accept kdbus until he thinks it's in a position where it will be stable and easily supported for the foreseeable future. Watching kdbus get refactored a few times over this past year, I'd wager a guess that they're going to end up keeping as much of dbus in userspace as possible, and only add the parts that absolutely must run in kernel space to the kernel (as kdbus). Thus far, this has been limited to the memfd API, which is needed for zero-copy memory transfers. They'll probably also end up adding a specialized kdbusfs (akin to devpts) that offers namespaced and permissioned access to dbus endpoints, represented as a hierarchy of character device files. Remember, kdbus isn't dbus, anymore than a UNIX domain socket is dbus. The reason they're working on kdbus at all is because they have discovered that it's costly to pipe a lot of data between dbus endpoints, and it's hard to control capabilities, visibility, and access to them (since there are usecases where endpoints may not trust each other). Arguably, these problems can be addressed by using a combination of existing IPC mechanisms, but the argument that Greg KH and company put forth over and over again is that there's too much legacy code using dbus at this point (namely, from the IVI community and desktop communities) that we can't just tell them to refactor everything. It might be true--I don't know how big the IVI codebases are, for example. However, I don't really sympathize with the desktop communities--they built dbus to their specifications from their experiences with DCOP and Bonobo, and still managed to get it wrong. My $0.02. -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
Does seem to be true, that he is a systemd supporter: http://kroah.com/log/blog/2014/01/15/kdbus-details/ Anybody have a crystal ball? Will a kernel fork be required to not use systemd? On Thu, Jun 18, 2015 at 10:59 AM, Marlon Nunes nu...@openmailbox.org wrote: The job of keeping kernel development moving isn't so much about “technical know-how” these days, he said. Running the core of arguably the world's most important operating system is now about “being trusted and being available. *Greg (aka Greg Kroah Hartman) is the obvious number two. He could take it up*, and then there are a couple of other people.” Linus Torvalds Guy, that's the guy who wants by all means, kdbus in the kernel. That's the systemd guy in the linux kernel community. http://www.theregister.co.uk/2015/06/17/now_i_can_die_happy_what_linus_didnt_iquitei_say/ -- Stop slacking you lazy bum! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
The problem is, kdbus isn't just an IPC, it's proprietary to systemd, and is the only software capable of utilizing it. Greg Hartman as the lead-takeover for Linus? Hell no. He'd give it to Lennart and Kay without batting an eye, and then shut out every developer save their own. Dare I say it, but Peter Griffin or Homer Simpson would be better choices... If Hartman takes over, the kernel will have to be forked. His track record of kissing Lennart's ass is too obvious. No no and no. Sent from my Windows Phone From: Jude Nelsonmailto:jud...@gmail.com Sent: 6/18/2015 9:20 AM To: Richardmailto:richard.h...@gmail.com Cc: dng@lists.dyne.orgmailto:dng@lists.dyne.org Subject: Re: [DNG] We Must be Prepared I'm not worried. Linus won't accept kdbus until he thinks it's in a position where it will be stable and easily supported for the foreseeable future. Watching kdbus get refactored a few times over this past year, I'd wager a guess that they're going to end up keeping as much of dbus in userspace as possible, and only add the parts that absolutely must run in kernel space to the kernel (as kdbus). Thus far, this has been limited to the memfd API, which is needed for zero-copy memory transfers. They'll probably also end up adding a specialized kdbusfs (akin to devpts) that offers namespaced and permissioned access to dbus endpoints, represented as a hierarchy of character device files. Remember, kdbus isn't dbus, anymore than a UNIX domain socket is dbus. The reason they're working on kdbus at all is because they have discovered that it's costly to pipe a lot of data between dbus endpoints, and it's hard to control capabilities, visibility, and access to them (since there are usecases where endpoints may not trust each other). Arguably, these problems can be addressed by using a combination of existing IPC mechanisms, but the argument that Greg KH and company put forth over and over again is that there's too much legacy code using dbus at this point (namely, from the IVI community and desktop communities) that we can't just tell them to refactor everything. It might be true--I don't know how big the IVI codebases are, for example. However, I don't really sympathize with the desktop communities--they built dbus to their specifications from their experiences with DCOP and Bonobo, and still managed to get it wrong. My $0.02. -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
Richard writes: Will a kernel fork be required to not use systemd? Perhaps if Linus dies any time soon. But I think not even in that case — don't forget that android is the biggest linux distribution. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
I hoping the Kernel Developers as a combined whole would see the bigger Linux picture well beyond the desktop. I can't see the Kernel being made to swallow something that would poison the whole multifaceted structure in the way that the various distros swallowed the, just another init, what's all the fuss about?, ever expanding systemd. The other day I was watching Monty Python's Mr. Creosote sketch from The Meaning of Life movie and I came to realization that at some point the same fate will surely befall the systemd conglomeration. It is rapidly becoming the only thing an average Linux distro needs other than a desktop and the kernel and continues to swallow up tempting morsels left and right. I await the day that somebody gives the project a thin mint. In the meantime there still exists the parallel no-systemd universe, if it all goes to hell in a hand basket and it comes down to forking the Kernel, I think that would be the time to go to another restaurant entirely. Clarke ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] We Must be Prepared ....
On 2015-06-18 14:13, James Powell wrote: The problem is, kdbus isn't just an IPC, it's proprietary to systemd, and is the only software capable of utilizing it. Greg Hartman as the lead-takeover for Linus? Hell no. He'd give it to Lennart and Kay without batting an eye, and then shut out every developer save their own. Dare I say it, but Peter Griffin or Homer Simpson would be better choices... If Hartman takes over, the kernel will have to be forked. His track record of kissing Lennart's ass is too obvious. No no and no. Even linus called him a kay sievers babysitter ... - From: Jude Nelson Sent: 6/18/2015 9:20 AM To: Richard Cc: dng@lists.dyne.org Subject: Re: [DNG] We Must be Prepared I'm not worried. Linus won't accept kdbus until he thinks it's in a position where it will be stable and easily supported for the foreseeable future. Watching kdbus get refactored a few times over this past year, I'd wager a guess that they're going to end up keeping as much of dbus in userspace as possible, and only add the parts that absolutely must run in kernel space to the kernel (as kdbus). Thus far, this has been limited to the memfd API, which is needed for zero-copy memory transfers. They'll probably also end up adding a specialized kdbusfs (akin to devpts) that offers namespaced and permissioned access to dbus endpoints, represented as a hierarchy of character device files. Remember, kdbus isn't dbus, anymore than a UNIX domain socket is dbus. The reason they're working on kdbus at all is because they have discovered that it's costly to pipe a lot of data between dbus endpoints, and it's hard to control capabilities, visibility, and access to them (since there are usecases where endpoints may not trust each other). Arguably, these problems can be addressed by using a combination of existing IPC mechanisms, but the argument that Greg KH and company put forth over and over again is that there's too much legacy code using dbus at this point (namely, from the IVI community and desktop communities) that we can't just tell them to refactor everything. It might be true--I don't know how big the IVI codebases are, for example. However, I don't really sympathize with the desktop communities--they built dbus to their specifications from their experiences with DCOP and Bonobo, and still managed to get it wrong. My $0.02. -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng -- Stop slacking you lazy bum! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
