HN user

jech

188 karma
Posts8
Comments97
View on HN

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.

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.

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

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.

On average, proprietary programs are not better than open-source programs, but usually worse, because they are reviewed by fewer people and because frequently the programmers who write them may be stressed by having to meet unrealistic timelines for the projects.

There's also the fact that when you write open-source code, you're writing for a friendly audience. I've often found myself writing the code, letting it rest for a few hours, then rewriting it so that it is easier to read. Sometimes, the code gets substantially rewritten before I push.

There's no cooling period when you write code during your 9-5 job: it works, it has the required test coverage, ship it and move on to the next task.

Alternate app stores are still allowed. It's just that they are restricted to applications signed by developers who have paid a tithe to Google.

Google are obeying the letter of the law, while openly violating its spirit. Perhaps it'll be possible to attack them in court, but it will take years, and by that time they'll have found another trick.

I’m aware of alternate mainframe OSs but I’m not sure how common using one was.

Extremely common at major universities and research centres. CTSS, ITS, TENEX, Multics, Unix and even VM/370 were all alternate operating at some point.

Other than OS2, alternate OSs for other systems were rather rare,

You weren't there, were you? A lot of people replaced MS-DOS with DR-DOS before Microsoft deliberately broke it with Windows. A little later, a number of people were running Unix System V on their PCs, to the extent that there was a regular column about Unix in Byte.

how does [100BASE-TX] save power vs [1000BASE-T] running at low throughput?

100BASE-TX uses just two pairs (lanes), one for sending and one for receiving. 1000BASE-T uses all four pairs, for both sending and receiving. Therefore, a 100BASE-TX interface that's only receiving needs to power up one pair. A 1000BASE-T interface needs to power all four pairs all the time.

I recall reading about some extensions that allow switching off some of the pairs some of the time ("Green Ethernet"), but I think that they require support on both sides of the link, and I'm not sure if they are widely deployed.

> You could have messaged an entire organization or department

This is a mailing list.

The way I understand it, the layering is different. In X.400, multicasting was a feature of the protocol. An SMTP mailing list, on the other hand, is an endpoint that terminates a protocol transaction, and then initiates one transaction for each final recipient.

I guess it boils down to where it is preferable to have the extra complexity: the ITU-T protocols invariably prefer to put it inside the network, while the Internet protocols prefer to put it at the endpoints. The SMTP protocol is simple, and therefore the mailing list software needs to be complex.

IETF wants a working open source implementation before standardising.

I don't think that's IETF policy. Individual IETF working groups decide whether to request publication of an RFC, and the availability of open source implementations is a strong argument in favour of publication, but not a hard requirement.

If the IETF standards are sometimes useful, it's more a matter of culture than of policy.

The ecosystem. The language is lovely, but dune/opam is not up to the standard of the Go or Rust build systems, and the set of useful libraries is somewhat skewed. Whenever I write a program in Caml, I gain an hour thanks to the nice language, and then lose two fighting with dune/opam.

There's also the support for concurrency and parallelism, which has started to improve recently, but is still years behind what is available in Go (but still better in my opinion than what is available in Rust).

You left out most of the interesting things. For example the vocative case is partially dissapearing.

The grammar is changing in many ways (for example, the inanimate masculine is being replaced with the animated, kroić kotleta), but this was about honorifics.

> Poland has honorifics that are probably on par to those in Japan

I'm interested in learning more about this!

It's very simple, actually.

For strangers, you use the third person and the title « Pan » or « Pani » (Sir or Lady). You avoid pronouns, « The Lady has forgotten the Lady's purse on the table ».

For friends, you use the t-form ("ty", thou), and use a diminutive rather than the full name. « Johny, you've forgotten your bag on the table ».

For work colleagues, you traditionally use « Pan » or « Pani » with the full form of the first name. « Mister John, the mister's bag is on the table ». This is perceived as old-fashioned, and is increasingly being replaced by the t-form.

The v-form has fallen into disuse, as it was promoted by the Communist regime.

(The old-fashioned honorifics still exist, but they are only used in administrative correspondence: the only time when you're "the respectable gentleman" is when you need to pay taxes.)

« I've been pulling public records on the wave of "age verification" bills moving through US state legislatures. IRS 990 filings, Senate lobbying disclosures, state ethics databases, campaign finance records, corporate registries, WHOIS lookups, Wayback Machine archives. What started as curiosity about who was pushing these bills turned into documenting a coordinated influence operation that, from a privacy standpoint, is building surveillance infrastructure at the operating system level while the company behind it faces zero new requirements for its own platforms. »

So far [Galene is] much better than I expected, both in terms of latency and the overall video/audio quality

Latency is better, since Galene uses an unordered buffer instead of a jitter buffer. Lipsynch should also be slightly better, as Galene carefully computes audio/video offsets and forwards the result to the receiver so it can compensate.

Audio and video quality, on the other hand, should be roughly the same, unless Jitsi is doing something wrong.