Getting the HAL/mounting discussion back in here:
Posted by szopin in libglib thread:

udisks requires libglib 2.31.13, available on Precise (.18) in armel flavour. Going to backup and try forcing it later on today. If that is just 'not going to work' let me know guys, reverting backups is not always successfull and would hate to have to resort to flashing/reinstalling everything

Hurrian:

Wait, hold on there.
You'll need udisks, a very new udev and take out HAL.
That last one will probably break Maemo.
/endquote

So there is no way to keep HAL for everything except storage mounting? Was hoping udisks could be used for mounting whole fs from /opt and keep HAL for the rest as it seems a gargantuan task

No, no, wrong, just no.
udisks mounts the sdcard for us. We define the eMMC (home, opt, MyDocs and hopefully /usr mounts) in fstab.
Maemo being Maemo, it's rootfs is mounted by the kernel at boot-time.

And udev works together with udisks to expose the devices to the system. No going around that. Part of the package.

Ok, so how could DeviceKit be possibly used to save rootfs space?

Come on, it's pure sophism. I'm perfectly aware of "early adopters" problems, but we're far away from times, when optification was arcane magic.

Of course, it's is obstacle for developing on device (yet, instructions on how to use whole 32GB eMMC as root may apply here), but to be honest, szopin's point about compression is much more interesting, IMO. Compression is a fact AFAIK, but isn't it possible to measure NAND actual speed (even including compression) just like we measure eMMC speed? I.E random access and raw read/write, separately? That would be much more appropriate, than "feelings" about something starting faster or not.

I'm quite convinced, that huge speed loss due to transparent compression in NAND is a myth, but it's also pure assumption - based on the fact, that compressing "bandwidth" based on CPU power is still much wider than writing capabilities of NAND (same apply for encrypted swap via TrueCrypt - despite encryption eating CPU, it doesn't make speed to suffer in any way, as it's still encrypting faster, than eMMC is able to write) - at worst, it may result in minimal speed lost on 100% CPU load (and if compression doesn't have highest/high priority).

/Estel

Estel: Yeah I know this is just as reliable as xxxpatch users' testimonies, but do me and yourself a favour: close all microB windows, click on microB and watch the time, takes around 0.5 second for the bookmark window to open up. Move microb-engine to opt, repeat the above, starts instantly. As startup loss of half a second is not even worth arguing about random read/writes etc. doesn't matter as it is not random but ~5MB worth of read/decompression. It does visually for me take more time to start and for you most likely also will. Lets not argue about non-issues.