The MM10 sometimes wakes from suspend to chuck me out to the Gnome logon, losing my session. Then when I try logging on again, Gnome is broken.

I suspected XServer crashes. Yep according to /var/log/Xorg.0.log . Looked at internet. It’s sort of pear-shaped. Sorry, that was a pear I was looking at then. Googled it. Turns out the net is littered with veterans from the war against this one.

Looks like XServer is trying to do its own power management via ACPI, and that seems to get broken when other thingies are trying to suspend/resume at the same time. Still unconvinced. But here are the magical incantations:

In Xorg.conf:

Section "ServerFlags"
	Option "NoPM" "true"
EndSection

also, need to pass a flag to X at startup. X is started by the display manager (Gnome/gdm) in my case. On debian, gdm’s config is /etc/gdm/gdm.conf. It has several clauses for starting different flavours of X session. Change all of the lines of the following kind to add the -noacpi flag:

command=/usr/bin/X -noacpi -audit 0

About to try this. Wish me luck.

Credits: too numerous to mention. Try googling ‘x server crashes resume suspend’

UPDATE:

Didn’t work. Blah. If you want, try it. Others have found success.

After aptitude safe-upgrade , I’m downgraded to a previous version of NetworkManager, and network-applet-gnome. These don’t work on the MM10 with madwifi.

Luckily, disconnected as I was, I still had the snapshot sources for the two packages in /var/tmp …

I re-configured, rebuilt, ran make install

The lenny NetworkManager stuff installs into /usr/local/sbin, but my version went into /usr/sbin, because I used the following configure line:

./configure --enable-maintainer-mode --prefix=/usr --sysconfdir=/etc --localstatedir=/var

So, to clean up:

cd /usr/local/sbin
mv NetworkManager NetworkManager.dontuse
mv NetworkManagerDispatcher NetworkManagerDispatcher.dontuse
ln -s /usr/sbin/NetworkManager /usr/sbin/NetworkManagerDispatcher .

Finally, ran restart:

/etc/init.d/NetworkManager restart

and off it goes, connecting. And here I am again! Byeeeeee.

Luckily, SpotlightFS continues to be developed. I went straight to the MacFuse Google Code page, and it just mentioned an unsupported Tiger version.

To install, I did:

0) Ensured I had MacPorts

1) Install:

port install spotlightfs

Failed for me, because I had the Tiger version hanging around still, so I de-installed it:

/Library/Filesystems/fusefs.fs/Support/uninstall-macfuse-core.sh

Then the next attempt running port install spotlightfs failed because of a ‘header not found error’. I did a port search fuse, and apart form the wonderfully named ‘libconfuse’, there was also a ‘libfuse’…assuming something wasn’t working with Darwin Ports’ dependency checking, I installed everything in this order:

port install libfuse
port install fusefs
port install libfuse
port install spotlightfs

Yes, I did libfuse twice…but just in case that’s significant, I offer it up anyway…didn’t seem to harm anything.

Can package systems resolve two-way dependencies?

E.g., say Pkg1 depends on the headers of Pkg2 to build, but Pkg2 depends on the libraries of Pkg1 to build… The correct answer is:

1. Install Pkg1 source
2. Install Pkg2 source (although at this point, it could happen before Pkg1)
3. Build Pkg1
4. Build Pkg2

I know sometimes you get the ‘devel’ package separate from the ‘run’ package, and that would mean it’s possible to do the above manually, but do package systems like DarwinPorts do it automatically?

I tried turning on ‘Nice Effects’ in Ubuntu’s Appearance preferences, but received an unhelpful ‘did not work’ error. I think that the next version of Gnome should have a random witticism generator instead. At least then it may disarm the urge to shout at the screen, fist clenched.

It turns out that ‘Nice Effects’ depends on Compiz, and my diddly laptop cannot handle that (at least Compiz won’t build). Bah!

The ‘Didn’t Work’ dialog, and the ‘Because of a Problem’ dialogs in Gnome remind me of a recalcitrant teen serving in a shop, who has been forced to do the job by his parents as they refused to continue supplementing his Mobile Phone account unless he got up and squeezed every ounce of oomph from his meagre motivational reservoir, and did something a little more productive than sitting in his darkened room listening to Emo Classics, Vol 3: The Best Depressing Music In the World, Ever…

Me in shop, to a young person of the above cast: “Excuse me, have you got this in blue?”
Teen: “Dunno…No.”,
Me: “Um, have you looked in the stock room?”,
Teen: “No”…

Have you noticed no matter how much weariness, sadness, irritation (or combination thereof) which you attempt to convey in your expression or voice at that point really doesn’t make any impression whatsoever? Then it dawns on you that this fragment of all of our futures truly does not see any issue, or reason to take further action. You’re an ex-problem.

