> only a fraction of the population would ever want the super fast typing
I think the primary motivation for using non-qwerty layouts is comfort, not speed. Though perhaps it only really becomes relevant once one actually learns the layout (touch typing, with all the fingers), and AFAICT not a large fraction of people does that, even with qwerty.
Or the holes can just be staggered (so that each hole is at an unique angle): then the rings won't have to rotate separately, though the reading would have to be more precise/higher-frequency then, and it may be tricky to rotate the dial with a finger as precisely (with 6 rings and 15 mm per hole, that would be a 15 / 6 = 2.5 mm margin, roughly).
I think the most straightforward way is to have a separate usual mechanism for each ring, stacked vertically, passing the rotation from each ring through the inner ones without rotating them. But likely something nicer (more optimal) can be designed: either purely mechanical (to end up with just a single combined rotation on the output) or relying on more modern technologies (plenty of options on reading dial positions then).
The holes on my rotary phone are about 1 cm. One can make them nested, since it would have to be custom anyway: starting with the diameter of, say, 3 cm, adding a bit more than 1 cm on each side (3 cm, 4.5 cm, etc), and assuming that at least floor (pi * (1.5 + 2.5 * n - 2) / 1.5) keys fit in the nth such nested ring (1.5 + 2.5 * n is the outer diameter, - 2 is there since the holes won't be on the outer diameter, / 1.5 cm is to leave some space around them; that's not meant to be optimal, just a quick estimate), that'd yield 101 holes/keys with 6 rings, with the outer diameter of 1.5 + 2.5 * 6 = 16.5 cm for the last one. That's a rather small keyboard.
Edit: nested rings would also work for modifier keys.
That's roughly my first thought too: the project seemed like pubsub with message authentication and without federation. Was about to bring up "Atom and RSS, mailing lists, NNTP, XMPP, ActivityPub, Matrix" as examples of existing protocols capable of that (to a different extent, and usually with more functionality), thought to add Mastodon to the list of examples too, but the README already mentions that Mastodon is undesirable because of the dependence on domain names/administrators (and elsewhere mentions undesirability of running servers by users, of having many servers, while considers simplicity from the point of view of in-browser JS, apparently), that the servers aren't run well, and so on; seems pretty opinionated and enthusiastic about this protocol, so I guess those existing protocols won't satisfy all those requirements either.
Initially restrained from posting it, since it's possibly rather grumpy, and the authors seem to have fun with the protocol, but here it is.
I had to allow JavaScript execution in order to read this rant about ads, and the website used that to present the "Black Friday starts now" modal popup/ad (which managed to get past uBlock Origin). Briefly wondered whether it's a part of the rant/article, but apparently it wasn't. Not exactly the same thing as it rants about, but still an odd combination.
Not seeing a date on the website beyond the recent file modification date of the file, but just today I was looking into video streaming (MJPEG over HTTP) from ESP32-CAM, and it's actually in the Espressif's examples for it [1]. Apparently there are web server projects for it around [2], too; would be rather surprising if the first such website appeared only recently.
Edit: though maybe ESP32 SoCs with RISC-V processors aren't that common among those other ESP32 ones.
I don't know about this project, but OSM data included information on levels for a while (and it was used, in addition to just being there: e.g., in JOSM you can switch between levels for editing; not sure if I saw 3D rendering of OSM data before, but that's possible). While this looks like a demo by a commercial company selling "Interactive Map Solutions": not major news about OSM itself, but may be amusing to poke.
I learned about two-spacing only in my 20s, initially thinking that it's interesting but not very useful. Now it just looks like a cute topic to argue about and to have a strong opinion on, or to speculate about conspiring two-spacers, while being generally harmless. Unlike tabs or inferior text editors. As if all the important issues are solved, tabs are eradicated, and it's left to argue about the number of spaces.
Those are defined for multiple common screen widths, without taking the scroll width into account, so at those points the horizontal scrollbar appears.
Indeed, I spotted a couple of typos too: "This book is free/libé", "to provide detaile information".
Also noticed that foreground colors are defined in the HTML version, while the background color isn't, and the blockquote foreground color doesn't meet the AAA level of WCAG contrast guidelines even if white background is assumed. That's rather nitpicky, and generally it's fine, but it feels like materials on UI and UX should better follow common guidelines.
I do browse with JS off by default (usually FF with noscript, though occasionally with simpler web browsers), often leaving pages if they require JS while they shouldn't and I can avoid those, and I know others who do the same.
Maybe a poll would be more suitable for this kind of a question though, and I guess there must be some already collected statistics around.
Edit: Speaking of "LiteMode" and accessibility in general, I think it's also nice to not go too heavy on CSS or assumptions about fonts. I used to override CSS (browsed quite a lot in the dark, so enforced a light-on-dark theme), to use textual browsers, and still disabling web fonts and setting a minimal font size, which occasionally leads to slightly messed up markup and related issues. Though those sorts of things tend to be covered in various accessibility guidelines.
Those invariants look to me pretty much like additional constructor arguments in languages with dependent types. Which both do "Make Illegal States Unrepresentable" and can provide "natural" ways to represent the data, along with the additional arguments (those proving the desired properties).
As a bit of anecdata, I received a spam message from SendGrid about 3 weeks ago (while just a few spam messages per year make it through), and that's how I've learned about them. But I guess they won't stay out of DNSBLs for long if the portion of spam messages will be particularly high.
Not sure about the support in mail clients (I mostly use mu4e with mbsync, I don't think they can look those up), and they certainly aren't required. But I set them anyway, along those for XMPP (where they should be set), and it's potentially useful. Similarly to setting TLSA, SSHFP, CAA records: those are rarely used, but they do seem nice to me, and it shouldn't harm to provide clients with such an option. Also the more servers provide it, the more motivation there is for clients to support it.
The link to part 3 from part 2 is broken (but the one in ToC works).
It doesn't mention reverse DNS (PTR for *.in-addr.arpa) records. Though not strictly necessary, but doesn't harm to have those set, and the author's mail server has those set.
Looks nice overall. The notable differences from how I set those are the lack of postscreen (including its greylisting), of a dedicated submission port, of SRV DNS records (_submission._tcp, _imap._tcp, _imaps._tcp), but presence/use of virtual hosts and users, and of OpenDMARC. Maybe I should try using the latter, though not sure how useful it is (whether it's worth the slight complication of the overall setup), when set on a small/low-traffic mail server.
But most of the email recipients (and senders too) don't use ProtonMail either, so those won't be encrypted, and then ProtonMail can still turn over the messages. The ideal situation with this approach is that everyone uses ProtonMail (no decentralization at all), to have everything encrypted. While the ideal situation with OpenPGP is that everyone uses that, which allows for multiple independent mail servers.
Edit: or do they perhaps not store sent messages (that is, they have to queue them, and attempt resending on failure, but beyond that), and/or encrypt incoming ones with the user's public key upon arrival?
Edit 2: apparently the stored messages are indeed additionally encrypted by ProtonMail [1]. That looks useful.
Edit 3: now I wonder why not to do that with OpenPGP too.
Edit 4: looked around, apparently some do that. [2]
AIUI it is, but that's achievable with generic setups (using OpenPGP for encryption, often GnuPG) and between any mail servers as well, in a standardized way. I think the ProtonMail's argument is that they make it the default for communication between their clients, while OpenPGP is not used commonly. But to benefit from that, all the involved users should use ProtonMail, which is contrary to decentralization.
I find ProtonMail odd too, especially in context of better decentralization, for them (AFAIK) not supporting regular client-to-server protocols (without the bridge software) and doing that reinvented encryption which only works between its clients, but as for account cancellation, it does seem to happen with others too: there are regularly appearing stories about Gmail/Google accounts being blocked with no way to contact the support, occasional services (like Opera mail) just shutting down, some seem to take your mailbox hostage demanding more of PI.
The "harder" argument is the regular deliverability uncertainty, while the "easier" one is availability of some less known and supposedly user-friendly software projects. I doubt they make it easier in the long run though: as with much of other new and supposedly user-friendly software, it's tempting to recommend that to new users (and they may prefer it anyway), but then all sorts of issues arise: often it's not in system repositories, so no updates (no automated/frequently happening in practice ones, that is), and there are occasional semi-broken manual installations, then there's a lack of documentation and community, probably it'll be abandoned in a few years, and generally you get all the characteristics of experimental/immature software, where you need more advanced skills to debug and maintain it than those needed to just use mature software. Throwing that onto new users, over the much more mature software, doesn't look like a good idea to me.
> I might write an article "Articles \"X considered harmful\" considered harmful".
People were annoyed by those and wrote such an essay at least 20 years ago [1,2] (possibly there were others). Didn't help much, but generally fighting idioms/memes/fashion doesn't seem quite productive: perhaps it's more useful to focus on not being frustrated by those (and accept the way this phrase is used).
Edit: Though ranting about titles on HN is still a fine activity, not trying to discourage that. Just an idle musing on being more content with those.
It seems that they also collect email addresses directly from git repositories: my email address isn't publicly visible on GitHub (in the user profile, that is) or similar services, yet spam with those developer-related products still arrives sometimes (e.g., some kubernetes-related "napptive" thingy, postgrest-related "subzero"). Asking spammers to stop spamming probably won't have much of an effect though.
After hours of searching, it is annoying when the reply is something like "does this chat look like Google to you?" (though fortunately those are pretty rare), but the answers trying to teach you how to discover answers to your original question are closer to "teaching a man to fish", or the Socratic method: you'll probably discover the answer soon (possibly with additional help), and will be able to discover similar ones in the future.
That approach is both more educational and may be easier on helpers themselves; answering the same (or very similar) questions, often from the same people, isn't particularly fun or productive.
> and only priests that specifically worship Hat can cast the spell that teleports you to the location of a random other player on the server
Actually anyone except for witches and wizards can use that ritual with a faith rod, as well as regular passaging (Divine Hand). And to add a few more methods:
- The JPCT wizard spell (magic portals) is another common method of travel, available to anyone via scrolls (but more easily for wizards, who can remember it).
- There's arcane transport for faster (though more expensive) travel, compared to carriages, especially between continents.
- Some use L-space for travel, or follow Khepresh (an NPC Hat priest who visits random players).
- The taxi system, with players moving other players around (for a small payment, free for newbies). 5 taxis online at the time of writing.
- "Speedwalking" (client-side routing) is commonly used as well.
Indeed, my bad, and it makes more sense upon re-reading it with just SPAs in mind (instead of picturing/comparing a modals-heavy SPA and a regular bunch of pages). I just have a strong association of modals with SPAs, but they don't necessarily go together.
I'm annoyed by modals on web pages (along with any excessive JS) as much as the next person, but:
> What's the difference between a dedicated page that has a link "return back to the table", and a modal that you cannot close by clicking on the overlay. And the only way to close it is by clicking the close button/icon which in fact returns you back to the table as well?
I think they tend to happen because (for whatever reason) people make SPAs, which is precisely about having everything on a single page; then opening a new one is slow (thanks to multi-megabyte JS) and contrary to the whole approach. And when you propose to avoid SPAs, it's met with "but Google does that", "that's modern", and so on.
Edit: Actually I've misinterpreted the article (and "dedicated page") and mixed up modals with SPAs, as pointed in one of the replies.
Sorry for being grumpy, but over time it becomes rather frustrating to see projects like that. The problem I encounter with recipes is that sometimes it's hard to find properly written (and preferably overall nice) ones: not just that units of measurements tend to be odd, but they often use volumes where you'd expect weights (particularly for baking), or don't mention important parameters (like vinegar solution for pickling, where it's commonly recommended to follow recipes exactly, precisely to get the acidity right), or would sometimes include odd/unexpected steps/proportions without an explanation. Yet the "solutions" I keep seeing are just some overengineered languages/formats/databases/websites, and I'm unsure what they are even supposed to achieve (except maybe for some monetization for its authors, or being a fun or educational project, which is good, but still not useful for potential users). This one just lists regular startup buzzwords, and the website seems to be quite broken in FF even after allowing JS. If we had one properly written Wikimedia Cookbook recipe instead of each one of those custom cooking/recipe projects, I guess there would be a rather comprehensive cookbook by now.
And large subnets were blocked back then, blocking many unrelated websites/services at once. IIRC even some of RKN's own services were temporarily disrupted by that, but generally they don't shy away from inflicting collateral damage. There's no shortage of cases of blocking large websites for humorous or silly pictures and texts (not even political), too.