Ok, beating Aboriginal 1.0 into shape.

Tracked down the mips64 failure (it was commit f6be75d03c88 which is a one line change that broke the build, and reverting it fixes it -- no idea what it was trying to accomplish, some register swap).

The armv4l thing was the conversion to miniconfig, it was configured for EABI instead of OABI.

I guess that's close enough.

SHIP IT!

Ok, I can't use this from my phone, but I _can_ cut and paste that on my laptop and then whip up an ugly little list:

• bird-welcome
• rowland-rt-linux-failure
• anderson-irq-threads
• kroah-hartman-android
• gross-android-porting
• jung-lim-kernel-responsiveness>
• sally-gpio
• bird-announcements
• asay-keynote
• hilman-runtime-pm
• malek-adeos
• rostedt-ftrace
• toupin-toolchain
• lewis-stb
• vlasenko-dead-code
• williams-iglesias-fpga-qemu
• taylor-semantic-data-storage
• likely-arm-device-tree
• verkuil-soc-video4linux
• katz-qt
• pan-x86-mid
• schleef-open-video
• anderson-multicore
• edge-threat-models
• monroy-moorestown
• bird-state-embedded-linux
• desnoyers-lttng
• demo-session
• anderson-selinux
• anderson-jtag-part1
• anderson-jtag-part2
• landley-qemu-crosscompiling
• bennett-scripting
• zores-geexbox
• damm-kexec
• vomlehn-crash-dump
• volkov-zero-copy
• thomas-workload-pm
• wool-polishing-dirt
• ungerer-linux-without-bootloader
• bennett-scripting
• tippett-webos
• kanda-lock-free
• takahashi-shared-libraries
• osier-mixon-documentation
• de-marchi-multi-threaded
• koo-sero-dvfs
• sales-maemo

There. Now I should be able to download them from my android phone and watch them there. (Don't ask me why blanking the display makes the sound stop playing. I want to listen to some of these without watching them, and if I put the thing in my pocket with the display up it interprets random commands from walking. Oh well...)

So, in the most recent test run, armv4l, mips64, and sparc unexpectedly failed. (sh4, m68k, and armeb all expectedly failed.)

All of them compiled. The armv4l issue is failure to launch userspace, presumably an OABI issue.

The sparc problem is a hang instead of launching the shell prompt. That's... odd. It runs the init script. It prints "Type exit when done." Then nothing. It's oneit hanging. Because oneit isn't build statically even when BUILD_STATIC=all. Right, fix that...

And mips64 is dying because compiling thread-hello2.c ends with "Aborted". Ok, that one could be a kernel issue, let's see...

Why do I consider the Linux Foundation incompetent? Today, they sent me this email:

Videos from all of our keynotes sessions and a number of our
conference sessions from LinuxCon 2010 are now available to everyone
for viewing.
Simply register here, and you will automatically receive a password to
view the videos:

And so on. They want me to register and receive a password for the priviledge of viewing their videos. There is a gratuitous permission step, pure pointy-haired bureaucracy with no obvious purpose.

I don't even read news websites that require me to log in, why would I log in to view their videos? I don't need to create yet another account to get bog-standard read only access to something you're claiming to be posting on the web free to all. If you don't comprehend how Youtube works, that's your problem, not mine.

The Linux Foundation: so open you need a password to access our web pages.

So I need to use a Network Block Device (nbd-client) on target. I wget the source from sourceforge and attempt ot build it natively, but it's autoconfed, and has grown pointless prerequisites.

checking for GLIB - version >= 2.6.0... no
*** A new enough version of pkg-config was not found.
*** See http://www.freedesktop.org/software/pkgconfig/
configure: error: Missing glib

Ok, nbd does _not_ need to suck in a library from ftp.gnome.org. And a 0.15 megabyte source package sucking in a 5.33 megabyte library... Code reuse is nice and all but have a sense of _scale_. But they refuse to build without it, so in the interest of getting this over with let's humor them...

checking whether to enable garbage collector friendliness... no
checking whether to disable memory pools... no

The purpose of this library is to make command line option parsing slightly easier, correct? It's over five megabytes of source code and contains a garbage collector with multiple configuration options.

The G in Gnome stands for GNU project. It's the FSF's desktop. This explains much.

checking for pkg-config... no
configure: error: *** pkg-config not found. See http://www.freedesktop.org/software/pkgconfig/

That's not really a configure thing, is it? That's a "the build breaks if you don't have this, so you might as well just try it and die if it doesn't work". That's the behavior you'd get in the absence of ./configure, so this is an _invented_ problem. Also, one that's really easy to switch off if you know the magic incantation: PKG_CONFIG=/bin/true and try again...

checking for iconv_open... no
checking for libiconv_open in -liconv... no
checking for iconv_open in -liconv... no
configure: error: *** No iconv() implementation found in C library or libiconv

It refuses to build without internationalization support. This is SAD.

According to ./configure --help the "optional packages" section says:

  --with-libiconv=[no/gnu/native]
                          use the libiconv library

So let's try building with that...

checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for pkg-config... /bin/true
checking for gawk... (cached) awk
checking for perl5... no
checking for perl... no
checking for indent... no
checking for a Python interpreter with version >= 2.4... none
checking for iconv_open... no
configure: error: *** No iconv() implementation found in C library or libiconv

Ok, let's gloss over the idea that a C compiler has a size limit on the incoming files that you'd want to support by doing anything _other_ than breaking your source file up into pieces of the appropriate size. And let's gloss over large file support being something other than 64 bits (and your code needing to care on any level that sizeof() wouldn't address). And that Posix awk isn't good enough for what configure is doing and you need to check specifically for gawk, yet work without it. (Um, and the second code path exists for _what_ reason, exactly?) And the idea that an internationalization library might optionally need perl or python. And let's gloss over why the heck indent, a code reformatting tool, is in there at all. (Bwah?)

