Re: Crowding out OpenBSD
"One could easily poke holes in this complaint; the characterization of PAM as "modern" is somewhat amusing; it is 1990s technology." Dafuk. If he's going to nitpick, then so am I. Marc did not say PAM was modern. He mentioned a modern Linux distro with pulseaudio, pam and systemd - to infer that he therefore considers PAM to be modern is a straw man argument at best. "in the early 1990s, BSD-oriented developers were equally unconcerned about the difficulty of porting their code to Linux." In the early 1990s, Linux was a dinky little toy, far from the ubiquitous platform it has become. The straw man rears its grassy head again. At least he recognises that a Linux monoculture would be just as damaging as the current arrangement. On Sat, Nov 17, 2012 at 7:57 PM, Andres Perera wrote: > On Sat, Nov 17, 2012 at 3:20 AM, Eric Furman wrote: >> You missed the point. >> This is a joke. >> Rod was making a joke by pointing out how F** retarded these people >> are. > > i'm going to pretend that you pointed out that cgroups prevent > double-forking from being a factor whereas pgroups do not > > this is a question of policy, not api: > > 1. if a program double-forks, that program has made it clear that it > does not need the destructors scripted in "systemd implementation", > and is eligible for being terminated by the generic, all-encompasing, > sysv killall(), linux killall5, or bsd kill(-1) at the end of > shutdown. this conclusion is drawn by the fact that the program can > negate scripted destructors ANYWAY under cgroups by way of being > unrestricted in its set of system calls (which is a concern OUTSIDE > "systemd implementation", therefore the role of a more generic > utility), or by plain bat shit insane userland code. there's no > sandbox being added by cgroups here > > 2. if a program double-forks, security is not compromised because the > permissions of that program are completely orthogonal to control via > "systemd implementation". the admin's *policy* is that there's always > an interest in running certain daemons as certain users. that "systemd > implementation" can also map processes to users is coincidental > > therefore the requirement for cgroups is completely arbitrary > > also of interest: > > * early versions of systemd documentation advised daemon authors not > to double fork. presumably cgroups wasn't in the radar at the time > > * several (all?) openbsd daemons have options for not double-forking. > some of these daemons have the gall of preceding systemd > >> >> On Sat, Nov 17, 2012, at 02:21 AM, Andres Perera wrote: >>> On Sat, Nov 17, 2012 at 1:55 AM, Rod Whitworth >>> wrote: >>> > On Fri, 16 Nov 2012 20:49:37 -0600, Amit Kulkarni wrote: >>> > >>> >>https://lwn.net/Articles/524606/ >>> >> >>> >>don't have a subscription but for those who do, enjoy. >>> >> >>> > >>> > But http://lwn.net/Articles/524920/ will give you the idea without $$$ >>> >>> "rleigh, it's really not as easy as you think. Making the event loop >>> portable to kqueue is complex, but doable, I can agree to that. -- But >>> the trouble starts beyond that. The BSDs don't have anything like >>> cgroups. *There's no way to attach a name to a group of processes, in >>> a hierarchal, secure way*. And you cannot emulate this. (And no, don't >>> say "BSD jail" now, because that is something very different). But >>> this already is at the very core of systemd. It's how systemd tracks >>> services." >>> >>> how can someone write this and not explain why a process managing >>> pgroups can't achieve the same results? >>> >>> pgroups is going to be the first alternative for someone instinctively >>> looking for a portable alternative, so i'm genuinely interested in >>> knowing why they've discarded the idea >>> >>> i am, however, aware of differences *unrelated* to writing a systemd >>> like appliance. pgroups do not provide per item hostname and other >>> virtualization facilities in freebsd jails/linux cgroups, but what >>> about *relevant* differences? something weak like "the index for for >>> cgroups is wide enough to fit an UUID"? in other words, something that >>> *doesn't* require a completely new api? > -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
Re: Crowding out OpenBSD
You missed the point. This is a joke. Rod was making a joke by pointing out how F** retarded these people are. On Sat, Nov 17, 2012, at 02:21 AM, Andres Perera wrote: > On Sat, Nov 17, 2012 at 1:55 AM, Rod Whitworth > wrote: > > On Fri, 16 Nov 2012 20:49:37 -0600, Amit Kulkarni wrote: > > > >>https://lwn.net/Articles/524606/ > >> > >>don't have a subscription but for those who do, enjoy. > >> > > > > But http://lwn.net/Articles/524920/ will give you the idea without $$$ > > "rleigh, it's really not as easy as you think. Making the event loop > portable to kqueue is complex, but doable, I can agree to that. -- But > the trouble starts beyond that. The BSDs don't have anything like > cgroups. *There's no way to attach a name to a group of processes, in > a hierarchal, secure way*. And you cannot emulate this. (And no, don't > say "BSD jail" now, because that is something very different). But > this already is at the very core of systemd. It's how systemd tracks > services." > > how can someone write this and not explain why a process managing > pgroups can't achieve the same results? > > pgroups is going to be the first alternative for someone instinctively > looking for a portable alternative, so i'm genuinely interested in > knowing why they've discarded the idea > > i am, however, aware of differences *unrelated* to writing a systemd > like appliance. pgroups do not provide per item hostname and other > virtualization facilities in freebsd jails/linux cgroups, but what > about *relevant* differences? something weak like "the index for for > cgroups is wide enough to fit an UUID"? in other words, something that > *doesn't* require a completely new api?
Re: Crowding out OpenBSD
On Sat, Nov 17, 2012 at 3:20 AM, Eric Furman wrote: > You missed the point. > This is a joke. > Rod was making a joke by pointing out how F** retarded these people > are. i'm going to pretend that you pointed out that cgroups prevent double-forking from being a factor whereas pgroups do not this is a question of policy, not api: 1. if a program double-forks, that program has made it clear that it does not need the destructors scripted in "systemd implementation", and is eligible for being terminated by the generic, all-encompasing, sysv killall(), linux killall5, or bsd kill(-1) at the end of shutdown. this conclusion is drawn by the fact that the program can negate scripted destructors ANYWAY under cgroups by way of being unrestricted in its set of system calls (which is a concern OUTSIDE "systemd implementation", therefore the role of a more generic utility), or by plain bat shit insane userland code. there's no sandbox being added by cgroups here 2. if a program double-forks, security is not compromised because the permissions of that program are completely orthogonal to control via "systemd implementation". the admin's *policy* is that there's always an interest in running certain daemons as certain users. that "systemd implementation" can also map processes to users is coincidental therefore the requirement for cgroups is completely arbitrary also of interest: * early versions of systemd documentation advised daemon authors not to double fork. presumably cgroups wasn't in the radar at the time * several (all?) openbsd daemons have options for not double-forking. some of these daemons have the gall of preceding systemd > > On Sat, Nov 17, 2012, at 02:21 AM, Andres Perera wrote: >> On Sat, Nov 17, 2012 at 1:55 AM, Rod Whitworth >> wrote: >> > On Fri, 16 Nov 2012 20:49:37 -0600, Amit Kulkarni wrote: >> > >> >>https://lwn.net/Articles/524606/ >> >> >> >>don't have a subscription but for those who do, enjoy. >> >> >> > >> > But http://lwn.net/Articles/524920/ will give you the idea without $$$ >> >> "rleigh, it's really not as easy as you think. Making the event loop >> portable to kqueue is complex, but doable, I can agree to that. -- But >> the trouble starts beyond that. The BSDs don't have anything like >> cgroups. *There's no way to attach a name to a group of processes, in >> a hierarchal, secure way*. And you cannot emulate this. (And no, don't >> say "BSD jail" now, because that is something very different). But >> this already is at the very core of systemd. It's how systemd tracks >> services." >> >> how can someone write this and not explain why a process managing >> pgroups can't achieve the same results? >> >> pgroups is going to be the first alternative for someone instinctively >> looking for a portable alternative, so i'm genuinely interested in >> knowing why they've discarded the idea >> >> i am, however, aware of differences *unrelated* to writing a systemd >> like appliance. pgroups do not provide per item hostname and other >> virtualization facilities in freebsd jails/linux cgroups, but what >> about *relevant* differences? something weak like "the index for for >> cgroups is wide enough to fit an UUID"? in other words, something that >> *doesn't* require a completely new api?
Re: Crowding out OpenBSD
On Nov 17, 2012, at 3:49 AM, Amit Kulkarni wrote: > https://lwn.net/Articles/524606/ > > don't have a subscription but for those who do, enjoy. I like Jonathan's work, but this article is ill-conceived. He picks up on Marc's upstream vendor remarks, then turns this into an issue of BSD does not have the strength to keep up with the (Linux) world we live in and that BSD might eventually be phased out due to: * lack of contemporary desktop support * lack of hardware support * lack of mobile goodies * lack of developers While it's easy to focus on the dark side of things, that's not the full picture. The whole GPL idea looks like it's getting into serious trouble in the coming years (see NVIDIA vs. DMA-BUF or Red Hat's recent SCSI target code mockery), with BSD being the more competitive license for business owners, who will NOT hesitate to ditch Linux given the chance. And GPL benefiting from BSD but not the other way around is childish at best. Upstream vendors will want to see their product not reach a dead end, which is, to be totally frank, part of the process. If GNOME doesn't make it because of their strategy, then that's a great day for desktops. And if they succeed, then everybody else will cope some way or another. On the upside, the comments to the article are surprisingly good, with lots of ideas and questions on how to not let the community as a whole fall apart. If anyone is interested in the full article, here you go: http://lwn.net/SubscriberLink/524606/611b3cb2f33e32ae/ Franco
Re: Crowding out OpenBSD
On Sat, Nov 17, 2012 at 1:55 AM, Rod Whitworth wrote: > On Fri, 16 Nov 2012 20:49:37 -0600, Amit Kulkarni wrote: > >>https://lwn.net/Articles/524606/ >> >>don't have a subscription but for those who do, enjoy. >> > > But http://lwn.net/Articles/524920/ will give you the idea without $$$ "rleigh, it's really not as easy as you think. Making the event loop portable to kqueue is complex, but doable, I can agree to that. -- But the trouble starts beyond that. The BSDs don't have anything like cgroups. *There's no way to attach a name to a group of processes, in a hierarchal, secure way*. And you cannot emulate this. (And no, don't say "BSD jail" now, because that is something very different). But this already is at the very core of systemd. It's how systemd tracks services." how can someone write this and not explain why a process managing pgroups can't achieve the same results? pgroups is going to be the first alternative for someone instinctively looking for a portable alternative, so i'm genuinely interested in knowing why they've discarded the idea i am, however, aware of differences *unrelated* to writing a systemd like appliance. pgroups do not provide per item hostname and other virtualization facilities in freebsd jails/linux cgroups, but what about *relevant* differences? something weak like "the index for for cgroups is wide enough to fit an UUID"? in other words, something that *doesn't* require a completely new api?
Re: Crowding out OpenBSD
On Fri, 16 Nov 2012 20:49:37 -0600, Amit Kulkarni wrote: >https://lwn.net/Articles/524606/ > >don't have a subscription but for those who do, enjoy. > But http://lwn.net/Articles/524920/ will give you the idea without $$$ R/ *** NOTE *** Please DO NOT CC me. I subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
