Vista, Windows 7, Ubuntu 9.04 and 9.10 boot speed comparison

Nice demo here on tuxradar showing Vista, Windows 7, Ubuntu 9.04 and Ubuntu 9.10 booting all at the same time. I won't tell you who wins, just follow the link.. :-)

blktrace graphs revisited

I blogged about seekwatcher a couple of days ago - it's great for producing charts from blktrace - however, I wasn't totally happy with the graph output. I wanted to be able to graph the data based on a tunable sample rate. So I've hacked up a script using awk and gnuplot to do this.

To run, suppose I've generated blktrace files readtest.blktrace.0 and readtest.blktrace.1 and I want a graph generated with 0.25 seconds per point, then do:

./generate-read-graph blktrace readtest.blktrace. 0.25

This generates a gnuplot file graph-reads.png, for example:

Now I'm happier with these results.

Ubuntu Release Party reaches 1000 users!

W00t - the Ubuntu Release Party for Karmic Koala reaches 1000 users!

Looking at free extent sizes on ext2, ext3 and ext4 filesystems

Today I stumbled on the wonders of e2freefrag, a tool for reporting the free space fragmentation on ext[2-4] filesystems. It scans the block bitmap data and reports the amount of free blocks a present in terms of free contiguous blocks and also aligned free space.

$ sudo e2freefrag  /dev/sda1
Device: /dev/sda1
Blocksize: 1024 bytes
Total blocks: 489951
Free blocks: 242944 (49.6%)

Min. free extent: 1 KB
Max. free extent: 7676 KB
Avg. free extent: 2729 KB

HISTOGRAM OF FREE EXTENT SIZES:
Extent Size Range :  Free extents   Free Blocks  Percent
    1K...    2K-  :             4             4    0.00%
    2K...    4K-  :            30            90    0.04%
    4K...    8K-  :             5            26    0.01%
  128K...  256K-  :             2           301    0.12%
  256K...  512K-  :             1           340    0.14%
  512K... 1024K-  :             6          4540    1.87%
    1M...    2M-  :             5          8141    3.35%
    2M...    4M-  :             5         14751    6.07%
    4M...    8M-  :            31        214751   88.40%


From this one can get an idea of the level of free space fragmentation in your filesystem.

BBC article on Ubuntu Karmic Koala

The BBC interviews Canonical's Chris Kenyon about Ubuntu 9.10 Karmic Koala. It's great to see the BBC helping to raise the profile of Ubuntu! Nice one.

blktrace based tools - seekwatcher

Previously I blogged about blktrace and how it can be used to analyse block I/O operations - however, it can generate a lot of data that can be overwhelming. This is where Chris Mason's Seekwatcher tool comes to the rescue. Seekwatcher uses blktrace data to generate graphs to help one visualise and understand I/O patterns. It allows one to plot multiple blktrace runs together to enable easy comparison between benchmarking test runs.

It requires matplotlib, python and the numpy module - on Ubuntu download and install these packages using:

sudo apt-get install python python-matplotlib python-numpy

and then get the seekwatcher source and extract seekwatcher from the source package and you are ready to run the seekwatcher python script.

Seekwatcher also can general animations of I/O patterns which also improves visualisation and understanding of I/O operations over time.

To use seekwacher, first start a blktrace capture:

blktrace -o trace -d /dev/sda

next kick off the test you want to analyse and when that's complete, kill blktrace. Next run seekwatcher on the blktrace output:

seekwatcher -t trace.blktrace -o output.png

..and this generates a png file output.png. Easy!

Attached is the output from a test I just ran on my HP Mini 1000 starting up the Open Office word processor:

One can generate a movie from the same data using:

seekwatcher -t trace.blktrace -o open-office.mpg --movie

The generated movie is below:





There are more instructions on other ways to use seekwatcher on the seekwatcher webpage. All in all, a very handy tool - kudos to Chris Mason.

Block I/O Layer Tracing using blktrace

blktrace is a really useful tool to see what I/O operations are going on inside the Linux block I/O layer. So what does blktrace provide:

• plenty of block layer information on I/O operations
• very low level (2%) overhead when tracing
• highly configurable - trace I/O on one or several devices, selectable filter events
• live and playback tracing

There are many different types of events that can be captured, for example, I/O merges, request re-queues, requests to underlying block device, I/O split/bounces, request completions and more beside.

