defanor

Being nitpicky, and since the article itself focuses on things not inflicted on users, here are a few things it still inflicts on users:

- Changing line-height.

- Changing fonts (or trying to, if it is allowed in a web browser).

- Changing colors (likewise).

- Changing body's max-width, margins, paddings.

- Adding a mostly useless header.

I find these less annoying than the ones listed in the article, and they are easily mitigated by the reader view, disabled CSS, or custom global CSS, but there they are.

I guess that Cambodian lion is rather like the Chinese lions, which "are intended to reflect the emotion of the animal as opposed to the reality of the lion" [1], falling into the bucket with intentionally unrealistic (non-lifelike) art.

[1] https://en.wikipedia.org/wiki/Chinese_guardian_lions#Appeara...

Sounds like a fun fact, but were those drawn by people who can draw cows and humans, and aim to draw realistically? Middle Ages were quite a dip in art generally, AFAICT, with humans often not looking realistic, either.

Do you mean that cryptocurrency submissions were penalized that way? I recall them being about as annoying and similarly filling the front page with uninformative submissions, but have not heard of such penalties. Same as with other subjects during their hype waves.

And if you have JS disabled by default, it redirects to a page on a different domain name, so you cannot easily allow it in noscrpt just for that website, even if you want to. I gave up on that though; judging by the title, the article is going to be about modelling all the things as functions, as commonly and similarly done with other objects (e.g., sets, categories), which I wanted to confirm, and maybe to nitpick on this perspective and/or the title then (i.e., it is not quite correct to declare everything a function just because you can model or represent things that way).

I do store and update backups of public information regularly, since losing access to much of the Internet completely is not such a remote possibility here; many resources are blocked already, both proxying services and protocols are being blocked as well. Storing those backups together with personal data backups.

The things I store are those that seem valuable and information-dense, the kinds that I would be able to use in a relatively prolonged isolation. Storage space is limited, and redundancy is important for backups, so more copies of important information are preferable, to some extent, over added less important information. That is, one may consider tiered backups.

Wikipedia and Project Gutenberg, perhaps as OpenZIM archives (for Kiwix, making them more readily accessible), look like good starting points, along with other Wikimedia projects (e.g., Wikisource, Wiktionary; also available as OpenZIM archives). A music collection is a part of my personal backups. Then there are textbooks: OpenStax provides good ones under the CC BY license, LibreTexts books are of variable quality, but also worthwhile to look into, while WikiBooks are mostly disappointing. Then one may consider copyright-infringing book libraries, if one is fine with those. A few hundred gibibytes seem sufficient for a decent stockpile, including a good chunk of human knowledge, and providing plenty to do alone (read and study, that is).

Textbooks could be much more lightweight if their sources (e.g., in LaTeX) were provided, rather than PDFs, but unfortunately even for those under permissive licenses, usually only PDFs are available, which hinders both printing (as another form of backups) and regular digital data storage.

I expect the government will block software repositories among the last ones, so not backing up those yet, but mirroring, say, Debian archive (including sources) may be a good idea for such a situation, or when preparing for the Internet to go down.

If one has a lot of extra storage available, other easily available large data dumps to consider are Common Crawl, arXiv bulk data downloads, complete OSM data, huge copyright-infringing libraries, and videos: plenty of nice YouTube channels and TV series.

And I am okay with YouTube when a video makes sense, but in this case they have basically crammed a short article into a video, making it more awkward to read: slides with texts and diagrams, with some background music, and only a video demonstration in the end.

Last year, I went for an explicitly useless project of this kind, which would probably qualify as an "elaborate ASCII art generator": ray tracing into ASCII graphics, in Emacs Lisp [1].

Afterwards, after (or during?) AoC 2023, inspired by both that project and AoC, I wanted to work on something similarly fun and useless, and composed a RISC-V emulator in Emacs Lisp [2] (RV64GC, but with unfinished floating-point operations; emulates a few Linux syscalls, so can run some programs, like dash).

Other exploratory and educational projects tend to be pretty useless as well, but not always so explicitly, and then questioning their usefulness may spoil the fun.

[1] https://codeberg.org/defanor/3d.el/

[2] https://codeberg.org/defanor/rv.el/

> Your motion through the x dimension in space, for example, is completely independent of your motion through the other two (y and z) spatial dimensions.

If one considers motion at (or near) the speed of light, that speed would have to be shared among space dimensions, just as with the time dimension. So not that independent.

Neither does soft wrap play nicely with preformatted texts (e.g., ASCII graphics, including diagrams and ornaments such as titles centered with spaces, as well as formatted code).

And the support for soft-wrapping in tools varies: it may be completely unavailable, or just turned off by default, and generally unused in such a case.

I think reflowable text enters the area of markup languages, rather than plain text.

Not directly related to the article's message (though may count as collaborative "sanding"), but related to its UI: the page has texts centered (margin-left: auto, margin-right: auto, short lines), but paragraphs with embedded images lack that, and the images are aligned to the left. I thought it may be due to JS disabled (if it relies on JS for the layout somehow), but enabling it did not change that. Observed in Firefox 115; it is not the intended layout, is it?

