I hear you want to cancel your membership? You know, we gave you this special deal -
Well, ok. We will be very sorry to see you go, but if you feel that this is what you need to do...
Oh, so you still would like to use the facilities?
Ok, and the meeting rooms and the address register? Hmm, I'm afraid that is really only available to members.
What do you mean, unfair? I would like to remind you that this is what members pay their membership fee for. If everybody could just -
Yes, certainly. Talking about fees - I just see that there are some outstanding payments and it also seems you have borrowed some of our gear -
Yes, we can discuss access to the facilities, I will send you the price list for non members. But could we maybe have a quick chat about how you would like to pay the outstanding -
Well, yes, there is a fixed set of prices for non-members. But, please, could we -
Sorry, I'm afraid I don't understand. You would like to cancel your membership but keep access to the premises and use the facilities and you also want a private room? How is that supposed to work?
I'm afraid I don't see how this would be possible.
Yes, certainly the other members are going to miss you, but -
Of course. But first, if you could please let me give you a list of outstanding -
If we don't offer you privileged access you are leaving and never coming back? Well, if that's -
No, I don't see how that would destroy our business.
Yes, sure. Of course. Good bye.
Tuesday 15 August 2017
Sunday 26 August 2012
Leaving
It is final - after 3 1/2 years in the UK and 4 1/2 years in The Netherlands before that we are going to move back to Germany. Although our three kids are bilingual English clearly is their first language. I am watching our youngest (2 1/2 - born in UK) flipping through a list of animal pictures on the iPad and naming them - in English - unaware that in three weeks time all the knowledge he has worked so hard to acquire will be obsolete. A very sad moment.
Saturday 14 May 2011
My new 260£ living-room-compatible NAS/HTPC
My first attempt at building a small silent HTPC (home theater pc) began and ended a couple of years ago with a mini-itx Pentium M board sitting bare and caseless on a cupboard in our living room. It worked quite well, but I never came around to building a case for it (back then mini itx cases were rare and expensive). When our daughter was born I decided that uncovered electronics and a baby were probably not going to mix well and exchanged it (the computer, that is) for a Mac Mini (the first Intel model had just come out).
I was delighted when I first discovered Front Row only to be severely disappointed only shortly thereafter by its lack of features and general bugginess. Nevertheless the Mini worked at least as well as a HTPC as the naked Pentium M had (especially after I had put Linux on it) and it was a lot prettier.
All was well until the Mini's hard drive *and* CD drive broke. Exchanging the hard drive was not a problem but it turned out installing Linux on an EFI-based computer without optical drive was. After a couple of very frustrating evenings I gave up and sold the Mini on ebay (for stupid 200£). First I thought about getting either an Efika MX or some cheap nettop as a replacement, but for various reasons that seemed unsatisfying.
I started to look into availability of components and - surprise - there is a *lot* more diversity today (at much better prices) than a couple of years ago. After some searching I decided to not only build my own HTPC but also to finally get rid of all the pesky external hard drives (containing our media collection) that litter our living room.
This is the configuration I went for:
When I had put everything together the system worked essentially as it was supposed to - except for the noise level. Case fans, CPU fan, PSU and hard disks taken together were definitely a lot more audible (at least in the evening after the kids' bed time) than I would have liked for our living room. This was however easily solved - the case fans I just disconnected (even under full load the puny Atom didn't need them), the CPU fan is under strict control by, err, fancontrol (comes with lm-sensors), making it barely audible and the data disks power down after five minutes (hdparm -S is your friend). After all this it turns out that the PSU is actually really quiet...
Add in mlnet and mediatomb and now from every device (except from my AC100, grrr) in our house the server can be accessed to browse, consume and, erm, acquire media. And the box in our living room is quiet and pretty.
I was delighted when I first discovered Front Row only to be severely disappointed only shortly thereafter by its lack of features and general bugginess. Nevertheless the Mini worked at least as well as a HTPC as the naked Pentium M had (especially after I had put Linux on it) and it was a lot prettier.
All was well until the Mini's hard drive *and* CD drive broke. Exchanging the hard drive was not a problem but it turned out installing Linux on an EFI-based computer without optical drive was. After a couple of very frustrating evenings I gave up and sold the Mini on ebay (for stupid 200£). First I thought about getting either an Efika MX or some cheap nettop as a replacement, but for various reasons that seemed unsatisfying.
I started to look into availability of components and - surprise - there is a *lot* more diversity today (at much better prices) than a couple of years ago. After some searching I decided to not only build my own HTPC but also to finally get rid of all the pesky external hard drives (containing our media collection) that litter our living room.
This is the configuration I went for:
- mainboard: Gigabyte GA-D525TUD (Atom D525, 4 SATA connections, 1 IDE)
- memory: 2GB Hypertec DDR3
- PSU: 350W Akasa AK-P350AG8-SLUK (cheap but relatively quiet)
- case: LianLI PC-Q08R (stylish, silly LED fans, 6 HHD bays)
When I had put everything together the system worked essentially as it was supposed to - except for the noise level. Case fans, CPU fan, PSU and hard disks taken together were definitely a lot more audible (at least in the evening after the kids' bed time) than I would have liked for our living room. This was however easily solved - the case fans I just disconnected (even under full load the puny Atom didn't need them), the CPU fan is under strict control by, err, fancontrol (comes with lm-sensors), making it barely audible and the data disks power down after five minutes (hdparm -S is your friend). After all this it turns out that the PSU is actually really quiet...
Add in mlnet and mediatomb and now from every device (except from my AC100, grrr) in our house the server can be accessed to browse, consume and, erm, acquire media. And the box in our living room is quiet and pretty.
Saturday 5 March 2011
Ubuntu on the Toshiba AC100 - 4 weeks later
Here are my impressions after a couple of weeks with my AC100 (with Ubuntu on it):
bad
good
the future
I am still quite happy that I replaced my EeePC with the AC100. Despite its flaws I already use it more. And the future seems to be bright:
bad
- Sound works sometimes, sometimes it doesn't. No idea why.
- Network seems to stop working after a while now and then, wifi disconnects and can't reconnect anymore.
- No flash obviously (the kids were seriously disappointed...).
- No automounting of usb sticks, sd cards, etc. (might be a problem with Ubuntu, though).
- Playing movies with vlc works ...sort of (flaky sound, slightly skippy picture).
- Closing the lid sometimes fails to trigger sleep mode.
- Still no display dimming on idle (shouldn't be too difficult using either xscreensaver or laptop-mode tools, just haven't found the time yet).
- Haven't managed to find a working skype yet (neither Ubuntu nor Android).
- The system sometimes just freezes at some point (although I also had it running for hours without any problems a couple of times).
good
- Most of the time the system works without issues.
- All programs I tried installed and worked flawlessly (even java).
- Although there are still a couple of things missing power usage is already quite low. I haven't really tried it yet, but my guess would be 4-6 hours on a full charge with wifi.
- Standby times are amazing as is wakeup from sleep.
- The device is really thin and light. Also - although that's a slightly silly thing to mention - I noticed that it is far better balanced than my EeePC 901. If I carry it around the house I tend to just dangle it from one finger which I hook into the gap between display and battery - it feels completely natural.
- I love the keyboard.
the future
I am still quite happy that I replaced my EeePC with the AC100. Despite its flaws I already use it more. And the future seems to be bright:
- A couple of days ago Toshiba *finally* managed to release the 2.2 update. At the moment it unfortunately seems to not get along well with Ubuntu but I've heard that the source is already on the way (it seems actually to get shipped on real CDs - weird). Therefore I guess it will be only a matter of time until dual-boot 2.2/Ubuntu works.
- Some people are working on a .36 kernel for the AC100 and seem to be making good progress. Hopefully the new kernel sources from Toshiba (.32 AFAIK) will be helpful for them.
- Mark Shuttleworth (Ubuntu chief) himself has been rather enthusiastic about Ubuntu on ARM in general and on the AC100 in particular. Maybe he will manage to coerce some cooperation from NVidia and Toshiba so that the last serious issues (e.g. xorg driver, power management) can be solved.
Tuesday 8 February 2011
Ubuntu on the Toshiba AC100
I recently replaced my beloved but aging EeePC 901 with a shiny new Toshiba AC100.
The nice thing is that it runs Android 2.1 which means a) I had a nice excuse to buy it (my Archos 5 has only 1.6 with no upgrade in sight... and of course I *need* a halfway current Android device for development ;-) ) and b) that most people think it sucks many of which sell theirs again on Ebay for real cheap.
The problem is that it runs Android 2.1 which really is not such a great choice as a netbook OS (and to make matters worse there is no Google market - and no hack to sideload it as far as I know). Thus, while I don't agree with most people regarding the degree to which Android sucks as a non-phone OS (I think it has its merits) I do think that the AC100 is a beautiful gadget that deserves a proper desktop linux installation. Fortunately a few adventurous souls have done most of the explorative work needed for that and put it online. Still, as usual there were a couple of problems on the way. Anyways, this is how I did it:
The main HOWTO sits on http://tosh-ac100.wetpaint.com/page/Ubuntu, however it is aimed at installing Ubuntu on an SD card and uses an older kernel. There is a newer kernel by phh available here, with accompanying instructions for installing onto the device's SSD.
installation
Everything worked fine up to the point where I wanted to boot the newly installed boot image which lead to this cryptic message:
Disassembling the boot image into kernel and ramdisk (following this guide) I found out that there were two distinct problems producing the same symptom: the older boot image did not check for /sbin/init on the right partition (mmcblk0p6 in my case) while the newer one did not have the right kernel arguments to recognize the partitions in the first place (see here). After I had just reassembled the new boot image with the proper kernel args everything worked fine.
(some) fine tuning
Most things worked out of the box after the install completed (notably sound!), however I had neither wifi nor suspend (there was also a problem with the touchpad but that disappeared mysteriously after a while...).
wifi
Following the discussion in this thread I put together a simple script which gets called from rc.local:
The instructions in the HOWTO work like a charm except that lid-switch-daemon doesn't take an option '-d' - just '-s' is fine.
backlight
The instructions in the HOWTO are a bit vague. In fact the light_05 command takes an rgb value as argument with intensities between 0 and 255. This script will take a single value (0-255) and call light_05 with the right argument:
what doesn't work (yet)
The nice thing is that it runs Android 2.1 which means a) I had a nice excuse to buy it (my Archos 5 has only 1.6 with no upgrade in sight... and of course I *need* a halfway current Android device for development ;-) ) and b) that most people think it sucks many of which sell theirs again on Ebay for real cheap.
The problem is that it runs Android 2.1 which really is not such a great choice as a netbook OS (and to make matters worse there is no Google market - and no hack to sideload it as far as I know). Thus, while I don't agree with most people regarding the degree to which Android sucks as a non-phone OS (I think it has its merits) I do think that the AC100 is a beautiful gadget that deserves a proper desktop linux installation. Fortunately a few adventurous souls have done most of the explorative work needed for that and put it online. Still, as usual there were a couple of problems on the way. Anyways, this is how I did it:
The main HOWTO sits on http://tosh-ac100.wetpaint.com/page/Ubuntu, however it is aimed at installing Ubuntu on an SD card and uses an older kernel. There is a newer kernel by phh available here, with accompanying instructions for installing onto the device's SSD.
installation
Everything worked fine up to the point where I wanted to boot the newly installed boot image which lead to this cryptic message:
Waiting for devices ... doneand a shell prompt. First I thought the problem was that I had used the newest update of the boot image, but the generic phh image had the same problem. It took a bit of fiddling and research but in the end a post in this thread lead me in the right direction.
/bin/sh: can't access tty; job control turned off
Disassembling the boot image into kernel and ramdisk (following this guide) I found out that there were two distinct problems producing the same symptom: the older boot image did not check for /sbin/init on the right partition (mmcblk0p6 in my case) while the newer one did not have the right kernel arguments to recognize the partitions in the first place (see here). After I had just reassembled the new boot image with the proper kernel args everything worked fine.
(some) fine tuning
Most things worked out of the box after the install completed (notably sound!), however I had neither wifi nor suspend (there was also a problem with the touchpad but that disappeared mysteriously after a while...).
wifi
Following the discussion in this thread I put together a simple script which gets called from rc.local:
#!/bin/bashsuspend
/etc/init.d/network-manager stop
/etc/init.d/networking stop
echo 1 > /proc/test_program/wifi3g
/etc/init.d/networking restart
/etc/init.d/network-manager restart
The instructions in the HOWTO work like a charm except that lid-switch-daemon doesn't take an option '-d' - just '-s' is fine.
backlight
The instructions in the HOWTO are a bit vague. In fact the light_05 command takes an rgb value as argument with intensities between 0 and 255. This script will take a single value (0-255) and call light_05 with the right argument:
#!/bin/bash
light_05 $(( $1 + $1 * 256 + $1 * 256 * 256 ))
what doesn't work (yet)
shut down - doesn't seem to do anything(see below)- CPU scaling - as far as I know
- dim screen on idle - should be doable
- I found two new places with documentation - the kernel tree on gitorious actually has a wiki; and there's a new wiki being set up on linad. Now they all just need to merge their info...
- Shut down works (see comments section)
- I added a hook for pm-utils to dim the backlight on battery. Just put this:
#!/bin/bash
in /etc/pm/power.d/00backlight (assumes /usr/sbin/dim_ac100 is the backlight script mentioned above)
if [ $1 = "true" ] ; then
/usr/sbin/dim_ac100 100else
/usr/sbin/dim_ac100 255fi
Tuesday 9 November 2010
An acquired taste
These days retro-minimalism in desktop computing has become quite fashionable. People play old console classics, use minimalistic tiling window managers and many people go back to using text editors that their parents already grew up with.
I have always found this trend a bit weird, especially with respect to text editors. Why on earth should I throw 20 years of CUA, a mousable gui and the convenience of not having to constantly switch between different modes overboard and start to use vi?
I myself learned to program with QuickBasic. Although Windows (I think some version 2.0 or 3.0) *was* running on my computer I did not use it since it was notoriously unstable and stole away precious RAM from my individual-based simulations (yes, this is what I did when I was 16...). Also the DOS IDE QuickBasic came with was actually quite nice. The built-in editor implemented a standard CUA interface, therefore that is what I became used to.
I was accordingly shocked when I started university and had to learn vi. Horrible non-intuitive key bindings, a modal interface, no menus - I was disgusted. Out of necessity I learned enough vi to get along (we weren't even allowed to use X terminals for the first two years), but I never liked it. At home I continued to use QuickBasic and QuickC, or, when I started to switch to DJGPP (it allowed programming for protected mode which meant I could use the whole *8MB* of RAM without jumping through hoops) I just went with the simple DOS edit command and later with rhide.
Later, after switching to Linux I luckily stumbled upon NEdit. NEdit actually made me happy - it was fast, featureful and extremely configurable and scriptable. Unfortunately - being based on Motif - NEdit was also firmly rooted in the ancient past of Unix UI technology. Since there also was no sign of ongoing development I finally with great regret abandoned it (together with WindowMaker and my iBook) a couple of years ago.
Since then I have tried all CUA editors and IDEs I could get a hold on but none of them really satisfied me. Having replaced my iBook with a MacBook I decided to try OS X for a while, which didn't make the text editor situation any easier. I didn't manage to warm up to XCode and Smultron although nice felt a bit too locked in (just in case I wanted to ditch OS X again) therefore I stuck for a while with jEdit. After my annoyance with OS X and my MacBook had grown strong enough to go back to Linux (on a nice Lenovo R61) I decided to give kate and kwrite a try, which I have used since then.
A couple of weeks ago after having encountered another weird annoying bug in kwrite and an extensive round of checking on all linux text editors I know of I finally had enough. I decided to give vi a second chance.
And to my own utter surprise this time around I actually liked it. Vim really excels at configurability, speed, syntax highlighting and multi-window editing (due to its bugginess a constant pain in kate). On the other hand I didn't find it difficult at all to memorize the odd key combinations (though having a cheat sheet pasted to the wall doesn't hurt) and somehow they just didn't feel nearly as unintuitive as during previous encounters. Even the constant switching between insert and command mode which has always been my biggest issue with vi hasn't started to annoy me yet.
I could imagine that it's an age thing. It took me nearly 30 years to start to like olives, capers and anchovy and now I love them (visiting Sicily helped...).
Maybe vi really is an acquired taste and I just needed to pass the 35 to finally learn to appreciate it.
P.S.: While ditching kate/kwrite I also changed (back) to E17 and modified all color schemes to bright on dark. Could be that I'm just following fashion after all...
I have always found this trend a bit weird, especially with respect to text editors. Why on earth should I throw 20 years of CUA, a mousable gui and the convenience of not having to constantly switch between different modes overboard and start to use vi?
I myself learned to program with QuickBasic. Although Windows (I think some version 2.0 or 3.0) *was* running on my computer I did not use it since it was notoriously unstable and stole away precious RAM from my individual-based simulations (yes, this is what I did when I was 16...). Also the DOS IDE QuickBasic came with was actually quite nice. The built-in editor implemented a standard CUA interface, therefore that is what I became used to.
I was accordingly shocked when I started university and had to learn vi. Horrible non-intuitive key bindings, a modal interface, no menus - I was disgusted. Out of necessity I learned enough vi to get along (we weren't even allowed to use X terminals for the first two years), but I never liked it. At home I continued to use QuickBasic and QuickC, or, when I started to switch to DJGPP (it allowed programming for protected mode which meant I could use the whole *8MB* of RAM without jumping through hoops) I just went with the simple DOS edit command and later with rhide.
Later, after switching to Linux I luckily stumbled upon NEdit. NEdit actually made me happy - it was fast, featureful and extremely configurable and scriptable. Unfortunately - being based on Motif - NEdit was also firmly rooted in the ancient past of Unix UI technology. Since there also was no sign of ongoing development I finally with great regret abandoned it (together with WindowMaker and my iBook) a couple of years ago.
Since then I have tried all CUA editors and IDEs I could get a hold on but none of them really satisfied me. Having replaced my iBook with a MacBook I decided to try OS X for a while, which didn't make the text editor situation any easier. I didn't manage to warm up to XCode and Smultron although nice felt a bit too locked in (just in case I wanted to ditch OS X again) therefore I stuck for a while with jEdit. After my annoyance with OS X and my MacBook had grown strong enough to go back to Linux (on a nice Lenovo R61) I decided to give kate and kwrite a try, which I have used since then.
A couple of weeks ago after having encountered another weird annoying bug in kwrite and an extensive round of checking on all linux text editors I know of I finally had enough. I decided to give vi a second chance.
And to my own utter surprise this time around I actually liked it. Vim really excels at configurability, speed, syntax highlighting and multi-window editing (due to its bugginess a constant pain in kate). On the other hand I didn't find it difficult at all to memorize the odd key combinations (though having a cheat sheet pasted to the wall doesn't hurt) and somehow they just didn't feel nearly as unintuitive as during previous encounters. Even the constant switching between insert and command mode which has always been my biggest issue with vi hasn't started to annoy me yet.
I could imagine that it's an age thing. It took me nearly 30 years to start to like olives, capers and anchovy and now I love them (visiting Sicily helped...).
Maybe vi really is an acquired taste and I just needed to pass the 35 to finally learn to appreciate it.
P.S.: While ditching kate/kwrite I also changed (back) to E17 and modified all color schemes to bright on dark. Could be that I'm just following fashion after all...
Sunday 31 October 2010
D is finally (nearly) there
Last week, in order to avoid working on more important things I started a small project I had wanted to do since quite a while. As mentioned before I am really not happy with C++ as a language to write simulations in. Unfortunately according to the Great Language Shootout all the nice languages are way too slow to be seriously considered.
However - as aptly explained on the shootout page - comparing the speed of programming languages and even the speed of implementations of programming languages is not very meaningful. Results will vary widely dependent on application area.
Therefore the only reasonable thing to do is to implement a benchmark which is representative of the kind of program one is interested in in all candidate languages. Which is exactly what I have started to do.
I have defined a reference model and implemented it in (very very basic) C++ and (C++ish) D (and CUDA which strictly speaking doesn't belong here. More on that in a later blog post - hopefully. I'm really bad at actually writing posts that I have announced before...).
To my great delight it turned out that the D program ran only about 10% longer than my basic C++ version. In principle this is clearly a small enough loss in speed to be compensated for by the nice improvements D offers over C++. I was really disappointed though (you can see how much I would like to abandon C++) when I found out a bit later that PGO (profile guided optimization) gives my C++ program another 20% boost. Add to that the fact that 64-bit D is still some way off and that value types are second class citizens in D and I'm not really sure whether I will do my next project in D or not. In any case it was nice to see the progress they have made. I am optimistic that my C++-days are numbered...
As for the shootout - I will try to find the time to add "proper" implementations in D and C++ (which hopefully will not perform much differently). I hope I will also be able to cover other interesting or up-and-coming languages, such as OCaml or Bitc. If anyone of my three readers feels willing and able to help out - just head over to the project page, read the model definition and hack away. I will be happy to post code/results.
However - as aptly explained on the shootout page - comparing the speed of programming languages and even the speed of implementations of programming languages is not very meaningful. Results will vary widely dependent on application area.
Therefore the only reasonable thing to do is to implement a benchmark which is representative of the kind of program one is interested in in all candidate languages. Which is exactly what I have started to do.
I have defined a reference model and implemented it in (very very basic) C++ and (C++ish) D (and CUDA which strictly speaking doesn't belong here. More on that in a later blog post - hopefully. I'm really bad at actually writing posts that I have announced before...).
To my great delight it turned out that the D program ran only about 10% longer than my basic C++ version. In principle this is clearly a small enough loss in speed to be compensated for by the nice improvements D offers over C++. I was really disappointed though (you can see how much I would like to abandon C++) when I found out a bit later that PGO (profile guided optimization) gives my C++ program another 20% boost. Add to that the fact that 64-bit D is still some way off and that value types are second class citizens in D and I'm not really sure whether I will do my next project in D or not. In any case it was nice to see the progress they have made. I am optimistic that my C++-days are numbered...
As for the shootout - I will try to find the time to add "proper" implementations in D and C++ (which hopefully will not perform much differently). I hope I will also be able to cover other interesting or up-and-coming languages, such as OCaml or Bitc. If anyone of my three readers feels willing and able to help out - just head over to the project page, read the model definition and hack away. I will be happy to post code/results.
Subscribe to:
Posts (Atom)