Again,

A quick post on Moblin repository updates.

I added wine 1.1.38 on my small Moblin repository. Aside from this, I added sane-backend, libieee1284. I also backported latest gphoto2 and libgphoto2 sources into moblin as well.

This should all be working properly. If there are any dependencies which I forgot to upload, please do inform me.

Hi there guys,

I noticed moblin’s repository of packages are quite limited. Yes, I know, moblin is gonna be meego in Q2 2010, but for the moment, I need my application fix.

Presenting a little moblin rpm repository until I meego comes, or whatever…

Two applications are in there, GFtp and Gnumeric. Those applications fitted my requirements for a useable netbook system.

To use the repository, just enter this as ostalks_moblin.repo in the yum.repos.d folder (updated to ibiblio):

[ostalks_moblin]
name=OStalks Moblin Repo $releasever – $basearch
baseurl=http://mirrors.ibiblio.org/pub/mirrors/ostalks/moblin/RPMS/
enabled=1
gpgcheck=0

I am also willing to compile applications for you guys, when I do get the time – I’m doing this on my own free time.

Have fun installing!

Well, it’s a short post.

Since I was around the area and was more or less free during the time, I attended a short meeting with a local Linux Users Group at the G2iX Techbar, IT Park, Cebu City, of which I am a member.

There was basically a short talk on Liferay, an Open Source Portal, Collaboration, Social Networking tool written in Java. After the talk was a discussion between the members about activities within the year.

Like I said, nothing much. People like Tom Wickline, head of the Bordeaux Group (a front-end to WINE), and writer to Wine-Reviews attended the meeting.

It also allowed me to show off my netbook running Moblin.

For those who don’t know who G2iX is, they’re a company headquartered in Manila, and specializes in Ruby on Rails development, Java, Dev Automation and Cloud Platform Deployment. They have also received awards like the Top Asian TechnoVisionary Awardee for 2006/2007 by ZDNet Asia, Top 20 Open Source Companies by Red Herring, among others.

A few days ago, we heard of the big news that Intel and Nokia have started consolidating their Moblin and Maemo codebases and have come up with a new distribution named Meego.

From the blog, it states that they “are taking the best pieces from these two open source projects and are creating the MeeGo software platform. Both teams have worked for a long time to support the needs of the mobile user experience – and MeeGo will make this even better.”

As I knew that Maemo’s interface was more suited for the mobile phone area for Meego, I decided to look into Moblin itself and see how it would serve the role of addressing the netbook part of the new platform.

As we see it currently, the pre-built Moblin live image is a largely Fedora 10 based distribution. It can however be built from Fedora 12, and Ubuntu 9.10. It is interestingly enough that the resulting build with be rpm based, not deb based.

Installing the live image to harddisk on my Benq Joybook was simple enough – it was actually similar to the Fedora/RedHat installs that I am used to.

Booting up was a treat: compared to Ubuntu Netbook Remix, the interface was intuitive and smooth.

The Miser interface upon first boot shows practically a wonderful display of your tasks, favorite apps, documents opened and other stuff that you’ve just used.

Different tabs allows the user to navigate through different sections of Moblin – easily categorized into media, internet, status, applications, zones, people and pasteboard.

The way that Moblin is organized is, in my opinion, one of the best interfaces that I’ve seen in a linux distribution for netbooks. It simply is the best optimization of space for 8″ to 12″ screens.

There are drawbacks however.

For one thing, NTFS is not supported in moblin. And due to licensing issues, the MP3s and H264 video is not supported out of the box, as well as proprietary codecs.

Another thing is that Moblin’s repository is still rather small. Understandable though, because this distribution is meant for netbooks.

There are a number of hacks you can do though, one is you can use the Fedora 10 (and sometimes 11) repository to download other programs.

Another option is to compile the source rpms from the fedora repositories yourself. The trick is to enable the development tools of moblin by typing in the command:

sudo yum groupinstall “Development Tools”

