Rob Landley

it seems somewhat unlikely. let's follow the trail

the existence of bell characters, of course, predates gordon bell's existence itself (they're in the ita2 baudot-murray code from 01932, two years before his birth) so what we're discussing is specifically the assignment of the ascii bell character to the control character corresponding to bell's middle initial

it was already ^g in 01963 according to tom jennings's excellent history https://web.archive.org/web/20100414012008/http://wps.com/projects/codes/index.html#ASCII-1963 https://landley.net/history/mirror/ascii.html#ASCII-1963 and at that point bell had just started working at dec three years before. however, he was working on serial communications at dec, and had just been doing research at mit, so it wouldn't be terribly surprising if he, or friends of his from mit or dec, were to sit on the ansi (then asa) committee

mackenzie's 'coded character sets' from 01980 has a chapter 13 about ascii https://textfiles.meulie.net/bitsaved/Books/Mackenzie_CodedCharSets.pdf#page=233 but unfortunately it doesn't go into any detail on the composition of the asa committee. note that mackenzie was the ibm thug who invented ebcdic and spent the 60s and 70s trying to kill ascii, so he devotes most of the book to glorifying that catastrophic error; the book is from 01980, the year before ibm shipped its first ascii-supporting equipment, the ibm pc. it's reasonable to see jennings's account as a violent reaction against mackenzie's…

In earlier times, before Google or OS X even existed, long before "automatic updates", it used to be own experience that Microsoft's pre-installed Windows programs would run generally faster and with fewer issues (read: none) than third party software that a Windows user would install. This was also the case with software downloaded from Microsoft that a Windows user might install. Hence I thought perhaps MS Word today might run smoother on a Microsoft laptop than an Apple laptop. I'm not a Windows user anymore so I have no idea.

For reading, editing, creating Word documents, the TextMaker Android app seems to work. Size of recent version I tried was 111MB, startup is quick. Paid features are non-essential IMHO.

https://www.softmaker.net/down/tm2024manual_en.pdf

A personal favourite program for me is spitbol, a SNOBOL interpreter written in a portable assembly language^3 called MINIMAL. I'm using a 779k static binary. SNOBOL is referenced here:

1. https://borretti.me/article/you-can-choose-tools-that-make-you-happy

The Almquist shell is another favourite of mine. It's both the "UI" and the language I use everyday to get stuff done on the computer. Like Microsoft Word makes some HN commenters unhappy, it seems that the UNIX shell makes some "developers" unhappy.^2

But the shell is everywhere and it is not going away.

IME, old software from an era before so-called "tech" companies funded by VC and "ad services", still works and I like it. For example, sed is…

The grand irony is that Larry was one of the earliest advocates of open sourcing the operating system at Sun[1] -- and believed that by the time Sun finally collectively figured it out and made it happen (in 2005), it was a decade or more too late.[2] So on the one hand, you can view the story of BitKeeper with respect to open source as almost Greek in its tragic scope: every reason that Larry outlined for "sourceware"[3] for Sun applied just as much to BK as it did to SunOS -- with even the same technologist (Torvalds) leading the open source alternative! And you can say to BK and Larry now that it's "too late", just as Larry told Sun in 2005, but I also think this represents a forced dichotomy of "winners" and "losers." To the contrary, I would like to believe that the ongoing innovation in the illumos communities (SmartOS, OmniOS, etc.) proves that it's never too late to open source software -- that open source communities (like cities) can be small yet vibrant, serving a critical role to their constituencies. In an alternate universe, might we be running BK on SunOS instead of git on Linux? Sure -- but being able to run an open source BK on an open source illumos is also pretty great; the future of two innovative systems has been assured, even if it took a little longer than everyone might like.

So congratulations to Larry and crew -- and damn, were you ever right in 1993! ;)

[1] Seriously, read this: http://www.landley.net/history/mirror/unix/srcos.html

[2]…

Strictly, the difference between /bin and /sbin versus their siblings in /usr has to do with what you can fit on the RK05 disk pack that the system boots from. If it comes up too broken to mount the DECtape (or if you're lucky and your institution's not cheap, the second RK05) where /usr lives, you'd better be able to fix it with whatever's in /, because until you do that's all you've got. Hence keeping some binaries there, but not too many; your root volume is only a couple megabytes large.

Too, if /usr is on tape, that's a lot slower in random access than even a contemporary disk, which matters because you also don't have enough core memory to avoid paging binaries - so even things you might not need to fix a broken system still may be worth putting in /bin if you can afford the space, if they're frequently enough used to be worth the speedup.

I believe the difference between /bin and /sbin per se had to do with dynamic versus static linking, with /sbin reserved for statically linked versions of binaries critical to bring up or repair a system - after all, if something in /bin is linked against libraries in /usr/lib, then you still won't be using it if you can't mount /usr.

I'm not so sure about that part, though; it's been a very long time since any of this mattered at all to how Unix is operated in practice, and it is really only of interest to those curious about how the constraints of early hardware informed the evolution of historical filesystem layout…

Manpages as "worse is better"? Them's fighting words :) I think it's more an example of how GNU isn't Unix, for better and for worse[1][2].

Info seems to be deeply integrated with the Emacs mindset, so coming from a different editor it's got some learning curve. Except it never seemed to be setup properly by default on a new server, and when I installed something new I'd never remember what I had to do to add it to the root page. Many's the time I tried to info for something and got.. its manpage, but in a crappier setting. Scanning a large manpage with '/' seems far superior to playing whack-a-mole with Info's tree structure. I don't want to sip documentation with a straw, just give me the firehose. (This is also why I prefer 'man zshall' rather than the trying-to-be-helpful sections of the zsh manpage. Who in god's name remembers which of those sections the factoid they're looking for is going to be in?)

All this would be surmountable if Info worked consistently out of the box. But the combination of encountering it only intermittently in working fashion meant that any lessons I learned quickly evaporated, and had to be repeatedly relearnt. I'm very happy now that GNU systems have given up on trying to make Info happen. Documentation quality is all about the quality of the content. Working on the tools instead of the content is classic bikeshedding.

(The one great advance in Unix documentation recently is git's approach of opening the man page when you type…

I did try to explain the logic already, in this comment:

https://news.ycombinator.com/item?id=42338166

Letwin says what killed OS/2 was that it could run Windows apps.

This is not true.

That only applied to OS/2 2; OS/2 1 could not run Windows apps.

It didn't matter; there weren't any.

Windows apps followed Windows 3.0. Windows 3.0 followed the failure of OS/2 1.x.

This is his bias: he was one of the project leads and was passionate about OS/2, which blinds him to the fact that it was OS/2 1.x that flopped and there was nothing OS/2 2.x could do to usefully come back from that.

His assertion is that 32-bit OS/2 flopped, because it lacked native apps, because it could run Windows apps. This is not true.

It flopped because Windows 3 was out, and Windows 3 was a hit because it did what 16-bit OS/2 failed to do: it ran DOS apps _well_ and it could do that because it took advantage of the 386 chip.

His bias means he fails to identify the true cause although he named it.

Secondarily, I think we can point to a 2nd, non-technical, personal reason: Letwin was not involved in Windows 3, which was essentially a 1-man skunkworks project.

It was done by David Weise:

https://news.microsoft.com/2000/09/10/i-found-a-cool-little-problem-that-i-just-couldnt-resist-solving/

Helped by Murray Sargent:

https://www.landley.net/history/mirror/ms/davidweise.html