8:47 a.m.
http://www.harald-hoyer.de/personal/blog/fedora-10-boot-analysis
A brief Fedora 10 boot analysis.
Hardware: Asus EeePC 901 with a flash disk.
Time taken from entering the encrypted root disk password until the password can
be entered (after pressing return in gdm). The 10 second wait in nash is ignored
here (which really annoys me and should be configurable in /etc/sysconfig/mkinitrd).
Default Live CD Installation: 39s (bootchart
http://www.harald-hoyer.de/files/f10boot/bootchart-nonread.png)
After installing readahead and running one collection boot process: 36s
(bootchart http://www.harald-hoyer.de/files/f10boot/bootchart-readahead.png)
At this point, I recognized that all processes (NetworkManager and newaliases),
which call a fsync(), let the boot process wait until all data is written to
disk. This is the same effect as the firefox sqlite fsync bug
http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/.
Mounting the root filessystem with relatime and turning off ordered data writing
for the journal with
# tune2fs -o journal_data_writeback /dev/root
improved the situation (even though data might be old on the disk after a crash,
but ext3 does not force the disk to empty the write cache anyway).
Turning off setroubleshoot and fixing
https://bugzilla.redhat.com/show_bug.cgi?id=476023 and
https://bugzilla.redhat.com/show_bug.cgi?id=476028: 32s (bootchart
http://www.harald-hoyer.de/files/f10boot/bootchart-readahead-nosetrouble.png)
Turning off bootchart: 30s
So all in all we have nearly accomplished the 30 Second Startup Feature
http://fedoraproject.org/wiki/Features/30SecondStartup.
To reach the 20 Second Startup Feature
http://fedoraproject.org/wiki/Features/20SecondStartup, we really have to tackle
setroubleshootd. Also we might start to move basic services to upstart and start
them in parallel (bootchart with some services moved
http://www.harald-hoyer.de/files/f10boot/bootchart-readahead-nosetrouble-...).
Parallel booting will show now benefits with readahead and a small amount of
active services, but the more services are turned on, the more you benefit with
a parallel boot setup. Moving more basic modules to be compiled in the kernel
also would gain some seconds. Speaking about modules, I ported Jakubs modprobe
patch to the recent 3.6pre1 module-init-tools version. Though it nearly halves
I/O, it would only safe us a fraction of a second here (not recognizable).
In the end, we also have to extend our view to things that happen after the user
logs in (bootchart http://www.harald-hoyer.de/files/f10boot/bootchart-full.png)
and do an extended analysis. Work is also in progress by Gnome developer Behdad
Esfahbod http://mces.blogspot.com/2008/12/improving-login-time-part-3.html.
8:54 a.m.
On Mon, Dec 15, 2008 at 15:47:32 +0100,
Harald Hoyer <harald(a)redhat.com> wrote:
Time taken from entering the encrypted root disk password until the
password can be entered (after pressing return in gdm). The 10 second
wait in nash is ignored here (which really annoys me and should be
configurable in /etc/sysconfig/mkinitrd).
If you are referring to bug 470628, that is fixed now with mkinitrd-6.0.71-3.
9:03 a.m.
Bruno Wolff III wrote:
On Mon, Dec 15, 2008 at 15:47:32 +0100,
Harald Hoyer <harald(a)redhat.com> wrote:
> Time taken from entering the encrypted root disk password until the
> password can be entered (after pressing return in gdm). The 10 second
> wait in nash is ignored here (which really annoys me and should be
> configurable in /etc/sysconfig/mkinitrd).
If you are referring to bug 470628, that is fixed now with mkinitrd-6.0.71-3.
ah :) very nice :)
9:06 a.m.
On Mon, 2008-12-15 at 15:47 +0100, Harald Hoyer wrote:
http://www.harald-hoyer.de/personal/blog/fedora-10-boot-analysis
A brief Fedora 10 boot analysis.
Hardware: Asus EeePC 901 with a flash disk.
Time taken from entering the encrypted root disk password until the password can
be entered (after pressing return in gdm). The 10 second wait in nash is ignored
here (which really annoys me and should be configurable in /etc/sysconfig/mkinitrd).
Default Live CD Installation: 39s (bootchart
http://www.harald-hoyer.de/files/f10boot/bootchart-nonread.png)
After installing readahead and running one collection boot process: 36s
(bootchart http://www.harald-hoyer.de/files/f10boot/bootchart-readahead.png)
At this point, I recognized that all processes (NetworkManager and newaliases),
Odd, NM isn't intentionally calling fsync() (it's not anywhere in the
code), nor does glib do that anywhere that I can find. I can't think of
anything that would require an fsync for NM, so I'm interested in
finding this and killing it.
dan
which call a fsync(), let the boot process wait until all data is
written to
disk. This is the same effect as the firefox sqlite fsync bug
http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/.
Mounting the root filessystem with relatime and turning off ordered data writing
for the journal with
# tune2fs -o journal_data_writeback /dev/root
improved the situation (even though data might be old on the disk after a crash,
but ext3 does not force the disk to empty the write cache anyway).
Turning off setroubleshoot and fixing
https://bugzilla.redhat.com/show_bug.cgi?id=476023 and
https://bugzilla.redhat.com/show_bug.cgi?id=476028: 32s (bootchart
http://www.harald-hoyer.de/files/f10boot/bootchart-readahead-nosetrouble.png)
Turning off bootchart: 30s
So all in all we have nearly accomplished the 30 Second Startup Feature
http://fedoraproject.org/wiki/Features/30SecondStartup.
To reach the 20 Second Startup Feature
http://fedoraproject.org/wiki/Features/20SecondStartup, we really have to tackle
setroubleshootd. Also we might start to move basic services to upstart and start
them in parallel (bootchart with some services moved
http://www.harald-hoyer.de/files/f10boot/bootchart-readahead-nosetrouble-...).
Parallel booting will show now benefits with readahead and a small amount of
active services, but the more services are turned on, the more you benefit with
a parallel boot setup. Moving more basic modules to be compiled in the kernel
also would gain some seconds. Speaking about modules, I ported Jakubs modprobe
patch to the recent 3.6pre1 module-init-tools version. Though it nearly halves
I/O, it would only safe us a fraction of a second here (not recognizable).
In the end, we also have to extend our view to things that happen after the user
logs in (bootchart http://www.harald-hoyer.de/files/f10boot/bootchart-full.png)
and do an extended analysis. Work is also in progress by Gnome developer Behdad
Esfahbod http://mces.blogspot.com/2008/12/improving-login-time-part-3.html.
9:18 a.m.
Dan Williams wrote:
On Mon, 2008-12-15 at 15:47 +0100, Harald Hoyer wrote:
> http://www.harald-hoyer.de/personal/blog/fedora-10-boot-analysis
>
> A brief Fedora 10 boot analysis.
>
> Hardware: Asus EeePC 901 with a flash disk.
>
> Time taken from entering the encrypted root disk password until the password can
> be entered (after pressing return in gdm). The 10 second wait in nash is ignored
> here (which really annoys me and should be configurable in /etc/sysconfig/mkinitrd).
>
> Default Live CD Installation: 39s (bootchart
> http://www.harald-hoyer.de/files/f10boot/bootchart-nonread.png)
>
> After installing readahead and running one collection boot process: 36s
> (bootchart http://www.harald-hoyer.de/files/f10boot/bootchart-readahead.png)
>
> At this point, I recognized that all processes (NetworkManager and newaliases),
Odd, NM isn't intentionally calling fsync() (it's not anywhere in the
code), nor does glib do that anywhere that I can find. I can't think of
anything that would require an fsync for NM, so I'm interested in
finding this and killing it.
http://www.harald-hoyer.de/files/bootchart-16.png
looks very much like it... but I could be wrong, though.
dan
9:26 a.m.
Harald Hoyer wrote:
http://www.harald-hoyer.de/files/bootchart-16.png
looks very much like it... but I could be wrong, though.
with newaliases this was 100% reproducable.
>
> dan
>
12:28 p.m.
On Mon, Dec 15, 2008 at 04:26:55PM +0100, Harald Hoyer wrote:
> http://www.harald-hoyer.de/files/bootchart-16.png
with newaliases this was 100% reproducable.
The fdatasync call comes from db4.
It would be nice if newaliases was executed only when /etc/aliases.db
is older than /etc/aliases, but other MTAs may use the same db file,
so it needs to be updated also after switching mta in the alternatives
system.
Maybe copy the timestamp in the init script to another file and don't
call newaliases only when the timestamps are equal?
Suggestions welcomed.
--
Miroslav Lichvar
5:08 a.m.
On Mon, 15 Dec 2008 19:28:23 +0100
Miroslav Lichvar <mlichvar(a)redhat.com> wrote:
Suggestions welcomed.
how about not running a full MTA on a laptop/client install... at all?
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
5:44 a.m.
> Suggestions welcomed.
how about not running a full MTA on a laptop/client install... at all?
I agree. Any of the daemons such as cron, or the jobs that run through
them mail locally by default and in most desktop/laptop style of use
that would never be changed. So to have a full blown MTA for local
delivery is overkill for a vast majority of situations. I filed a bug
[1] against cronie for OLPC when it started pulling in exim because I
think it was basically first on the list to provide
/usr/sbin/sendmail. It was mentioned in the bug that MTAs that can do
local delivery and other local delivery agents (procmail?) should
provide mail(local) and then those sort of apps Require it rather than
the explicit sendmail binary. I'm not sure how that deals with the
exim style first in the list though. Anyone who works out that they
want the mail delivered elsewhere should be able to work out how to
install a full MTA.
Peter
[1] https://bugzilla.redhat.com/show_bug.cgi?id=472710
7:01 a.m.
On Tue, Dec 16, 2008 at 12:44:16PM +0100, Peter Robinson wrote:
>> Suggestions welcomed.
>
> how about not running a full MTA on a laptop/client install... at all?
that would never be changed. So to have a full blown MTA for local
delivery is overkill for a vast majority of situations. I filed a bug
It is true, but more to the point, full blown MTA can do local delivery
without being started as daemons. So no MTA should be started in the
default case.
That being said using a specific provides for local mail delivery,
like mail(local), such that something lighter than full blown MTAs,
like esmtp+procmail can be used as cronie dependency is a good thing,
but it avoids dependency bloat, not startup time bloat.
--
Pat
8:11 a.m.
On Tue, Dec 16, 2008 at 02:01:37PM +0100, Patrice Dumas wrote:
On Tue, Dec 16, 2008 at 12:44:16PM +0100, Peter Robinson wrote:
> >> Suggestions welcomed.
> >
> > how about not running a full MTA on a laptop/client install... at all?
>
> that would never be changed. So to have a full blown MTA for local
> delivery is overkill for a vast majority of situations. I filed a bug
It is true, but more to the point, full blown MTA can do local delivery
without being started as daemons. So no MTA should be started in the
default case.
With default configuration, only exim can deliver directly. Postfix
and sendmail need a daemon running or a cron job to actually deliver
the mail.
--
Miroslav Lichvar
8:20 a.m.
On Tue, Dec 16, 2008 at 03:11:56PM +0100, Miroslav Lichvar wrote:
With default configuration, only exim can deliver directly. Postfix
and sendmail need a daemon running or a cron job to actually deliver
the mail.
I recall an somewhat old thread in which it was told that sendmail
didn't need to be run to perform local delivery. I don't have the
reference at hand, though, and I don't know myself.
At least MTA that don't need to be started as a daemon for local
delivery should not (and, in my opinion, it is a valid point for
changing the default in comps).
--
Pat
8:26 a.m.
Miroslav Lichvar wrote:
On Tue, Dec 16, 2008 at 02:01:37PM +0100, Patrice Dumas wrote:
> On Tue, Dec 16, 2008 at 12:44:16PM +0100, Peter Robinson wrote:
>>>> Suggestions welcomed.
>>> how about not running a full MTA on a laptop/client install... at all?
>> that would never be changed. So to have a full blown MTA for local
>> delivery is overkill for a vast majority of situations. I filed a bug
> It is true, but more to the point, full blown MTA can do local delivery
> without being started as daemons. So no MTA should be started in the
> default case.
With default configuration, only exim can deliver directly. Postfix
and sendmail need a daemon running or a cron job to actually deliver
the mail.
But note that (a) the daemon startup can be delayed so as not to impact
bootup time and (b) making sleep/hibernate reliable is what laptop users
need instead of booting all the time anyway because it is much faster if
you can simply close the lid and open it later with all your apps
working as you left them.
--
Les Mikesell
lesmikesell(a)gmail.com
3:03 p.m.
Les Mikesell wrote:
(b) making sleep/hibernate reliable is what laptop users
need instead of booting all the time anyway because it is much faster if
you can simply close the lid and open it later with all your apps
working as you left them.
This is actually the strongest argument against spending a lot of resources on
going sub 20 seconds. If Vista-style suspend-to-both works reliably, there is
no reason to turn a machine off at all.
That said, doesn't mean we shouldn't clean up cruft.
Hans de Goede wrote:
2) Load some services after gdm is up, for example cron, anacron,
at,
setroubleshootd
Please, no setroubleshootd by default. What's the point? Read section "The
rest" in my blog post:
http://mces.blogspot.com/2008/12/improving-login-time-part-3.html
Horst H. von Brand wrote:
> how about not running a full MTA on a laptop/client install... at
all?
That works if you have reliable, continuous access to the 'net. Not my
case, sorry.
Don't you have to configure the MTA if you want to use it? I mean, when a
normal user configures Thunderbird/Evo/... it puts the SMTP address that their
mail provider gave them (smtp.gmail.com, etc), NOT localhost. If you are an
advanced-enough user to set it to localhost and configure your MTA to point it
to your remote SMTP server, sure you don't mind a "yum install sendmail"
first, do you?
I always wondered what the point of having a mail server installed and started
by default is. The only use I have found for it is to deliver reports to
root. But on my typical Fedora installs (that is, anything other than
servers), I don't read root mail. The default MTA is simply useless for
normal desktop/laptop machine unless you configure it. As such, it should be
turned off by default, and hence removed from default install.
Not it surprises me that every time I suggest something should be turned off
by default, someone shouts "please, no, I use that!"...
Matej Cepl wrote:
On 2008-12-16, 16:09 GMT, Peter Robinson wrote:
> Nothing to say you can't re-enable it yourself. I don't have a
> permanent connection to the net but evolution happily holds it in my
> outbox until I go back online and can connect to a network. Fedora can
I have a nasty surprise for you -- Fedora is not Windows, so it
would is not only for people who use Evolution / Kmail
/ Thunderbird.
See above. On a similar line of though, how about: "please install and enable
httpd, postgresql, and squid" by default because I use them...
behdad
3:41 p.m.
On Tue, 16 Dec 2008, Behdad Esfahbod wrote:
Les Mikesell wrote:
> (b) making sleep/hibernate reliable is what laptop users
> need instead of booting all the time anyway because it is much faster if
> you can simply close the lid and open it later with all your apps
> working as you left them.
This is actually the strongest argument against spending a lot of resources on
going sub 20 seconds. If Vista-style suspend-to-both works reliably, there is
no reason to turn a machine off at all.
suspend uses LITTLE power but not none
hiberate uses no power but only happens when you've drained power already
so a good reason to power off is simply to save power
-sv
3:47 p.m.
Seth Vidal wrote:
On Tue, 16 Dec 2008, Behdad Esfahbod wrote:
> Les Mikesell wrote:
>
>> (b) making sleep/hibernate reliable is what laptop users
>> need instead of booting all the time anyway because it is much faster if
>> you can simply close the lid and open it later with all your apps
>> working as you left them.
>
> This is actually the strongest argument against spending a lot of
> resources on
> going sub 20 seconds. If Vista-style suspend-to-both works reliably,
> there is
> no reason to turn a machine off at all.
>
suspend uses LITTLE power but not none
hiberate uses no power but only happens when you've drained power already
so a good reason to power off is simply to save power
Or hibernate?
-sv
4:16 p.m.
On Tue, 16 Dec 2008, Behdad Esfahbod wrote:
Seth Vidal wrote:
>
> On Tue, 16 Dec 2008, Behdad Esfahbod wrote:
>
>> Les Mikesell wrote:
>>
>>> (b) making sleep/hibernate reliable is what laptop users
>>> need instead of booting all the time anyway because it is much faster if
>>> you can simply close the lid and open it later with all your apps
>>> working as you left them.
>>
>> This is actually the strongest argument against spending a lot of
>> resources on
>> going sub 20 seconds. If Vista-style suspend-to-both works reliably,
>> there is
>> no reason to turn a machine off at all.
>>
>
> suspend uses LITTLE power but not none
> hiberate uses no power but only happens when you've drained power already
>
> so a good reason to power off is simply to save power
Or hibernate?
At least on my system hibernate takes as much time as a reboot.
And as jesse said - we still need to reboot for kernels, dbus, all sorts
of stuff.
-sv
4:46 p.m.
On Tue, 2008-12-16 at 17:16 -0500, Seth Vidal wrote:
On Tue, 16 Dec 2008, Behdad Esfahbod wrote:
> Seth Vidal wrote:
>> so a good reason to power off is simply to save power
>
> Or hibernate?
At least on my system hibernate takes as much time as a reboot.
We should really work on fixing that too... :)
Jeremy
9:02 p.m.
On Tue, Dec 16, 2008 at 05:46:31PM -0500, Jeremy Katz wrote:
On Tue, 2008-12-16 at 17:16 -0500, Seth Vidal wrote:
> At least on my system hibernate takes as much time as a reboot.
We should really work on fixing that too... :)
Mm. When you say we...
(Humour. This is a genuinely difficult problem and one that inovolves
basically rearchitecting the current implementation)
--
Matthew Garrett | mjg59(a)srcf.ucam.org
9:11 p.m.
On Wed, 2008-12-17 at 03:02 +0000, Matthew Garrett wrote:
(Humour. This is a genuinely difficult problem and one that inovolves
basically rearchitecting the current implementation)
HibernateKit ?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
9:21 p.m.
On Tue, Dec 16, 2008 at 07:11:47PM -0800, Jesse Keating wrote:
On Wed, 2008-12-17 at 03:02 +0000, Matthew Garrett wrote:
> (Humour. This is a genuinely difficult problem and one that inovolves
> basically rearchitecting the current implementation)
HibernateKit ?
Writing 4 gigs of RAM to swap at 20 meg/sec = 1 minute 25 seconds. I
don't see much way around this.
12:17 a.m.
On Tue, 2008-12-16 at 22:21 -0500, Chuck Anderson wrote:
On Tue, Dec 16, 2008 at 07:11:47PM -0800, Jesse Keating wrote:
> On Wed, 2008-12-17 at 03:02 +0000, Matthew Garrett wrote:
> > (Humour. This is a genuinely difficult problem and one that inovolves
> > basically rearchitecting the current implementation)
>
> HibernateKit ?
Writing 4 gigs of RAM to swap at 20 meg/sec = 1 minute 25 seconds. I
don't see much way around this.
Why would you need to do that? I mean I can understand that it's
probably "easy" to do it that way ... but how much harder is it to do:
1. Write all the dirty pages to swap/disk.
2. Drop all the clean droppable pages.
3. write out what's left.
--
James Antill <james(a)fedoraproject.org>
Fedora
7:58 a.m.
On Wed, Dec 17, 2008 at 01:17:42AM -0500, James Antill wrote:
On Tue, 2008-12-16 at 22:21 -0500, Chuck Anderson wrote:
> On Tue, Dec 16, 2008 at 07:11:47PM -0800, Jesse Keating wrote:
> > On Wed, 2008-12-17 at 03:02 +0000, Matthew Garrett wrote:
> > > (Humour. This is a genuinely difficult problem and one that inovolves
> > > basically rearchitecting the current implementation)
> >
> > HibernateKit ?
>
> Writing 4 gigs of RAM to swap at 20 meg/sec = 1 minute 25 seconds. I
> don't see much way around this.
Why would you need to do that? I mean I can understand that it's
probably "easy" to do it that way ... but how much harder is it to do:
1. Write all the dirty pages to swap/disk.
2. Drop all the clean droppable pages.
3. write out what's left.
Oh, it probably does like you say. Maybe it's only 2 gigs then. It
still takes on the order of 2 minutes to hibernate, and even longer
than that for resume including swapping back in after the strict
resume part is done. Maybe hibernate-to-flash would be fast enough to
make it worthwhile.
The main reason I hibernate is to save the state of what I was working
on before. Rebooting could be a solution to this if:
- Rebooting is fast enough. This is what this thread is about.
- Applications were written to save state as a matter of normal
operation. Firefox is pretty good at this these days. See also
"Crash-Only Software" [1].
- gnome-session didn't break session saving support, or Fedora didn't
consume the broken GNOME release with
known-to-be-broken-session-support [2], and
we-wont-fix-this-until-the-resdesign-of-session-support-is-done
[3][4].
[1] http://en.wikipedia.org/wiki/Crash-only_software
[2] http://bugzilla.gnome.org/show_bug.cgi?id=552387
[3] http://live.gnome.org/SessionManagement/NewGnomeSession
[4] http://blogs.gnome.org/metacity/2008/03/08/session-management/
9:52 a.m.
Chuck Anderson wrote:
The main reason I hibernate is to save the state of what I was working
on before. Rebooting could be a solution to this if:
- Rebooting is fast enough. This is what this thread is about.
- Applications were written to save state as a matter of normal
operation. Firefox is pretty good at this these days. See also
"Crash-Only Software" [1].
It's fairly easy to save state in a program that only uses a stateless
protocol...
---
Les Mikesell
lesmikesell(a)gmail.com
1:10 a.m.
Chuck Anderson wrote:
On Tue, Dec 16, 2008 at 07:11:47PM -0800, Jesse Keating wrote:
> On Wed, 2008-12-17 at 03:02 +0000, Matthew Garrett wrote:
>> (Humour. This is a genuinely difficult problem and one that inovolves
>> basically rearchitecting the current implementation)
> HibernateKit ?
Writing 4 gigs of RAM to swap at 20 meg/sec = 1 minute 25 seconds. I
don't see much way around this.
On a laptop, can't you suspend first, then hibernate only if power drops
dangerously low (and while no one is waiting)?
--
Les Mikesell
lesmikesell(a)gmail.com
1:24 a.m.
On 17.12.2008 08:10, Les Mikesell wrote:
Chuck Anderson wrote:
> On Tue, Dec 16, 2008 at 07:11:47PM -0800, Jesse Keating wrote:
>> On Wed, 2008-12-17 at 03:02 +0000, Matthew Garrett wrote:
>>> (Humour. This is a genuinely difficult problem and one that inovolves
>>> basically rearchitecting the current implementation)
>> HibernateKit ?
> Writing 4 gigs of RAM to swap at 20 meg/sec = 1 minute 25 seconds. I
> don't see much way around this.
On a laptop, can't you suspend first, then hibernate only if power drops
dangerously low (and while no one is waiting)?
You would need to power up to hibernate -- not something laptops should
do automatically, as they might be in a bag without fresh air for
cooling (which obviously could lead to damaged hardware if hibernating
fails).
CU
knurd
1:48 a.m.
Thorsten Leemhuis wrote:
>>> HibernateKit ?
>> Writing 4 gigs of RAM to swap at 20 meg/sec = 1 minute 25 seconds. I
>> don't see much way around this.
> On a laptop, can't you suspend first, then hibernate only if power
> drops dangerously low (and while no one is waiting)?
You would need to power up to hibernate -- not something laptops should
do automatically, as they might be in a bag without fresh air for
cooling (which obviously could lead to damaged hardware if hibernating
fails).
I thought my old G4 powerbook did that years ago - and current XP. Did
I imagine that?
--
Les Mikesell
lesmikesell(a)gmail.com
9:16 p.m.
On Wed, 2008-12-17 at 01:10 -0600, Les Mikesell wrote:
On a laptop, can't you suspend first, then hibernate only if
power drops
dangerously low (and while no one is waiting)?
...but what if the user wants to open up and use the system again,
without plugging it in, six hours later?
This is the fundamental problem with hybrid suspend: it has to make a
guess (when to stop suspending and start hibernating), and it can't
always guess right. Practically speaking, some people will always need
to say "go straight to hibernate".
--
adamw
1:51 a.m.
On Tue, 16 Dec 2008 17:16:36 -0500 (EST)
Seth Vidal <skvidal(a)fedoraproject.org> wrote:
> Or hibernate?
At least on my system hibernate takes as much time as a reboot.
btw this is a very fundamental property of hibernate. You need to do all
disk IO to get the system state to disk. And then at resume, you need
to do all disk IO to get the state from disk again. That's twice ;)
This is compounded by the property that a hibernate tends to flush at
least half the disk cache (it has to, to get space to work in), which
you then need to page right back in, so even when you're back, the first
minute or two sucks badly.
I suspect you will always be able to boot faster than you can
hibernate+resume.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
1:59 a.m.
Arjan van de Ven wrote:
I suspect you will always be able to boot faster than you can
hibernate+resume.
Hard to argue with that. But if hibernate is the less common thing, and 90%
of time suspend works, it's a win. And lets not forget that hibernate gets
you back where you left, where shutdown/boot-up doesn't.
I know suspend-to-both doesn't work and is not expected to work soon. But
just making suspend work reliably gets us mostly there. My laptop suspends
and resumes in about 5 seconds each way. And fails perhaps once every 30
suspends. Has done wonders. I can't imagine having to shutdown all the time.
behdad
1:52 p.m.
On Wednesday 17 December 2008, Arjan van de Ven wrote:
On Tue, 16 Dec 2008 17:16:36 -0500 (EST)
Seth Vidal <skvidal(a)fedoraproject.org> wrote:
> > Or hibernate?
>
> At least on my system hibernate takes as much time as a reboot.
btw this is a very fundamental property of hibernate. You need to do all
disk IO to get the system state to disk. And then at resume, you need
to do all disk IO to get the state from disk again. That's twice ;)
This is compounded by the property that a hibernate tends to flush at
least half the disk cache (it has to, to get space to work in), which
you then need to page right back in, so even when you're back, the first
minute or two sucks badly.
I suspect you will always be able to boot faster than you can
hibernate+resume.
I have very different experience. For example comparable (from grub going
away to KDE + my bunch of default apps running and usable) numbers just taken
from the desktop box in front of which I'm right now (AMD64 3200, 2G RAM,
SATA, F-9 x86_64 KDE):
- shutdown: 28 sec
- fresh boot: 66 sec
- suspend to disk: 17 sec
- resume from disk: 23 sec
Shutdown takes a ~5 second penalty compared to suspend to disk due to the
shutdown sound during which everything else appears to be idling, and fresh
boot takes a bit of a penalty because my most recent readahead-collector run
(using the F-10 one) is not very recent, but the numbers speak for themselves
anyway. Also, I have a gut feeling that the sluggishness for a while after
the desktop is up is clearly worse on a fresh reboot than in resume from disk
case. But it's possible that I misremember this one - I haven't really shut
down/rebooted except for kernel updates in almost half a year.
2:44 a.m.
On Wed, 17 Dec 2008 21:52:30 +0200
Ville Skyttä <ville.skytta(a)iki.fi> wrote:
On Wednesday 17 December 2008, Arjan van de Ven wrote:
> On Tue, 16 Dec 2008 17:16:36 -0500 (EST)
>
> Seth Vidal <skvidal(a)fedoraproject.org> wrote:
> > > Or hibernate?
> >
> > At least on my system hibernate takes as much time as a reboot.
>
> btw this is a very fundamental property of hibernate. You need to
> do all disk IO to get the system state to disk. And then at resume,
> you need to do all disk IO to get the state from disk again. That's
> twice ;)
>
> This is compounded by the property that a hibernate tends to flush
> at least half the disk cache (it has to, to get space to work in),
> which you then need to page right back in, so even when you're
> back, the first minute or two sucks badly.
>
> I suspect you will always be able to boot faster than you can
> hibernate+resume.
I have very different experience. For example comparable (from grub
going away to KDE + my bunch of default apps running and usable)
numbers just taken from the desktop box in front of which I'm right
now (AMD64 3200, 2G RAM, SATA, F-9 x86_64 KDE):
- shutdown: 28 sec
- fresh boot: 66 sec
see this is the problem; this can be 5 to 10 seconds, and should be.
that's the point of this discussion
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
10:47 a.m.
On Thursday 18 December 2008, Arjan van de Ven wrote:
On Wed, 17 Dec 2008 21:52:30 +0200
Ville Skyttä <ville.skytta(a)iki.fi> wrote:
> - shutdown: 28 sec
> - fresh boot: 66 sec
see this is the problem; this can be 5 to 10 seconds, and should be.
that's the point of this discussion
Well, you said earlier:
> > I suspect you will always be able to boot faster than you
can
> > hibernate+resume.
Maybe I'm just having a problem parsing that. Does "will" here mean that it
will be like that in the future after $something gets done?
4:50 a.m.
On Thu, 18 Dec 2008 18:47:34 +0200
Ville Skyttä <ville.skytta(a)iki.fi> wrote:
On Thursday 18 December 2008, Arjan van de Ven wrote:
> On Wed, 17 Dec 2008 21:52:30 +0200
> Ville Skyttä <ville.skytta(a)iki.fi> wrote:
> > - shutdown: 28 sec
> > - fresh boot: 66 sec
>
> see this is the problem; this can be 5 to 10 seconds, and should be.
> that's the point of this discussion
Well, you said earlier:
> > > I suspect you will always be able to boot faster than you can
> > > hibernate+resume.
Maybe I'm just having a problem parsing that. Does "will" here mean
that it will be like that in the future after $something gets done?
yeah assuming you optimize both. Right now neither are well optimized;
the boot part is known how to do ;)
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
10:34 a.m.
On Mon, Dec 22, 2008 at 11:50 AM, Arjan van de Ven <arjan(a)infradead.org> wrote:
On Thu, 18 Dec 2008 18:47:34 +0200
Ville Skyttä <ville.skytta(a)iki.fi> wrote:
> On Thursday 18 December 2008, Arjan van de Ven wrote:
> > On Wed, 17 Dec 2008 21:52:30 +0200
> > Ville Skyttä <ville.skytta(a)iki.fi> wrote:
>
> > > - shutdown: 28 sec
> > > - fresh boot: 66 sec
> >
> > see this is the problem; this can be 5 to 10 seconds, and should be.
> > that's the point of this discussion
>
> Well, you said earlier:
>
> > > > I suspect you will always be able to boot faster than you can
> > > > hibernate+resume.
>
> Maybe I'm just having a problem parsing that. Does "will" here mean
> that it will be like that in the future after $something gets done?
yeah assuming you optimize both. Right now neither are well optimized;
the boot part is known how to do ;)
what exactly are the changes that need to be done to get a 5-10 second boot?
5:23 a.m.
On Mon, 22 Dec 2008 17:34:01 +0100
drago01 <drago01(a)gmail.com> wrote:
>
> yeah assuming you optimize both. Right now neither are well
> optimized; the boot part is known how to do ;)
what exactly are the changes that need to be done to get a 5-10
second boot?
the biggest thing that needs to be done is that a budget needs to be set
for the various pieces of the boot, that then has the desired target.
The rest is a consequence of that budget, and usually very local.
Yes sendmail needs to be sorted, cups, the selinux thing and a few
others.. but the time budget will make it very clear which these pieces
are.
In my experience, the individual pieces are not rocket science once the
budget is in place, there's no more excuses "but that other piece"...
resource scheduling is a well understood thing too, be it sreadahead or
the readahead that fedora has right now.
Yes parallel boot needs to be ignored (people who were at the plumbers
conference know that already)... it's counter productive. Asynchronous
actions are useful, but pure parallel is not.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
4:35 a.m.
Arjan van de Ven wrote:
On Tue, 16 Dec 2008 17:16:36 -0500 (EST)
Seth Vidal <skvidal(a)fedoraproject.org> wrote:
>> Or hibernate?
>>
> At least on my system hibernate takes as much time as a reboot.
>
>
btw this is a very fundamental property of hibernate. You need to do all
disk IO to get the system state to disk. And then at resume, you need
to do all disk IO to get the state from disk again. That's twice ;)
This is compounded by the property that a hibernate tends to flush at
least half the disk cache (it has to, to get space to work in), which
you then need to page right back in, so even when you're back, the first
minute or two sucks badly.
I suspect you will always be able to boot faster than you can
hibernate+resume.
Slightly off subject, did sreadahead ever get publicly released? Did I
miss it?
--CJD
4:42 a.m.
Casey Dahlin píše v Po 29. 12. 2008 v 05:35 -0500:
Arjan van de Ven wrote:
> On Tue, 16 Dec 2008 17:16:36 -0500 (EST)
> Seth Vidal <skvidal(a)fedoraproject.org> wrote:
>
>
>>> Or hibernate?
>>>
>> At least on my system hibernate takes as much time as a reboot.
>>
>>
>
> btw this is a very fundamental property of hibernate. You need to do all
> disk IO to get the system state to disk. And then at resume, you need
> to do all disk IO to get the state from disk again. That's twice ;)
>
> This is compounded by the property that a hibernate tends to flush at
> least half the disk cache (it has to, to get space to work in), which
> you then need to page right back in, so even when you're back, the first
> minute or two sucks badly.
>
> I suspect you will always be able to boot faster than you can
> hibernate+resume.
>
>
>
>
Slightly off subject, did sreadahead ever get publicly released? Did I
miss it?
It has been even submitted for review -
https://bugzilla.redhat.com/show_bug.cgi?id=464045
Dan
4:45 a.m.
Dan Horák wrote:
Casey Dahlin píše v Po 29. 12. 2008 v 05:35 -0500:
> Arjan van de Ven wrote:
>
>> On Tue, 16 Dec 2008 17:16:36 -0500 (EST)
>> Seth Vidal <skvidal(a)fedoraproject.org> wrote:
>>
>>
>>
>>>> Or hibernate?
>>>>
>>>>
>>> At least on my system hibernate takes as much time as a reboot.
>>>
>>>
>>>
>> btw this is a very fundamental property of hibernate. You need to do all
>> disk IO to get the system state to disk. And then at resume, you need
>> to do all disk IO to get the state from disk again. That's twice ;)
>>
>> This is compounded by the property that a hibernate tends to flush at
>> least half the disk cache (it has to, to get space to work in), which
>> you then need to page right back in, so even when you're back, the first
>> minute or two sucks badly.
>>
>> I suspect you will always be able to boot faster than you can
>> hibernate+resume.
>>
>>
>>
>>
>>
> Slightly off subject, did sreadahead ever get publicly released? Did I
> miss it?
>
It has been even submitted for review -
https://bugzilla.redhat.com/show_bug.cgi?id=464045
Dan
Good news. Its not a magic bullet any more than anything else but I like
this app a lot.
--CJD
3:51 p.m.
On Tue, 2008-12-16 at 16:41 -0500, Seth Vidal wrote:
so a good reason to power off is simply to save power
Or to reboot for one of our frequent updates that require it. kernel,
dbus, etc...
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
4:30 p.m.
Once upon a time, Jesse Keating <jkeating(a)redhat.com> said:
On Tue, 2008-12-16 at 16:41 -0500, Seth Vidal wrote:
> so a good reason to power off is simply to save power
Or to reboot for one of our frequent updates that require it. kernel,
dbus, etc...
Why does anything other than a kernel update require a reboot?
Is it possible to use kexec to boot a new kernel from the old one? That
would cut down on the reboot time (on some of my systems, especially
servers with SCSI and/or RAID, the POST takes much longer than the
kernel/daemon boot).
--
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:36 p.m.
> On Tue, 2008-12-16 at 16:41 -0500, Seth Vidal wrote:
> > so a good reason to power off is simply to save power
>
> Or to reboot for one of our frequent updates that require it. kernel,
> dbus, etc...
Why does anything other than a kernel update require a reboot?
Is it possible to use kexec to boot a new kernel from the old one? That
would cut down on the reboot time (on some of my systems, especially
servers with SCSI and/or RAID, the POST takes much longer than the
kernel/daemon boot).
Oh yes please! Some of my large servers seems to take weeks to boot :-)
Peter
7:44 p.m.
Dne Tue, 16 Dec 2008 23:36:23 +0100
"Peter Robinson" <pbrobinson(a)gmail.com> napsal:
>> On Tue, 2008-12-16 at 16:41 -0500, Seth Vidal wrote:
>> > so a good reason to power off is simply to save power
>>
>> Or to reboot for one of our frequent updates that require it.
>> kernel, dbus, etc...
>
> Why does anything other than a kernel update require a reboot?
>
> Is it possible to use kexec to boot a new kernel from the old one?
> That would cut down on the reboot time (on some of my systems,
> especially servers with SCSI and/or RAID, the POST takes much
> longer than the kernel/daemon boot).
Oh yes please! Some of my large servers seems to take weeks to
boot :-)
Yes, it is possible. I am actually using it on my laptop right now. My
goal was to have PackageKit restart the machine using kexec instead of
the full restart.
Here are patches I made for that:
http://michich.fedorapeople.org/kexec-fedora/
You most likely do not use PK on a server, but take a look at the
helper script ck-system-restart-quick in the ConsoleKit patch. It
can be used outside of CK. It's not perfect but works for me.
Michal
8:26 p.m.
On Wed, 2008-12-17 at 02:44 +0100, Michal Schmidt wrote:
You most likely do not use PK on a server, but take a look at the
helper script ck-system-restart-quick in the ConsoleKit patch. It
can be used outside of CK. It's not perfect but works for me.
Note that our kernel folks have said they will summarily ignore any and
all bug reports that come from any use of kexec.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
4:47 p.m.
On Tue, 2008-12-16 at 16:30 -0600, Chris Adams wrote:
Once upon a time, Jesse Keating <jkeating(a)redhat.com> said:
> On Tue, 2008-12-16 at 16:41 -0500, Seth Vidal wrote:
> > so a good reason to power off is simply to save power
>
> Or to reboot for one of our frequent updates that require it. kernel,
> dbus, etc...
Why does anything other than a kernel update require a reboot?
The system bus cannot be restarted. Similarly, any apps you have
running will be using old libraries so things like glibc you really want
to reboot for.
Jeremy
4:59 p.m.
Jeremy Katz wrote:
On Tue, 2008-12-16 at 16:30 -0600, Chris Adams wrote:
> Once upon a time, Jesse Keating <jkeating(a)redhat.com> said:
>> On Tue, 2008-12-16 at 16:41 -0500, Seth Vidal wrote:
>>> so a good reason to power off is simply to save power
>> Or to reboot for one of our frequent updates that require it. kernel,
>> dbus, etc...
> Why does anything other than a kernel update require a reboot?
The system bus cannot be restarted. Similarly, any apps you have
running will be using old libraries so things like glibc you really want
to reboot for.
Back in the days, sshd had a trigger to restart itself on glibc update. init
had a similar thing too I guess...
behdad
Jeremy
6:38 p.m.
On Tue, 2008-12-16 at 17:59 -0500, Behdad Esfahbod wrote:
Jeremy Katz wrote:
> On Tue, 2008-12-16 at 16:30 -0600, Chris Adams wrote:
>> Once upon a time, Jesse Keating <jkeating(a)redhat.com> said:
>>> On Tue, 2008-12-16 at 16:41 -0500, Seth Vidal wrote:
>>>> so a good reason to power off is simply to save power
>>> Or to reboot for one of our frequent updates that require it. kernel,
>>> dbus, etc...
>> Why does anything other than a kernel update require a reboot?
>
> The system bus cannot be restarted. Similarly, any apps you have
> running will be using old libraries so things like glibc you really want
> to reboot for.
Back in the days, sshd had a trigger to restart itself on glibc update. init
had a similar thing too I guess...
Yes, but that's not everything on your system. Should we add triggers
for everything you can possibly run? :)
Jeremy
6:42 p.m.
Jeremy Katz wrote:
On Tue, 2008-12-16 at 17:59 -0500, Behdad Esfahbod wrote:
> Jeremy Katz wrote:
>> On Tue, 2008-12-16 at 16:30 -0600, Chris Adams wrote:
>>> Once upon a time, Jesse Keating <jkeating(a)redhat.com> said:
>>>> On Tue, 2008-12-16 at 16:41 -0500, Seth Vidal wrote:
>>>>> so a good reason to power off is simply to save power
>>>> Or to reboot for one of our frequent updates that require it. kernel,
>>>> dbus, etc...
>>> Why does anything other than a kernel update require a reboot?
>> The system bus cannot be restarted. Similarly, any apps you have
>> running will be using old libraries so things like glibc you really want
>> to reboot for.
> Back in the days, sshd had a trigger to restart itself on glibc update. init
> had a similar thing too I guess...
Yes, but that's not everything on your system. Should we add triggers
for everything you can possibly run? :)
No, only for services that know how to restart without losing state.
behdad
Jeremy
10:20 p.m.
On Tue, 16 Dec 2008, Jeremy Katz wrote:
On Tue, 2008-12-16 at 17:59 -0500, Behdad Esfahbod wrote:
> Jeremy Katz wrote:
>> On Tue, 2008-12-16 at 16:30 -0600, Chris Adams wrote:
>>> Once upon a time, Jesse Keating <jkeating(a)redhat.com> said:
>>>> On Tue, 2008-12-16 at 16:41 -0500, Seth Vidal wrote:
>>>>> so a good reason to power off is simply to save power
>>>> Or to reboot for one of our frequent updates that require it. kernel,
>>>> dbus, etc...
>>> Why does anything other than a kernel update require a reboot?
>>
>> The system bus cannot be restarted. Similarly, any apps you have
>> running will be using old libraries so things like glibc you really want
>> to reboot for.
>
> Back in the days, sshd had a trigger to restart itself on glibc update. init
> had a similar thing too I guess...
Yes, but that's not everything on your system. Should we add triggers
for everything you can possibly run? :)
There's this yum plugin..... ;)
-sv
9:15 p.m.
On Tue, 2008-12-16 at 19:38 -0500, Jeremy Katz wrote:
Yes, but that's not everything on your system. Should we add
triggers
for everything you can possibly run? :)
Up to a couple of years ago, we attempted to do this in Mandriva; doing
a glibc upgrade would trigger a restart of all services.
We gave up doing this when stuff like dbus and hal started showing up,
and restarting all running services started to seriously screw up your
machine. Now we just do what Fedora does, and pop up a warning that says
"reboot your system".
It would probably be possible to have a robust system which really let
you keep the system running for all kinds of upgrade other than a kernel
upgrade, but it would be a hell of a lot of work, and probably not worth
the return on investment in practical consequences (actual time saved
and lives made better by avoiding reboots). It would certainly be
something it would make sense to do at a level higher than any one
distribution. And it would be one of those things that would *never* be
finished: someone would have to spend a substantial portion of his life
(or lots of somebodies spend a small portion) making sure this kept
working.
--
adamw
9:35 p.m.
On Wed, 2008-12-17 at 22:19 -0500, Colin Walters wrote:
On Wed, Dec 17, 2008 at 10:15 PM, Adam Williamson
<adamwill(a)shaw.ca> wrote:
>
> We gave up doing this when stuff like dbus and hal started showing up,
You restarted the X server?
Details, Colin, details =) I think it was actually everything in
runlevel 3. So yes, one of the drawbacks was you weren't really
restarting everything anyway.
Right. It's *never* been the case that one can randomly restart
processes after upgrading.
Indeed.
--
adamw
--
adamw
5:17 p.m.
On Tue, 2008-12-16 at 17:47 -0500, Jeremy Katz wrote:
On Tue, 2008-12-16 at 16:30 -0600, Chris Adams wrote:
> Once upon a time, Jesse Keating <jkeating(a)redhat.com> said:
> > On Tue, 2008-12-16 at 16:41 -0500, Seth Vidal wrote:
> > > so a good reason to power off is simply to save power
> >
> > Or to reboot for one of our frequent updates that require it. kernel,
> > dbus, etc...
>
> Why does anything other than a kernel update require a reboot?
The system bus cannot be restarted. Similarly, any apps you have
running will be using old libraries so things like glibc you really want
to reboot for.
The problem is mainly one of state. For example, NetworkManager has
some code to handle reconnection to the system bus. But to
transparently handle bus restarts, NetworkManager would have to perform
the following actions; none of this is NM or D-Bus specific, it would be
the same problem in any system using separate services for specific
functions, as is the unix way.
1) Sync internal device list with HAL, ie if you pulled a card out while
the system bus was down
2) Re-query dhclient state (currently impossible since dhclient doesn't
talk over D-Bus), ie if your DHCP lease got renewed or changed while the
system bus was down
3) Re-query avahi-autoipd state (currently impossible since
avahi-autoipd doesn't speak D-Bus), ie of your autoip address changed
while the system bus was down
4) Re-query pppd state (currently impossible since pppd doesn't speak
D-Bus), ie if the cellular network dropped your connection while the
system bus was down
5) Re-query all device IP addresses and routes, delete addresses/routes
that aren't known to NM and add addresses/routes that got dropped. Also
update stuff like MTU based on the DHCP server response that we had to
wait for in step #2
6) Re-query all VPN daemons for their connection state just in case any
of that changed while the system bus was down
7) Execute the callouts and send out D-Bus signals if any of these
things changed, so that scripts in /etc/NetworkManager/dispatcher.d get
notified of changes
8) Requery wpa_supplicant for the wireless scan list
9) Requery the wifi adapter for the current settings and ensure that
they are the same as NM thinks they should be, and if not, tear down
whatever the wifi card is doing and re-init the connection
10) Trust and rely on each D-Bus service to successfully reconnect to
the bus, where each service may handle this differently with different
reconnection attempt timeouts. Latency for handling a bus restart could
be quite large if a service like wpa_supplicant that is lower in the
stack takes a bit longer to reconnect than other services.
11) Re-query the system settings and user settings services and figure
out if any new connections were added while the bus was down, or if any
connections (including the one that was active during the bus restart)
were deleted. If the active connection was deleted during the bus
restart, tear it down.
How does all this stuff happen when the system bus is running? Signals
get emitted from the various components when things change, and NM
listens for those signals so it doesn't have to poll everything. Thus,
if the system bus isn't running, signals get lost and you have to
invalidate all your state, then re-query it when the bus comes back.
We've discussed less-invasive ways of fixing this, like queuing signals
in the services on the service-side in libdbus or so until the service
reconnects to the system bus, but that could be quite tricky and error
prone. You cannot do a 75% solution here.
Dan
4:44 a.m.
Dan Williams wrote:
On Tue, 2008-12-16 at 17:47 -0500, Jeremy Katz wrote:
> On Tue, 2008-12-16 at 16:30 -0600, Chris Adams wrote:
>
>> Once upon a time, Jesse Keating <jkeating(a)redhat.com> said:
>>
>>> On Tue, 2008-12-16 at 16:41 -0500, Seth Vidal wrote:
>>>
>>>> so a good reason to power off is simply to save power
>>>>
>>> Or to reboot for one of our frequent updates that require it. kernel,
>>> dbus, etc...
>>>
>> Why does anything other than a kernel update require a reboot?
>>
> The system bus cannot be restarted. Similarly, any apps you have
> running will be using old libraries so things like glibc you really want
> to reboot for.
>
The problem is mainly one of state. For example, NetworkManager has
some code to handle reconnection to the system bus. But to
transparently handle bus restarts, NetworkManager would have to perform
the following actions; none of this is NM or D-Bus specific, it would be
the same problem in any system using separate services for specific
functions, as is the unix way.
*snip*
We've discussed less-invasive ways of fixing this, like queuing
signals
in the services on the service-side in libdbus or so until the service
reconnects to the system bus, but that could be quite tricky and error
prone. You cannot do a 75% solution here.
Dan
Of course all this is SEP when dbus becomes a kernel module :)
--CJD
4:45 p.m.
On Tue, 2008-12-16 at 16:03 -0500, Behdad Esfahbod wrote:
Les Mikesell wrote:
> (b) making sleep/hibernate reliable is what laptop users
> need instead of booting all the time anyway because it is much faster if
> you can simply close the lid and open it later with all your apps
> working as you left them.
This is actually the strongest argument against spending a lot of resources on
going sub 20 seconds. If Vista-style suspend-to-both works reliably, there is
no reason to turn a machine off at all.
That said, doesn't mean we shouldn't clean up cruft.
Indeed. There are still plenty of reasons why reboots happen, so
speeding up boot is worthwhile.
Hans de Goede wrote:
> 2) Load some services after gdm is up, for example cron, anacron, at,
> setroubleshootd
Please, no setroubleshootd by default. What's the point? Read section "The
rest" in my blog post:
Dan is working on making setroubleshoot suck less -- the idea of
notifying you of problems even if the only thing you can do is report
them isn't bad. The implementation is less than ideal :)
Horst H. von Brand wrote:
>> how about not running a full MTA on a laptop/client install... at all?
>
> That works if you have reliable, continuous access to the 'net. Not my
> case, sorry.
Don't you have to configure the MTA if you want to use it? I mean, when a
normal user configures Thunderbird/Evo/... it puts the SMTP address that their
mail provider gave them (smtp.gmail.com, etc), NOT localhost. If you are an
advanced-enough user to set it to localhost and configure your MTA to point it
to your remote SMTP server, sure you don't mind a "yum install sendmail"
first, do you?
Yeah, I think that this is probably the right path although it
definitely is going to be a noisy path. FWIW, even mutt users don't
need sendmail anymore -- see 'set smtp_url'.
Jeremy
9 p.m.
On Tue, Dec 16, 2008 at 04:03:15PM -0500, Behdad Esfahbod wrote:
This is actually the strongest argument against spending a lot of
resources on
going sub 20 seconds. If Vista-style suspend-to-both works reliably, there is
no reason to turn a machine off at all.
It doesn't. It won't within a year. I think that makes short boot times
a worthy goal in the interim.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
1:20 a.m.
Behdad Esfahbod wrote:
> Matej Cepl wrote:
> On 2008-12-16, 16:09 GMT, Peter Robinson wrote:
>> Nothing to say you can't re-enable it yourself. I don't have a
>> permanent connection to the net but evolution happily holds it in my
>> outbox until I go back online and can connect to a network. Fedora can
> I have a nasty surprise for you -- Fedora is not Windows, so it
> would is not only for people who use Evolution / Kmail
> / Thunderbird.
See above. On a similar line of though, how about: "please install and enable
httpd, postgresql, and squid" by default because I use them...
Yes, how about it? What's the point of booting quickly - or at all, if
the machine won't provide any services?
--
Les Mikesell
lesmikesell(a)gmail.com
1:56 a.m.
Les Mikesell wrote:
Behdad Esfahbod wrote:
> > Matej Cepl wrote:
>> On 2008-12-16, 16:09 GMT, Peter Robinson wrote:
>>> Nothing to say you can't re-enable it yourself. I don't have a
>>> permanent connection to the net but evolution happily holds it in my
>>> outbox until I go back online and can connect to a network. Fedora can
>> I have a nasty surprise for you -- Fedora is not Windows, so it
>> would is not only for people who use Evolution / Kmail
>> / Thunderbird.
>
> See above. On a similar line of though, how about: "please install
> and enable
> httpd, postgresql, and squid" by default because I use them...
Yes, how about it? What's the point of booting quickly - or at all, if
the machine won't provide any services?
Why would I install the desktop spin if I need those? Fedora has been taking
the lets-start-any-services-that-someone-may-need approach so far. It doesn't
work. Spins are a neat way to customize the default install for different
sectors. The desktop spin should not install an MTA in my opinion. That's
all I'm saying.
behdad
4:26 a.m.
>>> On 2008-12-16, 16:09 GMT, Peter Robinson wrote:
>>>> Nothing to say you can't re-enable it yourself. I don't have a
>>>> permanent connection to the net but evolution happily holds it in my
>>>> outbox until I go back online and can connect to a network. Fedora can
>>> I have a nasty surprise for you -- Fedora is not Windows, so it
>>> would is not only for people who use Evolution / Kmail
>>> / Thunderbird.
>>
>> See above. On a similar line of though, how about: "please install
>> and enable
>> httpd, postgresql, and squid" by default because I use them...
>
> Yes, how about it? What's the point of booting quickly - or at all, if
> the machine won't provide any services?
Why would I install the desktop spin if I need those? Fedora has been taking
the lets-start-any-services-that-someone-may-need approach so far. It doesn't
work. Spins are a neat way to customize the default install for different
sectors. The desktop spin should not install an MTA in my opinion. That's
all I'm saying.
Exactly! But to do that we need a standard to all those apps require
the sendmail binary just in case you need to use the mail feature.
Peter
8 a.m.
Behdad Esfahbod wrote:
Les Mikesell wrote:
> Behdad Esfahbod wrote:
>>> Matej Cepl wrote:
>>> On 2008-12-16, 16:09 GMT, Peter Robinson wrote:
>>>> Nothing to say you can't re-enable it yourself. I don't have a
>>>> permanent connection to the net but evolution happily holds it in my
>>>> outbox until I go back online and can connect to a network. Fedora can
>>> I have a nasty surprise for you -- Fedora is not Windows, so it
>>> would is not only for people who use Evolution / Kmail
>>> / Thunderbird.
>> See above. On a similar line of though, how about: "please install
>> and enable
>> httpd, postgresql, and squid" by default because I use them...
> Yes, how about it? What's the point of booting quickly - or at all, if
> the machine won't provide any services?
Why would I install the desktop spin if I need those? Fedora has been taking
the lets-start-any-services-that-someone-may-need approach so far. It doesn't
work. Spins are a neat way to customize the default install for different
sectors. The desktop spin should not install an MTA in my opinion. That's
all I'm saying.
Even desktop users deserve an environment that follows standards. Has
everyone forgotten October's long discussion on this very subject?
http://fcp.surfsite.org/modules/newbb/viewtopic.php?post_id=298345&to...
Note particularly reply #96 stating mail delivery is required by both
posix and the LSB.
I don't understand why people who want non-standard configurations can't
stop the service startups themselves - and then they'll know why
normal programs that expect a standard environment don't work. Also,
this doesn't really have anything to do with boot time. The daemon
startup can be deferred or put in the background so as not to delay bootup.
--
Les Mikesell
lesmikesell(a)gmail.com
1:16 p.m.
Les Mikesell wrote:
Even desktop users deserve an environment that follows standards.
Has
everyone forgotten October's long discussion on this very subject?
http://fcp.surfsite.org/modules/newbb/viewtopic.php?post_id=298345&to...
Note particularly reply #96 stating mail delivery is required by both
posix and the LSB.
Who cares if my desktop is not POSIX and LSB compliant?
And what are all those applications that are claimed depend on sendmail? Show
it to me.
I don't understand why people who want non-standard
configurations can't
stop the service startups themselves - and then they'll know why normal
programs that expect a standard environment don't work. Also, this
doesn't really have anything to do with boot time. The daemon startup
can be deferred or put in the background so as not to delay bootup.
Screw standards, we're talking about how to get a decent desktop system that
boots fast.
behdad
1:24 p.m.
On Wed, Dec 17, 2008 at 10:16 AM, Behdad Esfahbod <behdad(a)behdad.org> wrote:
And what are all those applications that are claimed depend on
sendmail? Show
it to me.
Ask and you shall receive, at least for F10 with rpmfusion enabled:
repoquery --whatrequires --alldeps sendmail --qf
"%{NAME}\n"|sort -u
alpine
amavisd-new
arpwatch
asterisk-voicemail
bcfg2-server
bugzilla
clamav-milter-sendmail
cronie
dbmail
dkim-milter
fcron
fvwm
mgetty
milter-regex
mlmmj
nagios-plugins-mailq
pgp-tools
quilt
ratbox-services
redhat-lsb
sagator
sendmail
sendmail-cf
sendmail-devel
sendmail-doc
spamass-milter
squirrelmail
uudeview
websec
-jef"uudeview, I remember that program..stupid mac filesystem and its
resource forks in emails"spaleta
1:31 p.m.
Jeff Spaleta wrote:
On Wed, Dec 17, 2008 at 10:16 AM, Behdad Esfahbod
<behdad(a)behdad.org> wrote:
> And what are all those applications that are claimed depend on sendmail? Show
> it to me.
Ask and you shall receive, at least for F10 with rpmfusion enabled:
Thanks. And querying those on my FC10 desktop machine:
package alpine is not installed
package amavisd-new is not installed
package arpwatch is not installed
package asterisk-voicemail is not installed
package bcfg2-server is not installed
package bugzilla is not installed
package clamav-milter-sendmail is not installed
cronie-1.2-4.fc10.x86_64
package dbmail is not installed
package dkim-milter is not installed
package fcron is not installed
package fvwm is not installed
package mgetty is not installed
package milter-regex is not installed
package mlmmj is not installed
package nagios-plugins-mailq is not installed
package pgp-tools is not installed
package quilt is not installed
package ratbox-services is not installed
package redhat-lsb is not installed
package sagator is not installed
package sendmail is not installed
package sendmail-cf is not installed
package sendmail-devel is not installed
package sendmail-doc is not installed
package spamass-milter is not installed
package squirrelmail is not installed
package uudeview is not installed
package websec is not installed
behdad
> repoquery --whatrequires --alldeps sendmail --qf
"%{NAME}\n"|sort -u
alpine
amavisd-new
arpwatch
asterisk-voicemail
bcfg2-server
bugzilla
clamav-milter-sendmail
cronie
dbmail
dkim-milter
fcron
fvwm
mgetty
milter-regex
mlmmj
nagios-plugins-mailq
pgp-tools
quilt
ratbox-services
redhat-lsb
sagator
sendmail
sendmail-cf
sendmail-devel
sendmail-doc
spamass-milter
squirrelmail
uudeview
websec
-jef"uudeview, I remember that program..stupid mac filesystem and its
resource forks in emails"spaleta
1:55 p.m.
Behdad Esfahbod wrote:
> On Wed, Dec 17, 2008 at 10:16 AM, Behdad Esfahbod <behdad(a)behdad.org> wrote:
>> And what are all those applications that are claimed depend on sendmail? Show
>> it to me.
> Ask and you shall receive, at least for F10 with rpmfusion enabled:
Thanks. And querying those on my FC10 desktop machine:
package * is not installed
Where do you receive your notifications that your disk space is nearly
full, or that smartctl thinks a drive is dangerously near death?
--
Les Mikesell
lesmikesell(a)gmail.com
2:03 p.m.
Les Mikesell wrote:
Behdad Esfahbod wrote:
>
>> On Wed, Dec 17, 2008 at 10:16 AM, Behdad Esfahbod <behdad(a)behdad.org>
>> wrote:
>>> And what are all those applications that are claimed depend on
>>> sendmail? Show
>>> it to me.
>> Ask and you shall receive, at least for F10 with rpmfusion enabled:
>
> Thanks. And querying those on my FC10 desktop machine:
>
> package * is not installed
Where do you receive your notifications that your disk space is nearly
full, or that smartctl thinks a drive is dangerously near death?
Guess where those notifications go? In /var/spool/mail/root. Guess who pops
up a notification on my non-root desktop to notify me that my harddisk is
dying? Nobody.
behdad
2:21 p.m.
Behdad Esfahbod wrote:
>> package * is not installed
> Where do you receive your notifications that your disk space is nearly
> full, or that smartctl thinks a drive is dangerously near death?
Guess where those notifications go? In /var/spool/mail/root. Guess who pops
up a notification on my non-root desktop to notify me that my harddisk is
dying? Nobody.
Ahh, so you've finally identified a problem that needs to be solved.
Unless you think the distribution should cater only to people who don't
care if their computers work or not?
--
Les Mikesell
lesmikesell(a)gmail.com
2:24 p.m.
On Wed, Dec 17, 2008 at 11:21 AM, Les Mikesell <lesmikesell(a)gmail.com> wrote:
Ahh, so you've finally identified a problem that needs to be
solved. Unless
you think the distribution should cater only to people who don't care if
their computers work or not?
a posix complaint mta may not be the answer that makes sense in the
dbus enabled live desktop.
-jef
2:31 p.m.
On Wed December 17 2008 14:24:18 Jeff Spaleta wrote:
On Wed, Dec 17, 2008 at 11:21 AM, Les Mikesell
<lesmikesell(a)gmail.com>
wrote:
> Ahh, so you've finally identified a problem that needs to be
solved.
> Unless you think the distribution should cater only to people who don't
> care if their computers work or not?
a posix complaint mta may not be the answer that makes sense in the
dbus enabled live desktop.
+1
In fact, s/may not be/is not/, IMHO.
jerry
--
To be named later.
2:25 p.m.
Les Mikesell wrote:
Behdad Esfahbod wrote:
>
>>> package * is not installed
>> Where do you receive your notifications that your disk space is nearly
>> full, or that smartctl thinks a drive is dangerously near death?
>
> Guess where those notifications go? In /var/spool/mail/root. Guess
> who pops
> up a notification on my non-root desktop to notify me that my harddisk is
> dying? Nobody.
Ahh, so you've finally identified a problem that needs to be solved.
Unless you think the distribution should cater only to people who don't
care if their computers work or not?
A problem needing fix was identified at the beginning of the thread. Except
that you insist on keeping the broken status quo.
Things like hardware notifications can much easier be done using HAL and D-BUS
than using local mail.
behdad
2:40 p.m.
Behdad Esfahbod wrote:
>>> Where do you receive your notifications that your disk space is nearly
>>> full, or that smartctl thinks a drive is dangerously near death?
>> Guess where those notifications go? In /var/spool/mail/root. Guess
>> who pops
>> up a notification on my non-root desktop to notify me that my harddisk is
>> dying? Nobody.
> Ahh, so you've finally identified a problem that needs to be solved.
> Unless you think the distribution should cater only to people who don't
> care if their computers work or not?
A problem needing fix was identified at the beginning of the thread.
Waiting for daemon startup before doing something else in the bootup
sequence has a simple solution. Don't wait. You don't have to remove
functionality.
Except
that you insist on keeping the broken status quo.
The status quo in terms of services is not broken. Other programs
should be able to assume that a reasonable operating systems includes
mail delivery.
Things like hardware notifications can much easier be done using HAL
and D-BUS
than using local mail.
Such notifications would not be likely to seen by me as I almost never
sit near the machines where the disks live. Who gets them if multiple
users are logged in via X or freenx? Or if no one is logged in at all,
or if X isn't running?
--
Les Mikesell
lesmikesell(a)gmail.com
2:59 p.m.
On Wed, 2008-12-17 at 14:40 -0600, Les Mikesell wrote:
Such notifications would not be likely to seen by me as I almost never
sit near the machines where the disks live. Who gets them if multiple
users are logged in via X or freenx? Or if no one is logged in at all,
or if X isn't running?
Ahh, but to flip your argument on it's head, you know how to setup mail
delivery of such notices don't you?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:40 p.m.
2008/12/17 Jesse Keating <jkeating(a)redhat.com>:
On Wed, 2008-12-17 at 14:40 -0600, Les Mikesell wrote:
>
> Such notifications would not be likely to seen by me as I almost never
> sit near the machines where the disks live. Who gets them if multiple
> users are logged in via X or freenx? Or if no one is logged in at all,
> or if X isn't running?
Ahh, but to flip your argument on it's head, you know how to setup mail
delivery of such notices don't you?
Yeah people how know about them know how to enable them (its not
rocket science btw) but most users don't need them and don't even know
that they exits ...
so why make the boot process slower for most users?
And why do people always shout "oh no you changed something that has
been that way for years that must be wrong even if its better for most
users" ? ... nobody wants to remove MTA's from fedora they just want
to not install/enable it by default.
We really need to make the boot process faster .. talking about how
important a MTA isn't the best way to accomplish this goal .. it will
ends up like every fedora release.
Talk and no changes due to flamewar = no or minimal boot time improvement.
4:27 p.m.
drago01 wrote:
>> Such notifications would not be likely to seen by me as I almost never
>> sit near the machines where the disks live. Who gets them if multiple
>> users are logged in via X or freenx? Or if no one is logged in at all,
>> or if X isn't running?
> Ahh, but to flip your argument on it's head, you know how to setup mail
> delivery of such notices don't you?
Yeah people how know about them know how to enable them (its not
rocket science btw) but most users don't need them and don't even know
that they exits ...
OK, so some users are ignorant at first. That doesn't have to last forever.
so why make the boot process slower for most users?
That's a complete separate question, since having a standard mail
transport doesn't have to slow the boot process.
And why do people always shout "oh no you changed something that
has
been that way for years that must be wrong even if its better for most
users" ?
Why do people pretend that they just invented computers and that no one
else understands them, ignoring standards that have developed over many
years for good reasons?
... nobody wants to remove MTA's from fedora they just want
to not install/enable it by default.
How is not installing it different from removing it? If a 3rd party
program needs it, it's not there.
We really need to make the boot process faster .. talking about how
important a MTA isn't the best way to accomplish this goal .. it will
ends up like every fedora release.
So do the obvious thing. Make booting faster without disabling expected
functionality.
Talk and no changes due to flamewar = no or minimal boot time
improvement.
I don't think there would be any flamewar if someone stuck to the
subject of boot times and just deferred the MTA startup or put it in the
background. There is no need to wait.
--
Les Mikesell
lesmikesell(a)gmail.com
4:44 p.m.
Les Mikesell wrote:
drago01 wrote:
> Talk and no changes due to flamewar = no or minimal boot time
> improvement.
I don't think there would be any flamewar if someone stuck to the
subject of boot times and just deferred the MTA startup or put it in the
background. There is no need to wait.
+1. Since I switched my Asus to Cambridge, boot time has become a topic
near to my heart. But I still (AFAIK) have sendmail installed, because -
even though, forced to think about it, I probably don't need it - I
don't feel comfortable without a functional mail subsystem. (Maybe if I
removed cron also...)
I'm in favor of deferred-startup, however. As one of the individuals
opposed to breaking mail, I'd like to hope that's worth something :-).
After all, compromise is about finding a position that everyone finds at
least acceptable, if not satisfying. It would be nice if we could work
toward that instead of this "my way or no progress" attitude that seems
to be prevalent.
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"...anyway, that's my 0.02 toasters"
(with apologies to Niel)
4:04 p.m.
Jesse Keating wrote:
On Wed, 2008-12-17 at 14:40 -0600, Les Mikesell wrote:
> Such notifications would not be likely to seen by me as I almost never
> sit near the machines where the disks live. Who gets them if multiple
> users are logged in via X or freenx? Or if no one is logged in at all,
> or if X isn't running?
Ahh, but to flip your argument on it's head, you know how to setup mail
delivery of such notices don't you?
Yes, but the point of loading a distribution instead of assembling your
own linux from scratch is to have most of the grunge work for standard
things done for you. Plus, if notifications are moved to dbus, I'd have
no idea about how to catch them and deliver using standard protocols
instead.
--
Les Mikesell
lesmikesell(a)gmail.com
2:48 p.m.
Behdad Esfahbod wrote:
Les Mikesell wrote:
> Behdad Esfahbod wrote:
>>>> package * is not installed
>>> Where do you receive your notifications that your disk space is nearly
>>> full, or that smartctl thinks a drive is dangerously near death?
>> Guess where those notifications go? In /var/spool/mail/root. Guess
>> who pops
>> up a notification on my non-root desktop to notify me that my harddisk is
>> dying? Nobody.
> Ahh, so you've finally identified a problem that needs to be solved.
> Unless you think the distribution should cater only to people who don't
> care if their computers work or not?
A problem needing fix was identified at the beginning of the thread. Except
that you insist on keeping the broken status quo.
Things like hardware notifications can much easier be done using HAL and D-BUS
than using local mail.
...and cron still needs to be patched.
How's this, when I get a popup notification that the output from my cron
jobs is going to /dev/null and would I like to install an MTA please and
thank you, *then* I am okay making sendmail not a hard dependency :-).
...and these sorts of notifications ought to be provided by something
that is very hard to remove. As in, --nodeps, or at least taking out
something whose name makes it blindingly obvious that you're removing
something important.
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"...anyway, that's my 0.02 toasters"
(with apologies to Niel)
1:36 p.m.
On Wed, 2008-12-17 at 10:24 -0900, Jeff Spaleta wrote:
On Wed, Dec 17, 2008 at 10:16 AM, Behdad Esfahbod
<behdad(a)behdad.org> wrote:
> And what are all those applications that are claimed depend on sendmail? Show
> it to me.
Ask and you shall receive, at least for F10 with rpmfusion enabled:
> repoquery --whatrequires --alldeps sendmail --qf "%{NAME}\n"|sort -u
... and best of all, since those packages require sendmail, if you go to
install one of them (modulo cronie, they're not on the desktop live
image today), you'll get sendmail pulled in.
Hey, these new-fangled dependency things work! ;-)
Jeremy
1:45 p.m.
On Wed December 17 2008, Jeremy Katz wrote:
... and best of all, since those packages require sendmail, if you go
to
install one of them (modulo cronie, they're not on the desktop live
image today), you'll get sendmail pulled in.
They may also require /usr/bin/sendmail, e.g.:
$ LANG=C rpm -q sendmail websec
package sendmail is not installed
websec-1.9.0-5.1.noarch
Regards,
Till
1:59 p.m.
2008/12/17 Till Maas <opensource(a)till.name>:
They may also require /usr/bin/sendmail, e.g.:
I think for the purposes of the discussion... anything which provides
that file is something Behdad is going to rage madly against "needing"
in modern personal desktop experience default install target.
Should I run a set of aggregate queries for everything that provides
/usr/bin/sendmail and produce a list of any package in the repo which
would pull in anything that provides that file? I doubt it be a much
bigger list.
-jef"why does fvwm need an mta?"spaleta
2:18 p.m.
On Wed, Dec 17, 2008 at 10:59 AM, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
Should I run a set of aggregate queries for everything that provides
/usr/bin/sendmail and produce a list of any package in the repo which
would pull in anything that provides that file? I doubt it be a much
bigger list.
Okay to be pedantically comprehensive add these to the list:
exim
exim-clamav
exim-greylist
postfix
postfix-perl-scripts
postfix-pflogsumm
postgrey
sqlgrey
ssmtp
These packages depend on something provided by a package which also
provides /usr/sbin/sendmail, but do not require /usr/sbin/sendmail.
Its obvious these packages don't matter to the discussion at hand,
since they are intimately tied to a specific mail-server's operation
and not posix compliance.
-jef
2:38 p.m.
On Wed December 17 2008 13:59:14 Jeff Spaleta wrote:
2008/12/17 Till Maas <opensource(a)till.name>:
> They may also require /usr/bin/sendmail, e.g.:
I think for the purposes of the discussion... anything which provides
that file is something Behdad is going to rage madly against "needing"
in modern personal desktop experience default install target.
Rightly so, I think. For the 'modern personal desktop' (hope I used the
correct quotes there :-), the critical system messages deserve to be delivered
to the active (or soon to be) desktop, rather than a passive log file.
The os from M$ may give warning by way of errors, but most likely surprises
you at next boot. IIRC, OpenSUSE aliases root to the first user, so there is at
least possible notification there...
jerry
--
To be named later.
2:45 p.m.
Jerry Amundson wrote:
On Wed December 17 2008 13:59:14 Jeff Spaleta wrote:
> 2008/12/17 Till Maas <opensource(a)till.name>:
>> They may also require /usr/bin/sendmail, e.g.:
> I think for the purposes of the discussion... anything which provides
> that file is something Behdad is going to rage madly against "needing"
> in modern personal desktop experience default install target.
Rightly so, I think. For the 'modern personal desktop' (hope I used the
correct quotes there :-), the critical system messages deserve to be delivered
to the active (or soon to be) desktop, rather than a passive log file.
What does that mean? Has Linux stopped being a multiuser system?
--
Les Mikesell
lesmikesell(a)gmail.com
2:51 p.m.
On Wed, 2008-12-17 at 14:45 -0600, Les Mikesell wrote:
> Rightly so, I think. For the 'modern personal desktop'
(hope I used
the
> correct quotes there :-), the critical system messages deserve to be
delivered
> to the active (or soon to be) desktop, rather than a passive log
file.
What does that mean? Has Linux stopped being a multiuser system?
No, it hasn't. But Fedora is targeted at the desktop user.
And your continuous efforts at stopping any sort of progress
for the *common* case is truly frustrating.
I've used Linux on all my desktops for 12+ years. Never have I
found the root notifications useful in that case. And even if
they would have been, you seem to have no idea what a non-technical
person would make of them. I'll tell you: nothing.
On the other hand, boot speed is a perceived problem by most users,
technical or not. Back in '98 when I tried to install Linux for
my dad, the 1st question was: but does it start fast?
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
5:54 p.m.
On Wed, Dec 17, 2008 at 03:51:59PM -0500, Dimi Paun wrote:
No, it hasn't. But Fedora is targeted at the desktop user.
And your continuous efforts at stopping any sort of progress
for the *common* case is truly frustrating.
'Fedora is a Linux-based operating system that showcases the latest in free and open
source software.'
It is not a distro targeted at desktop users with a common case.
It is innovative, but it doesn't necessarily means desktop.
--
Pat
5:58 p.m.
Patrice Dumas wrote:
On Wed, Dec 17, 2008 at 03:51:59PM -0500, Dimi Paun wrote:
> No, it hasn't. But Fedora is targeted at the desktop user.
> And your continuous efforts at stopping any sort of progress
> for the *common* case is truly frustrating.
'Fedora is a Linux-based operating system that showcases the latest in free and open
source software.'
It is not a distro targeted at desktop users with a common case.
It is innovative, but it doesn't necessarily means desktop.
What about the Desktop Spin?
behdad
--
Pat
3 p.m.
Les Mikesell wrote:
Jerry Amundson wrote:
> On Wed December 17 2008 13:59:14 Jeff Spaleta wrote:
>> 2008/12/17 Till Maas <opensource(a)till.name>:
>>> They may also require /usr/bin/sendmail, e.g.:
>> I think for the purposes of the discussion... anything which provides
>> that file is something Behdad is going to rage madly against "needing"
>> in modern personal desktop experience default install target.
>
> Rightly so, I think. For the 'modern personal desktop' (hope I used
> the correct quotes there :-), the critical system messages deserve to
> be delivered to the active (or soon to be) desktop, rather than a
> passive log file.
What does that mean? Has Linux stopped being a multiuser system?
You're sounding like a troll now. The phrase "modern personal desktop" was
quite twice in the two-paragraph you replied to.
Just install the server spin and be happy. What's wrong with that?
behdad
3:22 p.m.
On Wed, 17 Dec 2008, Behdad Esfahbod wrote:
Les Mikesell wrote:
> Jerry Amundson wrote:
>> On Wed December 17 2008 13:59:14 Jeff Spaleta wrote:
>>> 2008/12/17 Till Maas <opensource(a)till.name>:
>>>> They may also require /usr/bin/sendmail, e.g.:
>>> I think for the purposes of the discussion... anything which provides
>>> that file is something Behdad is going to rage madly against
"needing"
>>> in modern personal desktop experience default install target.
>>
>> Rightly so, I think. For the 'modern personal desktop' (hope I used
>> the correct quotes there :-), the critical system messages deserve to
>> be delivered to the active (or soon to be) desktop, rather than a
>> passive log file.
>
> What does that mean? Has Linux stopped being a multiuser system?
You're sounding like a troll now. The phrase "modern personal desktop"
was
quite twice in the two-paragraph you replied to.
Just install the server spin and be happy. What's wrong with that?
the problem is that a lot of the notification utilities/tools seem to be
developed exclusively with a desktop/laptop in mind. Not with a server
infrastructure and a sysadmin-controlled-environment in mind.
In short, stop talking about desktop/laptop-centric notifications.
If you want to get rid of sendmail-style notifications then using the same
notification infrastructure make sure that at introduction there are
tools to notify a user on the desktop AND to get a message out in one of
the older styles, like sending an email.
And I don't mean a tool like 'oh just run oddjob' I mean something
tailored to do that. It's not an unreasonable request and since fedora
(and rhel which derives from fedora) are not desktop-only distros it is a
perfectly sensible thing to do.
The most obvious thing I've not seen, yet, is a notification->email dbus
listener. That would allow interaction to the mail notifications that Les
(and A LOT of sysadmins) want and it would also allow someone to learn how
to do that better. Dbus-notifications to nagios or zabbix, for example.
Does that make sense?
-sv
3:42 p.m.
On Wed, Dec 17, 2008 at 12:22 PM, Seth Vidal <skvidal(a)fedoraproject.org> wrote:
Does that make sense?
tonnes of sense.
And so would the opposite an email->notification utility which would
turn traditional local system emails meant for root into dbus
messages. Such a beast would set at /usr/sbin/sendmail when
installed..but would be replaced by a traditional mta if systems did
not want a dbus service running.
-jef
5:13 a.m.
"Jeff Spaleta" <jspaleta(a)gmail.com> writes:
And so would the opposite an email->notification utility which
would
turn traditional local system emails meant for root into dbus
messages. Such a beast would set at /usr/sbin/sendmail when
installed..but would be replaced by a traditional mta if systems did
not want a dbus service running.
What should it do with email not meant for root?
Apart from that little problem I like the idea, but IMHO anything that
provides /usr/sbin/sendmail should be able to actually send mail.
/Benny
5:29 a.m.
On Thu, Dec 18, 2008 at 12:13:01PM +0100, Benny Amorsen wrote:
"Jeff Spaleta" <jspaleta(a)gmail.com> writes:
Apart from that little problem I like the idea, but IMHO anything that
provides /usr/sbin/sendmail should be able to actually send mail.
That's the case, but cannot necessarily deliver locally (ssmtp).
--
Pat
7:07 a.m.
Patrice Dumas <pertusus(a)free.fr> writes:
On Thu, Dec 18, 2008 at 12:13:01PM +0100, Benny Amorsen wrote:
> Apart from that little problem I like the idea, but IMHO anything
that
> provides /usr/sbin/sendmail should be able to actually send mail.
That's the case, but cannot necessarily deliver locally (ssmtp).
ssmtp cannot (as far as I can tell) deliver to DBUS, which was Jeff
Spaleta's proposal. Both Jeff Spaleta's proposal and Seth Vidal's
proposal look good to me.
/Benny
3:51 p.m.
Behdad Esfahbod wrote:
>>>> They may also require /usr/bin/sendmail, e.g.:
>>> I think for the purposes of the discussion... anything which provides
>>> that file is something Behdad is going to rage madly against
"needing"
>>> in modern personal desktop experience default install target.
>> Rightly so, I think. For the 'modern personal desktop' (hope I used
>> the correct quotes there :-), the critical system messages deserve to
>> be delivered to the active (or soon to be) desktop, rather than a
>> passive log file.
> What does that mean? Has Linux stopped being a multiuser system?
You're sounding like a troll now. The phrase "modern personal desktop"
was
quite twice in the two-paragraph you replied to.
I have no idea what "modern personal desktop" means to you. For me, it
mostly means something that can run the NX client to connect to my
long-running desktop sessions on a few other machines.
Just install the server spin and be happy. What's wrong with
that?
I want desktop applications. I just don't want to be limited to one
user at a time running them, or forced to be at any particular location
relative to where they run, or to have to stay in one place after
starting a session.
--
Les Mikesell
lesmikesell(a)gmail.com
6:09 p.m.
Patrice Dumas wrote:
On Wed, Dec 17, 2008 at 02:51:15PM -0600, Matthew Woehlke wrote:
> Jeff Spaleta wrote:
>> -jef"why does fvwm need an mta?"spaleta
> ...I was wondering that also ;-).
It is for fvwm-bug. Guess that it calls sendmail.
Ah :-). That makes sense.
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"...anyway, that's my 0.02 toasters"
(with apologies to Niel)
2:05 p.m.
On Wed, 2008-12-17 at 20:45 +0100, Till Maas wrote:
On Wed December 17 2008, Jeremy Katz wrote:
> ... and best of all, since those packages require sendmail, if you go to
> install one of them (modulo cronie, they're not on the desktop live
> image today), you'll get sendmail pulled in.
They may also require /usr/bin/sendmail, e.g.:
The --alldeps option accounts for that:
% repoquery --whatrequires sendmail --qf "%{NAME}\n" | \
fgrep websec
% repoquery --whatrequires sendmail --alldeps --qf "%{NAME}\n" | \
fgrep websec
websec
%
--
James Antill <james(a)fedoraproject.org>
Fedora
8:27 a.m.
On Wednesday 17 December 2008 02:24:41 pm Jeff Spaleta wrote:
On Wed, Dec 17, 2008 at 10:16 AM, Behdad Esfahbod
<behdad(a)behdad.org> wrote:
> And what are all those applications that are claimed depend on sendmail?
> Show it to me.
Ask and you shall receive, at least for F10 with rpmfusion enabled:
> repoquery --whatrequires --alldeps sendmail --qf "%{NAME}\n"|sort -u
We ran into a problem doing the LSPP evaluation with regards to email. Of all
the packages listed, the only one that really mattered for security was cron.
So, what we did was patched cron to be able to take an argument, -m, to
define the mail delivery agent. It could be a shell script, procmail, or
anything you wanted to take the cron output and move it into the local spool
dir. Would using this solve the problems being debated here? (And since cron
can take a mail agent argument, it should not have a hard requirement for
sendmail.)
-Steve
10:05 a.m.
On Thu, Dec 18, 2008 at 5:27 AM, Steve Grubb <sgrubb(a)redhat.com> wrote:
We ran into a problem doing the LSPP evaluation with regards to
email. Of all
the packages listed, the only one that really mattered for security was cron.
So, what we did was patched cron to be able to take an argument, -m, to
define the mail delivery agent. It could be a shell script, procmail, or
anything you wanted to take the cron output and move it into the local spool
dir. Would using this solve the problems being debated here? (And since cron
can take a mail agent argument, it should not have a hard requirement for
sendmail.)
How would you expose the option to use the argument for a local admin?
Having them edit the service file in init.d seems inappropriate. Would
you expose it in an etc/sysconfig/ file to be parsed at service
script start?
-jef
10:21 a.m.
Jeff Spaleta wrote:
On Thu, Dec 18, 2008 at 5:27 AM, Steve Grubb
<sgrubb(a)redhat.com> wrote:
> We ran into a problem doing the LSPP evaluation with regards to email. Of all
> the packages listed, the only one that really mattered for security was cron.
> So, what we did was patched cron to be able to take an argument, -m, to
> define the mail delivery agent. It could be a shell script, procmail, or
> anything you wanted to take the cron output and move it into the local spool
> dir. Would using this solve the problems being debated here? (And since cron
> can take a mail agent argument, it should not have a hard requirement for
> sendmail.)
How would you expose the option to use the argument for a local admin?
Having them edit the service file in init.d seems inappropriate. Would
you expose it in an etc/sysconfig/ file to be parsed at service
script start?
That just seems like the wrong place to short-circuit an existing good
general solution. If you want root's mail to go somewhere else, use
aliases or .procmailrc. If you want to splat text onto a screen on the
odd chance that someone who cares happens to be watching, add a program
that takes a message on a pipe and does that, and use the existing
mechanisms to run it. Or add one that alerts for mailbox deliveries.
But don't break the well-designed ability to send to multiple
destinations, including local and non-local for the people who actually
do want the messages.
--
Les Mikesell
lesmikesell(a)gmail.com
11:03 a.m.
On Thursday 18 December 2008 11:21:07 am Les Mikesell wrote:
That just seems like the wrong place to short-circuit an existing
good
general solution.
Cron is the only thing that is installed in a default setup that actually
requires mail delivery. For most people, a shell script will do all that's
required. Anyone needing something more sophisticated can easily add postfix
or another MTA to do what they want. As for the other apps, they would
obviously pull in by Requires a real MTA.
We had to make this short circuit for LSPP because there is no Open Source
mail system that understands MLS. But what we did might solve the 99% use
case.
-Steve
10:52 a.m.
On Thursday 18 December 2008 11:05:47 am Jeff Spaleta wrote:
On Thu, Dec 18, 2008 at 5:27 AM, Steve Grubb
<sgrubb(a)redhat.com> wrote:
> We ran into a problem doing the LSPP evaluation with regards to email. Of
> all the packages listed, the only one that really mattered for security
> was cron. So, what we did was patched cron to be able to take an
> argument, -m, to define the mail delivery agent. It could be a shell
> script, procmail, or anything you wanted to take the cron output and move
> it into the local spool dir. Would using this solve the problems being
> debated here? (And since cron can take a mail agent argument, it should
> not have a hard requirement for sendmail.)
How would you expose the option to use the argument for a local admin?
In /etc/sysconfig/crond, there is the CRONDARGS variable where it can be set.
-Steve
11:36 a.m.
On Thu, Dec 18, 2008 at 7:52 AM, Steve Grubb <sgrubb(a)redhat.com> wrote:
In /etc/sysconfig/crond, there is the CRONDARGS variable where it can
be set.
Okay that meets the baseline requirement for the desktop live image.
And obviously kickstart scripts for other spin targets can flip that
config to something else as needed. If we get a Server Spin for
example it could choose sendmail by default and explicitly install
sendmail by default in its kickstart.
But can this be handled in a more sophisticated way so we can get a
system that can handle both the desktop target usecase and the managed
system usecase that Les is trying to articulate by default without a
config file edit?
IF a real honest-to-god mta is installed, can cron grow some logic to
prefer to use the mta if available? For example can the cron service
script see if /usr/sbin/sendmail is there.. if it is..use it... if its
not..fall back to something else (the yet to be written dbus-email
broker)
If that sounds doable, then we can start poking Behdad to write the
missing dbus-email broker as an F11 feature and we can get something
which should not disrupt Les's managed desktop usecase.
-jef
12:21 p.m.
Jeff Spaleta wrote:
On Thu, Dec 18, 2008 at 7:52 AM, Steve Grubb
<sgrubb(a)redhat.com> wrote:
> In /etc/sysconfig/crond, there is the CRONDARGS variable where it can be set.
Okay that meets the baseline requirement for the desktop live image.
And obviously kickstart scripts for other spin targets can flip that
config to something else as needed. If we get a Server Spin for
example it could choose sendmail by default and explicitly install
sendmail by default in its kickstart.
But can this be handled in a more sophisticated way so we can get a
system that can handle both the desktop target usecase and the managed
system usecase that Les is trying to articulate by default without a
config file edit?
I don't think I'd call wanting standard email a 'managed system'. It is
the system helping you manage itself, and I think people would use it if
they were aware that it existed.
IF a real honest-to-god mta is installed, can cron grow some logic
to
prefer to use the mta if available? For example can the cron service
script see if /usr/sbin/sendmail is there.. if it is..use it... if its
not..fall back to something else (the yet to be written dbus-email
broker)
If you really want to go down the reduced-functionality road, it doesn't
make sense to make every program that expects /usr/bin/sendmail (keeping
in mind that not every program in the universe is installed via yum out
of a fedora repostitory...) have to look for alternatives.
If that sounds doable, then we can start poking Behdad to write the
missing dbus-email broker as an F11 feature and we can get something
which should not disrupt Les's managed desktop usecase.
Just write the 10-line shell script version of /usr/bin/sendmail that
discards the message in whatever creative way you like and package it as
an alternative mailer. But, if I can't make them come to my phone when
I want, you've badly broken expected functionality.
--
Les Mikesell
lesmikesell(a)gmail.com
10:14 a.m.
On Thu, Dec 18, 2008 at 09:27:04AM -0500, Steve Grubb wrote:
We ran into a problem doing the LSPP evaluation with regards to email. Of all
the packages listed, the only one that really mattered for security was cron.
So, what we did was patched cron to be able to take an argument, -m, to
define the mail delivery agent. It could be a shell script, procmail, or
anything you wanted to take the cron output and move it into the local spool
dir. Would using this solve the problems being debated here? (And since cron
can take a mail agent argument, it should not have a hard requirement for
sendmail.)
I propose a virtual provides mail(local), in this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=472710
You can skip right to
https://bugzilla.redhat.com/show_bug.cgi?id=472710#c20
--
Pat
2 p.m.
Behdad Esfahbod wrote:
> Note particularly reply #96 stating mail delivery is required by both
> posix and the LSB.
Who cares if my desktop is not POSIX and LSB compliant?
Everyone preparing a distribution of any sort.
Screw standards, we're talking about how to get a decent desktop
system that
boots fast.
Do you not know how to turn services on and off on your own machine?
--
Les Mikesell
lesmikesell(a)gmail.com
2:05 p.m.
Les Mikesell wrote:
Behdad Esfahbod wrote:
>
>> Note particularly reply #96 stating mail delivery is required by both
>> posix and the LSB.
>
> Who cares if my desktop is not POSIX and LSB compliant?
Everyone preparing a distribution of any sort.
I doubt that claim.
> Screw standards, we're talking about how to get a decent
desktop
> system that
> boots fast.
Do you not know how to turn services on and off on your own machine?
I know. My mother does not know. And your mother does not know. And my
girlfriend should not have to know.
behdad
2:57 p.m.
On Wed, 2008-12-17 at 15:05 -0500, Behdad Esfahbod wrote:
I know. My mother does not know. And your mother does not know. And my
girlfriend should not have to know.
Neither does the guy on the bus who's looking for a good replacement to
his frustrating Vista install on his laptop. Or anybody else that I
talk to about leaving Windows or OSX for Fedora, man, woman, or child.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:12 p.m.
2008/12/17 Jesse Keating <jkeating(a)redhat.com>:
Neither does the guy on the bus who's looking for a good
replacement to
his frustrating Vista install on his laptop. Or anybody else that I
talk to about leaving Windows or OSX for Fedora, man, woman, or child.
Surprisingly enough, when I talk to polar bears who are waiting on the
side of the road for the bus at the end of the day...first thing they
ask is "How would I turn off services on Fedora."
-jef"You don't even want to know what the sleddogs ask me
about..NSFW"spaleta
7:13 p.m.
On Wed, Dec 17, 2008 at 08:00:02AM -0600, Les Mikesell wrote:
Even desktop users deserve an environment that follows standards. Has
everyone forgotten October's long discussion on this very subject?
http://fcp.surfsite.org/modules/newbb/viewtopic.php?post_id=298345&to...
Note particularly reply #96 stating mail delivery is required by both
posix and the LSB.
I have searched that on posix, but I have only seen that mailx
is specified and seems to be a mandatory utility. However
the wordings only requires local delivery. I don't think that a
running MTA is needed by the specification.
In the LSB, mailx and sendmail are required, but it seems to me
that only the sendmail comand line interface is needed. Even local
delivery is not mandated (though I may be missing something):
http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-...
However the fact that it is a mandatory posix utility doesn't
necessarily means that it should be on every install. For example
bc is mandatory. It should be brought in by the lsb virtual
package, however, and maybe a virtual posix package should exist.
--
Pat
8:29 a.m.
> > > how about not running a full MTA on a laptop/client
install... at all?
> >
> > that would never be changed. So to have a full blown MTA for local
> > delivery is overkill for a vast majority of situations. I filed a bug
>
> It is true, but more to the point, full blown MTA can do local delivery
> without being started as daemons. So no MTA should be started in the
> default case.
With default configuration, only exim can deliver directly. Postfix
and sendmail need a daemon running or a cron job to actually deliver
the mail.
and exim needs perl and other massives dependencies. is there just a
local delivery agent?
Peter
9:50 a.m.
Peter Robinson wrote:
Anyone who works out that they
want the mail delivered elsewhere should be able to work out how to
install a full MTA.
Errr, do you mean by installing a unix-like operating system instead of
whatever it is you have in mind that fedora should be?
--
Les Mikesell
lesmikesell(a)gmail.com
9:22 a.m.
Arjan van de Ven <arjan(a)infradead.org> wrote:
On Mon, 15 Dec 2008 19:28:23 +0100
Miroslav Lichvar <mlichvar(a)redhat.com> wrote:
> Suggestions welcomed.
how about not running a full MTA on a laptop/client install... at all?
That works if you have reliable, continuous access to the 'net. Not my
case, sorry.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
10:09 a.m.
> > Suggestions welcomed.
>
> how about not running a full MTA on a laptop/client install... at all?
That works if you have reliable, continuous access to the 'net. Not my
case, sorry.
Nothing to say you can't re-enable it yourself. I don't have a
permanent connection to the net but evolution happily holds it in my
outbox until I go back online and can connect to a network. Fedora can
never cater to everyone's needs out of the box without a little
tweaking.
Peter
10:27 a.m.
On 2008-12-16, 16:09 GMT, Peter Robinson wrote:
Nothing to say you can't re-enable it yourself. I don't have
a
permanent connection to the net but evolution happily holds it in my
outbox until I go back online and can connect to a network. Fedora can
I have a nasty surprise for you -- Fedora is not Windows, so it
would is not only for people who use Evolution / Kmail
/ Thunderbird.
Matěj
11:43 a.m.
On Tue, 16 Dec 2008 17:27:02 +0100
Matej Cepl <mcepl(a)redhat.com> wrote:
On 2008-12-16, 16:09 GMT, Peter Robinson wrote:
> Nothing to say you can't re-enable it yourself. I don't have a
> permanent connection to the net but evolution happily holds it in my
> outbox until I go back online and can connect to a network. Fedora
> can
I have a nasty surprise for you -- Fedora is not Windows, so it
would is not only for people who use Evolution / Kmail
/ Thunderbird
sure. and mutt and .. and ..
there's no reason the local MTA (as opposed the thing that listens to
port 25 for the world) can't be smart enough to only go into spool mode
if it has trouble delivering.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
12:45 p.m.
On Tue December 16 2008 11:43:05 Arjan van de Ven wrote:
On Tue, 16 Dec 2008 17:27:02 +0100
Matej Cepl <mcepl(a)redhat.com> wrote:
> I have a nasty surprise for you -- Fedora is not Windows, so it
> would is not only for people who use Evolution / Kmail
> / Thunderbird
sure. and mutt and .. and ..
there's no reason the local MTA (as opposed the thing that listens to
port 25 for the world) can't be smart enough to only go into spool mode
if it has trouble delivering.
Exactly the way it works in Courier, an MTA not even in Fedora (yet?).
jerry
--
To be named later.
10:52 a.m.
On Tue, 16 Dec 2008 17:09:47 +0100
"Peter Robinson" <pbrobinson(a)gmail.com> wrote:
>> > Suggestions welcomed.
>>
>> how about not running a full MTA on a laptop/client install... at
>> all?
>
> That works if you have reliable, continuous access to the 'net. Not
> my case, sorry.
Nothing to say you can't re-enable it yourself. I don't have a
permanent connection to the net but evolution happily holds it in my
outbox until I go back online and can connect to a network. Fedora can
never cater to everyone's needs out of the box without a little
tweaking.
and it's not like sendmail/exim/whatever can't decide to become a daemon
if it can't deliver... but only then.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
12:31 p.m.
Once upon a time, Arjan van de Ven <arjan(a)infradead.org> said:
and it's not like sendmail/exim/whatever can't decide to
become a daemon
if it can't deliver... but only then.
That would require more privilege in the /usr/sbin/sendmail program.
For example, with sendmail, the binary is setgid-smmsp, which is just
enough privilege to write a new entry to the MSP queue directory. You
probably don't want to run a new daemon as a normal user, so then you
have to have a setuid-(someuser|root) binary somewhere to start a daemon
on demand.
You'd still need to do something on boot, since there could be entries
in the queue from the last time the system was up (at which point, you
might as well just start a queue monitor daemon, maybe something using
inotify to only wake up when a new queue entry is written to be a little
more efficient).
Not saying it isn't possible, but it would take some (possibly not
insignificant) changes to make it work sanely and securely and cover the
corner cases correctly.
Also, part of the justification for a local MTA is that some programs
want to use SMTP on 127.0.0.1, which requires some kind of daemon
running there (either an MTA or xinetd to fork an MTA on demand).
If you want a local MTA (which IMHO should be there) and want to make it
work differently (start running a queue only on demand for example),
you're probably going to be better off writing an MTA to match your
special requirements (or starting off with something simple like ssmtp),
rather than trying to shoe-horn such changes into a "full fledged" MTA
like sendmail/postfix/etc.
--
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:46 a.m.
On Tue, 16 Dec 2008 12:31:38 -0600
Chris Adams <cmadams(a)hiwaay.net> wrote:
Also, part of the justification for a local MTA is that some
programs
want to use SMTP on 127.0.0.1, which requires some kind of daemon
running there (either an MTA or xinetd to fork an MTA on demand).
name one .
seriously.
(and this is what xinetd is for anyway)
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
2:37 p.m.
Am Montag, den 15.12.2008, 19:28 +0100 schrieb Miroslav Lichvar:
On Mon, Dec 15, 2008 at 04:26:55PM +0100, Harald Hoyer wrote:
>> http://www.harald-hoyer.de/files/bootchart-16.png
>
> with newaliases this was 100% reproducable.
The fdatasync call comes from db4.
It would be nice if newaliases was executed only when /etc/aliases.db
is older than /etc/aliases, but other MTAs may use the same db file,
so it needs to be updated also after switching mta in the alternatives
system.
Maybe copy the timestamp in the init script to another file and don't
call newaliases only when the timestamps are equal?
This is probably a three line fix for an immediate gain. Sounds good :)
9:51 a.m.
Harald Hoyer wrote:
Dan Williams wrote:
> On Mon, 2008-12-15 at 15:47 +0100, Harald Hoyer wrote:
>> At this point, I recognized that all processes (NetworkManager and
>> newaliases),
>
> Odd, NM isn't intentionally calling fsync() (it's not anywhere in the
> code), nor does glib do that anywhere that I can find. I can't think of
> anything that would require an fsync for NM, so I'm interested in
> finding this and killing it.
http://www.harald-hoyer.de/files/bootchart-16.png
looks very much like it... but I could be wrong, though.
ok, could only very the newaliases fdatasync(). NetworkManager and hald do not
seem to trigger this nor can I find any sync. Might be a normal journal commit
going on there coincidentally.
sorry for the false alarm.
>
> dan
>
9:55 a.m.
Harald Hoyer wrote:
http://www.harald-hoyer.de/personal/blog/fedora-10-boot-analysis
A brief Fedora 10 boot analysis.
Hardware: Asus EeePC 901 with a flash disk.
Time taken from entering the encrypted root disk password until the password can
be entered (after pressing return in gdm). The 10 second wait in nash is ignored
here (which really annoys me and should be configurable in /etc/sysconfig/mkinitrd).
Default Live CD Installation: 39s (bootchart
http://www.harald-hoyer.de/files/f10boot/bootchart-nonread.png)
After installing readahead and running one collection boot process: 36s
(bootchart http://www.harald-hoyer.de/files/f10boot/bootchart-readahead.png)
At this point, I recognized that all processes (NetworkManager and newaliases),
which call a fsync(), let the boot process wait until all data is written to
disk. This is the same effect as the firefox sqlite fsync bug
http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/.
Mounting the root filessystem with relatime and turning off ordered data writing
for the journal with
# tune2fs -o journal_data_writeback /dev/root
improved the situation (even though data might be old on the disk after a crash,
but ext3 does not force the disk to empty the write cache anyway).
Turning off setroubleshoot and fixing
https://bugzilla.redhat.com/show_bug.cgi?id=476023 and
https://bugzilla.redhat.com/show_bug.cgi?id=476028: 32s (bootchart
http://www.harald-hoyer.de/files/f10boot/bootchart-readahead-nosetrouble.png)
Turning off bootchart: 30s
So all in all we have nearly accomplished the 30 Second Startup Feature
http://fedoraproject.org/wiki/Features/30SecondStartup.
Well, no; not if this requires data=writeback. We can't ship that way,
it's a potential security hole. You don't want someone's maildir
suddenly containing pieces of /etc/shadow or whatnot. The old data that
may be exposed by data=writeback may not belong to that user.
-Eric
9:58 a.m.
Eric Sandeen wrote:
> Turning off bootchart: 30s
>
> So all in all we have nearly accomplished the 30 Second Startup Feature
> http://fedoraproject.org/wiki/Features/30SecondStartup.
Well, no; not if this requires data=writeback. We can't ship that way,
it's a potential security hole. You don't want someone's maildir
suddenly containing pieces of /etc/shadow or whatnot. The old data that
may be exposed by data=writeback may not belong to that user.
-Eric
So, we switch to xfs as the default FS? :-)
2:33 p.m.
Am Montag, den 15.12.2008, 16:58 +0100 schrieb Harald Hoyer:
Eric Sandeen wrote:
>> Turning off bootchart: 30s
>>
>> So all in all we have nearly accomplished the 30 Second Startup Feature
>> http://fedoraproject.org/wiki/Features/30SecondStartup.
>
> Well, no; not if this requires data=writeback. We can't ship that way,
> it's a potential security hole. You don't want someone's maildir
> suddenly containing pieces of /etc/shadow or whatnot. The old data that
> may be exposed by data=writeback may not belong to that user.
>
> -Eric
>
So, we switch to xfs as the default FS? :-)
XFS has a nasty bug where it will leave files full of zeros on disk in a
crash.
I think it was Alan Cox that said this could be fixed quite easily by
changing the write ordering for XFS, but that someone who was willing to
maintain the patch would need to do it.
If this was merged I would love to move to XFS :)
2:50 p.m.
nodata wrote:
Am Montag, den 15.12.2008, 16:58 +0100 schrieb Harald Hoyer:
> Eric Sandeen wrote:
>>> Turning off bootchart: 30s
>>>
>>> So all in all we have nearly accomplished the 30 Second Startup Feature
>>> http://fedoraproject.org/wiki/Features/30SecondStartup.
>> Well, no; not if this requires data=writeback. We can't ship that way,
>> it's a potential security hole. You don't want someone's maildir
>> suddenly containing pieces of /etc/shadow or whatnot. The old data that
>> may be exposed by data=writeback may not belong to that user.
>>
>> -Eric
>>
> So, we switch to xfs as the default FS? :-)
XFS has a nasty bug where it will leave files full of zeros on disk in a
crash.
No, it doesn't. Not any more (and technically not ever; what happened
was a truncate & extension of the file (like vi might do) led to a size
on disk but no extents so you got a sparse file. If the apps looked
after their data as they should, this wouldn't happen either, but that's
just an aside).
But anyway,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git&a=co...
I think it was Alan Cox that said this could be fixed quite easily
by
changing the write ordering for XFS, but that someone who was willing to
maintain the patch would need to do it.
If this was merged I would love to move to XFS :)
Go for it.
-Eric
4:06 p.m.
Eric Sandeen wrote:
>> So, we switch to xfs as the default FS? :-)
>
> XFS has a nasty bug where it will leave files full of zeros on disk in a
> crash.
No, it doesn't. Not any more (and technically not ever; what happened
was a truncate & extension of the file (like vi might do) led to a size
on disk but no extents so you got a sparse file. If the apps looked
after their data as they should, this wouldn't happen either, but that's
just an aside).
But anyway,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git&a=co...
> I think it was Alan Cox that said this could be fixed quite easily by
> changing the write ordering for XFS, but that someone who was willing to
> maintain the patch would need to do it.
>
> If this was merged I would love to move to XFS :)
Hasn't there always been a problem with xfs and 4k stacks? Or are you
only talking about 64-bit versions here?
--
Les Mikesell
lesmikesell(a)gmail.com
10:43 a.m.
Les Mikesell wrote:
Hasn't there always been a problem with xfs and 4k stacks? Or
are you
only talking about 64-bit versions here?
Well, we weren't talking about stacks :) but yeah, xfs can use more
stack than ext3, and on a complex IO path that can be a problem. But
4kstacks are another thing taken as holy gospel (though only on x86 for
some reason) so I doubt that will change.
I'm not really serious about xfs as default, btw, but did feel it
necessary to re-educate on the whole "null files" thing. :)
-Eric
5:48 p.m.
On Wed, Dec 17, 2008 at 09:33:47PM +0100, nodata wrote:
XFS has a nasty bug where it will leave files full of zeros on disk
in a
crash.
I think it was Alan Cox that said this could be fixed quite easily by
changing the write ordering for XFS, but that someone who was willing to
maintain the patch would need to do it.
Not guilty.
Ext3 has a set of options for data journalling (at a performance cost). XFS
is not something I look into the innards of as I don't have enough chickens
to sacrifice
11:35 a.m.
Am Mittwoch, den 17.12.2008, 18:48 -0500 schrieb Alan Cox:
On Wed, Dec 17, 2008 at 09:33:47PM +0100, nodata wrote:
> XFS has a nasty bug where it will leave files full of zeros on disk in a
> crash.
>
> I think it was Alan Cox that said this could be fixed quite easily by
> changing the write ordering for XFS, but that someone who was willing to
> maintain the patch would need to do it.
Not guilty.
Ext3 has a set of options for data journalling (at a performance cost). XFS
is not something I look into the innards of as I don't have enough chickens
to sacrifice
Sorry was Andrew Morton in his Google Tech Talk.
5:40 p.m.
On Mon, 2008-12-15 at 16:58 +0100, Harald Hoyer wrote:
Eric Sandeen wrote:
>> Turning off bootchart: 30s
>>
>> So all in all we have nearly accomplished the 30 Second Startup Feature
>> http://fedoraproject.org/wiki/Features/30SecondStartup.
>
> Well, no; not if this requires data=writeback. We can't ship that way,
> it's a potential security hole. You don't want someone's maildir
> suddenly containing pieces of /etc/shadow or whatnot. The old data that
> may be exposed by data=writeback may not belong to that user.
>
> -Eric
>
So, we switch to xfs as the default FS? :-)
Not until someone writes an XFS filesystem shrinker.
5:58 p.m.
Callum Lerwick wrote:
On Mon, 2008-12-15 at 16:58 +0100, Harald Hoyer wrote:
> Eric Sandeen wrote:
>>> Turning off bootchart: 30s
>>>
>>> So all in all we have nearly accomplished the 30 Second Startup Feature
>>> http://fedoraproject.org/wiki/Features/30SecondStartup.
>> Well, no; not if this requires data=writeback. We can't ship that way,
>> it's a potential security hole. You don't want someone's maildir
>> suddenly containing pieces of /etc/shadow or whatnot. The old data that
>> may be exposed by data=writeback may not belong to that user.
>>
>> -Eric
>>
> So, we switch to xfs as the default FS? :-)
Not until someone writes an XFS filesystem shrinker.
Just out of curiosity, do you really do offline root ext3 filesystem
shrinks that often?
-Eric
9:53 p.m.
On Sat, 2008-12-20 at 17:58 -0600, Eric Sandeen wrote:
Callum Lerwick wrote:
> On Mon, 2008-12-15 at 16:58 +0100, Harald Hoyer wrote:
>> Eric Sandeen wrote:
>>>> Turning off bootchart: 30s
>>>>
>>>> So all in all we have nearly accomplished the 30 Second Startup Feature
>>>> http://fedoraproject.org/wiki/Features/30SecondStartup.
>>> Well, no; not if this requires data=writeback. We can't ship that way,
>>> it's a potential security hole. You don't want someone's
maildir
>>> suddenly containing pieces of /etc/shadow or whatnot. The old data that
>>> may be exposed by data=writeback may not belong to that user.
>>>
>>> -Eric
>>>
>> So, we switch to xfs as the default FS? :-)
>
> Not until someone writes an XFS filesystem shrinker.
Just out of curiosity, do you really do offline root ext3 filesystem
shrinks that often?
Often? It's not a question of frequency. It's a question of... ever.
Anyway yes, most recently when caving in and installing Windows XP
dual-boot on previously Fedora only machines. Three of them, to be
exact.
Ableton Live, Team Fortress 2, and Spore just aren't usable in Wine, or
a VM.
1:14 a.m.
Eric Sandeen wrote:
Harald Hoyer wrote:
> So all in all we have nearly accomplished the 30 Second Startup Feature
> http://fedoraproject.org/wiki/Features/30SecondStartup.
Well, no; not if this requires data=writeback. We can't ship that way,
it's a potential security hole. You don't want someone's maildir
suddenly containing pieces of /etc/shadow or whatnot. The old data that
may be exposed by data=writeback may not belong to that user.
For my single user desktop with an encrypted filesystem, it makes no difference
from a security standpoint. Even the pieces of /etc/shadow would be encrypted
and only I can enter the decryption password after a (power?) failure.
5:07 a.m.
On Mon, 15 Dec 2008 15:47:32 +0100
Harald Hoyer <harald(a)redhat.com> wrote:
http://www.harald-hoyer.de/personal/blog/fedora-10-boot-analysis
A brief Fedora 10 boot analysis.
To reach the 20 Second Startup Feature
this begs the question, and you knew I as going to ask ;), if Fedora
wants to reach the 5 second boot that is quite possible on this
hardware, even without too insane compromises.
(which translates to something like 2 to 3 seconds on a full sized
laptop-with-ssd)
If not, I would regret that but it's not something I would have to live
without; I can get a fast boot myself quite fine.
If so, something needs to happen NOW for F11, with a real serious push
for this. It'll involve quite a few people and quite a few packages
that need to get things right, but it's not at all impossible nor does
it require impossible-for-fedora compromises.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
9:01 a.m.
On Tue, Dec 16, 2008 at 12:07 PM, Arjan van de Ven <arjan(a)infradead.org> wrote:
On Mon, 15 Dec 2008 15:47:32 +0100
Harald Hoyer <harald(a)redhat.com> wrote:
> http://www.harald-hoyer.de/personal/blog/fedora-10-boot-analysis
>
> A brief Fedora 10 boot analysis.
>
> To reach the 20 Second Startup Feature
this begs the question, and you knew I as going to ask ;), if Fedora
wants to reach the 5 second boot that is quite possible on this
hardware, even without too insane compromises.
(which translates to something like 2 to 3 seconds on a full sized
laptop-with-ssd)
If not, I would regret that but it's not something I would have to live
without; I can get a fast boot myself quite fine.
If so, something needs to happen NOW for F11, with a real serious push
for this. It'll involve quite a few people and quite a few packages
that need to get things right, but it's not at all impossible nor does
it require impossible-for-fedora compromises.
Yes that definitely should be the goal ... if it is possible to boot
in 5 seconds there is no reason to aim for 20.
9:05 a.m.
Arjan van de Ven wrote:
On Mon, 15 Dec 2008 15:47:32 +0100
Harald Hoyer <harald(a)redhat.com> wrote:
> http://www.harald-hoyer.de/personal/blog/fedora-10-boot-analysis
>
> A brief Fedora 10 boot analysis.
>
> To reach the 20 Second Startup Feature
this begs the question, and you knew I as going to ask ;), if Fedora
wants to reach the 5 second boot that is quite possible on this
hardware, even without too insane compromises.
(which translates to something like 2 to 3 seconds on a full sized
laptop-with-ssd)
If not, I would regret that but it's not something I would have to live
without; I can get a fast boot myself quite fine.
If so, something needs to happen NOW for F11, with a real serious push
for this. It'll involve quite a few people and quite a few packages
that need to get things right, but it's not at all impossible nor does
it require impossible-for-fedora compromises.
Push your kernel patches, so we have a kernel fast boot and sreadahead.
Persuade our kernel maintainer to compile more modules in the kernel.
But, we can't / don't want to drop gnome and most other services, you dropped to
reach 5 seconds.
9:27 a.m.
Harald Hoyer wrote:
Arjan van de Ven wrote:
> On Mon, 15 Dec 2008 15:47:32 +0100
> Harald Hoyer <harald(a)redhat.com> wrote:
>
>> http://www.harald-hoyer.de/personal/blog/fedora-10-boot-analysis
>>
>> A brief Fedora 10 boot analysis.
>>
>> To reach the 20 Second Startup Feature
>
> this begs the question, and you knew I as going to ask ;), if Fedora
> wants to reach the 5 second boot that is quite possible on this
> hardware, even without too insane compromises.
> (which translates to something like 2 to 3 seconds on a full sized
> laptop-with-ssd)
>
> If not, I would regret that but it's not something I would have to live
> without; I can get a fast boot myself quite fine. If so, something
> needs to happen NOW for F11, with a real serious push
> for this. It'll involve quite a few people and quite a few packages
> that need to get things right, but it's not at all impossible nor does
> it require impossible-for-fedora compromises.
>
>
Push your kernel patches, so we have a kernel fast boot and sreadahead.
Persuade our kernel maintainer to compile more modules in the kernel.
But, we can't / don't want to drop gnome and most other services, you
dropped to reach 5 seconds.
I agree with not dropping gnome :) But if we want faster startup we really
should be taking a serious look at trimming startup services.
Some ideas:
1) Make more services not start when not needed, for example bluetooth when
there is no bluetooth hardware, etc. We could even completely stop them from
being a service controlled by runlevel and make them be started from udev instead.
2) Load some services after gdm is up, for example cron, anacron, at,
setroubleshootd
3) Outright remove some services from the default started set, such as a
certain local mta.
Regards,
Hans
10:08 a.m.
Hans de Goede wrote:
Harald Hoyer wrote:
> Arjan van de Ven wrote:
>> On Mon, 15 Dec 2008 15:47:32 +0100
>> Harald Hoyer <harald(a)redhat.com> wrote:
>>
>>> http://www.harald-hoyer.de/personal/blog/fedora-10-boot-analysis
>>>
>>> A brief Fedora 10 boot analysis.
>>>
>>> To reach the 20 Second Startup Feature
>>
>> this begs the question, and you knew I as going to ask ;), if Fedora
>> wants to reach the 5 second boot that is quite possible on this
>> hardware, even without too insane compromises.
>> (which translates to something like 2 to 3 seconds on a full sized
>> laptop-with-ssd)
>>
>> If not, I would regret that but it's not something I would have to live
>> without; I can get a fast boot myself quite fine. If so, something
>> needs to happen NOW for F11, with a real serious push
>> for this. It'll involve quite a few people and quite a few packages
>> that need to get things right, but it's not at all impossible nor does
>> it require impossible-for-fedora compromises.
>>
>>
>
> Push your kernel patches, so we have a kernel fast boot and sreadahead.
> Persuade our kernel maintainer to compile more modules in the kernel.
>
> But, we can't / don't want to drop gnome and most other services, you
> dropped to reach 5 seconds.
>
I agree with not dropping gnome :) But if we want faster startup we
really should be taking a serious look at trimming startup services.
Some ideas:
1) Make more services not start when not needed, for example bluetooth
when there is no bluetooth hardware, etc. We could even completely stop
them from being a service controlled by runlevel and make them be
started from udev instead.
right, directly (and as an upstart event "/sbin/start bluetooth") or via
HAL/DeviceKit
2) Load some services after gdm is up, for example cron, anacron, at,
setroubleshootd
or start them in parallel via upstart
3) Outright remove some services from the default started set, such as a
certain local mta.
Regards,
Hans
5:23 a.m.
Harald Hoyer wrote:
Hans de Goede wrote:
> Harald Hoyer wrote:
>> Arjan van de Ven wrote:
>>> On Mon, 15 Dec 2008 15:47:32 +0100
>>> Harald Hoyer <harald(a)redhat.com> wrote:
>>>
>>>> http://www.harald-hoyer.de/personal/blog/fedora-10-boot-analysis
>>>>
>>>> A brief Fedora 10 boot analysis.
>>>>
>>>> To reach the 20 Second Startup Feature
>>>
>>> this begs the question, and you knew I as going to ask ;), if Fedora
>>> wants to reach the 5 second boot that is quite possible on this
>>> hardware, even without too insane compromises.
>>> (which translates to something like 2 to 3 seconds on a full sized
>>> laptop-with-ssd)
>>>
>>> If not, I would regret that but it's not something I would have to
>>> live
>>> without; I can get a fast boot myself quite fine. If so, something
>>> needs to happen NOW for F11, with a real serious push
>>> for this. It'll involve quite a few people and quite a few packages
>>> that need to get things right, but it's not at all impossible nor does
>>> it require impossible-for-fedora compromises.
>>>
>>>
>>
>> Push your kernel patches, so we have a kernel fast boot and sreadahead.
>> Persuade our kernel maintainer to compile more modules in the kernel.
>>
>> But, we can't / don't want to drop gnome and most other services,
>> you dropped to reach 5 seconds.
>>
>
> I agree with not dropping gnome :) But if we want faster startup we
> really should be taking a serious look at trimming startup services.
>
> Some ideas:
> 1) Make more services not start when not needed, for example
> bluetooth when there is no bluetooth hardware, etc. We could even
> completely stop them from being a service controlled by runlevel and
> make them be started from udev instead.
right, directly (and as an upstart event "/sbin/start bluetooth") or
via HAL/DeviceKit
>
> 2) Load some services after gdm is up, for example cron, anacron, at,
> setroubleshootd
or start them in parallel via upstart
parallel boot isn't much of a gain. The only real advantages are when
there's lots of blocking on hardware other than the disk, and whatever
is gained from flooding the io scheduler with more requests at once so
it doesn't have to predict the future to avoid seeks. The later
advantage disappears once we get readahead right, and by itself it isn't
better than readahead.
Upstart isn't there to parallelize things. Its there to start things
reactively as opposed to in response to arbitrary "runlevels."
--CJD
2:19 p.m.
On Tue, 2008-12-16 at 16:27 +0100, Hans de Goede wrote:
1) Make more services not start when not needed, for example
bluetooth when
there is no bluetooth hardware, etc. We could even completely stop them from
being a service controlled by runlevel and make them be started from udev instead.
There's a tracker bug for things like this --
https://bugzilla.redhat.com/show_bug.cgi?id=222312
Jeremy
9:47 a.m.
Harald Hoyer wrote:
Push your kernel patches, so we have a kernel fast boot and
sreadahead.
Persuade our kernel maintainer to compile more modules in the kernel.
Which ones? A lot have already been done.
http://cvs.fedoraproject.org/viewvc/rpms/kernel/devel/config-generic?r1=1...
was the big one.
Do you have more in mind?
-Eric
10:08 a.m.
Eric Sandeen wrote:
Harald Hoyer wrote:
> Push your kernel patches, so we have a kernel fast boot and sreadahead.
> Persuade our kernel maintainer to compile more modules in the kernel.
Which ones? A lot have already been done.
http://cvs.fedoraproject.org/viewvc/rpms/kernel/devel/config-generic?r1=1...
was the big one.
Do you have more in mind?
-Eric
mmmmhh :) looks good :)
10:09 a.m.
On Tue, 16 Dec 2008 09:47:15 -0600
Eric Sandeen <sandeen(a)redhat.com> wrote:
Harald Hoyer wrote:
> Push your kernel patches, so we have a kernel fast boot and sreadahead.
> Persuade our kernel maintainer to compile more modules in the kernel.
Which ones? A lot have already been done.
http://cvs.fedoraproject.org/viewvc/rpms/kernel/devel/config-generic?r1=1...
was the big one.
Some of those didn't actually work due to higher-level menu items being configured
as modular. (I just noticed this a few days ago.)
11:02 a.m.
On Tue, 16 Dec 2008 16:05:27 +0100
Harald Hoyer <harald(a)redhat.com> wrote:
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
Push your kernel patches, so we have a kernel fast boot and
there's nothing left needed for that, 2.6.28-rc has all you need.
sreadahead.
more tricky; kyle has a cleaned up patch but the fs-devel list tends to
be a black hole ;(
Persuade our kernel maintainer to compile more modules in
the kernel.
But, we can't / don't want to drop gnome and most other services, you
dropped to reach 5 seconds.
it's a total misunderstanding or excuse to claim we dropped services.
Most are started on demand instead. And really, also Fedora could
and should consider being smart about when to start them...
NFS for example should be started on the first mount (trivially
implemented via a post script on the modprobe of the nfs module)
Just throwing in the towel and say "can't do" is how you end up with a
40+ second boot time.
11:23 a.m.
-------- Original Message --------
Subject: Re: Fedora 10 - Boot Analysis
From: Arjan van de Ven <arjan(a)infradead.org>
To: Development discussions related to Fedora <fedora-devel-list(a)redhat.com>
CC: harald(a)redhat.com
Date: 12/16/2008 11:02 AM
Just throwing in the towel and say "can't do" is how you end up with a
40+ second boot time.
The motivation is lacking. Those same people are running on systems that
they never/hardly reboot. They might also use boot time as an excuse to
get up and go to the company water cooler. What would they do if their
computer booted faster then opening their e-mail?
Of course you probably know this. The only solution is to e-mail,
e-mail, and e-mail until you get something accomplished. Good luck. I'd
love to see a 5 second boot in Fedora, but I'm only an "end-user" (atm).
5649
days inactive
5663
days old
147 comments
41 participants
participants (41)
-
Adam Williamson -
Alan Cox -
Arjan van de Ven -
Behdad Esfahbod -
Benny Amorsen -
Bruno Wolff III -
Callum Lerwick -
Casey Dahlin -
Chris Adams -
Chuck Anderson -
Chuck Ebbert -
Colin Walters -
Dan Horák -
Dan Williams -
Dimi Paun -
drago01 -
Eric Sandeen -
Hans de Goede -
Harald Hoyer -
Horst H. von Brand -
James Antill -
Jef Spaleta -
Jeremy Katz -
Jerry Amundson -
Jesse Keating -
Les Mikesell -
Matej Cepl -
Matthew Garrett -
Matthew Woehlke -
Michael Cronenworth -
Michal Schmidt -
Miroslav Lichvar -
nodata -
Oscar Bacho -
Patrice Dumas -
Peter Robinson -
Seth Vidal -
Steve Grubb -
Thorsten Leemhuis -
Till Maas -
Ville Skyttä