One the user-space side, two tools are used: blktrace which is the event extraction utility and blkparse which takes the event data and turns it into human readable output.

Typically, one uses the tools as follows:

sudo blktrace -d /dev/sda -o - | blkparse -i -

And this will dump out data as follows:

8,0 0 1 0.000000000 1245 A W 25453095 + 8 <- (8,1) 25453032
8,0 0 2 0.000002374 1245 Q W 25453095 + 8 [postgres]
8,0 0 3 0.000010616 1245 G W 25453095 + 8 [postgres]
8,0 0 4 0.000018228 1245 P N [postgres]
8,0 0 5 0.000023397 1245 I W 25453095 + 8 [postgres]
8,0 0 6 0.000034222 1245 A W 25453103 + 8 <- (8,1) 25453040
8,0 0 7 0.000035968 1245 Q W 25453103 + 8 [postgres]
8,0 0 8 0.000040368 1245 M W 25453103 + 8 [postgres]

The 1st column shows the device major,minor tuple, e.g. (8,0). The 2nd column shows the CPU number. The 3rd column shows the sequence number. 4th column is the time stamp, which as you can see has a fairly high resolution time stamp. The 5th column is the PID of the process issuing the I/O request (in this example, 1245, the PID of postgres). The 6th column shows the event type, e.g. 'A' means a remapping from device (8,1) /dev/sda1 to device (8,0) /dev/sda, refer to the "ACTION IDENTIFIERS" section in the blkparse man page for more details on this field. The 7th column is R for Read, W for Write, D for block, B for Barrier operation. The next field is the block number and a following + number is the number of blocks requested. The final field between the [ ] brackets is the process name of the process issuing the request.

When one wants to stop tracing, hit control-C and a summary of the I/O operations is provided, e.g.:

CPU0 (8,0):
Reads Queued: 0, 0KiB Writes Queued: 128, 504KiB
Read Dispatches: 0, 0KiB Write Dispatches: 22, 508KiB
Reads Requeued: 0 Writes Requeued: 0
Reads Completed: 0, 0KiB Writes Completed: 32, 576KiB
Read Merges: 0, 0KiB Write Merges: 105, 420KiB
Read depth: 12 Write depth: 2
PC Reads Queued: 0, 0KiB PC Writes Queued: 0, 0KiB
PC Read Disp.: 9, 0KiB PC Write Disp.: 0, 0KiB
PC Reads Req.: 0 PC Writes Req.: 0
PC Reads Compl.: 0 PC Writes Compl.: 32
IO unplugs: 18 Timer unplugs: 0
CPU1 (8,0):
Reads Queued: 0, 0KiB Writes Queued: 16, 56KiB
Read Dispatches: 0, 0KiB Write Dispatches: 2, 52KiB
Reads Requeued: 0 Writes Requeued: 0
Reads Completed: 0, 0KiB Writes Completed: 0, 0KiB
Read Merges: 0, 0KiB Write Merges: 11, 44KiB
Read depth: 12 Write depth: 2
PC Reads Queued: 0, 0KiB PC Writes Queued: 0, 0KiB
PC Read Disp.: 3, 0KiB PC Write Disp.: 0, 0KiB
PC Reads Req.: 0 PC Writes Req.: 0
PC Reads Compl.: 0 PC Writes Compl.: 0
IO unplugs: 6 Timer unplugs: 0

Total (8,0):
Reads Queued: 0, 0KiB Writes Queued: 144, 560KiB
Read Dispatches: 0, 0KiB Write Dispatches: 24, 560KiB
Reads Requeued: 0 Writes Requeued: 0
Reads Completed: 0, 0KiB Writes Completed: 32, 576KiB
Read Merges: 0, 0KiB Write Merges: 116, 464KiB
PC Reads Queued: 0, 0KiB PC Writes Queued: 0, 0KiB
PC Read Disp.: 12, 0KiB PC Write Disp.: 0, 0KiB
PC Reads Req.: 0 PC Writes Req.: 0
PC Reads Compl.: 0 PC Writes Compl.: 32
IO unplugs: 24 Timer unplugs: 0

Throughput (R/W): 0KiB/s / 537KiB/s
Events (8,0): 576 entries
Skips: 0 forward (0 - 0.0%)

