Month: April 2010

Speaking at BarCamp KL

Should have named it Software instead of Layers!I gave a short 30-minute talk at BarCamp KL today. The title of the talk was “Open Source Hardware – non-Arduino”. My objective was to basically make people aware of Open Source Hardware and that we exist and it is not all about Open Source Software only. My secondary objective was to generate some interest in this area among the different people in Malaysia. I basically structured my talk and whipped together some slides in 5-minutes around the title – “Open Source Hardware”.

Hardware
First, I started by defining why Arduino is not Open Source Hardware. This falls squarely into the realm of embedded software programming. While you can work very closely with the hardware, you are still limited by the capabilities of the hardware. The actual layer that I talked about allows you to design the hardware itself. So, one is no longer limited by the hardware layer at all.

Hardware is further broken up into layers:

  • System – SystemC is the primary language used at this level to stitch up the software guys who code in low-level C/C++ and the hardware guys who talk a different language. It is mainly used for modeling rather than actual design.
  • RTL/Gate – Verilog and VHDL are the primary languages used at this level. This code can actually be translated directly into gates through a process called synthesis. This is the main area of work done by most digital designers.
  • Transistor – SPICE is the main language used. It allows you to model actual transistors by feeding in parameters such as gate length-width, source-drain sizes and dopant parameters. This is primarily the realm of analogue designers.

Source
Hardware design is similar to software work in a way. The flow is similar and the skill-set required is also similar. In software the general activities are: code, compile, debug and test. In hardware, the general activities are: code, synthesise, debug and test. The bulk of the difference is the process of translating code into hardware.

In software, the compilation takes the code and outputs a binary blob that contains the software bits. In hardware, the synthesis process takes the code and outputs a bunch of logic gates. These gates can then be mapped into real hardware implementations and plopped onto an electronic board.

Open
Of course, there are lots of open source hardware designs out there, mostly found on OpenCores.

I gave a guy the example of the Arduino. If you work with Open Source Hardware, you can actually build a super Arduino – take an open source AVR core and couple it with a ethernet core, a crypto core, a video core and then you’ve got a souped-up Arduino without the limitations. You have just opened up a whole new market.

There, a quick talk on Open Source Hardware.

Apple RISC Machines

The Internet is abuzz with rumours that Apple is considering to buy ARM – the makers of the ARM processor that has all but conquered the mobile computing space. In fact, the market has already reacted to such strong rumours and has caused the price of ARM stock to go up to £2.55 a share today.

Now, what do I think of the rumour?

The businessman in me says that it is baseless. Apple would have no incentive to buy ARM at all because ARM is an intellectual property company. It does not sell any real microprocessors but chooses instead to license out its designs to other people, of which Apple is a licensee. So, Apple can already do whatever it wants with the ARM core that it gets, short of re-selling it onto other people. It can pop it inside any product that it wishes to and even make modifications and customisations like it did for the A4 processors used in the iPad.

The only business reason for buying ARM would be to deny other competitors from using ARM chips. This makes some sense if you think of it from Steve’s point of view. ARM is undeniably the market leader in mobile computing for a reason – it has technology that allows its processors to run really fast while consuming little power. That is why everyone uses ARM cores. By controlling ARM, Steve would be able to essentially dictate who gets to make mobile devices and who does not.

However, the engineer in me thinks that Steve would be crazy to do that. Although the ARM processor is technically superior to its competition, it is by no means the only way to make mobile devices. If Apple blocks others from using ARM, there are many other people who would be happy to step into that market (including yours truly). It just does not make any sense for Apple to absorb ARM – considering that it would have to spend about $8 billion to acquire that asset.

Even if Steve decides that nobody else in the world can use ARM except Apple, they would not gain anything. Their chief rival in the mobile space – Google, would not even break a sweat. While the Android platform is currently based on ARM, there is no reason why it cannot be switched to MIPS or something else easily. The kernel is Linux, which supports dozens of microprocessor architectures besides ARM. So, while it would be a small hiccup, it would not be a show stopper.

What’s most likely happening is Apple interested in taking a significant stake in ARM. Now, that would make both engineering and business sense. A stake in ARM would allow Steve to ensure that Apple retains some sort of influence in that area as well and steers ARM in the right direction. It would also allow Apple to get cheaper licenses, which would allow Apple to put ARM in everything, including Macs and servers.

That said, I do hope that this gets ARM some much needed exposure. Not many people know them, even though they are most certainly using a device powered by an ARM processor. It is ubiquitous like that.

Software Engineering