If you’re a little lazy to compile gstreamer yourself, you can use a repository created by a Moblin user named Matthi. The repository, albeit small, includes some nice programs to install for Moblin, such as WINE, Blender, and the gstreamer plugins to make your Moblin distribution run codecs supported by ffmpeg. You can get instructions for his repository here.

What is the Moblin’s future as Meego? I would say, rather bright. Seeing how the interface really compliments the Intel Atom netbook specifications nicely, I believe that most of the GUI Moblin has implemented will be carried on in the netbook versions of Meego. A possible challenge will be on how to implement the user experience on the Qt toolkit (Meego will be based on it, rather on GTK that Moblin uses). Since Moblin uses the Mozilla codebase for it’s integrated browser, it is not farfetched to assume that Meego will implement the Webkit browser as it’s integrated browser for the Qt for it’s WM/Miser interface.

As Qt has integrated media, browsing, APIs, as well as a compositing engine compared to GTK (Gnome still uses Compiz as it’s compisiting engine), we would probably see a more integrated architecture internally, when Meego reaches it’s final stages of development into stable.

Nokia and Intel would benefit each other, because for one reason, Nokia has a netbook. Also, Nokia’s design principles are horrible and clunky (see the S60 interface on symbian as an example) and is also seeing pressure on their interface designs from competitors like Google and Apple. One thing that Nokia has, is that they’re great at hardware R&D (especially mobile), and it is my belief that Intel is also looking into the mobile sector, especially considering that OSes like chrome, and android run on ARM processors and are indirectly competitors with Intel on this space.

All in all, I would say that if both Intel and Nokia play their cards right, Meego will be a very good competitive platform for mobile and netbook apps in the future.

There’s an interesting writeup by Gabriel Forster in his blog on how he implemented linux on the Christian School that he was teaching in.

He started: “Like many other people, our church and, more importantly, our Christian school, ran the Windows operating system on all computers.”

Basically the computers he had in the school amounted to 40 computers initially, with some 65 computers donated a year ago. The problem that came about was of licensing all those computers. Although they had 100 licenses of Windows 2000, the software was obsolete and unsupported already, and basically, all of their computers don’t have enough processing power in them to handle Windows 7.

In short, they replaced their Operating Systems with Ubuntu, and run their windows software (Rosetta Stone, an online language program for their students in learning new languages, and Firefox) in WINE.

All in all it’s a really pragmatic and practical way to avoid lock-ins and costs. If you want to see the details on how he did it, read about it more in his blog.

We all have our favorite plug-ins for our browsers. Many people can’t live without their flash plug-in for their games and watching Hulu and YouTube videos. Other people use Java applets for their enterprise applications. Still, others use Quicktime for watching .mov videos on the browser.

What happens if a rogue plug-in runs in your browser? This is when sandboxing plug-ins become apparent.

Sandboxing applications have had it’s purpose and use in Java applications, especially plug-ins, where the program is placed in a restrictive environment that is not allowed to access system functions unless it is given access to.

This allows the plug-in to run in it’s own environment without harming the other browser or system processes.

How is sandboxing applied? Either through the plug-in itself (like java, and in a lesser way, flash), or through the browser.

Newer browsers such as Google Chrome separate their browser windows through threads, allowing rogue plug-ins to crash the affected window only. Other browsers implement some sort of sandboxing of their plug-ins. Which is better?

Since most people are in the fad of flash-bashing these days, let us make a sample of a rogue flash application that crashes the browser. Here is the link.

Mind you, I would say that flash has its uses; however as someone who dabbled in ActionScript one time or the other knows that the Flash runtime has a number of quirks and bugs that are really downright bad. In my opinion, this example is one of them.

Browsers who do not sandbox their plug-ins or separate their windows as separate threads would find this page crashes their browser really bad.

This includes Firefox, IE and Safari.

The only way to avoid spectacular crashes is to use a browser which implements some sort of separation between the plug-in and the browser itself.

Opera and Google Chrome passes this test admirably.

Interestingly, due to the flash plug-in running in a separate process in 64 bit systems in Linux (through nspluginwrapper), only the nspluginwrapper crashes, and does not take the whole browser in it.

