7:31 p.m.
Hi,
Seth posted more about his SystemServices thing (skip the 80s music
paragraph).
http://www.gnome.org/~seth/blog/2003/Sep/27
Havoc
8:39 p.m.
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.
9 p.m.
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.
10:31 a.m.
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(a)madboa.com>
10:37 a.m.
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(a)madboa.com>
10:38 a.m.
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
12:52 a.m.
Havoc Pennington (hp(a)redhat.com) said:
Seth posted more about his SystemServices thing (skip the 80s music
paragraph).
http://www.gnome.org/~seth/blog/2003/Sep/27
15 seconds from the kernel starting to load to having GDM up and
log-in able. With rearchitecting everything in python. Good luck. :)
Bill
1:10 a.m.
On Sun, 2003-09-28 at 22:52, Bill Nottingham wrote:
Havoc Pennington (hp(a)redhat.com) said:
> Seth posted more about his SystemServices thing (skip the 80s music
> paragraph).
>
> http://www.gnome.org/~seth/blog/2003/Sep/27
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(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Howard Owen "Even if you are on the right
EGBOK Consultants track, you'll get run over if you
hbo(a)egbok.com +1-650-339-5733 just sit there." - Will Rogers
9:53 a.m.
On Mon, 29 Sep 2003, Bill Nottingham wrote:
Havoc Pennington (hp(a)redhat.com) said:
> Seth posted more about his SystemServices thing (skip the 80s music
> paragraph).
>
> http://www.gnome.org/~seth/blog/2003/Sep/27
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
7:09 a.m.
Le lun 29/09/2003 à 02:31, Havoc Pennington a écrit :
Hi,
Seth posted more about his SystemServices thing (skip the 80s music
paragraph).
http://www.gnome.org/~seth/blog/2003/Sep/27
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,
--
Nicolas Mailhot
10:55 a.m.
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
11:09 a.m.
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,
--
Nicolas Mailhot
12:19 p.m.
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
12:35 p.m.
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,
--
Nicolas Mailhot
7519
days inactive
7519
days old
13 comments
8 participants
participants (8)
-
Behdad Esfahbod -
Bill Nottingham -
Chris Ricker -
Havoc Pennington -
Howard Owen -
Jason Tackaberry -
Nicolas Mailhot -
Paul Heinlein