I've been impacted by this particular "issue" and while it's changing the way "decades of convention" it's not really a bad thing imo. Running things via screen and tmux as a solution to background tasks has always been a huge hack imo. Not only that but the alternative approaches with nohup and disown also have their own issues. Imo it's actually pretty reasonable to need to work work the OS service manager to run background tasks, even with tmux and screen.
> The problem with systemd is that it's purposefully designed to be a viral monolith
Is it though?
Systemd is a project, not just a piece of software. It's got a lot of libraries that are reused across the different components that the systemd project ships. It's not that different from how most C/C++ projects have their own standard library built on top of stdlib/boost/etc. Any new "systemd project" could be done as a completely standalone piece of software, but it would mean recreating a lot of the libraries that already exist.
The biggest piece of coupling to systemd isn't really specifically systemd itself but how systems rely on how systemd does certain things, namely, cgroups. No one wants to manage cgroups themselves, so they use systemd to start services and put them into the cgroup hierarchy, etc. This is exactly one reason desktop environments "rely on systemd" (among others).
Why does everyone want to use cgroups (and thus systemd)? Because it makes managing groups of processes easier, which is directly tied to handling user sessions, which as it turns out, is something most applications want, since typically they deal with users!
Now, systemd's own sub-projects, (eg appd), are likely to be yet another consumer of systemd for similar reasons.
Using systemd, and building on top of it makes it much easier to implement features without having to do everything yourself.
Seems like the enactor should be checking the version/generation of the current record before it applies the new value, to ensure it never applies an old plan on top of an record updated by a new plan. It wouldn't be as efficient, but that's just how it is. It's a basic compare and swap operation, so it could be handled easily within dynamodb itself where these records are stored.
Also it's pretty likely it took less time than that to get an idea, but generally for public updates you want to be very reserved, otherwise users get the wrong impressions.
Sure they definitely were using Docker for their own applications, but also dotCloud was itself a PaaS, so they were trying to compete with Heroku and similar offerings, which had buildpacks.
The problem is/was that buildpacks aren't as flexible and only work if the buildpack exists for your language/runtime/stack.
If the the OP is the author, did consider filing a bug with errcheck? It should be possible for errcheck to check if the comparison is being done within an `Is(err error) bool` method and skip the warning in that case, or even better: it could check if your using `errors.Is` within an `Is` method and warn in that case!
That's not true, you can configure journald to be in-memory only in which case there's no binary log, no file. If your using systems, you can't really git rid of journald, but you can get rid of the binary logs.
And you don't need journald to read the log files either, you can use `journalctl --file /path/to/file.journal` to read them directly via `journalctl`.
If you get fired for going on paternity leave when the company explicitly has a policy for it, you're going to have an easy lawsuit win. I don't know why your even talking about startups that may not have a paternity policy, since the OP's company clearly has one.
It's not a requirement for "everyone else to pick up the slack". That's just the businesses choice.
At the end they could choose to let the team be less productive. Business should already assume that they may lose an employee at anytime, or roadblocks may come up, so if they're assuming the teams are always going to be at 100%, that's probably not realistic.
The business could also: hire another manager, or promote someone whose been looking for an opportunity to learn to manage. If they do want to shift the load to other existing employees, ideally the business is structured so that other managers aren't at 100% capacity and can help fill-in temporarily. That's still a form of "picking up the slack", but if it's planned for, it's usually less an issue.
A lot of this is just spending more money and resources to make it possible to optimize for speed.
With sufficient caching with and a lot of parallelism makes this possible. That costs money though. Caching means storing data twice. Parallelism means more servers (since you'll probably be aiming to saturate the network bandwidth for each host).
Pre-aggregating data is another part of the strategy, as that avoids using CPU cycles in the fast-path, but it means storing even more copies of the data!
My personal anecdotal experience with this is with SQL on object storage. Query engines that use object storage can still perform well with the above techniques, even though querying large amounts of data from object is slow. You can bypass the slowness of object storage if you pre-cache the data somewhere else that's closer/faster for recent data. You can have materialized views/tables for rollups of data over longer periods of time, which reduces the data needed to be fetched and cached. It also requires less CPU due to working with a smaller amount of pre-calculated data.
Apply this to every layer, every system, etc, and you can get good performance even with tons of data. It's why doing machine-learning in real- is way harder than pre-computing models. Streaming platforms make this all much easier as you can constantly be pre-computing as much as you can, and pre-filling caches, etc.
Of course, having engineers work on 1% performance improvements in the OS kernel, or memory allocators, etc will add up and help a lot too.
Agreed, but as OpenVPN has shown us, it's not a guarantee that security will be any better if everything is contained within a single process.
It's also possible to use something other than Vault, you could use LDAP for example, but Vault lets you use multiple authentication mechanisms, and can be used for other purposes, so it's kinda a multi-tool. Additionally, I'm not using consul, just Postgres on the same host as Vault.
If it gets anywhere yes, I've been a bit busy with life and it's been in a pause. The other aspect is this isn't super useful yet because I still need to implement the server side, as well as figure out how to make this useful as non-CLI for my mobile clients (iOS), which are the majority of what I use the VPN for.
If you want SSO, or fine grained access control, the idea is you would do that at a level above wireguard. For example, I'm prototyping a small CLI that talks to hashicorp vault via OIDC/OAuth2, and then creates a wireguard key pair + configuration locally, submits the public key to vault, and then the wireguard "server" is configured with a simple daemon that pulls all the public keys from vault and generates a wireguard configuration allowing access from those public keys.
This is a simple example, but much of what you need to do can be done with layers on top. This is similar to iptables, in that you can use `firewalld`, or `UFW` which all use iptables under the hood.
You can test it with:
The format is `DayOfWeek Year-Month-Day Hour:Minute:Second`
https://www.freedesktop.org/software/systemd/man/latest/syst...