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've never heard of this program but I heard the voice in my head pronounce it is p-yes immediately. Apparently I've internalised GNU English to totally native level.
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.
>Try running any part of the systemd software suite on an openrc system and see how that works out?
Well from this POV it's kinda openrc's problem if it doesn't. What about trying to run any part of the Openrc software suite on an Upstart system? The question why would anyone sane want to is rhetorical tho...
Why obsessing over whether systemd is monolithic and in what measure anyway? There certainly ARE optional systemd parts. So it's correct to say it's not entirely monolithic.
openrc-init can be used on an upstart system, the daemon manager itself can't but that's because you'd have two different daemon managers. Beyond that there aren't any openrc software components, because it was designed to be a modular init system that just handles what it was intended to handle.
The rest of the system for example chrony, sysklogd, cron, etc run fine on upstart systems, because they aren't tied to systemd and are fully modular.
It's okay to be a monolith, that doesn't make it inherently bad or anything, but we should be honest about it, and it does come with some tradeoffs.
Most systemd components do rely on some core systemd components like systemd (the service manager) and journald. I would say that a core thesis of systemd is that Linux needs/needed a set of higher-level abstractions, and that systemd-the-service-manager has provided those abstractions. The fact that other parts of systemd-the-project rely on those abstractions does not imply that the project is monolithic.
Explain the existence of "elogind" and "eudev" then?
It might be the case that one can disable some components of systemd, on a systemd system. It is certainly not the case that they are "loosely coupled", or there would be no incentive to maintain forks of core systemd components with the sole and explicit purpose of decoupling from systemd.
In theory. In practice, systemd is a mess of different components that have subtle dependencies on each other. And while the core of systemd is solid enough, everything around it is not.
It's a collection of tightly-coupled components that are functionally a monolith because large distros tend to rely on the various components rather than allowing modularity.
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.
Cloud servers mostly, though I still use it on my DAW workstation. I suppose both of those are "products" in a very tenuous sense since I make money from them.
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".
Huh? Guess you do learn something new everyday - I've been calling it that for ever too but apparently it is "engine-x" ... (thanks to you, I guess I won't sound like an idiot any more, to some ;).
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.
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.
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.
The thing about specific needs is that they are usually narrow. You could throw darts at the dartboard of problems, working on very narrow problems for years and never get a job solving any of them. If a problem calls out to you and you won't stop until you get a job with it, then the effort could be worth it. But sometimes, even if you get THE job, you'll have a slight twist in constraints that makes most of your prep go by the wayside.
I agree, but we all have to pick our battles. Do you want to solve real problems, enjoy other things in life, or solve some problem that a guy on the internet said is essential for any "real" programmer?
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".
The only thing missing is a recursive acronym e.g. Pies: Pies Is Experimental Software or something equally cringe like Hurd
Pies is eshewing systemd?
how about "Active Development" without any progress in 3 decades
I've never heard of this program but I heard the voice in my head pronounce it is p-yes immediately. Apparently I've internalised GNU English to totally native level.
It's how you would pronounce it if it were Latin. In which case it would mean "feet". Maybe that's not what inspired the name.
Also in Polish, which would mean "dog".
I think the Latin for feet would be "pedes", singular "pes".
Romanes eunt domum.
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.
I think they both run as user. But you can put gitlab in a docker
https://www.gnu.org.ua/software/pies/example.php?what=gitlab
https://www.gnu.org.ua/software/pies/manual/Docker-Entrypoin...
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
systemd is not a monolith.
It's a collection of losely coupled components and services of which basically every single one can be disabled or replaced by another implementation.
No it definitely is a monolith.
It's NOT loosely coupled in any way. Try running any part of the systemd software suite on an openrc system and see how that works out?
I have no idea why people are so insistent on claiming that its not a monolith, when it ticks off every box of what a monolith is.
>Try running any part of the systemd software suite on an openrc system and see how that works out?
Well from this POV it's kinda openrc's problem if it doesn't. What about trying to run any part of the Openrc software suite on an Upstart system? The question why would anyone sane want to is rhetorical tho...
Why obsessing over whether systemd is monolithic and in what measure anyway? There certainly ARE optional systemd parts. So it's correct to say it's not entirely monolithic.
openrc-init can be used on an upstart system, the daemon manager itself can't but that's because you'd have two different daemon managers. Beyond that there aren't any openrc software components, because it was designed to be a modular init system that just handles what it was intended to handle.
The rest of the system for example chrony, sysklogd, cron, etc run fine on upstart systems, because they aren't tied to systemd and are fully modular.
It's okay to be a monolith, that doesn't make it inherently bad or anything, but we should be honest about it, and it does come with some tradeoffs.
Most systemd components do rely on some core systemd components like systemd (the service manager) and journald. I would say that a core thesis of systemd is that Linux needs/needed a set of higher-level abstractions, and that systemd-the-service-manager has provided those abstractions. The fact that other parts of systemd-the-project rely on those abstractions does not imply that the project is monolithic.
Explain the existence of "elogind" and "eudev" then?
It might be the case that one can disable some components of systemd, on a systemd system. It is certainly not the case that they are "loosely coupled", or there would be no incentive to maintain forks of core systemd components with the sole and explicit purpose of decoupling from systemd.
In theory. In practice, systemd is a mess of different components that have subtle dependencies on each other. And while the core of systemd is solid enough, everything around it is not.
It's a collection of tightly-coupled components that are functionally a monolith because large distros tend to rely on the various components rather than allowing modularity.
GNU Shepherd
"Pies" means "dog" in Polish an Ukrainian (пес).
So, "Gnu is Not Unix, Dawg"?
“Pies” is Spanish for feet, which was my second reading after seeing the pronunciation. The first was in reference to round baked deserts.
Is that pronounced “peace” or “piss”?
More like pi+[y]es, but single syllable and no y.
EDIT: Here are three audio files to hear: https://pl.wiktionary.org/wiki/pies#pies_(j%C4%99zyk_polski)
As an American, I hear “pyes” - a single syllable “yes”, with a preceding “p.”
When do you use that vs собака (sobaka)?
I don't, I'm Polish. Can't say for sure for Ukrainians, don't know Ukrainian that well, but my reading of https://en.wiktionary.org/wiki/%D1%81%D0%BE%D0%B1%D0%B0%D0%B... and https://en.wiktionary.org/wiki/%D0%BF%D0%B5%D1%81#Ukrainian suggests that пес must be male, but собака is either male or female. I might be wrong.
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.
Init for what, your desktop or in a product?
Cloud servers mostly, though I still use it on my DAW workstation. I suppose both of those are "products" in a very tenuous sense since I make money from them.
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".
Tack is short for tackline, a length of line used to delimit messages encoded with flags in the days before shipboard radio communications.
Military and civil emergency communications use alternative pronunciations where clarity and brevity are critical.
Ooh! I do this! I got it from Darren Kitchen from Hak5! I have no idea where or why he did it though.
https://nginx.org/
Funny, I had a job where everyone called it "N-Jinx", so I said that at another job and everyone looked at me like an idiot.
Huh? Guess you do learn something new everyday - I've been calling it that for ever too but apparently it is "engine-x" ... (thanks to you, I guess I won't sound like an idiot any more, to some ;).
Lots of counterexamples to that one.
No.
English, dammit...
sudo? gnu? mate? debian? ubuntu? suse?
Oo Boon Too
I was born and raised amongst the rednecks of the southern US and still, someone saying “uh-BUN-too” sounds so silly
Wait, how are you supposed to say mate?
Mah-tay
WHAT D:
https://en.wikipedia.org/wiki/Yerba_mate
lol, no thank you
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.
Half an hour? Slacker!
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.
That makes a lot more sense than saying everything is essential lol.
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.
The thing about specific needs is that they are usually narrow. You could throw darts at the dartboard of problems, working on very narrow problems for years and never get a job solving any of them. If a problem calls out to you and you won't stop until you get a job with it, then the effort could be worth it. But sometimes, even if you get THE job, you'll have a slight twist in constraints that makes most of your prep go by the wayside.
Solving a variety of problems makes you better at solving problems.
I agree, but we all have to pick our battles. Do you want to solve real problems, enjoy other things in life, or solve some problem that a guy on the internet said is essential for any "real" programmer?