jech

> their design isn't particularly better than the others

Well, to be fair, they occasionally make rather nice hardware.

For my usage, the reason the Linux-on-Mac efforts are useful is that Apple hardware becomes easily and cheaply available once it is no longer supported. My home server is an old Mac Mini (GigE, HDD + SDD, double core Haswell, 7 W power envelope, doesn't take up space, silent) running stock Debian. When it dies, I'll probably be able to replace it with an M2 model, thanks to Asahi and friends.

> In terms of provenance there is a significant difference between "I wrote this." and "I found this."

That's very well put. I'm stealing your wording.

> According to the Wikipedia chart it can max out at ~300 Mbps depending on modulation

Note that the MM8108 (the chip supported by Linux) is a single-stream (no MIMO) 8 MHz implementation. So it's limited to 43.3 Mbit/s at the link layer. Which is still pretty cool, but nowhere near the figure you quote.

This benchmark only measures function call overhead, which is important but not the whole story. What kind of figures do you get with a more realistic benchmark?

> you have to spend an hour or two after install [...] Then you have practically zero nags.

And you see no problem with that?

You mean the only people innocent are the Russians?

From the article:

« Daniil, a university student in St Petersburg, said he reluctantly downloaded Max shortly before the start of the academic year after being told students would be denied access to university buildings or dormitories without a QR code generated through the app. »

> TIL that MacOS `pwd` has `-P` and `-L` options.

Interestingly, it wasn't designed to deal with case, but to select whether to resolve symbolic links:

    $ cd /tmp
    $ mkdir a
    $ ln -s a b
    $ cd b
    $ pwd && pwd -P
    /tmp/b
    /tmp/a

> C really isn't as great for this as is often suggested either, not for decades at least

It's good enough for undergraduate teaching. In C, you can easily explain the relation between a struct definition and its layout in memory. It's much more difficult in Caml (what's the relation between an algebraic datatype and its layout in memory?) or Java (which introduces pointers that you never asked for).

We (University of Paris-Cité) are teaching Java in first year, then C and Caml in second year, with seemingly good results.

> https://fail2zig.com

Thanks. I've had a quick look, and it looks like it's a drop-in replacement for fail2ban (it claims to parse fail2ban's configuration files unchanged), except that it doesn't require a Python runtime.

I haven't tried it, since I'm currently happy with sshguard. I'm keeping the link handy in case I find I need more features than what sshguard provides.

> Only 30% of Americans approve of him.

He got elected with 49.8% of the popular vote, even though he had already been in power and people knew reasonably well what his policies would be.

One hour later, it appears that sshguard is working fine. It's structured as a dozen binaries or so, but it has no dependencies. I haven't done any CPU usage measurements, but I haven't seen it appear in top's output.

> sshguard is exactly this

Thanks. I've replaced fail2ban with sshguard on one machine, we'll see how it goes.

I stand corrected, CoMaps can do tracking. It was introduced in Organic Maps a couple of years ago, but I was already using OpenTracks, so I never switched away from it.

I've found that websites specific to a single European country or, in the case of France, to a single city are the ones that work best.

> It has more features but is slower and clunkier

Just to clarify: OsmAnd has more features, CoMaps and Organic Maps are much faster.

(Aside: I'm using CoMaps myself. The main missing features are tracking (I use OpenTracks for that) and public transportation (I use a website for that). End of aside.)

> Transferring files shouldn't involve that central server, so you'd need to establish a direct connection between the users

That's exactly what Galene does when a user requests a file transfer.

> with network topologies those days, it will most likely require a relay between the two

We perform NAT traversal by using the server to punch holes in both NATs. Only if that fails (due to a symmetric NAT or to an overly restrictive firewall) do we fall back to relaying through the server.

Nice design, but that's the kind of functionality that's best integrated within a chat or videoconferencing application, since within a conference you can be pretty sure that you send the file to the right person.

For a demo, go to <https://galene.org:8443/group/public/hn/>. Login twice in two different browser tabs (leave the password field empty). Click on the username of your partner, and choose Send file.

> Would you treat an image of the US House of Representatives the same way?

No. The right analogy is an image of the Reichstag with Nazi banners.

> There are plenty of legal uses for a fully automatic AR-15

Such as?

> UTF-8 is not locale independent.

The encoding itself is locale-independent. Some algorithms (rendering, casing, hyphenation etc.) depend on the locale.

This is unlike the older paradigm, where the encoding itself was dependent on the locale, making things like copy-paste between applications running in different locales problematic.

That was a long time ago.

Traditionally, character's under Unix were encoded in a locale-specific manner: ISO 8859-1 in Western Europe, ISO 8859-2 in Eastern Europe, EUC-JP in Japan, etc. In the 1990s, there was a major push to get XFree86 (the ancestor of X.Org) to switch to locale-independent UTF-8, lead mainly by Markus Kuhn and Bruno Haible.

The link is to Markus Kuhn's web page, which appears to describe the UTF_8 software available around 1998 or so.

> we had many publications about it

I'd be interested in learning more, but the links you provide are just advertising copy. Could you please provide links to actual technical articles on your conclusions?

That's not my experience. Users naturally get frustrated when I break the software that they rely upon, and sometimes they use strong words, but the resulting conversation is almost always friendly and productive. (There are exceptions, of course, but that's life, right?)

Here's a recent sample, paraphrased for brevity:

Them: this is broken.

Me: no, it's not broken.

Them (a few days later): "I think I must not have tried all the combinations", followed with two pages of transcripts.

Me: "I've just checked the code, and you're right [...] I'm extremely sorry I wasted your time."

Them: "Heh, it's all good. I'm am chuffed you're taking the time to give thoughtful responses with me"

Source: https://github.com/jech/galene/issues/309

It will probably depend on whether NPUs are universally available in smartphones, and whether we get a standard API for accessing NPUs. But I don't know whether AI-based codecs can have battery usage competitive with fixed-function hardware.

> One of the interesting usage of AV1 was specifically for low bitrate calls, and software encoding was perfectly fine, even on mobile.

You really want hardware decoding on mobile, otherwise you end up with 40 minutes battery life. Fortunately, for typical videoconference resolutions, VP8 and H.264 are just fine. AV1 is nice to have, though, due to excellent support for synthetic content (screen sharing), and for scalable video coding (a much more elegant solution than simulcast, IMHO).

In the world I live in, the general plan is to stick to VP8 and H.264 for the time being, and to skip to AV1 when it's universally available on mobile. I haven't seen any features of AV2 which would justify waiting for it.

> For most people, 500M is probably fine. But once you have a few family members, each streaming 4K movies to their devices,

You must have a very large family. To saturate 500Mbit/s, you'd need around 30 family members all streaming at the same time.

> Then I got a manual audio cassette recorder and thought "Woah, I don't think it gets better than this!"

That's not how I remember it. By the time we got data cassettes, we knew very well that floppies were the future.