Mar

2

Boost your project with FUD

16 years ago, at the start of March | 1 Comment

I recently read quite a bit of FUD and really felt that it was worth comment even if only as a counter to the points made when someone Google’s the Neo 1973 / Openmoko. I’ll take on each of the points made and correct what is needed. Oh, and just for the record, this text represents my opinions – no-one else’s.

“First of all OpenEmbedded based systems are harder to build, due to the dependency of monotone and the properitary, OE-only, bitbake, and then even another MokoMakefile build wrapper.”

First of all any system that you know nothing about it hard to use. The use of monotone is not an issue, I use a version just for building my OE stuff. Calling bitbake propriatory is like suggesting that every kernel module is propriatory. Bitbake is used to ‘bake’ (make) the recipes (.bb files) and is “derived from Portage, which is the package management system used by the Gentoo Linux distribution.” The source is freely available at berlios – why is there an issue here? It also appears that this author doesn’t understand the role that the MokoMakefile plays. The MokoMakefile was developed by Rod Whitby to help people who are new to OE and OM build and setup it is not part of Openmoko or OpenEmbedded. Really, if they had even bothered to read the wiki entry for it they would have seen this. I guess it’s easier to spout bile than be accurate.

OpenMoko also is glibc and sysvinit based…”

Ok, I’ll let this slide since it’s true and just the author’s opinion on what is or is not suitable. I’ll come to the speed issue later.

“Forthermore OpenMoko comes with custom Gtk+ widgets and custom Moko libraries and applications, where Gtk+ PDA / phone applications are already available”

For a start “So what?”. Are you suggesting that no one develops anything that already exists? Should we have one email application, one word processor? What about one operating system? Clearly that gripe at Openmoko is just irrelavant. Furthermore you can actually build gpe applications for the Openmoko platform if you want. Take a quick look at what’s installed and you’ll even see that gpe-scap – what we use for screenshots is installed by default.

“yet another Gtk+ PDA / phone application stack equals reinventing the wheel.”

Actually, this is how progress is made. Take a look at the recent work on the moko underground stuff for an example. What’s more in the very next paragraph…

“We therefore started to create a saner, smaller, fully functional T2 based target”

So you decided to reinvent the wheel? Now to your bullet points

“T2 based, no bitbake…”

So you swapped one ‘propriatory’ build system for another?

“uClibC based, frees your phone’s…”

This, we agree on, but it does make building applications outside the tree a lot easier to not use uclibc.

“not sysvinit, bootup in less than 2 minutes…”

My Neo boots in less that 2 minutes all the time.

“GPE based GUI, to re-use existing applications…”

Did you actually write anything yourself then?

“focus on UI functionality early, no endless tinkering and rewriting, “

Wow, someone who writes perfect code and a perfect interface straight off! Oh, wait.. you’re actually using other people’s code so you’re not really doing anything yourself.

“includes just one embeded scripting language…”

Openmoko doesn’t include a scripting language by default, unless you count the shell, but you can install any number of them – including lua.

“just one… …webkit.”

Openmoko uses webkit.

Nothing you have said would inspire me to even take a look at your ‘T2 based’ project, least of all your attitude. Your main gripe seems to be that FIC didn’t use your T2 build system – that and a belief that everything not written by you is crap, as evidenced by your faq.



»crosslinked«

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

Tagged with:
March 2, 2008 15:18


Comments

Name (required)

Email (required)

Website

Speak your mind

1 Comment so far

  1. red on March 4, 2008 16:33

    I could be showing my naivety but I never saw enough of a difference in performance between ulibc and glibc to justify the additional effort required.

    After all, it’s not like you get an individual copy of the library in memory for every linked program that runs, right?

    We’re not working in 8Meg of memory anymore.

Current Electricity Use (15min)


iPhone/Webkit RSS Reader

Links


Tags

1-Wire android api Apple arduino currentcost DDAR development DVD FIC freerunner G1 google Google Phone gphone gprs GPS hardware image image builds inspiration iphone jailbreak kiosk linux Mac monitoring Music neo 1973 Nokia openmoko opensource OSX Pachube personal qtopia rhubarb rikki Rio slimp3 slimserver software tracking Trolltech u-boot


Twitpic


Graphy Stuff






Nasty Spam Monkeys