But the documented --with-libiconv=no option turned the configure check for iconv into a build break. Bravo.

How can anybody ever use autoconf without stopping to THINK about this stuff? Does nobody else ever question the utility of this giant steaming pile of crap?

Right. The easy way for me to do this is to port nbd support to busybox.

Putting together an Aboriginal Linux release. Documenting what I've done always brings up new things that maybe I _should_ have done. (Should build.sh produce a simple-system-image-$ARCH by default?) But I'm holding off on adding more stuff right now, for the moment anyway.

One persistent problem with building target-agnostic systems is that identifying the system you're on at runtime is a flaming pain.

There's a command to do it of course, "uname -m", and it works fine. The problem is the format of output it produces doesn't match what any of the build tools expect when told to produce code for a given format. On simple targets like x86_64 you can add "-unknown-linux" to the end of it to medicate the FSF packages into a semblance of rationality, but x86 is i486, i586, or i686, and that glosses over the floating point options entirely. The kernel calls them all "x86" and provides further detail in the .config file. Then on something like arm you've got armv4tejl-eabi...

The compiler knows what target it's building for, and #defines various macros, although in a highly inconsistent manner that leads to the programming equivalent of the blind man solving a Rubik's Cube in UHF. ("Is this it? Nope... Is this it? Nope...") But of course the FSF couldn't leave well enough alone, and invented multilib, so you have to tell the compiler what it's building for even when it's a native compiler. (I switch it off. That thing can't find _one_ set of libraries and headers reliably...)

Well duh.

China has been categorically ignoring copyright and patent for the past 30 years, and they're kicking our asses. Meanwhile, over here in "the land of the free" you need an ASCAP license to sing in public. We keep thinking the "free market" will doom China's totalitarian regime, but we're the ones patenting chemicals, genes and math. We've lost track of what "free" means, and we're wondering why we can't compete.

Remember how medieval guilds cornering the market on just about everything extended the dark ages by centuries? Today we've got the RIAA, MPAA, DVD CCA, MPEG LA... They're guilds. When Monsanto sues farmers because pollen from their genetically modified crops drifted into adjacent fields and thus their crops now contain patented genes, that's not a "free market". That's a shakedown extorting money from people who ACTIVELY DO NOT WANT TO BUY YOUR PRODUCTS, but have no choice.

Cornering the market does not improve the market. It's not good for the market. It's not HEALTHY. It makes a minority rich at the expense of the majority, which is bad for that majority. Making cartels very rich at the _expense_ of everyone else as a drag on the larger economy. Lowering entry barriers and transaction costs (as the internet does, the printing press did, pretty much the conventional definition of "free trade") is the _opposite_ of cornering the market.

Intellectual property laws are protectionist, raising transaction costs and entry barriers. They put moats around businesses so they don't have to compete with immitators to survive. They are obviously bad for the economy. Yet people go "But they allow you to corner the market and get rich! Getting rich is healthy for the economy, isn't it?"

Not always. Kim-Jong-Il eating off solid gold plates doesn't mean anybody else in South Korea has enough to eat. Mogadishu's full of warloads with suitcases full of cash, doesn't mean you want to live there. Cornering the market benefits individuals at the _expense_ of everybody else who has to pay monopoly prices to the single supplier, and intellectual property laws are all about cornering the market on ideas.

Gentoo from scratch progresses.

