Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On 05/29/2013 09:55 PM, William Hubbs wrote: > On Wed, May 29, 2013 at 09:56:00PM +0200, Tom Wijsman wrote: >>> There are a couple of other possible approaches... >>> >>> 1) If the 2 systems can achieve peacefull co-existance (i.e. >>> no identically-named files with different contents) then simply >>> have 2 boot entries in /etc/lilo.conf (or grub equivalant)... >>> >>> [SNIP to shorten mail] >> >> Users can already do this, this isn't a solution. >> >> We want to make this easier towards the user, therefore doing >> heavy discussion to exhaust all the alternatives and maybe >> someone's interested in implementing one of them that appears >> most feasible. > > Since users can already do this, why are we bothering with > re-inventing the wheel? How does running an eselect init command > make it easier for the user than telling them to edit their boot > loader config file? > > Gentoo users are expected to build their kernel and write their > boot loader config file initially, so why are we trying to dumb > this down? > > William > There is no harm in providing alternatives. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 30 May 2013 09:54:38 -0400 Ian Stakenvicius wrote: > On 30/05/13 02:46 AM, Ciaran McCreesh wrote: > > On Wed, 29 May 2013 19:22:32 -0500 William Hubbs > > wrote: > >> We could probably also turn gcc-config into an eselect module if > >> we want to use that argument. > > > > Someone did, but unfortunately gcc-config is a big pile of poorly > > understood voodoo, so eclectic gcc ended up being abandoned. > > > > The eselect-gcc wrapper was almost an alias though, wasn't it? ie, it > just called gcc-config underneath? At least one of the eselect gcc implementations was "from scratch". > Is there interest in reviving this? All of our documentation has > discussed using gcc-config directly for so long, i'm not sure if > there'd be that much adoption... It would be good, in the name of consistency. It would also be a great opportunity to fix Gentoo's unique inability to have multiple libstdc++ versions usable simultaneously. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iEYEARECAAYFAlGoQYgACgkQ96zL6DUtXhH69QCgseYybgvnYUyTJNBCrnQvyf3t XbkAnik/suBWNyQp6D919WqGmWc+3EeG =msFd -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Thu, May 30, 2013 at 08:35:22AM +0200, Tom Wijsman wrote: > Remember that eselect init is optional and an opt-in by emerging it, > this is in no way suggested anywhere to become a default on all systems. Ok, that's cool then, I just would hate to see it become a default. William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/05/13 02:46 AM, Ciaran McCreesh wrote: > On Wed, 29 May 2013 19:22:32 -0500 William Hubbs > wrote: >> We could probably also turn gcc-config into an eselect module if >> we want to use that argument. > > Someone did, but unfortunately gcc-config is a big pile of poorly > understood voodoo, so eclectic gcc ended up being abandoned. > The eselect-gcc wrapper was almost an alias though, wasn't it? ie, it just called gcc-config underneath? Is there interest in reviving this? All of our documentation has discussed using gcc-config directly for so long, i'm not sure if there'd be that much adoption... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGnWh4ACgkQ2ugaI38ACPDikgEAmMoqnaQK7INQvVWWN65DdP2q xQDyGr6X6CR59aZzV8sA/3EBjOBPTH4+SKOUjA4ar0ghlItSCrmWCBjNJdPhIwiQ =d1d+ -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, 29 May 2013 19:22:32 -0500 William Hubbs wrote: > We could probably also turn gcc-config into an eselect module if we > want to use that argument. Someone did, but unfortunately gcc-config is a big pile of poorly understood voodoo, so eclectic gcc ended up being abandoned. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, 29 May 2013 19:22:32 -0500 William Hubbs wrote: > > For the same reason we have all the other eselect modules. > > We could probably also turn gcc-config into an eselect module if we > want to use that argument. Looking at Duncan's reply, that has already happened in the past. Really, think about it, why do we have all those eselect modules at all? Why be inconsistent and not introduce one here? Why keep them around? Well, the answer is simple: Remember that eselect init is optional and an opt-in by emerging it, this is in no way suggested anywhere to become a default on all systems. If you don't want it, fine, but that doesn't stop us from pursuing it... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
Tom Wijsman wrote: > For the same reason we have all the other eselect modules. > http://www.gentoo.org/proj/en/eselect/ Ironically, that project description even mentions init system... :) As someone else pointed out, not the same thing. Quoting: William Hubbs wrote: > Yes, but the init system module that project refers to is already there. > Check out eselect rc. It has nothing to do with switching init systems. > It appears to be a wrapper around rc-update and a couple of other things > to manage init scripts and runlevels. > > Thanks, > > William > In case you missed the post, thought I would provide it to clear up the matter. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, 29 May 2013 22:52:58 -0400 "Walter Dnes" wrote: > If users can already do it themselves, then why this entire thread? > Why do we need eselect/whatever? The big argument in favour of eselect is that when the procedure for switching things changes, there's no need to worry about users doing the old thing. (That, and if eselect doesn't have it, there will be something far worse showing up on the forums anyway...) -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On 05/29/2013 10:55 PM, William Hubbs wrote: > On Wed, May 29, 2013 at 09:56:00PM +0200, Tom Wijsman wrote: >>> There are a couple of other possible approaches... >>> >>> 1) If the 2 systems can achieve peacefull co-existance (i.e. no >>> identically-named files with different contents) then simply have 2 >>> boot entries in /etc/lilo.conf (or grub equivalant)... >>> >>> [SNIP to shorten mail] >> >> Users can already do this, this isn't a solution. >> >> We want to make this easier towards the user, therefore doing heavy >> discussion to exhaust all the alternatives and maybe someone's >> interested in implementing one of them that appears most feasible. > > Since users can already do this, why are we bothering with re-inventing > the wheel? How does running an eselect init command make it easier for > the user than telling them to edit their boot loader config file? Because to me and many other EFI users is quite annoying having to rebuild the kernel or do something ugly such as editing a binary file. Because it isn't just editing a file or rebuilding the kernel but also have a short trip in single mode to switch back and forth inittab. Because addons such as bootchart2 or e4rat would be much simpler to use through eselect init than doing the whole bootloader or kernel-rebuild dance. > Gentoo users are expected to build their kernel and write their boot > loader config file initially, so why are we trying to dumb this down? Because usually we aren't linux from scratch and we try to automate as much as we could, leaving the options there to be selected =) lu
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, 29 May 2013 22:52:58 -0400 "Walter Dnes" wrote: > > > In order for a different init system to come up, some file(s) > > > somewhere *MUST* be different, no ifs/ands/ors/buts. > > > > How true is this in general? It is usually only a change of the init > > parameter. > > Where is the init parameter changed? Wherever it needs to be changed. > [... SNIP] byte-identical hard drives [SNIP ...] You either change it at boot time or on the hard drive. > > > The problem with an eselect approach is that it's like asking a > > > brain surgeon to operate on himself. > > > > eselect and wrappers don't operate on themselves, please elaborate. > > The operating system is changing itself. The world is changing itself. > > > [SNIP to shorten mail] > > > > Users can already do this, this isn't a solution. > > If users can already do it themselves, then why this entire thread? > Why do we need eselect/whatever? For the same reason we have all the other eselect modules. http://www.gentoo.org/proj/en/eselect/ Ironically, that project description even mentions init system... :) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, May 29, 2013 at 09:56:00PM +0200, Tom Wijsman wrote > "Walter Dnes" wrote: > > > In order for a different init system to come up, some file(s) > > somewhere *MUST* be different, no ifs/ands/ors/buts. > > How true is this in general? It is usually only a change of the init > parameter. Where is the init parameter changed? Even if it's only the "append" line in /etc/lilo.conf, my above statement still holds true. If you've got two identical machines with byte-identical hard drives, they can not boot two different OS's or init systems. > > The problem with an eselect approach is that it's like asking a brain > > surgeon to operate on himself. > > eselect and wrappers don't operate on themselves, please elaborate. The operating system is changing itself. > > [SNIP to shorten mail] > > Users can already do this, this isn't a solution. > > [SNIP to shorten mail] > > Again: Users can already do this, this isn't a solution. See above... If users can already do it themselves, then why this entire thread? Why do we need eselect/whatever? -- Walter Dnes I don't run "desktop environments"; I run useful applications
[gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
William Hubbs posted on Wed, 29 May 2013 19:22:32 -0500 as excerpted: > We could probably also turn gcc-config into an eselect module if we want > to use that argument. IIRC it actually was, at one point. The eselect gcc module even allowed separate configs for 32-bit and 64-bit on at least amd64/multilib. However, the gentoo dev, Jeremy Huddleston IIRC (tho I used to get him and another dev with I believe the same initials mixed up, so I might have gotten the wrong one), that developed and maintained the package moved on (IIRC to Apple... looks like he's still there if I'm googling the same one?), and nobody cared to take it up so it rotted until it was masked and I guess eventually removed. Since then I guess nobody's dared (or simply didn't have the prioritized time if they dared) mess with the existing gcc-config enough to try to turn it into an eselect module again. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Thu, May 30, 2013 at 02:06:42AM +0200, Tom Wijsman wrote: > On Wed, 29 May 2013 15:55:23 -0500 > William Hubbs wrote: > > > > We want to make this easier towards the user, therefore doing heavy > > > discussion to exhaust all the alternatives and maybe someone's > > > interested in implementing one of them that appears most feasible. > > > > Since users can already do this, why are we bothering with > > re-inventing the wheel? How does running an eselect init command make > > it easier for the user than telling them to edit their boot loader > > config file? > > > > Gentoo users are expected to build their kernel and write their boot > > loader config file initially, so why are we trying to dumb this down? > > For the same reason we have all the other eselect modules. We could probably also turn gcc-config into an eselect module if we want to use that argument. > http://www.gentoo.org/proj/en/eselect/ > > Ironically, that project description even mentions init system... :) Yes, but the init system module that project refers to is already there. Check out eselect rc. It has nothing to do with switching init systems. It appears to be a wrapper around rc-update and a couple of other things to manage init scripts and runlevels. Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, 29 May 2013 15:55:23 -0500 William Hubbs wrote: > > We want to make this easier towards the user, therefore doing heavy > > discussion to exhaust all the alternatives and maybe someone's > > interested in implementing one of them that appears most feasible. > > Since users can already do this, why are we bothering with > re-inventing the wheel? How does running an eselect init command make > it easier for the user than telling them to edit their boot loader > config file? > > Gentoo users are expected to build their kernel and write their boot > loader config file initially, so why are we trying to dumb this down? For the same reason we have all the other eselect modules. http://www.gentoo.org/proj/en/eselect/ Ironically, that project description even mentions init system... :) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, May 29, 2013 at 09:56:00PM +0200, Tom Wijsman wrote: > > There are a couple of other possible approaches... > > > > 1) If the 2 systems can achieve peacefull co-existance (i.e. no > > identically-named files with different contents) then simply have 2 > > boot entries in /etc/lilo.conf (or grub equivalant)... > > > > [SNIP to shorten mail] > > Users can already do this, this isn't a solution. > > We want to make this easier towards the user, therefore doing heavy > discussion to exhaust all the alternatives and maybe someone's > interested in implementing one of them that appears most feasible. Since users can already do this, why are we bothering with re-inventing the wheel? How does running an eselect init command make it easier for the user than telling them to edit their boot loader config file? Gentoo users are expected to build their kernel and write their boot loader config file initially, so why are we trying to dumb this down? William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, 29 May 2013 14:15:54 -0400 "Walter Dnes" wrote: > In order for a different init system to come up, some file(s) > somewhere *MUST* be different, no ifs/ands/ors/buts. How true is this in general? It is usually only a change of the init parameter. As far as I heard there is only one exception, /etc/inittab being different between just two init systems; if you know more exceptions, feel free to list them. So, please prove your statement. > The problem with an eselect approach is that it's like asking a brain > surgeon to operate on himself. eselect and wrappers don't operate on themselves, please elaborate. > The proper procedure is to have another brain surgeon operate on him > while the patient is under anesthesia. Actually no, we're going a step further. The eselect doesn't touch the wrapper, but only its config; it's like actually changing brain memory. > There are a couple of other possible approaches... > > 1) If the 2 systems can achieve peacefull co-existance (i.e. no > identically-named files with different contents) then simply have 2 > boot entries in /etc/lilo.conf (or grub equivalant)... > > [SNIP to shorten mail] Users can already do this, this isn't a solution. We want to make this easier towards the user, therefore doing heavy discussion to exhaust all the alternatives and maybe someone's interested in implementing one of them that appears most feasible. > > Having an initr* as a requirement for being able to switch init > > system is maybe a bit too much to ask; same as above, iff nothing > > else ... > > 2) We already have such a solution; it's called the Gentoo minimal > install ISO. I agree, I have mine always available; yet some people are consistent in coming up with solutions for when all hell breaks lose. > If the 2 init systems conflict over identically-named > files, I strongly recommend that the changes be done while booted > from a gentoo minimal install ISO. > > [SNIP to shorten mail] Again: Users can already do this, this isn't a solution. See above... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, May 29, 2013 at 10:52:49AM +0200, Tom Wijsman wrote > On Wed, 29 May 2013 00:36:58 + (UTC) > Duncan <1i5t5.dun...@cox.net> wrote: > > > 3b) Except... at that point root isn't writable > > Let me stop you here. Does it need to be writable at that point? > > We're reading the path of the init file to boot from a file, we start > the executable at that path; no writes are involved here. > > The only problem left here is that some init systems need a specific > version of the inittab file, although this can likely be changed in > late shutdown as the only exception to this approach. In order for a different init system to come up, some file(s) somewhere *MUST* be different, no ifs/ands/ors/buts. The problem with an eselect approach is that it's like asking a brain surgeon to operate on himself. The proper procedure is to have another brain surgeon operate on him while the patient is under anesthesia. > It sounds very feasible for init systems that are an exception to just > being able to switch init alone or have conflicting files to fix up > whatever is inconsistent; either by scheduling changes till when the > disk is writable, or by doing it on shutdown... > > > But it occurred to me that we actually do have a demonstrated > > workable and long used in actual practice exception to the normal > > boot case as precedent, where such maintenance tasks traditionally > > occur, single user mode. > > Iff nothing else is feasible enough, this makes a lot of sense to me. There are a couple of other possible approaches... 1) If the 2 systems can achieve peacefull co-existance (i.e. no identically-named files with different contents) then simply have 2 boot entries in /etc/lilo.conf (or grub equivalant)... append = "init=/etc/foo" append = "init=/etc/bar" ...and select whichever one you want from the boot menu. This guarantees a) the system shuts down properly with the old init b) the system starts up properly with the new init c) if the new files are incorrect/unbootable, you can simply reboot to the old version and try to figure out what went wrong > > [initr* SNIP] > > Having an initr* as a requirement for being able to switch init system > is maybe a bit too much to ask; same as above, iff nothing else ... 2) We already have such a solution; it's called the Gentoo minimal install ISO. If the 2 init systems conflict over identically-named files, I strongly recommend that the changes be done while booted from a gentoo minimal install ISO. This guarantees a) the system shuts down properly with the old init b) the system starts up properly with the new init c) if the new files are incorrect/unbootable, you can simply chroot into the machine and send pleas for help to the Gentoo user mailing list ;) -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, 29 May 2013 00:36:58 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > 3b) Except... at that point root isn't writable Let me stop you here. Does it need to be writable at that point? We're reading the path of the init file to boot from a file, we start the executable at that path; no writes are involved here. The only problem left here is that some init systems need a specific version of the inittab file, although this can likely be changed in late shutdown as the only exception to this approach. It sounds very feasible for init systems that are an exception to just being able to switch init alone or have conflicting files to fix up whatever is inconsistent; either by scheduling changes till when the disk is writable, or by doing it on shutdown... > But it occurred to me that we actually do have a demonstrated > workable and long used in actual practice exception to the normal > boot case as precedent, where such maintenance tasks traditionally > occur, single user mode. Iff nothing else is feasible enough, this makes a lot of sense to me. > [initr* SNIP] Having an initr* as a requirement for being able to switch init system is maybe a bit too much to ask; same as above, iff nothing else ... > 4) Finally, the fact that each init-system package gets to control > its own switcher-mode script keeps control of it with the init-system > package maintainers, allowing them to choose as complex or simple a > script as they need/wish, reasonably addressing the whole maintainer > control problem so evident in another current thread. We should avoid maintenance burden where we can; we can't also force things upon them, as you can see in other ML threads here. Init systems are quite necessary in Gentoo, let's not risk losing their maintainers. That being said; if there are exceptions to the approach we end up taking, we need to put these somewhere. It kind of depends on how we will integrate the init system approach in the Portage tree. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
[gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
Tom Wijsman posted on Tue, 28 May 2013 13:56:19 +0200 as excerpted: > You're making a lot of statements like this but don't back them up. > > Why would this work best for this situation? What's wrong with the rest? While as long as it stays out of my way enough so I don't have to worry about it, I don't particularly care (to the point I debated simply not replying), your post did make me aware of the fact that I was claiming negatives on the other methods without backing up the claims... because from here they were evident, and others had made them well enough I didn't need to. However, I guess if I claim something I owe it to my readers to be prepared to back it up, so... As I've read the thread, there seem to be four issues with most of the other methods discussed, three related, one separate. 1) Changing an initsystem with the system up and running in normal state risks not being able to shut down properly. While some init-systems may either not have that problem or be able to work around it in a trivial way, getting something robust enough to work reliably across all of them, in all sorts of weird site configurations, will be... challenging, to say the least. 2) Doing it at shutdown has problems of its own, including the incomplete switch crash scenario as well as having to do it late enough in the process that the operational-switch issues of #1 aren't triggered. The two problems above lead to the idea of not actually doing the change on a running system, but rather, simply using a trigger mechanism to trigger it at next boot. I didn't see it specifically stated what that would be, but at least here I envisioned it as comparable to the .fsck (whatever it's named) file dropped in root to trigger an fsck at the next boot, only in this case it would trigger the init-system switch. 3) Except... any switch has to occur VERY early in the boot process, before the existing init-system has already gotten us into the operational-switch situation of #1 that we were trying to avoid. Effectively, our switcher must be called as init either by the kernel itself or by the initr*, where it can do its thing before calling the normal init-system it might have just switched to. 3b) Except... at that point root isn't writable, and a robust solution to get it writable in ordered to actually make the switch permanent, that works on all the strange root-on-whatever systems out there, AND works with at least systemd and openrc and bb-init (with extensibility to others), AND inserts extremely minimal delay and code into the routine "no changes, just boot the same way you did last time" case, AND doesn't take control away from the individual init-system package maintainers, AND doesn't impose a huge burden on individual init-system package maintainers, AND fills ALL these requirements suitably robustly that it works well to say at least two-nines reliability... No wonder someone mentioned that it looked like a case for an initr*... but on gentoo anyway, requiring that has at least political problems of its own. It's beginning to look rather like a Sisyphean task... Which it might actually be. But it occurred to me that we actually do have a demonstrated workable and long used in actual practice exception to the normal boot case as precedent, where such maintenance tasks traditionally occur, single user mode. Then I began thinking how that fit the requirements and use case as outlined, including the (semi-?)automated bit. Which is how I came to post the idea of the sub-thread starter. Not to rehash everything I wrote there, but it seems to me to have the best chance at doing what is otherwise looking to be a Sisyphean task. With the extremely minimal two-case-only code inserted between kernel/initr* and the selected init-system at boot, it fills the quick and simple normal-case boot requirement. All the rest of the code is out of the way. The rest of the code then runs as a semi-automated single-user-mode equivalent. And having even that minimal normal-boot-mode insert under control of a USE flag allows people to get even that out of the way if they're not interested. Meanwhile, it's worth pointing out explicitly that by choosing this insertion point, root must already be at least mounted and accessible in read-only mode, whether by kernel command-line, initr*, or whatever, or the direct init invocation we're replacing wouldn't work. Thus, the whole issue of possibly initr* userspace or kernel commandline getting exotic root-on-whatever even mountable in the first place, is already taken care of, yet real-init hasn't yet executed, so we don't have to worry about messing with an already functioning init-system, thus leaving it no way to "climb down". 4) Finally, the fact that each init-system package gets to control its own switcher-mode script keeps control of it with the init-system package maintainers, allowing them to choose as complex or sim
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Tue, 28 May 2013 09:56:49 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > In part my post was to make it obvious that's really what we'll end > up doing if we want any sort of robustness at all. How much robustness do we really want? http://engineerblogs.org/2011/04/can-a-design-be-too-robust/ > Otherwise there's simply too much that can go wrong. You can't have too much go right, that's an unrealistic goal. > But assuming people DO insist on traveling that road, there's only > one way to do it robustly; thru some sort of single-user-mode by that > name or something else. Why reimplement something that exists? Can we reuse single user mode? Why do we need single user mode at all? If you're changing something as important as the init system, one should be prepared to have an system rescue medium available to correct the system if needed; although that is not necessarily needed if you use a wrapper with init=/sbin/einit as you can then just drop that kernel parameter and use the default again. > And if it's going to be done, let's quit wasting time on all the too > horribly brittle to think about if not simply broken methods that > I've seen discussed, A comparison between methods goes further than just calling the other methods broken; this doesn't make me see your method as better, but rather as just another method, perhaps even a broken method. > and get to it with something that really is proven to work, a > single-user-mode of some sort, with scripts to simplify the already > simple and potentially break those doing something complex, sure, but > if anything's going to work, that'd be it. And if even that can't be > made to work or is found not to be worth the hassle, well... You're making a lot of statements like this but don't back them up. Why would this work best for this situation? What's wrong with the rest? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
[gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
Walter Dnes posted on Mon, 27 May 2013 18:40:21 -0400 as excerpted: > What does this accomplish that could not be accomplished by... > * placing a switcher script in /sbin > * booting to single-user mode, and running the switcher script FWIW I agree with you. In part my post was to make it obvious that's really what we'll end up doing if we want any sort of robustness at all. Otherwise there's simply too much that can go wrong. But assuming people DO insist on traveling that road, there's only one way to do it robustly; thru some sort of single-user-mode by that name or something else. And if it's going to be done, let's quit wasting time on all the too horribly brittle to think about if not simply broken methods that I've seen discussed, and get to it with something that really is proven to work, a single-user-mode of some sort, with scripts to simplify the already simple and potentially break those doing something complex, sure, but if anything's going to work, that'd be it. And if even that can't be made to work or is found not to be worth the hassle, well... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
