Quotulatiousness

April 28, 2020

ESR on “Lassie errors” in software

Filed under: Technology — Tags: , , , — Nicholas @ 03:00

I’d never heard this term before, but it’s an excellent description of the problem:

“Interactive UNIX Booting” by mrbill is licensed under CC BY 2.0

Lassie was a fictional dog. In all her literary, film, and TV adaptations the most recurring plot device was some character getting in trouble (in the print original, two brothers lost in a snowstorm; in popular memory “Little Timmy fell in a well”, though this never actually happened in the movies or TV series) and Lassie running home to bark at other humans to get them to follow her to the rescue.

In software, “Lassie error” is a diagnostic message that barks “error” while being comprehensively unhelpful about what is actually going on. The term seems to have first surfaced on Twitter in early 2020; there is evidence in the thread of at least two independent inventions, and I would be unsurprised to learn of others.

In the Unix world, a particularly notorious Lassie error is what the ancient line-oriented Unix editor “ed” does on a command error. It says “?” and waits for another command – which is especially confusing since ed doesn’t have a command prompt. Ken Thompson had an almost unique excuse for extreme terseness, as ed was written in 1973 to run on a computer orders of magnitude less capable than the embedded processor in your keyboard.

Herewith the burden of my rant: You are not Ken Thompson, 1973 is a long time gone, and all the cost gradients around error reporting have changed. If you ever hear this term used about one of your error messages, you have screwed up. You should immediately apologize to the person who used it and correct your mistake.

Part of your responsibility as a software engineer, if you take your craft seriously, is to minimize the costs that your own mistakes or failures to anticipate exceptional conditions inflict on others. Users have enough friction costs when software works perfectly; when it fails, you are piling insult on that injury if your Lassie error leaves them without a clue about how to recover.

July 20, 2017

ESR on the early history of distributed software

Filed under: History, Technology — Tags: , , , , , — Nicholas @ 03:00

Eric S. Raymond is asking for additional input to his current historical outline of the development of distributed software collaboration:

Nowadays we take for granted a public infrastructure of distributed version control and a lot of practices for distributed teamwork that go with it – including development teams that never physically have to meet. But these tools, and awareness of how to use them, were a long time developing. They replace whole layers of earlier practices that were once general but are now half- or entirely forgotten.

The earliest practice I can identify that was directly ancestral was the DECUS tapes. DECUS was the Digital Equipment Corporation User Group, chartered in 1961. One of its principal activities was circulating magnetic tapes of public-domain software shared by DEC users. The early history of these tapes is not well-documented, but the habit was well in place by 1976.

One trace of the DECUS tapes seems to be the README convention. While it entered the Unix world through USENET in the early 1980s, it seems to have spread there from DECUS tapes. The DECUS tapes begat the USENET source-code groups, which were the incubator of the practices that later became “open source”. Unix hackers used to watch for interesting new stuff on comp.sources.unix as automatically as they drank their morning coffee.

The DECUS tapes and the USENET sources groups were more of a publishing channel than a collaboration medium, though. Three pieces were missing to fully support that: version control, patching, and forges.

Version control was born in 1972, though SCCS (Source Code Control System) didn’t escape Bell Labs until 1977. The proprietary licensing of SCCS slowed its uptake; one response was the freely reusable RCS (Revision Control System) in 1982.

[…]

The first dedicated software forge was not spun up until 1999. That was SourceForge, still extant today. At first it supported only CVS, but it sped up the adoption of the (greatly superior) Subversion, launched in 2000 by a group for former CVS developers.

Between 2000 and 2005 Subversion became ubiquitous common knowledge. But in 2005 Linus Torvalds invented git, which would fairly rapidly obsolesce all previous version-control systems and is a thing every hacker now knows.

Questions for reviewers:

(1) Can anyone identify a conscious attempt to organize a distributed development team before nethack (1987)?

(2) Can anyone tell me more about the early history of the DECUS tapes?

(3) What other questions should I be asking?

March 3, 2014

The origins of hacking and the myth of a lost Eden of open source code

Filed under: History, Technology — Tags: , , , — Nicholas @ 09:40

Gather round you kids, ’cause Uncle Eric is going to tell you about the dim, distant days of hacking before open source:

I was a historian before I was an activist, and I’ve been reminded recently that a lot of younger hackers have a simplified and somewhat mythologized view of how our culture evolved, one which tends to back-project today’s conditions onto the past.

In particular, many of us never knew – or are in the process of forgetting – how dependent we used to be on proprietary software. I think by failing to remember that past we are risking that we will misunderstand the present and mispredict the future, so I’m going to do what I can to set the record straight.

[…]

Without the Unix-spawned framework of concepts and technologies, having source code simply didn’t help very much. This is hard for younger hackers to realize, because they have no experience of the software world before retargetable compilers and code portability became relatively common. It’s hard for a lot of older hackers to remember because we mostly cut our teeth on Unix environments that were a few crucial years ahead of the curve.