• Build base system, USE_UNSTABLE=busybox to get ported toybox patch.
• Run gentoo-stage1.hdc build.
• Set up /etc/make.conf by hand (with the volatile bits at the end for easy appending in future):

  • CFLAGS="-Os -pipe"
    CXXFLAGS="$CFLAGS"
    MAKEOPTS="-j $CPUS"
    GENTOO_MIRRORS="http://gentoo.osuosl.org/"
    SYNC="rsync://rsync.gentoo.org/gentoo-portage"
    
    # see /usr/portage/profiles/use.desc
    USE=""
    
    # see http://www.gentoo.org/doc/en/change-chost.xml
    CHOST="i686-unknown-linux"
    

  Remember to have $CPUS exported by the init script or MAKEOPTS gets ugly. (You'd think there would be some way for make to auto-detect, but no...)

• Link /etc/make.profile to /usr/portage/profiles/uclibc/$ARCH (adding the relevant $ARCH if you have a new architecture, probably have to play keyword whack-a-mole at some point but for right now get an i686 stage 1 working first).

• Run emerge --sync (my wrapper script, sets up /usr/portage and does an emerge --sync before putting the real emerge in place)...
• Get a stage 3 package list: emerge --pretend --nodeps system
• Try to emerge --nodeps util-linux

And it hung because it's using the "patch filename patchfile" command line arguments. Wow, I've never seen anybody actually use that before. Toybox patch didn't support that, and adding it to busybox make it harder to fix.

Sigh. The busybox option parsing remains impenetrable. Poked the list about it. Simple to implement in toybox, but making busybox getopt32argsthing() do it is kind of unpleasant at a conceptual level...

So ncurses ./configure has --without-cxx-binding but never tests either "is g++ installed on the host" or "does the host cc support c++". So it runs 8 gazillion probes, none of which is "disable c++ support", even though it has an option to do so manually.

Meanwhile, the distcc autoconf probes for python (and won't build python extensions if it's not in the $PATH), but does _not_ have any command line way to --disable-python. Because consistent behavior out of autoconf is anathema.

Here's a fun section of the rsync autoconf:

checking size of int... 4
checking size of long... 4
checking size of long long... 8
checking size of short... 2
checking size of int16_t... 2
checking size of uint16_t... 2
checking size of int32_t... 4
checking size of uint32_t... 4
checking size of int64_t... 8

Yes, it's checking the size of uint32_t, which has the number of bits in the name of the symbol.

How many different _levels_ of wrong are we talking here?

• This is easy to do at compile time with sizeof().
• The integer types (char, short, and int, and the behavior of long on 32 bit and 64 bit platforms) have their size specified by the LP64 standard.
• The [u]intXX_t types were introduced in c99, which specified their sizes.

It's the last one that's really, really boggle-worthy. They're testing the size of types which were specified by the standard that introduced those symbols. They _don't_trust_c99_.

Then there's this chunk of the bash ./configure:

checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes

Three checks for each header. Apparently checking the exact same thing. Doing something pointless, in _triplicate_.

And yes, it's pointless. If you're worried a header might not be there, make an "includes" directory that contains stub versions of each header you're worred about, #defining whatever WE_DO_NOT_HAVE_THIS guards or other alternate behavior the ./configure test is enabling, and then stick it at the end of your include path. That way if it can't #include the thing out of the system headers, it gets your "we do not have this" version instead. There's compiler command line options for this. Having ./configure do it is dumb.

Dear autoconf authors: please stop. Just give it up. You are taking a horribly wrong approch. Even before we moved to ubiquitous SMP and your tool remained resolutely single-processor and started taking longer than the rest of the compile combined, it was a BAD IDEA.

And of course my day job (helping port Linux to a new processor) hits the fact that every instance of config.guess is pretty much trying to do "echo $(uname -m)-unknown-linux" except it sits down and dies if it doesn't recognize the uname -m output. (Which it won't on a new processor, but when you're trying to build something like "patch" or "rsync" it DOESN'T MATTER, and the fix is "for i in $(find . -name config.guess); do echo 'echo $(uname -m)-unknown-linux' > $i; done" in each package that was dumb enough to use autoconf. Adding support upstream in autoconf would take years to percolate through to these various packages that block-copied it into their infrastructure.

(And yes, I know about variants like the armv5l-unknown-linuxgnugnugnudammiteabi tuple; FSF tuples are horribly designed and inconsistent but that's _another_ rant.)

People keep taking things like dropbear that didn't use autoconf and adding autoconf support to it because they think it's somehow an improvement. People wrote this huge pile of infrastructure, look how huge and complicated it is, obviously we don't want to duplicate all that!

You're right, you don't. You don't want to USE it either. It's a solution in search of a problem that encourages pointless complexity to breed, and you really don't want to get any of it on you. It's a steaming pile of garbage that should not _exist_. Don't go there.

Sigh. This whole "War on Science" thing is getting old.

Take global warming. Remember acid rain in the 70's? We put scrubbers on chimneys to take out the sulphur. But the carbon dioxide remained, and it's causing a bigger problem over a longer period of time.

Are they claiming acid rain wasn't caused by humans? Are they also claiming that the rain forests in south america aren't being destroyed by human activity? We can watch deforestation happening, an entire continent changing, clearly visible on sattelite photos. "Oh, deforestation is us, but the stuff with the glaciers can't possibly be us because human activity doesn't result in changes on that scale". Pick one, guys.

And the "God wouldn't let it happen" people are hilarious. Your book has a Great Flood story that says the whole world was under water, and you're using that book as evidence that the sea level can't rise if we're stupid enough to do it to ourselves. As Bill Engvall said, "Here's your sign".

Hmmm... uClibc++ won't build in gcc 3.4 because:

  #pragma GCC visibility push(default)
  #pragma GCC visibility pop

Were introduced in gcc 4.0. How much effort would that be to backport...

Ooh, the Ted talk URLs are _regular_. The first ever Ted talk put up on the website (Al Gore in 2006) is at http://ted.com/talks/view/id/1 and then the next one is http://ted.com/talks/view/id/2 and so on... There's even a spreadsheet of them all.

This could turn into an enormous time sink. (And if I ever bother to learn android userspace programming, a good first app would be to turn the spreadsheet into a ted talk browser/viewer.)

The Oracle suit against Google goes like this:

A few years back, Sun released their Java code under the same license as the Linux kernel (GPLv2). They can't really sue people for patent infringment on that code, because suing people for using the code they released under the license terms they offered is an extremely weak legal position.

But when Google released Android, it refused to allow any GPL code in userspace. They wrote (inferior) clones of BusyBox and uClibc (toolbox and bionic, respectively), and came up with their own "clean room" clone of Java called Dalvik. (I'm not sure why they bothered to still use a fork of the Linux kernel instead of writing their own version of _that_, since it's GPLv2 also, but you'd have to ask them what they were smoking thinking. I don't pretend to understand it.)

When Oracle bought Sun, they went "we may have licensed our patents for use in GPLv2 code, but your Dalvik thing isn't based on that code or under that license, so you're violating our patents". And they sued them for software patent infringment.

On the one hand, Oracle's being an evil patent troll, after years of saying its patents were only for mutually-assured-destruction defensive purposes (preventing other people from suing _it_ over software patents). Oracle smells of greed and desperation, and deserves to die.

But on the other hand, Google's strange refusal to allow GPLv2 in userspace is what opened them up to this lawsuit in the first place. Their "Not Invented Here" syndrome is what made it posssible for Oracle to sue them specifically, without having to take on the whole Open Source community at once. (Also, Google made Android pointlessly dependent on Java. At first they didn't even let you write native code, they insisted that all Android apps _had_ to be modern cobol. That was another _highly_ questionable technical decision that wound up exacerbating their vulnerability to this patent troll.)

I'm not saying Google deserved to be sued, I'm just saying they shouldn't have been _surprised_ that an obviously dying company would be acquired by amoral cretins intent on strip-mining its IP. (After all, we just went through this with SCO, and Sun Microsystems' ongoing loss of viability was increasingly obvious for the whole of its last decade.)

