Re: [DNG] Technical overview of init systems
On Fri, 11 Aug 2017 07:43:42 +0200 Didier Kryn wrote: > I thing you're taking me wrong. I don't claim I know the matter > better that the author. He studied all these supervisors in some > detail; I didn't. I just say he failed to explain things in an > educative way - and it seems to me doesn't consider it worth. > > Didier Yes. I think the word for that is "cursory." He explained it all in a cursory manner. Which is fine: The world leds some high level docs. I just don't like the elevation of cgroups from init curiosities to wants. As someone said in this thread, given the way he writes, he's been influenced by some systemd types. SteveT Steve Litt July 2017 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Technical overview of init systems
Le 10/08/2017 à 16:22, Jamey Fletcher a écrit : Le 09/08/2017 à 22:46, Joel Roth a écrit : Despite what the author claims, this series of pages isn't about init. It is mostly about supervision and a little about containers. It assumes both are usefull, with no argumentation to motivate supervision. Confusion about init, supervision, and containers typically suggests that the author has been contaminated by systemd propaganda. Also I don't like the style of this series of explanations; there is little content within a lot of decoration and structure. Clearly the author has tried all these supervisors but his explanations could be more detailed. And the answer is... Take what he's written, add in your thoughts, more clearly specify the differences between inits, supervisors, hypervisors, and containers, and write up your own explanation. One thing I might suggest, since you think his explanations could be more detailed, is do a short explanation for each section, kind of an executive summary, and then add in a section closed up initially for more detail for those who need it. I thing you're taking me wrong. I don't claim I know the matter better that the author. He studied all these supervisors in some detail; I didn't. I just say he failed to explain things in an educative way - and it seems to me doesn't consider it worth. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Technical overview of init systems
Jaromil - 09.08.17, 09:16: > On Tue, 08 Aug 2017, Martin Steigerwald wrote: > > Adam Borowski - 08.08.17, 18:57: > > > On Tue, Aug 08, 2017 at 11:53:56AM -0400, Steve Litt wrote: > > > > Be careful recommending cgroups. > > > > > > > > I've never used them, and know little about them, but I know they were > > > > one of the main excuses for systemd. > > > > > > Uhm, what? Systemd uses ELF objects too, should we go with a.out for > > > this > > > reason? > > > > > > cgroups are a way to say "this group of processes may not use more than > > > 2GB > > > memory". How else would you ensure a misbehaving set of daemons / > > > container /etc does not bring down the rest of the system with it? > > > > I agree that cgroups can be a useful feature. Yet… also a bit clumsy to > > use, and not free of race conditions. That written, kernel developers are > > working to fix part of the clumsyness and completely and all of the race > > conditions by unifying all cgroup controllers (memory, cpu and so on) in > > one directory tree. > is the sourcecode of systemd the *only* example implementation of an > INIT 1 daemon using cgroups right now? > > here I see a lot of Go code > https://github.com/search?utf8=%E2%9C%93&q=cgroups&type= > > so why systemd is considered to be the only supervisor implementation > supporting cgroups? because all the rest are just libraries? > > I'm a bit confused and very curious I have no idea. I was only aware of systemd using cgroups so far. Well except… cgmanager… which runs separately from PID 1 and supports managing processes / containers in cgroups on SysVInit (or other non cgroup based) init systems. And… well… some low latency daemon written in Lua I don´t remember… well I found it with apt-cache search: ulatencyd - scriptable latency regulator using cgroups (server) Last version packaged in Debian is from march 2014 tough. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Shepherd
Hello. Anyone knowing more about GNU (Daemon) Shepherd?¹ I was completely unaware of this service manager which is based on dmd. I think I read about dmd some long time ago tough. GuixSD (Guixid System Distribution) uses it and it is planned to use it for GNU/Hurd as well. I am a bit vary about the choice of language it is implemented in (the Lisp like Guile), but if it works… I don´t really mind. [1] https://www.gnu.org/software/shepherd/ Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Technical overview of init systems
T On Wed, 9 Aug 2017 10:46:31 -1000 Joel Roth wrote: > > Edward Bartolo wrote: > > Using this 'resource' will do a disservice to Devuan. Anyone serious > > enough to read it will get the wrong impression that Devuan is some > > 'amateur' distribution not worthy of wasting professional hours on > > it. Scientific and technical text must at all costs avoid > > opinionated writing but this resource does the opposite. As said > > earlier, there is no objective comparism between the different > > inits. > Edward, > > I think that any articles that interest people in > exploring this part of their Linux systems can only > be good. True, but before promoting this bare outline resource, people should be referred to resources such as my Manjaro Experiments, Rich Felker's ewontfix.com/14 and ewontfix.com/15, http://thedjbway.b0llix.net/daemontools.html, http://troubleshooters.com/linux/diy/suckless_init_on_plop.htm, and if I had time probably 30 other excellent articles that give a clearer definition of what most people mean by a "supervisor", and more generally accurate priorities in init system composition. SteveT ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Technical overview of init systems
On Thu, 10 Aug 2017 09:22:38 -0500 "Jamey Fletcher" wrote: > Take what he's written, add in your thoughts, more clearly specify the > differences between inits, supervisors, hypervisors, and containers, > and write up your own explanation. This will probably fail due to a lack of agreed upon definitions. I'll discuss just inits and supervisors here. There are folks who say if it's not part of PID1, it's not part of the init system. That means that runit's rc files and process supervisor aren't part of the init system. But on very similar s6, where the supervisor *is* part of PID1, the whole thing is an init. And what about OpenRC, which has no PID1 at all but must borrow one from somewhere else, typically from sysvinit? Is OpenRC not an init system? As far as the word supervisor, Laurent Bercot is working very hard to keep a pure definition. I'm not sure I agree with all elements of his definition, but could live with it if he would write very tight definitions for both "process supervisor", "supervisor" if any different, and "process manager". We'd then have to correct the millions using different terminology. We see this definition mess all the time when people talk about "window managers" and "desktop environments". That's a distinction that never should have been made. I suggest everyone read and do their best to understand https://skarnet.org/software/s6/s6-svscan-1.html. This page does a great job of defining and explaining the three stages of the initialization process, and if you read carefully, it explains that there's not necessarily a relationship between stage and PID. In runit, stage1 is done in PID1, but a fork to an rc file culminating in runsvdir does all the stage2 work, while PID1 continues to check for zombies. In s6, PID1 does the first part of stage1, then the rest of stage1 is forked, and then supervisor s6-svscan is execed into PID1, and s6-svscan not only supervises, but also checks for zombies. I'm a little confused on stage3, shutdown. When I've built my own init systems, I've always had stage3 just be a shellscript to shut everything down. Sometimes I shut down by manually running the shellscript, rather than sending a signal. Crude, but effective. https://skarnet.org/software/s6/s6-svscan-1.html has an excellent bullet list on the four things a stage3 must do. https://skarnet.org/software/s6/s6-svscan-1.html is one of a few documents I read before beginning the Manjaro Experiments, along with such classics as ewontfix.com/14 and the Daemontools documentation. It helped me immensely, and I highly recommend it. SteveT Steve Litt July 2017 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Just out of curiosity, I wondered,
For some reason I can connect to the internet now, dunno what's different... but thank you all for your instructions. :) On 08/10/2017 03:37 AM, Narcis Garcia wrote: > Someone asked for an easy question, and I tried to reply with an > effective answer (without perfection). > I hope "zap/calmstorm" has already launched any GNU/Linux .iso with > that, because hasn't asked more details. > > > El 10/08/17 a les 08:42, Simon Hobson ha escrit: >> Adam Borowski wrote: >> >>> rtl8139 is a 100Mbit card, you really don't want your virtual network speed >>> hobbled by emulating such gear. >> It doesn't work like that. The nominal speed of the card is merely that of >> the real card being emulated - in the emulated version, there's no serial >> pipe to get the bits through (just in-memory copies/moves) and the actual >> throughput will be whatever the chain of bits can push through it. That's >> certainly the case with Xen which (AIUI) uses Qemu for the I/O stuff. >> >> >> Having said that, people bitten by "cr*p hardware or drivers" tend to have >> long memories - Realtek is a make I prefer to avoid. Now, Intel e1000 is a >> different matter. >> Yeah, I know - the newer stuff is OK, and it's only emulated not real >> hardware, but memories of pain are memories of pain. >> ___ >> 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 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Technical overview of init systems
> Le 09/08/2017 à 22:46, Joel Roth a écrit : > Despite what the author claims, this series of pages isn't about > init. It is mostly about supervision and a little about containers. It > assumes both are usefull, with no argumentation to motivate supervision. > Confusion about init, supervision, and containers typically suggests > that the author has been contaminated by systemd propaganda. > Also I don't like the style of this series of explanations; there > is little content within a lot of decoration and structure. Clearly the > author has tried all these supervisors but his explanations could be > more detailed. And the answer is... Take what he's written, add in your thoughts, more clearly specify the differences between inits, supervisors, hypervisors, and containers, and write up your own explanation. One thing I might suggest, since you think his explanations could be more detailed, is do a short explanation for each section, kind of an executive summary, and then add in a section closed up initially for more detail for those who need it. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Just out of curiosity, I wondered,
Someone asked for an easy question, and I tried to reply with an effective answer (without perfection). I hope "zap/calmstorm" has already launched any GNU/Linux .iso with that, because hasn't asked more details. El 10/08/17 a les 08:42, Simon Hobson ha escrit: > Adam Borowski wrote: > >> rtl8139 is a 100Mbit card, you really don't want your virtual network speed >> hobbled by emulating such gear. > > It doesn't work like that. The nominal speed of the card is merely that of > the real card being emulated - in the emulated version, there's no serial > pipe to get the bits through (just in-memory copies/moves) and the actual > throughput will be whatever the chain of bits can push through it. That's > certainly the case with Xen which (AIUI) uses Qemu for the I/O stuff. > > > Having said that, people bitten by "cr*p hardware or drivers" tend to have > long memories - Realtek is a make I prefer to avoid. Now, Intel e1000 is a > different matter. > Yeah, I know - the newer stuff is OK, and it's only emulated not real > hardware, but memories of pain are memories of pain. > ___ > 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