As tools go, this one is excellent for in-depth understanding of block I/O operations inside the kernel. I am sure it has many different applications and it's well worth playing with this tool to get familiar with all of the features provided. The ability to filter specific events allows one to focus and drill down on specific types of I/O operations without being buried by tracing output overload.

Jens Axboe the block layer maintainer developed and maintains blktrace. Alan D. Brunelle has contributed a lot of extra functionality - I recommend reading Brunelle's user guide to get started and also blktrace paper that contains a lot more indepth instruction on how to use this tool. The blktrace and blkparse manual pages provide more details on how to use the tools, but I'd recommend eyeballing Brunelle's user guide first.

Automounting Filesystems in user space using afuse

Afuse is a useful utility to allow one to automount filesystems using FUSE. Below is a nifty hack shown to me by Jeremy Kerr to automount directories on remote machines using sshfs:

sudo apt-get install sshfs afuse
mkdir ~/sshfs
afuse -o mount_template="sshfs %r:/ %m" \
-o unmount_template="fusermount -u -z %m" ~/sshfs/
cat ~/sshfs/king@server1.local/etc/hostname
server1

Ben Martin has documented afuse and some useful examples here.

Disabling Gnome Terminal Blinking Cursor

Looking at powertop, an idle Gnome Terminal is waking up around twice a second just to animate the blinking cursor. While this is a minimal amount of wake-ups a second, it still sucks power and also I find a blinky cursor a little annoying. To disable cursor blink for the Default profile run gconf-editor and set /apps/gnome-terminal/profiles/Default/cursor_blink_mode to off.

Makerbot - an open source 3D printer

This week I'm attending a Ubuntu Kernel Sprint and my colleague Steve Conklin brought along a fantastic gizmo - the Makerbot 3D printer. It is most fascinating watching it print 3D objects by extruding a thin ABS plastic trail of plastic in layers. It can print objects up to 4" x 4" x 6" - the imagination is the limiting factor to what it can print. Steve already demo'd it printing a variety of objects, the most impressive being a working whistle including a moving ball inside the whistle. It's not too slow either - it took about 25 minutes to print the whistle, which isn't bad considering the complexity and size of the object.













It's a cool piece of kit - doubly so because it's completely open sourced.

System Management Mode is Evil

System Management Mode (SMM) is an evil thing. It's a feature that was introduced on the Intel 386SL and allows an operating system to be interrupted and normal execution to be temporarily suspended to execute SMM code at a very high priviledge level. It's normally configured at boot-time by the BIOS and the OS has zero knowledge about it.

The System Management Interrupt (SMI) causes the CPU to enter system management mode, usually by:

• The processor being configured to generate a SMI on a write to a predefined I/O address.

• Signalling on a pre-defined pin on the CPU

• Access to a predefined I/O port (port 0xB2 is generally used)

SMM has been used to catch chipset errors, handle system failures such as CPU overheating, perform fan control, emulate hardware, and even run rootkits(!)

SMM cannot be masked or overridden which mean an OS has no way of avoiding being interrupted by the SMI. The SMI will steal CPU cycles and modify CPU state - state is saved and restored using System Management RAM (SMRAM) and apparently the write-back caches have to be flushed to enter SMM. This can mess up real-time performance by adding in hidden latencies which the OS cannot block. CPU cycles are consumed and hence Time Stamp Counter (TSC) skewing occurs relative to the OS's view of CPU timing and generally the OS cannot account for the lost cycles. One also has to rely on the SMM code being written correctly and not interfering with the state of the OS - weird un-explicable problems may occur if the SMM code is buggy.

By monitoring the TSC one can detect if a system is has entered SMM. In face, Jon Masters had written a Linux module to do this.

Processors such as the MediaGX (from which the Geode was derived) used SMM to emulate real hardware such as VGA and the Sound Blaster audio, which is a novel solution, but means that one cannot reliably do any real-time work on this processor.

The worrying feature of SMM is that it can be exploited and used for rootkits - it's hard to detect and one cannot block it. Doing things behind an OS's back without it knowing and in a way that messes with critical timing and can lead to rootkit exploits is just plain evil in my opinion. If it was up to me, I'd ban the use of it completely.