A colleague of mine sent me an article by Tom DeMarco, one of the pioneers of structured analysis and also a strong believer in software engineering processes. Previously advocating metrics, metrics and more metrics in the past, he has come to realise that software engineering is rather a misnomer. In one sense it is engineering but in another sense, it is not. After decades of invaluable experience, he has come to one conclusion:

For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business.

Since I have also been writing code for a couple of decades since my humble beginnings with LOGO and BASIC, I have to say that I am of the opinion that it is very difficult to control the process of software creation – and it is a creative process, no doubt about it. However, as an engineer, I do believe that metrics is useful but only after the fact. What I mean to say is that metrics are only useful in documenting failures.

It is silly to try to control software creation during its inception and conception. You just need to hire the best people, give them the best tools and then hope for the best. Project managers who try to micro-manage the project will invariably fail because of the nature of the metrics used – they try to attribute success to certain values. Unfortunately, the success of a software rarely depends on the number of lines of code maintained, nor does it depend on the number of faults found.

After a project has come to a finish – and when I say finished, I mean that the people involved have come to a unanimous decision that they are happy with the state of the product at the time – that is when software metrics can be used to measure certain things. For example, it could be useful to measure individual contributions to the code base and identify good managers. It could also possibly measure the number of significant changes made to base code.

Anyway, I think that the video below is as good a metric as any for measuring software quality. I like the fact that the contributors seem to come in waves. I wonder if it correlates with real-world events in any way.

Network Disk Cloning

I had occasion to clone a hard-disk over the network today. I wanted to replicate a VM setup that I already had running in one machine, over onto another, which will save me time from setting it up again. So, I checked the internet about using dd with nc to clone over the network. Most places gave the following info:

Target:

# nc -l -p 9000 | dd of=/dev/sda2

Source:

# dd if=/dev/sda2 | nc serverip 9000

However, trying that set of commands would fail. So, checking the man pages for NetCat revealed that you cannot use both the -l and -p parameters together. So, the correct set of commands should be as follows:

Target:

# nc -l 9000 | dd of=/dev/sda2

Source:

# dd if=/dev/sda2 | nc serverip 9000

Which worked out just fine in the end. Thought I’d share it.

Broadcast Storm

Learning about networking is not very fun unless you actually get to see it in action, which is the opportunity that I gave my apprentice today. A few months ago, the corporate network at the place where I am doing public service and paying my dues, went down when a low-level tech accidentally connected the network in a loop.

When that happens, it becomes possible to send packets round and round in a loop. This is not so much a problem with proper network connections because the packets will be terminated at the destination. However, it is a problem for broadcast packets as they could possibly be broadcast in circles – ad infinitum.

First, I got two computers with two network ports each. Then, I bridged the ports together so that br0 on each computer bridged eth0 and eth1 together. This is the example configuration for Debian networking:

auto br0
iface br0 inet static
bridge_ports eth0 eth1
bridge_stp off
....

Next, I connected one network port from each PC together with a LAN cable. I asked my apprentice to observe the lights on the network ports. They blinked a few times when the cables were first attached due to hand-shaking of the network capabilities. Then, all activity stopped.

So, I initiated a broadcast packet by performing a ping to a random IP address. Because the PC does not know the destination machine, it will send an Address Resolution Protocol (ARP) broadcast packet asking for the destination machine for a reply. We could have just as easily done this with an arping command instead.

The lights on the network ports began to blink with activity and we managed to observe things. After my apprentice got a good look, I stopped the pinging and we confirmed that all activity stopped.

Then, we connected the other two network ports from each PC together with a second LAN cable. Now, we have got ourselves a network loop. Again the lights blinked a few times during hand-shaking and then all activity stopped. I initiated another broadcast and the lights began to blink again. So far so good.

Now, it was time for the broadcast storm. I stopped the pinging like before but this time around, the lights did not stop blinking. The broadcast packet was moving round the network in a loop. My apprentice got all excited that the network ports were blinking rapidly even when there was no application sending out any activity.

Then, I disconnected one port and the blinking stopped – magic!

Finally, I showed my apprentice how the network would work with STP enabled. I changed the settings above and set bridge_stp on instead, restarted the network stack and reconnected the network cable. With STP in place, there would be periodic network activity when the STP packets were sent out but these were easily distinguished from the crazy blinking broadcast storm.

I repeated the whole experiment again, but this time, the broadcast packets stopped after the pinging application was stopped – success!

I think that this would make networking subjects more interesting. This experiment was fairly simple to conduct and took nary five minutes. It would demonstrate networking concepts in a very visual and visceral manner. It does away with the whole idea of imagining how network packets moved through a network. Beautiful simplicity.