To end, this is what I like to see implemented in all browsers. Running plug-ins in a separate process, as well as limiting it’s scope in relation to access to the underlying operating system.

Apparently, Linus Torvalds, the creator of Linux, apparently caved in and bought a Nexus One last week, as he stated in his blog.

He initially bought a G1 (aside from other phones in the past), a Motorola phone running Linux, but admitted not using it because as he states “I generally hate phones – they are irritating and disturb you as you work or read or whatever – and a cellphone to me is just an opportunity to be irritated wherever you are. Which is not a good thing.”

After he heard that the Nexus One had pinch-and-zoom, he decided to take the leap and bought one and found it to be a gadget device (actually found it useful), with a secondary purpose of being a phone. In short, he loved it.

Some commenters asked him about the current status of the android kernel fiasco not being merged into the mainline kernel, in which he replied that the merge would most likely be a few years away. He cited the case of the SGI extreme scalability code as an example.

Here’s to seeing more linux developments on the mobile space!

The OS which powers my E51 and E61i phone is now open sourced.

From the Symbian.org wiki site, the whole system platform is ready for download and development.

Amounting to about 25 million lines of code (38 million lines if you include the tools used to create the platform), Symbian now becomes one of the largest projects ever to be moved from proprietary to open source.

The not so good news is that you cannot reprogram your existing phone with Symbian 3 (this is symbian with all the proprietary 3rd party IP removed). However, you can take pieces of the individual applications, modify and extend them and install them back in the phone.

Greater news is that it is possible to build a Symbian phone now. The Symbian foundation provides template base ports for certain types of hardware. This includes an emulator run in QEMU.

All in all, this is great news for an OS installed in a majority of phones worldwide.

We’ve all seen the html 5 upcoming features and admittedly, it is very exciting.

Features such as canvas, and even a way for communication between servers (like a chat client), and geolocation are just one of the few highlights that html 5 offers.

One of the most anticipated features is the <video> tag which allows for embedding video without the use of an external browser plugin (ie flash).

Many pundits would say that it is the beginning of the end for Adobe Flash.  And I would agree, to an extent.  I believe that Flash’s days as a premium source of progressively streaming video content are numbered somewhat.

Things to keep in mind though:

1. HTML 5 does not include options for LIVE video streaming.  We can say that there is H264 streaming by the open source darwin server (created by apple).  But let’s be real.  Quicktime is a resource hog, and it’s frankly, its awful in windows.  And flash is practically present in over 90% of the computers worldwide – computers are then mostly live streaming content ready.

2. Games and RIA – Canvas and javascript have some neat tricks in HTML 5 (freeciv.net comes to mind).  One thing that flash trumps HTML 5 is how flash makes it easy for developers to create games (and elaborate ones at that!), with sound and effects to boot.  Flash simply trumps HTML 5 in Rich Internet Application features.

3. HTML 5 final draft is on 2022.  What would happen here is that as browsers race to implement HTML 5 features this early, they will have their own implementation.  We have already seen this in the implementation of the <video> tag.  Safari, Chrome support H264.  Firefox and Opera support Theora – IE has no support for the <video> tag.  From experience, I have to contend with different implementations of javascript, dhtml, and even css for different browsers.  What I am hoping is that HTML 5 will not descend into a web developer’s nightmare of supporting different browsers.  For flash, backwards compatibility is largely maintained: AS2 will still run on the newest Flash runtime, and developers will just develop flash applications without worrying that their applications won’t run on linux, windows or macs.

4. One thing about the video tag is that the actual video file is linkable, and thus, downloadable.  Content providers don’t like their videos readily downloadable by users, especially for premium video content.  Although not perfect, Flash offers a way hamper downloads of video content by users.  We live in the real world, and the fact is, however we want our videos to be openly available, content providers would think otherwise.

