Shawn Walker wrote: > On 06/07/07, Dave Miner <[EMAIL PROTECTED]> wrote: >> Ian Murdock wrote: >> > Alberto Ruiz wrote: >> >> 2007/7/5, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> <[EMAIL PROTECTED] >> >> <mailto:[EMAIL PROTECTED]>>: >> >> SMF is not overkill for indiana. >> >> >> >> it might be overkill to instantiate quite the number of SMF >> services >> >> that >> >> a full-blown solaris installation does at first-boot, but SMF >> itself is >> >> incredibly useful. ;) >> >> >> >> I think that a lot of people find SMF frustrating because they think >> >> it's slow due to the prohibitive number of services that Solaris and >> >> Solaris Express boot by default. Maybe we should try to keep as >> less as >> >> possible services for Indiana? Does that makes sense? >> > >> > Is this something we should add to the list, i.e., investigate >> > the services started at boot time to determine which aren't >> > necessary and can be removed? I haven't noticed a problem >> > with speed here aside from the first boot (which does take an >> > inordinately long time--what on earth is it doing exactly?). >> > >> >> It's importing all of the xml service manifests from /var/svc/manifest >> into the SMF repository. The SMF team is working on performance >> improvements there, so you might follow up with them on the plans there >> and see if the community here can help accelerate it. I'd approach it >> that way, as limiting services usually means limiting functionality. >> The Secure-by-Default project took care of the low-hanging fruit here >> already, IMHO. >> >> Moinak and I have pretty well whittled down the live CD case already, >> which is the one place where it actually matters a lot how much you >> start at boot. > > Would it be possible for "standard" installations (i.e. non-custom) > that use a pre-defined installation profile to get a pre-built > manifest index installed instead of having to build one? > > I can understand why we would have to dynamically build one for custom > installs, but "standard ones" I would think we could build the index > ahead of time. >
You can (and we do exactly that in Live Media), but then you can run into flag day problems, where you need to build that repository with the same version of the OS, and it really clashes with all the stated desires here to have lots of flexibility in choosing functionality. CR 6351623 is the main one which covers manifest import speed. I suspect getting the fix Liane has suggested there implemented would cover this well enough for a while. Dave _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
