Linked by Thom Holwerda on Thu 7th Mar 2013 11:43 UTC
Debian and its clones "When you buy a Raspberry Pi, the $35 computer doesn't come with an operating system. Loading your operating system of choice onto an SD card and then booting the Pi turns out to be pretty easy. But where do Pi-compatible operating systems come from? With the Raspberry Pi having just turned one year old, we decided to find out how Raspbian - the officially recommended Pi operating system - came into being. The project required 60-hour work weeks, a home-built cluster of ARM computers, and the rebuilding of 19,000 Linux software packages. And it was all accomplished by two volunteers."
Thread beginning with comment 554541
To read all comments associated with this story, please click here.
Comment by Antartica_
by Antartica_ on Thu 7th Mar 2013 21:29 UTC
Member since:

There are some points that IMHO are being misundertood.

WARNING! Wall of text follows...

First point, about wasting talented people time:

In the Ars Technica article it was explained that this project was started as a "learning Journey", that is, one individual wanted to understand better the process of porting a distribution to a new architecture.

If you want to master something, you have to do this type of projects. If you want to know it inside-out, you have to do this sort of thing. [Unrequited car analogy follows] Car aficionados used to dismantle a car and rebuild it part by part. This is the same but with software.

This people just did it in a way that created something useful. AFAIK, this skill is normally studied using the "Linux From Scratch" guides.

Second point, about reinventing the wheel:

This is just an optimized port of a distribution. Just like in the past the i386 Linux distributions had versions optimized for i586 and later to i686.

It is something valuable, not "reinventing the wheel for the sake of it".

And the code is mostly there, the difficult part is bootstraping: having the initial "core" packages that allows you to build the rest of the packages. They smartly piggybacked on the armhf port and compiled from there the versions for raspbian.

This is not the first time someone has done a port of debian to a platform that has suboptimal characteristics with current arm ports. For example someone did an "armeb" Debian port, that is, arm big endian. This was to have a port with compatibility with big endian ARM binaries, in contrast with "arm" and "armel" that were little endian.

Third point, about the lack of this specific port in Debian proper:

Debian already had various ARM ports: the old "arm", the new "armel" and the newer "armhf" (see ). And if I'm not mistaken, both "arm" and "armel" official ports should work in the pi (albeit slower that raspbian).

I will explain this a little.

There are a lot of configurations of ARM in the wild. The initial Debian ARM port ("arm") was for armv4t with "old ABI".

This Debian used hardfloat with floating point accelerator opcodes which can be emulated in the kernel (so Debian worked in hardware like the ancient StrongARM).

Later there was the migration to EABI (the "new ABI", debian port named "armel"), which had a lot of advantages, such as being able to use in the same system binaries with hardware floating point support and binaries without it (softfloat), so you can have special versions of some packages optimized for a specific floating point unit. A specific one? Yes, there are hardware with several incompatible hardware floating point implementations (see ).

Even later, a new port was started targeting modern arm cores (armv7, that is Cortex A8 and compatibles; port name "armhf").

Just for reference, Debian is brewing a new port for 64bit ARM (although that hardware is not available yet!).

So, it is not that Debian didn't had a port for ARM hardware, rather that there are so many variations of ARM that they had to choose the subset to target. As they wanted to be "universal", they chose the ports which cover most hardware, at the expense of some performance.

Thank you for reading up to here, and excuse my grammar (I'm not a native english speaker).

Edited 2013-03-07 21:46 UTC

Reply Score: 9

RE: Comment by Antartica_
by Alfman on Thu 7th Mar 2013 22:03 in reply to "Comment by Antartica_"
Alfman Member since:

Thank you for posting. Are you connected to the project or are you just reading the article too?

That ARM ABI switch affected me quite directly as I witnessed it on a Buffalo Linkstation NAS device.

For my embeded NAS, I was able to recompile software to the new ABI without any of the shenanigans the article alludes to. Why go about solving the problem by building a completely unnecessary cluster comprised of underpowered target processors except as a personal challenge?

I'm not trying to be critical of that, I said in my first post that many of us do it for fun and do learn this way. But it still looks like most of the work was overkill and not necessary to achieve the end result. It will probably get thrown away if debian officially adds support.

Reply Parent Score: 3

RE[2]: Comment by Antartica_
by Antartica_ on Fri 8th Mar 2013 11:22 in reply to "RE: Comment by Antartica_"
Antartica_ Member since:

Yes, the information about them is only from the article and comentaries. I'm not connected to the raspbian project.

On the other hand, I've been a long time using Debian, both for hobby projects and for work. I've been using it continuously from version 1.3.1 onwards, and in embedded scenarios in the MIPS and several ARM variants.

About the compile farm: Debian is not setup for cross-compiling the operating system (in contrast to Angstrom, for example).

Not so long ago, you could cross-compile Debian using scratchbox (based on qemu emulating ARM, patched so that it calls the native cross-compiler when necessary), but as Nokia abandoned Maemo I suspect that scratchbox is not being updated anymore, so not usable with Debian Wheezy.

Reply Parent Score: 3