Hi,
Seth posted more about his SystemServices thing (skip the 80s music paragraph).
http://www.gnome.org/~seth/blog/2003/Sep/27
Havoc
On Sun, 2003-09-28 at 20:31, Havoc Pennington wrote:
Seth posted more about his SystemServices thing (skip the 80s music paragraph). http://www.gnome.org/~seth/blog/2003/Sep/27
Aside from more flexible startup notification of services during boot, does anyone know what other advantages this architecture provides?
Certainly doing something as drastic as replacing init can't be justified by the end goal of having a graphical booting, so I'm quite keen to hear some other other benefits of SystemServices or the deficiencies of init/initscripts SystemServices will address.
Cheers, Jason.
On Sun, 28 Sep 2003, Jason Tackaberry wrote:
On Sun, 2003-09-28 at 20:31, Havoc Pennington wrote:
Seth posted more about his SystemServices thing (skip the 80s music paragraph). http://www.gnome.org/~seth/blog/2003/Sep/27
Aside from more flexible startup notification of services during boot, does anyone know what other advantages this architecture provides?
Certainly doing something as drastic as replacing init can't be justified by the end goal of having a graphical booting, so I'm quite keen to hear some other other benefits of SystemServices or the deficiencies of init/initscripts SystemServices will address.
Just my own two cents:
* Boot time, the time before you get a login screen is pretty long in initscripts model.
* No way to define different profiles, for example, one for HTTP serving, one as a workstation.
* Silly dependency handling, by putting services in a total order, so they can't be run in parallel.
Cheers, Jason.
On Sun, 28 Sep 2003, Behdad Esfahbod wrote:
- No way to define different profiles, for example, one
for HTTP serving, one as a workstation.
For us, profiles would be *extremely* handy for laptops. Red Hat has the networking profiles infrastructure largely plumbed, but afaict there's no good way to specify a profile at boot time.
--Paul Heinlein heinlein@madboa.com
On Mon, 29 Sep 2003, Paul Heinlein wrote:
On Sun, 28 Sep 2003, Behdad Esfahbod wrote:
- No way to define different profiles, for example, one
for HTTP serving, one as a workstation.
For us, profiles would be *extremely* handy for laptops. Red Hat has the networking profiles infrastructure largely plumbed, but afaict there's no good way to specify a profile at boot time.
I have seen the net profiles in rh. It just means 10 lines of shell script in rc.sysinit. I have my own profile support on my laptop.
--Paul Heinlein heinlein@madboa.com
On Mon, 29 Sep 2003, Paul Heinlein wrote:
On Sun, 28 Sep 2003, Behdad Esfahbod wrote:
- No way to define different profiles, for example, one
for HTTP serving, one as a workstation.
For us, profiles would be *extremely* handy for laptops. Red Hat has the networking profiles infrastructure largely plumbed, but afaict there's no good way to specify a profile at boot time.
Is appending
netprofile=profile_name
to your kernel line in your boot loader not what you need?
later, chris
Havoc Pennington (hp@redhat.com) said:
Seth posted more about his SystemServices thing (skip the 80s music paragraph).
15 seconds from the kernel starting to load to having GDM up and log-in able. With rearchitecting everything in python. Good luck. :)
Bill
On Sun, 2003-09-28 at 22:52, Bill Nottingham wrote:
Havoc Pennington (hp@redhat.com) said:
Seth posted more about his SystemServices thing (skip the 80s music paragraph).
15 seconds from the kernel starting to load to having GDM up and log-in able. With rearchitecting everything in python. Good luck. :)
Bill
Sounds sorta improbable, doesn't it? On the other hand, it could be cool if he pulls it off.
I still need some way to get the machine to single user mode. Whether that's a run level or a service state is immaterial. Getting there is what matters, both from multiuser and a cold start, of course.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
On Mon, 29 Sep 2003, Bill Nottingham wrote:
Havoc Pennington (hp@redhat.com) said:
Seth posted more about his SystemServices thing (skip the 80s music paragraph).
15 seconds from the kernel starting to load to having GDM up and log-in able. With rearchitecting everything in python. Good luck. :)
Oh, Python. It may not be easy as now to hack the new system then.
Bill
Le lun 29/09/2003 à 02:31, Havoc Pennington a écrit :
Hi,
Seth posted more about his SystemServices thing (skip the 80s music paragraph).
It's nice but it won't fly with java daemons for example. Java people do not care nor want to know about system stuff. You'll always need a shell wrapper to launch the jvm for example (well people may use gcj one day but you get the point), change system users and so on.
I like the general idea but the "shell scripts wrappers are never needed" assumption makes be a bit uncomfortable.
Cheers,
On Mon, 2003-09-29 at 08:09, Nicolas Mailhot wrote:
I like the general idea but the "shell scripts wrappers are never needed" assumption makes be a bit uncomfortable.
With any new system you'd need a "run legacy init scripts" feature if only for LSB compliance, so I think there's an answer here.
Havoc
Le lun 29/09/2003 à 17:55, Havoc Pennington a écrit :
On Mon, 2003-09-29 at 08:09, Nicolas Mailhot wrote:
I like the general idea but the "shell scripts wrappers are never needed" assumption makes be a bit uncomfortable.
With any new system you'd need a "run legacy init scripts" feature if only for LSB compliance, so I think there's an answer here.
Sure. But java is not really legacy and I don't see how we can ever get rid of the shell system adaptation layer for java apps (gcj may one day be an answer, but will all bytecode java apps be ever replaced by natively build ones ?). Even c++ apps like moz often start via a shell script. I'd felt better about this new system if it catered to the needs of shell wrappers (other than putting them in a legacy bin).
Regards,
On Mon, 2003-09-29 at 12:09, Nicolas Mailhot wrote:
Sure. But java is not really legacy and I don't see how we can ever get rid of the shell system adaptation layer for java apps (gcj may one day be an answer, but will all bytecode java apps be ever replaced by natively build ones ?). Even c++ apps like moz often start via a shell script. I'd felt better about this new system if it catered to the needs of shell wrappers (other than putting them in a legacy bin).
You're just talking terminology I think. If it runs LSB init scripts, maybe with extensions to do any additional stuff RH init scripts currently allow, then what other catering do you want? There's no way we'd ever be able to remove this support, so perhaps "legacy" is the wrong word. "Classic" ;-)
Of course there are tons of issues and I'm as skeptical as anyone, but we should keep an open mind and encourage people to try to improve the boot process.
Using D-BUS is an interesting experiment; it does potentially offer a more robust approach to locking than pid files, and a method for doing dependencies and parallel service launching. On the other hand, there are possible problems.
Havoc
Le lun 29/09/2003 à 19:19, Havoc Pennington a écrit :
On Mon, 2003-09-29 at 12:09, Nicolas Mailhot wrote:
Sure. But java is not really legacy and I don't see how we can ever get rid of the shell system adaptation layer for java apps (gcj may one day be an answer, but will all bytecode java apps be ever replaced by natively build ones ?). Even c++ apps like moz often start via a shell script. I'd felt better about this new system if it catered to the needs of shell wrappers (other than putting them in a legacy bin).
You're just talking terminology I think. If it runs LSB init scripts, maybe with extensions to do any additional stuff RH init scripts currently allow, then what other catering do you want? There's no way we'd ever be able to remove this support, so perhaps "legacy" is the wrong word. "Classic" ;-)
Well, as long as wrappers are supported normally you can call it whatever you want;). I was afraid legacy = bitrot haven.
Cheers,
-
Behdad Esfahbod -
Bill Nottingham -
Chris Ricker -
Havoc Pennington -
Howard Owen -
Jason Tackaberry -
Nicolas Mailhot -
Paul Heinlein