Back to the Gnome example: the correct error message would be helpful and empathetic. In this case, it (the error message) would tell me—probably addressing me as ‘Sir’–how terribly sorry it was, but it could not fulfil my request as it was missing a vital component, and that unfortunately, to it’s eternal sadness, it cannot use that component on Sir’s behalf, as Sir’s hardware is shall we say, not quite the latest model (the error would pause to convey a potentially distressing fact, and to emphasise its regret). On the other hand, the error might continue, if Sir was in need of a lesser, but still most gratifying enhancement of Sir’s visual and graphical spectacle, then Sir might consider the package just down the road on the left, by the name of ‘xcompmgr’. The error would finish by saying, if Sir was to take possession of suitable hardware in the future, then Sir would of course be most welcome to return to this dialogue, whereupon the manager, Mr Gnome, would personally attend to his needs. Good day.

There you are, teen-boy-in-shop, that’s customer service!

xcompmgr

Some nice settings:

xcompmgr -cCfF -r4 -o.65 -l2 -t2 -D2

The incantations to make it work…

in /etc/X11/xorg.conf:

Section "Extensions"
	Option	"Composite"	"Enable"
EndSection
...
Section "Device"
	Identifier	"Silicon Motion, Inc. SM720 Lynx3DM"
	Driver		"siliconmotion"
	Option		"UseBIOS"	"off"
	Option		"pci_burst"	"on"
	Option		"fifo_aggressive"	"on"
	Option		"RenderAccel"	"true"
	Option		"AllowGLXWithComposite"	"true"
	BusID		"PCI:0:9:0"
	VideoRam	16384
EndSection

The only thing in the Driver section that is (or may be) necessary is AllowGLXWithComposite. The rest are aggressive acceleration options for SiliconMotion, which do actually seem to speed things up.

I’m not sure about the VideoRam argument. This is stating that the siliconmotion driver should treat the inbuilt graphics card as though it has 16M of Video RAM, when in fact all of the specs show that the Lynx 3DM chip only has 8M of Video RAM. So what’s the point?

Like a lot of this, I don’t have the time to discover the reason, and so it remains a magical incantation that makes me feel better, and is gentler on the skin than repetitive hand-washing.

BTW. I don’t have anything against teens. I was one once.

In Drivel, select MovableType, and enter the following URL: ‘http://<journalName>.wordpress.com/xmlrpc.php

Vanilla install of Ubuntu 8.xx on MM10, with Ubuntu Desktop (gnome) and encrypted LVM…

1. Didn’t auto-detect monitor. Need to go in and edit /etc/X11/xorg.conf manually

2. longrun not installed by default

3. Authentication seems flaky. Sometimes I am asked several times for my password.

4. To get to a root prompt:

$ sudo su

Optionally, can use ‘passwd’ then to set a root password, which is undefined by default on Ubuntu

5. Suspend doesn’t work.

6. Need to resize fonts a bit — too large for DiddlySharp

7. Otherwise, looking good!

I’ve been dabbling with Linux now for a couple of months.

When I started, I was sure that I wouldn’t be doing anything new compared to others who ‘went before’ — I would just be covering ground worn bare by the sneaker tracks of other, more experienced geeks. My task was to avoid the traps, and the dead-ends, marked by the forum posts that trail off into nothing, or with a plaintive ‘Haven’t heard anything for two months now. Please help!’ posting.

As everyone knows the Geek’s last cry is a terrible sound to hear — somewhere between the call of a dying elephant and that of a distressed hamster. Shiver.

I discovered quickly that Linux is on two tracks:

1. The academic-driven track, where new concepts and technologies are developed and implemented, often in C/C++ with a low-level non-gui interface
2. Those who believe that, with a bit of effort, and if everyone just ‘pulls together’, Linux will become the desktop-environment-to-end-all-desktop-environments

Lurking in the sidelines are the big companies who wait for something worth cherry-picking to turn up, and then they cherry-pick the products of the first of the Linux types, add their own spin, and make lots of money. Cough, cough Asus-tishoo..

The second Linux type is full of missionary zeal, and often youthful energy. They respond almost immediately to people posting questions on the forums they own.

In between all of the honest, wonderfully generous hard-graft, there is also time to have the Linux version of the sneering conviction that no-one else can do anything half as ‘cool’ as we can attitude that infects open source.

That is the problem.

They want to make their component the best it can be, and will soon become irritated by the lack of facilities that dependent other components offer up to their component. So what do they do? They ask for patches in the other components to give them the functionality they require.

That is why most forum postings end in: “You should be using Patch xyz of <dependent component>”, and the forum poster replies “That fixed it! Thanks!” If you are like me, you feel sudden elation, followed by a brooding depression: now I’ll have to patch, recompile, and try again. And then, I’ll find the patched component doesn’t quite work with <other component>, and so on.