5. Concerning the video tag, is Firefox’s and Opera’s refusal to support H264.  Fact of the matter is, H264 is patent encumbered, and in order for Firefox and Opera to use H264, they would have to shelve off H264 licensing fees.  As a blog of a Mozilla developer states: “In other words, if you’re an end user in a country where software patents (or method patents) are enforceable, and you’re using software that encodes or decodes H.264 and the vendor is not on the list of licensees, the MPEG LA reserves the right to sue you, the end user, as well as the software vendor or distributor.” – Flash on the other hand, has licensed H264 for use in their player.

6. Flash has some excellent authoring tools available, which makes development easy.  One thing which bugs me in the Open Source world is that IDEs are found mostly wanting.  I wouldn’t mind an open source IDE as good as Visual Studio – Eclipse comes close, but I hate the bloatedness of the application, causing me to have out of memory errors for large amounts of source code (and that was during my Java coding days).

In short, will HTML 5 obsolete Flash completely?  My answer: in some ways, yes, in other ways, not.  What I believe is that both technologies will coexist together for quite some time, until of course, a new version of the HTML spec comes, which may drive Flash into obsolescence once and for all.

An interesting development happened during the release of the 2.6.33 linux kernel and generated some heated discussions on the lwn comments section. The android code in the linux kernel tree was deleted.

Why was it deleted? Greg Kroah-Hartman in his blog stated in a nutshell that:

In short, no one cared about the code, so it was removed. As I’ve stated before, code in the staging tree needs to be worked on to be merged to the main kernel tree, or it will be deleted.

There was a more serious problem though, as stated by Greg:

Now branches in the Linux kernel source tree are fine and they happen with every distro release. But this is much worse. Because Google doesn’t have their code merged into the mainline, these companies creating drivers and platform code are locked out from ever contributing it back to the kernel community. The kernel community has for years been telling these companies to get their code merged, so that they can take advantage of the security fixes, and handle the rapid API churn automatically. And these companies have listened, as is shown by the larger number of companies contributing to the kernel every release.

But now they are stuck. Companies with Android-specific platform and drivers can not contribute upstream, which causes these companies a much larger maintenance and development cycle.

On the lwn comments section, Greg further stated that a number of hardware companies approached the kernel development community for help due to this problem.

Apparently part of the problem is the problem is that Google created a new kernel core infrastructure which in order for it to be placed into the mainline kernel, numerous changes in kernel and userspace have to be done. Google has essentially created a fork of the kernel.

Cris DiBona stated:

To sum up: I think that Android is an unusual use of Linux that doesn’t match up with what is normally done, and I think that a fork isn’t unwarranted in these cases. I should point out we didn’t use glibc , either, or a ’standard’ VM. We built android.

The aforementioned fork was mostly in the implemention of wakelocks, a process of bringing a system out of various low power states.

Google found the current implementation inefficient, and due to time constraints and pressure to produce a product, made their own API implementation.

The downside of this is that in order for linux drivers new and current ones to work on Android, one has to hook up to the new wakelock mechanism. This causes lots of distress in maintaining current userspace and kernelspace development.

It was generally agreed that the problems of power management was an issue that needed to be solved. However, a number disagreed on the way that Google handled the solution, including the kernel developers.

The reason mainline hasn’t accepted the wakelock infrastructure is that Google has still failed to demonstrate why it’s necessary. Almost identical benefits can be obtained using the kernel’s existing range timer functonality, which has the added bonus of removing the need for the strong userspace/kernel tying that Android requires right now.

Interestingly enough, Nokia handled the problem more maturely than Google. Whereareas, Google basically sent a large number of patches and left it hanging, one user noted:

I can’t remember significant interaction between Google Android developers and mainline kernel developers before early 2009. Contrast that to Nokia who have been *all over* the kernel upstreaming their OMAP patches for the N8xx and N900.

It was further noted that:

But they both have to solve the same problems (power management) and the fact that Nokia seems to get good battery life out of their devices appears at first glance to be a counterpoint to the necessity of wakelocks.

The discussion went on, without resolution. Time will tell if the Android code will be resubmitted back to the kernel, and the issues that hamper it being in the mainline kernel tree will be resolved and taken care of.