defanor

I saw it on HN before (and did not like that, either), while now noticed it in another submission by the same user, on a similar topic. [0]

Apart from that, as mentioned in another comment here, the article's content seems no less strange than the style.

[0] https://news.ycombinator.com/item?id=30358271

Looks like A and B are swapped in the "errorB vs. errorA" plot's description: in other places (and on the plot itself, actually) A is the noisy sensor, B is the occasionally-faulty one.

SVG feels much like HTML to me, especially when animations are involved: on the first sight it is quite nice and simple, does its job well, can be handled by fairly basic viewers (as well as converters, editors) and generated easily. Then there are even more features with CSS and JS, which also look neat, but then simplicity goes away, along with it goes the wide support of full functionality, and compatibility (due to partial support, unexpected behaviors in different contexts). It still looks like a fine option when animations are needed, but I would rather avoid those in SVG when they are not necessary.

I think an article like that would benefit from focusing more on protocols, rather than particular APIs to work with those: referencing the specifications and providing examples of messages. I am pretty sure that the article is about chunked transfer encoding [1], but it was not mentioned anywhere. Though possibly it tries to cover newer HTTP versions as well, abstracting from the exact mechanisms. In which case "JS API" in the title would clarify it.

As for the tendency described, this seems to be an instance of the law of the instrument [2], combined with some instruments being more trendy than others. Which comes up all the time, but raising awareness of more tools should indeed be useful.

[1] https://en.wikipedia.org/wiki/Chunked_transfer_encoding

[2] https://en.wikipedia.org/wiki/Law_of_the_instrument

> It's such a wild idea that I've never heard it in the public discourse.

IIRC there is a Dilbert comic strip about that.

> Clickbait [...] would become worthless overnight

Advertisement is not the only incentive. E.g., the Veritasium YouTube channel's host explicitly switched to clickbait, explaining it by his intent to reach a wider audience. Another example is clickbait submission titles on HN, not all of which are for the sake of advertisement (unless you count HN submissions in general as advertisements themselves, of course).

> When I say advertising, I also mean propaganda. Propaganda is advertising for the state

Not necessarily for the state, the usual definition includes furthering of ideas in general. In more oppressive regimes, propaganda of certain ideas is actually banned, as it used to be in even more places ("heresy" and suchlike). Combined with selective enforcement, it is as good as banning all propaganda. It may be a particularly bad example of such a ban, but still an illustration of the dangers around it.

I think a better path towards the world without (or almost without) commercial advertising is not via coercion, but as kaponkotrok mentioned in another comment, via education and public discussion (which may also be called "propaganda"), shifting social norms to make such advertisement less acceptable. People can make advertisements unprofitable if they will choose to: not just by ignoring them (including setting ad blockers), but also by intentionally preferring products not connected to unpleasant and shady tactics, including those beyond advertisement: slave labor and other human rights violations, unsustainable energy sources, global warming, animal cruelty, monopolies, proprietary or bloated software and hardware are some of the common examples. Social norms and such enforcement seem to be less brittle than laws are, and harder to turn into an oppression mechanism.

Although, since I brought up monopolies and other issues, perhaps state agencies may also usefully assist with restriction of advertisement, as they do with those. Social norms and laws are not mutually exclusive, after all.

I did not mean that there is a problem with it, only that I appreciate the simplicity of WHOIS. While HTTP-with-JSON is perhaps the most practical solution these days.

To clarify my point of view, an ad hoc HTTP client for this indeed should not be hard to write from scratch, demonstrating that there is not much complexity in that. The server part would be a little more tricky; still doable, but not as easily as for WHOIS, and in most cases a more sensible approach would be to use libraries (or a program like curl, in case of shell scripting or manual usage) for that, as you said. Likewise with JSON: though one can deal with it as with text, some added tools (a library or jq, depending on context) would be sensible to use. But then added dependencies lead to all kinds of issues in non-ideal conditions (e.g., when it is problematic to install those). But again, I am not saying that this should stop adoption of RDAP.

On top of that, a complete and proper HTTP 1.1 implementation, server or client, would be quite large. And JSON, while indeed common and not particularly complicated, still has bits I find awkward (no sum types or a standard way to encode those, but has "objects", arbitrary-looking primitive types; no single standard for streaming, either), so working around it is not exactly pleasurable. Those add up to a difference between a trivial protocol and, well, a non-trivial one. I appreciate such trivial yet working and useful solutions, though the other kind is commonly useful as well.

I like WHOIS with its extreme simplicity [0]. RDAP, on the other hand, works on top of a large and changing HTTP [1], and uses a JS-derived serialization format [2]. RDAP has advantages, such as optionally benefiting from TLS, the data being better structured and defined, but the cost in added complexity seems high.

[0] https://datatracker.ietf.org/doc/html/rfc3912

[1] https://datatracker.ietf.org/doc/html/rfc9082

[1] https://datatracker.ietf.org/doc/html/rfc9083

