1:17 p.m.
Is there any plan to replace sysvinit with a system like SMF (Service
Management Framework) in Solaris? Perhaps it is even possible to take SMF
as is and integrate it into fedora without building our own or resurrecting
DMD (http://directory.fsf.org/GNU/DMD.html) from the grave?
Cheers,
Shane
1:35 p.m.
On Saturday 15 October 2005 14:17, Shane Stixrud wrote:
Is there any plan to replace sysvinit with a system like SMF
(Service
Management Framework) in Solaris? Perhaps it is even possible to take SMF
as is and integrate it into fedora without building our own or resurrecting
DMD (http://directory.fsf.org/GNU/DMD.html) from the grave?
Why not just create something thats compatible with the Windows registry? ;)
We've been using 10 since it was in beta for several reasons and once you've
gotten past the "woohoo - new and shiny" phase, SMF is one of the worst
changes in Sol10.
The biggest issue with SMF is the state database. A single type on a service
file can corrupt your state database. So can interrupting a svcs command at
the wrong time. If that happens, good luck - you go back to the last saved
state and hope things still work. Of course if you installed software since
then you end up with a mess and...
Then the startup time gains are overrated... Log into your Sol10 box as soon
as its possible and run "format" - if your box survives that (some older ones
dont) then you'll see your format stall for a long time before you get your
output. In the end, if you measure the time from push of the power button
(assuming a reasonable diag level) to the time you logged in and got your
format output there is barely any difference between Sol9 and Sol10. Same
holds true for printing or a JES webserver request.
Other problems are that you're trading a well known, well debugged system
against something noone knows and that has virtually no tools to troubleshoot
at the moment. You also make it much harder for anyone to port software to
your Linux flavor.
SMF is in my opinion one of the biggest technical mistakes sun has made in the
recent history - would be a shame if Fedora followed such a bad example.
Peter.
1:49 p.m.
On Sat, 15 Oct 2005, Peter Arremann wrote:
The biggest issue with SMF is the state database. A single type on a service
file can corrupt your state database. So can interrupting a svcs command at
the wrong time. If that happens, good luck - you go back to the last saved
state and hope things still work. Of course if you installed software since
then you end up with a mess and...
Are you saying this is a fundamental problem with a SMF type management
framework or just a implementation detail in the current SMF system?
Then the startup time gains are overrated... Log into your Sol10 box as soon
as its possible and run "format" - if your box survives that (some older ones
dont) then you'll see your format stall for a long time before you get your
output. In the end, if you measure the time from push of the power button
(assuming a reasonable diag level) to the time you logged in and got your
format output there is barely any difference between Sol9 and Sol10. Same
holds true for printing or a JES webserver request.
I never found the startup time issue that big of a deal, it is a bigger
deal for desktops/hand helds than servers IMO. I am more fond of the
service monitoring/event features than I am how quick it is.
Other problems are that you're trading a well known, well debugged system
against something noone knows and that has virtually no tools to troubleshoot
at the moment. You also make it much harder for anyone to port software to
your Linux flavor.
This is true every time major change occurs, it is valid consideration
though.
Cheers,
Shane
2:02 p.m.
On Saturday 15 October 2005 14:49, Shane Stixrud wrote:
Are you saying this is a fundamental problem with a SMF type
management
framework or just a implementation detail in the current SMF system?
I'm
complaining about the current SMF implementation mostly. The porting will
always be an issue if you introduce new technology but if the reward is worth
it, it makes sense.
I never found the startup time issue that big of a deal, it is a
bigger
deal for desktops/hand helds than servers IMO. I am more fond of the
> service monitoring/event features than I am how quick it is.
And that only
works if your application supports it. And if you take only a
small section of the market the way sun is doing it, getting people to port
to the new setup is gonna be difficult.
> Other problems are that you're trading a well known, well
debugged system
> against something noone knows and that has virtually no tools to
> troubleshoot at the moment. You also make it much harder for anyone to
> port software to your Linux flavor.
This is true every time major change occurs, it is valid consideration
though.
That's why its important that what you're doing is really really
worth it
(like the SYSV package changes to support zones) and not something half baked
like SMF.
Peter.
4:50 p.m.
On Sat, 2005-10-15 at 11:17 -0700, Shane Stixrud wrote:
Is there any plan to replace sysvinit with a system like SMF (Service
Management Framework) in Solaris? Perhaps it is even possible to take SMF
as is and integrate it into fedora without building our own or resurrecting
DMD (http://directory.fsf.org/GNU/DMD.html) from the grave?
https://www.redhat.com/archives/fedora-devel-list/2005-June/msg01024.html
--
Ignacio Vazquez-Abrams <ivazquez(a)ivazquez.net>
http://fedora.ivazquez.net/
gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
5:44 p.m.
Shane Stixrud wrote:
Is there any plan to replace sysvinit with a system like SMF (Service
Management Framework) in Solaris? Perhaps it is even possible to take
SMF as is and integrate it into fedora without building our own or
resurrecting DMD (http://directory.fsf.org/GNU/DMD.html) from the grave?
There was a similar discussion before in this list. The consoldiated
form is http://fedoraproject.org/wiki/FCNewInit.
regards
Rahul
6769
days inactive
6769
days old
5 comments
4 participants
participants (4)
-
Ignacio Vazquez-Abrams -
Peter Arremann -
Rahul Sundaram -
Shane Stixrud