Announcement

Collapse
No announcement yet.

Apple's OS X Launchd Being Ported To FreeBSD

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

  • #11
    Originally posted by blackout23 View Post
    Good since FreeBSDs current init system sucks monkey balls. It's the most slow thing I have ever used in my life. You totally forget that you have a SATA 3 SSD installed. My Arch Linux installation is able to boot faster than FreeBSDs init is able to set the hostname. I'm not kidding.

    It's systemd btw not Sytemd or SystemD or systemD.
    I think this plays into the aura of BS that surrounds the FreeBSD community. They constantly claim that their OS is "faster" than Linux, while the benchmarks claim otherwise. Even without systemd, sysv easily beats the pants off bsdinit. A recent interview with Marshall Mckusick shows just ignorant their leaders are. He claimed that "Windows teaches you to tolerate BSODs three time a week, so one time a week is welcome news". This is absolute horses***. I've been using Windows in home and office for a decade, on many machines, and I barely get one BSOD a year. The last time I got a BSOD that was not hardware related was three years ago for a GPU driver update.

    Comment


    • #12
      Originally posted by garegin View Post
      I think this plays into the aura of BS that surrounds the FreeBSD community. They constantly claim that their OS is "faster" than Linux, while the benchmarks claim otherwise. Even without systemd, sysv easily beats the pants off bsdinit. A recent interview with Marshall Mckusick shows just ignorant their leaders are. He claimed that "Windows teaches you to tolerate BSODs three time a week, so one time a week is welcome news". This is absolute horses***. I've been using Windows in home and office for a decade, on many machines, and I barely get one BSOD a year. The last time I got a BSOD that was not hardware related was three years ago for a GPU driver update.
      Is sysvinit really faster than bsdinit? I'm pretty sure all init systems I've seen finish in about 2 seconds flat (on a 5400RPM hard drive no less). As for the interview, well, that kind of claim is something I expect from most FOSS prononents, whether Linux, BSD, or something else.

      Comment


      • #13
        Originally posted by JX8p View Post
        Is sysvinit really faster than bsdinit? I'm pretty sure all init systems I've seen finish in about 2 seconds flat (on a 5400RPM hard drive no less). As for the interview, well, that kind of claim is something I expect from most FOSS prononents, whether Linux, BSD, or something else.
        It allows concurrent boot, so yes, its faster. Its also not much different from BSD init, one got links, other text entries. The only case where BSD init might win is slow file open operations.

        Comment


        • #14
          Originally posted by JX8p View Post
          Is sysvinit really faster than bsdinit? I'm pretty sure all init systems I've seen finish in about 2 seconds flat (on a 5400RPM hard drive no less). As for the interview, well, that kind of claim is something I expect from most FOSS prononents, whether Linux, BSD, or something else.
          my hunch is that the slowness has to do with poor hardware support/optimization. on some computers Linux boots unnaturally slow too. Usually those are funky firmware handoff bugs. The slowness I encounter is usually in the early stages of boot which confirms my theory. I've had a vanilla install of pfsense take twice longer to boot than a full install of Fedora with Gnome.
          At the end of the day, money talks and BS walks. If FreeBSD was superior to Linux, it's server marketshare wouldn't have been so terrible. And you can't give the "people just haven't heard of it" argument, because every Linux admin I have met has heard of FreeBSD and even played with it. Back in the early 90s FreeBSD actually had a lead over Linux, because the later was extremely immature (early Debian, Slackware), while the former was tried and tested for more than a decade (FreeBSD was just BSD without the AT&T bits)

          Comment


          • #15
            Originally posted by Marc Driftmeyer View Post
            It was about control, license restrictions and design goals.

            The world is better off with LLVM/Clang in it. It's what has gotten GCC to evolve.
            Yeah, pretty much. BSD-license has no control, is legally incompetent license (hence most switched to Apache), no restrictions (do what you want, close all you want), BSD init had the only design goal of being KISS for the sake of KISS which leads to poorly integrated system, lack of advanced functionality.

            On the other side the only misarchitecture of GNU was monolithic design because they feared emerging of proprietary plugins (which do happen) but on the other side it lead to piles of old hard to manage code. Still, LLVM is exact opposite, there are proprietary extensions available. I guess GNU couldn't care less. This is exact same thing with Gstreamer, with the topmost contributor being codec-selling/licensing/pro-patenting company. This is why you prefer VLC.

            Otherwise, GNU has powered BSD since forever and doesn't care what proprietary company those guys are powering next (like Blizzard, Netflix). GNU is also a political movement, that is protecting free software, where BSD is politically an anarchy being a tool for everything.

            That said, I hardly imagine why a tool needs launchd. Maybe because they have low resources, and Apple is kind enough to allow them that. Apple still holds all the rights, but they already use LLVM, CUPS, they prefer Apple to GNU, they couldn't care more.

            So, where is this shitornado about how launchd is incompatible with legacy and how non-KISS it is; like what pro-BSD trolls created about systemd?
            Last edited by brosis; 12-18-2013, 01:14 PM.

            Comment


            • #16
              Originally posted by brosis View Post
              It allows concurrent boot, so yes, its faster. Its also not much different from BSD init, one got links, other text entries. The only case where BSD init might win is slow file open operations.
              sysvinit has concurrent boot? since when?

              Comment


              • #17
                Originally posted by garegin View Post
                sysvinit has concurrent boot? since when?
                Since years ago.
                It's called startpar.

                @JX8p: From "loading init" to login: in 2 seconds? I doubt that.
                When people talk about how fast an init system is, it's about how fast it starts all daemons, not just how fast it starts the daemons it comes with.

                @brosis:
                You clearly haven't searched the BSD forums...I've read a bit of criticism of launchd there, all on the basis of not following unix design principles...

                Comment


                • #18
                  Originally posted by Ibidem View Post
                  @JX8p: From "loading init" to login: in 2 seconds? I doubt that.
                  When people talk about how fast an init system is, it's about how fast it starts all daemons, not just how fast it starts the daemons it comes with.
                  In both cases the same daemons were being started, near enough. Given that enabling /all/ daemons is a bad idea it's not really an issue of concern.

                  Comment


                  • #19
                    Originally posted by brosis View Post
                    On the other side the only misarchitecture of GNU was monolithic design because they feared emerging of proprietary plugins (which do happen) but on the other side it lead to piles of old hard to manage code. Still, LLVM is exact opposite, there are proprietary extensions available. I guess GNU couldn't care less. This is exact same thing with Gstreamer, with the topmost contributor being codec-selling/licensing/pro-patenting company. This is why you prefer VLC.
                    Are you serious ? Are you such a fanboy you're ready to accept bad design choices in a software just to avoid other reusing your work ? It's crazy. First, the license is supposed to achieve this goal, and second, just because you don't want other to reuse your work as they want (which harmless in my opinion, but ok, let's admit some people don't like that), you'll make your code worse, reducing the quality of the software for people who use it like you expected, and you make it harder for you to maintain ?

                    It's amazing you can just suggest such a thing...

                    Comment


                    • #20
                      Originally posted by enjolras View Post
                      Are you serious ? Are you such a fanboy you're ready to accept bad design choices in a software just to avoid other reusing your work ? It's crazy. First, the license is supposed to achieve this goal, and second, just because you don't want other to reuse your work as they want (which harmless in my opinion, but ok, let's admit some people don't like that), you'll make your code worse, reducing the quality of the software for people who use it like you expected, and you make it harder for you to maintain ?

                      It's amazing you can just suggest such a thing...
                      The GPL does not prohibit anyone from re-using code licensed under it. The GPL's "viral" nature attempts to extend the rights of code re-use even further. It is those who reject a project based on it being GPL that are responsible for less code re-use, not those that choose to cover their projects using the GPL

                      If a project's members choose to license their code under the GPL, those members should not be held responsible for the decisions of others not under their control to reject GPL code. On the other hand, those who reject GPL code do so because they don't want others to re-use their own derivatives of that code, so it is in fact those that reject the GPL and other copyleft licenses, not those that proliferate them, who are discouraging code re-use.

                      It is true that not every project entity that chooses the GPL for its output does so for the purposes of encouraging code re-use. Some projects make their work available under both GPL and proprietary licenses in order to enable the commercial entities financially backing the project to sell proprietary licenses to the code. Both such asynchronous licensing situations and permissive licensing situations have drawbacks compared to a pure GPL approach: for permissively licensed code, the rights of code re-use are not protected to the same extent that they are with the GPL, while for dual-licensed code, one or several entities is placed in a privileged position relative to that of other stakeholders.

                      However, since the output of such dually-licensed projects is available under a GPL license at no charge, the only potential adopters of the code who are directly affected by the availability of a proprietary license to the code are those that had already made the decision to reject the GPL. Those that were seeking to use GPL code in the first place can still do so and are not directly negatively impacted by the availability of proprietary licensing options.

                      Comment

                      Working...
                      X