Bart Smaalders wrote: > Henry B. Hotz wrote: > > >> I find it really >> difficult to invest time in learning single-platform technologies. >> > > That makes it difficult to do innovation, since we need to convince > other OSes to use our technology before you will use it :-). > > So far we've succeeded w/ DTrace and ZFS; while many OS developers like SMF > because it solves a bunch of hard problems, many system admins have > complained loudly. > > Personally, I now hate dealing w/ pre-S10 systems, since i have to remember > how to enable/disable each sub-system separately... and I have to redo that > every time I update the OS on the box. > As more of an admin than a developer, I agree the centralized enable/disable of SMF is valuable. As are the log files you mention below. Some configurability in SMF is also useful, starting multiple instances of the same service for instance.
I think the my main complaint against SMF from a sysadmin point of view is the use of XML, but that's a totally different discussion. The point I think a previous poster was trying to make is that even if SMF is the greatest thing since indoor plumbing, the policy of trying to stuff every configuration detail of all the services into it, is not always a great idea. It dhould probably be done on a case by case basis. If a service like ssh needs a separate config file per instance, and has as many configuration options as ssh does, or if portable configuration has value for it, then maybe one of few SMF properties should just be the name of the config file for that instance. To me at least that gives the best compromise of innovation, and flexibility. -Kyle > W/ SMF, I always know where my log files are, how to do basic admin and > (above all), I can now log into my machine when the building yp servers > are completely > fubar'd. > > - Bart > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/smf-discuss/attachments/20080319/c67fed81/attachment.html>