For those who are interested at looking at an implementation of a SMM handing code, coreboot has some well written and commented code in src/cpu/x86/smm. Well worth eyeballing. Phrack has some useful documentation on SMM and generating SMI interrupts, and mjg59 has an article that shows an ACPI table that generates SMI interrupts by writing to port 0xb2.

Footnote: Even Intel admits SMIs are unpleasant. The Intel Integrated Graphics Device OpRegion Specification (section 1.4) states:

"SMIs are particularly problematic since they switch the processor into system management mode (SMM), which has a high context switch cost (1). The transition to SMM is also invisible to the OS and may involve large amounts of processing before resuming normal operation. This can lead to bad behavior like video playback skipping, network packet loss due to timeouts, and missed deadlines for OS timers, which require high precision."

Always read the README file..

You know how it is, you get some source code and you fiddle around with it and try and make it build, install, work.. and then after wasting some time you eventually get around to consulting the README file. Well, some README files are well worth reading, here is the contents of the gnome-cups-manager README file... very amusing.

gnome-cups-manager
------------------

Once upon a time there was a printer who lived in the woods. He was a lonely printer, because nobody knew how to configure him. He hoped and hoped for someone to play with.

One day, the wind passed by the printer's cottage. "Whoosh," said the wind. The printer became excited. Maybe the wind would be his friend!

"Will you be my friend?" the printer asked.

"Whoosh," said the wind.

"What does that mean?" asked the printer.

"Whoosh," said the wind, and with that it was gone.

The printer was confused. He spent the rest of the day thinking and jamming paper (for that is what little printers do when they are confused).

The next day a storm came. The rain came pouring down, darkening the morning sky and destroying the printer's garden. The little printer was upset. "Why are you being so mean to me?" he asked.

"Pitter Patter, Pitter Patter," said the rain.

"Will you be my friend?" the printer asked shyly.

"Pitter Patter, Pitter Patter," said the rain, and then it left and the sun came out.

The printer was sad. He spent the rest of the day inside, sobbing and blinking lights cryptically (for that is what little printers do when they are sad).

Then one day, a little girl stumbled into the printer's clearing in the woods. The printer looked at this curious sight. He didn't know what to think.

The little girl looked up at him. "Will you be my friend?" she asked.

"Yes," said the printer.

"What is your name?" asked the little girl.

"HP 4100TN", replied the printer.

"My name is gnome-cups-manager" said the little girl.

The printer was happy. He spent the rest of the day playing games and printing documents, for that is what little printers do when they are happy.

Note that this text is covered by the GNU GENERAL PUBLIC LICENSE, Version 2, June 1991.

Disabling terminal bell in bash and vim

The terminal bell sound generated in bash and vim is rather annoying to myself and is an audible alert to my colleagues that I'm typing badly too. So how does one disable it?

Open ~/.inputrc and add the following line:

set bell-style none

To disable the bell in the vim editor, edit ~/.vimrc and add the following line:

set vb

Ah - silence again! That's one less distraction to contend with!

Encrypted Private Directory

One neat feature that's been in Ubuntu since Intrepid Ibex is the ability to encrypt a private directory. This allows one to put sensitive data, such as one's ssh and gnupg keys as well as data such as email into an encrypted directory. Thanks to Dustin Kirkland for writing up how to do this.

Basically, an encrypted Private directory is created and one can move the directories you want to be encrypted into this directory. Then one create symbolic links to these files in the Private directory. At login time, the encrypted Private directory is automatically mounted and also unmounted at logout time.

Note that hibernating is not a good idea with this solution, since private data in memory is written out to swap, which is not encrypted.

2009 Linux Plumber's Conference Videos

For those of you who could not attend the 2009 Linux Plumbers Conference in Portland last month, the Linux Foundation has now uploaded a whole bunch of videos of some of the talks, so you can now attend the conference from the comfort of your computer.

Linus's Advanced Git Tutorial (below) is an example of the kind of content available.






Below is a pretty impressive demo of Wayland, a new display manager for Linux - it's a great example of the way compositing should be. Well worth viewing..






I'm glad these talks got videoed, as I was unable to attend some of them because I was attending other talks in parallel tracks.

Multi-touch input demo

The 10/GUI project has a crisp video (below) of a multi-touch desktop user interface illustrating the downside in the single point mouse orientated GUI compared to the advantages of the multi-touch GUI.





