Casper.Dik at Sun.COM wrote: > Unfortunately, the "few disadvantages" are, IMHO, show stoppers. > (the ability to hide all sorts of malware, for one, lack of natural change > control, etc)
Like you can't hide malware in all of the scripts and config files scattered throughout the system that are the equivalent in a typical UNIX system? The reason there's more malware on Windows is that there are many more systems and the users are less savvy, so creating malware is more interesting and profitable. Everybody else is safer because they don't have a big target painted on their back. Like there's any sane way to do system-wide configuration control with a typical UNIX system? (Yes, a savvy administrator can track down every single config file in the system and manually put it under change control, but that doesn't sound like a realistic answer.) Windows automatically backs up the system configuration every day and at every software install, I believe. I think it'll automatically fall back to a previous known working configuration in many boot failure cases. Is such a thing even conceivable with a traditional UNIX administration model? Putting all of the system configuration in one place _enables_ configuration control. > (Ask AIX users, for one, and I think the Windows registry giving > rise to a whole cottage industry of "fix registry" software is > telling. Like there isn't a cottage industry of "fix UNIX config files" software? Sure, there aren't as many commercial tools, but that's at least partially because of audience (UNIX users tend to hack their own and tend to use more freeware) and partially because of market size (100x as many users makes for a lot more incentive to create a product). There's also the fact that when you have an audience that isn't savvy, it's easier to sell snake oil. How many tools to hack UNIX config files have you personally written? > 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) Yes. There needs to be hierarchy and progressive disclosure and blah blah blah. But at least there's _some_ structure, where previously there was _none_. I expect that it wouldn't be hard to layer on a "service groups" mechanism to get some of that. There also needs to be a GUI with "enable" checkboxes and links to explanations of each service and to pages that let you tweak its parameters. (Again, with progressive disclosure so that you normally only see the parameters that you probably _want_ to tweak.) >>> 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 know, that's why I said "personally" and proceeded to discuss the situation assuming that they can be different. Again, *personally* I think that the simplicity of the "it's like a light switch" model outweighs the flexibility of allowing for variation, but I understand that others disagree. We ought to be working towards a model where reboots never happen, making the question moot. >> 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. Industry experience suggests that it is not possible to get *anything* right the first time. I hope that's not a reason for never doing anything new. > 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) I can't say that I've encountered that particular problem, but it doesn't surprise me. Getting upgrades right is pretty hard, and doesn't get nearly enough attention. File CRs. ... and is it worse under SMF, or under traditional models? If you delete somebody's rc*.d file it kills them for now, but is almost certainly undone on upgrade.