Indeed, that one would be more descriptive. At first I thought that the project is a joke about pretend-discovering that you can create a web page without tools other than a text editor, and without embedding external resources, similar to vanilla-js.com. I wonder whether "note" is readily understood as "a document edited in a WYSIWYG editor" by some, possibly because it is called that way in some software.

User experience with it, and opinions on it, seem to vary. I, for one, rather like both postfix and dovecot: both are well-documented, maintained, lightweight, reliable, yet configurable and feature-rich software, with few dependencies and good track records.

More than SMTP hosting, but I use a VPS for multiple online services, including SMTP. SMTP in particular is handled by postfix, OpenDKIM, policyd-spf. Its incoming mail part is additionally supported by uacme with knot, nftables, fail2ban, but sounds like you are not in need of that. 1 GB of main memory, 10 GB of disk space, and a bit of CPU is a comfortable (overkill, even) system to run a variety of services with a few users and without particularly bloated software, and I think it normally costs less than $5/month (or even under $1/month with occasional promotional plans), with plenty of hosting providers to choose from.

Edit: my current setup is documented [0], and the older (slightly different) one is linked from it.

[0] https://steady.mooo.com/~defanor/notes/simpler-server-setup....

Same, with Firefox on a Linux desktop, even after enabling JS.

Edit: apparently it uses Oklab/oklch() [1], which is supposet to work in Firefox since version 113, but does not seem to work in 115. Or possibly it also uses something else that breaks it.

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/color_value...

Same here (not certbot and containers, but the part about reusing certificates for multiple services): it feels wrong to couple certificate acquisition with a web server. Apparently it is convenient when there is just a web server out of TLS-using services, or at least when it is in the center of the setup and HTTP-based certificate acquisition is used, which seems to be a common enough case to justify this, but still an odd coupling in general.

As a counterpoint, I find custom formats to often be nicer than reusing generic ones: atomic values (individual lexemes, primitive types: strings, numbers, etc) tend to have custom formats or semantic restrictions anyway (say, dates, length-limited strings, range-limited numbers, though in some cases numbers are also just restricted strings), so that part is mostly handled from scratch either way. And then there is composition, with JSON--apparently the most popular format now--not having a standard way to encode sum types, so you basically have to hammer those on top. At which point it feels like building on top of a JSON structure instead of building on top of a sequence of characters, but not in a very different way: sometimes it is more helpful in some parts, sometimes adds more clutter than needed. Likewise with XML: it is not uncommon to see something like <my-custom-format>a string in a custom format here, or even a base64-encoded blob</my-custom-format>.

In practice it is easier to use JSON for interfaces, since for someone unfamiliar with parsing it is less work to sort out on the other end, and then you have at least a partially specified structure, the rest can be easier to specify (with JSON schema, for instance), there are readily available libraries and tools to work with it, to do at least some of the parsing without writing a parser. But I think cleaner interfaces can be achieved with custom formats.

It is one of the proposed mechanisms, but apparently it is still unclear what is actually used [1,2].

[1] https://en.wikipedia.org/wiki/Magnetoreception#Proposed_mech...

[2] https://www.scientificamerican.com/article/how-migrating-bir...

As a satire, it does look amusing: the "professional" versions are about as rude as "unprofessional" ones, but the wording in those makes it more annoying (and perhaps condescending), "adding insult to injury". Perhaps one could also slap random emojis onto those, like in its README's headings, and follow with over the top valedictions, to push it even further.

As an option that still uses HTML, with relatively minimal and common dependencies: the unified header and navigation insertion, as well as other aspects of website generation and syntax checks, can be handled with XSLT. Or one may employ a generic macro processor like M4, which should be fairly easy to set to convert LaTeX into MathML, as well as to include shared headers.

A few things in it that I would not put into a beginner's (or any) guide:

- Semantic tags (header, footer, main, section): machine-readable semantics can be fun to play with if one is so inclined, one can go even for RDFa, but AFAICT they will not do anything visible or useful, especially for a small beginner's website, but they complicate the guide.

- CSS: the page itself uses low-contrast pink text on a pink background, which is hard to read (and goes against W3C accessibility guidelines, which can be checked with one of the online contrast checkers as well), and provides similar low-contrast examples. It also makes links bold on hover, which moves the texts that follow them, and which is annoying.

- Viewport meta tag: this can be controversial, I think, but the tag itself is rather a hack to tell a browser "this page is not too broken, it can be rendered with a legible font size without breaking the markup". Teaching beginners to repeat that feels wrong both as promotion of such bad browser behavior, and as a road to potential misuse even of that (and the next version of the guide will have to include a new "this page really is not broken" invocation).

With search engine results polluted with "AI slop" (often long-winded and useless articles, not answering the questions; a relatively advanced SEO spam), I notice that Stack Exchange websites are among the good ones now: if there are answers, they tend to be decent. It is disappointing to see it heading that way, though commercial projects tend to fall into something like that (if not slop, then ads, feature creep, UI bloat/annoyances/captchas, "enterprise" and any hyped stuff, paywalls). SE had its issues before as well, but even if it will become unusable, there is a potential for better Q&A places in the future, maybe federated ones. A quick search did not reveal any projects like that though.

