On MeeGo
Whatever MeeGo was, it never made it into the open source mainstream, which I consider to consist of projects actively worked on by volunteers and companies alike, and didn’t manage to become an project attractive enough for individual open source enthusiasts not driven by money to make substantial contributions.
There is enough room to speculate over the reasons why this is. My personal take is that MeeGo failed to be a successful open source project because the corporate commitment to the open source idea was not strong enough and expectations were too high right from the start.
Open source projects start with an idea and evolve into a proper product over time. Sometimes they are developed incrementally, sometimes it happens that big parts of them are replaced all at once. The idea behind an open source project may be huge but they all start off with baby steps. MeeGo, however, wasn’t supposed to. The idea behind MeeGo was big, and due to market pressure it was expected to become complete and successful quickly. It occurs to me that the idea was to sort of guarantee success by providing the project with professional, corporate governance.
I think everyone who started working on open source as a hobby knows that this is something a lot of hackers don’t are comfortable with. An open source project under corporate leadership may easily suffer from top-down decisions that give developers the feeling of working in a restrictive environment rather than a playful one. I’m not surprised by the fact that the only people I know ever contributed to MeeGo worked either for/with Intel or Nokia.
It isn’t the technologies, tools or frameworks that are reason for the failure of MeeGo. KDE and GNOME are large and successful projects based on Qt, GTK+, Clutter, D-Bus-based desktop middleware etc. What has lead to failure in my eyes—-the eyes of an outsider, opn source developer and potential user—-is that the dynamic nature of open source projects conflicted with corporate expectations and hopes for a quick success they needed so badly. Add to that the pressure on Nokia, the corporate culture clash of two global information technology companies and the fast pacing world of mobile devices and interfaces, and you have a pretty explosive mixture.
Personally, I won’t place my bets on Tizen. I can only imagine how frustrated and disappointed everyone who tried to get involved may be today, even those who contributed to MeeGo as part of their work for Intel, Nokia or one of the many smaller companies that make up the corporate part of the open source ecosystem. It is also frustrating for me as a developer aiming for a job in open source and desktop/mobile/UI technologies.
I guess the mobile open source platform we are all hoping for will be there some day. But it will only appear slowly, driven by the efforts of enthusiastic individuals with big ideas, realistic expectations and sound knowledge of the pace and dynamics with which open source projects grow and mature. This of course relies on open hardware and I don’t know enough about the manufacturing industry to predict the availability of open, hackable devices in the near future.
In the meantime, the best we can do as open source software developers is improve the base OS level and innovate in desktop/mobile/UI technologies by experimenting with new ideas and extending existing frameworks. I’ll help where I can.
Meego installation on a USB stick
This post wouldn't be if the hard-drive from my Acer Aspire One didn't die. I have a fresh backup of the disk (a full 'dd' plus a separate one for just the home partition) so if I need something back, and I know I don't I care but backups are important, I can always mount it in a loopback and copy files.The hard-drive is actually, what I want to call it, a cheap and fake SSD. It's a PATA SSD that I'm sure I will never find a replacement for. Look:
Now the dilemma was easy, or I threw the netbook to trash, or I found something to boot on. I started to look for a solution and Meego just got released, this is crazy timing. I downloaded the boot image and tried it out, and guess what, it is getting better and better. It's definitely more beautiful, it is getting faster, it has better dialogs for customization, well just try it out if you didn't yet, you wont be disappointed but surprised.
So in the end, installing a system on a USB stick is the only solution I can come up with. I ordered an extra USB stick, but mini please, a Kingston DTmini10! Now when I tell people this is my actual hard-drive, they are like “say-whaaat.”
The installation of Meego didn't went that fluently. I have two USB sticks, one with the boot image, another serving as target device for installation. The installation worked fine without any modification, it boots but ends on a black screen with the CAPS del blinking. Boo, kernel panic, or something else ungroovy. I also tried an installation with the file-system ext3, the default is btrfs, but then the grub installer fails and the Meego installer is knocked out in a waiting sequence. So I did a default installation again, sigh. After a search I tried out some parameters for the kernel command line and adding “rootdelay=8” did the trick. In fact, the USB stick boots without problem, but past that there is some delay for the kernel to discover the USB device, you can then see the following message:
sd 11:0:0:0: [sdx] Assuming drive cache: write through
If there is no rootdelay parameter there is no root device found, and booting just ain't gonna work out. End of story. There are some tiny tweaks to be done afterwards. The kernel command line must point to the right root device, just like for the fstab file. The kernel command line can be edited in the file /boot/extlinux/extlinux.conf. Everything else works out just fine. Booting time, except the rootdelay, is acceptable, but shutting down seems to be endless, and precisely when I want the netbook to turn off I want it to be really fast. I'm going to send it to sleep more often than usual, by closing and opening the lid, which is the fastest “boot” sequence one can get ;-)
Meego installation on a USB stick
This post wouldn't be if the hard-drive from my Acer Aspire One didn't die. I have a fresh backup of the disk (a full 'dd' plus a separate one for just the home partition) so if I need something back, and I know I don't I care but backups are important, I can always mount it in a loopback and copy files.The hard-drive is actually, what I want to call it, a cheap and fake SSD. It's a PATA SSD that I'm sure I will never find a replacement for. Look:
Now the dilemma was easy, or I threw the netbook to trash, or I found something to boot on. I started to look for a solution and Meego just got released, this is crazy timing. I downloaded the boot image and tried it out, and guess what, it is getting better and better. It's definitely more beautiful, it is getting faster, it has better dialogs for customization, well just try it out if you didn't yet, you wont be disappointed but surprised.
So in the end, installing a system on a USB stick is the only solution I can come up with. I ordered an extra USB stick, but mini please, a Kingston DTmini10! Now when I tell people this is my actual hard-drive, they are like “say-whaaat.”
The installation of Meego didn't went that fluently. I have two USB sticks, one with the boot image, another serving as target device for installation. The installation worked fine without any modification, it boots but ends on a black screen with the CAPS del blinking. Boo, kernel panic, or something else ungroovy. I also tried an installation with the file-system ext3, the default is btrfs, but then the grub installer fails and the Meego installer is knocked out in a waiting sequence. So I did a default installation again, sigh. After a search I tried out some parameters for the kernel command line and adding “rootdelay=8” did the trick. In fact, the USB stick boots without problem, but past that there is some delay for the kernel to discover the USB device, you can then see the following message:
sd 11:0:0:0: [sdx] Assuming drive cache: write through
If there is no rootdelay parameter there is no root device found, and booting just ain't gonna work out. End of story. There are some tiny tweaks to be done afterwards. The kernel command line must point to the right root device, just like for the fstab file. The kernel command line can be edited in the file /boot/extlinux/extlinux.conf. Everything else works out just fine. Booting time, except the rootdelay, is acceptable, but shutting down seems to be endless, and precisely when I want the netbook to turn off I want it to be really fast. I'm going to send it to sleep more often than usual, by closing and opening the lid, which is the fastest “boot” sequence one can get ;-)
Moblin blazing fast
I updated my netbook to give it a new look. I switched the Xfce Panel against bmpanel2 and changed the background (the previous definitelly lasted very long.) Not much changes, but I topped a cold boot of about six seconds, always faster baby :-P And the window manager is OpenBox by the way.
The only real useful entry missing in this panel is a battery monitor. At least I have an indicator over the keyboard that starts blinking when there is about three percents left. What I like about this panel is the cool themes that it is provided with, however the configuration is set through a hand-written configuration file which sucks but what do you want, it is extremely lightweight on the other hand.
Update: Should I mention I totally forgot about the Xfce power manager? Well I did, and it is provided with a notification icon displaying the battery status :-) However I had to fix the default ACPI script related to the lid, since HAL doesn't list it, in order to get the netbook to go into sleep.
Moblin blazing fast
I updated my netbook to give it a new look. I switched the Xfce Panel against bmpanel2 and changed the background (the previous definitelly lasted very long.) Not much changes, but I topped a cold boot of about six seconds, always faster baby :-P And the window manager is OpenBox by the way.The only real useful entry missing in this panel is a battery monitor. At least I have an indicator over the keyboard that starts blinking when there is about three percents left. What I like about this panel is the cool themes that it is provided with, however the configuration is set through a hand-written configuration file which sucks but what do you want, it is extremely lightweight on the other hand.
Update: Should I mention I totally forgot about the Xfce power manager? Well I did, and it is provided with a notification icon displaying the battery status :-) However I had to fix the default ACPI script related to the lid, since HAL doesn't list it, in order to get the netbook to go into sleep.
Fed up with Moblin
I slowly begin to be fed up with Moblin, the base installation. The base system starts way too often with core-dumps (crash on mutter f.e. which also means X restarts), but mainly because of RPM. When package-kit starts to check for an update — or when you do any installation/upgrade with yum e.g. you use rpm directly or indirectly — the whole system goes unusable, the browser acts like it is frozen, it takes very long to switch between tasks, and all of this for at least a minute up to an hour if you accept to run an update. You can call this whatever you want, I call this a big fail.This happens on an Acer Aspire One 9", where I guess they installed the cheapest SSD out there.
In fact things were getting really bad when I switched to an Xfce session, I received unbelievable long startup times. Uxlaunch, the new automatic login application on Moblin 2.1, is totally uncooperative. The Xfce session ends launching many tools and applications twice, two corewatcher-applets, two connman-applets, etc. Uxlaunch will run xfce4-session, but also executes the same desktop files — as it seems after a quick look in the code — from the autostart directory, which is a role taken by the Xfce session manager.
So I have been looking around to finally throw away some junk.
Now I have been looking close at the autostart applications since the "all-in-twice" fiasco to get this netbook fast again. Of course you have to know what you do, this kind of tasks isn't open to people without technical skills. First I changed the default "desktop" to Openbox, by downloading the RPM source package, compiling it and putting it inside the uxlaunch configuration file. Then I have been removing some base packages and manually hiding some desktop files to avoid them to autostart — I have been playing with the Hidden/NoDisplay key but it didn't have any effect on uxlaunch so it ended with a chmod 000 command.
I dropped four packages, kerneloops, corewatcher and obexd/openobex. I really don't want them around anymore. And I "dropped" seven autostart files, ofono which depends on a lot of applications, the bkl-orbiter, and the rest are Moblin panel related applications, bluetooth-panel which I don't even have on this netbook, carrick-panel as I use connman-applet which works at least for an automatic connection, two dalson applications dalson-power-applet and dalston-volume-applet, and at last moblin-panel-web.
I kept the gnome-settings-daemon although I have the Xfce settings daemon installed which I do prefer at some extends. And after all this I changed the GTK+ and icon themes through the gconf keys. And what's the conclusion? Moblin is nice, but I managed to munch it and enforce my desktop.
Update: After running under OpenBox I feel that my remark toward RPM is wrong, I don't know maybe it is the mixed use of OpenGL that makes the tasks taking ages to react. All in all, the default desktop environment is something where you must know about patience :-)