Well, time for a nice "depressive" post ;-).
So, at the beginning of week I decided to port GParted. Was more or less easy, just a fix for an obvious thinko from the author regarding C++ std namespace ;-). However, it failed on linking stage with infamous rpl_malloc() and friends not resolved for libparted. Looking thru cofigure log, that's of course result of crosscompiling assumptions, but OE has defines for the corresponding tests in autoconf site files, so what was actually happening is shipped parted 1.8.7's configure not loading these site files.
It also turned out that autoreconf'ing of this parted version doesn't work, as it requires autoconf 2.61 and friends as minimal, while OE has 2.59. Trying autoreconfing 2.61 (which is DEFAULT_PREFERENCE=-1 in OE) lead to the same issue with site files loading. At this point I submitted bugs on this, and raised issue on #oe. Actually I didn't even expect immediate big attention, but it caught developers' eye, and with the help of XorA and hrw, to the end of the day we had a solution. (And the root of issue was bug in autoconf 2.61. They used "shell programming patterns" (cough) you really don't want to use in your scripts, and the result is proverbial - they outslied themselves).
Well, on the droop of day, GParted was built. I run in QEMU and was surprised that UI was pretty barely usable on QVGA. Run on a real device to try a real card brought a gore however. First of all, GParted didn't detected my SD card at all. I even went looking at GParted source for how it scans devices, but then run parted on it. "Overlapping partitions now supported" was abort message. Overlapping partitions? Me? No! Wrong call! Fortunately, running fdisk showed instead of the senseless bold accusation the fact that my camera indeed tried to dig weird holes in parttable, apparently confused with ext2 partition there ;-)
Well, finally GParted was run, bliss. But just going thru menus once made them no longer accessible. Already trained on such stuff with LiveRamdisks work, I knew it's out of memory. Running ps aux showed some unusual suspects. Killing them (btw, GParted's RSS was "merely" 15Mb comparing to those 6Mb's. Ah, it's all shared libraries, ok, ok, I shut up.), I finally had the thing live. Now closer look look showed it doesn't recognize EXT2 partition (at least FAT it did). The same in parted. Have no idea is it camera hosed it or it's just proverbial GNU software quality. It also turned out that the only operation I was able to do is to change boot flag for a partition ;-). I tried to format unrecognized partition as EXT2 for example, and it failed after shuffling a card for a bit. Getting to HTML report it laid in the home dir surfaced "sh: nice: Command not found". Oh, oops, dear app ;-).
Finally, I wanted to make a screenshot, but gpe-scap failed to write it, complaining that it can't do UTF-8 -> ISO-8859-1 conversion for PNG CREATOR chunk (soft laugh).
So, what are the conclusions? X is not an ultimate solution, but merely an option. Lure to run large body of existing, and updated, software is still a lure, as besides this opportunity X brings bloat, which on resource-constrained system vice-versa inhibits ability to run all that wealth of soft well.
Also, all those kernel-hacking games are really old. And I hope that everyone on the block understands by now that what they get once kernel is well and polished is havoc in userspace (this applies to new players like Neo1973 too). So, it's time (yes, finally now, if not long ago)
to leave machine-level feudalism behind, and bring all Linux PDA/phone communities together, to work on common aims. And OE is well established community crossroad project, so implementation-wise, that would mean making sure that any more or less developed device is available in OE, and that any newcomer for a questions "Is X supported?" or "Where can I find stuff for X?" could be answered "Use OpenEmbedded." Yes, right that - use OpenEmbedded, period. Not even "You can use OpenEmbedded, just copy one to another one, and tweak this and that".