I felt the quake in Montreal today, while working at home with my girlfriend. Although no dishes in our 3rd story apartment fell from the shelves and no structural damage to the building was immediately visible, it did serve as a good exercise about what to do in the event of a larger quake.

My girlfriend suggested that we stand in the middle of the building close to no visible exits. In spite of my immediate instinct to run down the stairs that we were directly beside, i went with her, which probably would have been a bad call, if the quake had been any larger in magnitude. In other words, if the building had collapsed we probably would have been trapped under debris.

The moral of the story is, that its sometimes a much wiser decision to exactly the opposite of what your girlfriend wants, even if it means that you won't be getting any for a few days.

Other examples of where Octave has much better potential than Matlab are:

1) Calling matlab-like matrix functions from another programming language.
2) Using Octave on an architecture other than x86.
3) Using Octave on mobile devices.

Thank Jobs for that!

There's a major difference you're not realizing. Java does not use 'arrays' in the classical sense (probably like many other languages with a VM).

In fact, a Java array is not even necessarily in the same congtiguous block of memory, while an array in C is. This holds for arrays of Objects as well as arrays of primitive types.

A Java array is essentially like any other object managed by the JVM but with syntactical support for indexing.

If you've ever used a C struct and some function pointers before, you could easily create a managed array 'class' in C. 'Object oriented' programming in C is used far more than you might think.

Poorly written code is the cause of buffer overflows, and naive programmers tend to make that very apparent when they write in C.

A few months ago, wasn't he going on about an economic rescue something or other?

In my opinion (although I am Canadian, but my opinion applies equally to my homeland as well), civil budgets should be one of the primary figures available to all on data.gov. That way, careless spending could be fairly easily monitored (potentially automatically).

This is utterly ridiculous... do people really find it that difficult to change the theme if they don't like it?

I promise, that it will not be torturous, nor will it inflict physical or psychological pain on anyone to simply go to System, Preferences, and Appearance to change the theme to what they've grown accustomed to.

It is Shuttleworth's distribution, and he can do with it what he wants. If he believes that these slight aesthetic changes will make him more money, then he has the freedom to make those changes.

Similarly, anyone else has the freedom to modify the default installation ISO to use the classic theme, if they prefer.

... but weigh less than half of one typical textbook.

Translation: This will weigh less than 1/10th of most engineering textbooks.

Why didn't they come out with this 10 years ago!?

today's smartphones are all about the 'software stack,' not the 'radio stack,'

The referenced article is not exactly valid. The author is spouting off historical common-knowledge to hopefully gain literary credibility, and must lack the technical expertise to be authoritative on the topic... more about that later.

The entire point of the article is to say that Microsoft approves of Apple for suing other companies (both Nokia and HTC now) over software patents.

The systems in question (mobile devices with loads of integrated wireless technology) are a sort of fusion of tightly-coupled hardware and software. Essentially, the software part is a device driver, whether it's communicating with an RF frontend or reading bytes from a capacitive touchscreen (which is why Apple has no grounds to be suing anybody right now). Also, Apple originally denied licensing their touchscreen software to Nokia in the first place, so they are essentially monopolizing it.

What this boils down to, is that some things are patentable while others are not. The capacitive touchscreen design - the physical form, the novel arrangement of metals and plastics and capacitive material - is patentable. The RF Frontend is (potentially) patentable, novel dedicated circuits for decoding baseband information are patentable. Reading bytes from an N-pin connector and interpreting those bytes is not patentable.

Now, to address the 'radio stacks are trivial comment': although the baseband portion (i decline to use the term radio here) does use a large part of software, that concept is already quite old.

Software-defined-radio was originally designed back when certain radio technologies were still young and they needed an easily reconfigurable transceiver. Transceiver technology has had quite a bit of time to mature since then, and now that we are approaching the theoretical limit of wireless channel capacity, companies are turning toward dedicated silicon. Dedicated circuits have the benefit of increased speed as well as the benefit of decreased power consumption (all that and more!), when compared to a general purpose dsp. When it's economically viable for a company to produce a dedicated circuit, then they usually will, and they should seek a patent for that device.

The aforementioned dedicated circuits ARE patentable, but the software used to control them is NOT.

A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux

The smallest Linux ELF binary to print ’Hello world!’