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 watched this in 2020 even though it's from EuroBSDCon 2019. I'm talking about Patricia Aas keynote "Embedded Ethics": https://www.youtube.com/watch?v=HfNIiitVFtc

Hasn't aged one bit. If anything Patricia is spot on pretty much everything. If you don't have time to spend on this, you may want to take a look at the slides: https://www.slideshare.net/PatriciaAas/embedded-ethics-eurob...

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.

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:

http://lists.llvm.org/pipermail/llvm-dev/2017-April/112300.h... https://marc.info/?l=openbsd-misc&m=147503691302850&w=2

So they're using the last LLVM release with an acceptable licence.

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 :(

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].

[1] https://github.com/tmux/tmux/issues/428nk

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.

[1] https://skarnet.org/software/s6/

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.

EuroBSDcon 2019 Keynote by Patricia Aas: Embedded Ethics (https://www.youtube.com/watch?v=HfNIiitVFtc / slides: https://www.slideshare.net/PatriciaAas/embedded-ethics-eurob...)

Because, sometimes you need to worry less about the gritty details of the tech and take a step back and look at the bigger picture.

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).

No argument there. My point is that the default for FreeBSD jails is "isolate everything" and it's up to the user to open it up.

My post was in response to 'sayhello' that is wondering whether jails provide enough isolation.

The BSD jails / Solaris zones approach is not the same at the path taken by Linux. Linux gives you a facility to isolate network, a facility to isolate process views etc. You put them all together and you get a "container". The former starts off by having a container primitive that can't do much because, well, it's contained from everything. You then proceed to give it access to the network, the filesystem.

Doubt it had anything to do with ministers. They probably have 'work' phones, and these are paid by 'work'. In other words, citizen's tax euros ...

I am by not means qualified to judge on the quality of the patch, but I'm glad Linus is moving away from adding flags to getrandom() (resulting in subtly different behaviour than the Open/FreeBSD implementations). Now if only Linux fixed the "/dev/random provides higher quality random numbers than /dev/urandom and blocks when the entropy pool is empty" nonsense, that would be great.

Thanks. I was staring at the snippet wondering. I'm not all that familiar with YAML, so I thought perhaps all the values needed to be quoted rather that just written as is.

Upstreaming means the 'cost of maintainance' is shared. If you have out of tree patches, and upstream changes the API, either you have to update your patches or you have to keep running an older version. Possibly missing out on other improvements.

Getting things upstream can be more time consuming, but it's a worthwhile investment IMO.

Shipping the required network settings alongside makes sense. i.e.: a smtp mailer declares it needs to access tcp/25.

How does one get a global view though ? What am I allowing on this host and more importantly, how do I fix it when things go wrong ? (they always do at some point!)

This is the same kind of reply I got when systemd implemented IP accouting in unit files. Lennart said systemd gets a lot of flak, but in the end it's only implementing kernel features. I proceeded to ask him: why is it necessary to have this ? Do you feel obligated to make every single feature available ?

Parent comment raises a very valid question. How do you manage the firewall policy with this system ? Netfilter configuration is already a mess on Linux (iptables ? nftables ? iptables-persistent package ? netfilter-persistent package ? some custom shell script that calls individual iptables rules ? rules dynamically inserted by scripts ?) Each of these tools/methods has its flaws, but it becomes completely unmanageable if two are used at the same time.

When this won't work as expected, how should a sysadmin handle the situation ? Where do you even start debugging ? Is he/she expected to inspect every single unit file in search of the one that is amiss? Can one get a list of all currently loaded rules ? (preferably with counters about matched packets and ideally with the possibility to log a packet matched by a rule)

systemd making this 'easy' to use may be a bad idea. In my eyes, it's just giving users more rope to hang themselves with. The unit file format is often touted as an asset, because it's much simpler than the shell-goo you would find on most distributions (Debian and derivatives for example provided a skeleton file for people to write their own init.d services. Just the boilerplate was almost 100 lines of sh. Contrast with OpenBSD where most scripts to configure service startup are only a couple of lines).

Having a key=value format was touted as a plug as it made things easier. Turns out that's not exactly true because some settings will have the expected effect only if you add enable a different setting at the same time. In my mind, this translates as an if/else which makes me think systemd.unit(5) format is not INI style configuration, but a small programming language masquerading as a configuration.

Anyhow, this turned out longer than I expected. The fact that it would be possible to do with sysvinit does not mean it would be a good idea to do this sysvinit.

Which is not going to happen because Google has multiple competing messaging apps.

Had a quick glance and while the content seems worthwhile I am a little saddened by the code.

There are numerous calls to strcpy() which is a buffer overflow waiting to happen. I know this is not production code but it's just as important. This code is to be used as a learning tool so I think it's important to use correct idioms.

Apologies for nitpicking, but code gets copied, often in a hurry and you get bugs all over the place.

One more comment: in the intro you mention that while the code is mostly tested on Linux, it's likely it works on other Unixes such as Free/OpenBSD. You might want to remind the reader that epoll() is Linux-only (bonus points if you mention the BSDs have something similar called kqueue() :)).