2020-08-17
Firefox and web browsers for Linux
The (web) news of the time interval is that Mozilla is laying off a significant number of people, including people working on Firefox's web developer tools and MDN. Naturally this has led to people worrying about the future of Firefox (well, more than usual, since it's had declining web browser share for some time). As a user of Firefox on Linux I have some extra worries, because Firefox is kind of special on Linux.
People on Windows, Mac OS, iOS, and Android can be confident that there will pretty much always be a competent browser on their platform. Each of these platforms is backed by a big company and having a competent browser is too important to their success for the company to neglect it. Linux (or Unix in general) is the odd platform out, since there's no large company behind it to fund browser development. Competent Unix web browsers are kind of a side effect of browser development for other platforms.
Out of the main browsers remaining, only Mozilla has felt genuinely committed to keeping their browser going on Unix. Apple and Microsoft are obviously indifferent, and Google's corporate goals for Chrome only require it to work on major platforms such as Windows and Android (Android is not Unix here, because Android doesn't use X11 or Wayland and has increasingly divergent APIs and capabilities). It's fairly easy to imagine a future where Firefox fading out leaves Unix people with essentially no modern browsers and a growing set of sites that we couldn't really use.
(I believe that the Chrome developers generally care about Chrome working on Unix, but they're at the mercy of what Google is willing to spend money on. If the spur of competition from Firefox goes away, Google might decide that Unix no longer qualifies. They might even decide that supporting Chromium on Unix is getting in the way of internal changes that make it better on Android and Windows.)
This might sound theoretical, but in a way Unix users have been here before. Back in the days before Netscape open-sourced its browser to create Mozilla, Netscape's browser was pretty much the only good option for Unix users, and Netscape had a solid period of relative stagnation in the late 90s and early 00s. I used Netscape back then and it was not really a great experience. I'm not looking forward to the possibility of a rerun of that.
(In the pre-Mozilla days, Unix users were also at the mercy of what Unixes Netscape bothered to provide browser binaries for. I'm pretty sure that there were some Unix workstation users who lost out due to that, which didn't help the fortunes of their Unix vendors in an era where the web was becoming more and more important.)
PS: It's possible that Canonical, Red Hat, and perhaps SuSE would get together to fund enough ongoing Firefox development to keep things viable on Linux (and hopefully other Unixes). Perhaps there are even people in these organizations considering this issue right now.
Important parts of Unix's history happened before readline support was common
Unix and things that run on Unix have been around for a long time now. In particular, GNU Readline was first released in 1989 (as was Bash), which is long enough ago for it (or lookalikes) to become pretty much pervasive, especially in Unix shells. Today it's easy to think of readline support as something that's always been there. But of course this isn't the case. Unix in its modern form dates from V7 in 1979 and 4.2 BSD in 1983, so a lot of Unix was developed before readline and was to some degree shaped by the lack of it.
(This isn't to say that GNU Readline and Bash were the first sources of readline style editing, command completion, and so on; on Unix they go back at least as far as 1983, with tcsh. But tcsh wasn't pervasive for various reasons.)
One obvious thing that was shaped by the lack of readline was csh. Csh has a sophisticated set of operations on your command history that are involved through special strings embedded in your command line. To quote the 4.2 BSD csh manpage:
History substitutions place words from previous command input as portions of new commands, making it easy to repeat commands, repeat arguments of a previous command in the current command, or fix spelling mistakes in the previous command with little typing and a high degree of confidence. History substitutions begin with the character `!' and may begin anywhere in the input stream (with the proviso that they do not nest).
The most well known history substitution for tcsh users is probably
'!!', which repeats the previous command. Bash has a similar
facility, cf,
and even today the Bash manual calls out its similarity to csh's
version. These days I suspect most people using Bash don't use Bash's
history substitutions and just stick to readline stuff; it's generally
more fluid and easy to deal with.
(This is an obvious observation, but at times it's easy to blur the old days of Unix together and lose track of how comparatively old some parts of it are. Or at least it is for me.)
PS: My impression is that the widespread availability of command and filename completion subtly shapes the kind of command names and file names that people use. When you don't have completion, it makes a lot of sense for names to be short and it doesn't matter if they're all jumbled together so that completion can't tell them apart. Famously, Unix loves short command names because they're short to type, which makes a lot of sense in a V7 environment.