I quite like the presentation, however I'm not sure how this maps onto a laptop where touchpad and keyboard real estate is limited. I also feel that it won't work out well with users who have had a bad accident with a hedge strimmer and have a few less fingers to use.

Anyhow, it's an interim solution; in 25 years time we will be controlling the computer with out any physical user interface as thought control will be the norm... ;-) Perhaps this should be called the 0/GUI as it require any finger digits at all.

Dumping ACPI tables using acpidump and acpixtract

Most of the time when I'm looking at BIOS issues I just look at the disassembled ACPI DSDT using the following runes:

$ sudo cat /proc/acpi/dsdt > dstd.dat
$ iasl -d dstd.dat

..and look at the disassembly in dstd.dsl

Some BIOS bugs need a little more examination, and that's where I use acpidump + acpixtract. The simplest way to dump all the ACPI tables is as follows:

$ sudo acpidump > acpi.dat
$ acpixtract -a acpi.dat
Acpi table [DSDT] - 24564 bytes written to DSDT.dat
Acpi table [FACS] - 64 bytes written to FACS.dat
Acpi table [FACP] - 244 bytes written to FACP1.dat
Acpi table [APIC] - 104 bytes written to APIC1.dat
Acpi table [HPET] - 56 bytes written to HPET.dat
Acpi table [MCFG] - 60 bytes written to MCFG.dat
Acpi table [TCPA] - 50 bytes written to TCPA.dat
Acpi table [TMOR] - 38 bytes written to TMOR.dat
Acpi table [SLIC] - 374 bytes written to SLIC.dat
Acpi table [APIC] - 104 bytes written to APIC2.dat
Acpi table [BOOT] - 40 bytes written to BOOT.dat
Acpi table [SSDT] - 685 bytes written to SSDT1.dat
Acpi table [SSDT] - 163 bytes written to SSDT2.dat
Acpi table [SSDT] - 607 bytes written to SSDT3.dat
Acpi table [SSDT] - 166 bytes written to SSDT4.dat
Acpi table [SSDT] - 1254 bytes written to SSDT5.dat
Acpi table [XSDT] - 148 bytes written to XSDT.dat
Acpi table [FACP] - 116 bytes written to FACP2.dat
Acpi table [RSDT] - 88 bytes written to RSDT.dat
Acpi table [RSDP] - 36 bytes written to RSDP.dat

..this dumps out all the tables into files.

One can the disassemble the required file using iasl, e.g.:

$ iasl -d APIC1.dat

or decode the table using madt:

$ madt < ACPI1.dsl
ACPI: APIC (v001 INTEL CRESTLNE 0x06040000 LOHR 0x0000005a) @ 0x(nil)
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
ACPI: IOAPIC (id[0x01] address[0xfec00000] global_irq_base[0x0])
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
Length 104 OK
Checksum OK

Or to just get one particular table, I use:

$ sudo acpidump -t SSDT > SSDT.dat
$ acpixtract -a SSDT.dat
$ iasl -d SSDT.dat
Intel ACPI Component Architecture
AML Disassembler version 20090521 [Jun 30 2009]
Copyright (C) 2000 - 2009 Intel Corporation
Supports ACPI Specification Revision 3.0a

Loading Acpi table from file SSDT.dat
Acpi table [SSDT] successfully installed and loaded
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)
.........
Parsing completed
Disassembly completed, written to "SSDT.dsl"

Armed with a copy of the ACPI spec, one can then start digging into why there are weird Linux/BIOS interactions occurring.

Arduino: Pulse Width Modulated Blinky LEDs

Another hour of Arduino hacking has allowed me to do some pulse width modulation on some LEDs producing some fade in/out effects. Basically I produce a square wave with varying durations for the high/low phases to control how bright/dim each LED is. Not exactly rocket science, but a fun little experiment.



It's a little more entertaining than my first Arduino program. Next I need to get some analogue inputs sorted out.. just need to find some free time.

Has the dollar devalued or are consumer goods getting expensive nowadays?

Price $16,321,500.00, sale price $12,555,000.00, you save $3,766,500.00


At least the shipping is free :-)

Ubuntu Kernel Team Bug Policies

Got a Ubuntu kernel related bug and you need help in report it? Or got an audio bug that's kernel related and you want to log the bug? Need advice or hints on how to gather kernel oops messages into a bug report? Or need to figure out how to report a bug upstream?

