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.
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.
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.
In OpenBSD, "base builds base". That is to say, one must be able to build the system using the compiler provided in the compXX.tgz set.
gcc moved to GPLv3 and OpenBSD doesn't ship GPLv3 code. For a long time, that's the reason why it was stuck on an ancient gcc.
OpenBSD moved to clang/llvm because it has a more acceptable licence. However, clang/llvm does not support all architectures OpenBSD supports, so that's why there's stil gcc.
Users can install a newer gcc (v8.3) from packages/ports.
Newer LLVM releases are licensed with APL2.0, and that doesn't sit well with OpenBSD:
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.
At some point, systemd introduced a RemainAfterExit= option, which killed all user started programs when the user logged out. IIRC, this is because of some misbehaving gnome application that wouldn't quit properly.
Of course, since this hack solved the gnome bug, it was enabled by default by many, thus breaking applications like screen and tmux.
What should have been done is fix the issue in whatever offending application. Certainly not at systemd level. Because in that case, you need to do some insane things (IMO), like link tmux with libsystemd [1].
I have a problem with how service files are good, except when you don't get them right on the first try and it's difficult to debug (unless I've missed something obvious). More generally, I find that systemd is difficult to observe and thus debug. To debug an ancient init.d script, you'd just run it with "sh -x" rather that sh, and you would have a trace of what the script is doing.
If your service file is a tad more complicated, then you quickly discover that there's a scripting language masquerading behind key/value entries.
I have a hard time wrapping my head around dbus being the core component used for coordination among systemd components. dbus wasn't built for this use case, and having PID1 depend on a well behaved dbus for proper system operation sounds insane. systemd adds a lot of features, which means additional complexity. My understanding so far is that the tooling is not there yet to manage this complexity.
Another gripe I have with systemd is that it does parallel service start introduces non determinism at boot. Which means your setup could work very well most of time, but fail miserably 1 time out of 10. Not exactly what you'd want if you are rebooting a remote server for example. s6 [1] init doesn't appear to have this problem.
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.
Not going to use yGuard anywhere, but thanks for opensourcing it. On the other hand, I stumbled upon yEd some time ago and it has been my go-to tool for diagrams ever since. Thanks to all the folks at yWorks that work on yEd !
After Google killed Reader, I switched to theoldreader.com and then inoreader. Very clean interface, the Android app rocks. I'm still too cheap to go on a paid plan, but even so the only limitation I see is the number of total feeds. Then again, I'm not sure that's a bad thing considering I have way too many feeds as it so having the possibility to add any more would only worsen the problem.
Alright, so that would mean that it's not WireGuard that's broken because it's trying to be more picky about the RNG, but rather the Linux CSPRNG that's broken when RDRAND is misbehaving. As you said, worrisome.
I'm surprised WireGuard asks RDRAND directly. Isn't there a facility inside the Linux to get random numbers ?
OpenBSD conveniently provides arc4random() in its libc for applications to use, and the same function is available for kernel components (obviously one needs to include different headers).
> αι = ε > αι 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.