Skip to main content ↑ ↓
Topic: OpenRC User Services feature now available (experimental) (Read 1805 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: OpenRC User Services feature now available (experimental)

Reply #15 –
Quote from: capezotte – on
Quote from: mrbrklyn – on
<<Hacking user services with profiles is also somewhat ugly.>>


No it is the standard and you always know where it is. Moving user space activities to init just breaks the standard

Then where is it? .profile? .xprofile? .xinitrc? .bashrc?

"You know because you set it up". Then it's not a standard (everyone's rolling their own thing) and it begs the question, why have an init system in the first place? Back in the early 80s, PID 1 just called an admin written /etc/rc file that started all the services the machine needed.

Plus, as gripped said, existing ways of autostarting programs aren't going way.

Quote
and makes complexity where it is not needed.

Init systems already have 99% of the complexity user services need. Looking at the code for runit or s6, which have had user services for longer than OpenRC, you'll find no special handling is needed for that, the separation happens naturally because of permissions. The only extra code needed is making the user services start up (be it via the "main" init system, profile files, DE autostart or PAM), and that's just hooking the login process (or something that happens alongside it) to a runlevel change.

This isn't like spending extra on groceries for six completely different dinners, it's more like a dessert that reuses the existing ingredients in a new way.

Quote
And there is  zero benefit... at least nobody has pointed any out.

The second paragraph on the wiki page that supposedly says there's no benefit over profiles or autostarting starts with:

Quote from: https://wiki.gentoo.org/wiki/OpenRC/Legacy_user_services
A process supervisor offers two main benefits [...] also offers minor benefits

For a concrete example, there's Pipewire -- user services (this or Turnstile) prevent the known bugs caused by the autostarted processes lingering after logout. Sure, I can add a bunch of pkill/killall to the startup script (like the old launcher script used to do), but that won't work well with shell profiles and it's exactly the kind of bulk process management init systems are supposed to help you with.


FWIW - Piperware  should ALSO not be in user space.... 

supervision tools are built into the OS, a tool that needs to be started and supervised should probably not be in users space.  Actually, supervision is most often a bad idea.  I hated having a buggy apache process keep spinning up after dieing.  It should die and stay dead and the programmer should fix it.

Re: OpenRC User Services feature now available (experimental)

Reply #16 –
Quote from: mrbrklyn – on
FWIW - Piperware  should ALSO not be in user space.... 
Pipewire is designed to run as a per-user daemon, not a system-wide service. Unless you are talking about the design decision ?
Quote
Actually, supervision is most often a bad idea.  I hated having a buggy apache process keep spinning up after dieing.  It should die and stay dead and the programmer should fix it.
Don't use it then? As already stated in this thread you can just get init to run a self made script which sets up your system then starts some services and one or more getty's.

The actual 'init' part of Artix's openrc implementation, openrc-init,  has not changed at all due to the addition of user services. It's still the same simple code that mainly just calls /usr/bin/openrc plus handles signals, zombies and shutdown .Otherwise user services would not work on Gentoo as they don't use  openrc-init (at least they didn't use to?)
You could maybe just replace /usr/bin/openrc with the above mentioned script and be done with user services and supervision. Though in that case I imagine you'd be better off with suckless init or similar.

I've taken a slightly closer look at the openrc user service implementation and have come to the conclusion that it's quite elegant.

At the end of the day the folks who write openrc are free to code it as they wish. If you don't like it you don't have to use it.

Re: OpenRC User Services feature now available (experimental)

Reply #17 –
Quote from: gripped – on
Quote from: mrbrklyn – on
FWIW - Piperware  should ALSO not be in user space.... 
Pipewire is designed to run as a per-user daemon, not a system-wide service. Unless you are talking about the design decision ?

Yes it was a bad design decision and I don't use it.  There is one sound system per machine and a system wide resource.
Quote
Quote
Actually, supervision is most often a bad idea.  I hated having a buggy apache process keep spinning up after dieing.  It should die and stay dead and the programmer should fix it.
Don't use it then? As already stated in this thread you can just get init to run a self made script which sets up your system then starts some services and one or more getty's.

