Announcement

Collapse
No announcement yet.

Debian Developers Take To Voting Over Init System Diversity

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

  • Danielsan
    replied
    Originally posted by oiaohm View Post
    No its not unfair. There is something you don't understand of the problem.
    You got it... :-p

    By the way, thanks for the time you taking for a so detailed explanation. From the page of Freedesktop is not clear if logind exist before of systemd, it just says that exist from version 30 and that: systemd's logind service obsoletes ConsoleKit which was previously widely used on Linux distributions.

    If systemd incorporated everything up to Gnome3 or if they just met each other halfway doesn't change the situation. And I hope that Debian will be able to provide alternatives to systemd like Gentoo does to OpenRC. And I will totally fine with a stripped version of systemd that does less, something without journalctl, socket, target, service, cron, etc...

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Danielsan View Post
    We should always have alternatives especially when the "standards" come from a corporation rather than a community.
    While I am mostly agreed with you, let me say that today we don't have alternative, or at least the majority of the distros do not provide alternatives. Hard coding systemd in Gnome3 has been quite unfair.
    No its not unfair. There is something you don't understand of the problem.

    Originally posted by Danielsan View Post
    Before you were free to use Sysvinit or Upstart without issues,
    This is not in fact true. Ubuntu upstart was patched into Ubuntu Gnome to attempt to prevent particular issues and if you forced Ubuntu of the time to use sysvinit you would have issues.

    Please note you said Sysvinit/upstart. Notice you did not mention like runit or other options. Upstart and sysvinit kind of got along because they could use the same configuration in udev and consolekit(precursor to logind). But items like runit would not work dependably before systemd existed.

    Init/service management diversity did not exist in a functional way before the existence of systemd. Reality in that regard nothing much has changed.

    Originally posted by Danielsan View Post
    https://wiki.gentoo.org/wiki/Elogind


    Anyway I am not a programmer but I am still able to use my brain and constraining Gnome3 with systemd has been always for me an arbitrary decision rather than a mandatory feature.
    Gnome going systemd for logind was not arbitrary derision. Something that is overlooked is logind starts before systemd exists as a consolekit experiment. Objective to work out how to run X11 server without being root user was what logind was about of course we have not fully got that that point yet in most distributions.

    Also logind before systemd was to work out how to prevent leaked processes by users from preventing users from logging back in.

    logind/elogind and is precurser consolekit both have been major pain points when it has come to running multi init systems.
    udev/eudev have also been major pain points when it come to running multi init systems to the point well before the existance of systemd it was suggest that udev should be taken into the Linux kernel mainline to prevent the issues between service management systems and force some unified discussion between service management solutions on how udev stuff should be done.

    Really at some point we do need to sort out device management(udev/eudev) and login session management(logind/elogind and is precurser consolekit) in away that when you have these that they are not limit service management system compatible.

    There is user/DE session management that is what the Gnome DE is working on replacing theirs with users mode systemd and tried usermode upstart in the past.

    Lot of this is lets blame systemd while complete missing that these problems have existed on linux since 1993 and that functional service management has been fiction. Even systemd had to emulate sysvinit so that it could get market share in the first place. Any init/service management solution that could not emulate sysvinit has been dead.

    You want to say today we don't have alternatives. The reality is we have not had proper alternatives for over 2 decades. Remember upstart is like systemd where it can emulate sysvinit this is also why there appears to be some compatibility until you start altering settings on a upstart system to suit upstart well then sysvinit booting fails. Yes altering udev and consolekit back in the day to suit upstart broken sysvinit mode.

    So what diversity in fact.

    Leave a comment:


  • Danielsan
    replied
    Originally posted by intelfx View Post
    Then you would surely be able to propose a patchset, that would remove this "unnecessary" dependency with no loss of functionality or any other downsides. Please go ahead and propose such a patchset. I will personally see to it being merged.



    And as Cynyr wrote above using GTK does not prevent to use QT or EFL runtime, as systemd does.

    Anyway I am not a programmer but I am still able to use my brain and constraining Gnome3 with systemd has been always for me an arbitrary decision rather than a mandatory feature.

    Leave a comment:


  • cynyr
    replied
    Originally posted by intelfx View Post

    How about "hard coding" Gtk in GNOME 3? Do you feel that it's "unfair" that it's not possible to use GNOME 3 without Gtk?

    It's software. Software has dependencies. That's the way it is.
    Sure, but having GTK3 installed doesn't prevent me from also having QT5 installed, or even GTK2, or using QT5 apps. Surely any talk of this freedom needs to include "selectable at runtime" as a requirement.

    Leave a comment:


  • kindu smith
    replied
    If you observe systemd's behavior carefully。 enable or disable a service, you will basically create or delete a link under / etc / systemd / system. So essentially there is no violation of the unix kiss principle. The only criticism is that the command used is too long, and the journalctl log file is a binary format.

    Leave a comment:


  • intelfx
    replied
    Originally posted by Danielsan View Post
    Gnome3 was designed as is but there wasn't a real necessity to do that.
    Are you sure about that?

    Then you would surely be able to propose a patchset, that would remove this "unnecessary" dependency with no loss of functionality or any other downsides. Please go ahead and propose such a patchset. I will personally see to it being merged.

    Leave a comment:


  • Danielsan
    replied
    I am the least person to say that but GTK are the libraries and the widgets you built Gnome with, which has been bonded with systemd components like udev and logind, and since the moment all the GTK Desktop Environment share a lot of Gnome libraries all of those are obligated to use systemd as well. Unless you use the forks eudev and elogind like as GuixSD and Gentoo. Gnome3 was designed as is but there wasn't a real necessity to do that.
    Last edited by Danielsan; 10 December 2019, 12:52 PM.

    Leave a comment:


  • intelfx
    replied
    Originally posted by Danielsan View Post
    Hard coding systemd in Gnome3 has been quite unfair. Before you were free to use Sysvinit or Upstart without issues, not today
    How about "hard coding" Gtk in GNOME 3? Do you feel that it's "unfair" that it's not possible to use GNOME 3 without Gtk?

    It's software. Software has dependencies. That's the way it is.

    Originally posted by Danielsan View Post
    One of the coolest thing of GNU & Linux is also the modularity
    Nobody is taking away your modularity. It's just the choice of "modules" that you can connect to GNOME3 has a size of 1. Unfortunately, there is nobody willing to write an alternative "module" that would implement the interfaces GNOME3 wants to use.

    But if someone was to write it, I assure you, it would plug into GNOME3 just fine.

    Leave a comment:


  • Danielsan
    replied
    Originally posted by intelfx View Post

    I don't see anything in that Social Contract that wouldn't apply to Arch.

    What Debian has to codify on paper in form of various "Social Contracts", Arch simply understands as common sense.
    I gently disagree.

    Leave a comment:


  • Danielsan
    replied
    Originally posted by oiaohm View Post
    There is not really fragmentation and that is the problem. The idea that we should always have alternatives is a horrible one when it done unbounded.
    We should always have alternatives especially when the "standards" come from a corporation rather than a community.
    While I am mostly agreed with you, let me say that today we don't have alternative, or at least the majority of the distros do not provide alternatives. Hard coding systemd in Gnome3 has been quite unfair. Before you were free to use Sysvinit or Upstart without issues, not today, I can't use whatever on Debian, I have to use another distro like Devuan. I don't want say we have to come back to sysvinit, but I would like to have the freedom to use OpenRC instead of systemd, or Shepherd on Debian. One of the coolest thing of GNU & Linux is also the modularity, and have the option the change a critical component with the one you think is better for your job is a great feature.

    Leave a comment:

Working...
X