Re: [Dng] Combatting revisionist history
В Thu, 26 Feb 2015 07:25:16 + KatolaZ kato...@freaknet.org пишет: I personally think that the essence of that nice post is in the very last quote: Those who don't understand Unix are condemned to reinvent it, poorly. I've another story, same way: Whenever people did invent good (here comes its criterias) OS -- they always got UNIX. :o) Sthu. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Combatting revisionist history
Le 25/02/2015 22:11, Go Linux a écrit : This excellent analysis of the systemd debacle was just posted over on FDN. Should be required reading IMO. Enjoy! http://forums.debian.net/viewtopic.php?f=20t=120652p=570371 golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng Thanks Go Linux for this post. I didn't follow thhe battle inside Debian; therefore it's interesting to read a point of view on the story. I like the jokes about the Fork posted in the replies. I see Devuan on the clear side of the Fork. About init in general, and first of all about systemd, I always thought there was an abuse in the terminology and in the implementation, which I would like to explain below: Well, there are two pecularities in process #1: a) it is the first process started by the kernel, and, as such, it is in charge of starting all the necessary services. b) it adopts the orphans These two things are very different and I am amazed that one can call init the process in charge to adopt the orphans and eventually re-launch them, and moreover shut down the system. Init proper, when it has finished starting the system, should exec() another application, in charge of maintaining it alive; and this other should exec() yet another one for shutdown. There is no reason to put all these delicate jobs in only one application. exec() does not change the pid. The Fork be with Devuan, yeah! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Combatting revisionist history
[Sorry Gravis, I could find no shorter way to say this] On Wed, 25 Feb 2015 15:49:34 -0600 T.J. Duchene t.j.duch...@gmail.com wrote: On Wed, 2015-02-25 at 13:11 -0800, Go Linux wrote: This excellent analysis of the systemd debacle was just posted over on FDN. Should be required reading IMO. Enjoy! http://forums.debian.net/viewtopic.php?f=20t=120652p=570371 golinux I must respectfully disagree. I find the analysis to be very biased toward one side of the discussion, And the author tells us that. Now I'd like you to admit that you're very biased toward the other side of the discussion. I'm proud to say that I'm biased in the same direction as the author. So is the vast majority of this mailing list, whose project was created in order to choose one's init system without trashing the entire OS. as well as creating their own definitions to fit their side. If something replaces init, it is by definition an init system. So then, if I replace your car's radio by replacing the whole car, it is by definition a car radio? Whether it does more or less than the previous init is immaterial to that simple fact. I find no credible element of truth in the preceding sentence. But anyway, disregarding the definition of init system, the author is dead bang right on: * Debian isn't other distros * no one—has ever articulated a value proposition for systemd that adequately addresses its implementation costs. About Debian isn't other distros, he characterized the situation exactly right, plus the fact that when Debian moved, all the Debian descendents moved with it (except a couple that were born to exclude systemd, like DNG). And, his assertion was even more right back in September, when many of the brains behind DNG were helping out with Debian. About value proposition vs cost: 90% of the value ennunciated by systemd fans boil down to it boots faster, because any benefit achieved by socket activation and the like could be simulated by strategically placed sleep statements in any other init. And keep in mind that if boot speed and reliability are truly important to one, one would be unlikely to start the number and type of services that would be problematic to boot speed. AND, although I've gotten systemd to boot in 4 seconds on a spinning platter, it took 30 seconds after that to get into the Desktop Environment, because a lot of boot tasks including networking happened in the desktop environment. AND, I got Epoch to boot in 7 seconds, and runit to boot in 11 seconds, on the same hardware, and they both took less time to get to the GUI. The other 8% have to do with making the GUI responsive to changes in the system, and vice versa. Nice, but not essential, and not worth a 15 major component monolith tied together with thick, not well documented interfaces. Not only that, but there are plenty of other ways to get that feature without gumming up the system by eliminating advantages of interchangeable parts. That leaves the 2% benefit of cgroups, whose benefit boils down to, when all the bullfeathers are removed, reaping zombies. Zombies were an irritation to all of us, but we've lived with them for 15 years, and their removal certainly doesn't justify a software V'ger. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Combatting revisionist history
On Wed, 25 Feb 2015 17:05:44 -0500 Neo Futur d...@ww7.be wrote: If I had to point the finger at Linux's greatest failing, it is the expectation that users want others to do all of the work compiling and packaging and then they want to complain that that someone else made a choice that they didn't like. well i wont say that as a gentoo user ;) I'd like to take a crack at this. If somebody builds me a house to live in, I have no business criticizing the house. I can move in or not. Contrast the preceding with this: Somebody built me the house, and I moved in. I like the house. Several years later, a group partially comprised of the same group that built the house reduce the roof's slope to the point where rain blows under the shingles and leaks all over my possessions. I'm definitely going to tell them don't break my house! I'm going to yell don't break my house very loudly. And if they continue to, because they can, I'll either find ways, that they can't touch, to waterproof the house (runit, Epoch, wpa_supplicant), or move to a house they can't touch (DNG). Instructing them how to build the house is pure, lazy ingratitude. Telling them not to break what already is built is a good thing. If they want to destroy things, they shouldn't call it work. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Combatting revisionist history
That leaves the 2% benefit of cgroups, whose benefit boils down to, when all the bullfeathers are removed, reaping zombies. Zombies were an irritation to all of us, but we've lived with them for 15 years, and their removal certainly doesn't justify a software V'ger. there is a bit more to cgroups than that but there is no reason another init manager can't perform the same task without becoming The Blob. --Gravis On Wed, Feb 25, 2015 at 5:17 PM, Steve Litt sl...@troubleshooters.com wrote: [Sorry Gravis, I could find no shorter way to say this] On Wed, 25 Feb 2015 15:49:34 -0600 T.J. Duchene t.j.duch...@gmail.com wrote: On Wed, 2015-02-25 at 13:11 -0800, Go Linux wrote: This excellent analysis of the systemd debacle was just posted over on FDN. Should be required reading IMO. Enjoy! http://forums.debian.net/viewtopic.php?f=20t=120652p=570371 golinux I must respectfully disagree. I find the analysis to be very biased toward one side of the discussion, And the author tells us that. Now I'd like you to admit that you're very biased toward the other side of the discussion. I'm proud to say that I'm biased in the same direction as the author. So is the vast majority of this mailing list, whose project was created in order to choose one's init system without trashing the entire OS. as well as creating their own definitions to fit their side. If something replaces init, it is by definition an init system. So then, if I replace your car's radio by replacing the whole car, it is by definition a car radio? Whether it does more or less than the previous init is immaterial to that simple fact. I find no credible element of truth in the preceding sentence. But anyway, disregarding the definition of init system, the author is dead bang right on: * Debian isn't other distros * no one—has ever articulated a value proposition for systemd that adequately addresses its implementation costs. About Debian isn't other distros, he characterized the situation exactly right, plus the fact that when Debian moved, all the Debian descendents moved with it (except a couple that were born to exclude systemd, like DNG). And, his assertion was even more right back in September, when many of the brains behind DNG were helping out with Debian. About value proposition vs cost: 90% of the value ennunciated by systemd fans boil down to it boots faster, because any benefit achieved by socket activation and the like could be simulated by strategically placed sleep statements in any other init. And keep in mind that if boot speed and reliability are truly important to one, one would be unlikely to start the number and type of services that would be problematic to boot speed. AND, although I've gotten systemd to boot in 4 seconds on a spinning platter, it took 30 seconds after that to get into the Desktop Environment, because a lot of boot tasks including networking happened in the desktop environment. AND, I got Epoch to boot in 7 seconds, and runit to boot in 11 seconds, on the same hardware, and they both took less time to get to the GUI. The other 8% have to do with making the GUI responsive to changes in the system, and vice versa. Nice, but not essential, and not worth a 15 major component monolith tied together with thick, not well documented interfaces. Not only that, but there are plenty of other ways to get that feature without gumming up the system by eliminating advantages of interchangeable parts. That leaves the 2% benefit of cgroups, whose benefit boils down to, when all the bullfeathers are removed, reaping zombies. Zombies were an irritation to all of us, but we've lived with them for 15 years, and their removal certainly doesn't justify a software V'ger. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance ___ 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] Combatting revisionist history
On Wed, Feb 25, 2015 at 01:11:09PM -0800, Go Linux wrote: This excellent analysis of the systemd debacle was just posted over on FDN. Should be required reading IMO. Enjoy! http://forums.debian.net/viewtopic.php?f=20t=120652p=570371 I personally think that the essence of that nice post is in the very last quote: Those who don't understand Unix are condemned to reinvent it, poorly. The rest is just history, and as always happens to history it is and will be manipulated, rearranged, edulcorated, simmered and served in several possible fashions, styles and shapes, according to the taste of the narrator. My major regret is that in the end the immense decisional infrastructure of Debian, which I respected for years as an example of bottom-up democracy, was not able to *decide* on such a delicate and fundamental issue, which in fact was not just technical but phylosophical (and if you call the result of the GR a decision then we have very different views about what deciding means). My2Cents 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