Announcement

Collapse
No announcement yet.

SysVinit 2.90 Released With Fixes & Better Support For Newer Compilers

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • starshipeleven
    replied
    Originally posted by Bsdisbetter View Post
    Proves nothing other than more distributions use it and/or are forced to use it.
    It proves that the distro maintainers, (the people who actually care the most about their distro and the time they spend working on it, have decided to use it.

    To the contrary of most users that just take and don't understand, the maintainer know and are invested in the distro.

    Core dumps? Where are they hiding?
    you have issues reading documentation?

    Binary logs - crap can't forward them without installing rsyslog anyway.
    What do you mean with "forward them"?

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by moltonel View Post
    Because not every software package comes with the scripts for your favorite init system. The software may have complicated internal startup/monitoring and not wish to support multiple init systems. So it's nice when they can bring their init system, and you can plug that as one unit into your OS's native init.
    No offence but there is no way in hell that I'm letting a service designed for a different init run in another without looking very closely at it and doing some test runs. I've had issues running (admittedly complex) services supposed to run on Debian's sysvinit when ported over to CentOS's sysvinit, just because the system was configured differently and some tools called from the script were giving slightly different answers (screwing up stuff).

    I've had less problems mixing openrc, sysvinit, and runit scripts, probably because those don't try as hard to be the sole source of truth as systemd does.
    I can't think of a single program that has only openrc or runit script at all, much less those that I would run in a server.

    Custom solutions for logging, managing control groups, monitoring health, etc are possible under systemd but you have to fight for it.
    Afaik init scripts that call the older logging facilities still work normally, I'm not sure about what issues you have with managing users, monitoring health is so much better with systemd, but again I don't see the issues with the old systems.

    Subsystems like udev and logind that could (or used to) be independent projects get lumped into systemd seemingly just to strong-arm people into using systemd
    Yeah, udev working fine on its own too, and logind using standard and stable protocols towards the userspace with the stated intent of allowing people to replace it with their own daemons if they so choose. Illuminati confirmed.

    It is these reasons, not some internal architechture, that make systemd monolithic.
    Being monolithic in this case is not having dependencies and integrating all things in a single software, which systemd (the project) is NOT doing and never did.

    If you are calling something "monolithic" and it is not doing the above you are using the word wrong.

    Leave a comment:


  • nomadewolf
    replied
    Originally posted by jpg44 View Post
    systemd completely supports System V Init, if you want to use it. Pretty surprising isn't? because if you listen to systemd haters you would think that System V support was taken away. But you can quite happily start services by SystemV files just as you always have. Thats why all of this systemd hating nonsense is nonsense, systemd doesnt take away any functionality, it just adds on additional functionality. I find systemd to be much easier to use because of the declarative file format, there is much less wheel reinventing and results in easier to read files than bash code. The start up model is different, because its more powerful and allows you more flexibility to determine when a service to start based on prerequisites rather than just a sequence based start up. You can absolutely use a sequence based startup, but systemd allows you to configure it to start services on a much more precise set of conditions. People are just afraid of whats different, once you learn it, its worth it because it is much more powerful
    I speak only for myself, but i don't hate systemd because it took anything away.
    I don't actually HATE systemd. It works surprisingly well.
    But, i do believe in the Linux philosophy: do one thing, and do it well.
    And systemd does not abide by that philosophy. It wouldn't surprise me at all if systemd announced today that they will ship their own office suit within systemd in the future...
    All i'm calling out (and many others. maybe not all) is for systemd to be just an Init System. Everything else should be it's own project.
    And, with that 'simple' change, i would (gladly) use SystemD. The difference being: gladly, becasue it's already 'my' init system.

    It's not like we want it to die... we just want it to improve.

    Leave a comment:


  • nomadewolf
    replied
    Originally posted by Weasel View Post
    Am I the only one bothered (especially with systemd, but here too) by the "ctl" suffix short-hand for control? Seriously. It's CTRL on keyboards. initctrl sounds much better.
    Yes!
    Put an end to this madness!

    Leave a comment:


  • rtfazeberdee
    replied
    Originally posted by Bsdisbetter View Post

    Now I understand its taken over everything from login management to dns. I avoid it like the plague.
    You understand wrong. people have already explained about logind, but things like DNS are optional as it most of the systemd components

    Leave a comment:


  • lostdistance
    replied
    Originally posted by starshipeleven View Post
    Why not using busybox's light "init" instead? I don't think you need runlevels in embedded (which is the main difference, busybox's init does not support runlevels).
    The Intel Braswell Qseven module has plenty of processor performance and memory capacity, so I was able to avoid busybox in favour of the full size utilities.

    As it happens, I did use runlevels to boot the module into either a development system or a production system.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Bsdisbetter View Post

    Proves nothing other than more distributions use it and/or are forced to use it. For an end user who doesn't interact with systemd I can see no issue, but in my years-ago use of it it stank. Core dumps? Where are they hiding? Binary logs - crap can't forward them without installing rsyslog anyway. Now I understand its taken over everything from login management to dns. I avoid it like the plague.
    Forwards messages from the journal to other hosts over the network using syslog format RFC 5424 - systemd/systemd-netlogd

    The cannot forward over network bit kind of shows you something if a program is not put in the main systemd bundle users don't get it with a lot of distributions. So claim systemd does not have something. It magically shows what distributions are after as well.

    As stupid as it sounds distributions like to build less packages for system initialisation . To make a working systemd distribution you have to build less packages than what you have to build to have a working sysvinit one. Also you don't find the systemd project extras.

    Leave a comment:


  • rtfazeberdee
    replied
    Originally posted by sjukfan View Post

    So how does someone use logind without systemd?
    eh? a dependency makes something monolithic - i see your problem... comprehension. try running your distro without glibc (or similar)..... whooops that makes the distro monolithic. aahhhh abandon ship.

    Leave a comment:


  • Bsdisbetter
    replied
    Originally posted by starshipeleven View Post
    nah, most userbase is on Systemd these days.
    Proves nothing other than more distributions use it and/or are forced to use it. For an end user who doesn't interact with systemd I can see no issue, but in my years-ago use of it it stank. Core dumps? Where are they hiding? Binary logs - crap can't forward them without installing rsyslog anyway. Now I understand its taken over everything from login management to dns. I avoid it like the plague.

    Leave a comment:


  • Bsdisbetter
    replied
    Originally posted by unixfan2001 View Post
    Why would anyone use this horribly written, highly monolithic artifact from bygone ages?
    Lol sysvinit is not monolithic by any definition. Old it may be, but so what?

    Leave a comment:

Working...
X