Announcement

Collapse
No announcement yet.

Systemd Continues Getting Bigger, Almost At 550k Lines Of Code

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

  • #41
    Originally posted by phred14 View Post
    I do not wish to run it. Do you have a problem with that? Are you telling me that I am being stupid and wrongthinking because I don't wish to run systemd? I'm not even getting into technical issues, let's ignore that for the moment.

    My problem is that it is getting to be rather difficult to not use it. Fortunately I'm running Gentoo on my systems, and the biggest problem is masking Gnome back to pre-3.8 while I figure out how to replace all of the pieces. Are you telling me I should not have the freedom to not use systemd?
    You're totally free not to use systemd, but you're confusing freedom with authority. You don't have the authority to ask others to work for your convenience for free.

    Supposedly, you have no freedom to choose a kernel neither, you have to use the Linux kernel want it or not. Now go blame the Linux kernel developers because they didn't develop several kernels simultaneously so that you could choose the one you liked better. The same can happen with other projects where just a team is seriously working in a task and they could be blamed for not having a menu selection of alternatives for you to choose. I hope the hard-working developers don't have to read comments likes those from you since I think they don't deserve them.

    Having said that, Debian isn't dumping all other init systems so you can use Debian and choose not to use systemd, at least while there's people willing to do that work for you. Remember it and be thankful.

    Comment


    • #42
      Originally posted by Vim_User View Post
      For me it isn't actually about technical issues at all if I should run systemd or not.
      For me the core question is: Should I put a collection of software at the very core of my systems that is maintained and developed with people like Kay Sievers and Lennart Poettering as heads of the project, with their very poor track record of blaming bugs on others, being zealots about their project, ..., to the point that the head developer of the most important open source project in the world, Linus Torvalds, tells them to fuck of until they get their shit together.

      The clear answer from me is: No, until you get your shit together I will not put systemd on my systems or systems that I am responsible for. systemd might be a good project, but the developers simply are narcissists who think that they are always right and everybody else is wrong. Nope, not on my systems. Replace Sievers and Poettering and I may think about using systemd.

      This of course sounds like hate, but in reality it is a trust issue, simple as that. I don't trust them, I don't use their software. Many of you argue the same way about Microsoft or Apple, I don't see why it shouldn't be valid here.
      It's your distribution developers that are putting systemd in your systems, if you don't trust you should use another distribution. Simple as that.

      If developers thought they're always wrong and everyone else is right we'd had users that think they're always right and everyone else is right writting code. Please, no!

      Comment


      • #43
        Originally posted by porken View Post
        Then why can't they spin it off into separate libraries so that they can be used with other programs rather than just with systemd and systemd alone, without having to be spun off by some other developer?
        You mean like:
        /usr/lib/libgudev-1.0.so
        /usr/lib/libgudev-1.0.so.0
        /usr/lib/libgudev-1.0.so.0.2.0
        /usr/lib/libsystemd-daemon.so
        /usr/lib/libsystemd-daemon.so.0
        /usr/lib/libsystemd-daemon.so.0.0.12
        /usr/lib/libsystemd-id128.so
        /usr/lib/libsystemd-id128.so.0
        /usr/lib/libsystemd-id128.so.0.0.28
        /usr/lib/libsystemd-journal.so
        /usr/lib/libsystemd-journal.so.0
        /usr/lib/libsystemd-journal.so.0.11.5
        /usr/lib/libsystemd-login.so
        /usr/lib/libsystemd-login.so.0
        /usr/lib/libsystemd-login.so.0.9.3
        /usr/lib/libsystemd.so
        /usr/lib/libsystemd.so.0
        /usr/lib/libsystemd.so.0.1.0
        /usr/lib/libudev.so
        /usr/lib/libudev.so.1
        /usr/lib/libudev.so.1.4.0
        /usr/lib/libnss_myhostname.so.2

        Comment


        • #44
          Originally posted by berarma View Post
          It's your distribution developers that are putting systemd in your systems, if you don't trust you should use another distribution. Simple as that.
          Thank you for voicing one of the reasons why I finally switched to Gentoo.

          Comment


          • #45
            Lots of untrusted devs in FOSS, but monitoring is possible

            Originally posted by Vim_User View Post
            For me it isn't actually about technical issues at all if I should run systemd or not.
            For me the core question is: Should I put a collection of software at the very core of my systems that is maintained and developed with people like Kay Sievers and Lennart Poettering as heads of the project, with their very poor track record of blaming bugs on others, being zealots about their project, ..., to the point that the head developer of the most important open source project in the world, Linus Torvalds, tells them to fuck of until they get their shit together.

            The clear answer from me is: No, until you get your shit together I will not put systemd on my systems or systems that I am responsible for. systemd might be a good project, but the developers simply are narcissists who think that they are always right and everybody else is wrong. Nope, not on my systems. Replace Sievers and Poettering and I may think about using systemd.

            This of course sounds like hate, but in reality it is a trust issue, simple as that. I don't trust them, I don't use their software. Many of you argue the same way about Microsoft or Apple, I don't see why it shouldn't be valid here.
            To me the definition of "trust" is do I consider the devs likely to drop in a keylogger or tracking software for a corporate employer like Google or the NSA, and do I think someone could do this and not be found, thus removing the deterrent to NSA or Google-funded sabotage.

            If Systemd was a closed binary, this trust issue would be deadly serious with no solution but avoidance. Same for Firefox. As open source software, however they can be audited formally or informally. I expect that Firefox is rather closely watched and expect that Systemd's haters will be constantly trying to pick it apart, so nobody could hide something in either without a serious risk of getting caught. Remember that the exact commits that introduce things like heartbleed can be found and thus traced to their authors-if anyone is looking. Much better than an obscure init system nobody checks, where a programmer skilled in obfuscated C could hide anything and forget about being caught.

            From where I stand, there are a lot of coders I do not trust in too many projects to keep track of them all, since I consider outfits like Google(they try to track everyone) to be malicious.There was that former snitch against ALF who turned up in Mozilla, forcing me to delay using Firefox 4 until enough time passed for any unwelcome additiions to be found. Since I cannot screen out all untrusted programmers-and probably nobody in all of FOSS can trust all other programmers, I have to rely on checks and balances. In addition, we must all learn from the Heartbleed mess to keep really important stuff like cryptagraphy under a microscope,

            Does anyone here really suspect a keylogger in say, systemd cryptsetup generators or the systemd password agent? I wrote my own code to unlock my disks but will be going over the systemd code for both of these mostly out of curiosity but also to see if I can find anything really stupid or malicious. I expect to find nothing, I am not an expert in C (so I would miss obfuscated C coding) and for Red Hat to get caught bugging cryptsetup in Systemd would probably put them permanently out of business.

            Comment


            • #46
              Renaming GNU/Linux

              Soon, we can talk about Systemd/Linux or the Torvald-Poettering OS.

              Cool.

              Comment


              • #47
                Originally posted by Luke View Post
                To me the definition of "trust" is do I consider the devs likely to drop in a keylogger or tracking software for a corporate employer like Google or the NSA, and do I think someone could do this and not be found, thus removing the deterrent to NSA or Google-funded sabotage.
                And to me, the definition of trust is broader-- I want to trust it to not be a steaming pile of crap that I all but *must* migrate to in 2 years and away from again in 8, and trust them to not make it happen that way. Saying "I trust the Funtoo guys to not push systemd on me in the near future" is as important as never finding a keylogger because there isn't one. When I started in Gentoo ~10 yrs back, they recommended Reiserfs and now Funtoo recommends XFS. I trust them to not lead me down the path toward massive data loss, and I haven't lost yet from anything other than carelessness on my part. It's the little things.

                Comment


                • #48
                  Thorsten Glaser put together a useful Debian package called "systemd-must-die"; install and hold the package and it will prevent any systemd components being installed on upgrade, or as a depencency of something else. Available from:
                  http://users.unixforge.de/~tglaser/d...bilos-support/

                  If some useful package in Debian testing (jessie pre-release) turns out to be uninstallable because of this, make sure to tell the maintainer and/or mention it on a relevant mailing list. I think enough people care to make sure systemd is not a required component and everything will be still usable (except for gdm3/gnome-shell, whose maintainers will not co-operate).

                  systemd-must-die may need to be modified in the future to allow systemd-shim to be installed; we'll see if it turns out to be necessary.

                  Comment


                  • #49
                    Originally posted by doom_Oo7 View Post
                    And why can't VLC spin off its functions for rendering subtitles and changing the volume of a sound into separate libraries so it can be used with other programs rather than just with VLC?
                    dumbst question ... for a long long time. or should i better say answer?

                    Comment


                    • #50
                      Originally posted by Scimmia View Post
                      You mean like:
                      /usr/lib/libgudev-1.0.so
                      /usr/lib/libgudev-1.0.so.0
                      /usr/lib/libgudev-1.0.so.0.2.0
                      /usr/lib/libsystemd-daemon.so
                      /usr/lib/libsystemd-daemon.so.0
                      /usr/lib/libsystemd-daemon.so.0.0.12
                      /usr/lib/libsystemd-id128.so
                      /usr/lib/libsystemd-id128.so.0
                      /usr/lib/libsystemd-id128.so.0.0.28
                      /usr/lib/libsystemd-journal.so
                      /usr/lib/libsystemd-journal.so.0
                      /usr/lib/libsystemd-journal.so.0.11.5
                      /usr/lib/libsystemd-login.so
                      /usr/lib/libsystemd-login.so.0
                      /usr/lib/libsystemd-login.so.0.9.3
                      /usr/lib/libsystemd.so
                      /usr/lib/libsystemd.so.0
                      /usr/lib/libsystemd.so.0.1.0
                      /usr/lib/libudev.so
                      /usr/lib/libudev.so.1
                      /usr/lib/libudev.so.1.4.0
                      /usr/lib/libnss_myhostname.so.2
                      no, he means like libs that work independed of each other...

                      Comment

                      Working...
                      X