René Rebe

Finally my Neo1973 (advanced box) arrived. Finally, because I did not even expect it anymore. Not because they targetted beginning of 2007 to ship the initial prototypes, but because the people running the online store and shipment have been so unresponsible and did not answered a single mail asking on a status update. We where mostly curious, because we ordered early and the shop did not yet had the “no functional software” disclaimer and no color choice option. So we had to answer auto generated mails confirming “YES_I_DO” “know that there is no functional software” and which color to ship: “ORANGE”. But then there was a big silence - and apparently we thought the order would have been gone lost or whatever. But - well - now it is there.

Of course I knew the software is not ready, I even replied “YES_I_DO”. Actually I did not even care, because I’m going to use it for my own development. However, that it would be that incomplete, I did not dare to imagine: Depending on which image set you flash (2007.1 or 2007.2) you either get a little UI phoning capability, but unreadable buttons and fonts (2007.1) or no phoning, but better buttons and readable fonts (2007.2). No phoning due to a non starting gsmd. And on some actions, such as activating GSM with no SIM present and other variations the whole X server dies away. Ooops.

Even for images where a the gsmd is started, they usually (at least not for me for all the pre-built images I gave a try) did not even setup the ALSA mixer to route the GSM audio stream somewhere. And as there is not even an UI part to alter the audio level, yes. This mean you either have to use the built-in terminal or ssh into the phone to load ALSA settings in order to be able to communicate with the person you are talking with. Now both problems should be one-lines to fix, and I wonder why even after man years of development and nearly 1000 shipped phones this did not even happen?

13:18 < hhf423> so, here we go. the new SIM I have here gets accepted by the Neo
13:19 < hhf423> the not so funny part is that I do not get asked for a PIN. libgsmd-tool dialling works, though
13:20 < hhf423> oooh, i get asked for pin, the joy!
13:23 < woglinde> hhf423 hehe
13:23 < woglinde> dial 112
13:26 < hhf423> how do I crank up the vulume, I can hear nothing
13:27 < hhf423> something with slsa, no?
13:27 < hhf423> alsa
13:27 < woglinde> hhf423 alsamixer
13:27 < woglinde> m for mute/unmute
13:27 < woglinde> up down/left right
13:27 < hhf423> woglinde: where is that?
13:27 < woglinde> open console
13:28 < woglinde> type alsamixer

Additionally the closed GSM firmware of the Texas Instruments Calypso based chip has compatibility problems with most SIM cards from the year 2007. While my USIMv1 I use primary in my primary (functional) phone (Sony M600i) my second SIM I just got for testing the Neo phone is a USIMv2 which does work with the GSM modem at all. From the #openmoko IRC channel and their bug #666 it becomes obvious this is one of the biggest showstoppers for new users of the Neo1973 phone right now. Let’s hope FIC and TI can provide a firmware update in the future.

But if that is not all, the Neo has a rather short battery life right now, probably the reason why (at least my advanced) came with 2 battery packs. As the phone did not overlived the first night I explicitly turned it off the second, but still the battery was fully drained in the morning. Yes, while it was “software off”. Maybe the GSM modem was left on in the firmware was proposed as an answer on the #openmoko channel - probably, as I can not imagine the Philips power-management chip would draw that much energy.

Last but not least the GPS chip can not yet used due to no open protocol spec and no clearance to ship the binary blog from the manufacture, …

Well - that said it becomes clear why the OpenMoko company let you select:

Please note that the OpenMoko products are not meant for the end user and explicitly marked as Developer preview at this time. Read this wiki article to find more technical details of what you can and cannot expect of these devices. I have been warned!

Well any other company would probably be bashed badly with such a product, but - well - the OpenMoko is a shiny Open project. Well, almost. The driving force behind the phone is FIC, First International Computer, and it’s newly founded sub-company OpenMoko, Inc. Most development happens behind closed doors and closed IRC channels: #openmoko-devel and #openmoko-core can only be joined with a channel key. The hardware schematics are non-free and most of the time changes appear to be only communicated in the classic, one big PR event at a time fashion with counting news probabilites counting up in the channel:

Probability for major news utill next wednesday 70%.

Now while pointing out this mayor flaws in the #openmoko channel, you get badly bashed about beeing a troll, to go away, to be /ignored, … Now they care about their customers.

At last I like to point out that the OpenMoko folks are also not basing on existing open source code for their applications. With the focus on Gtk+, GPE would have been a natural choice. But the project decided to implement an own application stack from scratch, with custom Gtk+ widgets and applications - maybe to have some IP lock-in for their OpenMoko Inc. company?

For OpenMoko it can only be hoped they get their software stack into an better shape, because otherwise the “just average” phone hardware is of little use and not really an helpful promotion for Linux on embedded end user devics.

Update 2007-11-24:

Still not much progress update, The Rasterman is now paid by FIC/OpenMoko, while Harald Welte quit as technical project lead.

Some random daily IRC scroll-by:

17:35 < Writchie> Crofton: actually the “design process”, if it even exists, is completely closed.
17:35 * mwester still is stuck with a hammerhead.
17:36 < mwester> Writchie: the “if” is a big question when it comes to certain parts of the software ;)
17:36 < Writchie> and hardware
17:36 < buz_> mwester: even with the hardware i have my doubts
17:37 < Writchie> 9 spins of the board - gimme a break
17:38 < edistar> Writchie: 9? quite a lot..
17:38 < buz_> other companies churn out 2 phones a month
17:38 < edistar> buz_: lol.. but I hope the next generation will be faster..
17:39 < Writchie> not unless they get some engineering process
17:39 < edistar> Writchie: What does that mean?
17:39 < buz_> hiring some good industrial designers wouldnt hurt, either
17:40 < Writchie> chinese engineering teams do what you tell them - if you don’t tell them you can get anything
17:40 < CM> I think someone said GTA01 was designed by some guys in taiwan, but gta02 was done “in house”
17:40 < CVirus> in house ?
17:40 < CM> By OpenMoko
17:41 < oramirez> Hi, I am trying to install openmoko h3900 image, but it freezes at the booting. I have been searching for some work-around .. but I haven’t found anything.. any idea?
…
16:25 < borg_> abraxa_: i could deamonize neod and add dbus bindings and outsource the aux/power menu and the lock display, but i wont do it when neod will go anyway :)
16:26 < borg_> so it is like with every other application in openmoko, no information about the future of them at all.

For some time I keep an eye on normal PC laptops as the Mac world degenerates more and more to real junk quality. Most annoying right now is the high-frequency noise of the MacBook that is killing my nerves while I try to think about the innovative code and algorithms in our company and the ongoing battery issues that even sometimes keep the MacBook from powering on at all and all the other tiny details that are imperfect.

Now the Sony TZ series comes quite near to a good ultra-portable. Of course the CPU of the 1.1kg device only runs at 1 or 1.2 GHz (depending on how much money you have to spare), but that’s pretty fine for my normal business, programming tasks with the resouce efficent Linux kernel anyway (Vista anyone ?). But the Sony TZ series has some extremly annoying design bugs that really keep me from grabbing one:

• no digital video output, no DVI nor HDMI nor Display Port - only good old VGA
• glossy finish exactly where you touch it all the time: the keyboard area
• as usual for Sony, the network port is mounted upside down. You have to lift the device to un-plug the network cable while on most other devices on the world you can comfortable press the RJ-45 nipple from the top.
• superflous, sparkling media keys on the front side
• and if you ever use Windows (thanks God I don’t) you get ugly black/white, “back to the 80s” on-screen notifications on brightness and volume change (as it was for previous Sony devices aas well)

The rest of the sub-notebook is really pretty neat, obviously because Sony was influenced by the MacBook design and nearly copied the keyboard 1:1 … :-)