Well if you need this kind of help, then look no further than the Ubuntu Kernel Bug Policies wiki page. It's got a load of helpful information on kernel bug reporting and also how bug states are recorded from being initially reported, triaged, processed by a kernel developer and fixed.

We hope this will take the pain out of reporting bugs and helping you understand the bug fixing process. Kudos to Leann Ogasawara for this wiki page!

Software and bugs - the never ending march of progress

In my work I see bugs all the time. In fact, it's all I generally deal with. You see, software is always being written, re-written, optimised, improved with new features and being tweaked. Fundamentally, because humans are not perfect (and neither is the hardware too!) then bugs appear in their code.

If software just stood still and no changes were made, people will still would be finding and fixing bugs for a long time to come. With software changing so frequently, it's a small wonder bugs keep on appearing.

Then there is the added fun of more users getting their hands on software and hence more opportunities for bugs to be found. Software gets used in ways that the original authors did not expect. Sometimes weird (buggy) hardware issues need working around, which get reported as software bugs and need fixing either in software, firmware or hardware.

There are lots of sophisticated tools now to analyse code and determine if there are bugs such as buffer overruns or dead code paths. Tools can be used to measure the code complexity - this normally indicates one needs to do code restructuring to reduce the risk of obscure bugs lurking in the complex non-trivial code paths.

That's why I keenly believe in reviewing code, testing code and making sure it is well documented. Keeping the documentation up to date is paramount, and it's a never ending and weighty task (also known as boring!).

So if you are writing code, my challenge is as follows:

1. Are you more interested in adding new features than making sure the code works as bug-free as it can?
2. Are you regression testing your code, or just slapping it out and waiting for others to find the bugs?
3. Are you keeping your code well documented and keeping the documentation up to date?

Please don't mis-understand me, I don't want to sound critical. I'm not against progress, I'm just aware that sometimes new fancy "features" have higher priority than fixing old issues. Quality matters. Without it, users eventually give up and walk away, and that's a shame.

Wavemon - a bit more interactive than iwconfig...

There are times when I'm looking at wifi problems and I use iwconfig to check out link quality, signal level and noise level information. I did get into the habit of using the following rune:

watch -n 1 iwconfig wlan1

..to check out the status on my wifi interface wlan1.

There's always a tool out there that does the same kind of thing, but in a more presentable form - in this case it's wavemon.

To install use:

sudo apt-get install wavemon

and using it is as simple as:

wavemon

or one can specify the interface using:

wavemon -i interfacename

It's a minimally interactive screen based curses application, one can switch between display modes using the function keys. Pretty straight forward and easy to use.


One can configure the refresh rate, so one can poll the stats at the frequency you desire. Not bad at all.

LinuxCon 2009 Videos

A bunch of videos from LinuxCon 2009 last month are now available thanks to the hosting of linuxfoundation.org. Worth watching is the LinuxCon Round Table talk "The Linux Kernel: Straight From The Source" led by James Bottomley with panelists Linus Torvalds, Jon Corbet, Greg Kroah-Hartman, Ted Ts'o and Chris Wright.

Also, the closing Keynote talk by Mark Shuttleworth on "Coordinated Software Releases, The Linux Ecosystem, and the Impact on the Global Marketplace" is worth checking out too.

There are more LinuxCon 2009 videos available here.

Hacking the Arduino

I acquired a 16Mhz 8 bit Arduino micro-controller development board last week from my colleague Steve Conklin. The Arduino is a cool little open source electronics development system and allows rapid prototyping - ideal for hacking up small controller projects. I downloaded the C toolkit and GUI development environment from Arduino.cc and configuration was very simple and straight forward.

Basically, one can cruft up small C programs and download these to the board using a USB interface - the code is flashed onto the board so it can run stand-alone - sweet. Just compile, download and go!

Anyhow, today was my first opportunity to get some quality time to get hacking. I rummaged around in my loft and found a bread-board and a bunch of LEDs and resistors that I bought over 20 years ago and rigged up 4 LEDs to be driven from from 4 digital output pins. I quickly hacked up some code to enable the pin outputs and then drive the LEDs, see the video below:


