Comment 41 for bug 542343

Hmm, I must admit this seems like some kind of a race condition to me. As Lucid in general starts up processes "in parallel", then in a case where the system performance is not adequate, things might go south.
To test this, I have assembled two machines of notably low performance.
The first one is running on a Celeron 667 (sic) MHz CPU. Initially I put 256 megs of RAM into it. It has a 20 GiB hard drive. Swapping as hell, it worked, apart from the fact that its i740 video card didn't support resolutions higher than 800x600 and so I was forced to generate an xorg.conf file and use the vesa driver. But that's another issue. Adding an additional 256 MiB helped to remedy the swapping issue, and, although pretty slow, it still worked.
The second one is the precise Intel Desktop Board with the i815 chipset mentioned in post #38. It has a Celeron 600 MHz CPU and 384 MiB of RAM installed. It uses the embedded video. Oh my - the first logon works as it should, as perhaps the configuration files are generated/cached, but the second one has no panel. Actually the panel launches, and pressing Ctrl+Alt+T to open the terminal and issuing `sudo killall gnome-panel` brings it back up. I tried to edit the /usr/share/applications/gnome-panel.desktop file and uncomment the X-gnome-autostart-phase=Panel line. After doing that, deleting ~/.g* directories and rebooting the panel came up again. And so after several restarts. But then I realized another issue - Nautilus does things the same way, so, although the panel is up, the desktop icons ain't. :(
Needless to say that after installing the updates the .desktop files were changed back to original, so just editing them is not enough, as any updates could put "things back to normal".
I suspect the problem is Celeron 600's performance. I have a Celeron 766 MHz somewhere at home, so if I find it, I'll try to install that CPU on the faulty PC and see whether startup works normally then. It could be that the critical line for using a Celeron CPU is somewhere between 600 and 667 MHz. At least in the configuration I used.
Anyway, regardless of whether my tests will be successful, the very main issue that creates such behaviour is the one Lucid developers are proud of - parallel starting of processes. While giving an advantage on modern multi-core CPUs, this may not work on slower machines. I would be very glad in this regard if there was an option available during the installation (and maybe also afterwards) that would allow me to choose whether I want to start processes in parallel or in a sequential manner, so owners of older and slower machines (anyway, Celeron 600 is still enough for my Grandma to read e-mails) could also run Lucid. At the very least, update manager should not try to be smarter than me and change the .desktop files back to "original". If I have edited them, I think I know what I'm doing and WHY I am doing that... :(

So, the bottom line of this is: I strongly suspect that this "bug" is created by the parallel starting of processes. If a machine, for whatever reason, does not have enough horsepower, a race condition could appear. The obvious solution would be to allow the user to choose a "compatibility mode" where those Gnome things would be started up in a sequential manner.

I will inform you later (after about 10 hours) whether upgrading the CPU to 766 MHz has solved the issue.