Hard disagree with the notion this adds a degree of failure.
From a layman's perspective, it replaces one primary degree (pilot-control coordination) with another (a technological solution) and delegates the staffers to supervisory roles. That is a risk reduction due to the increase of confirmations and the independence between the staff decision and the software's decision.
OP is completely right that this is bad design because the fundamental issue is NOT that multiple giftcards are being made - the issue is you cannot have a Kindle shopping cart.
No matter how you spin it, that's Amazon being difficult in the hopes that a few lazy shoppers will "just" buy things as they see it and not track their spending.
Likewise, .epub is a garbage format. DRM does not belong on books.
I think its a bit of systemd's issue since it's attempting to cover a large range of functionality. The way it provides that functionality is important.
Re: the binary logs - true, but the core point that its not text by default is still a (small) issue IMO. Not ideal default behaviour.
- Its a "big" for small docker containers (which is part of why a lot of people like Alpine Linux).
- It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script.
- the binaries are all a lot bigger in terms if SLOC and in terms of storage space than the solutions they replace. This makes auditing the code more of a chore and is a big argument against it in certain security environments.
- (my main gripe) systemd produces vendor lock-in from seemingly unrelated apps. A lot of packages which indirectly depend on a systemd functionality need to be patched to work on OpenRC Gentoo, for example.
Some arguments for systemd:
- systemd abstracts process management. This can be fantastic for scripting and security (again, context dependent)
- systemd by default kills services on log out (which is great for desktop - but can be an obstacle for servers). This is a good default behavior from a security perspective.
- systemd has some parallelization of init, making start up more predictable (because something falling over is less likely to nuke the whole procedure - again good for desktop)
- systemd provides a lot of tooling to stop you doing things the "wrong" way. For example, systemd-analyze-security provides configuration tips to harden your system
==========
In general, I would say that systemd is a very impressive tool and helped a lot of distributions standardise how they handle boot. I wish it did not impact downstream development the way it does though.