However last but not least comes the price tag, and starting at 1.999 € (in Germany) for the entry model, over 2.699 € - for the model which has a black display cover, comes with 2 GB instead of 1 GB memory, 100 GB instead of 80 GB hard-disk and a finger print reader - up to 2.899 € for the top model - which comes with a 1.2 GHz (instead of 1 GHz) Core 2 Duo ULV CPU. Last but not least for 2.999 € you can get a 32 GB SSD (solid state disk) extra, special, ueber edition, … These prices are just insane. Other people get a whole car for that money!

And even despite the insane price I even still considered purchasing one (the least expensive one that is), but well - no digital video output to connect a high-definition display on my desk really kills the whole baby.

As gone thru the media, Debian is retireing the sparc32 port. However, despite the lack of an upstream Linux kernel sparc32 maintainer, our T2 SDE will just continue to support sparc32 - so if you need an up-to-date and optimized distribution for your older SPARC boxes, or new ESA satelites just give T2 a try.

For the past 5 years I just used ReiserFS (3) for all file-systems, as it was the first and then fastest journaling filesystem that made it into the Linux kernel. However since then Ext3 made progress and with XFS and JFS new player hit the Linux kernel “game”, I recently gave the alternatives a little test-run and just wanted to drop my tiny, unnumbered notes on the topic.

First of all I should mention that I have quite an exessive workload - even on my laptop’s /home partitions. This is due to my full-system development with multiple complete root filesystems and deep ccache directories beeing created as part of my development with and on the T2 SDE.

Testing XFS (somewhere around 2.6.19) oopsed the kernel a couple of times already in the first hours, so I went on testing JFS. While JFS never oopsed in my testing it shared the same slightly slower initially performing on operations like “svn st” on the multiple-thousand files T2 working copy with XFS. JFS does not come with in-kernel log replay after crashes or power outage - the user-space fsck.jfs is needed to perform this job. This decreased in-kernel code complexity, however your distribution must support fsck’ing JFS, especially the root (/) partition if you want to use JFS on it. As the Ext2/3 family was way too slow on the multi million files partition, I kept using JFS for half a year. However, it degenerated significantly in performance over time to a point where it was no fun to work anymore. Right now I even cleanup temporary files as well as the resulting root filesystems sandboxes created over the past 6 months in oder to backup the whole partition and re-format with reiserfs (v3), but unfortunatle just wiping the ccache directories already took over an hour so far:


removing build/ccache-arm-1 ...
removing build/ccache-avr32-1 ...
removing build/ccache-x86-64 ...


