Re: [Dng] nameservers
On March 30, 2015 9:42:33 AM WEST, KatolaZ kato...@freaknet.org wrote: --Snip-- a selection of packages compiled for a certain platform who talk to each other well, and among which a user can select those that better suit their needs. Fullstop. --snip-- I would like to scream those words to all systemd fanatics that stop us having choiced and force us to fork. -- nextime ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Why daemontools is so cool
Le 29/03/2015 11:15, marc a écrit : No need to mix doubleforking and PID tracking on your program. That should be the duty of whatever daemonizes and manages your program. You know, like Daemontools or s6. So there is a very good reason for a deamon to handle its own backgrounding: The sensible convention is it that it should only background at the instant where it is ready to service requests: If there is a long initialisation phase it should stay in the foreground - so that things that depend on it in turn do not get started too soon. A more detailed description of this problem I wrote up a while ago at welz.org.za/notes/on-starting-daemons.html. More fundamentally: If an application has problems calling the a daemonize() or fork_parent() function or the handful of system calls that make up this, then maybe this a limitation of the development environment or language - if calling these this is regarded to be hard then one wonders how reliable the rest of the program is. Dear Marc, This makes sense if we consider the very old way a Linux system was run: boot; then mount filesystems, them start syslog; then initialize network; then start nfs and ssh ... then stop daemons in the reverse order, unmount filesystems and shutdown. A more modern way of starting daemons is to have fine-grained dependencies. Instead of waiting until syslogd is started, why not wait until the socket /var/log is created, or create it even before starting syslogd. And furthermore, is it really necessary to wait for anything before starting the daemons; why wait until the network is configured to start ssh and nfs? Things are not going the linear way anymore. The network cable, as an example, can be disconnected and reconnected, and the network interface de-configured and re-configured, and the ssh daemon will survive, and NFS as well. Even you can reboot an nfs server and clients having their rootfs nfs-mounted come back to life seemlessly. Daemons should be prepared to wait until the needed ressource is available; they should even be prepared to see the ressource they need disapear and to wait until it shows up again. You make a very good point - often forgotten , including by me - about daemon's current directory. But about orphanning the daemons, I disagree. I used to do like you for my private daemons, and to manage pid-files, but it was because I repeated the same scheme by pure lazyness. I am decided to now use a supervisor. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Devuan commitments - will trade-off be applied?
On Mon, Mar 30, 2015 at 02:07:41PM +0200, Didier Kryn wrote: Le 30/03/2015 13:53, John Morris a écrit : Both the FSF and Debian claim to be the most 'Free.' This is not my understanding. Debian does not claim to be more free than GNU. They just admit the reality that some non-free softwares are usefull enough that they deserve to be put in their non-free repo. It's not only FSF accusing Debian of non-freeness (making the non-free repo available), but also the other way: at least two licenses that came from FSF are non-free. And Debian tries hard to look the other way and let bad stuff in: the AGPL is allowed despite failing both FSF Freedom 0[1] and the DFSG Dissident Test[2]. The GFDL, too, is allowed in principle, despite forbidding the user to chmod -r or use technology known as a key to lock the door to the server room, and only unmodifiable sections are disallowed in Debian. The FSF is unhappy Debian called them out for problems in their licenses. [1]. You're not allowed to reuse AGPLed code in an IMAP server, a networked lift control or any other scenario where there's no way for the user to download the source. [2]. Have a blogging platform that allows the general public to place their articles, and dissidents to communicate via steganography hidden in articles they post. Without the public access, suspicious messages stand out, putting the dissidents in risk. Yet the AGPL would force you to release the source, making it obvious for the authorities that there's steganography hidden there. On the other hand, the GPL requires source release only to fellow dissidents who run the software. -- // If you believe in so-called intellectual property, please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] This has GOT to be an April Fools joke
I hope it's absolutely true. Do all the ripping out and rebuilding in their own tree, and if Linus et al don't want to merge the changes back into mainline, distro users can use a sane kernel. Keep your peanut butter out of my chocolate, as it were. Chris Kalin Sr. Network Engineer Leading Upward Mobility Industries for the Blind, Inc. 445 S. Curtis Rd. | West Allis, WI 53214 p. 414-778-3065 c. 414-238-3914 t. 800-642-8778 f. 414-778-3041 www.IBmilw.com Facebook | LinkedIn | Twitter | YouTube NOTICE: The information contained in this email and any document attached hereto is intended only for the named recipient(s). If you are not the intended recipient, nor the employee or agent responsible for delivering this message in confidence to the intended recipient(s), you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this transmittal or its attachments is strictly prohibited. If you have received this transmittal and/or attachments in error, please notify me immediately by reply e-mail and then delete this message, including any attachments. -Original Message- From: Nate Bargmann [mailto:n...@n0nb.us] Sent: Monday, March 30, 2015 6:25 AM To: Devuan project Subject: [Dng] This has GOT to be an April Fools joke Is this really happening? Now it appears as though the systemd developers have found a solution to kernel compatibility problems and a way to extend their philosophy of placing all key operating system components in one repository. According to Ivan Gotyaovich, one of the developers working on systemd, the project intends to maintain its own fork of the Linux kernel. There are problems, problems in collaboration, problems with compatibility across versions. Forking the kernel gives us control over these issues, gives us control over almost all key parts of the stack. http://distrowatch.com/weekly.php?issue=20150330#community Our proximity to April 1 makes me wonder, but still... While there are several quotes in the article from one Ivan Gotyaovich, I don't see any links to said quotes which leaves me a bit skeptical of the veracity of the article. However, the link to GitHub looks very much like a kernel source tree, but I'm not certain that it is an official repository. Before anyone takes this too seriously a bit more research needs to be done as we are very close to the date that an elaborate ruse is plausible, at least for us in the USA. - Nate -- The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true. Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ 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] This has GOT to be an April Fools joke
This would IMO be a good thing, as it will limit the interaction between Poettering OS and normal Linux, and they would have to fix the bugs they create themselves, rather than bitch and moan about the kernel not playing well with their software, it would also mean that they can implement stuff like kdbus without inflicting it on the real kernel. Seriously this if true would be the first good thing to come out of the systemd team in a long time, why aren't we funding this? On Mar 30, 2015 2:25 PM, Nate Bargmann n...@n0nb.us wrote: Is this really happening? Now it appears as though the systemd developers have found a solution to kernel compatibility problems and a way to extend their philosophy of placing all key operating system components in one repository. According to Ivan Gotyaovich, one of the developers working on systemd, the project intends to maintain its own fork of the Linux kernel. There are problems, problems in collaboration, problems with compatibility across versions. Forking the kernel gives us control over these issues, gives us control over almost all key parts of the stack. http://distrowatch.com/weekly.php?issue=20150330#community Our proximity to April 1 makes me wonder, but still... While there are several quotes in the article from one Ivan Gotyaovich, I don't see any links to said quotes which leaves me a bit skeptical of the veracity of the article. However, the link to GitHub looks very much like a kernel source tree, but I'm not certain that it is an official repository. Before anyone takes this too seriously a bit more research needs to be done as we are very close to the date that an elaborate ruse is plausible, at least for us in the USA. - Nate -- The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true. Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ 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] Devuan commitments - will trade-off be applied?
On Mon 30 March 2015 14:30:44 Didier Kryn wrote: Le 30/03/2015 13:49, John Morris a écrit : Simple. Systemd is only the tip of the spear in what appears planned as a total reinvention of the OS. They aren't done yet. What happens when the next major component of that plan appears upstream is something that should be anticipated and planned for this time. We should not be caught unawares again. Seems to be happening pretty fast, even if the other thread is an Aprils joke. Quoting Vlad: Seriously this if true would be the first good thing to come out of the systemd team in a long time, why aren't we funding this? Excellent! Even *I* will fund it, provided that they do *one* thing: Rename your systemd Linux-LennDows|PoetteringOS|RedHatOS, and leave true linux alone. The linux trademark is owned and protected, I think they can't do with linux whatever they want. All they may do is fork and take it elsewhere, like e.g. Android did. And heck when will they finally do? @Didier: I fully agree we should prepare for next impact that's prolly any arbitrary piece picked from http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html /j signature.asc Description: This is a digitally signed message part. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Devuan commitments - will trade-off be applied?
Le 30/03/2015 15:10, Adam Borowski a écrit : On Mon, Mar 30, 2015 at 02:07:41PM +0200, Didier Kryn wrote: Le 30/03/2015 13:53, John Morris a écrit : Both the FSF and Debian claim to be the most 'Free.' This is not my understanding. Debian does not claim to be more free than GNU. They just admit the reality that some non-free softwares are usefull enough that they deserve to be put in their non-free repo. It's not only FSF accusing Debian of non-freeness (making the non-free repo available), but also the other way: at least two licenses that came from FSF are non-free. And Debian tries hard to look the other way and let bad stuff in: the AGPL is allowed despite failing both FSF Freedom 0[1] and the DFSG Dissident Test[2]. The GFDL, too, is allowed in principle, despite forbidding the user to chmod -r or use technology known as a key to lock the door to the server room, and only unmodifiable sections are disallowed in Debian. The FSF is unhappy Debian called them out for problems in their licenses. [1]. You're not allowed to reuse AGPLed code in an IMAP server, a networked lift control or any other scenario where there's no way for the user to download the source. [2]. Have a blogging platform that allows the general public to place their articles, and dissidents to communicate via steganography hidden in articles they post. Without the public access, suspicious messages stand out, putting the dissidents in risk. Yet the AGPL would force you to release the source, making it obvious for the authorities that there's steganography hidden there. On the other hand, the GPL requires source release only to fellow dissidents who run the software. Thanks Adam to recall that this Copyleft matter is probably even more complex that Copyright. I forgot it. It's a nightmare; I think Debian has lawyers to manage all that stuff. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Devuan commitments - will trade-off be applied?
On Mon, Mar 30, 2015 at 02:07:41PM +0200, Didier Kryn wrote: Le 30/03/2015 13:53, John Morris a écrit : Both the FSF and Debian claim to be the most 'Free.' This is not my understanding. Debian does not claim to be more free than GNU. They just admit the reality that some non-free softwares are usefull enough that they deserve to be put in their non-free repo. This is the only reason why Debian is not listed in GNU's list of free OS. True, as far as the actual computer software goes. Not so for documentation. Debian objects to the invariant sections that the GNU Free Documentation Licence approves. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Devuan commitments - will trade-off be applied?
I use F-Droid with cyanogen and I am quite happy, the number and quality of apps is steadily increasing too. On Mar 30, 2015 2:49 PM, John Morris jmor...@beau.org wrote: On Sat, 2015-03-28 at 12:33 +0100, Didier Kryn wrote: BTW, I, like many others, find convenient to use e.g. Skype, and I would prefer to run it inside a container. Over there, Linux installers are Shareware. All of them. I'm not a priest of St. Ignucius but the idea of the return of Shareware gives me the willies and is a future I do. not. want. I don't understand your point. Are sharewares the present as you first say or are they a future you don't want to see? I don't see also why you call shareware the Debian installer. Go look at the Play Store. You can install Linux, including Debian, inside Android via fairly turnkey installers. All of them are Shareware. Not just most of them. Yes there is F-Droid, with all of a few hundred packages, everything else is nagware, spyware, adware or outright paid. F-Droid has Linux a Linux installer too and yup it too was Shareware last time I looked. They had to start admitting Shareware to F-Droid or it apparently would be an empty repo. Build a platform around the idea of untrusted apps and apparently they will come, add in seamless ads and micropayments and Free Software vanishes, Virtualization, containers and jails all have their place, untrustworthy (all closed source) software like Skype being a good use. But when we reach the point we routinely take the performance hit and run everything in one it will probably be because we have surrendered control of the repos to the untrustworthy... or soon will. At the end, John, I don't find what you are proposing, nor even if you do propose anything to avoid what happened with systemd and might well happen again. Simple. Systemd is only the tip of the spear in what appears planned as a total reinvention of the OS. They aren't done yet. What happens when the next major component of that plan appears upstream is something that should be anticipated and planned for this time. We should not be caught unawares again. ___ 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] This has GOT to be an April Fools joke
exactly. On Mar 30, 2015 4:15 PM, Chris Kalin chris.ka...@ibmilw.com wrote: I hope it's absolutely true. Do all the ripping out and rebuilding in their own tree, and if Linus et al don't want to merge the changes back into mainline, distro users can use a sane kernel. Keep your peanut butter out of my chocolate, as it were. Chris Kalin Sr. Network Engineer Leading Upward Mobility Industries for the Blind, Inc. 445 S. Curtis Rd. | West Allis, WI 53214 p. 414-778-3065 c. 414-238-3914 t. 800-642-8778 f. 414-778-3041 www.IBmilw.com Facebook | LinkedIn | Twitter | YouTube NOTICE: The information contained in this email and any document attached hereto is intended only for the named recipient(s). If you are not the intended recipient, nor the employee or agent responsible for delivering this message in confidence to the intended recipient(s), you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this transmittal or its attachments is strictly prohibited. If you have received this transmittal and/or attachments in error, please notify me immediately by reply e-mail and then delete this message, including any attachments. -Original Message- From: Nate Bargmann [mailto:n...@n0nb.us] Sent: Monday, March 30, 2015 6:25 AM To: Devuan project Subject: [Dng] This has GOT to be an April Fools joke Is this really happening? Now it appears as though the systemd developers have found a solution to kernel compatibility problems and a way to extend their philosophy of placing all key operating system components in one repository. According to Ivan Gotyaovich, one of the developers working on systemd, the project intends to maintain its own fork of the Linux kernel. There are problems, problems in collaboration, problems with compatibility across versions. Forking the kernel gives us control over these issues, gives us control over almost all key parts of the stack. http://distrowatch.com/weekly.php?issue=20150330#community Our proximity to April 1 makes me wonder, but still... While there are several quotes in the article from one Ivan Gotyaovich, I don't see any links to said quotes which leaves me a bit skeptical of the veracity of the article. However, the link to GitHub looks very much like a kernel source tree, but I'm not certain that it is an official repository. Before anyone takes this too seriously a bit more research needs to be done as we are very close to the date that an elaborate ruse is plausible, at least for us in the USA. - Nate -- The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true. Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ 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] This has GOT to be an April Fools joke
Nate Did you read the devs name? According to Ivan Gotyaovich link to distrowatch http://distrowatch.com/weekly.php?issue=20150330#community On 03/30/2015 07:25 AM, Nate Bargmann wrote: Is this really happening? Now it appears as though the systemd developers have found a solution to kernel compatibility problems and a way to extend their philosophy of placing all key operating system components in one repository. According to Ivan Gotyaovich, one of the developers working on systemd, the project intends to maintain its own fork of the Linux kernel. There are problems, problems in collaboration, problems with compatibility across versions. Forking the kernel gives us control over these issues, gives us control over almost all key parts of the stack. http://distrowatch.com/weekly.php?issue=20150330#community Our proximity to April 1 makes me wonder, but still... While there are several quotes in the article from one Ivan Gotyaovich, I don't see any links to said quotes which leaves me a bit skeptical of the veracity of the article. However, the link to GitHub looks very much like a kernel source tree, but I'm not certain that it is an official repository. Before anyone takes this too seriously a bit more research needs to be done as we are very close to the date that an elaborate ruse is plausible, at least for us in the USA. - Nate ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Devuan commitments - will trade-off be applied?
On Sat, 2015-03-28 at 12:33 +0100, Didier Kryn wrote: BTW, I, like many others, find convenient to use e.g. Skype, and I would prefer to run it inside a container. Over there, Linux installers are Shareware. All of them. I'm not a priest of St. Ignucius but the idea of the return of Shareware gives me the willies and is a future I do. not. want. I don't understand your point. Are sharewares the present as you first say or are they a future you don't want to see? I don't see also why you call shareware the Debian installer. Go look at the Play Store. You can install Linux, including Debian, inside Android via fairly turnkey installers. All of them are Shareware. Not just most of them. Yes there is F-Droid, with all of a few hundred packages, everything else is nagware, spyware, adware or outright paid. F-Droid has Linux a Linux installer too and yup it too was Shareware last time I looked. They had to start admitting Shareware to F-Droid or it apparently would be an empty repo. Build a platform around the idea of untrusted apps and apparently they will come, add in seamless ads and micropayments and Free Software vanishes, Virtualization, containers and jails all have their place, untrustworthy (all closed source) software like Skype being a good use. But when we reach the point we routinely take the performance hit and run everything in one it will probably be because we have surrendered control of the repos to the untrustworthy... or soon will. At the end, John, I don't find what you are proposing, nor even if you do propose anything to avoid what happened with systemd and might well happen again. Simple. Systemd is only the tip of the spear in what appears planned as a total reinvention of the OS. They aren't done yet. What happens when the next major component of that plan appears upstream is something that should be anticipated and planned for this time. We should not be caught unawares again. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] This has GOT to be an April Fools joke
I'm going with early april fools joke On 30 March 2015 at 14:39, Vlad 2389...@gmail.com wrote: This would IMO be a good thing, as it will limit the interaction between Poettering OS and normal Linux, and they would have to fix the bugs they create themselves, rather than bitch and moan about the kernel not playing well with their software, it would also mean that they can implement stuff like kdbus without inflicting it on the real kernel. Seriously this if true would be the first good thing to come out of the systemd team in a long time, why aren't we funding this? On Mar 30, 2015 2:25 PM, Nate Bargmann n...@n0nb.us wrote: Is this really happening? Now it appears as though the systemd developers have found a solution to kernel compatibility problems and a way to extend their philosophy of placing all key operating system components in one repository. According to Ivan Gotyaovich, one of the developers working on systemd, the project intends to maintain its own fork of the Linux kernel. There are problems, problems in collaboration, problems with compatibility across versions. Forking the kernel gives us control over these issues, gives us control over almost all key parts of the stack. http://distrowatch.com/weekly.php?issue=20150330#community Our proximity to April 1 makes me wonder, but still... While there are several quotes in the article from one Ivan Gotyaovich, I don't see any links to said quotes which leaves me a bit skeptical of the veracity of the article. However, the link to GitHub looks very much like a kernel source tree, but I'm not certain that it is an official repository. Before anyone takes this too seriously a bit more research needs to be done as we are very close to the date that an elaborate ruse is plausible, at least for us in the USA. - Nate -- The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true. Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ 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] Why daemontools is so cool
On Mon, 30 Mar 2015 11:44:29 +0200 Didier Kryn k...@in2p3.fr wrote: Le 29/03/2015 11:15, marc a écrit : No need to mix doubleforking and PID tracking on your program. That should be the duty of whatever daemonizes and manages your program. You know, like Daemontools or s6. So there is a very good reason for a deamon to handle its own backgrounding: The sensible convention is it that it should only background at the instant where it is ready to service requests: If there is a long initialisation phase it should stay in the foreground - so that things that depend on it in turn do not get started too soon. A more detailed description of this problem I wrote up a while ago at welz.org.za/notes/on-starting-daemons.html. More fundamentally: If an application has problems calling the a daemonize() or fork_parent() function or the handful of system calls that make up this, then maybe this a limitation of the development environment or language - if calling these this is regarded to be hard then one wonders how reliable the rest of the program is. Dear Marc, This makes sense if we consider the very old way a Linux system was run: boot; then mount filesystems, them start syslog; then initialize network; then start nfs and ssh ... then stop daemons in the reverse order, unmount filesystems and shutdown. A more modern way of starting daemons is to have fine-grained dependencies. Instead of waiting until syslogd is started, why not wait until the socket /var/log is created, or create it even before starting syslogd. And furthermore, is it really necessary to wait for anything before starting the daemons; why wait until the network is configured to start ssh and nfs? Things are not going the linear way anymore. The network cable, as an example, can be disconnected and reconnected, and the network interface de-configured and re-configured, and the ssh daemon will survive, and NFS as well. Even you can reboot an nfs server and clients having their rootfs nfs-mounted come back to life seemlessly. Daemons should be prepared to wait until the needed ressource is available; they should even be prepared to see the ressource they need disapear and to wait until it shows up again. Hi Didier, If your post says what I think it says, you're saying that modern init systems should always start services concurrently, not consecutively. Certainly that's a good thing, and we're working toward it, but it's important to keep some perspective on the matter and do a cost/benefit analysis on the alternatives. On my experimental Manjaro machine, systemd, which most would agree is very concurrent, booted in 4 seconds. Epoch, which has absolutely no concurrency at all and boots completely consecutively, booted in 8 seconds. How much complexity, how much indeterminacy, are we willing to put up with to get A) 4 more seconds in our life every time we reboot, and B) do it the more modern way? The preceding question has no one right answer. As has been pointed out in many pro-systemd assertions, if you're contracted to provide 0.99 uptime, that four seconds means everything. If there's some reason you need to reboot six times a day, the four second difference could become meaningful. If you're starting 40 services, it could be a difference between 1 minute and 2 minutes, which might be somewhat meaningful if you shut down every night and boot up every morning. And most of all, if you or your distro is careless with order on a completely consecutive boot, it could make all the difference in the world. I've had 5 minute boots, of which 3 minutes was, IIRC, NFS timing out instead of running instantly, because of no reverse DNS. Even today, if you put wicd-cli in your bootup, it takes 20 seconds or so to do the wifi negotiations. But note that all wifi-equipped systemd systems I've seen simply delay wifi-negotiation out of init and into X startup. Looking at the use cases in the preceding two paragraphs, I'd say that in all other cases I can think of, the 4 second plus modern-man feelgood benefit you get from concurrent startup during init doesn't begin to pay for the increased complexity and decreased determinacy of concurrent service startup. By the way, one excellent thing about the Epoch init system is that, because it's completely consecutive, you can get a close look at which services are taking too long to start, troubleshoot them to find the bottleneck, and fix them, so that they'll start efficiently in your concurrent init. The quicker everything starts in a concurrent init, the less chance for race conditions. 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] This has GOT to be an April Fools joke
On 03/30/2015 04:55 PM, Nate Bargmann wrote: repository. According to Ivan Gotyaovich, one of the developers working on systemd, the project intends to maintain its own fork of A search on systemd/systemd on Github indicated that there are no contributions to systemd by an Ivan Gotyaovich. Nimal R. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] This has GOT to be an April Fools joke
On Mon, 30 Mar 2015 06:25:27 -0500 Nate Bargmann n...@n0nb.us wrote: Is this really happening? Now it appears as though the systemd developers have found a solution to kernel compatibility problems and a way to extend their philosophy of placing all key operating system components in one repository. According to Ivan Gotyaovich, one of the developers working on systemd, the project intends to maintain its own fork of the Linux kernel. There are problems, problems in collaboration, problems with compatibility across versions. Forking the kernel gives us control over these issues, gives us control over almost all key parts of the stack. http://distrowatch.com/weekly.php?issue=20150330#community Our proximity to April 1 makes me wonder, but still... While there are several quotes in the article from one Ivan Gotyaovich, I don't see any links to said quotes which leaves me a bit skeptical of the veracity of the article. However, the link to GitHub looks very much like a kernel source tree, but I'm not certain that it is an official repository. Before anyone takes this too seriously a bit more research needs to be done as we are very close to the date that an elaborate ruse is plausible, at least for us in the USA. - Nate ROFLMAO, Here's the problem, Nate. With any other software vendor, we'd instantly and doubtlessly assume it an April Fools Joke. But this is systemd we're talking about, and the first time I heard that it had a 2 way link to Gnome I thought This must be an April Fools Joke, but it wasn't. Whether now or later, I fully expect the systemd guys to make their own kernel, and do it with a non-copyleft license. Interestingly, I was referring to systemd as having an April Fools Joke Architecture in December 2014: http://www.troubleshooters.com/linux/init/manjaro_experiments.htm#manjaro_experiments_pre20141217 See the third non-numbered paragraph. 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] This has GOT to be an April Fools joke
On Mon, Mar 30, 2015 at 12:38:37PM -0400, Steve Litt wrote: [cut] ROFLMAO, Here's the problem, Nate. With any other software vendor, we'd instantly and doubtlessly assume it an April Fools Joke. But this is systemd we're talking about, and the first time I heard that it had a 2 way link to Gnome I thought This must be an April Fools Joke, but it wasn't. Whether now or later, I fully expect the systemd guys to make their own kernel, and do it with a non-copyleft license. That one seems to be a well-conceived (yet premature) April's fool, but in any case nobody can put the Linux kernel under a non-copyletf license, and distribute it :) Actually, nobody can put the Linux kernel exclusively under a license a single bit more restrictive that the GPLv2 in terms of the rights granted to the recipient, and this is just due to the fact that the Linux kernel *is* under GPLv2 ;) Anyway, this little (disgusting) joke is revealing that some users that are currently tolerating the systemd-nonsense would be quite upset if the systemd-nonsense guys would decide to take the Linux kernel aboard (something that I personally think they don't have neither the experience nor the skills to do, but still...). I personally find hilarious that most of the people out there are still convinced that the systemd-nonsense is just a replacement for sysv-init, while it should be clear by now that it is already becoming a pervasive cancer... 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] This has GOT to be an April Fools joke
On 30/03/15 15:15, Chris Kalin wrote: I hope it's absolutely true. Do all the ripping out and rebuilding in their own tree, and if Linus et al don't want to merge the changes back into mainline, distro users can use a sane kernel. Keep your peanut butter out of my chocolate, as it were. Chris Kalin Sr. Network Engineer Last year, I was wondering why they didn't fork Linux kernel first and then do the systemd infection on their own distros with their forked Linux kernel. But after I thought about it further, there is no advantage to them to do it as that would only affect RedHat, Fedora and all distros based on them. So they infected systemd into all major distros first then after that they will start to fork Linux kernel. I was so afraid that this is going to happen. But I felt quite relief to know that some sane and intelligent people forked Debian. So I really hope that they are really going to fork Linux kernel and do all the infections there, as that will make Devuan easier to move on. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Why daemontools is so cool
Hi Steve, On Mon, Mar 30, 2015 at 7:24 PM, Steve Litt - sl...@troubleshooters.com devuan.kn.3c178e07a2.slitt#troubleshooters@ob.0sg.net wrote: Hi Didier, If your post says what I think it says, you're saying that modern init systems should always start services concurrently, not consecutively. Certainly that's a good thing, and we're working toward it, but it's important to keep some perspective on the matter and do a cost/benefit analysis on the alternatives. On my experimental Manjaro machine, systemd, which most would agree is very concurrent, booted in 4 seconds. Epoch, which has absolutely no concurrency at all and boots completely consecutively, booted in 8 seconds. How much complexity, how much indeterminacy, are we willing to put up with to get A) 4 more seconds in our life every time we reboot, and B) do it the more modern way? How fast is epoch when you throw it at a generic piece of hardware that you did not hand-tune it for? The problem there is that a consecutive boot system needs to probe for hardware and give that hardware time to show up, blocking the boot process in the meantime. If you have lots of hardware you need to probe for (as e.g. Devuan would need to out-of-the-box), then those wait-times can sum up really fast. And some hardware can take a very long time to register, so you need to be generous with those time-outs. On the other hand anybody without the hardware will stuck for the entire timeout, so you need to keep them as short as possible. A parallel boot system can just start all hardware probes at the same time, be very generic with the timeouts and just continue as soon as the necessary hardware showed up. It is also impossible to *generically* support all possible of combinations of real hardware, devicemapper, LVM, software raid, fsck and cryptsetup in a consecutive boot setup. Debian had long-standing bugs to that regard. Note that you can of course configure anything with any system manually, but any Linux distribution should strive to support as wide a range of setups as possible out-of-the-box. Well, arch and gentoo obviously do not need to, but they already fill their niches quite nicely:-) And most of all, if you or your distro is careless with order on a completely consecutive boot, it could make all the difference in the world. I've had 5 minute boots, of which 3 minutes was, IIRC, NFS timing out instead of running instantly, because of no reverse DNS. Even today, if you put wicd-cli in your bootup, it takes 20 seconds or so to do the wifi negotiations. But note that all wifi-equipped systemd systems I've seen simply delay wifi-negotiation out of init and into X startup. If your distro screws up, then you are screwed (until you fix it;-). That is pretty much true independent of the topic. I seriously doubt that systemd was pushing wifi-negotiation into X startup though. With any non-concurrent system X may be up and waiting for your login long before init is done with the initial setup of your system. So it may appear like wifi negotiation happens only after X login. Or you might have been ended up using network-manager, which has a tendency to only start the network after somebody logged in:-/ Looking at the use cases in the preceding two paragraphs, I'd say that in all other cases I can think of, the 4 second plus modern-man feelgood benefit you get from concurrent startup during init doesn't begin to pay for the increased complexity and decreased determinacy of concurrent service startup. The killer argument for parallel startup with dependency handling is robustness, not speed. Maybe it is my tendency to mess around with cryptsetup and co. that gets me into trouble, but I did have unbootable systems with sysv-init due to unexpected setup problems. Nothing I could not fix, but still an annoyance that I would be happy to get rid of. This is a statement about the concept of parallel init systems with dependencies, not about any specific implementation. By the way, one excellent thing about the Epoch init system is that, because it's completely consecutive, you can get a close look at which services are taking too long to start, troubleshoot them to find the bottleneck, and fix them, so that they'll start efficiently in your concurrent init. The quicker everything starts in a concurrent init, the less chance for race conditions. Yes and no. What happens if your filesystem has a slow day (e.g. due to some f*ing RAID controller deciding that it needs to do some extra sanity checks)? That will lead to the consecutive boot system panicking since its root device is not there (after some timeout), which in turn will lead to some poor admin having to investigate and nudge the server to try once more. The whole consecutive boot thing hinges on timeouts and that is neither generic nor robust. I admit that it is simple. And I also think that epoch can make a great init system for a specific system, but there are
Re: [Dng] This has GOT to be an April Fools joke
* On 2015 30 Mar 06:37 -0500, etech3 wrote: Nate Did you read the devs name? According to Ivan Gotyaovich Umm, yes, which is partly the reason why I mention my skepticism. Remember, all good humor has a kernel of truth. - Nate -- The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true. Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Why daemontools is so cool
The problem there is that a consecutive boot system needs to probe for hardware and give that hardware time to show up, blocking the boot process in the meantime. The only hardware detection during boot that *needs* to block is mounting the root device. Boot cannot proceed without that. To do so, the kernel needs to have a driver for the device--either loaded into it by the initramfs (the loading and execution of which takes time), or compiled in directly. The remaining driver-loading does not run as part of the boot sequence. Only the modules needed to bring the system up get loaded (i.e. the modules in /etc/modprobe.d). Once root and the other filesystems are mounted, you should be able to start programs up in whatever order regardless of the state of the hardware. Individual programs like ntpd should be smart enough to wait until the required hardware is available and configured, such as network interfaces (either on their own, or with the help of a supervisor). If your boot sequence is taking too long because it's loading unnecessary drivers, then your boot sequence is misconfigured. And some hardware can take a very long time to register, so you need to be generous with those time-outs. On the other hand anybody without the hardware will stuck for the entire timeout, so you need to keep them as short as possible. If your hardware is taking a long time to spin up, it's due to bug in either the hardware or its driver, not the boot sequence. Again, if you're talking about waiting for the device with your root filesystem, the boot process is *supposed* to block until it's ready. Boot cannot proceed until the root device is found and mounted; otherwise you obviously cannot load programs. This process cannot be sped up through parallelization (Amdahl's Law and all that). Same goes for programs that cannot be started until /usr is mounted (if you have a separate /usr). A parallel boot system can just start all hardware probes at the same time, be very generic with the timeouts and just continue as soon as the necessary hardware showed up. Hardware detection happens in the kernel, and the kernel does detect hardware in parallel. That's one of the reasons why you get to deal with disk and interface names changing between boots. Just continuing as soon as the necessary hardware shows up is already what happens, like I said above. Also, it's useless to run more instances of insmod(8) than you have CPU cores. It can be dangerous to run even two insmod(8)'s in parallel, since last I checked [1], setting up a kernel module is not an atomic operation. Run multiple insmod(8)'s at your own risk--you may expose race conditions that crash your system or render your hardware unusable without a reboot. The killer argument for parallel startup with dependency handling is robustness, not speed. No, the opposite is true. Programs with multiple instances of execution (processes, threads, coroutines) in practice tend to be much more error-prone, because they are much harder to reason about. This is because the number of states such a program can be in increases with the *factorial* of the number of instances of execution it has. This is such a problem that determinism is often a design requirement for mission-critical software whose failure will result in huge costs and/or loss of life. Maybe it is my tendency to mess around with cryptsetup and co. that gets me into trouble, but I did have unbootable systems with sysv-init due to unexpected setup problems. Nothing I could not fix, but still an annoyance that I would be happy to get rid of. Parallel boot won't fix misconfigurations you introduced by messing around with it. The whole consecutive boot thing hinges on timeouts and that is neither generic nor robust. The boot sequence does *not* hinge on timeouts. If anything, timeouts are a fallback mechanism for working around other programs not making forward progress (i.e. due to bugs, a down network, or faulty hardware). If your boot sequence is encountering timeouts, then something's wrong with your boot sequence. -Jude [1] http://lkml.iu.edu/hypermail/linux/kernel/1502.2/01852.html On Mon, Mar 30, 2015 at 2:54 PM, devuan...@spamgourmet.net wrote: Hi Steve, On Mon, Mar 30, 2015 at 7:24 PM, Steve Litt - sl...@troubleshooters.com devuan.kn.3c178e07a2.slitt#troubleshooters@ob.0sg.net wrote: Hi Didier, If your post says what I think it says, you're saying that modern init systems should always start services concurrently, not consecutively. Certainly that's a good thing, and we're working toward it, but it's important to keep some perspective on the matter and do a cost/benefit analysis on the alternatives. On my experimental Manjaro machine, systemd, which most would agree is very concurrent, booted in 4 seconds. Epoch, which has absolutely no concurrency at all and boots completely consecutively, booted in 8 seconds. How much complexity,
Re: [Dng] This has GOT to be an April Fools joke
* On 2015 30 Mar 12:05 -0500, KatolaZ wrote: Anyway, this little (disgusting) joke is revealing that some users that are currently tolerating the systemd-nonsense would be quite upset if the systemd-nonsense guys would decide to take the Linux kernel aboard (something that I personally think they don't have neither the experience nor the skills to do, but still...). I think Red Hat does have the man power and the people with the skills to maintain their own autonomous kernel indefinitely. In fact, there likely a lot of parts they could simply do away with to streamline the process. Also, Red Hat is large enough and prestigious enough to attract the necessary talent. I personally find hilarious that most of the people out there are still convinced that the systemd-nonsense is just a replacement for sysv-init, while it should be clear by now that it is already becoming a pervasive cancer... Of course, the next step is an authorized and signed kernel distributed only in binary form that can be trusted on Win10 certified hardware. Add to that scenario that some future version of systemd will only work with the signed and trusted binary only kernel... - Nate -- The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true. Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Why daemontools is so cool
If you need to generically support a wide range of setups and include the fun stuff listed above into the mix, then your init system will need to do a lot more than what is necessary to bring up one individual system. Debian did run all of the above during its boot sequence (if the package was installed), just in case somebody actually went ahead and used it. Except that it doesn't. Debian will only do the extra fun stuff if it's installed and usable. Go read the init scripts in /etc/rcS.d if you don't believe me. Dependencies enable you to have a robust boot sequence even with hardware like this. No. No they do not. Let me say it again: if the device with your root filesystem is unavailable, the boot process *will* wait for it to become available. There is no alternative, besides panicking. There is no parallelization before root gets mounted, because nothing else *can* start. If you want to support a wide range of combinations of all the goodies Linux comes with, incl. software raid, logical volume management, disk encryption and any combination thereof, then you can not do so in a generic way using a strictly sequential init system. You can configure all of these for each individual system, but you can not have generic support for all of them in any valid combination in your distribution. First, the extra packages are not used unless you install them, and will only get invoked if they are needed. Second, Debian has initialized them all sequentially, in the right order, without fail for the better part of its existence. In fact, if you go look at Debian bug tracker, the introduction of init script parallelization strategies have lead to hard-to-reproduce boot bugs due to race conditions. You will also need to introduce timeouts (which are either too short or too long, depending on the system) into each and every step along the way. What are you talking about? root@t510:/home/jude# runlevel N 2 root@t510:/home/jude# fgrep -r sleep /etc/rc2.d /etc/rcS.d root@t510:/home/jude# You do *not* need timeouts to boot the system sequentially. My point is A init system should be robust to work with any valid configuration I can put the system in and I understand your reply to be Complexity makes programs less robust. I agree with both statement and see no contradiction whatsoever. Um, no. That has *never*, *EVER* been the case. If you break something, it stays broken until you fix it. The OS does exactly what you tell it to do, as it should. It's not the OS's responsibility to clean up your mistakes if you put it into a state where it can't boot. A strictly sequential boot is not able to do that in a generic way. You can configure *your* system to do that by tweaking the sequence, but it is impossible for a distribution to ship a sequential init system that can robustly set up any filesystem that you can mount manually. Then how, pray tell, has Debian been able to boot sequentially all these years, with all these features? Okay. I hate that it's come to this, but at this point in reading your reply I can no longer tell whether or not you're a troll. You talk about the low-level details of userspace like you think you understand it, but it's pretty clear that you do not (or, you do a very bad job at communicating it). Either way, this thread has gone wildly off-topic, so I will no longer reply to it. -Jude On Mon, Mar 30, 2015 at 7:06 PM, devuan...@spamgourmet.net wrote: Hi Jude, hello Isaac, I did express myself poorly when I spoke of hardware detection. You both are fully correct to call me out on that. Yes, hardware detection happens in the kernel, and indeed some of it is done in parallel there. I was thinking about all the user-space tools that scan drives and create new devices based on their findings when writing this mail. These little things like btrfs scan, lvm --forgot-the-parameter, cryptsetup open, and the others that allow you to do cool things with your filesystems. Sorry for the confusion this caused and my poor choice of words. On Tue, Mar 31, 2015 at 12:05 AM, Jude Nelson - jud...@gmail.com devuan.kn.ae5676beef.judecn#gmail@ob.0sg.net wrote: snip If your boot sequence is taking too long because it's loading unnecessary drivers, then your boot sequence is misconfigured. If you need to generically support a wide range of setups and include the fun stuff listed above into the mix, then your init system will need to do a lot more than what is necessary to bring up one individual system. Debian did run all of the above during its boot sequence (if the package was installed), just in case somebody actually went ahead and used it. And some hardware can take a very long time to register, so you need to be generous with those time-outs. On the other hand anybody without the hardware will stuck for the entire timeout, so you need to keep them as short as possible. If your hardware is taking a long time
Re: [Dng] Why daemontools is so cool
Okay, one technical correction (on myself): What are you talking about? root@t510:/home/jude# runlevel N 2 root@t510:/home/jude# fgrep -r sleep /etc/rc2.d /etc/rcS.d root@t510:/home/jude# You do *not* need timeouts to boot the system sequentially. I should have typed fgrep -r sleep /etc/rc2.d/* /etc/rcS.d/*, since it slipped my mind that fgrep does not follow symlinks unless specified on the command-line. While this command yields many instances of sleep, a cursory inspection of when they occur indicates that the init scripts almost always execute sleep as part a restart, reload, upgrade, or failsafe. They do not sleep on the start/stop critical paths. Thus, I stand by my earlier point that timeouts aren't an expected part of the boot process. -Jude On Mon, Mar 30, 2015 at 10:55 PM, Jude Nelson jud...@gmail.com wrote: If you need to generically support a wide range of setups and include the fun stuff listed above into the mix, then your init system will need to do a lot more than what is necessary to bring up one individual system. Debian did run all of the above during its boot sequence (if the package was installed), just in case somebody actually went ahead and used it. Except that it doesn't. Debian will only do the extra fun stuff if it's installed and usable. Go read the init scripts in /etc/rcS.d if you don't believe me. Dependencies enable you to have a robust boot sequence even with hardware like this. No. No they do not. Let me say it again: if the device with your root filesystem is unavailable, the boot process *will* wait for it to become available. There is no alternative, besides panicking. There is no parallelization before root gets mounted, because nothing else *can* start. If you want to support a wide range of combinations of all the goodies Linux comes with, incl. software raid, logical volume management, disk encryption and any combination thereof, then you can not do so in a generic way using a strictly sequential init system. You can configure all of these for each individual system, but you can not have generic support for all of them in any valid combination in your distribution. First, the extra packages are not used unless you install them, and will only get invoked if they are needed. Second, Debian has initialized them all sequentially, in the right order, without fail for the better part of its existence. In fact, if you go look at Debian bug tracker, the introduction of init script parallelization strategies have lead to hard-to-reproduce boot bugs due to race conditions. You will also need to introduce timeouts (which are either too short or too long, depending on the system) into each and every step along the way. What are you talking about? root@t510:/home/jude# runlevel N 2 root@t510:/home/jude# fgrep -r sleep /etc/rc2.d /etc/rcS.d root@t510:/home/jude# You do *not* need timeouts to boot the system sequentially. My point is A init system should be robust to work with any valid configuration I can put the system in and I understand your reply to be Complexity makes programs less robust. I agree with both statement and see no contradiction whatsoever. Um, no. That has *never*, *EVER* been the case. If you break something, it stays broken until you fix it. The OS does exactly what you tell it to do, as it should. It's not the OS's responsibility to clean up your mistakes if you put it into a state where it can't boot. A strictly sequential boot is not able to do that in a generic way. You can configure *your* system to do that by tweaking the sequence, but it is impossible for a distribution to ship a sequential init system that can robustly set up any filesystem that you can mount manually. Then how, pray tell, has Debian been able to boot sequentially all these years, with all these features? Okay. I hate that it's come to this, but at this point in reading your reply I can no longer tell whether or not you're a troll. You talk about the low-level details of userspace like you think you understand it, but it's pretty clear that you do not (or, you do a very bad job at communicating it). Either way, this thread has gone wildly off-topic, so I will no longer reply to it. -Jude On Mon, Mar 30, 2015 at 7:06 PM, devuan...@spamgourmet.net wrote: Hi Jude, hello Isaac, I did express myself poorly when I spoke of hardware detection. You both are fully correct to call me out on that. Yes, hardware detection happens in the kernel, and indeed some of it is done in parallel there. I was thinking about all the user-space tools that scan drives and create new devices based on their findings when writing this mail. These little things like btrfs scan, lvm --forgot-the-parameter, cryptsetup open, and the others that allow you to do cool things with your filesystems. Sorry for the confusion this caused and my poor choice of words. On Tue,
Re: [Dng] Any plans to provide xinit without the systemd hacks?
Hey Isaac, So, I'm looking at startx here: http://cgit.freedesktop.org/xorg/app/xinit/tree/startx.cpp Where's the offending block of code? Is it lines 191-200? Looking at the commit history ( http://cgit.freedesktop.org/xorg/app/xinit/log/), it doesn't look like startx sees many changes these days. It should be easy to keep a separate startx script around, if you don't want it starting X on your current tty. -Jude On Sat, Mar 28, 2015 at 11:26 AM, Isaac Dunham ibid...@gmail.com wrote: startx always used to start a new X server on a new TTY; now it starts on the current vt. This is the result of a block of code in startx that forces vtarg to the equivalent of `tty`. The sole reason for this is that logind gets confused when something opens on a new vt. Will Devuan include an xinit package that doesn't do this? Thanks, Isaac Dunham ___ 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
