Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Apple Businesses Operating Systems BSD

NetBSD's COMPAT_DARWIN Adds XDarwin Support 255

Posted by timothy from the agglomeration dept.
Dan writes "NetBSD's Emmanual Dreyfus says that COMPAT_DARWIN is now able to run Mac OS X's XDarwin (this is, the X Window server for Darwin). The server is fully functional: display, keyboard and mouse work. He says that running Darwin has no interest in itself, but having it working ensures that NetBSD's IOKit (1) emulation is good enough to be used. Darwin is Apple's Mac OS X core. A fully functional Darwin binary compatibility on NetBSD/powerpc & NetBSD/i386 will imply getting MacOS X libraries to run any Mac OS X program, just like NetBSD is now able to run binaries from Linux, FreeBSD, Solaris, and many other OSes."
This discussion has been archived. No new comments can be posted.

NetBSD's COMPAT_DARWIN Adds XDarwin Support More

NetBSD's COMPAT_DARWIN Adds XDarwin Support

Comments Filter:

  • Next stop, Quartz... then Aqua (Score:3, Funny)

    by corebreech ( 469871 ) on Monday November 03, 2003 @01:30AM (#7375669) Journal
    It's ironic that right after the story Technology Spending On The Rise, we get a story about how to run Apple software under a free OS.

    Or is that, iconic?
    • hmm OSX runs on a free OS already ; Darwin. goto the dev site and download the code. This is a pretty pointless project aside from the "cool hack" nature of it. There is really nothing new that can come out of it since you are just going from one unix on PPC to another and they are both free

      • Re:Next stop, Quartz... then Aqua (Score:4, Interesting)

        by IM6100 ( 692796 ) <elben@mentar.org> on Monday November 03, 2003 @02:02AM (#7375798)
        Actually, that isn't the case at all.

        NetBSD has a substancial cross-platform 'packages' library of source code and a robust build system. Most packages, when they appear ready for one architecture, are ready and buildable on any other architecture. If you're not going to be running MacOS stuff in that 'Macintosh' API layer(s), you're FAR BETTER OFF running NetBSD/macPPC than you are running Darwin alone on your Apple hardware. Furthermore, if you run multiple architectures, with NetBSD you'll be able to admin the same exact /etc structure on your i386, sparc, sparc64, macPPC, prep, m68k, etc. boxes.

        I threw Darwin on my beige G3 machine last week, from the ISO downloadable from the OpenDarwin project. It installed fine and booted properly (I had specifically told it what drive to install itself on and it instead installed on a different drive, wiping out my MacOS 9 partition, but I don't hold a grudge about that)

        I looked at the Unix command prompt, said 'gee whiz, it works, but there's no packages to run' and took it off. I noted while reading the howtos at opendarwin.org that the binary packages they have built require you to use the MacOS X installer to put them on your system.

        I do not own a copy of MacOS X. It was a no-starter proposition for me. Nor am I about to buy OS X for a Beige G3 just to install 'free' software packages on it.
        • I had specifically told it what drive to install itself on and it instead installed on a different drive, wiping out my MacOS 9 partition, but I don't hold a grudge about that
          Don't hold a grudge? Hell, that sounds to me like a feature.

        • Re:Next stop, Quartz... then Aqua (Score:2, Insightful)

          by Anonymous Coward
          The NetBSD pkgsrc collection works on Darwin [netbsd.org].

          I agree that you'd be a little nuts to bother, but please don't cloud the issue. Software availability for both NetBSD and Darwin is really pretty good; the reason to pick one over the other should be based on the kernels, if you want to be technical, or licenses, if you want to be political. (Technically: NetBSD is NetBSD, monolithic but proven; Darwin is xnu, a curious hack on Mach. Some people dig it, some people don't trust it.)

          If you're a UNIX neophyte,
        • DarwinPorts [opendarwin.org] will allow you to install ports from source, and appearently yum [opendarwin.org] offers the ability to install binaries. The point being that Darwin is supposed to be a fully functional unix, not just the little bastard child that's kept in the cellar. Mostly useful I think when (as you pointed out) you want to keep multiple systems with identical configurations, or things that relate to administering or serving to os x machines, when you don't need the gui.
          • I like the idea of DarwinPorts, but the implementation is missing quite a bit.

            As of the last time I tried to use dports, there was no tracking of installed packages and no upgrade functionality beyond manually uninstalling a package, fetching the latest package tree from CVS, and then installing the new one.

            The package selection is not bad, but there's certainly quite a bit of work to be done before it becomes a viable package system for OS X.

    • Re:Next stop, Quartz... then Aqua (Score:5, Insightful)

      by johram ( 660233 ) on Monday November 03, 2003 @01:59AM (#7375781) Journal
      The point isn't "free" as in "free-OS". The point is embracing open standards.

      Apple might have a proprietary OS in Panther but it is based on standards that allow for easy networking and integration into existing frameworks.

      • Standards not always good (Score:5, Insightful)

        by 0x0d0a ( 568518 ) on Monday November 03, 2003 @08:43AM (#7376770) Journal
        Apple might have a proprietary OS in Panther but it is based on standards that allow for easy networking and integration into existing frameworks.

        This is just an aside, and doesn't directly relate to MacOS.

        For a long time, I used to think "standards good, propriatary bad". I wanted everything I used to be standards compliant.

        Then I got into the industry, and ran into some of the standards-setting folks.

        The good news is that generally folks involved with setting standards are reasonably (not necessarily the best) competent. It's not as good a situation as the brutally harsh meritocracy of Linux development, where code with vast amounts of time and effort can get thrown out because someone else came up with a better/faster system, but it ensures some degree of sanity.

        However, politicking involved in standards committees is horrible. Generally, standards are set by industry consortiums, a recipe for disaster. Everyone has their personal pet features they want in, for starters. They then have to advance the interests of their company, so they try to exclude things that might benefit their competitors, and include support for things they're working on (even if they're technically inferior -- so if IBM is making a worse system than Dinky Company, Inc., it's likely that the technically inferior method gets used.). People are under pressure to finalize standards in time for products based on them to come out -- if there are still issues, too bad. Because different companies may prefer different methods of doing something/have different methods under work already, standards need to include support for both. Standards are frequently bad about exluding redundant methods of doing something. Finally, standards are frequently designed for companies doing a product implementation. They often cost money, and while complete they may not be particularly clear. This compares poorly against the RFCs that provide specifications for traditional Internet protocols today (yes, traditionally RFCs weren't final specs, but they are today).

        I've come to realize that "open" is more important than "standardized". If you write a good specification for something, distribute it freely, and you've done a good job with designing the system, others can (and will) adopt the system (if it's better than the alternatives). yEnc, gzip and png were originally "open", though not standardized, and (perhaps more crucially) none were produced by industry consortiums.

    • Re:Next stop, Quartz... then Aqua (Score:4, Insightful)

      by anarkhos ( 209172 ) on Monday November 03, 2003 @04:27AM (#7376152)
      Aqua isn't a library. It's a specification nobody seems to follow.

      Quartz isn't necessary to run most Carbon apps. I'd start there.

  • Plain English (Score:4, Insightful)

    by randomErr ( 172078 ) <ervin,kosch&gmail,com> on Monday November 03, 2003 @01:34AM (#7375687) Journal
    So in plain English this means that Mac OSX programs will soon be able to run on BSD and eventually Linux?

    • Re:Plain English (Score:5, Informative)

      by Sebby ( 238625 ) on Monday November 03, 2003 @01:40AM (#7375709)
      No.

      That would require emulating the Apple's APIs for everything in the OS.

      Given that most of it is proprietary, this is very unlikely to happen, though not impossible (just look at Wine)...

      • Re:Plain English (Score:3, Interesting)

        by Arker ( 91948 )

        Actually, if I'm reading this correctly, it would mean running their libraries, containing those APIs, in binary form. There's your OSX on x86. Of course, it'll be slow as mud on that kind of hardware, but for those that keep screaming for it, there you go.

        Probably breaks your EULA with Apple, if you agreed to one. And their lawyers would probably come down on you like a ton of bricks if you tried redistributing them, but for however many folks have an OSX disk, want to run it on x86, and didn't agree to

      • Re:Plain English (Score:4, Informative)

        by __aavhli5779 ( 690619 ) on Monday November 03, 2003 @06:48AM (#7376483) Journal
        One of the major APIs for OS X already exists in an open-source form called are [gnustep.org].

        Of course, this is not emulation, rather source compatibility.

        Throw in a GNUstep Makefile and new interface files, and you can have apps that compile from the same source on any free *NIX with GNUstep and on OS X with Cocoa.

    • Re:Plain English (Score:5, Interesting)

      by BrookHarty ( 9119 ) on Monday November 03, 2003 @01:40AM (#7375710) Journal
      The post doesnt make it clear, this is about PowerPC os's and emulation. Doesnt mean you can take X86 code, and run it on the netbsd for PPC.

      Remember this is binary compatibility, not emulation: programs run at full speed, but only on a NetBSD machine with the same CPU the program was designed for. Binary compatiblity does not enable running Linux/i386 binaries on NetBSD/powerpc, for instance.

      So far Mac OSX only runs on PPC. So if you run NetBSD on PPC, your set. But then, Why not use MOL (Mac On Linux)?
      • For that matter, why not run OS X and handle UNIX programs via Fink?

        If you're going for Insane Hack Value, they're all about as viable. The nice part of NetBSD is that is runs on damned near anything. If I don't have to fire up an OS X instance from within my Open Source OS of choice to run OS X binaries, hey, that's pretty cool.

        I'd imagine OS X binaries on NetBSD/PPC is just another instance of "because I can." Then again, I've really found no major disadvantage to running OS X versus Linux on my Mac.
        • There's a whole lot of PPC hardware out there
          that OS X does not and will never support.
          In fact, it's a lot cheaper than anything
          apple will ever produce. Admittedly, none
          of the stuff that is available on the market
          today is G5 (please, please prove me wrong!)
          but on a $/MFLOP or $/MIP basis, if you don't
          need the candy and macaroni, it would be
          insane to make, for example, an apple-based
          compute cluster of G4s, as opposed to an
          off-label cluster of G4s. G5 will come too,
          one can reasonably expect.
          • On a cluster basis, sure. I was referring to my own Mac, which is obviously a different case altogether.

            Still, the main reach of either project is to run OS X programs while sticking with a non OS X base OS. If you're not bothering, then you don't really need Darwin support at all. Just slap NetBSD/PPC on a G4/PPC970 (eventually, if it's not already done,) and go to town.

            If I just needed a diskless PPC system with two ethernet ports and a serial console, I agree. Apple would be the last vendor I'd go
            • Thing is, my OS X code will run on OS X *or*
              NetBSD (speaking hypothetically, assuming a
              completed portability layer), while my NetBSD
              code will *only* run on NetBSD.

              Okay, so it's not a VM, but I won't be
              running post-stack migrations on .NET or JRE
              any time soon.

  • So what's the implication here? (Score:5, Interesting)

    by numbski ( 515011 ) * <[numbski] [at] [hksilver.net]> on Monday November 03, 2003 @01:35AM (#7375691) Homepage Journal
    Are you trying to get to a point where you can run any OSX binary, including the Cocoa/Aqua environment itself?

    Nifty for sure, but you start to wonder about the usefulness of this...I mean, in order to legally use the more interesting, useful parts of the OS, you would have to own a copy of OSX, unless for some reason the soft Unix underbelly of Darwin doesn't fit your needs, and you want a more traditional BSD, but still be able to use the OSX GUI.

    If you're making a unix binary compatibility for just standard CLI or X-Windows, it cries out of 'what's the point'.

    So what is the point?

    • ah, so THAT's the point! (RTFA): (Score:5, Informative)

      by numbski ( 515011 ) * <[numbski] [at] [hksilver.net]> on Monday November 03, 2003 @01:43AM (#7375722) Homepage Journal
      Running Darwin has no interest in itself, but having it working ensures

      that our IOKit (1) emulation is good enough to be used . The real target
      now is MacOS X's WindowServer. WindowServer is like XDarwin for the
      quartz displaying system, which is used natively by MacOS X
      applications.

      See the status page at http://hcpnet.free.fr/applebsd.html for more
      informations.


      They're trying to get the OSX environment running on NetBSD instead of Darwin. I'm failing to see the point of this other than a different package manager...anyone else see a benefit to this? Drivers? Cheaper hardware? All looks the same to me...

      • Re:ah, so THAT's the point! (RTFA): (Score:2, Informative)

        by Anonymous Coward
        IOKit points to drivers. So if someone crafts a driver for the Macintosh (popular consumer hardware platform, that), it should work:

        -On PowerPC machines running NetBSD, be they Macs or the few open PowerPC boards (AmigaOne, Pegasos) cropping up. ... Remember, the existing Mac ports don't let you use Mac drivers any more than you can use Windows drivers on Linux/i386.

        -Hopefully with a simple recompile on NetBSD i386/etc. So for companies that have the sense to open-source their drivers, this is a shortcu

        • Re:ah, so THAT's the point! (RTFA): (Score:4, Interesting)

          by numbski ( 515011 ) * <[numbski] [at] [hksilver.net]> on Monday November 03, 2003 @02:01AM (#7375790) Homepage Journal
          I follow you now...uber_cool device gets released for Macintosh. Specialized device, no BSD drivers written.

          IOKit allows these drivers to work on NetBSD/PPC.

          Nice.

          • Re:ah, so THAT's the point! (RTFA): (Score:2, Insightful)

            by Anonymous Coward
            Yep. As others have pointed out, it's also a shortcut to letting the Quartz server binaries from OS X run on NetBSD/PPC (just like X11 needs to be built to talk to the hardware through standard UNIX APIs or direct rendering modules, Quartz needs to be able to talk to the hardware through IOKit), but Apple's EULA probably bars that, so I don't see that as bragging rights. Drivers are third-party code, so they're not governed by Apple's licensing. :)

            However, there may be a loophole - as I understand Apple'
      • Ask the people who already own a G3 that _won't_ run MacOS X at all or the most current versions, and for better reason than that Apple doesn't feel like maintaining OS compatability for these "old" machines. Of course you could alway just buy a newer Mac, but it may seem like a waste of perfectly good hardware just to run the latest/greatest x.y.z release, not to mention the cost.

        If your Mac can run NetBSD, then when the time comes that it won't run MacOS X versions, you could switch over to NetBSD, espe
    • The point is the flexibility you gain in being able to alter the kernel of the OS on which you're running your programs. While BSD is of course a different, older tradition, recall that the reason RMS got into the whole "free uber alles" thing was because he wanted to have the source to a printer driver [april.org], not because he didn't want to have to pay for one.

      This ability could actually improve Max OS X's adoption by the enterprise - companies will know that they won't have to depend upon Apple to make any des
      • You can already modify the kernel of OS/X - it's called Darwin, and it's open source (or at least some sort of shared source model... I don't remember the license). I suppose if you are just a NetBSD freak and want to run a pure-blood BSD licensed OS but still run all your spiffy looking Mac apps in an Aqua environment, this project will get you there as soon as the full Aqua window manager runs on top of NetBSD/PPC.

        • Re:Not just nifty (Score:4, Informative)

          by quigonn ( 80360 ) on Monday November 03, 2003 @04:34AM (#7376170) Homepage
          Darwin is more than just the kernel, it's also the non-graphical userland. Darwin's kernel is actually called "xnu". And Darwin is licensed under the Apple Public Source License, version 2, which is actually GPL-compatible. They even worked together with the FSF to ensure this.
        • Uh... do you know of anybody running Mac OS X applications on Darwin? Every time I've asked about whether this is possible, the answer has been "no."

          If yes, I'd love to see some docs on how to do it. If not, Darwin is not a solution to the problem I specified.
    • So what is the point?

      The point is called "hack value". They do it simply because they _can_ do it, and nobody did it before them.
    • So what is the point?

      To see if it can be done?

      (Kids these days, just don't grok the old-school hacker/tinkerer aesthetic... grumble grumble)

    • The text of the article notwithstanding,
      it is tremendously useful for running code
      developed for OS X on non-apple hardware.
      It means you don't need Apple hardware to
      run OS X and its applications.

  • Only apps without Aqua (Score:4, Insightful)

    by Offwhite98 ( 101400 ) on Monday November 03, 2003 @01:40AM (#7375708) Homepage
    The apps which will work will be the ones that only use the BSD core and not the entire Aqua graphics layer where the majority of popular MacOS X application run. But it is conceivable that an emulation of Aqua could be created for NetBSD which could replace X11. And since X11 is really show its age, I think a replacement for the graphics layer on Unix-like system is long in coming. Emulating the Dock and other MacOS UI features would be great. Just ask the developers at WindowMaker.
    • > The apps which will work will be the ones that only use the BSD core and not the entire Aqua graphics layer where the majority of popular MacOS X application run. But it is conceivable that an emulation of Aqua could be created for NetBSD which could replace X11.
      I think you are being short-sighted here. A smarter and more realistic goal would be to get the compatibility with Darwin good enough that you could run Aqua and the rest of the OS X userland on top of NetBSD, without having to rewrite it al
    • I wonder if that'll be the step that gets the project cease-and-desisted. Creep too closely into Apple's look and feel, and you're threatening 95% of their product.

      Not that I have a problem with encroachers being warned off, of course, as nearly as much research and effort goes into designing an effective user interface as goes into the rest of a successful product. But I'd hate to see NetBSD embroiled in difficulties similar to those that faced themes.org regarding the copyright of the Aqua theme.

    • I wouldn't be surprised if the intent were more to do what WINE has been allowing on x86 for years: the ability to run binary libraries/frameworks from another OS.

      I doubt Aqua is going to be recreated as much as, once IOKit support is complete, people will be able to run Apple's core Aqua/Window Server binary frameworks on NetBSD and then run native OS X apps in non-emulation.

      Rewriting Aqua would be a gargantuan task. Allowing people to run the libraries necessary for Aqua presents fewer hurdles, and is

  • XDarwin and NetBSD/powerpc binary compatibility (Score:4, Insightful)

    by ubiquitin ( 28396 ) * on Monday November 03, 2003 @01:49AM (#7375748) Homepage Journal
    Although the post by Emmanual Dreyfus indicates that XDarwin is essentially a test case, this is a rather important [xdarwin.org] test case. If you can run XDarwin, you're just a short hop away from having all of the X11 apps along with it. Also, imagine a package system [metapkg.org] like the fink [sf.net] working equally well on OSX and NetBSD. You could develop on OSX with its comfortable GUI and deploy to NetBSD with its comfortable price.
  • Actually it says right in the summary that having IOKit emulation working was the important thing right now.

    So the question I have is, does this mean that now NetBSD on PPC can use Mac OS X drivers? The short article doesn't really point that out. Seems like a nice bonus before working on the Window Server.

  • some posts here are crazy.. (Score:5, Insightful)

    by minus_273 ( 174041 ) <{aaaaa} {at} {SPAM.yahoo.com}> on Monday November 03, 2003 @01:56AM (#7375773) Journal
    while it would be very nice, this DOES NOT let you run OSX apps on linux, not on and i386. This simply lets you run binaries for the PPC processor from OSX on netbsd running on a PPC. Not just any binaries too, just those that dont use the Aqua GUI. Dont really see the point of it aside from it being a nice technical achievement, kinda like running darwin on an i386.. no real point just cool :)

  • Why I find this interesting (Score:4, Interesting)

    by Stonent1 ( 594886 ) <stonentNO@SPAMstonent.pointclark.net> on Monday November 03, 2003 @02:00AM (#7375785) Journal
    As the Mac OS series moves on, certain hardware is eventually dropped. This may be their only chance to keep their system going with something current. Also it adds the possibility to use any NetBSD supported PCI cards on your Mac.

    This reminds me of Theo talking about running SunOS (68k) binaries on really fast 68k hardware supported by OpenBSD.

  • Enlighten Me (Score:2, Interesting)

    by use_compress ( 627082 )
    Why would you want to X and one of its clumsy window managers instead of Aqua, the best user interface around?

    • Re:Enlighten Me (Score:3, Interesting)

      by 0x0d0a ( 568518 )
      Because Aqua is mind-bogglingly inefficient and *isn't* the best user interface around. In Apple's golden days, yes, they could claim the best user interface around. However, they lost that claim over time, lost a lot of their HCI people, and now make something that looks like Enlightenment -- emphasis on eye candy over usability.

      I've watched people using Aqua and a ton of other interfaces. About the fastest you'll see anyone is when they're using a fully keyboard-driven interface and are extremely fami
  • So far the port to get it to the powerpc is progessing. FreeBSD already runs on sparcs as well as Alpha's.

    Its by the far the most easiest BSD to use and has alot of example files and scripts to hack with.

  • Do you ever just read a headline like this.... (Score:5, Funny)

    by caitsith01 ( 606117 ) on Monday November 03, 2003 @04:12AM (#7376126) Journal
    and wonder if you could be doing something more with your life?

    "NetBSD's COMPAT_DARWIN Adds XDarwin Support" What the fuck is that? It's not even vaguely english. Probably the majority of people who know what it means are reading this site right now.

    Reminds me of (what else) The Simpsons:

    Comic Book Guy [reading comic]: "No aquaman... you cannot marry a woman without gills! You're from two different worlds!"

    [looks up to see a nuclear warhead streaking towards him]

    "Oh, I've wasted my life."

    [kabooooom!]
    • "NetBSD's COMPAT_DARWIN Adds XDarwin Support" What the fuck is that? It's not even vaguely english. Probably the majority of people who know what it means are reading this site right now.

      Which seems to be to be a good argument for putting it on Slashdot.

      This was listed under Software, BSD, and Operating Systems (all tech forums on a website frequented by technical people). If you can't handle reading about any of the three above topics from a tech standpoint, then why the hell are you even on Slashdot,
      • Oh, get a sense of humour.

        I was just making the point that sometimes things get a tad esoteric here. I am a technical person, but sometimes headlines don't even make sense to me.

        Of course personally I would like to see a bit less 'news for nerds' and a bit more 'stuff that matters.'

  • What this really means... (Score:3, Interesting)

    by Anonymous Coward on Monday November 03, 2003 @04:32AM (#7376160)
    I posted this in a thread above, but only one person's noticed. I hate to whore, but really, many of the comments lack perspective on the situation overall.

    So if you appreciate this, please do whatever Slashmojo it takes to make it visible, or do the same for the original [slashdot.org]?

    ---

    IOKit points to drivers. So if someone crafts a driver for the Macintosh (popular consumer hardware platform, that), it should work:

    -On PowerPC machines running NetBSD, be they Macs or the few open PowerPC boards (AmigaOne, Pegasos) cropping up. ... Remember, the existing Mac ports don't let you use Mac drivers any more than you can use Windows drivers on Linux/i386.

    -Hopefully with a simple recompile on NetBSD i386/etc. So for companies that have the sense to open-source their drivers, this is a shortcut to using them on NetBSD without rewriting the code itself for a new API.

    Niche, but a nice hack, and with XDarwin working, also a convenience for PPC users if they come across a plain X11 app only available as a Darwin binary. (Rare now, but we don't know how it'll play out; look how annoying the Macromedia Flash plugin makes life on FreeBSD/i386; it's only distributed as a Linux binary, so you need the 'Linuxulator' to take advantage.)

    ---

    Yep. As others have pointed out, it's also a shortcut to letting the Quartz server binaries from OS X run on NetBSD/PPC (just like X11 needs to be built to talk to the hardware through standard UNIX APIs or direct rendering modules, Quartz needs to be able to talk to the hardware through IOKit), but Apple's EULA probably bars that, so I don't see that as bragging rights. Drivers are third-party code, so they're not governed by Apple's licensing. :)

    However, there may be a loophole - as I understand Apple's EULA, they don't care what you do with the software, as long as you only run it on their hardware. So Mac-on-Linux, which is more of a VMWare type deal, is perfectly legal under Yellow Dog or whatever -- *if* you're running it on Apple hardware, and have a license for your seat of OS X -- and Quartz atop NetBSD should equally be fine. (It could even be useful, depending on your opinion of NetBSD versus xnu [apple.com]. I gather a few people actually use Linux+MoL for improved stability; NetBSD+COMPAT_DARWIN+Quartz would offer the same, but with even fewer virtualization overheads.)

    However, since Apple doesn't sell any version of OS X permitting use on non-Apple hardware, users of the new 'alternative' PowerPC boards are left out in the legal cold. (In the USA; if you live in a jurisdiction where EULAs don't hold and software is sold on copyright alone, go wild... but don't expect Apple to tolerate it any more than Microsoft tolerated DR-DOS or post-partnership OS/2.)

    ---

    Okay, new content for this post: Can we stop arguing subjective things like package managers? It's a great distraction from the real issues in this thread. To lay that one to rest... well, let's put it this way - you can use the NetBSD pkgsrc collection on Darwin if you really want to. [netbsd.org] Choose your poison based on the kernels, not subjective nonissues with userland.

    • OKit points to drivers. So if someone crafts a driver for the Macintosh (popular consumer hardware platform, that), it should work:

      -On PowerPC machines running NetBSD, be they Macs or the few open PowerPC boards (AmigaOne, Pegasos) cropping up. ... Remember, the existing Mac ports don't let you use Mac drivers any more than you can use Windows drivers on Linux/i386.

      -Hopefully with a simple recompile on NetBSD i386/etc. So for companies that have the sense to open-source their drivers, this is a shortcut

  • Running Mac software on Linux/*BSD (Score:5, Informative)

    by damieng ( 230610 ) on Monday November 03, 2003 @06:00AM (#7376385) Homepage Journal
    The fact that all Mac binaries are PPC is going to mean at best on i386 platforms you're going to have to use emulation, a better approach is to emulate the Cocoa API allowing a recompile for i386/whatever.

    The Cocoa API is basically the NextStep API with Quartz replacing Display Postscript for the display composition/rendering and a number of additional classes and extensions since. (Display Postscript was licenced, Quartz is based on the free PDF specification).

    The original NextStep API exists on non-PPC platforms in two forms;

    The first is Apple's own implementation which was called 'Yellow Box' back in the NextStep days and let you recompile your apps for Windows. Alas there were licencing issues that Apple claim meant the runtime was expensive to deploy.

    Apple still use this runtime in WebObjects for Windows - I don't know if it's been extended to keep up with the OSX enhancements.

    The second option is an interesting project called GNUStep [gnustep.org] who are working towards a complete implementation of the NextStep API and have stated they will add Cocoa's extensions where they provide value. With it being open source you could always add any missing classes/functionality yourself.

    This project is usable on FreeBSD and Linux and the core and gui classes are nearly complete however the developer tools themselves are not. This i not a problem however if you are developing on OSX and using them for a port.

  • No, it's not going to save anybody any money, and it's not going to replace MacOS in the enterprise. But NetBSD does have some advantages over MacOS - better VM, for instance. With MacOS, I routinely find that if I do anything memory-intensive, my interactive performance goes to hell. NetBSD's VM system does much better in similar circumstances.

    So I'm always jonesing for NetBSD because, for me, it performs better. I am sure there are other good reasons to do this, and of course there are good reaso

Slashdot Top Deals

The moon is made of green cheese. -- John Heywood

Close