> My problem with systemd isn't pid 1. It's all the rest of the shovelware that comes along for the ride. And it's the "you'll use what we tell you to use" attitude of the project.
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].
> 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.
The backstory is actually enlightening to me. To me, RemainAfterExit just seemed like the obvious sane decision and I actually wondered why it ever was different. When a user logs out, I absolutely want everything cleaned up after them unless they explicitly want something like screen or tmux to linger.
> you need to do some insane things (IMO), like link tmux with libsystemd
That would probably be the easiest choice for the tmux devs. If they don't want to link libsystemd, they could have accessed logind's DBus interface directly (either by calling dbus-send(1) or via libdbus). Contrary to wide-spread belief, systemd does, in fact, present well-defined and documented interfaces that other daemons can implement as well (and they do, see elogind). libsystemd is not magical.
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.
The problem with this in practice is that you're often not the person implementing the 3rd instance. It's some other dev who comes and sees 2 copy/pasted implementations, either figures there's a good reason for it, or is lazy, or is risk adverse, or just wants to get the job done and move on, and copy/pastes it a 3rd time.
Explanatory comments that tell the reader to go look for other instances of this pattern are the key to success.
// AB-20200405 - Hi future developer (probably me),
// if you're copying and pasting this code, then
// please take an extra five minutes to locate the
// other similar instance of this code snippet in
// the codebase, and refactor both of these into a
// method first. The other snippet will have the
// same comment that precedes this one.
//
// Here's what this overly clever snippet of code
// is doing, so that when you do refactor it into a
// method in 2023, you don't miss an important edge
// case. Ta!
Or, the new dev doesn’t see the second copy, because they gave you the benefit of the doubt, and only apply a bugfix to one copy.
Later, since your team is growing, some other dev applies some other fix to the other branch (which was also copy pasted three times by three distinct devs because “rule of three”).
Soon, you have a dozen copies, and they are all wrong/diverged enough to not be clear copy pastes any more.
I’ve seen this happen more often than not, especially when scaling teams. Since the team is scaling, the original dev won’t always review all the code changes.
Japan, Korea, Germany are also in line and also India (with successful space program without immigrants). There are many countries which are successful without immigrants, some of them are even democracies.
>Japan, Korea, Germany are also in line and also India (with successful space program without immigrants).
This is just plain wrong, in the case of Germany. Germany has a huge immigrant population, and has since WWII when they brought in tons of Turks to be laborers there. There's an enormous Turkish population in Germany, and it's not new. Germany probably would not be where it is now without them.
Japan and Korea don't have many immigrants, it's true, but they were both occupied by the US for some time (and Japan still is, in a way, as is Germany).
I hope your not including India in your list as an example of ethnic uniformity, are you even aware of the vast number of different cultures and languages spoken in India? India stands as the original melting pot since ancient times. Oh and it also has the one of the largest immigrant population in the modern world.
I wrote the python compiler. It's very slow. With the optimizations it's probably something on the order of O(n^3) or O(n^4). One of the test cases took seconds to compile. I made no effort to optimize the compiler speed.
There is a mandatory compilers-lite course at UW and he teaches the advanced version of it, where the project is to fill in pieces of a Scala-lite compiler written in Scala.
Hi. I wrote the python implementation. I've had prior experience with compilers and I'm obviously biased but I would say it's quite readable. The main compiler part (without optional features or the LR(1) or lexer generator) is 2040 lines and contains very little magic. It would be easy to translate 1-1 to idiomatic C++ for instance - it would just be much more verbose. eval() is only used by the lexer generator. The metaprogramming could have been avoided by using dataclasses (but the marker used python 3.5).
(To be clear, the optional portions in which I implement SSA, various optimizations, a Hack-style allocator and some ad-hoc codegen is much less readable.)
Sounds really cool! As someone who programs a bit for work to help with automating processes and fun, but is not a computer scientist I'm a little jealous of never having taken a true database, compilers, PLT, or theory of computation course.
It sounds like you and your classmates are top notch and will go on to some pretty freaking cool careers (ex: I'd work at Jane Street if I was not a parent and a lot smarter :)). Out of curiosity, what are the typical places your classmates go upon graduation?
I'm guessing this is because most people who trade tether don't intend on holding it for long, so the "shennanigans" surrounding tether aren't as likely to affect them.