The actual 'init' part of Artix's openrc implementation, openrc-init,  has not changed at all due to the addition of user services. It's still the same simple code that mainly just calls /usr/bin/openrc plus handles signals, zombies and shutdown .Otherwise user services would not work on Gentoo as they don't use  openrc-init (at least they didn't use to?)
You could maybe just replace /usr/bin/openrc with the above mentioned script and be done with user services and supervision. Though in that case I imagine you'd be better off with suckless init or similar.

I've taken a slightly closer look at the openrc user service implementation and have come to the conclusion that it's quite elegant.

At the end of the day the folks who write openrc are free to code it as they wish. If you don't like it you don't have to use it.

The built in complexity affects the entire system, whether it is used or not.  It is mission creep.  More and more desktop widgets will expect it etc etc.
 

Re: OpenRC User Services feature now available (experimental)

Reply #19 –
@Shoun2137
(Not knowing the full story but) thanks to healthy skepticism am I now able to enjoy this awesome distribution.
Not instantly swallowing everything lead to replies here that I found very educating.

Re: OpenRC User Services feature now available (experimental)

Reply #20 –
Quote from: gripped – on
Quote from: mrbrklyn – on
You obviously never raised 6 kids and made dinner for them...
Offering choice to all six kids would involve the parent then have to cook six possibly different dinners all at the same time, in the present. Offering choice to the users of Openrc does involve extra work PRIOR to the choice being made by the user but does not involve extra work at the time the users choice is made. In other word it's not the same thing at all (I haven't raised six kids, only three).

I don't think anyone is going to die because of user services? At least I truly hope not.
You think user services are a bad idea. I think they are a reasonable idea but I wasn't desperate for them.
There is no drama ?
We don't know where artix is being used... seriously.  Computers certainly do life saving work.

Put that aside of the moment.  Worst than preparing all those meals, with our analogy, during the meal it causes total chaos.  It fosters petty jelousies, bickering at the dinner table,  arguing over plates, and general chaos.  That is aside for huge clean up of plates.

Unix is like a train.  You get on the train and it has doors, and seats, and temperature control, possibly a food car. It has an engine, sheltered areas with tools and fuel.  Passangers are the users.  They enter the train and find their assigned seat, and use the trains services, and many areas of the train they never directly use... like they never use the engine room, or access the food preperation areas, or have direct access to the water suppply.

When you give each passanger access to their own little engine... yeah that is not good.  If you have the engine room responsible for cleaning each passangers seating assignment... you can do that.  But it is innefficient and confuses the crew and puts the train in danger.

Passenger access services as they are doled out by the crew.  Choices are limited but everyone gets to their station safely and comfortably.

Passangers are not the crew.

Re: OpenRC User Services feature now available (experimental)

Reply #21 –
Quote
Worst than preparing all those meals, with our analogy, during the meal it causes total chaos.  It fosters petty jelousies, bickering at the dinner table,  arguing over plates, and general chaos.  That is aside for huge clean up of plates.

I was gonna argue against that analogy, but since this thread looks so much like your hypothetical dinner table, maybe you're right :P

Re: OpenRC User Services feature now available (experimental)

Reply #22 –
If it looks like a duck, and quacks like a duck, it's probably a train.

Re: OpenRC User Services feature now available (experimental)

Reply #23 –
Quote from: capezotte – on
Quote
Worst than preparing all those meals, with our analogy, during the meal it causes total chaos.  It fosters petty jelousies, bickering at the dinner table,  arguing over plates, and general chaos.  That is aside for huge clean up of plates.

I was gonna argue against that analogy, but since this thread looks so much like your hypothetical dinner table, maybe you're right :P



I just got off the phone with my friend Rick Moen (Linux Mafia, SVLUG)  and we both agreed on the point that Number #1, we don't want to spend what little is left of our life learning the details for a complex peice of software that replaces something that has been functions just fine for 30 years.

To the degree that this change is not going to force us to do that, we don't care.  I have doubts it will remain like that.  It always bleeds into the user enviroment...

Mind you, I felt that was about Java years ago...and Rick's biggest Hard Drive storage is 120 Gigs...
 
Artix forum uses a single cookie to remember youOK