From having this occur repeatedly to me, I began to believe that I was simply ‘on the bleeding edge’ of Linux, and suddenly I began to become infected by the same revolutionary zeal of the component writers. I thought “Maybe I can make a difference! Maybe, if I pull all of the right levers, twiddle all of the correct knobs I can create the most perfect installation of Linux ever!”

And so began the ‘tail chasing’ of someone who believed he was only ever an hour away from Linux Nirvana.

1. Install latest ‘testing’ version of NetworkManager (say)
2. Install latest ‘testing’ version of WPA Supplicant (say)
3. It kinda works, but not automatically when I wake the laptop up from sleep.
4. Install cutting edge version of NetworkManager, compile from code if necessary
5. Try again. Now all of my network APs look like gibberish.
6. Forum search
7. Install cutting edge version of WPA Supplicant
8. My networks are fixed!
9. Buy new network card
10. My networks are broken!
11. Install patches for NetworkManager
12. Grow several grey hairs
13. etc.

In fact, it really is best to get off the bleeding edge, or you’ll get hurt. Not to realise this is to indulge in masochistic fantasy.

I also believe that the very enthusiasm which makes Linux so dynamic is also its weakness.

I want to develop the theory here that the GUI component writers are closet sadists, releasing patches to dependent components in an uncontrolled way, thereby potentially breaking everything, and requiring the masochistic masses to follow the path of pain.

In other words, I want to propose the theory of Sado-Masochistic Software Development which will always stay one-step behind capitalist companies paying non-masochistic employees to develop to a vision…because if it ever led the world, it wouldn’t have anything to beat itself up about, and then it would be as bad as ‘The Man’. In the end, being a leader is too scary.

Most people will look at what I have written in the previous paragraph, and snort, laugh, or just get angry. Or ignore it.

I am suggesting no less than a massive collusion between developers to believe in ‘them and us’ so that they can always define themselves as ‘us’: the Honest Geek Syndrome.

The very ‘freedom’ that allows anyone to release a component which claims to work well with the rest of the environment, and which is ‘a lot better than the old <component>’ is what creates the world of pain we inhabit; one in which the dependencies between patch-levels can grow exponentially.

The only answer is more control, and a reigning in of creative impulses without responsibility.

Yes, our betters have said it for years: without discipline, we’ll never amount to much.

Installed ‘longrun’ package to control Centrino power saving,


longrun -p

cack’d out with ‘cannot read blah blah’. A bit of Googling said sometimes (whether using udev or not), the correct query nodes are not created automatically.

This needs to be done on each boot.

An answer is to add the following to your /etc/rc.local:

# Create nodes for querying CPU performance (longrun)
for i in 0 1 2 3; do
	mkdir -p /dev/cpu/$i
	mknod -m 444 /dev/cpu/$i/msr c 202 $i
	mknod -m 444 /dev/cpu/$i/cpuid c 203 $i
done

# Default to highest performance
longrun -f performance

Note, the final line. I found out that by default, my MM10 was running in ‘economy’. Now I have a massive battery attached, I think I can afford a little careless power.

Excuse me, I have a man with an axe from the Green Party at the door. I’ll be back in a mo…

Here

After getting suspend2 and hibernate working from the command line, the way to integrate these sleep/hibernate methods into gnome-power-manager world is to change the underlying HAL query scripts that gnome-power-manager uses.HAL abstracts hardware details from upper layers. That means:

1. It allows querying of a ‘virtual hardware’ machine so that upper-layers don’t need to worry so much about adapting to each and every hardware variation
2. it provides ‘actions’ on the ‘virtual hardware’ via scripts in /usr/lib/hal/scripts

gnome-power-manager uses these HAL scripts to poke your machine into doing the right thing.HAL is SOOOOOO concerned with abstraction, that it also seems designed to abstract away the fact we’re using linux…so it has sub-directories in /usr/lib/hal/scripts for each OS.Here, we’re interested in /usr/lib/hal/scripts/linux.And, we’re particularly interested in the HAL actions for power management:hal-system-power-hibernate-linuxhal-system-power-suspend-linuxetc…For whatever reason, my default scripts only support actually doing the power management (in a concrete sense) via pm-tools…an alternative to hibernate. So, I added a few bits to support hibernate as well.Note, the scripts as they are are mostly about setting up params to pass to pm-tools to handle ‘quirks’ of hardware. Hibernate handles quirks itself, so we don’t need to use all of the quirk code here. Just call hibernate-ram or hibernate-disk or whatever…E.g., hal-system-power-suspend-linux will end up with a section as so:

...  # We support hibernate-ram and pm-utils

if [ -x "/usr/local/sbin/hibernate-ram" ] ; then

# All Quirk handling delegated to hibernate script

/usr/local/sbin/hibernate-ram

RET=$?

elif [ -x "/usr/sbin/pm-suspend" ] ; then

/usr/sbin/pm-suspend $QUIRKS

RET=$?

else

# TODO: add support

unsupported

fi ...