SysVinit 3.11 Released With An "Important Feature" At Long Last

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

  • TheMightyBuzzard
    replied
    Originally posted by anda_skoa View Post
    You can selectively build any daemon in the systemd repository right?
    Don't need systemd-networkd then you don't build/package it.
    In theory, yes. In practice, "lol fu".

    Way too many cultist userspace programmers have made their code dependent on one specific init system when it has absolutely no reason to be. That should never have happened with anything except system utilities that deal directly with the systemd init system and no other. That's not systemd's fault but it absolutely is the fault of its cultists.

    Leave a comment:


  • anda_skoa
    replied
    Originally posted by skeevy420 View Post
    Desktop is but one part of the Graphical Spectrum. There are many, many combinations of things like form factors, input methods, graphical toolkits, rendering and compositing (2D/3D/X11/Wayland), desktop environments, and more that make up the Graphical Spectrum of Linux.
    I do agree, just that "desktop" was the only simplification in the other user's post that could somewhat work.

    The other two just cover way to many scenarios.

    Originally posted by skeevy420 View Post
    How does that relate to the init system?
    The thing is with init systems other than systemd that they are just that and in certain use cases you then end up having lots of efforts to find solutions for things that the ecosystem around systemd brings for free.

    Like, as I wrote before, D-Bus APIs for all kind of system functionality.

    Originally posted by skeevy420 View Post
    IMHO, I think systemd needs to figure out how to strip itself down to what the operating environment actually needs once the system is configured into its role
    Isn't that already the case?

    You can selectively build any daemon in the systemd repository right?
    Don't need systemd-networkd then you don't build/package it.


    Leave a comment:


  • mobadboy
    replied
    Originally posted by Weasel View Post
    With a million daemons running in the background?

    systemd needs to be exorcised. Waste of CPU power and memory.
    πŸ€‘β€‹πŸ€‘β€‹β€‹πŸ€‘β€‹πŸ€‘β€‹β€‹πŸ€‘β€‹πŸ€‘β€‹β€‹

    tell me more about how you are thoroughly unfit to run anything

    Leave a comment:


  • Weasel
    replied
    Originally posted by intelfx View Post
    Oh, it’s already there since day 1.
    With a million daemons running in the background?

    systemd needs to be exorcised. Waste of CPU power and memory.

    Leave a comment:


  • TheMightyBuzzard
    replied
    Originally posted by Developer12 View Post
    This is pointless when the time honoured and far more sane solution has been to put the complicated logic in a script file and call the script file.
    Truth. This isn't a feature, it's an anti-feature. Previous to this you could be absolutely assured that all logic rested in the init script rather than ever having to even check the inittab. Now that it's an option, idiots are going to use it and spread out the logic into multiple files instead of one.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by anda_skoa View Post

    I don't think one can simplify it to that level.

    While "desktop" might work as a category, the other two are too much of a spectrum themselves.

    Embedded, for example, covers a really wide range of devices.

    On one hand it might be unnecessary overhead for devices with restricted resource, on the other hand, once you are in the area of having GUI and user configurability, it becomes really nice to have access to the systemd ecosystem.

    It makes application development much easier of you can access system features through D-Bus, e.g. talking to timedated when the user changes the device time.
    Desktop is but one part of the Graphical Spectrum. There are many, many combinations of things like form factors, input methods, graphical toolkits, rendering and compositing (2D/3D/X11/Wayland), desktop environments, and more that make up the Graphical Spectrum of Linux. It's not like the spectrums are isolated, either. There are Embedded Desktops, Graphical Servers, Graphical Cluster/HPC monitoring, and all sorts of wacky combinations people use to fulfill their needs.

    How does that relate to the init system? Well, the more capabilities that the graphical environment is expected to be able to do, the more features the init system has to have to be able to cover more and more potential roles the system might be used for. The more fixed of a role the hardware and software is being used for, the less features and abilities the init system actually needs. An embedded graphical with one display and the one way of doing things doesn't necessarily need the full features of systemd like a generic graphical desktop or workstation might. Even the desktops and workstations don't need the full features of systemd once configured into a fixed-function role, but if they want to get reconfigured into a new role then being able to easily "systemctl start/stop some_stuff" is damn handy. If the role will never change, does it need all of that?

    IMHO, I think systemd needs to figure out how to strip itself down to what the operating environment actually needs once the system is configured into its role; graphical or not is rather irrelevant to the overall problem. Not only would that help with the system using excessive space, the system wouldn't contain unnecessary and potentially exploitable functionality should someone obtain root.

    The problem with that "solution" is that it assumes we're using the minimal amount of storage which begs the question, "Does Embedded have to have the same limitations in the 2020s as it did in the 1990s or the 1960s?" This is an era where we can store TBs of storage in less space than a dime. In this day and age, at what point does using minimalist storage become a problem caused by chintzy​ capitalism leading to bad product designs and not updating inefficient hardware because it still works?

    What's the real solution? Adapting a one-size-fits-all software solution to work in more places, software using less, or adapting hardware to better align with the one-size-fits-all software, hardware coming with more? Or is it something different like keeping on with the status quo where we use the distribution that makes the most sense for our needs even if that goes against using common standards and practices?

    Does Yann Collet need to develop LZ5?

    Leave a comment:


  • Raka555
    replied
    Originally posted by DesktopLinux

    or perhaps an asteroid that will wipe out all "sysv init /compile everything from source / don't use graphical tools only command line" dinosaurs?

    No, the asteroid is not necessary. You will die out slowly and in the process you will make a lot of noise but still remain irrelevant.

    Why don't you recompile kernel once more with few more flags, it will calm you down
    I am not making noise, I am writing code... But you are probably right in that it will still be futile.
    Last edited by Raka555; 22 October 2024, 10:00 AM.

    Leave a comment:


  • andyprough
    replied
    Originally posted by DesktopLinux

    or perhaps an asteroid that will wipe out all "sysv init /compile everything from source / don't use graphical tools only command line" dinosaurs?

    No, the asteroid is not necessary. You will die out slowly and in the process you will make a lot of noise but still remain irrelevant.

    Why don't you recompile kernel once more with few more flags, it will calm you down
    LOL, "Join Date: Oct 2024". Abhors compiling and any disgusting person who would ever compile. It's like a meme has sprung to life.

    Leave a comment:


  • reba
    replied
    Originally posted by Raka555 View Post
    The time is ripe for a revolution against "Linux". Where "Linux" came to mean linux kernel, glibc and systemd and the bloatware technologies like flatpak/snap/appimage ...
    Burn them all! For progress!

    Leave a comment:


  • Raka555
    replied
    The time is ripe for a revolution against "Linux". Where "Linux" came to mean linux kernel, glibc and systemd and the bloatware technologies like flatpak/snap/appimage ...

    Leave a comment:

Working...
X