Poetteringware seems to be highly praised by mostly young people who would like Linux to be a Windows clone. People who understands Unix concepts tends to dislike it.
I'm pushing 50 and have been using one kind of unix or another for nearly 30 years, so I like to think (a) I have a pretty good grasp on 'Unix concepts' and (b) if I'm a 'young people' why do my knees hurt so much.
As such, my opinion on systemd is the old ways weren't all that great and I'm glad the youth are trying to improve things.
DNS + NTP are completely optional, but you get really good integration with systemd-networkd's DHCP client if you use them. Switching network is completely seamless, and the resolver updates fully automatically (direct DNS and NTP are blocked in many networks, sadly). Also, you get something that works out of the box, with essentially 0 configuration. You can't even install a system today over the internet without setting the time, and systemd-timesyncd does it with 0 configuration.
Other than "sysvinit based init had horrific shell scripts with 100 lines of repeated nonsense", given that almost every alternative to systemd which still uses shell scripts needs around 2 lines of shell per service (including the shebang) what exactly is the issue with shell scripts (if all they do is run a wrapper which sets up the environment of a program or the program itself)?
> - no forking services
When I used archlinux these were extremely common and I used archlinux as recently as last year.
> - logging and service management is tightly coupled (this is arguably good with some bad parts, required CPU for logging with systemd is not great)
So runit handles spawning a log daemon before the service is started to ensure all log entries are kept and comes with a really simple yet extremely powerful log daemon (but obviously you can use almost anything else including cat if you want). It manages to integrate logging tightly into service supervision while being maximally flexible and decoupled. What do you think about this?
OK I bite. Nothing is wrong with shell scripts. However, I would like to know if something _wont_ work. Shell scripts do not have this feature. You know if something does not work when you run it. There might be external dependencies missing or other very typical problems. If we have a way to push all of these to "compile time" it is an improvement. I also spent many years in the land mines of implicit overrides in shell script hells and thank you but no. As a good example you can have how people try to set JVM parameters in a big data project using shell scripts. I it is absolute insanity. Same thing in init scripts. Did you implement reload or restart? Is stop actually doing something or a noop. And so on.
If there is only one thing that I could keep from systemd, it would be the use of unit files instead of shell scripts.
The rest is your observations, nothing to disagree or agree with.
> However, I would like to know if something _wont_ work. Shell scripts do not have this feature.
... Does systemd?
I still have endless problems with unreliable service startup and I've read all the documentation, have done all the debugging and asked all the people I could find.
> I also spent many years in the land mines of implicit overrides in shell script hells and thank you but no.
I'm not sure what you mean by this.
> Same thing in init scripts. Did you implement reload or restart? Is stop actually doing something or a noop.
So this is linux sysvinit style init scripts, OpenRC doesn't have this issue (as far as I can tell) and definitely I've never had to ask myself any of these questions when using daemontools or runit. Maybe you should familiarize yourself with how some modern non-linux-sysvinit inits work because they're certainly extremely functional, reliable and clear.
> If there is only one thing that I could keep from systemd, it would be the use of unit files instead of shell scripts.
I've actually considered this and I think it would be incredibly trivial to make a unit file parser which you can call from a shebang which would do this kind of thing. You could even have it fork off the parser to run it unprivileged. I think I'll try writing it sometime soon. You could even integrate all the namespacing, cgroups and lots of the other features systemd provides into it.
A few extra features, but you probably don't need them. I use svlogd because I use runit and I use runit because it happens to be supported by my distro.
> Yes they do. Healthy vegans are way more common than you think. There is nothing unique about meat that can't be obtained from plant-based foods.
You can easily check if a vegan is actually following a vegan diet without cheating, because after a few years they will develop the sunken eyes and hollow collarbones, definitely not looking healthy.
Wait then why do literally none of the staunch vegan people I know look like this? And why does the American Dietetic Association officially state that a vegan diet is completely fine for all stages of life?
> Wait then why do literally none of the staunch vegan people I know look like this?
Maybe your are lying or in denial? I have first hand experience with the cult like properties of the vegan movement. It's very clear from how ex-vegans - people how really tried to embrace veganism, but had to quit because of health issues - are harassed by current vegans, any criticism of the movement cannot be tolerated and ex-vegans are very dangerous as they expose that veganism is not for everyone.
> And why does the American Dietetic Association officially state that a vegan diet is completely fine for all stages of life?
Lobbyism? Research some of the former controversies. The name is Academy of Nutrition and Dietetics now by the way.
Do you have any proof that lobbyism is the cause? Or are you just saying that?
Also would you be interested in having a zoom call with me, or some other vegans, to see that we don’t at all look unhealthy? We can clear this up very quickly, I think.
If you rent a server (real or virtual), whose software load you have control over, that's not SaaSS. In SaaSS, someone else decides what software runs on the server and therefore controls the computing it does for you. In the case where you install the software on the server, you control what computing it does for you. Thus, the rented server is virtually your computer. For this issue, it counts as yours
To backup the passwords a copy of ~/.password-store/ is enough, but to completely recover, a backup of the gpg keys is also required. What's your strategy for this? Do you just backup the entire ~/.gnupg/ directory?
I use passphrase2pgp[1] so I can recreate my GPG key anywhere. I need to remember three pieces of information:
- passphrase (long sentence, but it's easy to remember)
- uid (Name <email> - easy)
- timestamp (10 digits - kinda hard to memorize but you can have it noted is plain text since it's not sensitive information)
I have my key on multiple devices (e.g. my phone where I use the Password Store app). Then I have backups of the key as .asc on USB drives as well as printed on paper at two different physical locations.
> And, if I want it to be an app I can use some HTML/JS wrapper and be done in a similar amount of time. I can have a new electron app up and running and on 3 platforms in under an hour. If I had more mobile experience I'm sure I could do the same there.
So now you have made a crap UI that is running on 3 platforms. It was quick and easy for you, but now every user has to suffer with a slow and bloated electron "app".
GUI development definitely has gone backwards at least a decade. Of course it can still be done right, but with so many low skill web developers everywhere, electron "apps" are what we get.
How is the process going with reducing Javascript on the frontend? Simple things like reading replies to issues or merge requests should not require Javascript, it also makes Gitlab feel annoyingly sluggish compared to GitHub.
Specifically, consider a person who lost a child to suicide. What kind of emotional regulation skill will help them remain happy and productive at work after reading the word 'suicide' in code?
Who teaches this skill?
What percentage of people are able to learn and use it effectively?
How does the cost of learning and relying on the skill compare to the cost of changing some words in our code?
It's not feasible or reasonable depending on the world catering to your every need. If seeing or hearing a word will result in a mental breakdown, the solution is NOT to demand the entire world stop using that word, but for you to build mental resilience and being able to cope with that word, longterm this is the only way for you to not be miserable.
> It's not feasible or reasonable depending on the world catering to your every need.
You are implying that someone who wishes to remove trigger words from their codebase is "depending on the world catering to their every need." I don't see how that could be true. What does it even mean to depend on the world?
Removing trigger words from work documents and systems is inexpensive. It makes business sense.
You suggest that people "build mental resilience and being able to cope with that word". You seem to be repeating yourself. Again, please share some documentation about how to do this and its effectiveness.
There's some information that you seem to be missing: the characteristics of the human grieving process, techniques for dealing with grief, techniques for teaching those techniques, and their effectiveness. I suggest that you study a bit about the grieving process. I assume that you are a mortal human. Unless you die young, you will experience soul-crushing grief one day. You will be better off if you learn about it beforehand.
It's possible that you have experienced soul-crushing grief and have repressed it. Is that what you mean by "mental resilience"? If so, I'm very sorry for you. Repression puts off the hard work and prolongs the recovery time.
