Note to readers: This is written by a linux newbie so corrections are welcome, flames are not.
Linux on the eee is NOT ready for the casual user yet. I've been doing cargo-cult programming getting the Eee to talk to my windows mobile 6 phone.
Broadly speaking the steps involved installing a compiler (requires a new repository adding to apt-get), subversion, download the kernel, rebuilding it then FINALLY building the driver I needed. Most of this involved typing in make commands that I'm not sure I needed and finally a bit of magic adding to a system file that I'm not sure is correct.
Having said that it does actually work unlike WMWifiRouter (turns your phone into a router) which works fine for the Vista machine but the Eee can't seem to route correctly via, it sees the phone connects and gets an address over DHCP but gets no further. I have tried it on the Ubuntu VM I have lying around and the situation is somewhat better as I had to install just subversion then the make files just worked.
My big problem here is that I'm typing in stuff that I've googled and found on the web with magic incantations that have no explanation and for some I've no idea why I need to it (why do I need to edit /etc/networks/interfaces) I feel like a cargo cult programmer who just cuts and pastes stuff straight of the web with no understanding of what it does. Worse still since I'll hopefully only ever need to do most of this once it doesn't even make commercial sense to actually spend the time to learn why (it may be worth doing for intellectual curiosity reasons). Someone could have messed with the wikis where I found this stuff and inserted in a 'rm -rf *' (or suitably obfuscated equivalent in perl for example) into the instructions and resulted in me nuking the machine without me having any chance of spotting it.
Sadly according to this interview with Linus TorvaldsI'm not sure the situation is going to get any better here are some choice quotes from Linus:
So, there’s a real reason why we need to be able to have source code which means that to all kernel developers, a binary interface is basically – it is only a bad thing. There is – there are no upsides whatsoever.
....
And this is something you do see in other projects where, yes, they have binary interfaces for one reason or another—quite often because of commercial reasons—and that just means that they cannot fix their fundamental design. They sign up not just the binary interfaces, they also sign up to the exact design they had when they came up with that interface.
....
So, there’s – that’s the second major reason why a stable ABI is not going to make – in fact, that means that we don’t even guarantee a stable API; so, even on a source level we say, “Okay, this is the API and we’ll – if you have external drivers that use this, we’ll help you fix them up when we have to change the API. But we don’t guarantee that the same API will work across versions.” And it doesn’t.
Jim Zemlin: But by opening up, you’d obviously be able to work with those issues.
Linus Torvalds: Right. Immediately when people work with, like, source API and then we can say when somebody complains, “Hey, it doesn’t compile anymore. My external module here depended on that function and now it doesn’t exist anymore,” at that point at least we can fix it for them.
So, that’s not a huge deal. It does mean that people who maintain external modules, even with source available, they can’t assume that they can just recompile unmodified across many different versions.
Sorry Linus this is a huge deal if Linux wants to escape the datacentre and make it over on to the desktop, I can't just go to a manufacturers website and pull down a linux driver, double click on the download hit next a few times and away I go. What you have suceeded in doing is transferring the pain from the kernel developers out to the driver developers (which may explain why you don't see as a problem) and the end users will never be able to cope with the pain. Wireless drivers seem to be a great example where there is a shim layer called ndis-wrapper which wraps windows drivers for linux. Oddly driver manufacturers put effort into their windows drivers where there is a stable interface, not into an environment where they have to release their source code and keep several different variants around in case someone decides to reconfigure the ABI / API. Windows drivers basically fall into four catagories: pre Win32 (Windows 3.11 and friends) Windows 9x, Windows NT and Windows NT 64 bit (ignoring Itanium). In practice as a driver writer today you can get away with writing drivers just for Windows NT and Windows 64bit possibly doing itanium drivers if you feel like it. Certainly the source code for both 32 & 64 bit windows can be the same, the rest is driven by compiler flags.
As an ex hardware engineer (many many years ago) I can well understand why driver manufacturers don't want to release their source code. It could be something embarassing, such as the need to reset a card when it times out sending a packet or it could be something which speeds up the network by 25% via a software hack and you'd like to keep secret.
To be fair to the Linux community on Windows I have the problem that I have no idea what a driver manufacturer will be installing (HP seem bad at installing other crap) but if the driver has been WHQL tested I have a fair idea that it will work and the testing MS perform on drivers has shaken the worst of the bugs out and I can always run DriverVerify myself on a really bad day. The version of 64bit Vista I run on my main machine forces drivers to be signed which can be a pain sometimes but means my system has only crashed when I've had actual hardware faults i.e. the MiniPCI network card in machine or the slot it's plugged into went wrong and brought the machine down.
Part of the problem here is the assumption on the part of the GPL crowd that binary compatibility doesn't matter. For me as the end user of the little Eee it isn't an issue out of the box it has an office suite and a webbrowser so it's probably good enough for most folks, but it doesn't have all the bluetooth bits you need to talk to a phone in place without a bit of compilation (or adding some repositories I think one of the Eee community ones has the bits). It doesn't have the stuff I wanted to talk to a Windows mobile phone either, it's a pure pain point that on windows I solve by finding the manufacturers website (or sticking in the supplied CD) clicking next a few times.
For software vendors binary compatibility IS a big issue, today you can get away with targetting JUST the NT code base (2000, xp, 2003, vista, 2008 and 64 bit variants) and for my current project I'm ignoring 2000 as I want to use WPF for learning purposes. Windows solves this pain point for me and it's where I'll be working for the forseeable future.
