Fostering a culture that values stability and reliability(drewdevault.com)
drewdevault.com
Fostering a culture that values stability and reliability
https://drewdevault.com/2021/01/04/A-culture-of-stability-and-reliability.html
6 comments
Just to offer a compari-trast to the viewpoint of this article: X11. Two of the examples cited are the direct result of the attempt to throw out the X Window System. If there are any pieces of software that exhibit properties of serious stability, then the X Window System is surely among them--not to mention exhibiting a de facto "doneness". Wayland, on the other hand, seems to be a perfect example of a piece of software that enjoys an undue image of "freshness" because of its recency and level of activity--i.e. the trendiness that the post lambasts--while in practice seeming to be in a state of being perpetually never ready.
Besides X11, there's the Web for stability, or at least a subset of it. That's a subset of the subset that includes everything that has been standardized, implemented, and widely available since let's say 2000, 2005 or so. It's perhaps one of the most stable pieces of technological infrastructure that we have examples of. But in the face of this, we have people advocating that we throw away this stability in favor of another approach (Gemini) that is supposed to deliver on some vague promises of fulfilling its purpose better than HTTP does. In reality, it looks like another example of NIH and the flakiness of hobbiest programmers' fleeting interests and will probably be deader 10 years from now than Flash. Whatever the case ends up being, Gemini is needlessly incompatible with existing Web infrastructure, given its advocates' ostensible priorities of stability (and it goes beyond mere irony, considering the places where they are similar--but just not similar enough to be compatible).
Besides X11, there's the Web for stability, or at least a subset of it. That's a subset of the subset that includes everything that has been standardized, implemented, and widely available since let's say 2000, 2005 or so. It's perhaps one of the most stable pieces of technological infrastructure that we have examples of. But in the face of this, we have people advocating that we throw away this stability in favor of another approach (Gemini) that is supposed to deliver on some vague promises of fulfilling its purpose better than HTTP does. In reality, it looks like another example of NIH and the flakiness of hobbiest programmers' fleeting interests and will probably be deader 10 years from now than Flash. Whatever the case ends up being, Gemini is needlessly incompatible with existing Web infrastructure, given its advocates' ostensible priorities of stability (and it goes beyond mere irony, considering the places where they are similar--but just not similar enough to be compatible).
Nether X11 nor the web are stable. They are hulking behemoths that require the constant effort of lots of skilled programmers to keep working and up-to-date with the rapidly moving ecosystem around them. X11 cannot keep up with new hardware. The web cannot keep up with its maintenance load. They're well beyond the point of redemption.
In fact, they're both classic examples of the opposite approach to what my article argues for: they did not start saying "no" to ideas. They never constrained their scope to focus on stability and longevity. A website which works today could easily be broken tomorrow, which has only become true in recent memory. These are excellent examples of the consequences of not holding true to the ethos I describe.
In fact, they're both classic examples of the opposite approach to what my article argues for: they did not start saying "no" to ideas. They never constrained their scope to focus on stability and longevity. A website which works today could easily be broken tomorrow, which has only become true in recent memory. These are excellent examples of the consequences of not holding true to the ethos I describe.
The message is a contradiction. When you say that websites starting to break "has only become true in recent memory", you're just confirming the truth about the stability of the Web mentioned earlier, nothing else. You're playing with definitions, but not much more. If that kind of play is valid and your post is truly meant to describe an ethos of "saying no" (though sounds more like more retroactive argumentation), then there's nothing that stops "Gemini" from being defined as an intersection-by-proper-subset of HTTP, etc. Go ahead, commence with calling the 2005-era Web "done" by just saying "no". You'll be able to do with it whatever you want to do with Gemini. If you find that's still too much, then just say "no" more aggressively, right?
But that's not what's going on. As of today, what's written above about Gemini is true. Gemini is NIH, and it's definitely not a picture of stability. Despite the entire "ethos" of the project, it manages to project a worse sense of its own dependability, right from the beginning, than the Web does. Given all the bad stuff that can be said about the Web, that's saying a lot. Here's what you can't say about the Web or Gemini: that it's "Becoming a tool which 'just works' and can be depended on without a second thought". But the reason you can't say that about the Web? Because that's what the Web already is. There is no "becoming" involved. This is unlike Gemini, for which there is also no "becoming", but that's because that would imply there's a possibility that Gemini will ever get there, of being anything more than the computational equivalent of a fidget spinner that it is. Here's the best you can say about Gemini, even if you're predisposed to look at it with unmerited optimism:
Hey, folks. Step up and build your world around the opinions and whims of a bunch of people who showed up yesterday and decided to make something new because it felt like a good way experience self-fulfilment at the time. It's not the Web, because, you know--because of bloat. And it's important to say "no". Ah, yeah, that makes sense. Sounds good, too. So we're gonna go with that. And it's not Gopher, either, because... well, just because. But pay no attention to that! Gemini is the product of brilliant programmers who think the right way and are totally committed to dependability.
But that's not what's going on. As of today, what's written above about Gemini is true. Gemini is NIH, and it's definitely not a picture of stability. Despite the entire "ethos" of the project, it manages to project a worse sense of its own dependability, right from the beginning, than the Web does. Given all the bad stuff that can be said about the Web, that's saying a lot. Here's what you can't say about the Web or Gemini: that it's "Becoming a tool which 'just works' and can be depended on without a second thought". But the reason you can't say that about the Web? Because that's what the Web already is. There is no "becoming" involved. This is unlike Gemini, for which there is also no "becoming", but that's because that would imply there's a possibility that Gemini will ever get there, of being anything more than the computational equivalent of a fidget spinner that it is. Here's the best you can say about Gemini, even if you're predisposed to look at it with unmerited optimism:
Hey, folks. Step up and build your world around the opinions and whims of a bunch of people who showed up yesterday and decided to make something new because it felt like a good way experience self-fulfilment at the time. It's not the Web, because, you know--because of bloat. And it's important to say "no". Ah, yeah, that makes sense. Sounds good, too. So we're gonna go with that. And it's not Gopher, either, because... well, just because. But pay no attention to that! Gemini is the product of brilliant programmers who think the right way and are totally committed to dependability.
I agree the web as a platform for publishing static information is feature complete. You can publish basically any kind of static content you want (news, academic articles, personal sites, business landing pages, restaurant menus, etc) with ~2005 era tech and no JS.
But once you start to consider forms and interactive content, the possibilities for expanding interactivity are near endless: raster or vector maps, the spam bot / capcha arms-race, custom form widgets (ie. better dropdowns, file upload dropzones, datatables, drag/drop items), different connection types or wire protocols (XML/JSON vs. binary formats, Websockets, WebRTC, QUIC, more UDP-based stuff in the future), rich API's like payments, hardware security dongles, and social networks (webmentions/activity-pub/etc).
Kind of like Excel, these are each must-have's for some industry or app. Each one requires a different 10% of core features to work. So, we need them all if the web is going to be an application delivery platform. And for better or worse, it is the current de-facto standard cross-platform apps.
But I think this shows an interesting effect: platforms are very unlikely to ever be feature complete. Whereas distinct pieces of software are. PDF is another example of this kind of scope creep.
But once you start to consider forms and interactive content, the possibilities for expanding interactivity are near endless: raster or vector maps, the spam bot / capcha arms-race, custom form widgets (ie. better dropdowns, file upload dropzones, datatables, drag/drop items), different connection types or wire protocols (XML/JSON vs. binary formats, Websockets, WebRTC, QUIC, more UDP-based stuff in the future), rich API's like payments, hardware security dongles, and social networks (webmentions/activity-pub/etc).
Kind of like Excel, these are each must-have's for some industry or app. Each one requires a different 10% of core features to work. So, we need them all if the web is going to be an application delivery platform. And for better or worse, it is the current de-facto standard cross-platform apps.
But I think this shows an interesting effect: platforms are very unlikely to ever be feature complete. Whereas distinct pieces of software are. PDF is another example of this kind of scope creep.
A couple more examples I can think of:
- jq: https://stedolan.github.io/jq/
- pass: https://www.passwordstore.org/
- tokyo/kyoto cabinet: embedded key value database
- awk: text processing tool / programming language
- (almost per-se) any game that shipped on physical media