2:44 p.m.
I've been playing around with initng quite a bit lately and have had a
good amount of luck getting it running successfully on my rawhide laptop, a
VMWare test environment, and my FC4 desktop. Had a few issues right off the
bat, but eventually worked most of them out (thanks to the help of
Daniel Malmgren). I believe fedora related patches even hit their repos
as well.
Here's what I've seen so far...
initng - http://initng.thinktux.net
======
Pros
o Dynamic service dependencies
o Service monitoring
o Automatic respawning of services
o Parallelized service startup
o Plugin support
o Very active and helpful community
- Extremely open to getting initng working by default in Fedora
o Supports /etc/rc.* scripts via a plugin, but uses it's own format by
default (also supports xml init scripts via plugin)
o FAST AS HELL[0]
Cons
o Gentoo look-and-feel (brings back old memories)
- Having such an open-minded community, giving initng a more
unified/professional feel would hopefully be accepted
o No inherent D-BUS support
- initng's plugin support would allow this to be accomplished (but I
would bring it up to the developers; who knows, they might want it
upstream?)
- - -
After talking with Harald about his SystemManager, apparently he hasn't
actually gotten it complete enough to successfully start a system with
it yet, but he kindly answered all of the questions I had.
SystemManager - :pserver:anonymous@rhlinux.redhat.com:/usr/local/CVS servicemanager
=============
Pros
o /etc/rc replacement; so integration into our current SysVinit setup
would be close to trivial
o Will work with our current init scripts without modification
o Automatic/On-demand respawing of services
o Exporting of services as D-BUS objects
o Dynamic service dependencies
Cons
o Not complete/tested
o Still supports the /etc/rc.d/rc$i.d framework (which is horrible by
design)
- - -
I'm sure I missed many aspects of the init/bootup procedure in the above
observations, as this is far from a complete analysis. Please jump in if
you have any additional observations/questions/comments/corrections.
So.. our first step ?
Getting initng into extras definitely won't hurt. It will give everyone
a chance to play it with, and hopefully will help work most of the kinks out.
As far as SystemManager goes; it's definitely a project with lots of
potential, and if the demand is there, I'm ready to start hacking.
What does everyone else think ?
luke
[0]: I generated bootcharts for a default FC4 install with minimal
tweaking (removed a few unnecessary services) and FC4 with a
default initng install. These are in no way supposed to be an accurate
measurement of the true speeds of either of these versions of init
(they are also both running different init scripts).
http://people.redhat.com/lmacken/initng-bootchart.png
http://people.redhat.com/lmacken/SysVinit-bootchart.png
2:51 p.m.
Luke Macken (lmacken(a)redhat.com) said:
I've been playing around with initng quite a bit lately and have
had a
good amount of luck getting it running successfully on my rawhide laptop, a
VMWare test environment, and my FC4 desktop. Had a few issues right off the
bat, but eventually worked most of them out (thanks to the help of
Daniel Malmgren). I believe fedora related patches even hit their repos
as well.
Here's what I've seen so far...
initng - http://initng.thinktux.net
======
Pros
o Dynamic service dependencies
o Service monitoring
o Automatic respawning of services
o Parallelized service startup
o Plugin support
o Very active and helpful community
- Extremely open to getting initng working by default in Fedora
o Supports /etc/rc.* scripts via a plugin, but uses it's own format by
default (also supports xml init scripts via plugin)
o FAST AS HELL[0]
Cons
o Gentoo look-and-feel (brings back old memories)
- Having such an open-minded community, giving initng a more
unified/professional feel would hopefully be accepted
o No inherent D-BUS support
- initng's plugin support would allow this to be accomplished (but I
would bring it up to the developers; who knows, they might want it
upstream?)
One of the ideas was that eventually services would expose
*themselves* over d-bus without wrappers, and that would be the
native management framework. I'm not sure how that would fit into
this model. It could be something to look at, though.
[0]: I generated bootcharts for a default FC4 install with minimal
tweaking (removed a few unnecessary services) and FC4 with a
default initng install. These are in no way supposed to be an accurate
measurement of the true speeds of either of these versions of init
(they are also both running different init scripts).
http://people.redhat.com/lmacken/initng-bootchart.png
http://people.redhat.com/lmacken/SysVinit-bootchart.png
Hm, comparing against a SysVinit bootup *without* rhgb might
be interesting, as it's known that that adds to the startup time.
Bill
3:11 p.m.
From: "Luke Macken" <lmacken(a)redhat.com>
I'm sure I missed many aspects of the init/bootup procedure in
the above
observations, as this is far from a complete analysis. Please jump in if
you have any additional observations/questions/comments/corrections.
So.. our first step ?
I think we need to make a choice and go with it. Encouraging multiple
solutions at this point will only dilute the focus, and confuse users.
What do we need to do to pick something and go with it? It looks like
initng is 'close enough', how about approaching the developers and see
how willing they are to integrate D-BUS in it? What about Bill's
suggestion? It looks like SystemManager does that, no?
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
3:12 p.m.
From: "Luke Macken" <lmacken(a)redhat.com>
o FAST AS HELL[0]
Fast, but can we do better? Why do we need to bring up
the networking before we start X? Also, is it feasible
to probe for just some hardware (disk, video), start x,
then continue with the hardware probing? Will it be any
faster if we get rid of the wrappers? Would readahead
help here at all?
Basically, can we have X up in 10s? :)
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
3:14 p.m.
Dimi Paun (dimi(a)lattica.com) said:
From: "Luke Macken" <lmacken(a)redhat.com>
> o FAST AS HELL[0]
Fast, but can we do better? Why do we need to bring up
the networking before we start X? Also, is it feasible
to probe for just some hardware (disk, video), start x,
then continue with the hardware probing?
What 'hardware probing' are you talking about here? We
just load all relevant modules, splitting it up will
probably just cause more complication and slow things
down.
Bill
4:49 p.m.
From: "Bill Nottingham" <notting(a)redhat.com>
What 'hardware probing' are you talking about here? We
just load all relevant modules, splitting it up will
probably just cause more complication and slow things
down.
I'm talking about modprobe. I agree, not a bit problem
(~2.5s), but I was wondering if we can start X before it.
I mean, things should work out correctly in face of
hotplug events anyhow, so why don't we delay modprobing
until after we start X, and treat them as hotplug events?
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
9:36 a.m.
Once upon a time, Dimi Paun <dimi(a)lattica.com> said:
I'm talking about modprobe. I agree, not a bit problem
(~2.5s), but I was wondering if we can start X before it.
X yes. GNOME, probably not. GNOME likes to see the network and many of
the applets only check for things on start-up (like sensors, sound,
etc.). For example, system sensors are not hot-swap on any system that
I'm aware of, so the applets are not typically written to handle that.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
9:40 a.m.
Chris Adams wrote:
Once upon a time, Dimi Paun <dimi(a)lattica.com> said:
>I'm talking about modprobe. I agree, not a bit problem
>(~2.5s), but I was wondering if we can start X before it.
>
>
X yes. GNOME, probably not. GNOME likes to see the network and many of
the applets only check for things on start-up (like sensors, sound,
etc.). For example, system sensors are not hot-swap on any system that
I'm aware of, so the applets are not typically written to handle that.
Those are probably bugs/RFE's to report then. GNOME should work in a
non-networked system without any complaints whatsoever.
regards
Rahul
9:46 a.m.
On 11/16/05, Rahul Sundaram <sundaram(a)redhat.com> wrote:
Those are probably bugs/RFE's to report then. GNOME should work
in a
non-networked system without any complaints whatsoever.
non-networked... meaning no local loopback? The network service
doesn't just handle external route it starts up 127.0.0.1 as well.
I'm not sure requiring 127.0.0.1 to be available is unreasonable
-jef
9:57 a.m.
From: "Jeff Spaleta" <jspaleta(a)gmail.com>
non-networked... meaning no local loopback? The network service
doesn't just handle external route it starts up 127.0.0.1 as well.
I'm not sure requiring 127.0.0.1 to be available is unreasonable
It would be nice to not depend on localhost, but I agree, it's reasonable
to assume its there. In any case, bringing localhost up should be
a lot faster then up the others, no?
BTW, it would be an interesting experiment to see what happens if
127.0.0.1 is not up. There will be a time when it's needed, I agree.
At which point we would need a clean way of waiting on networking
to be brought up. Hopefully this is after the user enters their
username and password.
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
10:03 a.m.
On 11/16/05, Dimi Paun <dimi(a)lattica.com> wrote:
It would be nice to not depend on localhost, but I agree, it's
reasonable
to assume its there. In any case, bringing localhost up should be
a lot faster then up the others, no?
You are talking to the wrong person.. I don't think its worth the
extras complexity of seperating out the network startup into lo and
other. I'm sure its technically possible to seperate out lo startup
into its own service.
-jef
11:17 a.m.
Dimi Paun (dimi(a)lattica.com) said:
I'm talking about modprobe. I agree, not a bit problem
(~2.5s), but I was wondering if we can start X before it.
I mean, things should work out correctly in face of
hotplug events anyhow, so why don't we delay modprobing
until after we start X, and treat them as hotplug events?
a) because X is dumb, and doesn't handle hotplug devices
b) becuase it really shouldn't take *that* long
Bill
11:28 a.m.
From: "Bill Nottingham" <notting(a)redhat.com>
a) because X is dumb, and doesn't handle hotplug devices
You mean mouse & keyboard? I'd consider it a bug, really.
I think X should handle it if I change the keyboard and
or the mouse.
b) becuase it really shouldn't take *that* long
True, 3s is not *that* long, just wanted to see what
it would take to get rid of it. Problem is that nothing
is *that* long (most things take less then 3 sec), but
they do add up. And 40s is too much.
This is offtopic, but I think in general we have a problem
with startup times. For example, starting gedit (which is
marketed as a fast and simple text editor) on my fairly
decent 3GHz CPU/1GB RAM box takes a *few* seconds. This
should be instantaneous (<300ms). I think we're about 100
slower then we should be. And this is in an area that people
care about startup times more than for boot. I wouldn't
be surprised to have similar inefficiencies during init.
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
11:30 a.m.
Dimi Paun (dimi(a)lattica.com) said:
This is offtopic, but I think in general we have a problem
with startup times. For example, starting gedit (which is
marketed as a fast and simple text editor) on my fairly
decent 3GHz CPU/1GB RAM box takes a *few* seconds. This
should be instantaneous (<300ms). I think we're about 100
slower then we should be. And this is in an area that people
care about startup times more than for boot. I wouldn't
be surprised to have similar inefficiencies during init.
Disk seek.
Bill
11:56 a.m.
On 11/16/05, Bill Nottingham <notting(a)redhat.com> wrote:
Dimi Paun (dimi(a)lattica.com) said:
> This is offtopic, but I think in general we have a problem
> with startup times. For example, starting gedit (which is
> marketed as a fast and simple text editor) on my fairly
> decent 3GHz CPU/1GB RAM box takes a *few* seconds. This
> should be instantaneous (<300ms). I think we're about 100
> slower then we should be. And this is in an area that people
> care about startup times more than for boot. I wouldn't
> be surprised to have similar inefficiencies during init.
Disk seek.
To elaborate.. there are factors beyond your CPU/memory. What kind of
diskdrive do you have? What is its transfer rates? What are it
hit/miss rates? How is the layout of the disk optimized for disk-seek?
A lot of commodity disk-drives are sub-par on these areas. This means
that programs will slow down because you are spending a lot of time
waiting for the disk-drive to give you bits because it keeps plugging
up its cache or not able to get various items off disk as fast as
advertised.
--
Stephen J Smoogen.
CSIRT/Linux System Administrator
12:22 p.m.
On 11/16/05, Stephen J. Smoogen <smooge(a)gmail.com> wrote:
A lot of commodity disk-drives are sub-par on these areas. This
means
that programs will slow down because you are spending a lot of time
waiting for the disk-drive to give you bits because it keeps plugging
up its cache or not able to get various items off disk as fast as
advertised.
Is there some reasonably valid understanding of how big an impact this
makes in the average and worst case? Sort of a measure of the spread
of disk-drive performance out in the wild.
Say for example...a typical christmas special home desktop from
Dell... does the disk-seek performance on a system like that make an
order of magnitude faster bootup or application startup times a
pipedream?
-jef
12:32 p.m.
On 11/16/05, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
On 11/16/05, Stephen J. Smoogen <smooge(a)gmail.com> wrote:
> A lot of commodity disk-drives are sub-par on these areas. This means
> that programs will slow down because you are spending a lot of time
> waiting for the disk-drive to give you bits because it keeps plugging
> up its cache or not able to get various items off disk as fast as
> advertised.
Is there some reasonably valid understanding of how big an impact this
makes in the average and worst case? Sort of a measure of the spread
of disk-drive performance out in the wild.
Not that I know of.. I am guessing the proper methodology would be to get
3 disks of the same model (to check for divergence inside a model)
1 set of 5000 RPM ???
1 set of 7200 RPM
1 set of 10000 RPM
1 set of 15000 RPM
and sets depending on disk cache sizes and such.
And then plug them into the same hardware system so that one should be
just testing the diskdrive. Once that divergence testing has been
done.. it would next to see what changing controllers do [that is the
second thing we subjectively saw as a bigger improvement than getting
someone a faster CPU.]
--
Stephen J Smoogen.
CSIRT/Linux System Administrator
12:44 p.m.
Jeff Spaleta wrote:
Is there some reasonably valid understanding of how big an impact
this
makes in the average and worst case? Sort of a measure of the spread
of disk-drive performance out in the wild.
Say for example...a typical christmas special home desktop from
Dell... does the disk-seek performance on a system like that make an
order of magnitude faster bootup or application startup times a
pipedream?
My back-of-the-envelope number is 3x better performance in Ultra 320
drives vs PATA for seek-heavy workloads (database apps, make -j4, cp a
50 GB directory.) A big part of the advantage comes from tagged command
queueing -- recent SATA drives support Native Command Queueing (NCQ) but
benchmarks I've seen of NCQ drives aren't impressive.
12:48 p.m.
From: "Stephen J. Smoogen" <smooge(a)gmail.com>
To elaborate.. there are factors beyond your CPU/memory. What kind
of
diskdrive do you have? What is its transfer rates? What are it
hit/miss rates? How is the layout of the disk optimized for disk-seek?
A lot of commodity disk-drives are sub-par on these areas. This means
that programs will slow down because you are spending a lot of time
waiting for the disk-drive to give you bits because it keeps plugging
up its cache or not able to get various items off disk as fast as
advertised.
I think this is missing the point -- we are not talking about some
big database intensive application that needs special handling to
work optimally. We are talking about the simplest application on
the desktop, on a fairly beefy machine, running the most stock FC4
out there.
If I need to do _anything_ special to get gedit to start in a decent
manner, something is clearly wrong. And BTW, try to start notepad
in Windows. It's fast.
I think that anything over 500ms for gedit is bad. Even on a 500MHz box.
Granted, part of the problem may be in the application, but the user
doesn't know (and frankly, doesn't care).
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
12:58 p.m.
Dimi Paun (dimi(a)lattica.com) said:
I think this is missing the point -- we are not talking about some
big database intensive application that needs special handling to
work optimally. We are talking about the simplest application on
the desktop, on a fairly beefy machine, running the most stock FC4
out there.
If I need to do _anything_ special to get gedit to start in a decent
manner, something is clearly wrong. And BTW, try to start notepad
in Windows. It's fast.
I think that anything over 500ms for gedit is bad. Even on a 500MHz box.
Granted, part of the problem may be in the application, but the user
doesn't know (and frankly, doesn't care).
It's disk seek on shared libraries, almost certianly. It's the majority
of lag time on *any* startup these days, including the OS itself.
Bill
1:11 p.m.
Once upon a time, Bill Nottingham <notting(a)redhat.com> said:
It's disk seek on shared libraries, almost certianly. It's
the majority
of lag time on *any* startup these days, including the OS itself.
I know we have prelink, but has someone considered a defrag-like thing
that could work with prelink to re-arrange the libraries on the disk for
better performance? IIRC Windows has the ability to do this and it is
supposed to really help.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
1:12 p.m.
From: "Bill Nottingham" <notting(a)redhat.com>
It's disk seek on shared libraries, almost certianly. It's
the majority
of lag time on *any* startup these days, including the OS itself.
OK, that's reasonable. However, I'm not sure we should just accept that.
How come notepad starts up fast on Windows? They don't have seeks?
And besides, what libs does gedit need on a fully loaded GNOME desktop
that are not already loaded?
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
1:30 p.m.
Dimi Paun wrote:
From: "Bill Nottingham" <notting(a)redhat.com>
>It's disk seek on shared libraries, almost certianly. It's the majority
>of lag time on *any* startup these days, including the OS itself.
>
>
OK, that's reasonable. However, I'm not sure we should just accept that.
How come notepad starts up fast on Windows? They don't have seeks?
And besides, what libs does gedit need on a fully loaded GNOME desktop
that are not already loaded?
I had some startup issues with gedit too. But it wasn't a disk seek
issue. (noticed that it takes longer if there is heavy network load ex:
bittorent) . (its *much* fast when hostname=localhost=no network up)
I have set up a local dns server using bind and now the issues are gone.
Local apps should always use localhost as hostname which would have
avoided this problem.
1:50 p.m.
On 11/16/05, dragoran <dragoran(a)feuerpokemon.de> wrote:
I had some startup issues with gedit too. But it wasn't a disk
seek
issue. (noticed that it takes longer if there is heavy network load ex:
bittorent) . (its *much* fast when hostname=localhost=no network up)
I have set up a local dns server using bind and now the issues are gone.
Local apps should always use localhost as hostname which would have
avoided this problem.
Can you explain why my system which has hostname!=localhost with an
active network
using a remote dns server has gedit start in under 1 second?
-jef
3:54 p.m.
On Wed, Nov 16, 2005 at 02:12:57PM -0500, Dimi Paun wrote:
OK, that's reasonable. However, I'm not sure we should just
accept that.
How come notepad starts up fast on Windows? They don't have seeks?
And besides, what libs does gedit need on a fully loaded GNOME desktop
that are not already loaded?
A quick strace of gedit startup on a FC3 system shows it doing over 3000
opens, which break down as:
1980 .icon files
1265 miscellaneous
76 .so files
--
Red sky at night - gerroff my land!
Red sky at morning - gerroff my land!
-- old farmers' sayings #14
3:57 p.m.
Dave Mitchell wrote:
On Wed, Nov 16, 2005 at 02:12:57PM -0500, Dimi Paun wrote:
>OK, that's reasonable. However, I'm not sure we should just accept that.
>How come notepad starts up fast on Windows? They don't have seeks?
>And besides, what libs does gedit need on a fully loaded GNOME desktop
>that are not already loaded?
>
>
A quick strace of gedit startup on a FC3 system shows it doing over 3000
opens, which break down as:
1980 .icon files
1265 miscellaneous
76 .so files
Perhaps the gedit or GNOME performance lists would be a better place to
analyse and provide such feedback.
regards
Rahul
8:59 a.m.
On Wed, Nov 16, 2005 at 01:58:11PM -0500, Bill Nottingham wrote:
It's disk seek on shared libraries, almost certianly. It's
the majority
of lag time on *any* startup these days, including the OS itself.
I doubt its the shared libraries that dominate. Not unless gnome has much
improved. The older traces I studied were dominated by the poorly designed
gconf system and the even more badly designed theme code. Simply packing
the themes using a trivial library I wrote reduced the cost of theme loading
to almost zero and reduced gnome memory usage by about 2MB/app
Perhaps Havoc can update on the state of the themes and gconf code
Alan
6:49 p.m.
New subject: Improving desktop application performance WAS Re: init observations
On Wed, 2005-11-16 at 13:48 -0500, Dimi Paun wrote:
From: "Stephen J. Smoogen" <smooge(a)gmail.com>
> To elaborate.. there are factors beyond your CPU/memory. What kind of
> diskdrive do you have? What is its transfer rates? What are it
> hit/miss rates? How is the layout of the disk optimized for disk-seek?
>
> A lot of commodity disk-drives are sub-par on these areas. This means
> that programs will slow down because you are spending a lot of time
> waiting for the disk-drive to give you bits because it keeps plugging
> up its cache or not able to get various items off disk as fast as
> advertised.
I think this is missing the point -- we are not talking about some
big database intensive application that needs special handling to
work optimally. We are talking about the simplest application on
the desktop, on a fairly beefy machine, running the most stock FC4
out there.
If I need to do _anything_ special to get gedit to start in a decent
manner, something is clearly wrong. And BTW, try to start notepad
in Windows. It's fast.
I think that anything over 500ms for gedit is bad. Even on a 500MHz box.
Granted, part of the problem may be in the application, but the user
doesn't know (and frankly, doesn't care).
[changing Subject to better reflect this part of the thread]
There's lots of good work on improving exactly this kind of thing going
on at the moment in the upstream GNOME community (e.g. optimizing Pango,
the filechooser, session startup time etc).
If anyone with C coding skills is interested in helping out with this
effort, it'd be great if you could help out there, and we'll see the
improvements landing in FC5
The relevant mailing list is performance-list(a)gnome.org, where there's a
strong focus on good methodology i.e. measuring to determine exactly
what's really causing a problem, then trying a change, then measuring
the effects. Sometimes the proposed optimizations have turned out to
actually slow things down...
Some great resources are Lorenzo's Colitti's analysis page on speeding
up gnome:
http://www.gnome.org/~lcolitti/gnome-startup/analysis/ [1]
See also Federico's blog:
http://primates.ximian.com/~federico/news.html
Plus this page on the GNOME wiki:
http://live.gnome.org/Performance
Hope this helps
Dave
[1] with plenty of help from the #fedora-desktop gang :-)
11:50 a.m.
On 11/16/05, Dimi Paun <dimi(a)lattica.com> wrote:
This is offtopic, but I think in general we have a problem
with startup times. For example, starting gedit (which is
marketed as a fast and simple text editor) on my fairly
decent 3GHz CPU/1GB RAM box takes a *few* seconds. This
should be instantaneous (<300ms). I think we're about 100
slower then we should be.
How do you time this?
According to my wristwatch with second hand resolution, getting a
gedit window on my 1 GHz athlon with 512Meg ram... takes under a
second from the moment I click on the gedit menu item on the
accessories menu on this fc4 system... right after a fresh reboot and
login to my gnome session. I really don't think ancedotal
conversations about application window appearence time are worthwhile.
-jef
7:17 p.m.
On Wed, 2005-11-16 at 12:50 -0500, Jeff Spaleta wrote:
How do you time this?
Stopwatch. I just did it again, and it's just shy of 3s
(maybe 2.9s). And since people asked about HD, here are
some numbers:
[root@dimi ~]# hdparm -Tt /dev/hda
/dev/hda:
Timing cached reads: 3704 MB in 2.00 seconds = 1851.36 MB/sec
Timing buffered disk reads: 170 MB in 3.03 seconds = 56.17 MB/sec
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
9:02 a.m.
On Wed, Nov 16, 2005 at 12:17:12PM -0500, Bill Nottingham wrote:
> hotplug events anyhow, so why don't we delay modprobing
> until after we start X, and treat them as hotplug events?
a) because X is dumb, and doesn't handle hotplug devices
a) if X is using /dev/input/* it doesnt need to know about the
base keyboard/mouse
11:29 a.m.
Alan Cox (alan(a)redhat.com) said:
On Wed, Nov 16, 2005 at 12:17:12PM -0500, Bill Nottingham wrote:
> > hotplug events anyhow, so why don't we delay modprobing
> > until after we start X, and treat them as hotplug events?
>
> a) because X is dumb, and doesn't handle hotplug devices
a) if X is using /dev/input/* it doesnt need to know about the
base keyboard/mouse
Until the upstream input developers have their way and remove
the /dev/input/mice multiplexor. I think they've been convinced
to wait for now...
Bill
3:15 p.m.
On Tue, 2005-11-15 at 16:12 -0500, Dimi Paun wrote:
Fast, but can we do better? Why do we need to bring up
the networking before we start X? Also, is it feasible
to probe for just some hardware (disk, video), start x,
then continue with the hardware probing? Will it be any
faster if we get rid of the wrappers? Would readahead
help here at all?
Basically, can we have X up in 10s? :)
Not a developer or programmer, but what about those systems that use
x/fonts from a server and not on the workstation? How would X start
without networking capabilities?
--
Mike Chambers
Madisonville, KY
"It's better to hurt a little now, than to hurt a lot later!"
3:19 p.m.
--On Tuesday, November 15, 2005 3:15 PM -0600 Mike Chambers
<mike(a)miketc.com> wrote:
Not a developer or programmer, but what about those systems that use
x/fonts from a server and not on the workstation? How would X start
without networking capabilities?
What does it currently do if your font server is unreachable? Does it wait,
or fall back to local fonts until it can reach the server? Or just fall
over?
5:53 p.m.
Kenneth Porter wrote:
--On Tuesday, November 15, 2005 3:15 PM -0600 Mike Chambers
<mike(a)miketc.com> wrote:
> Not a developer or programmer, but what about those systems that use
> x/fonts from a server and not on the workstation? How would X start
> without networking capabilities?
What does it currently do if your font server is unreachable? Does it
wait, or fall back to local fonts until it can reach the server? Or just
fall over?
Our out of the box supported default configuration of the X server,
is that it requires a properly configured xfs font server to be
running on the same machine. If xfs is not running, the X server
will not start, as it will be unable to find the 'fixed' and
'cursor' fonts.
The X server and font server are highly configureable however, and
various people use them in various non-default setups. Some people
might have their X server manually configured to not use xfs, or to
use xfs over the network via TCP being enabled. Some people may
have /usr mounted over NFS, possibly read-only, and the X server
binary and other X applications in /usr/bin et al. aren't available
until /usr is mounted, which requires networking to be started.
There are as many other custom setups likely, as there are users
out there. ;o)
On a side note:
When modular X hits rawhide over the next few days, it is highly
recommended that people using customized configurations that are
not the default, test their setups with the new modular X, and
see if they need to adjust their configuration.
HTH.
3:23 p.m.
On 11/15/05, Dimi Paun <dimi(a)lattica.com> wrote:
Basically, can we have X up in 10s? :)
I still don't understand exactly why this is the important goal.
Explain to me why the 10second to X goal on "reboot" is more important
than getting a robust suspend/hibernate working that doesn't require a
full boot up process at all? I can see why the fist 4 items in Luke's
list are technical wins for a less grotesque init process... but i
still don't get why getting to a login screen in under 10 seconds on a
full boot is noteworthy or highly desirable compared to a
suspend/hibernate that actually works across desktops and laptop
hardware.
And until we see bootchart output that shows a comparison of initrd to
SysVinit for the default Fedora Core service set... the jury is out on
how big a difference this actually makes for the default case.
-jef
3:35 p.m.
On Tue, 2005-11-15 at 16:23 -0500, Jeff Spaleta wrote:
On 11/15/05, Dimi Paun <dimi(a)lattica.com> wrote:
> Basically, can we have X up in 10s? :)
I still don't understand exactly why this is the important goal.
Explain to me why the 10second to X goal on "reboot" is more important
than getting a robust suspend/hibernate working that doesn't require a
full boot up process at all? I can see why the fist 4 items in Luke's
list are technical wins for a less grotesque init process... but i
still don't get why getting to a login screen in under 10 seconds on a
full boot is noteworthy or highly desirable compared to a
suspend/hibernate that actually works across desktops and laptop
hardware.
I agree. I have recently installed Rawhide on my laptop (IBM T40) and
got gnome-power-manager with suspend to disk working (the only problem
was the non-support for swap partitions identified by label, already in
bugzilla but I can't remember the number) and it is superb. I now plan
on pretty much never rebooting again.
Kudos to all those who worked so hard to make the bits join up - kernel,
hal, dbus, g-p-m!
Keith.
4:46 p.m.
On Tue, Nov 15, 2005 at 04:23:56PM -0500, Jeff Spaleta wrote:
On 11/15/05, Dimi Paun <dimi(a)lattica.com> wrote:
> Basically, can we have X up in 10s? :)
I still don't understand exactly why this is the important goal.
Explain to me why the 10second to X goal on "reboot" is more important
than getting a robust suspend/hibernate working that doesn't require a
full boot up process at all?
If suspend was 100% reliable, I'd agree. For a lot of systems,
we may never get them working due to lack of hardware specifications
to wake the drivers up on resume. (Video drivers are particularly
bad in this area).
Even for the hardware we *do* have docs for, we're likely to be
playing bug-whack-a-mole for quite some time yet. For FC4 and
earlier, any suspend/resume bugs that have been filed have
frankly been 'best effort'. If it was a simple fix, I merged it.
Anything else is stuff that we've inherited from upstream.
With swsusp being enabled in FC5, I'm expecting to see a lot
more suspend/resume bugs being filed after its release.
Dave
6:04 p.m.
On 11/15/05, Dave Jones <davej(a)redhat.com> wrote:
If suspend was 100% reliable, I'd agree. For a lot of systems,
we may never get them working due to lack of hardware specifications
to wake the drivers up on resume. (Video drivers are particularly
bad in this area).
I'm sure its going to be the hard thing to do... but who said the
right thing to do was the easy one? I'm sure the difficulties in
hardware coverage are real, but I still haven't seen a smoking gun
that init parallelization is going to be an instant win for boottime
for the default case, the average case, the worst case or anything
else worth noting. The introduction of the bootchart and the
resulting optimization of the init process we have now and I don't see
why parallelization is garunteed to improve on that. Considering all
the other technical benefits to moving to a more sophisticated init, I
just don't think boottime is a strong argument.. I don't think we
really know what the impact on boottime is going to be.
-jef"I thought the mark was 80% reliable"spaleta
5:58 p.m.
Jeff Spaleta wrote:
On 11/15/05, Dimi Paun <dimi(a)lattica.com> wrote:
>Basically, can we have X up in 10s? :)
I still don't understand exactly why this is the important goal.
Explain to me why the 10second to X goal on "reboot" is more important
than getting a robust suspend/hibernate working that doesn't require a
full boot up process at all? I can see why the fist 4 items in Luke's
list are technical wins for a less grotesque init process... but i
still don't get why getting to a login screen in under 10 seconds on a
full boot is noteworthy or highly desirable compared to a
suspend/hibernate that actually works across desktops and laptop
hardware.
And until we see bootchart output that shows a comparison of initrd to
SysVinit for the default Fedora Core service set... the jury is out on
how big a difference this actually makes for the default case.
"X" starts in less than 5 seconds on most systems and has for years.
However, if what is meant is "Have a fully working graphical GNOME or
KDE desktop started up in X in less than 10 seconds" is the goal, then
my opinion is thus:
Getting a full desktop started up in less than 10 seconds is a
completely orthagonal problem than having working suspend/hibernate
support. Most likely the people who would be working on either
project, would be different developers working in parallel on
different problems. So it isn't IMHO about allocation of resources
per se.
I personally think that getting a full desktop running in less than
10 seconds is more important than working hibernate support, simply
because there are probably one ore more orders of magnitude more
"desktop users" than there are "laptop users" out there. Both
features are important to have for their respective userbases of
course, but the "desktop users" group generally is a superset of the
"laptop users" group.
6:13 p.m.
On 11/15/05, Mike A. Harris <mharris(a)redhat.com> wrote:
I personally think that getting a full desktop running in less than
10 seconds is more important than working hibernate support, simply
because there are probably one ore more orders of magnitude more
"desktop users" than there are "laptop users" out there. Both
features are important to have for their respective userbases of
course, but the "desktop users" group generally is a superset of the
"laptop users" group.
why can't "desktop" or "thin clients" or "home theature
settop boxes"
or "router appliance" benefit from a robust suspend? Just because
"laptop" users are the traditional group who feel a need for this,
doesn't mean its not the right solution for a broader range of users.
Don't desktop bioses that are being sold right now claim to support to
suspend?
-jef"this discussion is moot anyways, neural interfaces will be here
in a decade and i doubt rebooting your brain will be an option"spaleta
6:21 p.m.
On Tuesday 15 November 2005 05:13pm, Jeff Spaleta wrote:
On 11/15/05, Mike A. Harris <mharris(a)redhat.com> wrote:
> I personally think that getting a full desktop running in less than
> 10 seconds is more important than working hibernate support, simply
> because there are probably one ore more orders of magnitude more
> "desktop users" than there are "laptop users" out there. Both
> features are important to have for their respective userbases of
> course, but the "desktop users" group generally is a superset of the
> "laptop users" group.
The moment I read that, I knew this was coming.
why can't "desktop" or "thin clients" or
"home theature settop boxes"
or "router appliance" benefit from a robust suspend? Just because
"laptop" users are the traditional group who feel a need for this,
doesn't mean its not the right solution for a broader range of users.
Don't desktop bioses that are being sold right now claim to support to
suspend?
I think that what he meant by laptop userbase vs. desktop userbase is valid
because *most* "desktop" users don't care about suspend. Even if they see
it
available, they probably won't use it.
I think you are right, though, Jef; desktop systems, set-top boxes, and so on
and so on, would definitely benefit, too. But I have to wonder, since the
developers who are going to work on both possible solutions are probably not
the same people, why not just do both?
Also, since it is unlikely that broad suspend, et. al. support is going to
come along too quickly, I think faster boot and shutdown times are a great
idea.
--
Lamont R. Peterson <lamont(a)gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
6:35 p.m.
On 11/15/05, Lamont R. Peterson <lamont(a)gurulabs.com> wrote:
I think that what he meant by laptop userbase vs. desktop userbase is
valid
because *most* "desktop" users don't care about suspend. Even if they see
it
available, they probably won't use it.
User education problem.... which only serves to re-enforce the status-quo.
I think you are right, though, Jef; desktop systems, set-top boxes,
and so on
and so on, would definitely benefit, too. But I have to wonder, since the
developers who are going to work on both possible solutions are probably not
the same people, why not just do both?
The context in this discussion is.... does the parallelization that
initng provides actually improve boottime or does it not. My argument
is.. compared to the other technical "wins" with changing init systems
the boottime "benefit" is speculative and should not be the focus of
the decision at hand. Hell, initng might actually cause a boottime
increase for the default case.
I'm all for continued optmization of the boot process, the creation of
the bootchart tool and the optmization built on the use of that tool
has been a good thing{tm} and I'm sure more progress will be made on
that front regardless of which init system is in use. But, I think its
ill-advised to make the focus of the discussion of changing the init
system centered around boottime enhancements which may or may not
materialize. As a matter of priorities associated with the specific
issue of changing the init system... boottime ehancement should be the
last concern.
-jef"most desktop users dont care about linux.. even if they see it
available they won't use it.... but here we are anyways.. attempting
to educate and to make better solutions "spaleta
3:29 p.m.
On Tue, 2005-11-15 at 16:12 -0500, Dimi Paun wrote:
Why do we need to bring up
the networking before we start X?
NFS-mounted /home. No point in being able to log in if you don't have a
home directory yet.
--
Ignacio Vazquez-Abrams <ivazquez(a)ivazquez.net>
http://fedora.ivazquez.net/
gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
3:36 p.m.
Once upon a time, Ignacio Vazquez-Abrams <ivazquez(a)ivazquez.net> said:
On Tue, 2005-11-15 at 16:12 -0500, Dimi Paun wrote:
> Why do we need to bring up
> the networking before we start X?
NFS-mounted /home. No point in being able to log in if you don't have a
home directory yet.
LDAP or NIS authentication require network for that matter.
Also IIRC, GNOME tries to do a hostname lookup during login (I get an
error sometimes on my notebook).
I think instead of trying to replace the init system wholesale, it would
be better to make a few improvements to the current system. For
example, it should be possible to mark a service as "background startup"
so boot doesn't wait on it (one candidate is nut; right now I have to
wait a bit while it thinks about talking to my UPS). Many of the
network services (SMTP, SSH, FTP, etc.) don't need to be available
before local login.
I'm not convinced that parallel startup is such a great idea. A lot of
work will be required to get (and keep) dependencies straight. Also, is
it really a win? Firing off a dozen things at once does not make them
finish 12 times faster; it can make them take longer.
How often do people reboot their system? Most of mine are typically up
for weeks at a time. If power management worked better on my notebook,
I'd probably never do a full shutdown.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
3:44 p.m.
On 11/15/05, Chris Adams <cmadams(a)hiwaay.net> wrote:
I'm not convinced that parallel startup is such a great idea. A
lot of
work will be required to get (and keep) dependencies straight. Also, is
it really a win? Firing off a dozen things at once does not make them
finish 12 times faster; it can make them take longer.
This is why we need to see initng booting a default set of services
side-by-side with a SysVinit.
Its very much an open question as to whether there is much win at all
here... and exactly which segment would be expected to benefit. Luke's
images don't come close to telling a real comparitive story about
boottime. Out of all the potential benefits I see the boottime
argument as least compelling, and most speculative... so its probably
best not to focus on this item at all.
-jef
4:11 p.m.
Jeff Spaleta wrote:
This is why we need to see initng booting a default set of services
side-by-side with a SysVinit.
Its very much an open question as to whether there is much win at all
here... and exactly which segment would be expected to benefit. Luke's
images don't come close to telling a real comparitive story about
boottime. Out of all the potential benefits I see the boottime
argument as least compelling, and most speculative... so its probably
best not to focus on this item at all.
In the past, boot times have been a major complaint of ordinary
consumers.
A few years back, we bought a computer for my sister-in-law. It
came with Windows XP at about the time Win XP first came out. In six
months they installed a huge amount of junkware on it, which finally
made the machine inoperable. The last straw was a keyboard driver for a
keyboard with idiot buttons (connect to AOL...) that put up a modal
dialog box that asked if I wanted to upgrade the keyboard driver that
stopped me from fixing another serious problem with the start sequence.
So, we think, they want to browse the web, let's set them up with
Linux -- I think it was RH 9. At least they're not going to trash the
machine by installing junkware.
Laura's first complaint about the machine was that it took forever
to boot, and I realized she was right. I took about 2/3 of the stuff
out of the boot sequence (HP laserjet drivers, asian language input
methods...), and things got a lot better.
FC3 and RHEL 4 made a great leap forward. When I installed RHEL 4
on an old 400 MhZ machine, I booted the machine for the first time,
turned my back on it, expected it to still be grinding, and was amazed
to see that it was already up!
The starting and stopping experience makes a big difference in the
experience of a computer. If it takes forever to boot your computer,
you leave it on all the time, wasting electricity and being a bigger
target for hackers. My pet peeve with Windows and MacOS X right now is
that these operating systems usually don't shut down when I hit the
shutdown button. They mollycoddle bad-behaving applications, so often
I have to hang around for 5 minutes after a shutdown to make sure I
haven't missed any dialog boxes. My wife often leaves our Mac on all
night because she hits "shutdown" and doesn't hang around to close all
my terminal windows, and I often find that my Windows machine at the
office is still on in the morning after I thought I shut it down at
night and took off in a hurry to catch the bus.
4:26 p.m.
On 11/15/05, Paul A Houle <ph18(a)cornell.edu> wrote:
In the past, boot times have been a major complaint of ordinary
consumers.
You missed my point entirely.
Why are we considering all "start up" situations as "full boot"
scenarios?
Why isn't focusing on suspend to disk scenarios a better win?
Laura's first complaint about the machine was that it took
forever
to boot, and I realized she was right. I took about 2/3 of the stuff
out of the boot sequence (HP laserjet drivers, asian language input
methods...), and things got a lot better.
And if we focused instead on a robust suspend that most users could
use... how often would such a system need to do a full reboot instead
of a suspend? Every kernel update?
FC3 and RHEL 4 made a great leap forward. When I installed RHEL 4
on an old 400 MhZ machine, I booted the machine for the first time,
turned my back on it, expected it to still be grinding, and was amazed
to see that it was already up!
Right.. improvement without having to reach for parallelzation. We
still don't have a direct side by side comparison of a "default" set
of services that shows that paralization is going to be a worthwile
win on average hardware..let alone legacy hardware like a 400 Mhz
machine with what I imagine is below average ram compared to desktops
shipping now. You want to see a bootup process slowdown..have it
start swapping out memory because of competing processess. I have not
seen a convincing argument that parallelization can get to a boot time
much lower than continued optimization of the default init process we
have right now.
The big win, is suspend to disk, so that you can avoid doing the full
boot on day to day shutdown and restarts.
The starting and stopping experience makes a big difference in
the
experience of a computer. If it takes forever to boot your computer,
you leave it on all the time, wasting electricity and being a bigger
target for hackers.
I'm not arguing that.. I'm arguing that most day to day startup
situations do not have to be "full boot" situations they could be
"recover from suspend" and avoid service startup completely.
-jef
4:36 p.m.
Le mardi 15 novembre 2005 à 17:26 -0500, Jeff Spaleta a écrit :
On 11/15/05, Paul A Houle <ph18(a)cornell.edu> wrote:
> In the past, boot times have been a major complaint of ordinary
> consumers.
You missed my point entirely.
Why are we considering all "start up" situations as "full boot"
scenarios?
Why isn't focusing on suspend to disk scenarios a better win?
> Laura's first complaint about the machine was that it took forever
> to boot, and I realized she was right. I took about 2/3 of the stuff
> out of the boot sequence (HP laserjet drivers, asian language input
> methods...), and things got a lot better.
And if we focused instead on a robust suspend that most users could
use... how often would such a system need to do a full reboot instead
of a suspend? Every kernel update?
The problem is not so much in boot time but in service interdependencies
Just try to activate a service you didn't use before (or a new service)
- trying to locate all the other services it needs and to activate them
in the right order is power user stuff right now.
It gets worse with all the cool avahi/dbus/etc new services that do
nothing by themselves but are used by other stuff. The spaguetti plate
is growing
--
Nicolas Mailhot
8:34 a.m.
Jeff Spaleta wrote:
You missed my point entirely.
Why are we considering all "start up" situations as "full boot"
scenarios?
Why isn't focusing on suspend to disk scenarios a better win?
Software suspend seems to work well. I wouldn't be suprised if it
has problems at the 1-in-20 level.
A major reason for rebooting is to put the machine into a clear
state. I have some Linux desktops that are trouble-free (reboot for
kernel upgrades, power failures) but I've got some that have problems.
For instance, I've got one machine that sometimes loses the USB mouse
after I unplug the USB speakers -- maybe it's a hardware problem or
maybe a software problem... It doesn't happen all that often, but when
I do, a reboot fixes it.
It would be horrible to suspend the machine in a bad state and then
bring it back up in a bad state. I suppose that you could work out an
emacs-like scheme where we boot the machine, then dump an image of the
machine that lets us bring the machine back to a clean-boot state.
I'm not arguing that.. I'm arguing that most day to day
startup
situations do not have to be "full boot" situations they could be
"recover from suspend" and avoid service startup completely.
I won't argue with that. My guess is that the problems in getting
that working at the 1-in-1000 level are worse than getting parallel boot
to work at 1-in-10000. A next-gen init should be flexible enough that
it can support software suspend scenarios.
Another concern I'd have for ordinary users is the UI -- as I've
said, I find myself baffled by commercial OSes that make it hard to
turn off the machine (for instance, "Log Out" is the easy menu item to
hit on my Mac, despite the fact that we've got one account that people
actually log into and about 15 Unix accounts for various daemons the
machine runs.) Would ordinary users understand the difference between
shutting down, suspending and such? I, for one, have learned to
avoid all the "Suspend" and "Hibernate" options on Windows laptops,
since these often wedge the machine, forcing me to take the battery
out... I think we can do better with software suspend, but confusion
and bad UI could make a good feature into a curse.
12:05 a.m.
On Tue, 2005-11-15 at 17:11 -0500, Paul A Houle wrote:
Laura's first complaint about the machine was that it took
forever
to boot, and I realized she was right. I took about 2/3 of the stuff
out of the boot sequence (HP laserjet drivers, asian language input
methods...), and things got a lot better.
In my experience, the faster boot of Windows is just a bit of slight of
hand. Sure, you get to a graphical desktop faster, but everything is
still loading once you're there. This would be fine, except that you
can't even look through the start menu and have another service start
(or the start menu disappears - WTF?).
Of course, this situation on Linux would be a lot nice (the application
menu for starters doesn't close because another application starts (or
puts a window on the screen).
Of course, the biggest funny is why Windows starts so quickly. Users
got sick of having to reboot because Windows was so unstable, so to
address the problem, Microsoft made Windows reboot faster (instead of
fixing the crashes - Again, WTF?)
He he he.
Rodd
--
"It's a fine line between denial and faith.
It's much better on my side"
12:36 a.m.
On Wed, 2005-11-16 at 17:05 +1100, Rodd Clarkson wrote:
In my experience, the faster boot of Windows is just a bit of slight
of hand.
That's fine -- users (for whatever reasons that are not worth
debating), like that behavior. I think we'd do better if we
could start X faster, while other things are going on in the
background. (For fun, look at the first item on this page that
I have just stumbled across: http://kegel.com/linux/comfort/ ).
Going back to X, for a normal Linux install (no networked /home),
what do we _really_ need to start X? We need:
* The files. These we typically have on the HD that the
kernel booted from, so no additional time is needed.
* Video card. This is mostly there.
Everything else (including mouse and keyboard) can come later.
We should be able to bring X up well within 5 seconds. And if
we do bring it up fast enough, we can also drop the rhgb and
speed it up even more.
To do this right we need a proper API for services, one that
can be called from code to start/stop/wait_for/... a service.
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
3:49 p.m.
Le mardi 15 novembre 2005 à 15:36 -0600, Chris Adams a écrit :
I'm not convinced that parallel startup is such a great idea. A
lot of
work will be required to get (and keep) dependencies straight. Also, is
it really a win? Firing off a dozen things at once does not make them
finish 12 times faster; it can make them take longer.
Honestly, I don't care a little bit about the parallel part, but smarter
service ordering (*not* hardcoded startup numbers) wouldn't be luxury.
Anyone who tried to allocate a meaningful startup number to a service
taking into account all its deps permutations knows what I'm talking
about
--
Nicolas Mailhot
7:30 a.m.
--On Tuesday, November 15, 2005 4:12 PM -0500 Dimi Paun <dimi(a)lattica.com>
wrote:
From: "Luke Macken" <lmacken(a)redhat.com>
> o FAST AS HELL[0]
Fast, but can we do better?
It's funny how the discussion gets lost in a focus on speed, and the other
benefits that are more important to servers seem to get ignored (at least
for discussion).
To me the big wins are explicit expression of dependencies instead of
numbered start/stop order, and better integration with hot-plugging.
The speed is nice, but to me it's the ability of the system to describe the
desired relationships clearly that makes the admin's life more bearable.
9:07 a.m.
From: "Kenneth Porter" <shiva(a)sewingwitch.com>
It's funny how the discussion gets lost in a focus on speed, and
the other
benefits that are more important to servers seem to get ignored (at least
for discussion).
I don't understand why people think these topics are mutually exclusive.
There are clearly a number of different aspects when we discuss about
init replacement, all important to some group of people:
* dynamic dependencies
* hot plugging
* D-BUS integration
* speed
* parallel startup
* graphical boot
* proper API
* service monitoring
* automatic respawning of services
* on-demand startup of services
* backwards compatibility
They are all important, and each should be addressed. But we can not
do it all at once. If you want to discuss about a different aspect,
we should start a different thread.
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
10:42 a.m.
Kenneth Porter wrote:
It's funny how the discussion gets lost in a focus on speed, and the
other benefits that are more important to servers seem to get ignored
(at least for discussion).
To me the big wins are explicit expression of dependencies instead of
numbered start/stop order, and better integration with hot-plugging.
The speed is nice, but to me it's the ability of the system to
describe the desired relationships clearly that makes the admin's life
more bearable.
I'd like to see a system that's smart about dependencies, but I've
got some fear that the cure could be worse than the disease. I'd want
the ability to break the rules if I want to.
Another problem is that dependencies aren't always so clear: does
Apache depend upon Tomcat or does Tomcat depend on Apache?
* Apache can't handle .jsp files w/o Tomcat, but
* A Java application runs just fine in Tomcat, except that you need
Apache for the outside world to see it.
Tomcat gets wedged often, and needs a kick. I don't need to
restart the web server in this case. I often kick Apache because I
changed the configuration files... I don't need to trash the
application state in Tomcat when I do this. Although I want these
services to start together, things would go smoother if I could kick
them independently.
On the other hand, if you're using Oracle from PHP, you'll lose
your connection to the Listener if you kick Oracle and don't kick Apache.
I'm not completely happy with dependencies being represented in the
'init file' (or generalization thereof) because a dependency is a
function of two software systems, not a product of one. For instance,
imagine that I'm running the Apache that comes with Fedora/RH, and I'm
using it in a 'web services' or 'application server' mode where it
depends on some other daemons such as Tomcat, mcached, etc that I've
installed myself. Well, if I hacked the init script for Apache to add
the new dependencies, that may cause problems for rpm management.
(I've got this problem with the .desktop file system for creating
the Gnome menu -- I might want to attach my own categories such as
"Favorite" or "Available in Kiosk Mode", but hacking 100 .desktop
files
would be a disaster)
It might be easy to create 'virtual' services that are a bundle of
other services, and this might even be a replacement for numbered
runlevels... A 'desktop' service, for instance, brings up X Windows,
Xft, input method daemons and all that.
----
I think it's good that we're having a free-wheeling discussion of
all aspects of a new init system because it's important that it has a
design that embraces all of the things we're going to want to do with
it. A new init system ought to facilitate fast boot and it ought to be
flexible enough to support software suspend -- if we pick bad data
structures, we'll have a system that we'll be cursing for years to come.
I'm particularly concerned about customizability. Different shops
have different ideas about the 'right' way to manage systems, and there
are many questions that have no conclusive answer. It's one thing for
Gnome to be tough to customize (if I hate the panel, I can install a
different panel) but I'd hate to have to do surgery on initd for every
FC5 or RHEL 5 box I maintain.
11:06 a.m.
On Tue, 2005-11-15 at 16:12 -0500, Dimi Paun wrote:
From: "Luke Macken" <lmacken(a)redhat.com>
> o FAST AS HELL[0]
Fast, but can we do better? Why do we need to bring up
the networking before we start X? Also, is it feasible
to probe for just some hardware (disk, video), start x,
then continue with the hardware probing? Will it be any
faster if we get rid of the wrappers? Would readahead
help here at all?
Basically, can we have X up in 10s? :)
We sometimes need X to have network connectivity. The reason is a simple
one:
X is a network protocol and X is used to login remotely to other hosts.
GDM can query these hosts using XDM Broadcast iirc.
We also might need the authentication system to be up and running. That
can be LDAP or Kerberos or Samba or something else, which might require
network support.
There are many reasons I can think of that require network to be started
first. But it's mainly for the ones that I can't think of right now that
I hope we can get Network Support before X.
I doubt that we can have X up in 10s in some cases.
In my case I have to start 2 ethernet interfaces and 10 vlans and 4 vpn
and one pppoe connection before I get network support. Load the firewall
and start the quagga-bgp daemon. This will always take more than 10
seconds. After that the LDAP support must come up. And only then I am
willing to talk about GDM.
Then again, one that does not have all these to worry about, would be
fine having X start before network and LDAP.
Cheers,
Razvan
11:33 a.m.
From: "Răzvan Corneliu C.R. "d3vi1" VILT"
<razvan.vilt(a)linux360.ro>
Then again, one that does not have all these to worry about, would
be
fine having X start before network and LDAP.
And this is the point, one should not pay for something they don't use.
We have two alternatives to get that:
1. Have the init be flexible enough so that it can easily start X before
the network if at all possible.
2. Have an API so that software can wait for things. This way you can
start X, and if it reaches some code that needs networking (for XDMCP
for example), it can just say "wait for networking to be up".
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
3:22 p.m.
--On Tuesday, November 15, 2005 3:44 PM -0500 Luke Macken
<lmacken(a)redhat.com> wrote:
o Still supports the /etc/rc.d/rc$i.d framework (which is horrible
by
design)
What do packagers of services need to do to natively support the
alternatives? Presumably they need to supply the native equivalent to the
init.d script.
3:33 p.m.
Kenneth Porter wrote:
--On Tuesday, November 15, 2005 3:44 PM -0500 Luke Macken
<lmacken(a)redhat.com> wrote:
> o Still supports the /etc/rc.d/rc$i.d framework (which is horrible by
> design)
What do packagers of services need to do to natively support the
alternatives? Presumably they need to supply the native equivalent to
the init.d script.
It would be excellent if the glue code could be done in python:
- fast compared to shell scripts since there is no need to continually
fork/exec utilities
- non-intrusive: less patches to packages
- easy to write and maintain
I imagine an initng plugin should be feasible.
[there might be opposition to linking init with /usr/, but I consider it
outdated. we have initrd to mount our filesystems today]
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
3:38 p.m.
Once upon a time, Avi Kivity <avi(a)argo.co.il> said:
It would be excellent if the glue code could be done in python:
Requiring /usr be available before starting anything is not going to
work.
[there might be opposition to linking init with /usr/, but I consider
it
outdated. we have initrd to mount our filesystems today]
I don't really want to have to rebuild initrd anytime I change network
settings and such (think network shared /usr).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
3:40 p.m.
Chris Adams (cmadams(a)hiwaay.net) said:
Once upon a time, Avi Kivity <avi(a)argo.co.il> said:
> It would be excellent if the glue code could be done in python:
Requiring /usr be available before starting anything is not going to
work.
> [there might be opposition to linking init with /usr/, but I consider it
> outdated. we have initrd to mount our filesystems today]
I don't really want to have to rebuild initrd anytime I change network
settings and such (think network shared /usr).
OK, this is something I've been meaning to ask about - who
still uses network /usr, and why do you use that instead of
network / ?
Bill
3:43 p.m.
On Tue, 2005-11-15 at 16:40 -0500, Bill Nottingham wrote:
Chris Adams (cmadams(a)hiwaay.net) said:
> Once upon a time, Avi Kivity <avi(a)argo.co.il> said:
> > It would be excellent if the glue code could be done in python:
>
> Requiring /usr be available before starting anything is not going to
> work.
>
> > [there might be opposition to linking init with /usr/, but I consider it
> > outdated. we have initrd to mount our filesystems today]
>
> I don't really want to have to rebuild initrd anytime I change network
> settings and such (think network shared /usr).
OK, this is something I've been meaning to ask about - who
still uses network /usr, and why do you use that instead of
network / ?
And how do you get hard drives that are smaller than 40GB :)
-sv
3:56 p.m.
On Tue, 2005-11-15 at 16:40 -0500, Bill Nottingham wrote:
OK, this is something I've been meaning to ask about - who
still uses network /usr, and why do you use that instead of
network / ?
What about LTSP? They do some such over network.
--
Jesse Keating RHCE (http://geek.j2solutions.net)
Fedora Legacy Team (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
4:26 p.m.
On Tue, 2005-11-15 at 13:56 -0800, Jesse Keating wrote:
On Tue, 2005-11-15 at 16:40 -0500, Bill Nottingham wrote:
>
> OK, this is something I've been meaning to ask about - who
> still uses network /usr, and why do you use that instead of
> network / ?
What about LTSP? They do some such over network.
LTSP in its current incarnation does Network / rather than /usr.
-Tos
4:13 p.m.
Once upon a time, Bill Nottingham <notting(a)redhat.com> said:
OK, this is something I've been meaning to ask about - who
still uses network /usr, and why do you use that instead of
network / ?
I don't currently use network /usr, but I typically have /usr on a
separate fs from / (at least on servers). I then can mount /usr
read-only which means:
- no writes - less chance of an "oops" (either due to kernel fs error or
user admin error)
- in the case someone does break into the system somehow, less chance of
them doing anything meaningful (since they'd have to know to remount
/usr read-write)
- / is smaller - less to go wrong/get screwed up that would keep the
system from at least booting in emergency mode
Network / would only be useful between identical systems using DHCP,
since /etc contains users/passwords, network config, hardware config,
etc., unless you want to make /etc a separate fs (which has the same
problems as trying to mount /usr from initrd).
Other problems with /usr being mounted from initrd are handling fsck,
/usr on different device from / that requires additional init, etc.
Look at what happens in rc.sysinit before other filesystems are mounted.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
4:37 p.m.
notting(a)redhat.com (Bill Nottingham) writes:
> > [there might be opposition to linking init with /usr/, but
I
> > consider it outdated. we have initrd to mount our filesystems
> > today]
>
> I don't really want to have to rebuild initrd anytime I change network
> settings and such (think network shared /usr).
OK, this is something I've been meaning to ask about - who
still uses network /usr, and why do you use that instead of
network / ?
It's not only a network /usr. It is an issue with the traditional
splitting of /, /usr and /var too. These filesystems can not be used
by init but must be made available by it (which is a non-trivial task
because it requires e.g. module-loading, fsck or lvm setup).
Enrico
3:54 p.m.
Chris Adams wrote:
Once upon a time, Avi Kivity <avi(a)argo.co.il> said:
>It would be excellent if the glue code could be done in python:
>
>
Requiring /usr be available before starting anything is not going to
work.
We require /. We require initrd.
>[there might be opposition to linking init with /usr/, but I
consider it
>outdated. we have initrd to mount our filesystems today]
>
>
I don't really want to have to rebuild initrd anytime I change network
settings and such (think network shared /usr).
I'm sure we can arrange initrd to look at the command line. For example:
mount=/=server1:/path/to/root,/usr=server2:/path/to/usr
IP can already be configured this way.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
4:16 p.m.
Once upon a time, Avi Kivity <avi(a)argo.co.il> said:
We require /. We require initrd.
initrd is not currently required. It is for out-of-the-box setups, but
you can:
a) not use LVM for root
b) not use ext3 for root or rebuild kernel with ext3 included
c) use hardware that doesn't require modules for root device or rebuild
kernel with drivers included
I'm sure we can arrange initrd to look at the command line. For
example:
mount=/=server1:/path/to/root,/usr=server2:/path/to/usr
IP can already be configured this way.
That's a pretty ugly hack just to get python support for startup. Also,
that is limited; the kernel command line has a limit that isn't all that
big. You also then need to handle fsck and such in initrd for
non-network filesystems.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
1:02 a.m.
Chris Adams wrote:
Once upon a time, Avi Kivity <avi(a)argo.co.il> said:
>We require /. We require initrd.
>
>
initrd is not currently required. It is for out-of-the-box setups, but
you can:
a) not use LVM for root
b) not use ext3 for root or rebuild kernel with ext3 included
c) use hardware that doesn't require modules for root device or rebuild
kernel with drivers included
seems very close to "required" to me.
>I'm sure we can arrange initrd to look at the command line.
For example:
>
> mount=/=server1:/path/to/root,/usr=server2:/path/to/usr
>
>IP can already be configured this way.
>
>
That's a pretty ugly hack just to get python support for startup.
It's not just for python; it's to avoid dependency on a very small
subset of functionaly present in /bin and /sbin. For flexibility.
Also,
that is limited; the kernel command line has a limit that isn't all that
big.
This limit is going away.
You also then need to handle fsck and such in initrd for
non-network filesystems.
This can be handled in the same way that fsck / is done.
The point is that we have two (well, more, but in this context just two)
bootstrap sequences: initrd -> / and / -> rest of world. the first
bootstrap does not leave permanent effects, but the second does, and
these hurt. Eliminating the second stage would simplify the system and
open the door for many improvements.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
4:54 p.m.
On Tue, Nov 15, 2005 at 03:44:05PM -0500, Luke Macken wrote:
o FAST AS HELL[0]
Perhaps that because the comparison is comparing
different things. Ie, the faster of the two
isn't running cups, firewire, alsa, usb etc
(In fact, none of the stuff forked from udev)
Without that scanning, aiui, we'll fail to pick
up for eg, USB keys left inserted at boot,
requiring an unplug-replug action before they
get seen.
Dave
5:10 p.m.
From: "Dave Jones" <davej(a)redhat.com>
Without that scanning, aiui, we'll fail to pick
up for eg, USB keys left inserted at boot,
requiring an unplug-replug action before they
get seen.
Shouldn't we get a plug event when we do detect it?
This way there would be no difference between the
initial scan and any subsequent unplug/plug events.
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
5:13 p.m.
On Tue, Nov 15, 2005 at 06:10:26PM -0500, Dimi Paun wrote:
From: "Dave Jones" <davej(a)redhat.com>
> Without that scanning, aiui, we'll fail to pick
> up for eg, USB keys left inserted at boot,
> requiring an unplug-replug action before they
> get seen.
Shouldn't we get a plug event when we do detect it?
This way there would be no difference between the
initial scan and any subsequent unplug/plug events.
That's what I'm saying. Looking at the chart,
it looks like the plug events never happen, as
udev doesn't seem to be scanning anything any more.
Dave
6735
days inactive
6738
days old
72 comments
27 participants
participants (27)
-
Alan Cox -
Avi Kivity -
Bill Nottingham -
Chris Adams -
Dave Jones -
Dave Mitchell -
David Malcolm -
Dimi Paun -
dragoran -
Enrico Scholz -
Ignacio Vazquez-Abrams -
Jef Spaleta -
Jesse Keating -
Keith Sharp -
Kenneth Porter -
Lamont R. Peterson -
Luke Macken -
Mike A. Harris -
Mike Chambers -
Nicolas Mailhot -
Paul A Houle -
Rahul Sundaram -
Razvan Corneliu C.R. "d3vi1" VILT -
Rodd Clarkson -
seth vidal -
Stephen John Smoogen -
Toshio Kuratomi