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.
Those were just the most prominent things, which were immediately noticed because it's completely normal to leave them open remotely to maintain context for something and quickly pick it back up when reconnecting. It's kind of their whole purpose. But the change affected everything, including for example the "daemonize" program.
> 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!
Cronjobs often run as root. If the host has is configured to send emails when a cronjob is completed it will default to sending it to user@domain where the user is the user the cronjob runs as, and the domain is what was configured in the cron configuration.
Minor nitpicky correction: cron only sends an email if there's any stdout of the job.
This is an important distinction because if you have configured mail forwarding, your cron jobs should be configured to output only on error.. then any emails are actionable.
Moreutils has a great command `chronic` which is a wrapper command like `time` or `sudo`, ie. you just run `chronic <command>`. It'll supress stdout and stderr until the command exits at which point it will print only if the exit code was non-zero.
I worked at the OSL as a student years ago, and it was one of the most impactful places I've ever worked at. I learned a lot, and I wouldn't be the engineer I am today without having worked there.
Since graduating, I've also hired, and worked with multiple alumni from the OSL and they're always top notch. Anyone looking for interns or new graduates with devops/SRE or SWE experience should be looking at the OSL for talent. It's not too often you can hire a new graduate with potentially multiple years of production experience, especially in devops.
In context of HN/Y Combinator, https://www.ycombinator.com/companies/coreos was a successful container/Kubernetes focused startup founded by two OSUOSL alumni, Alex Polvi and Brandon Philips, which was eventually acquired by Red Hat.
The OSL is something special.
For a list of projects the OSL helps host, check out https://osuosl.org/communities/. You might see a project you care about in that list! As an example: they provide aarch64 and powerpc VMs for a ton of projects to do their CI/builds on.
https://www.freedesktop.org/software/systemd/man/latest/syst...
reply