Atemu

Somewhere inside that abstraction you’ll need to have the pieces of info that Spanish “leche” [milk] is feminine, that Zulu “ubisi” [milk] is class 11, that English predicative uses the ACC form, so goes on.

Of course you do. The beauty of abstraction is that these language-specific parts can be factored into generic language-specific components. The information you're actually trying to convey can be denoted without any language-specific parts or exceptions and that's the important part for Wikipedia's purpose of knowledge preservation and presentation.

you'll need people to mark a multitude of distinctions in their sentences, when writing them down, that the abstraction layer would demand for other languages. Such as tagging the "I" in "I see a boy" as "+masculine, +older-person, +informal" so Japanese correctly conveys it as "ore" instead of "boku", "atashi, "watashi" etc.

For writing a story or prose, I agree.

For the purpose of writing Wikipedia articles, this specifically and explicitly does not matter very much. Wikipedia strives to have one unified way of writing within a language. Whether the "I" is masculine or not would be a parameter that would be applied to all text equally (assuming I-narrator was the standard on Wikipedia).

Even the idea of "abstract concept of milk" doesn't work as well as it sounds like, because languages will split even the abstract concepts in different ways. For example, does the abstract concept associated with a living pig includes its flesh?

If your article talks about the concept of a living pig in some way and in the context of that article, it doesn't matter whether the flesh is included, then you simply use the default word/phrase that the language uses to convey the concept of a pig.

If it did matter, you'd explicitly describe the concept of "a living pig with its flesh" instead of the more generic concept of a living pig. If that happened to be the default of the target language or the target language didn't differentiate between the two concepts, both concepts would turn into the same terms in that specific language.

The same applies to your example of the different forms of "I" in Japanese. To create an appropriate Japanese "rendering" of an abstract sentence, you'd use the abstract concept of "a nerdy shy kid refers to itself" as the i.e. the subject. The Japanese language "renderer" would turn that into a sentence like ”僕は。。。” while the English "renderer" would simply produce "I ...".

A language is not an agent; it doesn't "do" something. You'd need people to actively insert those pieces of info for each language, that's perhaps doable for the most spoken ones, but those are the ones that would benefit the least from this.

Yes, of course they would have to do that. The cool thing is that this it'd only have to be done once in a generic manner and from that point on you could use that definition to "render" any abstract article into any language you like.

You must also keep in mind that this effort has to be measured relative to the alternatives. In this case, the alternative is to translate each and every article and all changes done to them into every available language. At the scale of Wikipedia, that is not an easy task and it's been made clear that that's simply not happening.

(Okay, another alternative would be to remain on the status quo with its divergent versions of what are supposed to be the same articles containing the same information.)

Languages simply don’t agree on how to split the usage of words. Or grammatical case. Or if, when and how to do agreement.

Just for the sake of example: how are they going to keep track of case in a way that doesn’t break Hindi, or Basque, or English, or Guarani? Or grammatical gender for a word like “milk”? (not even the Romance languages agree in it.) At a certain point, it gets simply easier to write the article in all those languages than to code something to make it for you.

I don't know what the WMF is planning here but what you're pointing out is precisely what abstraction would solve.

If you had an abstract way to represent a sentence, you would be independent of any one order or case or whatever other grammatical feature. In the end you obviously do need actual sentences with these features. To get these, you'd build a mechanism that would convert the abstract sentence representation into a concrete sentences for specific languages that is correctly constructed according to those specific languages' rules.

Same with gender. What you'd store would not be that e.g. some german sentence is talking about the feminine milk but rather that it's talking about the abstract concept of milk. How exactly that abstract concept is represented in words would then be up to individual languages to decide.

I have absolutely no idea whether what I'm talking about here would be practical to implement but it in theory it could work.

A really, really cool solution for problem nobody has.

Do you have a media center and/or server already? It's a bit overkill for the former but would be well suited as the latter with its dedicated GPU that your NAS might not have/you may not want to have in your NAS.

Glad I could save you some money :)

I can see where you're coming from but it's probably less of a hassle than finding and going to an in-person shop.

NixOS packages only work with NixOS system. They’re harder to setup than just copying a docker-compose file over and they do use container technology.

It's interesting how none of that is true.

Nixpkgs work on practically any Linux kernel.

Whether NixOS modules are easier to set up and maintain than unsustainably copying docker-compose files is subjective.

Neither Nixpkgs nor NixOS use container technology for their core functionality.
NixOS has the nixos-container framework to optionally run NixOS inside of containerised environments (systemd-nspawn) but that's rather niche actually. Nixpkgs does make use of bubblewrap for a small set of stubborn packages but it's also not at all core to how it works.

Totally beside the point though; even if you don't think NixOS is simpler, that still doesn't mean containers are the only possible mean by which you could possibly achieve "easy" deployments.

Also without containers you don’t solve the biggest problems such as incompatible database versions between multiple services.

Ah, so you have indeed not even done the bare minimum of research into what Nix/NixOS are before you dismissed it. Nice going there.

as robust in terms of configurations

Docker compose is about the opposite of a robust configuration system.

I imagine a bad actor could buy a custom domain, connect it to proton, and then spam millions of people from thousands of addresses, using Proton’s infrastructure?

You could do that without creating thousands of addresses; one is plenty for that. Also, they'd still be under your domain, so all you'd do is hurt the custom domain's reputation and probably get it blocked by everyone quite quickly. If anything, I'd imagine thousands of addresses under one domain spamming would get that domain banned much more quickly than if it was just one address.

What is the # limit on a custom domain?

There is no specific limit for addresses on custom domains; it's one global limit of 15 addresses, no matter which domain they're under.

This is a false dichotomy. Just because containers make it easy to ship software, doesn't mean other means can't be equally easy.

NixOS achieves a greater ease of deployment than docker-compose and the like without any containers involved for instance.

I would not buy a CPU without seeing a real-world measurement of idle total system power consumption if you're concerned about energy (and therefore cost) efficiency in any way. Especially on desktop platforms where manufacturers historically do not care one bit about efficiency. You could easily spend many hundred € every year if it's bad. I was not able to find any measurements for that specific CPU.

Be faster at transcoding video. This is primarily so I can use PhotoPrism for video clips. Real-time transcoding 4K 80mbps video down to something streamabke would be nice. Despite getting QuickSync to work on the Celeron, I can’t pull more than 20fps unless I drop the output to like 640x480.

That shouldn't be the case. I'd look into getting this fixed properly before spending a ton of money for new hardware that you may not actually need. It smells like to me that encode or decode part aren't actually being done in hardware here.

What codec and pixel format are the source files?
How quickly can you decode them? Try running ffmpeg manually with VAAPI decode, -c copy, and a null sink on the files in question.

What codec are you trying to transcode to? Apollo lake can't encode HEVC 10 bit. Try encoding a testsrc (testsrc=duration=10:size=3840x2160:rate=30) to AVC 10 bit or HEVC 8 bit.

Note that ProtonMail and Fastmail have quite different feature sets.

ProtonMail does not store your Email in plain text for instance; they cannot read them or be ordered to read them. This comes with some drawbacks such as that standard protocols such as IMAP do not work without a bridge because they necessitates that the server can read all the emails.

I also find it weird that you can't create unlimited addresses on your custom domains.

For the shared domains, limits in this regard are absolutely understandable as the supply is limited but addresses should have next to no cost for PM when they're under my own domain.

Why is that? @[email protected]