Finally (and thanks to some nice people in Graz who resent a misaddressed package -- thanks guys!) my Cubox has arrived! It really is a cute little box:

The Cubox is a nice little ARM-based computer, capable of running Linux and decoding HD content. It sports HDMI and SPDIF outputs, and boots from an internal SD-card. It has minimal power requirements (3 Watts when streaming, <1W in standby) and is real quiet, as in, you don't hear it at all. It has no internal storage but can mount USB drives, and, even more importantly, networked drives.

I intend to replace my ageing media center PC with this. It did it's job, but was relatively noisy and drew a lot more power (ie. I always turned it off when done and had to accomodate the boot time).

Installing XBMC was quite straightforward thanks to the Wiki. I still need to set up the SPDIF stuff, and also need a TOSLink cable (I'm usually not into high end audio but I hope to combat some hum I get when using regular cabling to the amp).

Bootup:

[    0.000000] Linux version 2.6.32.9-dove-5.4.2 (rabeeh@kossay-desktop) (gcc version 4.3.2 (sdk3.2rc1-ct-ng-1.4.1) ) #46 PREEMPT Sat Jan 7 12:23:38 IST 2012
[    0.000000] CPU: Marvell PJ4 v7 Processor-wmmx [560f5815] revision 5 (ARMv7), cr=10c53c7f
[    0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] Machine: SolidRun CuBox Platform
[    0.000000] Marvell Dove DRAM parameters found (version = 0x09080000)
[    0.000000] Marvell Dove DVS parameters found (version = 0x09080000)
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] On node 0 totalpages: 163840
[    0.000000] free_area_init_node: node 0, pgdat c0756e30, node_mem_map c07ff000
[    0.000000]   Normal zone: 1200 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 152400 pages, LIFO batch:31

Permalink | Leave a comment  »

Permalink | Leave a comment  »

I'm a great fan of taking notes. I've collected notes for years, mainly on technical topics. The main goal was to prevent the "I know how to do this, I've done it before -- but how did I do it?" phenomenon -- ie. to collect a log of solutions to technical problems I've solved on the job or in private so I could easily reproduce said solution without relying on my rather haphazard memory. Some of the notes are just crudely copy-pasted terminal screenbuffer with a title; with others I've been more elaborate, adding prose explanation, resource links, etc. This was accompanied by notes from meetings, presentations and the like.