and is still going on :-( with an average disk-load of just 300kB/s and and CPU load (of the Core 2 DUo @ 2GHz) of just 1%/0% … :-(

At least the disk-io while removing increased to 700kB/s, now - so I have the hope that removing the various complete systems (== the next million files to delete), becomes a little more performant.

I also tested reiser4 which in contrast to to XFS did not oops and showed quite a performace increase over reiser (v3), however with reiser4 not beeing in the mainline kernel and the still ongoing cleanup and rewriting and uncertain future, I rather do not put my data at that risk. It’s on-the-fly compression however would probably be a nice benefit for the laptop HD and the many plain/text files resulting while compiling whole systems.

I wanted to review the historically cumbersome endianess conversion for our ExactImage for some time now. Thanks that the good old C macros (and the various variants of it) annoyed me enough to finally do so. What we now have in our “exact-base” repository is a C++ template setup that can be used to either define variables that have a specifc endianess in memory - probably because the composed structures are read and written as part of a externally defined format (such as BMP :-) - or to explicitly convert as in former times, just with the syntactic sugar of C++.

Using the template in packed structures is as easy as:


/* Size in bytes of the bitmap file */
Exact::EndianessConverter < uint32_t, LittleEndianTraits > iSize;


This defines iSize as ‘unsigned 32 bit’ with little-endian representation in-memory.

The next handy thing this Plain Old Data template avoids, is accidently messing with the data. As the type is incompatible with the usual ‘uint32_t’ it can not mangled. hWile the assignment operator is overloaded to store the data in the indended order, the cast to type passed to the template yield the swapped value, so straight-forward code just works:


#include < iostream >
#include “utility/Endianess.hh”

int main() {
Exact::EndianessConverter < int16_t, Exact::BigEndianTraits > test;
test = 0×1234;
std::cerr << "sizeof: " << sizeof (test) << std::endl
<< "value: " << std::hex << (int32_t)test << std::endl
<< "in-memory: " << test.value << std::endl;
}

Prints out:

sizeof: 2
value: 1234
in-memory: 3412

Checking the actual native endianess is as easy as:

if (Exact::NativeEndianTraits::IsBigendian)

And explicit conversion done like this:


Exact::ByteSwap < BigEndianTraits, NativeEndianTraits, uint16_t > ::Swap (some_data)

The whole source is available under the terms of the GPL!

With the ongoing T2 System Development Environment efford, I wonder if we do not only build up an awesome tool to create customized systems and appliances, but also a more and more complete, generic Free and Open Source reference map.

The nearly 3000 (still increasing quickly) packages of T2 generically describe where the software comes from and includes meta-data like: verbose overview, author, license, supported architectures, kernels among others and the packages are not cluttered with branding or other unnecessary patching. The packages are left vanilla as the up-stream author intended it to be and only patched where needed to get the source code actually build.

The term “generic Free and Open Source reference map” mostly came into my mind when I noticed that we more often get packages that are not even listed on Freshmeat.net nor part of other major Linux distrubitions. And the T2 packages are just soo clean and lean, just take a look into one yourself, the just added ipmiutil for example :-)

To get a complete list just take a look at the T2 package matrix listing.

I think putting some efford to setup a search and browse engine around this meta data might really worth the effort, promoting it as uncluttered “Free software map”.

A last note: Don’t let other’s distributions high package numbers confuse you, in T2 the 3000 package number refer to one package for a single piece of software, and not like 4 or more in other Linux flavours, such as -devel, -doc, … So one would have to strip this split packages from the published numbers of other distributions such as Ubuntu, Fedora, SuSE or Debian when comparing raw-numbers.

Microsoft Says Free Software Violates 235 Patents, probably as famous ones as the “FAT” - file-system - patent.

The free software world remains unimpressed, and elsewhere the NY Stock Exchange Moves To Linux, while Linus Torvalds estimates:

It’s certainly a lot more likely that Microsoft violates patents than Linux does.

Intel released a new, tiny tool named “powertop” that can help to find possibilites to save more power on Linux systems. On the homepage they recommend:

Use a recent distribution
Linux is a fast moving project, with very fast evolving components. If you’re using an older distribution, older than 4 to 6 months (and anything with “Enterprise” in the name is by definition old), please consider going to a newer distribution. Reporting issues on older distributions is going to be frustrating to a lot of people, since the issue is likely to have been fixed more than 6 months ago… Please be considerate of the developers of projects and use a recent codebase and avoid bugging them about issues they solved long ago.

As I could not agree more, here we go: T2 SDE

… with powertop already included.

Not only that the Novell Microsoft patent exchange and cooperation deal was bizzare enough, now Dell event joined this wanna-be Linux alliance after their customers most often asked for Linux in the Dell Idea Storm.
AND IT IS NOT EVEN April the 1st! :-(

After answering where to get and how to build the k-drive, TinyX a few tines on the xorg mailing list I figured it is about the tine to let Google now about it more verbosely:

Keith Packard’s k-drive based, TinyX was merged into the mainline xorg-server package, so it is as easy as downloading the latest, greatest X.org release and configure the xorg-server package with something like:

--enable-kdrive --disable-dri --disable-xorg --disable-xorgcfg

along with the other options like –prefix et al. as appropriate.

If you want all this in an automated way, with cross compile support you can also take a look into the T2 SDE Project which among others supports exactly this: Cross compiling X.org, including the tinier k-drive variant, even with alternative C libraries such as uClibC and dietllibC. To check it out and give it a try the T2 Rescue target provides tiny ISO images, pre-built for at least x86 and x86-64 (other like powerpc and sparc are easily buildable from the T2 source as well).