Hi, >>The Registry model is NOT one to aspire to.
I think that Solaris is going the wrong way with SMF. SMF as replacement for the init scripts is okay - but I don't think it's a good idea to replace existing config files with SMF properties. This breaks mostly all existing environments for installing, configuring, and maintaining Solaris machines (because they rely on the existing config files). And it makes adminstration more difficult for long time Solaris admins. In the old days, before Solaris 10, I used to know in which config files I've to look if there's an error. Now it depends on the Release of Solaris that is running on a machine where to look for config options. And IMHO it does not make sense to have a unique repository for the configuration of the OS. There are too much diffcult configurations to save them all in one repository. And if the repository dies all configurations are gone... I still don't understand why Sun is going here the "Windows Way" -- Windows has already prooven that this is the wrong way. Only my 2 cents Bernd Casper.Dik at Sun.COM wrote: >> Casper.Dik at sun.com wrote: >> >>> The Registry model is NOT one to aspire to. >>> >> I have to just completely disagree there. I think there are numerous >> advantages to such a model, and very few disadvantages. >> > > Unfortunately, the "few disadvantages" are, IMHO, show stoppers. > (the ability to hide all sorts of malware, for one, lack of natural change > control, etc) > > (Ask AIX users, for one, and I think the Windows registry giving > rise to a whole cottage industry of "fix registry" software is > telling. > > Also, I am getting a but tired of "everything as a service"; "svcs" > output now average over 100 lines and "svcs -a" lists 250. > > There's a ton to improve in data presentation (and, in particular, > data hiding) > > (I'm meaning to file an RFE for a more meaningful STIME column) > > >>> For one I strongly dislike the fact that I never have an idea >>> what is the current property and which would be the property value >>> on boot; clearly they are different at times. >>> >> First, I'd personally say that they should _not_ be different. >> > > I'm not sure I agree on that. I want to be able to disable a service > and then make sure it runs at boot (in fact, I'd like to be able > to "enable at next boot") too. > > > >> I have no opinion on its fragility and agree that it must _not_ be fragile. >> >> I see no technical reason that it must be fragile. >> > > Industry experience seem to suggest that it is not possible to get right the > first time. > > That, I think, is a technical reason. "beyond the state of the art of > software engineering". > > Sad, but true. > > I don't know enough of SMF and don't have spare cycles to go and figure > out which it decides that the database is not correct. > > I very much like the fact that SMF allows me to disable a service once and > for all; it's too bad that some services conspire to remove that big > advantage by reenabling themselves each upgrade (webconsole) > > > Casper > > _______________________________________________ > smf-discuss mailing list > smf-discuss at opensolaris.org > > -- Bernd Schemmer, Frankfurt am Main, Germany http://home.arcor.de/bnsmb/index.html M s temprano que tarde el mundo cambiar . Fidel Castro