Without JS, it does not show any content at all, but once you disable CSS as well, the contents show up.

Indeed, both are mentioned in the "programming" section, which I have either misread or skimmed over.

Edit: The options in the same paragraph are for different languages though (I saw those), but nevertheless it also mentions that they exist in general, including those for C. Well, it only mentions the official SDK for C, but hinting at more options still.

Strange to see an overview of network protocols in the guide, and a web server in the SDK: they are very generic, do not seem like any of that should be specific to ESP8266.

Edit: Removed two points of the comment that were wrong (as mentioned in a reply).

I guess you are considering the case where a single signer transfers commits over SSH to a single verifier, with both putting the same meaning into the act of transfer as people normally would into a signature. But git is a distributed VCS, with signatures handling many more scenarios: consider multiple committers and multiple signatures, transfer over multiple, different, untrusted channels, multiple verifiers.

And when font selection by a web page is disallowed altogether, it is rendered with my preferred font, but with a reduced font-weight, slightly increased font-size, and increased line-height. The low weight in particular, combined with it picking up the dark theme, makes the text rather uncomfortable to read.

I do not manage a mailing list, since the one I have set is not active, but I found Mailman 3 to be too resource-hungry, so went with much more lightweight mlmmj for mailing list management, and MHonArc for archiving. At least the initial setup is fairly easy with those, once you have postfix set. Probably not hard to set them with Exim, either, while Courier apparently includes mailing list functionality out of the box (though I have not tried that).

If one is not willing to get up, they can just sleep through the alarm, stash the phone (or other alarm device) somewhere, or turn it off (not restart); I doubt software can help much with those. I think the most efficient strategy is to decide that it is important to get up, and preferably to sleep enough in general. Well, maybe you can have software removing important files if it is not turned off, while not having a backup -- that would be an additional motivation, but that is rather extreme.