The Arduino has a bunch of digital input/ouput pins and some analogue pins too - although I need to now read up about this to see what I can really do with this kit. Anyhow, thanks to Steve for getting this kit into my hands and walking me through the elementary stuff on how to select the right resistors so that I don't kill the LEDs and the Arduino; I knew I should have remembered all that basic electronics jiggery pokery when I did my Computer Science degree 20+ years ago...

My hope is to hook this up to various bits of hardware to enable me to do the usual debugging and hacking around. I've got various ideas of projects, such as an interface between my PC and my old Commodore 1541 disk drive, but I need to get some reference books out of my loft and do some more research before I get my hands grubby with real code.

What's neat is that I'm able to some relatively fast low-level 8 bit hackery without all that unnecessary OS nonsense making life more complex :-)

Ubuntu Karmic Koala 9.10 Beta Ready for Testing

Ubuntu Karmic Koala 9.10 Beta 1 is now ready to download and test. I recommend testing it out on your system now and filing any bug you find on LaunchPad as it helps to improve the final release product.

If you don't want to download it, here are some reviews worth checking out to give you a taste of 9.10:

Softpedia
ZDNet
TuxMachines.org
Fileforum.betanews.com

As it is, I'm running the Desktop release fine on a HP Mini 1000 (32 bit), a Lenovo 3000 N200 (64 bit) laptop, a Dell Inspiron 6400 (64 bit) laptop and server release on a Quad Xeon build box.

Enjoy!

Amusing Linux vs Windows comparison blog article

Ubuntucat has an amusing tongue-in-cheek comparison of installing software on Linux and Windows in this blog article. Made me laugh.

Monitoring top bandwidth usage of a network interface

Paul Warren's iftop tool provides quick-n-easy way of seeing the top bandwidth hogging connections on a specified network interface. Just like other top like tools, it's a text console based tool.

To install, use:

sudo apt-get install iftop

To monitor traffic on my wifi interface wlan1, I used:

sudo iftop -i wlan1

..note that specifying more than one interface causes it to segfault :-(

It has a few interactive commands, press 'h' to get help, and 'h' again to toggle back out of the help screen. For example, the 't' key allows one to cycle through send/receive display modes, and the 'p' key toggles on/off the port number on the connection display. Naturally, the 'q' key quits the application.


The bottom of the screen displays a summary of the TX/RX statistics including cumulative totals and peak transfer rates. All in all quite a helpful little tool.

Getting sense out of the sensors applet

There are times when I drive my laptop CPU really hard, for example compressing Gigs of data or running QEMU, and it would be useful to see how hot my processor is actually getting. This is where sensors-applet is useful - it has the ability to show the core temperature of the CPU and HDD if one has the appropriate hardware sensors and drivers installed. However, getting it configured requires a little bit of hand-holding to get it working.

Firstly, install sensors-applet using:

sudo apt-get install sensors-applet

..this will also install the lm-sensors tools.

Next, one needs to probe the H/W to find the appropriate drivers required to be able to sense CPU and HDD temperatures. To do this use:

sudo sensors-detect

This will ask you if you want to probe and scan various I2C, PCI and SMBus adaptors, so answer the probing questions with respect to the hardware you have in your machine. On my machine I answered "YES" to every question, your mileage may vary.

At the end of the probing, sensors-detect will print out some lines that you need to add to /etc/modules. Using sudo, edit /etc/modules and add these lines. Then reboot your machine.

Once you are logged in again, right click on the top Gnome panel and select "Add to Panel.." and scroll down and select the "Hardware Sensors Monitor". Once it's added to the panel, right click on it and select "Preferences". On the Sensors Applet Preferences panel, select the "Sensors" tab and then select the appropriate CPU and HDD devices to monitor.


Once this is done, you will hopefully be able to see your CPU and HDD temperatures rise and fall as you work on your machine:


From the command line one can also get the current sensor data using the sensors command, e.g.:

$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Core 0: +58.0°C (high = +85.0°C, crit = +85.0°C)

coretemp-isa-0001
Adapter: ISA adapter
Core 1: +57.0°C (high = +85.0°C, crit = +85.0°C)

Hopefully I won't see my CPU get to 85 degrees C, but now at least I can keep my eye on how hot it's getting :-)

More info about Ubuntu 10.04 Lucid Lynx

For those who haven't seen it yet, here is Mark Shuttleworth's announcement of Ubuntu 10.04 Lucid Lynx.