My notes system used to be a desktop wiki for some time, but quirks in the software (and the fact that I mostly relied on "grep" to find stuff, and didn't need interlinking that much anyway) led me to keep the notes in just a bunch of text files versioned first in subversion and then git, which I synchronised over ssh to a server of mine from various workstations.

That has worked quite well for some time now, but there are some issues. For one, while on a workstation I can easily sync text files up, this becomes a little more cumbersome on a smartphone. I'd like a little more comfort there. Also, while on a notebook it's no issue to type eg. some text from a flipchart, I'm not quite fast enough to do this on a phone -- the more natural solution would be to just take a photo. Finally, I've come to realize that I don't use all that many git features for my notes, it's mainly a glorified backup and synchronization solution there. In short, I'm thinking of migrating somewhere else.

I've had an Evernote account for some time, but only barely used it. I'm now contemplating adopting it for all my note-taking needs. There's a few niceties I discovered in the past days about Evernote:

• There's an API available, so migrating to (or from, as the case may be) Evernote should not be too much of a problem
• Besides the Android and Web client, there's also a quite nice free Linux client available (Nixnote/Nevernote)
• For my bunch of text files I relied on the filesystem for categorization, which is a bit limiting. Tagging notes with keywords makes much more sense
• Text recognition for photos and PDF (to make them searchable) and speech-to-text are two features which I won't use everyday but which can come in handy
• Also, there seems to be an Emacs mode for Evernote

So, I'm halfway sold. Still, I'm feel a bit uneasy relying on a proprietary external service, and I wonder if it's worth it. After all, my pile of text files served me well; they were reliable and I was fully in control. And another issue is whether it will put up an additional barrier to usage. Something I've come to consider as crucial for my note-taking is that it must be as easy and fast to use as possible; otherwise I will omit some of the most important notes (that service I finally managed to set up at 11pm after hours of head-scratching and swearing -- if taking a note about the process is the least bit of effort I won't do it). I hope that using Evernote won't impede that.

Do you use Evernote? Any thoughts, pro/cons? Should I take the plunge?

Permalink | Leave a comment  »

Had a “huh?” moment today: a copying job erroring out with the message “no space left on device”, even though there were plenty of free blocks on said disk device. What the copy process wanted to tell me of course was that it ran out of inodes, not free blocks.

I was copying a biggish code repository (lots of small files!) over to a 8Gb virtual disk I created for testing purposes.

Usually, on bigger disks, this wouldn’t be a problem since the default traditional ext3/4 Linux filesystem calculates a fixed number of inodes based on the size of the disk — large disks, large number of files and vice versa. With the defaults, a 8Gb disk would amount to only 524288 files however — my testing repository easily beat that.

The df command has the ‘-i’ switch to show the number of free inodes, eg.:

$ df -ih
 Filesystem            Inodes   IUsed   IFree IUse% Mounted on
 /dev/sda1                11M    490K    9,8M    5% /
 udev                    201K     520    201K    1% /dev
 tmpfs                   206K     452    206K    1% /run

Other filesystems, eg. JFS, allocate inodes dynamically, but with ext4 it’s baked into the filesystem at creation time.

For my virtual machine this was easy enough to overcome however — just add another virtual disk, and format it with a more fitting number of inodes. Specify ‘-i NUM’ with the mkfs.ext4 command to tell it how many bytes per inode it should use. The default is 16384; with 4096 you get four times as much inodes.

Permalink | Leave a comment  »

Maybe it's just me, but I find SE Linux just difficult to use. And hard to use, especially in a security context, is no good.

Permalink | Leave a comment  »

DARPA's autonomous hellgoatyoutube.com/watch?v=xY42w1…

— William Gibson (@GreatDismal) February 11, 2012

I guess mechanized warfare should be scary.

Permalink | Leave a comment  »

I’m a lazy/impatient typist and therefore a big fan of shell completion. There’s a lot of good completion support for common programs, but what if I want to have shell completion for a custom program or shell function? A quick and easy way is to bind one of the pre-defined completion functions, as I learned today.

Eg. I have a shell function “sshr” to log me into a remote host as root:

sshr() { /usr/bin/ssh "root@$@" ;}

To have the shell use the same expansion rules as regular ssh, bind it like this:

complete -F _ssh sshr

To get a list of predefined completion rules, run “complete -p”

This and more from

• Debian Admin post, pt1
• Debian Admin post, pt2

Permalink | Leave a comment  »

These guys have trained Golden Eagles for hunting. Awesome BBC video.

Permalink | Leave a comment  »

So I spent the last week in Amsterdam for training. Amsterdam is a great city, so it's unfortunate that I didn't have all that much time for exploration. Luckily I at least managed a small trip to the Rijksmuseum; while most of the museum is closed for restoration, they have a small selection with truly great pieces on display.

Training was also very enjoyable however. Topic of the training was the IT automation toolkit Puppet, and, since Puppet is written in Ruby, also a little of that was covered. Mr Haugen from Puppetlabs did an excellent job as an instructor; with just the right mix of theory presentation and exercises (and in between answering lots of questions).

I have a bit of a love/hate relationship with Puppet. I've been using Puppet before; it sure is a very useful tool but on the other hand... It does have some warts.  

For one the terminology of the DSL. For someone who has done OO programming the word "class" carries very specifc meaning. Puppet also has classes, but the are almost entirely unlike those from OOP. For example, all Puppet classes are singletons and may not be instantiated more than once. Also, there is some inheritance but overriding parameters is not supported; so the advice is to avoid inheritance and use includes. Include is not at all like someone with a C (or Erlang) background might expect it to be; it's not a simple literal file include but actually a kind of import + instantiate function. And so on.

On the other hand, I much like the declarative model and the fact that it is very open and extensible. For instance, configuration parameters need not be held in static files but may also reside in an external repository; all that is needed is a glue script to fetch said parameters.

Also Puppets approach is refreshingly pragmatic; it's all about getting stuff done. One can easily see that there are actual sysadmins using this stuff in production. It has decent support for testing and dry runs, for example -- good to have if you're not that confident about a system change you're going to roll out to a few thousand hosts. 

It actually reminded me a little bit of the earlier days of Zope2 -- lots of magic and little documenation; for someone who knows how to push the right buttons a lot can be done with little effort but to get there you have a not so friendly learning curve.

Puppet is written in Ruby, and for many types of extensions you have to get down to the Ruby level.

I haven't done much with Ruby before, so I'd like to take up the opportuniy write up some thoughts about the language and platform. My reference here is mainly Python, a) because these languages are in a pretty similar niche and b) Python is what I know best.

For this Python programmer, Ruby tends to feel a little "Perlish" from time to time. In cases where Python might choose to focus on "one right way" to do something, Ruby would rather provide several ways (in different flavors) to accomplish the same thing. This sometimes can be quite useful, sometimes rather confusing. For me, this makes Python more intuitively useful, but admittedly sometimes more verbose. 

One of the Perlish features of Ruby that I quite like are built-in regular expressions. For Sysadmins who constantly have to wrangle output of other tools to their own end regular expressions are a must have.  While Python of course has an excellent library for RE's it is still not the same level of integration as a native datatype with accompanying operators etc. On the other hand Ruby has Perls habit of setting tons of special global variables for RE matches -- not trying to be dogmatic here but can we maybe just try to avoid automatic global vars? Please? People get hurt by that stuff! This, to be fair, is entirely possible because Ruby _also_ provides other ways of accessing these values, without resorting to globals.

One of the Perlish things in Ruby that I wish they just had left out is the postfix conditional, ie. one can write "if x then foobar()" but also "foobar() if x". Larry Wall has stressed how that helps make Perl like writing English but in all honesty I'd like to have my software a little more regular than the English language with its abundance of corner cases and special rules for all kinds of occasions.