In section 5.7:

> But in this section we’re going to be talking about a specific kind of merge: the fast-forward. This occurs when the branch you’re merging from is a direct ancestor of the branch you’re merging into.

Looks like "from" and "into" are swapped: "main" is "into" there, "newbranch" is "from", and "main" is a direct ancestor of "newbranch".

I guess that authoring in MathML, and rendering MathML into images for browsers that do not support it, would have helped to avoid the mentioned inconsistency.

> So we did that for a bit much to the annoyance to developers. Then we started emailing them to see if they wanted to chat- I can't speak for you, but a lot of people in our book didn't reply.

This looks like an amusing misunderstanding in both directions: I did not check the linked previous blog post until now, and interpreted it as developers disliking to use email to contact you, but apparently what you mean is that you contact them, for no important reason. I would not just ignore such an email, but probably would treat it as spam, and this sounds like the kind of thing some people dislike email for.

> It gives us 50x better engagement than email and 8x better response times to customers.

Does it mean that it forces the customers to send 50 messages instead of a single mail message?

> However, developers hate email.

Always feels awkward when there are general statements about the group you belong to, which are certainly false at least for you, and possibly for most others you know in that group.

If anything, I would expect developers to dislike a web chat, as tech-savvy people generally seem to prefer more lightweight and customizable options.

> That context helps Railway Engineers deliver a truly first class support experience.

Much of the post reads like a rather annoying advertisement.

I was curious why it was a problem to support thousands of customers in the first place, and looks like the issues were in combining conversations over different communication channels, and that a single overloaded person used to create those Slack chats.

For libre options available from Linux distributions' repositories, see isync (aka mbsync) and offlineimap. And mail clients in general should be able to handle IMAP and standard formats (Maildir, mbox). If one cares about mail backups, it is also useful to archive and backup one's mail in one of those standard and portable formats, and/or to synchronize between multiple machines regularly.

Not exactly accessibility features, but a more general usability, even for people without disabilities. I personally noticed the lack of a scrollbar when I wanted to check how far through the article I am, but another common use case for those is to actually scroll through the document (particularly for skimming of larger documents, for which mouse wheel, space bar, or Page Down key are too slow, or in more rare situations when they are not easily available).

Unfortunately tinkering with visual presentation tends to conflict with the principle of least surprise, user settings, or even basic functionality.

The DEs it uses are GNOME and KDE, which are as far from "simple" in that sense as one can get on Linux-based systems: the two largest (and perhaps most widely criticized for being buggy and bloated) DEs. While the use of uncommon (non-GNU) userland sounds like a stream of unusual issues to debug, adding up to a strange combination.

Though probably not counting the DEs as an important part of the system (and maybe they have other DEs or WMs in the repositories), one may argue that the non-GNU userland is simpler in a sense. But then again, it is presented here as a simplified desktop, while GNOME-based and KDE-based systems are on the images it provides. And it lists GNOME as its primary DE [1].

[1] https://chimera-linux.org/docs/

Indeed. I was about to write about it to the author by mail, but noticed that he posted this link, and probably will read these comments, so can as well provide the feedback by joining this subthread: at least a few readers are not happy about our scrollbars being hidden.

Unless the precision (resolution) is known (stated), it is unclear whether the trailing zeroes are significant or not, one may only guess (while such a guess looks reasonable in this case). A convention for writing that unambiguously is to avoid insignificant trailing zeroes: e.g., writing it as 26e2 or 2.6e3. Then the written number carries along its precision.

A few more, which seem to be used somewhat commonly:

- Emacs clients: built-in rcirc and erc, non-built-in Circe.

- irrsi (standalone TUI)

- Quassel IRC (GUI; have not tried it myself, but saw others using it).

- mIRC (GUI, for Windows).

I think it is about as varied as communications outside of IRC: there are different communities with different rules, which are sometimes written down and linked from the channel topic. Generally hanging around quietly for a bit may help to get a sense of any particular community's customs.

AIUI, the "Decentralized" added to RSS here stands for:

- Propagation (via asynchronous notifications). Making it more like NNTP. Though perhaps that is not very different functionally from feed (RSS and Atom) aggregators: those just rely on pulling more than on pushing.

- A domain name per user. This can be problematic: you have to be a relatively tech-savvy person with a stable income and living in an accommodating enough country (no disconnection of financial systems, blocking of registrar websites, etc) to reliably maintain a personal domain name.

- Mandatory signatures. I would prefer OpenPGP over a fixed algorithm though: otherwise it lacks cryptographic agility, and reinvents parts of it (including key distribution). And perhaps to make that optional.

- Bitcoin blockchain.

I do not quite see how those help with decentralization, though propagation may help with discovery, which indeed tends to be problematic in decentralized and distributed systems. But that can be achieved with NNTP or aggregators. While the rest seems to hurt the "Simple" part of RSS.