this post was submitted on 07 Mar 2024
1409 points (92.9% liked)

linuxmemes

20686 readers
1473 users here now

I use Arch btw

Sister communities:

Community rules

  1. Follow the site-wide rules and code of conduct
  2. Be civil
  3. Post Linux-related content
  4. No recent reposts

Please report posts and comments that break these rules!

founded 1 year ago
MODERATORS
poopsmith@lemmy.world
zephyr@lemmy.world
1409
That's LTT in the bottom (lemmy.dbzer0.com)
submitted 6 months ago by 0x4E4F@lemmy.dbzer0.com to c/linuxmemes@lemmy.world
502 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] erev@lemmy.world 1 points 6 months ago (1 children)

How's the init script management access? I had a friend try to switch to openrc on Arch (I know) and he had a terrible experience, most likely because it's Arch and not Arco which is designed for alternative init systems. Do you have to write and maintain your own init scripts, or is that created during installation?

[–] ed_cock@feddit.de 2 points 6 months ago* (last edited 6 months ago) (1 children)

Do you have to write and maintain your own init scripts, or is that created during installation?

Packages should come with the necessary scripts (on Gentoo and Alpine they do), but if they don't for some reason then writing them is pretty simple. I think the updated layout really only needs dependencies and a couple variables defined.

Void uses Runit which is even simpler, you have one directory per service and at least a script called "run" in there which gets executed by the supervisor. The is usually just one line, that's all it takes to make a service work. It also has the supervisor take care of handling logging, similar to what Systemd does. I think it's a very clean, modern take on classic init, except that dependency/ordering doesn't exist - it just retries until things fall into place. Works well though.

[–] erev@lemmy.world 1 points 6 months ago

i wonder if you can do a waterfall init where you can have an entry point that defines what services to run next. then you services can continue to pass on the next to run, or if it encounters one with a service that isn't running, it looks at what services that one requires and traverses up to start the root unstarted service. Easy way to define dependencies without much hassle. The former case handles system services, the latter handles application services.