Announcement

Collapse
No announcement yet.

Apple's OS X Launchd Being Ported To FreeBSD

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

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