Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
and again start several regularly used apps and record the start up times.
edit: I just tried this and found no real difference in application start times whereas when I wrote this howto the differences were large and unmistakeable. In the meantime I've moved from using i686 laptops to mostly using an amd64 desktop and I've also recompiled the kernel with the latest version from kernel.org and enabled preemption and changed the timer frequency to 1000 so I can't say which factor made the difference or if it's a combination though I suspect preemption is the key, but at the moment on my system I find application start up times are at least as good when preload is actually uninstalled so it's gone.
Wisdom from my inbox: "do not mock at your pottenocy"
Features
Dates recorded modification (mtime), attribute modification (ctime), access (atime), delete (dtime), create (crtime)
I haven't used ext4 but examples of people's fstab I've seen show noatime being used. If this is from necessity or habit I don't know. Suggest you read Ext4 overview
Wisdom from my inbox: "do not mock at your pottenocy"
(like you said: its about 10 minutes of work and, as far i can tell,
the system seems to be much more solid now
+ one is getting interested in the 'problem/topic'
+ its important for everyone).
thanks for that jalu
I have been a satisfied user of CONCURRENCY=shell since the end of last year, running Lenny (when it was testing) and subsequently Squeeze.
I'm pretty sure that it was recent updates to sysvinit (v2.86.ds1-63) that broke my system, boot stopping with a flashing cursor and no further action (further details below). Commenting the CONCURRENCY=shell line in /etc/default/rcS restored booting.
Interestingly, the difference between with and without CONCURRENCY=shell in the current Squeeze is almost too small to notice, though it certainly made a bigger difference when I first used it.
=====
For the sake of those Googling later, these were the significant lines from the boot process (not the full output):
getpt: no such file or directory
could not get pty for /etc/rcS.d/S02hostname.sh
could not get pty for /etc/rcS.d/S02mountkernfs.sh
The final line to appear before the boot process stopped indefinitely:
Waiting for /dev to be fully populated ... done
<flashing cursor>
I would like to mention, for those so inclined, that after installing insserv and setting the concurrency variable, I could not boot into my system. After removing the package and commenting out the concurrency line, I could once again boot: http://forums.debian.net/viewtopic.php? ... 53#p243853
Luckily this was on an experimental system. I know I would get to keep both pieces.
Hadret wrote:What about Upstart? It's in Sid repository, does anybody use that? Is it fast? (:
I use it and it was originaly developed for ubuntu I belive, when it made it into squeeze and has ben used also for fedore I think it should be quite stable by now.
I mean I got some improvements with it.
Installed it on 3 computers and did not have any problems despite the warnings.
Me too and it worked quite well.
I can now get into my desktop invironment in less then 1 minute.
I doubt it posible to get it any faster without disabling things I use and trow out the ultra slow 5400rpm hardisk.
Is there any easy way of managing scripts in /etc/rc?.?? Cause I have some I need to disable and wondered if there's any simpler way than renaming symlinks starting with S to start with K and than launching update-rc.d script defaults...
[edited]
Got it -- *sysv-rc-conf* (:
Also, is there any place that explains how Debian is booting and which /etc/rc's are launched in what time?
My normal boot was 48.8 seconds. Of that, 6 is for the bios, 4 is for Grub2. So, let's say an even 10 seconds is something other than the system booting up.
Normal boot is therefore 38.8 seconds.
Installed readahead-fedora (readahead just points at this I believe), rebooted twice to allow it to profile the boot. Third reboot was 33.5, so about 5 seconds saved.
Then I tried to install insserv and found it was already installed, strange, but I set concurrency to shell. Reboot was timed again and came in at a slightly faster 32.2, so saved about 1 second with that.
That's right to a useable gnome desktop by the way, with network manager up and running and all panels and wallpapers brought up and ready. It's roughly 10 seconds from GDM to ready desktop, though I never timed that part.
Oh and I've got a pretty slow 7200 rpm hard-drive, because I like things quiet rather than super speedy.
Update
Created a bit of a problem here. Made some changes to /etc/readahead.conf and so wanted to regenerate my profile. Removed the four custom files under /etc/readahead.d and rebooted, thinking it would regenerate. But that is how ubuntu's readahead operates. Oops.
Reinstalling doesn't fix it. Though i haven't tried purging then reinstalling. Can't touch /etc/readahead/profile-once, because that directory doesn't exist. Touch /etc/readahead.d/profile-once doesn't work either. Gonna look for a solution, but if you know of one before I post back please clue me in.
If you're the sole user and use autologin you can save a few megabytes of RAM by replacing gdm with nodm.
[I run Trisquel these days (a FSF approved Debian derivative via Ubuntu) so your mileage may vary. No refunds.]
nodm is an autologin display manager. When you install the nodm package, gdm will be removed. Then you will want to edit /etc/X11/default-display-manager to point to nodm instead of gdm and then edit /etc/default/nodm to first enable nodm and then you probably want to login as somebody else besides root. (If you don't edit these files, you can funk your .Xauthority file. Ask me how I know...)
Should you logout, you will be automagically login again at once. Restarts and reboots work just like they used to.
Since this is a desktop version, how about a server version? Not that booting is that relevant, but I bet there are some other stuff to disable and such.