There are nice little headings in the video. But sometimes there are larger (multi-line, with paddings) headings, or simply broken ones (e.g., custom fonts with icons that don't load), and such headings are more annoying than useful to have sticky. Especially with pages that also show their headers and footers at all times, leaving little space for the content. Which makes it one of those features that should be used with care (while it is occasionally useful, and so is raising awareness about it).

I thought the non-evil phase of Google is commonly viewed to be considerably earlier, sometime before Gmail (2004). While the article mentions 2010 as still being in it. I wonder whether by 2040 somebody will lament the good old Google of 2024.

That aspect could be leaner, indeed, although all those processes put together can easily consume fewer resources than a single bloated program or a web page, especially if they do not include a particularly large DE. The systems I have in mind as references are Debian with Xfce (runs on an old Atom-based netbook, taking 600 MB of main memory altogether), or Debian on a server with a bunch of common services (web, email with related services, XMPP, Gopher, IRC bouncer, authoritative and caching DNS servers, etc), also consuming under 600 MB (under 400 without DNS cache), with CPU load coming mostly from fail2ban, but being pretty close to zero. On the other hand, there are KDE and GNOME, which would probably at least double that resource usage.

To be clear, I brought up GNU/Linux distributions as examples of container-free packaging, and as notable collections of relatively lean programs, but not necessarily as an example of the combined systems being particularly lean themselves. Though then again, compared to something like recent Windows versions, perhaps even the Linux-based systems with larger DEs would seem lean.

While I generally agree with the article, the "reality check" project seems somewhat forced: there are many widely used projects that are fairly lean. Many of the GNU projects are like that, not to mention explicitly minimalistic ones, and generally on a GNU/Linux system (either server or desktop) you have a few notable resource hogs, but the rest you would barely notice. Many of those can be built without Python build-time dependencies, too. And there are tens of thousands of proper packages in common distributions' repositories, so surely it is possible. The mentioned Electron, Node.js, and SaaS examples probably happen more often in certain other settings, perhaps enterprise software tends to be like that. Likely its advocates would bring up speed and cost of development, and it may be argued that even security is improved with those, given the other constraints. A more interesting "reality check" may be to take a few actual (and preferably somewhat widely used) bloated projects, and implement leaner alternatives, while fitting into the same constraints: similar profits for commercial projects, maybe similar initial expertise levels, time spent, and perceived impact for non-commercial ones.

Took me about a minute to identify it is a yo-yo (without reading any of the discussions), and they point out there that the official ball has a yo-yo for Y, so I am quite convinced that it is supposed to be a yo-yo as well. Just not drawn particularly nicely: the yellow bit is a cartoon string, the blue-and-white bit is the yo-yo's "body".

Edit: although now that I finished reading the rest of the investigation, there are quite a few arguments for "yxa" as well. Still seems like an odd coincidence to see a yo-yo there myself, and then to read that it is supposed to be a yo-yo on the official ball.

> This is very different from where we’re at today, where there’s one format: HTML

The part of the proposal it comments listed "pure ASCII", and surely we have plaintext files on the web as well. And all kinds of images, sound, video files, which are readily supported by common web browsers, out of the box. PDFs, too, which may contain hyperlinks that are active and handled by common web browsers. And even more if you count those handled by external programs (e.g., LibreOffice Writer must qualify as a "word processor", which is also mentioned in the commented part of the proposal, and then there are all sorts of other markup languages and formats, including those capable of hyperlinking further), web browser extensions, or don't restrict it to common web browsers.

I would like to rant about yet another website (book, article) on typography or accessibility worsening the typography and accessibility with their tweaks, and advising the reader to do the same.

The fixed font size and increased line height are uncomfortable and unnecessary: as a user, I have preferred ones set already. There seems to be such a trend among typographers (and maybe web designers), as noted multiple times at [1].

Then it places light gray text on dark gray background, but near pure white pictures, which make that text uncomfortable to read. With some odd bright icons preceding the image captions. Possibly it looks different with a light system theme (inherited by a web browser, handled by CSS media queries).

The thumbs-down icon near "Hard to read" text was hard to read, being pink on dark background.

As mentioned by others, a table of contents is missing for such a sequence of web pages.

As for the written advises, some of them sound sensible, but:

> It is preferable to use serif fonts in interfaces where there will be a lot of text information, such as articles, news, and long reads.

I find serif fonts very uncomfortable to read, especially for longer texts, such as books. Have read elsewhere (though probably also without much of a justification, but at least matching my own observations) that fonts without serifs are generally more comfortable to read, especially from a screen. Actually even this "book" appears to use a sans serif font, Inter (though I have custom font loading disabled, so seeing a sans serif font either way).

Then it proceeds to describe many other ways in which one can mess up fonts for users (choosing different sets of fonts, pairing them, tweaking their properties), but as an instruction, not a warning.

I would replace all that with the "do not mess with others' fonts" advice, and perhaps a similar one for colors.

[1] https://news.ycombinator.com/item?id=38226833

> Is this “because I can” or does XMPP fill a niche in modern text chat?

Not only text chat, but also audio/video calls, file transfer. And not sure if it is exactly a "niche", but it is a standard for a federated IM, quite widely supported. Probably the only comparable alternative now is Matrix, but that comes with a bunch of downsides.

> This feels like a step beyond running your own email server.

Running both XMPP and mail servers, I find that an XMPP server setup is easier: there are fewer components, less spam, fewer restrictions on federation; I think you can run it fine even with a residential ISP unless there is a NAT. Not that email setup is particularly hard though.

Looks good. A couple more things I find useful to set with Prosody are:

- The firewall module to blacklist spammers; that can be done with a system-wide firewall as well, but it is nicer for diagnostics to serve proper errors, not just to drop packets or refuse connections.

- The bosh and websocket modules, to use with converse.js. A web UI is convenient to have for logging in from systems without XMPP clients.

> I'd like to be a purist about email, but I just can't bring myself to care, because as long as my correspondent is a corporate whore, why shouldn't I be too? A copy of the email is going to end up on their servers anyway.

No immediate confidentiality is achievable by using a trusted mail server while interacting with untrusted ones, but doing what seems right often works as an improvement. I find it analogous to, among other things, not throwing garbage on the ground: by carrying it to a trash bin, you don't make all streets clean at once, and it may be an inconvenience, but once more people do it, streets do become cleaner. And even if others keep just dumping trash on the ground, it may be nice to know that you don't contribute to the unpleasantness. Likewise with a multitude of other areas, including good practices in programming and administration, good manners: it is unfortunate that not everyone follows them, offsetting the effort put by those who do, but it is not necessarily a reason to give up.

"My mistake that seemed to potentially cost up to $500M, but then it turned out fine" would be more accurate. While a more appropriate title would be something akin to "learning from mistakes" or "a Mars rover testing scare".

Docker keeps reminding me of people in the past shipping VM images, or sometimes physical machines, often with rather inappropriate desktop hardware and software. So do these points:

> The problem is the use of Docker as a lowest common denominator, or perhaps more accurately lowest common effort, approach to distributing software to end users.

Shipping physical machines probably is even lower than that though. Or even the VMs.

> One of the great sins of Docker is having normalized running software as root.

I am not as familiar with Docker practices, but unfortunately, AFAICT, people did that frequently on regular systems as well, just to not bother with permissions. (Edit: now I recalled people also not following the FHS and storing things in the root directory inside Docker images, but sometimes it was/is similar without containers as well, and inside a container it does not clutter the host system, at least).

> Having "pi" in the name of a software product is a big red flag in my mind, it immediately makes me think "they will not have documented how to run this on a shared device."

This approach is similar to shipping physical machines. Or at least maintaining odd legacy software on a dedicated machine.

I think a rather pessimistic view is that proper packaging switched to Docker or single-purpose machines, but an optimistic one is that those are the unnecessary VMs and larger single-purpose machines that were replaced by Docker and RPi. Maybe there is a little of both going on.