Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 25

Thread: Phasing Out SysVInit In openSUSE Raises Concerns

  1. #11
    Join Date
    Jul 2010
    Posts
    589

    Default

    Quote 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

  2. #12
    Join Date
    Dec 2011
    Location
    Basement
    Posts
    389

    Default

    Quote 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!

  3. #13
    Join Date
    May 2010
    Posts
    684

    Default

    Quote 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 at 02:12 PM.

  4. #14
    Join Date
    Oct 2009
    Posts
    2,052

    Default

    Quote 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.

  5. #15

    Default

    Quote 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.

  6. #16
    Join Date
    May 2010
    Posts
    684

    Default

    Quote Originally Posted by AnonymousCoward View Post
    Yeah right, except that it isn't.
    Yeah, it is.

  7. #17
    Join Date
    Nov 2007
    Posts
    44

    Default

    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.

  8. #18
    Join Date
    Apr 2011
    Posts
    405

    Default

    Quote 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?

  9. #19
    Join Date
    Jul 2010
    Posts
    589

    Default

    Quote 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.

  10. #20
    Join Date
    Apr 2011
    Posts
    405

    Default

    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 at 11:00 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •