Announcement

Collapse
No announcement yet.

Phasing Out SysVInit In openSUSE Raises Concerns

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

  • #11
    Originally posted by funkSTAR View Post
    So please stop accusing Phoronix for stirring up things. It is all Qts fault.
    Please stop thread jacking. It is agaist the rules.

    Just in case someone is interested in the topic: http://phoronix.com/forums/showthrea...ion-New-WebKit

    Comment


    • #12
      Originally posted by Teho View Post
      Please stop thread jacking. It is agaist the rules.
      This is not thread jacking. It is an answer to the person who brought up the subject of open core business. If you want to address this properly go tell the instigator.

      Thanks!

      Comment


      • #13
        Originally posted by Viper_Scull View Post
        I've been using systemd for 1 year on my arch installation. Some troubles at the very beginning, but running perfect since then.

        Teho is right, once you try systemd, there's no going back.
        I used systemd on arch for a while, but I'm back with sysvinit. Its just simpler to configure. And TBH on my machine I get no difference in boot time with systemd (and yes when I used it I used a "pure" systemd setup, with only native systemd units). The biggest improvement I get with my boot time in arch is using fedora-readahead + a light login manager (Right now I am quite liking LXDM)

        I'm already getting 15-17 seconds to a usable XFCE desktop with compiz/emerald/dockbarx on a 5400rpm laptop drive anyway
        Last edited by bwat47; 12-20-2011, 02:12 PM.

        Comment


        • #14
          Originally posted by deanjo View Post
          Systemd has huge issues with NFS shares in openSUSE 12.1. It tries to mount before the service is started which leads to boot times measured in minutes. Switching back to SysVinit however resolves the issue and boot times are back to around the 30 second mark.
          That doesn't sound at all like a bug in systemd, but in opensuse's configuration of it.

          Comment


          • #15
            Originally posted by bwat47 View Post
            I used systemd on arch for a while, but I'm back with sysvinit. Its just simpler to configure.
            Yeah right, except that it isn't.

            Comment


            • #16
              Originally posted by AnonymousCoward View Post
              Yeah right, except that it isn't.
              Yeah, it is.

              Comment


              • #17
                Interesting thread. Systemd provides hooks for scripts... so the scripting argument can really be used. If I found one things I didn't like is that in sysvinit you had the ability to set shell ulimits globally using /etc/initscript as a frontend to all scripts executed in init. I guess what I'd like to see is the idea of ulimits promoted somehow (if it were possible) into cgroups. Since cgroups are how some limits are already done....

                Just an idea.

                Systemd is where everything is going.... like it or not. Yes... if you follow the list there are still lots of things being tweaked... so there will be some people affected by it.... it will all get fixed. But I think we're beyond the ability to discuss anything but an all systemd future at this point.

                Is systemd easier? Yes and no. I think it's likely to be a better question to ask everyone a year from now. People tend to get used to the way things are done... and by that time, systemd will likely be considered easier. With that said, for those of us on heterogeneous networks, don't through away sysv style init since it still has some application there (though even there, much less than it used to).

                I like how runlevels are being simulated ... not sure if that's a lasting thing or not (or even something outside of openSUSE)... but does ease things a bit. Also, I think the idea of preserving the command "service" is going to work going forward (?). I mean, it's already an abstraction mechanism... vs. making systemctl calls for start/stop.

                I a bit concerned over the move to place everything into /usr... I understand the reasoning, and I suppose the idea of having a mandatory indirect point isn't necessarily a bad idea... so maybe this will grow on me. But I do wonder if the the folks pushing for this fully understand the reasons why it might be a bad idea (?).

                Also concerned about the future of syslog*.... and daemons that will have to be changed to operate properly in a systemd world.... all fixable no doubt, just very different.

                Comment


                • #18
                  Originally posted by droidhacker View Post
                  That doesn't sound at all like a bug in systemd, but in opensuse's configuration of it.
                  The quality issues in SUSE have been going on a lot longer than since they effectively became Microsoft Linux back in 2006 with the Novell deal, then were bought by a Microsoft-controlled shell company earlier this year. They have every reason to want to make Red Hat's software look bad. What better way than by making a half-hearted half-assed attempt at integrating systemd then claiming that the problems in the way they configured it were actually problems in its design?

                  Comment


                  • #19
                    Originally posted by DaemonFC View Post
                    The quality issues in SUSE have been going on a lot longer than since they effectively became Microsoft Linux back in 2006 with the Novell deal, then were bought by a Microsoft-controlled shell company earlier this year. They have every reason to want to make Red Hat's software look bad. What better way than by making a half-hearted half-assed attempt at integrating systemd then claiming that the problems in the way they configured it were actually problems in its design?
                    Yeah only that these things just don't work like that. SuSE is owned by Attachmate Corporation and their goal is to make as much profit to their owners as possible not to please some other corporation. Do you honstly believe that if Microsoft was somehow sabotaging Novell that none of the thousands of developers would have spoken up? OpenSuSE is developed in the open and that's why things like that do not happen is secret. If you don't have any concrete evidence then spouting crap like that is just discrespectful towards the people who spent their time working on project that helps improve the Linux and open source ecosystem in total. But sure if you really have something please share.

                    Comment


                    • #20
                      Pretty much all "Open" SUSE does is use other distributions as an upstream, and apparently integrate it poorly. They don't really do a lot of their own stuff anymore.

                      "AttachMSFT" is a Microsoft Gold Partner.

                      The only thing their SUSE division is there to do is trumpet the few remaining proprietary software applications they scavenged from the wreckage of Novell and finish running SUSE into the ground, while claiming to offer cut rate Red Hat support hijacking in partnership with Microsoft (complete with a joint SUSE/Microsoft site that is signed with a Microsoft SSL certificate).

                      Businesses that fall for that will depend on Microsoft for support, and once you replace redhat-release with something from "MicroSUSE", you're not only no longer running RHEL, but you lose all of the certifications that RHEL has, including the ones that they have earned to verify that RHEL is dependable and secure enough for US government agencies.

                      I don't trust "Open" SUSE because they depend on the people at "AttachMSFT"'s "MicroSUSE" division holding the purse strings, owning the copyrights and trademarks to a good part of the distribution, deciding what goes in and how it is configured, or often, misconfigured...
                      Last edited by DaemonFC; 12-20-2011, 11:00 PM.

                      Comment

                      Working...
                      X