Announcement

Collapse
No announcement yet.

Apple's OS X Launchd Being Ported To FreeBSD

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

  • #16
    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, 12:14 PM.

    Comment


    • #17
      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


      • #18
        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


        • #19
          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


          • #20
            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


            • #21
              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


              • #22
                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...
                It doesn't even matter, systemd is clearly a Linux only component since it requires several Linux only features such as cgroups.

                No amount of license changes will effect that, although hopefully there will be some API compatibility between launchd and systemd.

                Comment


                • #23
                  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
                  Nonsense... GCC isn't monolithic because of proprietary plugins - it's monolithic because it's an ancient code base that never had any pressure to make it modular. Whereas LLVM has been designed that way from the start, in the assumption that people want to integrate it with other tools like IDEs, instead of running from a command line or Makefile...

                  Comment


                  • #24
                    Originally posted by intellivision View Post
                    It doesn't even matter, systemd is clearly a Linux only component since it requires several Linux only features such as cgroups.
                    Yeah, systemd is non-portable by deliberate design - it's built to take maximum advantage of OS capabilities, not to try to work around key features being implemented differently (or not at all) on different platforms. Lennart's advice to porters is to reimplement the systemd APIs on top of native features, rather than trying for a portable codebase.

                    Comment


                    • #25
                      systemd is non-portable by deliberate design
                      That is correct

                      http://aboutthebsds.wordpress.com/20...-fear-systemd/

                      Comment


                      • #26
                        Originally posted by intellivision View Post
                        It doesn't even matter, systemd is clearly a Linux only component since it requires several Linux only features such as cgroups.

                        No amount of license changes will effect that, although hopefully there will be some API compatibility between launchd and systemd.
                        Radeon and the Intel driveres required KMS and othere Linux only features, yet they where eventually ported.

                        Comment


                        • #27
                          Originally posted by garegin View Post
                          The last time I got a BSOD that was not hardware related was three years ago for a GPU driver update.
                          Oh I have one sure fire way of bluescreening Windows 8 / 8.1 with Virtualbox 4.2 series.

                          Poof!!! DRIVER_IRQL_NOT_LESS_OR_EQUAL (VBoxUSBMon.sys)

                          Comment


                          • #28
                            Originally posted by endman View Post
                            Oh Geez, you aren't really quoting that idiot are you?

                            Comment


                            • #29
                              Originally posted by Pawlerson View Post
                              So, sysv init is now a bad guy for bsd?
                              FreeBSD does not, and never has, used SysV init; it uses BSD init.

                              Comment


                              • #30
                                Originally posted by deanjo View Post
                                Oh I have one sure fire way of bluescreening Windows 8 / 8.1 with Virtualbox 4.2 series.

                                Poof!!! DRIVER_IRQL_NOT_LESS_OR_EQUAL (VBoxUSBMon.sys)
                                That is exactly what "hardware related" means. That's a driver trying to overwrite memory that doesn't belong to it, probably freed memory.
                                The only other meaning of "hardware related" in this context is actually faulty hardware, but it doesn't apply to a virtual driver, of course.

                                Comment

                                Working...
                                X