Speaking of conditionals -- many things which would be statements in other languages are actually expressions in Ruby, ie. they have a value; also including if-conditions. Eg. this function would add 2 to numbers smaller than 23 (since functions return the value of their last expression):

       def foo(a)
           if a < 23
              a+2
           else
             a
           end
       end

I find having more expressions lets one focus more on the data than on the procedure of how to operate on it. Yay for expressions! 

Ruby has a very easy way to parametrize methods with anonymous blocks of code. While this allows for some very higher-order / functional coding style (which I appreciate) I had the impression that feature tends to get somewhat overused (well at least from what I've seen in Puppet). Sometimes it felt as if people we're actively trying to avoid writing regular methods and instead resorting to fiddling with blobs of anonymous code to achieve the same thing. Still, good to have for functional programming.

Ruby is more consistent in its OO compared to Python, eg. while Python provides a built-in "length()" function, in Ruby only values which actually have a length (ie. Arrays) provide a ".length()" method. Makes a lot more sense, in my opinion.

By the way, you may call methods with or without parentheses in Ruby. Personally I prefer parentheses for calls, I find code easier to read that way, but that might also just be a matter of practice.

As to concurrency, Ruby unfortunately has similar problems as Python. The only directly supported concurrency model is a threading one, and like Python Ruby has to serialize access to data through a global interpreter lock. This usually results in Ruby code not scaling up very well on CPU-bound tasks. On the other hand, if you are doing CPU-intensive tasks you might want to consider a C extension anyway; these are luckily quite easy to embed (there even is a library that lets you inline C code into Ruby).

Moving away from the core language on to the runtime environment -- there's a lot of good and also some bad there. 

First to the bad: the standard library is, at least compared to the Python equivalent, a pretty rough place. Many modules are sparsely documented or not at all, and for some of the modules I kinda
wonder if anyone uses them.

The good, of course, is the gem system, to the point that I'm thinking maybe gems are the reason the stdlib seems to be lacking in maintenance.

Gems is Ruby's packaging format and application, and it handles everything a packaging system should -- installation, dependency management, querying, etc. Pythons packaging system(s) are, in comparison, a bit of a mess.

There are a lot of gems available. Rubygems.org boasts a total of 33160 packages available, and >444 million downloads. While nothing can be infered about the quality and/or usefulness of the provided libraries (and while still below CPANs legendary scale), these are nevertheless some impressive numbers.

All in all, I'm looking forward to doing more Puppet and Ruby. There's lots to discover!

Permalink | Leave a comment  »

These poor people have to share one guitar. And make some excellent noise with it.

Permalink | Leave a comment  »

Excellent street art by Mark Jenkins -- http://xmarkjenkinsx.com/outside.html

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Amazing vid, and definitely a great toy. Wonder if it can be taught useful things too tho'

Permalink | Leave a comment  »

Permalink | Leave a comment  »

That is, Go the programming language, not the board game.

Especially Clojure had fascinated me, and I hope to be able to
take a look at it further down the road. In the end, I went for Go out
of practical reasons. My bread-and-butter language is Python, and a
language closer to the metal (like Golang) would complement it better
than the rather high-level Clojure. I wanted to experiment with
distributed systems type stuff, and an efficient systems language
would just fit the bill.

I'm on vacation now for a few days, and while the main project for
it will be spending time with family, I'll set aside some hours to
dive deeper into Go. I have already read a bit about Go, and today
Frank Müllers Go book arrived in the mail -- so for the most part I
will work through that.

Permalink | Leave a comment  »

Andrzej Krzywda opines that Ruby on Rails is not in fact modeled after
the MVC pattern despite claims to the contrary. One could add that
Rails is not the only web framework or -application which misuses the
"MVC" tag. As Andrzej notes, the crux is that MVC requires the Model
to notify the View about any data changes. Something which in
classical web apps doesn't happen save for Websockets or similar
"push" technologies.

Indeed it seems that MVC has become some kind of marketing term, to
the point that not being "MVC" in a way reflects negatively on the
product in question.

Despite this, there are architectural patterns that make a lot more
sense for a web framework than MVC, which has its roots firmly in GUI
applications. For instance, Martin Fowler describes some patterns that are much closer to the way real web applications work.

Permalink | Leave a comment  »

From Neil Youngs superb and very underappreciated "Trans" album, 1982. I think I liked the album partly because it annoyed the folk lovers I grew up with ;-)

Oh, I just see a contemporary review -- the Rolling Stone praised the album highly at the time. Well, maybe not so underappreciated after all.

Permalink | Leave a comment  »

Animated tire commercial, ca. 1960

(via)

Permalink | Leave a comment  »

Went up Zugerberg yesterday. Was completely destroyed at the top but got rewarded with some gorgeous views!

I went counterclockwise, ie. up via Widishof and Juchenegg, down via Schindellegi, Berghof and Blasenberg. Next time I'll try it the other way round though; I think it might be less steep and this way you have the most beautiful views on the up stretch.

See the full gallery on Posterous

Permalink | Leave a comment  »

Excellent graphic novel, nice and dark

Permalink | Leave a comment  »