But we shouldn’t forget. One very good reason is that believing a myth of the fall obscures the remarkable rise that we actually accomplished, bootstrapping ourselves up through a series of technological and social inventions to where open source on everyone’s desk and in everyone’s phone and ubiquitous in the Internet infrastructure is now taken for granted.

We didn’t get here because we failed in our duty to protect a prelapsarian software commons, but because we succeeded in creating one. That is worth remembering.

Update: In a follow-up post, ESR talks about closed source “sharecroppers” and Unix “nomads”.

Like the communities around SHARE (IBM mainframe users) and DECUS (DEC minicomputers) in the 1960s and 1970s, whatever community existed around ESPOL was radically limited by its utter dependence on the permissions and APIs that a single vendor was willing to provide. The ESPOL compiler was not retargetable. Whatever community developed around it could neither develop any autonomy nor survive the death of its hardware platform; the contributors had no place to retreat to in the event of predictable single-point failures.

I’ll call this sort of community “sharecroppers”. That term is a reference to SHARE, the oldest such user group. It also roughly expresses the relationship between these user groups and contributors, on the one hand, and the vendor on the other. The implied power relationship was pretty totally asymmetrical.

Contrast this with early Unix development. The key difference is that Unix-hosted code could survive the death of not just original hardware platforms but entire product lines and vendors, and contributors could develop a portable skillset and toolkits. The enabling technology – retargetable C compilers – made them not sharecroppers but nomads, able to evade vendor control by leaving for platforms that were less locked down and taking their tools with them.

I understand that it’s sentimentally appealing to retrospectively sweep all the early sharecropper communities into “open source”. But I think it’s a mistake, because it blurs the importance of retargetability, the ability to resist or evade vendor lock-in, and portable tools that you can take away with you.

Without those things you cannot have anything like the individual mental habits or collective scale of contributions that I think is required before saying “an open-source culture” is really meaningful.

July 25, 2009

A blast from my past

Filed under: History, Technology — Tags: , , , — Nicholas @ 20:08

I was reading Charles Stross’s blog the other day, and noticed that he’d nicely compiled all his “How I got here in the end” blog entries into a single post. I’d not read the whole thing, so a quick bookmark and I was off to other things. Today, while going back to the bookmark, I discovered that we may have crossed paths in our respective previous lives:

I spent nearly three and a half years working on technical documentation for a UNIX vendor during the early 90s. Along the way, I learned Perl (against orders), accidentally provoked the invention of the robots.txt file, was the token Departmental Hippie, and finally jumped ship when the company ran aground on the jagged rocky reefs of the Dilbert Continent. At one time, that particular company was an extremely cool place to work. But today, it lingers on in popular memories only because of the hideous legacy of it’s initials … SCO.

SCO was not then the brain-eating zombie of the UNIX world, odd though this may seem to young ‘uns who’ve grown up with Linux. Back in the late eighties and early nineties, SCO (then known more commonly as the Santa Cruz Operation) was a real UNIX company. Started by a father-son team, Larry and Doug Michels, SCO initially did UNIX device driver work. Then, around 1985, Microsoft made a huge mistake. Back in those days, MS developed code for multiple operating systems. Some time before then, they’d acquired the rights to Xenix, a fork of AT&T UNIX Version 7. SCO did most of the heavy lifting on porting Xenix to new platforms; and so, when Microsoft decided Xenix wasn’t central to their business any more, SCO bought the rights (in return for a minority shareholding).

SCO is one of the stops on my resumé that I rarely call attention to, as it was an unhappy and eventually unpleasant stop along the way. Charles says “late 1991”, so perhaps we didn’t actually meet . . . I visited the SCO Watford office in August.

Still, I’d like to think that I met one of my favourite authors before he became famous . . .

Later on in that mega-post he says:

During this process I discovered several things about myself. I do not respond well to micro-managing. I especially do not respond well to being micro-managed on a highly technical task by a journalism graduate. Also, I’m a lousy proofreader. Did I say lousy? I meant lousy.

Dude. You want to talk micro-managed? My (Toronto-based) manager wanted twice-daily meetings where I needed to show my progress since the last meeting. I got so paranoid about “showing progress” that I stopped writing altogether, just showing a list of emails I’d been involved in since the last 4-hourly meeting occurred . . .

Do I need to say that my employment at SCO didn’t last much more than a few months after my visit to the Watford office?

Reading further in Charlie’s memoirs:

Here is an example of a Terminally Bad Sign for any organization in the computer business:

… When you discover that your line manager’s recreational reading is the 1980 edition of the IBM Staff Handbook.

Oddly enough, I had a few co-op work terms with IBM in the mid-to-late 1980’s. There were few books that could strike fear in the hearts of technology sector workers like official IBM publications. My very first official IBM staff meeting had the head of R&D in IBM Canada saying things like “There is business out there that we’re not getting. Business that GOD HIMSELF wanted us to have!” For some reason, I thought he was making a joke. I laughed out loud. My IBM career didn’t exactly go upwards from there . . .

Powered by WordPress