Re: [gentoo-dev] Re: openrc portage news item
On Sat, Apr 30, 2011 at 08:06:37AM -0500, Jeremy Olexa wrote: > This openrc upgrade is the *least* painful Gentoo upgrade I have > experienced. What a waste of time (IMO) to "script" some defaults. Basically answering my question- it wasn't considered since it ain't worth the time. Danke- consider it dropped. ~harring pgphnFvXUK6v9.pgp Description: PGP signature
Re: [gentoo-dev] Re: openrc portage news item
On 04/30/2011 07:58 AM, Brian Harring wrote: On Sat, Apr 30, 2011 at 08:03:43AM -0400, Rich Freeman wrote: Frankly getting fairly annoyed people are immediately taking it to the rhel/ubuntu extremes- that is *not* what I asked and is frankly a strawman argument. Occasional pain on upgrades is a given in gentoo, although anyone claiming we've not kept an eye on those sharp corners is delusional (versioned eapi, etc-update's very existance, portage warning on removal of a pkg in the system set, the list goes on). Hell, even the notification mechanism y'all want to use for informing is an example of trying to soften those corners were possible, rather than precluding their existance. I asked if we had looked at scripting away some of the upgrade pains. This openrc upgrade is the *least* painful Gentoo upgrade I have experienced. What a waste of time (IMO) to "script" some defaults. -Jeremy It's a pretty simple fucking question requiring either a 5 second "no" or 5 minutes of "yes, heres what we looked at, they were deemed too painful". Answering that also is a helluva lot quicker then people trading barbs over "we need to release it now" or proper SA; while your retort was dead on for what folks should do, it was completely unrelated to answering the question I'm *asking*. If we didn't look into it, that's fine. Means I've got something to poke at over the weekend. If we did, and it was ruled out, awesome, I have other things on my todo list I'll poke at this weekend. ~harring
Re: [gentoo-dev] Re: openrc portage news item
On Sat, Apr 30, 2011 at 08:03:43AM -0400, Rich Freeman wrote: Frankly getting fairly annoyed people are immediately taking it to the rhel/ubuntu extremes- that is *not* what I asked and is frankly a strawman argument. Occasional pain on upgrades is a given in gentoo, although anyone claiming we've not kept an eye on those sharp corners is delusional (versioned eapi, etc-update's very existance, portage warning on removal of a pkg in the system set, the list goes on). Hell, even the notification mechanism y'all want to use for informing is an example of trying to soften those corners were possible, rather than precluding their existance. I asked if we had looked at scripting away some of the upgrade pains. It's a pretty simple fucking question requiring either a 5 second "no" or 5 minutes of "yes, heres what we looked at, they were deemed too painful". Answering that also is a helluva lot quicker then people trading barbs over "we need to release it now" or proper SA; while your retort was dead on for what folks should do, it was completely unrelated to answering the question I'm *asking*. If we didn't look into it, that's fine. Means I've got something to poke at over the weekend. If we did, and it was ruled out, awesome, I have other things on my todo list I'll poke at this weekend. ~harring pgpABmwbRwHHD.pgp Description: PGP signature
Re: [gentoo-dev] Re: openrc portage news item
On Sat, Apr 30, 2011 at 7:46 AM, Brian Harring wrote: > A proper SA avoids upgrade pathways were possible that require > manual intervention. This requires manual intervention. > > Said proper SA's also have a rather large hatred of anything that can > leave a system nonbootable (rant: including crappy SA's who don't > verify the !@#*ing thing comes back up in a proper hot/warm state). > This qualifies for that. This will be far from the first Gentoo upgrade which has required either manual intervention, or which leaves the system in a potentially-unbootable state. Gentoo just generally doesn't offer the level of handholding that you are asking for. Users who want that kind of experience may be better off with RHEL or another platform. I think we need a reasonable balance here. From what I've seen the openrc upgrade seems pretty straightforward. The only caveat is that you need to read the instructions before doing it. Nervous users should burn rescue discs in advance. I think the important thing is to widely announce the upgrade. The maintainers intend to do exactly this. I have complained in the past when maintainers have made disruptive changes without notice, or with notice committed at the same time as the change (which means that if your emerge --sync is in a cron job you first hear about it AFTER running emerge -au world). This isn't being done here. I'm afraid that if we set the bar as high as you're proposing, then nobody will ever get around to providing an Ubuntu-like level of polish or whatever and we'll just end up with two baselayouts for the next five years. Keep in mind that ~arch having such major differences from stable defeats some of the purpose of testing. Sure, if somebody worked hard I'm sure they could meet your level of polish in a few weeks, but unless you're personally willing to do it I'm not sure that the maintainers are going to be willing - this is a volunteer organization so when you say "do it this way or don't do it at all" you're more likely to get the latter than the former. My feeling is that the openrc upgrade fragility is in keeping with the general traditions of Gentoo - we expect Gentoo users to be reasonably willing to get their hands dirty. I'm more concerned with making sure our users are INFORMED than hand-held. And as far as "proper SAs" go - a "proper SA" always deploys changes on a production-equivalent test environment anyway. Most "proper SAs" also make backups and VM snapshots so that a borked upgrade is just a bump in the road. "Proper SAs" also run on managed hardware so that they can boot off of a rescue disc without being physically present. Most of these "Proper SAs" also run RHEL anyway. :) Rich
Re: [gentoo-dev] Re: openrc portage news item
On Sat, Apr 30, 2011 at 07:13:59AM +, Duncan wrote: > Brian Harring posted on Fri, 29 Apr 2011 21:59:45 -0700 as excerpted: > > > Checking the boot levels, udev included, same thing- if ROOT=/ and > > baselayout is there already you likely *could* look at the running > > system to see what's needed/in use, and kick rc-update as needed for > > spots where it *isn't*. > > Um... 32-bit chroots for amd64 comes to mind, tho that's just a single > supported case of the general idea. Here, I've adapted the idea slightly > by simply installing a complete system to the chroot, just never actually > /running/ it from there, as a maintained system image that was initially > transferred to USB, now updated thru rsync, for my netbook. What I'm suggesting is mangling the default configs that get pushed in via postinst to reflect the old configs for the spots where it's necessary. The 32bit/64bit scenario there still is addressable- scan the pre-existing rc-update show. If you're just chroot'ing into the sucker without kicking any services within it, you're unaffected either way if it rc-update's a couple of services- you weren't starting the services in the /first/ place after all, so no further fall out. If you were starting services, udev for example, spotting that and transferring it across isn't hard. It's actually slightly more complex than that to track the settings from setup through postinst, but that's implementation details, secondary issue to my original question. > Portage's ROOT is unchanged in these cases, but depending on how the > detection of the running system is achieved, the script might attempt > changes based on the components of the 64-bit HOST system, not the 32-bit > chroot system image, or conversely, changes inappropriate for an image > that never actually boots on its host system. That would *NOT* be a good > thing! Already outlined above how this interpretation is incorrect. It's basically identification of scenarios- your posited (presumably what you run locally since you seem fairly heated about it) scenario looks like it still would fly due to pre-existing configuration being referencable- or you weren't actually configuring it in full, nor running the services from w/in it, so it's a non issue anyways. Either way, I did not say it was necessarily simple; I'm fundamentally asking why those potentials, from the rough look of it, were ruled out. If they were considered, then it should be reasonably easy to point folks at bugs/discussions clarifying why it wasn't considered viable. 32bit chroot is one example of where it might be dicey, although frankly I still consider that deployment a bit whacked on it's own. I'm looking for more than just that however > Meanwhile, all this is a rather nice idea in theory, but with literally > days left before pulling the trigger, now's rather late in the game to > bring the suggestion. It's an arbitrary deadline. To be clear, it's an arbitrary deadline that has a horrid ass set of "do these things or your system is fubared", plus that pkg_pretend frankly is a different form of horrible beyond that. While late in the game, frankly it just came to the attention- I've ran openrc basically since day 1. It crossed the radar only recently due to the desired announcement requesting feedback- which means feedback on the change itself, fundamentally. Regardless, what you're offering up here is deflections/excuses to just do it. Which... frankly, that's fine. If that's peoples decision in full, fine, they own that decision. If the potentials weren't explored, it would be useful *knowing* so looking at reducing the pain can be done- if they *were* explored and discarded, then it saves folks the time of digging into it further. Simple enough. > Are you actually trying to delay the upgrade to OpenRC /forever/? Why? Chill the hell down. I didn't kick your puppy, nor did I steal your lunch money in 7th grade. I may have mocked your 'flock of seagulls' haircut (or 'bieber' haircut for the younguns), but they're stupid haircuts- it was deserved ;) Joke aside, I asked a valid question. Rhetorical nonsense isn't a valid response, nor useful. > Meanwhile, Gentoo has always been about expecting Gentoo's users to take > responsibility as their own sysadmins. Yes, we document, and automate > where reasonably possible, but there's a reason for etc-update, dispatch- > conf, etc. While that's a fun quotation to use, you basically just aligned with exactly why I'm asking this. Yes, users must function as the sysadmin/SA of their system. A proper SA avoids upgrade pathways were possible that require manual intervention. This requires manual intervention. Said proper SA's also have a rather large hatred of anything that can leave a system nonbootable (rant: including crappy SA's who don't verify the !@#*ing thing comes back up in a proper hot/warm state). This qualifies for that.
[gentoo-dev] Re: openrc portage news item
Brian Harring posted on Fri, 29 Apr 2011 21:59:45 -0700 as excerpted: > Checking the boot levels, udev included, same thing- if ROOT=/ and > baselayout is there already you likely *could* look at the running > system to see what's needed/in use, and kick rc-update as needed for > spots where it *isn't*. Um... 32-bit chroots for amd64 comes to mind, tho that's just a single supported case of the general idea. Here, I've adapted the idea slightly by simply installing a complete system to the chroot, just never actually /running/ it from there, as a maintained system image that was initially transferred to USB, now updated thru rsync, for my netbook. Portage's ROOT is unchanged in these cases, but depending on how the detection of the running system is achieved, the script might attempt changes based on the components of the 64-bit HOST system, not the 32-bit chroot system image, or conversely, changes inappropriate for an image that never actually boots on its host system. That would *NOT* be a good thing! So any such detection would have to be based on far more than the setting for ROOT and existence of baselayout. Meanwhile, all this is a rather nice idea in theory, but with literally days left before pulling the trigger, now's rather late in the game to bring the suggestion. Development and proper testing of such a script would certainly take months, at least. This whole idea, suggested now, seems to me to be a rather advanced case of letting the perfect be the enemy of the far better but nobody claiming perfect. The time for such a suggestion would have been several months ago when the final push toward stabilization and development of the final migration technique was announced. And certainly, trying to shove the required development and testing into anything less something like six more months reasonable minimum, is folly indeed. Meanwhile, existing stable gets further and further behind and harder to maintain, and Gentoo looks more and more "legacy". Are you actually trying to delay the upgrade to OpenRC /forever/? Why? There's other questions I could ask but there ARE things worse than unasked questions. I'm seriously fighting the urge to go there as that bit of list history is something that doesn't need repeated, for sure. Meanwhile, Gentoo has always been about expecting Gentoo's users to take responsibility as their own sysadmins. Yes, we document, and automate where reasonably possible, but there's a reason for etc-update, dispatch- conf, etc. This is as good a case for letting Gentoo users take ultimate responsibility as admins on their own systems as it gets. We've waited long enough. The guides are ready. The systems are ready. The warnings are ready. Now it's time to pull that trigger. -- 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
[gentoo-dev] Re: openrc portage news item
William Hubbs posted on Fri, 29 Apr 2011 02:08:31 -0500 as excerpted: > Also, the way you can recover if you boot your system before following > the steps is mentioned in the news item now, and there's not really > anything more to it, so I'm not sure where else it should be mentioned. > > What does everyone think? This one looks very reasonable, to me. The bases are all covered including the level of criticality, what to do to recover if it becomes necessary, and links for migration and further information. Thanks again for your work on this. =:^) -- 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
[gentoo-dev] Re: openrc portage news item
Peter Hjalmarsson posted on Fri, 15 Apr 2011 16:04:09 +0200 as excerpted: > [parallel boot] feature is still not really perfect, at least not > perfect enought. Use squid on a system where it takes longer for its > daemon to exist (like my router, where the media is a intel SSD, > 4GB memory and a AMD Athlon 2x on the AM3 socket) and you will see > lots of outputs from openrc about all those scripts waiting for it > to end... If you're talking about the 50...40... etc wait if something takes longer than 10 seconds (I get it here on startup with ntp-client), I'd argue that's demonstration of the feature's maturity. What can start/stop does. Other things wait, with a (configurable) timeout until their dependency comes up (or goes down, at shutdown). If the wait is more than 10 seconds, the system tells you what is going on. That's as designed and IMO a good thing. What's broken about it? > So maybe when that feature is ready to be enabled by default? I believe it's ready for everyone to give a try. If it doesn't work or they prefer the more ordered output of a serial boot, despite the longer wait time, fine, but it'll work for most, with possible tweaking of the the timeout, the services that don't timeout at all (fscks, by default), or fine dependency ordering, if necessary. To have the system take far longer to POST than from end of POST to waiting for me to login (despite the idle-wait for ntp-client), is very nice indeed. =:^) -- 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
[gentoo-dev] Re: openrc portage news item
tor 2011-04-14 klockan 08:09 + skrev Duncan: > 1) While baselayout-1 had a parallel boot option, it was quite broken and > (partly or entirely, not sure which) non-functional. The same thing in > baselayout-2/openrc works WELL and I use it all the time. (Given the > emphasis placed on this in the media, the various boot-timing contests, > etc, and the fact that this feature puts Gentoo in-play again in regard to > speed-boots, it's a pretty big positive in favor of upgrading.) > This feature is still not really perfect, at least not perfect enought. Use squid on a system where it takes longer for its daemon to exist (like my router, where the media is a intel SSD, 4GB memory and a AMD Athlon 2x on the AM3 socket) and you will see lots of outputs from openrc about all those scripts waiting for it to end... So maybe when that feature is ready to be enabled by default? Regards Peter Hjalmarsson
Re: [gentoo-dev] Re: openrc portage news item
Hi Matt, On Thu, Apr 14, 2011 at 10:41:23AM -0500, Matthew Summers wrote: > 1. We should determine and then announce the precise date (appears to > be in May) and time that baselayout-2 will be stabilized via: > 1.1 A front page News item on www.g.o (PR team assemble!), > 1.2 The main MLs (gentoo-announce, gentoo-users, etc), > 1.3 Add a link to the www news item to /topic in #gentoo, and > 1.4 Post a sticky topic in the Forum. > all in addition to the eselect news item under discussion here. The > above would link to the migration guide too. The problem is that the date is still subject to change. If we get more bugs that we think should block stabilization, those would be fixed, then a new release put out, then we are back to waiting 30 days unless we make an exception to the 30 day rule. > 2. We should prepare a quick "recover-your-system" guide (could also > create a script too) that can be quickly linked to for user support. > This will save time for people providing support via IRC, email, etc, > and give people a reasonable means of system recovery without huge > pain. As far as I know, the only thing that can go wrong here is rebooting after installing bl2/openrc without following the migration guide. If you do that, the only thing you can do is boot a live cd, chroot into the system and follow the migration guide from there. There's not really a way I know of that we could write a script to do that. > 3. Update the handbook to reflect these changes as soon as possible, > and have that all go public simultaneously with the stabilization. There is a bug that is blocked by the tracker for this. > 4. I have attached an edited and unfinished version of the original > news item for review. I attempted to be succinct. Ok, I took your news item, and I'll look it over. I may add more to it about what will happen if you do not follow the migration guide. pgphF1gkzJGmd.pgp Description: PGP signature
Re: [gentoo-dev] Re: openrc portage news item
Matthew Summers wrote: Hi, I have a few suggestions regarding this major change to Gentoo systems. 1. We should determine and then announce the precise date (appears to be in May) and time that baselayout-2 will be stabilized via: 1.1 A front page News item on www.g.o (PR team assemble!), 1.2 The main MLs (gentoo-announce, gentoo-users, etc), 1.3 Add a link to the www news item to /topic in #gentoo, and 1.4 Post a sticky topic in the Forum. all in addition to the eselect news item under discussion here. The above would link to the migration guide too. The rationale for this effort at getting the word out is to prevent users from hosing their system(s). While I tend to agree that users should read these eselect news items, its often not the case. Therefore I recommend shooting for the widest possible distribution of this information. Also, this gives PR a chance to let the world know about openrc and its benefits to Gentoo. 2. We should prepare a quick "recover-your-system" guide (could also create a script too) that can be quickly linked to for user support. This will save time for people providing support via IRC, email, etc, and give people a reasonable means of system recovery without huge pain. 3. Update the handbook to reflect these changes as soon as possible, and have that all go public simultaneously with the stabilization. 4. I have attached an edited and unfinished version of the original news item for review. I attempted to be succinct. This is a really exciting and potentially also rather anxiety-provoking change for our user base and Gentoo. We all know that the new baselayout is awesome, and users will find out soon enough. We simply need to make our best effort at easing the transition so we minimize the number of casualties. Thank you, Matt I wouldn't mind seeing this on the main Gentoo page as soon as possible. Some people may not visit the Gentoo page very often, I'm one of those. This could be done even if it has to be changed as things update. Maybe one that it is coming and one a few days before it hits stable in the tree. +1 on this being a good idea. This is a really important update since it can cause a system to be unbootable. I'm thinking about folks that may admin a box remotely too. If all the above is done and people miss that it is coming, I think it could safely be said that everything that could be done was done to inform people. The list above includes about every means of communication Gentoo has. Great post. Dale :-) :-)
Re: [gentoo-dev] Re: openrc portage news item
Hi, I have a few suggestions regarding this major change to Gentoo systems. 1. We should determine and then announce the precise date (appears to be in May) and time that baselayout-2 will be stabilized via: 1.1 A front page News item on www.g.o (PR team assemble!), 1.2 The main MLs (gentoo-announce, gentoo-users, etc), 1.3 Add a link to the www news item to /topic in #gentoo, and 1.4 Post a sticky topic in the Forum. all in addition to the eselect news item under discussion here. The above would link to the migration guide too. The rationale for this effort at getting the word out is to prevent users from hosing their system(s). While I tend to agree that users should read these eselect news items, its often not the case. Therefore I recommend shooting for the widest possible distribution of this information. Also, this gives PR a chance to let the world know about openrc and its benefits to Gentoo. 2. We should prepare a quick "recover-your-system" guide (could also create a script too) that can be quickly linked to for user support. This will save time for people providing support via IRC, email, etc, and give people a reasonable means of system recovery without huge pain. 3. Update the handbook to reflect these changes as soon as possible, and have that all go public simultaneously with the stabilization. 4. I have attached an edited and unfinished version of the original news item for review. I attempted to be succinct. This is a really exciting and potentially also rather anxiety-provoking change for our user base and Gentoo. We all know that the new baselayout is awesome, and users will find out soon enough. We simply need to make our best effort at easing the transition so we minimize the number of casualties. Thank you, Matt -- Matthew W. Summers Title: Baselayout update Author: Christian Faulhammer Author: William Hubbs Content-Type: text/plain Posted: 2011-05-01 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: http://www.gentoo.org/doc/en/openrc-migration.xml FAILURE TO FOLLOW THE MIGRATION GUIDE CAN RESULT IN AN UNBOOTABLE SYSTEM! For more information or supprt regarding this change please see the following: - link to news item (should contain info regarding where to obtain support) - link to recover-system guide - link to handbook
Re: [gentoo-dev] Re: openrc portage news item
Duncan wrote: > From my read, while it does actually say it's important, the politeness with which it does so don't well convey the true importance and urgency of the situation. If there's a fire, you don't say "Please, excuse me for interrupting, but there's a fire and at your convenience, please make your way to the exit." Rather, it's "*FIRE*! Please STAY CALM. WALK DON'T RUN. The exit is OVER THERE. Make your way to it IMMEDIATELY!" So more along the lines of: """ After installing these packages, please DO NOT REBOOT until you follow the upgrade guide located at http://www.gentoo.org/doc/en/openrc-migration.xml. If you do not follow the guide as soon as possible after these packages are upgraded and you reboot or crash without doing so, the system will likely fail to boot properly, and you may be looking at some time in manual recovery mode to fix it. """ Yes, the DO NOT REBOOT is shouting, not exactly polite, but that's arguably what's called for in this situation. Plus having it in all caps makes it stand out. If a person even looks at the message, they will see that at least. Then hopefully, they will read the rest. I think bold would be nice to tho. It's not like this is not really really important. Even with that, I see a few people not even noticing it and the next reboot going badly. Dale :-) :-)
Re: [gentoo-dev] Re: openrc portage news item
On Thu, Apr 14, 2011 at 4:09 AM, Duncan <1i5t5.dun...@cox.net> wrote: > FWIW/IMHO, I don't believe the news item needs mentioning that it was bash > that made it slow and inflexible. Most users don't so much care whether > it's C or bash or java that made it so, only that it was. If this were Ubuntu I'd be inclined to agree. However, I think that most Gentoo users would be interested. Maybe I have a different perspective because I just gave a talk on booting two nights ago at an LUG, but I wasn't even the one to bring up the shortcomings of bash in the typical linux SysVInit-based service scripts. Various approaches that were discussed included symlinking /bin/sh to dash instead of bash, and C-based solutions (or a combination of both). It was interesting to hear that at least a few other distros struggle with bashisms in their init scripts, but no so much due to licensing/BSD issues but because of a desire to use dash which does not support all bashisms. No need to go into gory details, but mentioning that it is C-based instead of bash-based seems reasonable. Granted, we're not really getting rid of one of the problems with bash, which isn't just /sbin/rc but rather it includes the init scripts themselves (every one of which requires spawning a new bash, and many spawn additional processes like sed/awk/etc). Rich
[gentoo-dev] Re: openrc portage news item
Dirkjan Ochtman posted on Thu, 14 Apr 2011 09:21:48 +0200 as excerpted: > On Thu, Apr 14, 2011 at 07:30, justin wrote: >> To me, it doesn't makes it totally clear that you screw everything when >> rebooting before following the guide. Perhaps this should be made much >> clearer. > > Huh? > > "After you install these packages, please do not reboot your system > until you follow the upgrade guide located at > http://www.gentoo.org/doc/en/openrc-migration.xml. > > It is important that you follow the guide as soon as possible after > these packages are upgraded. Otherwise, there is a chance that your > system will not reboot properly." > > Seem quite clear to me. >From my read, while it does actually say it's important, the politeness with which it does so don't well convey the true importance and urgency of the situation. If there's a fire, you don't say "Please, excuse me for interrupting, but there's a fire and at your convenience, please make your way to the exit." Rather, it's "*FIRE*! Please STAY CALM. WALK DON'T RUN. The exit is OVER THERE. Make your way to it IMMEDIATELY!" So more along the lines of: """ After installing these packages, please DO NOT REBOOT until you follow the upgrade guide located at http://www.gentoo.org/doc/en/openrc-migration.xml. If you do not follow the guide as soon as possible after these packages are upgraded and you reboot or crash without doing so, the system will likely fail to boot properly, and you may be looking at some time in manual recovery mode to fix it. """ Yes, the DO NOT REBOOT is shouting, not exactly polite, but that's arguably what's called for in this situation. -- 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
[gentoo-dev] Re: openrc portage news item
William Hubbs posted on Wed, 13 Apr 2011 14:58:51 -0500 as excerpted: > On Wed, Apr 13, 2011 at 08:41:16PM +0200, "Pawe?? Hajdan, Jr." wrote: >> On 4/13/11 8:15 PM, William Hubbs wrote: >> > The baselayout package provides files which all systems must have in >> > order to function properly. You are currently using version 1.x, >> > which has several issues. The most significant of these is that the >> > included init system is written entirely in bash, which makes it slow >> > and not very flexable. >> >> I think it would be worth it to mention other problems too (just a list >> of most important bugs if that makes sense). > > Does anyone on the list have any particular suggestions for what should > be mentioned? The definition of "important" might vary per person, but, while it has been awhile since I ran baselayout-1, here's what I recall that I'd consider significant. 1) While baselayout-1 had a parallel boot option, it was quite broken and (partly or entirely, not sure which) non-functional. The same thing in baselayout-2/openrc works WELL and I use it all the time. (Given the emphasis placed on this in the media, the various boot-timing contests, etc, and the fact that this feature puts Gentoo in-play again in regard to speed-boots, it's a pretty big positive in favor of upgrading.) 2) In baselayout-1, the early-boot wasn't actually dependency based, but rather, was strict-serial-order based on a list of IIRC four services started in the exact order they were listed. (clock or whatever the baselayout-1 name was, was one of them, IDR the others). OpenRC/ baselayout-2 is fully dependency based at every stage. I mentioned both of these points earlier in a different context. FWIW/IMHO, I don't believe the news item needs mentioning that it was bash that made it slow and inflexible. Most users don't so much care whether it's C or bash or java that made it so, only that it was. I'd personally put more emphasis on the /how/ instead of the /why/, as I believe that's what most users want to know. The above two points support that, thus, reworking that whole bit: """ You are currently using version 1.x, which was slow and inflexible. It was slow in part because the parallel boot option was broken, and inflexible in part because dependencies didn't work until later in the boot process, so the first few services had to be started in order according to an arbitrary list. """ No mention of bash as a reason because that's an internal implementation deal I as an admin don't want or need to care about. What difference will it make in the way my system boots and how will that be better, that's what I as an admin want to know. (That said, the above can surely be improved as well. The ideas conveyed are better I believe, more direct to what a Gentoo user/admin will likely want to know, but I'm my wording isn't right, yet.) -- 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
