Just want to jump
in on this - watch the video, read the slides. It's powerful
stuff. No all the answers are not there, hell most of the questions are not there, but just take 2 minutes and read it.
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).
> I'm mostly interested in docker et al for the isolation aspect. The "ships the app with all its dependencies" is an interesting byproduct
And that's why i use Jails instead (or LXC if you're on Linux). None of the layers. Any vulnerability is in the "base" image, and easily spotted, and can be hotfixed using normal package tools.
Docker is a mess. Most containers consist of minimum 4 "base images", each of which can contain vulnerabilities. All done to save the "overhead" of installing Python on top of a base Debian image, or whatever your flavor of poison is.
Instead i use Ansible for reproducibility, and scripts for updating/upgrading.
Another advantage to jails is that they're just plain directories in a hosts filesystem, allowing existing vulnerability scanners to scan the entire stack from a single host, instead of using containers that needs to be scanned individually.
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.
Yes, signaling is definitely centralized, before it was done by mega-peers. P2P contact does work behind NAT if it's a cone NAT. Symmetric NAT would require that the signaling server assign a forwarding server to handle data from and to each peer. In general CGNAT applications with cone NAT, UDP hole punching can be used to communicate between peers, organized by the signaling server.
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:
Why not? This isn't the 90s anymore. Clang 8 is a very usable c compiler with excellent optimizations and excellent diagnostics. (OpenBSD doesn't use c++, so they don't need newer standards of that anyway.) And newer versions of both clang and gcc are available as packages.
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.
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.
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...