Announcement

Collapse
No announcement yet.

Apple's OS X Launchd Being Ported To FreeBSD

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

  • crymsonpheonix
    replied
    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.

    Leave a comment:


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

    Leave a comment:


  • deanjo
    replied
    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)

    Leave a comment:


  • AJenbo
    replied
    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.

    Leave a comment:


  • endman
    replied
    systemd is non-portable by deliberate design
    That is correct

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

    Leave a comment:


  • Delgarde
    replied
    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.

    Leave a comment:


  • Delgarde
    replied
    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...

    Leave a comment:


  • intellivision
    replied
    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.

    Leave a comment:


  • Serge
    replied
    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.

    Leave a comment:


  • enjolras
    replied
    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...

    Leave a comment:

Working...
X