Stonehenge is probably one of those places that don't need much introduction. There has been a lot of speculation as to the meaning and original use of the site. Personally, I find it unlikely that we will ever discover ultimate answers to those questions. And perhaps that's exactly what makes up the magic of the place and draws so many people from all over the world to this small spot in the beautiful Wiltshire countryside.
I visited Stonehenge on June 9th. A selection of the photos I took can be found in this photoset. At some point I'll have to return at the time of sunrise or sunset. The magic of the stones only truly unfolds with the right lighting.
Salisbury, on the other hand, is probably less well known. And if it hadn't been for a nice lady on the train from Cardiff to Salisbury who recommended seeing Salisbury Cathedral I might actually have missed this outstanding gem of English Gothic architecture.
The cynic in me says "Wherever I go the scaffolding is already there", but once again I'll just take that as a reason to pay another visit to Salisbury. The atmosphere inside Salisbury Cathedral was remarkable. It was overall darker than Bath Abbey, but that allowed the various light spots and candles to work their magic.
A lot has happened since my last entry. I visited Salisbury and Stonehenge, my Erasmus stay in Cardiff officially ended, I went back home via London on a flight that felt like magic due to the sun setting while we were above the clouds, and last but not least I'm in the early stages with another robotics project at my home university in Bremen.
Unfortunately getting the latter started didn't leave much time for anything else, but things are looking promising now, so I'm taking a bit of a break tagging and uploading photos and should have some slightly more detailed blog entries ready soon.
Tempus fugit. Or so they say. My Erasmus stay here in Cardiff is about to end and, between preparing for my departure and planning all the stuff I'll need to do once I'm back home, I'm traveling around a bit to see places I haven't been to yet.
Yesterday, I spent the afternoon in Roath Park, a Victorian style park in the north of Cardiff featuring a large artificial lake with many swans and all sorts of other birds, as well as botanical and rose gardens. I found it to be a great place to relax. Some impressions are below, have a look at the complete photo set for more.
Between this semester's second last and last exams I had almost a week of time, so I took a Saturday afternoon off and went to Barry Island again. Barry Island is just a 30 minutes train ride from Cardiff, so this is a great way of escaping the city.
One of the main Barry Island attractions is Barry Island Pleasure Park with all sorts of fun rides.
The reason why I went there, however, was the beach and the sea. It was a rather grey and windy day, but I enjoyed it nonetheless. Note the sand "flying" over the beach.
While climbing alonside the cliffs I noticed a number of tiny but beautiful flowers that I wouldn't have expected in such a location.
Watching the waves crash onto the rocks had a very relaxing and refreshing effect. Refreshing in more than one way... I got slightly wet right after the following shot.
I then went on to the pebbles beach of Cold Knap. I don't know whether these pebbles occur there naturally, but it gave the place an interesting atmosphere. Unfortunaly, the photos don't do the brilliant light justice...
I had originally planned to stay there and wait for the sunset, but the high tide had blocked the way I got there (along the beach). Not knowing how long it would take me to find an alternative route I decided to go back early. I still saw the sun approach the horizon over Barry Island Pleasure Park
and the actual sunset later over Barry which marked the end of a wonderful day.
I arrived back in Cardiff for the final stint of my Erasmus stay at Cardiff University last weekend. The journey was uneventful and I even had a bit of time in London for another brief visit to Buckingham Palace. If you are wondering about the barriers in some of the photos, those were for the London Marathon which took place the following day.
I also managed to make it inside Cardiff Castle this week! It only took me some 7 months ;) Personally, I liked the Norman Keep best (see the photo below), but the castle is also interesting if you're into gold covered rooms and all sorts of other luxuries.
Back in December we spent a weekend in London. On my way home from Cardiff last Saturday, I took the chance to visit central London again. In only about 2.5 hours, I managed to see Victoria Train Station, the Royal Mews, Buckingham Palace, the Victoria Memorial, the gate to Green Park, parts of St. James's Park, Parliament Square with its statues, Big Ben and Westminster Palace (Houses of Parliament) from Parliament Square and from the south bank of the River Thames, the London Eye, St. Margaret's Church, and Westminster Abbey. The weather was somewhat mixed with high winds, rain, snow, and sunshine. The best part of the trip was clearly the walk along the south bank of the River Thames in the sun.
I will definitely be back, with a tripod, a wide angle lens and more time at hand. In particular I'd like to take more night shots and go inside Westminster Abbey.
You probably know the feeling when software you use daily gets in your
way rather than assisting you. To me Emacs has been such an offender
for a long time - in that it creates backup and
semantic.cache files in every directory you edit files
in. Obviously, this makes it often impossible to find the file you
are looking for in a directory listing.
Last week I had enough and searched for a solution. I found one to
the backup files problem in Xah Lee's Advanced
Emacs Tips and got rid of
semantic.cache by following
a suggestion in the ECB FAQ to set
semanticdb-default-save-directory. In both cases the
functionality in question is not disabled, but the corresponding files
are created in a directory somewhere in
makes me a happy Emacs user again.
Another huge annoyance is the long time it takes current Linux distributions to boot. I remember how my old 350MHz Pentium II with its by today's standards dead slow harddisks booted in about 20 seconds from the Lilo prompt to the KDM/GDM login screen. Out of the box the Debian installation on my 2.4GHz Core 2 Duo workstation with its 7200RPM disks needs about twice as much time to get me to a graphical (GDM) login. After getting rid of a bunch of unnecessary init scripts I got that figure down to slightly less than 30 seconds. So, it's definitely worth the effort to review what init scripts are run and whether you really need them. I still don't find the result very satisfactory though.
Last but not least I'd like to recommend the tips over at lesswatts.org. Even if you don't
have a recent enough kernel and userspace to benefit from
CONFIG_NO_HZ etc. it's worth going through their Tips & Tricks section
and looking for potential power savings. Personally, I found the
suggestion to mount filesystems with the
option enabled very useful, not necessarily because it saves power,
but because it significantly speeds up things like
search, access to the
dpkg database, and loading
We visited Bath on March 1st. It was a really beautiful day with lots of sunshine and therefore many opportunities to take pictures. The brilliant light created a very special atmosphere inside Bath Abbey which is hard to capture, but the photo below may give you a rough idea of it. If you get a chance, Bath Abbey is a must visit and I recommend you allow plenty of time to really enjoy the experience - there is so much to discover inside.
The Roman Baths were somewhat disappointing. From an archeological point of view the presentation of the historic site had a rather unprofessional feel to it - many interesting bits were not explained at all or only via an electronic "audio guide" which I found extremely tiresome to listen to. The Hypocaust (underfloor heating system) is probably among the most noteworthy of ancient Roman engineering feats, yet I couldn't find any diagram explaining how it worked or even a mention of it in the "audio guide". It was certainly fun to see pilae stacks (part of a Hypocaust) live, but only because I knew what I was looking at - people around me gave me a rather funny look wondering why I was so excited over a couple of bricks until I explained it all.
From a photographer's point of view, the scaffolding that was basically everywhere was a bit of a show stopper (as can be seen above). Given the hefty admission fee, I believe a warning notice at the entrance would have been the least the museum should have done. On the flip side, it makes for a good reason to visit Bath again and re-do the affected shots.
Just in time before the weather changed (for the worse) we also managed to pay shorts visits to The Circus (pictured above) and the Royal Crescent (below). I particularly liked the trees in the middle of The Circus.
And finally, I love seagulls.
My little blog engine/compiler is approaching feature completeness and I think what it generates is ready for public consumption, so I've switched the front page of nelianur.org over to it now. There is no non-blog content yet, but that is going to change over the course of the next few weeks.
I've also switched the CSS to that from K2 and added a header image based on a photo I took on a trip to Barry Island a few weeks ago. I love watching waves crash onto the beach, so I guess it fits well.
Finally, I've imported old posts from Advogato and my blog on the university
webserver (which I had almost forgotten about). The latter will soon be removed
because I don't want to keep maintaining the pyblosxom installation behind it.
Importing the Advogato posts was rather painful, as they were missing all
the closing HTML tags although I'm sure I entered them.
up most issues but I still had to correct some stuff manually.
The blog engine now has a simple editor interface that opens an editor, allows the user to enter a post, and then stores it.
The engine now reads and shows date information and supports multiple posts.
I've been meaning to set up my own blog for a long time, but it never happened until now. The reason is simple: all popular blog engines are inherently insecure. Take WordPress as an example of one in which major flaws are found almost on a weekly basis.
The solution is of course obvious: create static content and store it as xhtml on regular web space. Unfortunately, there aren't many tools around that do that sort of thing and none of them satisfied my expectations.
Consequently, I've written my own static blog engine in Haskell which generated this very page you're reading right now. It's still rather basic but will be extended as I get around to implementing missing functionality.
When someone pointed me to Greg K-H's book Linux Kernel in a Nutshell my initial reaction was: Building a kernel isn't exactly rocket science. Why would I want to read a book about it?
Well, it seems I was wrong. I skimmed through the PDF version today and noticed a very useful feature of make menuconfig: Hit / and it allows you to search the CONFIG_ strings.
I've been looking into LISP recently (initially for university stuff). Historically, I think it played an outstanding role in the development of computing. Bringing functional programming to a world of assembler and low-level C hacking is clearly an achievement in its own right. I am particularly impressed learning that LISP was used to control some NASA spacecraft - today most people don't even use anything higher level than C or perhaps C++ on robotic systems, and that's on much more powerful and significantly more accessible hardware (try attaching a JTAG interface to a probe on another planet to debug a problem with your code).
From a language design point of view I'm not overly impressed by (Common) LISP though. Some of the criticism I have for it is arguably purely a question of taste: I find the lack of mixfix operators rather annoying, but of course it makes parsing by orders of magnitude easier. More of a problem is the apparent lack of strong typing - e.g. LISP will happily allow you to have elements of differents types in a list, among other more serious issues. It also appears to be possible to change semantics based on input types of a function. The fact that functions (like +) can take a variable number of arguments is a bit of a nail in the coffin from my point of view. I'll keep using Haskell for real world functional programming.
A while back Riku Voipio called for help with missing bits for Debian/armel one of which was GHC. Not knowing Martin Guy was already (privately) working on bootstrapping GHC (an ARM port existed already) I decided to have a go at it. The GHC porting documentation is clearly excellent and resulted in quick success (relatively quick given the slow build hardware). At that time Martin was already far ahead of me. Meanwhile he has made packages available. I have yet to get around to reporting some minor problems GHC upstream and I may also investigate why ghci doesn't work at some point, but basically this means Haskell is available to the EABI crowd :)
I'm a bit late with my obligatory Android post. Partly that's because I wrote this in a lab at university a while back and forgot to post it.
The announcement of Android and the release of the "early look" SDK have created quite a bit of hype. There have been numerous similar announcements by other initiatives to get Linux on mobile devices, so what's with the excitement about Android?
Of course, it's backed by Google. Whether you like it or not there isn't going to be a way around it. But that's not all there is to it. The engineers behind Android have simply done an excellent job judging from the SDK. And there's a lesson or two to be learned by the open source world:
The Linux kernel is good at what it does. Userspace is generally not worth bothering with.
I found this very striking. If you have a look at what's running in the emulator (which is based on Qemu), you'll notice that there are just a few processes and the only standard component among them is dbus.
Android uses a custom (launchd/upstart-like) init replacement. Traditional, SysV style, init systems waste a lot of time just forking shell processes. And doing stuff in shell also opens the door for monstrous shell scripts that spend ages performing simple tasks such as creating a few files and directories (that script takes 5-10 seconds to run). It still takes a while for Android to boot though, which I hope is just because my laptop is slow.
Android also doesn't bother with providing a complete Unix commandline environment, since, hey, the user isn't going to see that anyway. It's funny how it's never occured to me to stop shipping the lower layers (non-essential bits of busybox, login). But then again, I'd probably have been yelled at for that by some users...
I have yet to check whether udev or a udev replacement is involved as that tends to be a bit of a bottle neck on resource constrained devices. It would certainly be nice to either get things to work without udev or with a more efficient replacement. The other thing I have yet to figure out is whether any type of X is involved in windowing. At a glance, it doesn't look like it though.
You can build efficient security models that are still simple enough for people to actually use them.
Most PDA/phone stacks make the assumption that only one user uses the system. Personally, I prefer multi-user environments so I can lend devices to friends/family, but for the average user that assumption is reasonable.
In a multi-user environment you need technologies like SELinux to separate individual applications run on behalf of a single user. Mobile stacks have to my knowledge (apart from an extremely locked down set of Motorola phones) up to now never bothered with that. Applications either all run as (yuck!) root (Qt/Embedded, Qtopia) or as a single user (GPE, Maemo, Poky, OpenMoko) without any significant restrictions as to what individual applications are allowed to do.
Enter Android... Why not re-use the space freed by the single-user assumption and run each application as a separate user? Sufficient for most use cases and still very simple to understand. Security models only matter if they are simple because they won't be used otherwise. It remains to be seen how well the Android security model works out in practice but I like the concept.
It's not a platform unless it comes with a comprehensive API and an easy to use, well-integrated SDK.
I found it rather amusing how people referred to OpenMoko as the first open platform in reaction to the Android SDK release. At present OpenMoko is a prototype device plus a number of mockups and a few prototype applications. There's a long way to go to turn that into a platform.
First of all, developers will want a comprehensive API. From experience talking fellow developers through GLib/GObject/Gtk+/etc. development basics, it's fairly obvious to me that just throwing a bunch of libraries at people doesn't do the trick. People get lost too easily around the borders between the territory covered by the different libraries involved. Arguably, this is mainly a documentation problem, but there's more to it. Following the development of the Gnome desktop throughout the years shows that people spend a lot of time discussing at which level to implement functionality, shuffling bits around, etc.
Android takes a different approach. Using the Java programming language allows integration with Eclipse (or similar commercial IDEs) which provides developers with API documentation right in the editor. Combine that with refactoring/reenginering features of modern Java IDEs and you'll never look back to anything else.
And the level of integration goes beyond that. You don't even have to leave Eclipse to upload your application to the devices. It's all just a matter of clicking a few buttons. For an "early look" SDK that's rather polished and provides a new level of efficiency compared to what I'm used to on other Linux based systems.
The primary goal must be to attract developers. The larger the set of potential developers the better.
If you want people to use your stuff you'll have to make it easy for them to hop on the train. As simple as that may sound, most of the time it just doesn't work like that.
I believe the choice of Java as the programming language was the right one. Personal taste aside, there is hardly any way around Java. It's the de-facto standard first language in teaching around the world.
It remains to be seen whether there will be other language bindings in the future. It doesn't seem very likely to me though, since Google probably wants to avoid a mix of languages which easily leads to a giant mess.
Avoid cross compilation and complex build systems.
People tend to spend a lot of time setting up a cross toolchain, fighting applications that won't cross compile cleanly, etc. That's a major waste of time.
Of course there are various meta-level build systems, which try to hide that sort of thing from you. But that comes at the price of another level of indirection and complexity. There are very few people who actually understand how, say, OpenEmbedded works under the hood in every detail - the problem being that in certain cases you need that level of understanding to get your work done.
Android's take on this is to avoid cross compilation and build systems altogether (for application development anyway). I like the approach. It's very refreshing to find a development environment that you can instantly work with after downloading. My first simple application ran in the emulator within minutes.
People have raised the question whether Android renders various other projects obsolete. And, realistically, I think it will once fully open source under a permissive license. The impact will be dramatic. As outlined above, traditional handheld distribution paradigms along the lines of a "base system" are shown to be irrelevant and there's been a clear focus on creating a fun developer and user experience.
Do I sound overly optimistic for the success of Android? Perhaps. I haven't held a device running Android in my hands yet after all and there are licensing questions to be sorted out, too. Given the list of consortium members behind the Open Handset Alliance, however, I'm confident there's some exciting, well engineered stuff ahead.
I noticed today that the Four-Legged-League has been renamed to Standard Platform League and will be using a new humanoid robot at future competitions. There isn't a whole lot information available about the Aldebaran Nao but it definitely makes me wish I was starting with my 2 year project now (rather than being almost finished) so I could join the local team.
Why is a standard humanoid platform so exciting? If you've ever worked with robotics hardware and prototypes in particular, you'll know only too well that you rarely get to do the stuff you want to. There's always one hardware component or another that fails on you, not to speak of the usual pain of (systematically) incorrect sensor readings. A standard platform makes sure that everyone has the same starting point and (ideally) allows people to concentrate on algorithmic work rather than developing and fixing hardware.
I've recently been doing algorithm prototyping in GNU Octave. Although not fully compatible with Matlab, it usually interprets code written for Matlab correctly. Some functionality (specialized functions) is missing but usually slightly different but equally capable replacements are available.
I must say I'm impressed with how quickly you can develop mathematical algorithms in Matlab/Octave. Basically, you're all done at about the same time you'd start debugging your matrix library in any other language. It's definitely an approach people in computer science in general and robotics in particular should use more often.
Octave uses gnuplot for plotting but hides the gory gnuplot details from you which is really pleasant. On the other hand, if you're used to computer algebra systems such as Maple or GNU Maxima it feels a bit odd to plot a set of points rather than a (symbolic description) of a function. Considering the internal representation of a function in Matlab/Octave it does however make sense the way it's implemented.
Now on to the next algorithm on the list of algorithms to evaluate...
I saw Nassler & Schneider in concert on Thursday. It was just amazing. Two classical/latin guitars, some percussion elements, mild use of synthesizer and live recording/playback effects, and a unique mix of classical, spanish, latin and jazz influences.
If you ever get the chance to see these two masters of the guitar in concert, don't hesitate to go!
...is one of the things I'll be doing at university this semester (although I don't actually need the credit points). There are various other interesting courses, but I haven't made a final decision on which of them to take. Anyways. Good times :)
Of course I'm a bit late to blog about this... Etch has been released. It's working well on several of my machines. Congratulations to the Debian project for a successful release!
I've just released GPE Screenshot 0.4 which is the first public release.
GPE Screenshot allows the user to save a screenshot to the local filesystem or upload it to http://handhelds.org/scap/. Thanks go to Russ Nelson for adding PNG upload support to the cgi scripts on handhelds.org.
Screenshots are taken from the X server using some code from gnome-screenshot which is part of gnome-utils. With minor modifications to the source code it is, however, also possible to use external applications such as fbgrab or import to grab screenshot images.
Source code is available from the usual place, a .bb is in OpenEmbedded already, and binary packages will follow soon.
Being a handhelds.org guy I talked to Andrew Haley at the Oldenburg DevJam about how feasible running GCJ on ARM would be and what needs to be done to make it happen. Incidentally Tom Tromey had given an overview on the same topic on IRC a few days before. So, thanks to Tom I wasn't totally clueless ;)
Anyways, here's a short summary:
Andrew also pointed out that Java classes compiled to native code add significantly to the space requirements of the class library. Michael Koch and me had blogged about possible solutions to this issue before.
That's it for now. As usual, any corrections/suggestions are welcome. Oh, I should note that in order to work on this myself I'd have to learn a *lot*, which doesn't mean it won't happen but don't hold your breath on it...
I returned from Amrum where I've spent the past three weeks on Sunday. I didn't have internet connectivity there but I didn't miss that. Here are a couple of reasons why:
I received an invitation from Joey a while ago and accepted (and forgot to blog about it). I'll attend the meeting from Wednesday to Sunday. Although I'm not a kernel hacker I plan to meet some friends from the GPE project and other nice people there.
And if the GNU Classpath distro DevJam takes place there, it will be even more fun!
I've just released GPE Life 0.2. Changes since 0.1 are limited to a fixed .desktop file ("Conway's Game of Life" was too long, so it's just "Game of Life" now).
I've also taken a couple of screenshots:
I'm afraid I can't push ('monotone sync' actually) to the OpenEmbedded repository right now, since monotone decided to screw itself over and fail with an invariant violation on 'monotone merge'. If you want to build Classpath 0.17 with OE just rename the .bb: 'mv packages/classpath/classpath_0.16.bb packages/classpath/classpath_0.17.bb'.
While I've been on a work and university deadlines induced hiatus a lot of things have happened in the Free Software world. One of those is that the free (as in beer) BitKeeper client is now history and OpenEmbedded switched to monotone. After a bit of struggling with monotone (it's dead slow - 80mins for an initial pull on a P4 2.4GHz, much longer on older hardware) I now have a working OpenEmbedded environment again.
I've upgraded GNU Classpath, JamVM, and SableVM to current versions. Binary packages for Familiar 0.8.x are available here. The dependencies are against more recent packages than what's in Familiar 0.8.2. Try --force-depends to install them - YMMV.
For those who are wondering, I have no plans to add SableVM SDK to OpenEmbedded or ship it as a package for Familiar, since it violates a couple of common distribution rules (and the FHS?). And on embedded devices (which are low on flash space) it doesn't make sense to ship duplicate binaries anyway . Fine grained packaging and sharing binaries/libraries among applications is the rule there.
In related news, I had to remove the included external libraries from the sablevm source tree and patch out any references to them from the Makefile.am's to make autoreconf work with it (That's necessary to replace certain macros with ones that work in a cross compilation environment). I highly recommend running autoreconf to sanity check the autotools input files before releasing stuff like that.
I'd like to point out one more idea in addition to Michael's list.
4) Supporting a finer grained packaging.
What do I mean by this? For an application specific runtime environment it's rather easy to identify stuff you don't want. It's very unlikely that you'll need AWT/Swing on a headless webserver. Following Michael's strategy 1), you'll build classpath with --disable-gtk-peer, possibly remove unused classes from glibj.zip, and you're finished.
However, this doesn't work too well for distributions (like Familiar) which aim to provide a universally usable set of packages. This "one-size-fits-all" approach sounds like it has to collid with the aim of consuming as little precious flash space as possible, doesn't it?
Well, the easy way out - packaging different build configurations - isn't an option really, since that would result in conflicting packages and a general maintenance nightmare.
A more clever way is to use one build time configuration covering a wide range of use cases and to split the result into as many packages as reasonably possible. E.g., the current kernel packaging code in OpenEmbedded creates one package per kernel module. The same goes for GStreamer modules and glibc localedata just to name a few. This also helps reduce runtime dependencies for core functionality of a given software component (which isn't a new idea of course if you look at gnuplot in debian for example).
Obviously, I'd like GNU Classpath to support something similar. The native libraries (libgtkpeer.so in particular) can be packaged separately already. What's left is one big (in embedded terms rather giant) glibj.zip. Splitting that up isn't a trivial task due to partly less than obvious (java) package interdependencies etc.
Any pointers as to how this could be accomplished would be appreciated (packaging AWT/Swing separately is what users request most frequently btw).
OpenEmbedded is a cross compilation aware build system (consisting of a set of tools and package description files) aimed at building entire (currently Linux based) distributions from sources. Examples for distributions using it today are Familiar and OpenZaurus.
So what's in already?
The road ahead obviously includes cross compilation to native code using gcj. Basically it should be as simple as enabling gcj in the gcc-cross build, but I haven't got to looking into that closely yet.
The issues with SableVM I mentioned earlier appear to have been fixed in SableVM 1.11.x. The apparently ARM specific random crashes don't seem to happen either. Good job guys!
JamVM 1.3.0 is out.
It is kind of sad to hear that "the AWT/Swing in 1.1.10 and current staging are horribly broken".
In other news, JamVM 1.2.5 appears to work fine with GNU Classpath 0.14 (at least for AWT applications). This is the first JVM to run AWT apps flawlessly on my iPAQ (and will be the first free one to do so in Familiar as part of the next release).