marios

Interesting take, but as a sibling commented: όχι.

> αι = ε > αι already sounds identical to ε in Modern Greek, so the digraph is dropped.

sounds the same, but the distinction actually helps semantically (helps identify passive voice vs active notably).

> ει, οι, υι, η, υ = ι > all these spellings produce the same /i/ sound. This does however remove spelling distinctions that currently encode grammatical information like gender, number, and verb conjugation.

why would you drop something that communicates information ? the distinctions encode meaning (what you already mentioned + etymology)

> ου = Ȣ ȣ > the common digraph gets its own single character. The historic ligature ou.

I read the sample text and automatically parsed this as θ because the surrounding text, otherwise it's an 8 in my eyes. (although to be honest, you'll see a similar symbol in some byzantine iconography)

> ντ = D d > the digraph that produces /d/ becomes a single letter.

ντ and D d do not produce the same sound. ντ is meant to be pronounced 'n' followed by 't'. Notice where your tongue goes when pronouncing n / t / d => these are not the same sound.

> μπ = Б b > the digraph that produces /b/ becomes a single letter. The uppercase uses cyrillic Б to avoid confusion with Β (Vita).

same as above. 'μπ' is the 'm' sound followed closely by 'p'. This one is harder to hear in isolation, but for example when saying 'αμπέλι' (grape vine) you actually hear the 'm'.

> γκ = γγ = G g > the digraphs that produce /ɡ/ become a single letter.

again, the sound is different, i.e: άγγελος. it is not pronounced agelos (hard g), but rather ang-gelos (notice how in english the word becomes 'angel' with an extra 'n' ?)

> σ, ς = ϲ > all lowercase sigmas are unified into the lunate sigma ϲ, eliminating positional variants.

ς is used only when it's the last letter of the word. That's all the complexity there is.

if this is meant to help foreign speakers learn the language, then I weep for the moment they encounter the sea: Ȣάλαϲϲα. is it a soft c (as in 'copper') or a hard c (as in 'face') ? is it somehow changed by the fact there are two of them ?

> ω = ο > lowercase omega merges with omicron. They already share the same /o/ sound in Modern Greek, so the distinction is dropped.

phonetically, ω is supposedly longer ο, though it's quite hard to hear (I have rarely heard people where you consistently hear the difference). OTOH, orthographic distinction remains for etymological reasons. οστικός => related to bones ωστικός => related to pushing

change the omega to an omicron, and you just created an homograph (+ homophone) out of nowhere. queue future learners wondering why those crazy Greeks decided it would be appropriate to use the same spelling and pronunciation for two entirely different meanings.

the changes look arbitrary in order to simplify the rules for _some_ learners, but end up making it more complicated. What you saved in spelling, you definitely lost in semantics.

I worry about online voting not being transparent enough

One could implement a rudimentary IPv4 stack in a couple of afternoons. There is not much magic in parsing Ethernet / ARP / IPv4 / UDP. For IPv6, a node needs to speak ICMPv6/NDP/MLDv2 which are all orders of magnitude more complex than their predecessors.

Another vote for inoreader.

Used TheOldReader.com when Google killed Reader, then switched to inoreader. Haven't looked back (even though I'm using the free version still).

edit: Adding that I find the android app to be of excellent quality.

But the content of shipping container #1 does not spill into shipping container #2. If it does, there's a problem.

Similarly with software containers, you don't want data flowing into nearby containers (unless you do want that, in which case you have setup the necessary networking and that should be the only way for the containers in question to share data).

I'm mostly interested in docker et al for the isolation aspect. The "ships the app with all its dependencies" is an interesting byproduct, although all too often it translates it means there's a mess in the amount of dependencies required. And that it's going to be an equal mess come update time -- unless of course the image is never updated in which case there's a chance the image becomes vulnerable (for example, outdated libssl).

My guess is that the signaling servers are centralized. You need those for connection establishment between two peers. Once they 'know' each other, they may aswell talk to each other directly. Routing all calls through central servers would yield an enormous bill every month. On the other hand, it is sometimes necessary as direct communication between peers may not be possible (NAT, firewalling). IIRC, a central server is also required for multi-party calls.

I'd recommend any Python talk by Raymond Hettinger (Python core developer). The content is top notch, and he is also very good at delivering it.

As pointed out by JdeBP, I confused RemainAfterExit= with KillUserProcess=. RemainAfterExit is an option indicating how systemd should process a unit file, while KillUserProcess is for systemd itself.

It's nice to know that libsystemd is not required in all cases, but I still have a problem with software having to be modified because systemd changes how libc's daemon() function behaves.

yes, indeed. Too late to edit now though :(

Does anyone have resources related to learning concurrency ?

I've had a very short introduction to pthreads in a CS class, but it was too succinct to get any practical benefit IMO. Knowing that a mutex can be used to limit access to a shared variable is easy enough to understand. How to structure software that runs concurrent tasks is still a mystery to me. Code I've written that uses threads appears to work but I'm not confident I haven't introduced a deadlock in there that's just waiting the worst possible timing to trigger. For instance, the pthreads manpage does a good job at listing the available functions. I have no idea when they should be used though.

If anyone can point me to learning resources around concurrency (books, presentations, talks, sample open source software that does good use of concurrency patterns, ... anything goes, really) I will be eternally grateful.

I have followed eBPF development from afar, so I don't exactly where it's at. I have a ... semantics question: do people really refer to eBPF as BPF ? This is probably bothering me more than it should, but why do overload terms when a more correct solution is available from the start ? The BPF virtual machine is not exactly new. For example, tcpdump supports BPF. Not eBPF, though. If we start referring to eBPF as BPF, then pretty soon other OSes using BPF will be referred as having "incomplete BPF implementations" because Linux has eBPF and we incorrectly refer to it as BPF.