One release every 4 years. So this is like monit or systemd-supervisord and so on, a process manager. I have to say the thing I most enjoy about it is the fact that it's got the classic GNU trend of "here's an obviously pronounceable spelling; let's say it a different way".

I'm reminded of this https://supervisord.org/

Used it inside of containers a few times when I wanted to keep things simple and have a container that ran both a web server and PHP-FPM at the same time and kept them up.

Are the collection of components run in some kind of namespace? Say I run a Pies for Gitlab (which in itself had lots of components), and I run a Pies for Frpd, do they share the same space or are they isolated from each other? Am I maybe overthinking this? Perhaps its just a program manager.

Is this the gnu version of systemd?

edit: I know it's not a monolith like systemd but service/unit files are a core component of systemd

The area where I've seen the most homegrown implementations of things like these is HFT, with the caveat it's also designed to be distributed, integrated with isolation systems, start/stop dependency graphs...

I once worked for a company which chose to use Kubernetes instead, they regretted it.

> pronounced "p-yes"

Absolutely not.

Apologies to the Slavs, but there’s already a utility pronounced like that.

I've been using this init for years and always liked it. It's sad the Init Wars ignored it completely.

If you have to explain the pronunciation of the name of your tool in the first sentence, you've already lost.

I was in a group who began pronouncing the dashes in command-line options as "tack" and they said it was military lingo, but I cannot now find any connection to dash, hyphen, "minus", or Morse code "dah".

No.

English, dammit...

sudo? gnu? mate? debian? ubuntu? suse?

Wait until the docs tell you to pronounce it "py-eez" and not like the food. Then you'll really lose.

Lots of counterexamples to that one.

SMI was pronouncing itself "ess-em-eye" in '91 and did just fine. Name clarity matters less than solving real problems.

Pies it means "foot" in spanish

Plural - “feet”

'a dog' in polish

Good to hear that some people out there still have some old-school -style sense of humor.

> The name Pies (pronounced "p-yes")

oh come on

Almost 20 years ago now I worked for a company that sat a group of about 25 of us down to talk about their latest survey named...CRMPIES.

Everyone looked at me like I was insane as I sat there chuckling. Thank you for bringing back that unfortunate memory.

If you don’t think whoever named it that way wasn’t based, you’re almost as naive as your coworkers :P

Everyone needs to have made a web framework. Everyone needs to have made a programming language. Everyone needs to have made a supervisor. Everyone has to have made a container manager. Everyone needs to have made a text editor.

Absolutely. I recently wrote my first compiler to get it off the bucket list… brainf*ck compiler/interpreter #100010134 or such? :-) Well… it was a fun half hour.

What's the value of making a supervisor? It seems to be mostly about gluing together some system APIs.

In some industries it’s critical. Think about aerospace where code is almost always homegrown or done by specialized company, and are specific implementations for specific needs. You don’t have that many COTS due to the criticality etc.

I've written supervisors for auto-restart with better logging than systemd could give us. We needed custom health checks and graceful deploys. Saved weeks debugging phantom crashes.

I built one for managing microservices at a startup. The moment you need dependency ordering, environment isolation, and proper restart policies, you appreciate how much subtle work goes into these tools.

I disagree with all of this. If you have time and interest, or a real need, then go ahead. I've never met a programmer who's made all of these things in my 20 years of programming, and that includes PhDs, professors, and old graybeards about to retire.

I think that at least one thing from the least is feasible.

The design echoes Erlang's supervision trees—formally studied in Armstrong's thesis—though without the fault isolation guarantees. I wonder if the Unix process model limits what's achievable here.