I can't say I'm really rooting for either of them here. The one I want to see go out of _business_ is Oracle, but Google's pointy haired, holier-than-thou approach to Android isn't really something I'm inclined to defend, either. That project's approximately as Open Source as MacOS X, it's just a fork off of Linux instead of from FreeBSD.

Eh, however it works out, this FUDs the heck out of Java as a programming language. "Use this, get sued." Good riddance, I hope.

Linux: losing capabilities it used to have since 1991. (Go ahead and boot it in 2 megs of RAM.)

• Endless discussion, which never gets implemented.

• Incompatible forks implementing the various approaches, which can't be integrated in the absence of emprical tests to determine "The Right Thing" to do.

• Delegating the problem to nobody, either by separating the "engine" from the "interface" (and thus tabling the issue in hopes that somebody builds a good interface someday) or else by making an extensively configurable interface with every possible UI suggestion as a selectable option, such that its lack of sane default behavior is now somehow your fault. (X11 managed to do both with "Window Managers". It's not our problem to do this part _and_ we refuse to make any actual aesthetic choices.)

But don't take my word for it. Here's Ian Jackson (author of Debian's package management system) explicitly telling non-coders he doesn't want to hear from them, and explaining why. He didn't mean to, but he excellently summarized why open source development can't handle user interface design.

This is why Linux on the desktop _can't_ happen. Our UI success stories involve a very small team (like the FireFox guys) going off and producing something they think looks good. And then we either enjoy their aesthetic vision (or in the case of FireFox grudgingly tolerate it because IE is so much worse), or we try something else. We don't collaboratively participate in the aesthetic design, because nobody's ever worked around Brooks' Law in this aspect of software development. Open source can produce Wikipedia, but it can't produce a story with a plot (let alone The Great American Novel).

Turns out the build doesn't rebuild itself without toybox patch. I really need to put a proper patch into busybox.

Ooh, Bernhard already started porting toybox patch to busybox...

Gentoo From Scratch is currently blocked on busybox "patch" being broken (can't handle offsets, which most patches accumulate fairly quickly). And I can't "emerge patch" because they might apply patches to it during the emerge. (Most packages do.)

Grabbed toybox patch and looked at breaking it out from toybox (the way I did oneit), but it turns out to be a bit of a pain. Patch makes uses of the option parsing infrastructure, which is incredibly convenient to use and a real pain to do without. I also have some library code, such as the line based streaming/cacheing infrastructure (copy_tempfile(), replace_tempfile(), delete_tempfile()) and linked list code (llist_free() and friends) that patch is built around. I.E. I'm making extensive use of common code, just like a good swiss-army-knife program should, and the busybox equivalents either don't exist, don't map easily, or are crap. Even turning it into a standalone program involves rolling up rather a lot of code and making stubs to glue it together (toy_exec() replacement that calls the command line parsing).

I can't just build toybox on the target because the Hexagon uses gcc 3.4 and the toybox build uses flags that aren't there in 3.x, and I don't want to upgrade the toybox build when I'm trying to wean things off of it.

I think the easy thing to do is just grab gnu patch and build that on target along with ncurses and zlib. (That way I know I won't be patching the tarball before building it.) Long term, getting my patch implementation into busybox means I could do without toybox, but the port is nontrivial and I'm not getting it finished tonight...

Why do I consider the FSF incompetent at programming

checking whether strstr must be declared... no
...
checking whether declaration is required for strstr... yes

Yeah, it's an old version of binutils, but _dude_. Autoconf is an abomination, but this kind of gratuitous duplication is just _sad_, there shouldn't be the _option_ for the two tests to get out of sync because it shouldn't be testing for the same thing twice in different ways. Code that doesn't exist can't break.

Of course code duplication is why the FSF exists in the first place; it's not like there wasn't already a Unix. The charitable view of their goal was they were trying to pull a Compaq and reverse engineer the Existing Thing to let a thousand clones flourish. Except they didn't. They failed to produce a clone, they refused to let other people build on their work without trying to hijack those projects and claim ownership of them (from copyright assignment to the Gnu/Linux/Dammit campaign, there's some serious turf issues going on with those guys). I gave up on them when they split the community with an unnecessary GPLv3, because it seemed like such a good idea when Sun came out with CDDL.

Yeah, glass houses: Busybox similarly reimplemented a bunch of existing command line utilities. Our excuse was that the existing versions (from the FSF) were obviously, objectively, demonstrably crap, and we were trying to improve the technology. They were doing it for ideology.

Every time I see Stallman say "Freedom" I keep imagining him screaming the word, painted blue, holding up a sword, channeling Mel Gibson.

Christian pointed mem at the "git describe --tags" command, which is the bespoke thing that does what I was looking for, which there's no way to work out logically unless you know the magic incandation that does it. This command does what I asked about, and nothing else. Knowing "git tag -l" gives you no hint this other command exists, the logical relationship between these UI elements is zero.

That's git for you. (And yes, the --tags option is on a command that deals exclusively with tags.)

I hate git. I really do. The people who designed the plumbing never stopped to think how any of it would be used, and the user interface is a bunch of ad-hoc bolted on independent bits that have nothing to do with each other.

For example, the kernel mercurial repository just ate itself, so I decided to move my old http://kernel.org/doc scripts over to git, since that's all the kernel maintainers care about. I had a simple mercurial invocation that would find the current tag, because it listed the tags in the order they were applied to the repository, and the last one in the list would therefore be the most recent. (If I pulled tags from multiple sources the order would get weird, but I don't. There's one upstream tagging source I care about, and pulling from that won't re-order the tags.)

So all I had to do to figure out the current kernel version was list tags and take the one at the end.

Git does not work that way. It's showing me the tags in alphabetical order or something, so 2.6.35 is always before 2.6.35-rc1, even though 2.6.35 is the final and -rc1 was the start of the development series that led up to it.

So I look at "git help tag" to see if there's some way to go "tell me the most recent tag preceding this commit". There is not, at least in the documentation. It never occurred to them.

In Mercurial, this is trivial to work out how to do for yourself. In git, it's random magic that somebody had to implement special and you have to learn the magic word, and if nobody coded up some bespoke code path to fish this piece of data out of the incoherence of their repository, it can't be done.

This is pervasive. I hate git.

Note that "git log -v" doesn't show tags in the log entries, so I can't search that way.

BUILD_THIS_PACKAGE_WITH_JUST_ONE_CPU=linux

Yeah, that's going to go over well...

Doctor Who "The End of Time" was surprisingly bad. It seems like it was made by people who have no respect for the franchise.

Putting the doctor on San Dimas time in the beginning was kind of odd. Leaving the "somebody's accelerating the development of the Ood" as a dangling plot thread, maybe it's a setup for future episodes, whatever.

Turning the Master into a cut-rate spider-man supervillan was just sad. The dude was always a meanace because he was smart, devious, and evil, not because he was a cross between The Toad and The Shocker. (Dude had access to rayguns under the 3rd doctor, it simply wasn't his _style_.) He made _plans_, and went out to Earth and its colonies to be a punch-clock villian the same way a british explorer in a pith helmet would go on safari to africa to shoot the native wildlife (and the occasional native). He was so obviously _enjoying_ it, but in an unthinkingly smug, superior way. Giving him pointless superpowers actually REDUCES the character.

Speaking of which, The Doctor is not Batman. This episode _wrote_ him as batman, but that's not his character normally.

I'm not always bothered by plot holes you could drive a truck through, but the main MacGuffin was _stupid_. "It's a gate! It's a medical device! And a floor wax! Oh, and it affects entire species at once!" Leaving aside how they implemented that last addendum, _why_ would you build something like that? What use case did they have in mind, exactly? Obviously there were no security implications to be considered in doing so, since they left it lying around to be salvaged after all.

When the master _did_ transform everybody, what happened to babies and fat people? It wasn't Timelord technology (it was familiar to the cactus people, whose ship was nothing to write home about), yet it affected an entire planet at once in a way that wasn't bothered by conservation of mass, yet left clothing alone... Right.

And then the "gate" _did_ get used as a transportation device later on for the time lords to (almost) come through. MAKE UP YOUR MIND.

The human trying to salvage the gate was apparently supposed to be a villian (I think?), but came across as a watered down version of The Man Your Man Could Smell Like. They really didn't bother with any characterization for him (or his daughter). Lots of abandoned plot threads. I have no idea why Donna, Rose, Martha, or Ricky were even in this episode. None of them had anything to do, it was just extended cameos. Donna not being transformed was another plot thread that went nowhere, it had zero effect on the outcome of the plot. Apparently the doctor planted an EMP generator in her skull though.

Digging up Rassilon as the main bad guy is a bit like the americans always being represented by George Washington. We've had lots of Time Lord names (Borusa and Thalia were chancellors, Leela married Andred, and of course Romanadvoratrelundar... IMDB gives a half-dozen other time lord names for The Deadly Assassin alone), plus a history of addressing people by titles (The Doctor, The Master, The Rani, Omega, Castellan). Going for Rassilon was _lazy_.

The Doctor's attempted execution in Arc of Infinity was "only the second time the Time Lord race has sentenced one of its own to death" (after Morbius), and Rassilon casually offs one of his advisors. The "race of dusty senators" is way, way, way off model.

Rassilon himself is hugely out of character. Let's dig up the dude who invented regeneration (that's why Rassilon's famous, Omega was the one who invented time travel) who put a limit on it (12 times) because he was worried about society stagnating if nobody ever died, and then bowed out of politics and bogged off to The Tomb of Rassilon despite being immortal... Let's dig up THAT guy and make him a power-mad bond villain played over the top by Timothy Dalton, with such an enormous drive to monologue that he narrates the episode. Ok, we all knew James Bond was a time lord, he's regenerated often enough, but this was played _straight_. That's the sad part.

I don't expect them to explore more of Gallifrey in an episode like this, but some BASIC RESPECT FOR CANNON would be nice. There is a bit. The War Games introduced Gallifrey under the second doctor, the Three Doctors had cutscenes on it, The Deadly Assassin was the first episode that took place entirely on Gallifrey, and Invasion of Time was set there as well. The Five Doctors, Arc of Infinity, and the whole season of Trial of a Time Lord were set there. Plus a bunch of time lords bumped into the doctor elsewhere, Drax and the Meddling Monk and that professor from Shada and the one who hijacked the 4th doctor's transmat beam to send them to ancient Skaro and that guy from the 6th doctor episode with the giant slugs... They've been the bad guys before, and put the doctor on trial and/or tried to kill him at least four times (war games, deadly asassin, arc of infinity, trial of a timelord). But they weren't "destroy the universe for personal gain" type nutso evil, they had _motivations_ and acted reasonably consistently. The Planet of Hats ridiculous headgear treatment they got this time around was just _sad_.

The seer from The Ribos Operation was on a primitive planet. Putting her on Gallifrey with the chanting and weird face paint made no sense. "The bones, the bones I seek! Gallifrey Falls!" Why did they do that?

Doctor Who is not Star Wars. The "Jar-Jar addresses the Imperial Senate" moment substituting Rassilon for Jar-Jar is easy to do with CGI cloning your five extras to make them look like a crowd inset in a matte painting, but really lazy. They blew budget on CGI and skimped on sets and extras. Also, the bad rip-off of the bit from the original Star Wars where the millenium falcon fought off the tie fighters (shooting down the missiles) was way too obvious, and also unnecessary. (The music tried to make it exciting, and failed badly.)

The Doctor's Sonic Screwdriver has turned into a magic wand, and is way overpowered. It was actually used as an offensive weapon this time. "Disable the whole spaceship with a zap" then "Oh, it's fixed" later on... I can only assume the two cactus people are mechanical idiots who don't know how their own ship works, despite the fact they were lead techs trying to salvage the gate thing? You can't pull that kind of stunt on a car (the engine block's cracked and the cylinders siezed up due to overheating? No problem, trivial fix.) But obviously spaceships are much simpler to maintain...

Having the Doctor jump out of a moving aircraft, crash through a skylight onto concrete and live... for no obvious reason. (Couldn't have rigged a parachute? Apparently didn't _need_ to. He's batman.) If internal injuries from _that_ had been the excuse for the regeneration, ok. But no, it wasn't.

Radiation poisoning taking days to kill him is one thing. Having his injuries magically disappear right afterward with a comment "it's starting" but then he still has a week to travel around and hook Jack up with a date and everything... They didn't NEED to do that.

Oh, and numbers. Have a sense of scale. Way back in Unearthly Child, the Doctor and Susan were from about 5000 years in the future (they didn't say which planet). Under the sixth doctor (trial of a timelord) it was something like ten million years of history. Now it's a billion. Those are very, very different numbers. Being pulled out of someone's ass.

Just about everything this episode got wrong wasn't _necessary_. They had enormous potential, and they blew it. Any reasonable scientific advisor or continuity researcher would catch a lot of this stuff, they just didn't _try_. Under the 7th doctor, they treated the show as a children's program and by doing so slowly strangled it to death. They seem to be doing it again. That's sad.

America, where any noun can be verbed and any verb is subject to nouning. When you you verbify a noun by adding an s to it you mostly seem to follow the pluralization rules ("jumps, watches"). But what do I do for the "cd" command? When somebody "cds" into a directory. Is it "cd's"? The thing is, it's an acronym for "change directory" but it's got no vowels so everybody pronounces the individual letters, and adding an s has a mental clashing of gears. I _really_ want to put an apostraphe, but that's posessive and I haven't got a good excuse.

I'll probably do it anyway, I'd just like to come up with a good _reason_. (I've also tried to rephrase the sentence, but "extracts the tarball, patches it if necessary, and cd's into the new directory" doesn't lend itself easily to rephrasing. "changes the current directory into that new directory"... awkward.

Yeah, more documentation work.

And as always, doing documentation work dredges up things I need to fix (because explaining how something works often reveals how it's subtly broken, and documenting the broken thing is less appealing than fixing it). My todo list runneth over, as usual...

Today, toybox patch has "possibly reversed hunk" issues, because if a hunk moved in the file then the first instance looks backwards if you're doing a position-independent search (which I am). The correct thing to do is make a note of it but only complain if we hit the end of the file and didn't find a correct place to put the hunk.

Did breaking apart extract_package from setupfor fix the old "we downloaded a new version, and setupfor tries to clone a working copy before cleanup_oldfiles runs" issue? Or do I have more work to do? (Eh, remove the workaround from sources/native-builds/gentoo-stage1.sh and see if it dies. And while we're at it, put FORK=1 back into buildall.sh for that. And move build-control-images.sh to the start of buildall.sh so the rest can rely on them being there. And make the USE_UNSTABLE=busybox build run the busybox test suite...)

Wow, the busybox test suite is sort of craptacular, isn't it? Yeah, I bumped into this a month and change back, but it really doesn't get a lot of love. I need to go bang on it at great length. I should figure out how to check stuff into git and push it upstream via ssh to morris, and what Denys's policy on that is...

Why does Google's "Chromium OS" exist? I've been trying to get a clear answer to that, and failing. People keep pointing me at some infomercial video so I can see it slice and dice and such, but they can't explain its _purpose_. The closest I've gotten was "like Gentoo, only less so".

Chromium's main design goal seems to be to _not_ run local apps. Everything runs in your web browser. Ok, except you can do that with existing Linux distros already, a web browser is a standard app that runs on Linux today (in fullscreen mode if you like), and people have been making dedicated kiosk systems out of Linux for 15 years now. (Often for the purpose of running a web browser to display some info.) You can make a squashfs root filesystem with nothing but a web browser on it, running as PID 1 on the frame buffer. Or have init fire up X11 and have .xinitrc bring up the web browser. Add a jffs2 mount for persistent config data if you want. This is not a new distro, this is a weekend project for a couple of embedded Linux geeks.

Speedy boot that doesn't probe for hardware... The hard part is making a speedy boot that _does_ probe for a wide range of hardware, and people have been working on that hard part for about 10 years.

They announced this thing back in 2008, their goal was to come up with a distro that did _less_ than existing distros, and they're still working on it. But... working to make it do what?

It's so uninteresting it almost comes out the other side to be fascinating: _why_ are they doing this? There's utterly no point to it I can see. Android had to add cell phone functionality and aggressive power saving stuff, and while they were at it they rewrote the whole of userspace to avoid Stallman's GPLv3 crusade and make a Linux that even the FSF can't bracket with "GNU//DAMMIT". But Chrome OS... what's the _point_? What exactly are they trying to accomplish?

No idea...

However, it's been long enough that I'm just going to make an exception, stub in that one, and go back and finish it later.

Biked to work today, hoping to get some cleanup done to prepare for the new guys starting monday. (And hoping to be able to take Friday off so I could spend an entire 3-day weekend trying to ship Aboriginal Linux 1.0 a week from now.) An hour and change later, arrived to discover I'd left my badge at home, and can't get into the building. Biked to Chick-fil-a. It's Sunday, they're closed. I've already got as much sunburn and heatstroke as I'm prepared for, and have finished both bottles of tea I brought with me. It's July in Texas, and only "flirting" with triple digits if the definition involves extensive use of tongue, so I'm not biking back home until the sun goes down a bit.

The list of Unix clones a couple days back didn't include an entry from the FSF. There's a reason for that. Stallman's own Gnu/Hurd project failed to produce a usable clone. His project did result in some interesting development tools (such as emacs and gcc) and a license other people found useful, but Stallman's focus on politics and idealism over engineering meant his actual attempt at a usable operating system utterly failed. (A fact he's been in an almost psychotic level of denial about for almost 20 years now.)

In 1998 he switched to trying to claim credit for Linux, ignoring not just Linus's work but the contributions of Tanenbaum and comp.os.minix community, the Berkeley developers, MIT's project Athena, and many others.

He's also tried to claim credit for the invention and preservation of "free software", which was the status quo before 1983 and continued to be so in many contexts, and which is similar to independent efforts such as creative commons (and project Gutenberg, which predates the founding of the FSF). Before Apple changed copyright law in 1983, "free software" was the norm from DECUS to the 8-bit BBS community. After the NSF allowed unrestricted use of the (heavily subsidized) internet backbone in 1993, free downloads were the norm from Napster to bittorrent. There was only a 10 year window for "shrinkwrap" software to establish itself, and the WWIV mod community arose and flourished during that without reference to any other group.

The initial success of the Free Software Foundation in the 1980's was aided by two things: the ftp site athena.ai.mit.edu and Sun's Vice President of Marketing (later head of the Software Division) Ed Zander.

The internet was started by the defense department, and later funded by the National Science Foundation, neither of which allowed commercial for-profit use of the network. To attach to the internet, you needed to either be a government entity or have a valid educational or research purpose. (Almost immediately the bulk of the traffic on the internet came to be dominated by non-scientific uses such as the sf-lovers mailing list, but since this attracted smart people to use the net it was considered a good tradeoff and the authorities looked the other way.)

In this context, having a high bandwidth FTP site (provided to Stallman by MIT) was an extremely attractive proposition. People signed their code over to the FSF to get internet distribution, back in the days when individuals unaffiliated with large institutions had few other options. They were the Sourceforge of their day, except that they essentially required you to sign a loyalty oath copyright assignment statement. Thus Larry Wall (who would go on to create the Perl programming language) assigned his "patch" program to the FSF, to get it up on their FTP site, even though he wasn't part of Stallman's crusade (and happily supported Perl on windows years later).

In 1992 Sunsite (now ibiblio) started up and undercut the FSF's power significantly, but the big change came when the NSF changed their Acceptable Use Policy in 1993 to allow for-profit use of the internet backbone. Suddenly, the internet hit the big time and home ISPs became commonplace. This meant jumping through hoops to get code on the FSF website was no longer necessary. The FSF's "killer app" was rendered irrelevant by Geocities.

The other big driver of the FSF's initial popularity was the short-sighted greed of Sun's Ed Zander, who started at Sun in 1987 and quickly came up with an idea to increase Sun's profitability: by unbundling previously standard parts of the operating system (such as network support) and selling them as optional extras. When Zander tried to charge extra for the compiler, lots of users looked around for alternatives, found that gcc supported sun3 from its 1.0 release (also in 1987), which quickly made it the de-facto standard compiler of Solaris.

This gave gcc the critical mass of early users and motivated developers to push ahead of other free compilers (such as BSD's Portable C Compiler, and the Minix C Compiler). Similarly, instead of paying Sun extra for better userspace tools, Sun's customers installed the GNU tools from the FSF (and improved upon them), because they were already familiar with the compiler. Zander forcing them to find and improve gcc was the initial attraction for this crowd.

But these users had no interest in working on Stallman's new operating system or promoting his politics, they just wanted a freeware tools vendor for their Sun workstations. So the Hurd and the rest of the FSF languished in relative obscurity, and with the rise of other internet distribution channels (sunsite, geocities, sourceforge), and codebases (FreeBSD, Linux), they began to recede into obscurity.

What really did them in was the rise of superior internet-enabled development models. Stallman never quite "got" the internet, he sold printed manuals and physical copies of GNU software (on _tape_) as a fundraising effort well into the 2000's. The distributed collaboration that gave rise to Wikipedia and Project Gutenberg was anathema to him, he insisted on tight control of all projects. To this day, the FSF requires a physical copyright assignment statement be filed (on paper) with the FSF before accepting patches from a new developer. The centralized "Cathedral" in Eric Raymond's "The Cathedral and the Bazaar" was the FSF, and the paper contrasted that old model with the new internet-enabled Bazaar of Linux development.

By the late 90's, the FSF was all but forgotten. Even Cygnus (which took its name from "Cygnus, Your Gnu Support", another recursive acronym which apparently Stallman finds funny) forked gcc development away from them with the "EGCS" project, because mainline development had ground to a halt.

By the time the internet was piped into everyone's homes, internet-enabled collaboration became commonplace, so Linux and Mozilla and Apache were probably inevitable. Alas, as Clay Shirky's talk points out, the main purpose of institutions is to perpetuate themselves, and the FSF's cathedral was no exceptiono.

Then in 1998, Linux grew "212%" because the Java developers switched over en masse when Netscape told them to. Netscape had led them into Java, and Netscape led them back out again to Linux. Most Java developers hadn't even moved from Java 1.0 to Java 1.1 until Netscape shipped it in their browser, and when Netscape released its source code and made Linux only its third "tier 1" platform (after Windows and MacOS), the Java developers immediately focused on Linux.

The "Anything But Microsoft" crowd had united behind Java a year or two earlier, after Windows 95 came out and made Windows tolerable enough that its userbase was no longer actively looking to replace it (like DOS and the 640k barrier before it). Technical superiority was no longer enough, if you wanted to avoid becoming a Windows programmer, you needed a development and deployment environment. Java was many things, but it never quite managed to be an operating system. Linux was, and it ran on cheap PC hardware, and because there was no way to choke off its development funding (as Microsoft had done for OS/2, MacOS, and BeOS), it wasn't going away.These developers didn't know anything about the history of Linux, they just saw it as an island of stability. Linux developers had wound up on Linux from such diverse places as the Amiga (Alan Cox's previous platform) and various 8-bit systems (Linus Torvalds himself went from a commodore Vic 20 to a Sinclair QL to a PC running DOS and Minix, to Linux). The flood of Java immigrants was welcome, but more than doubling the size of the community provided more than they could easily socialize.

The flood of new Linux developers didn't understand their own history, how Linus had inherited the original Unix flame (started by Ken Thompson and Denis Ritchie) through Andrew Tanenbaum's Minix and the Sun Microsystems manuals in his university library. They didn't know that the Berkeley guys had continued BSD development and fought a legal challenge to keep their own version unencumbered, and that Linux had only beaten the first 386 version of FreeBSD to market by a few months (and then leapt past it because of Linus's visionary management of an internet development community, the flood of warm bodies from the comp.os.minix development community it had inherited, and because early 386 BSD releases wouldn't boot without an expensive floating point coprocessor and Linux was designed to run well on the cheap hardware available to a college student).

In 1998, the Linux developers had their hands full teaching the new Linux developers their technical knowledge and development methodology, they didn't have time to spend on history.

Stallman saw his opportunity then. If the flood of new Linux developers didn't know the history of Linux, he'd tell them the story of the FSF. He would claim credit for Linux. He responded to the failure of his life's work with a compaign of revisionist history and self-aggrandizement that continues to this day.

Building on this, the FSF moved to recapture gcc development, handing over the GCC name to the EGCS project in exchange for them setting up a "government board" with some FSF members on it. The FSF quickly co-opted this new bureaucracy, co-opting EGCS (now "gcc 2.95") and turning it into a slow, bloated tangled mess. Much of this damage was done intentionally because a clean modular design would more easily allow proprietary extensions. As always, Stallman's political goals trumped practical engineering considerations, but now that the engineering work was being done for him (essentially due to the rise of the internet), he could focus exclusively on evangelism. The FSF became an almost religious crusade, with the occasional nod to the "charity work" of software development, but primarily focused on multi-level marketing, winning converts to spread the faith.

Of course Stallman's inability to give up control undermined the multi-level aspect of the hoped-for pyramid scheme, the pragamatists continued to ignore the FSF, and its importance continued to recede. Red Hat bought Cygnus, employing the maintainers of projects such as glibc, who resented Stallman's interference ("The morale[sic] of this is that people will hopefully realize what a control freak and raging manic Stallman is. Don't trust him." - Ulrich Drepper, maintainer of glibc.) Even though Stallman had inserted himself in Linux's historical narrative (after first ignoring Linux, then insisting it would never amount to anything), he was quickly relegated to "crazy uncle" status, a relic of a bygone age which most people could safely ignore, somebody who spent all his time blowing his own horn and hadn't produced any useful code in many years.

Eventually Stallman (along with uber-lawyer Eben Moglen) turned to the last thing the FSF unequivocally owned, the GPL. They produced a new incompatible version, and used their cabinet full of copyright assignment statements to force all their projects to move to it, in a bid to regain relevance.

The problem is that GPLv3 wasn't actually needed. Linus himself (correctly predicting the FSF's actions) had explicitly removed the "lifeboat clause" from the Linux kernel by specifying version 2 only for his own code back in 2000, shortly before the 2.4.0 release. Six years later, the FSF played chicken with Linus, assuming he (and the other senior Linux developers) would fall in line with the FSF and bow to Stallman's demands. They didn't.

Thus the FSF's pointless self-aggrandizement split the development community that had formed around the GPL by triggering the "lifeboat clause" when the ship wasn't actually sinking. (Nothing had rendered GPLv2 invalid or unenforceable, it was still a perfectly good license. Stallman channeled Darth Vader's Cloud City speech, "I am altering the bargain, pray I don't alter it any further". The pragmatists didn't play along.)

From a pragmatic/engineering/software development perspectve, this is probably the single most counterproductive thing Stallman could have done, but it achieved the goal of digging the FSF out of its well-earned irrelevance and dragging the spotlight back onto it. They could no longer be ignored, because of the damage they could do. The pragmatistis had to pay attention and be prepared to defend themselves.

GPLv3 prompted the BSD guys to get together to produce an alternative compiler (PCC), and the apple guys to sponsor their own (LLVM/Clang), but as with Windows, an entrenched de-facto standard is difficult to unseat. Hopefully, gcc will be obsoleted before the FSF finishes rewriting it in C++.

The FSF started as a conservative reactionary organization, resisting changes that swept across the industry in 1983 and harking back to the glory days of the 1970's (when source code was so ubiquitous computer magazines had BASIC program listings) in the back. The fact that change was worth resisting doesn't mean he _wasn't_ a short-sighted stick-in-the mud balking like a mule at the new and unfamiliar, with the goal of cloning existing technologies like Unix and C compilers. (Even emacs seems to have been a group effort primarily designed by other people.)

That's not how they present themselves, but you can't be a computer historian without wincing at the FSF's revisionist history. The success of Linux was in _spite_ of the FSF, not because of it.