Running Mac OS X Binaries With NetBSD 177
An anonymous reader writes "KernelTrap has an interesting article about an effort to add a Mach and Darwin binary compatibility layer to NetBSD. The project has evidently already made a fair amount of progress, currently working to stabilize the WindowServer emulation portion that will then allow NetBSD to run Mac OS X graphical applications."
Fantastic (Score:4, Funny)
Re:Fantastic (Score:1)
Great idea (Score:1, Redundant)
Best of all the worlds combined. Run the app you need, on an OS you can trust.
Re:Great idea (Score:3, Funny)
Re:Great idea (Score:1)
Re:Great idea (Score:4, Informative)
Re:Great idea (Score:2)
now i'm really lookin forward to installing NetBSD on my Quadra 660av [lowendmac.com]. kudos to NetBSD!
Run it on FBSD (Score:2)
I commend the NetBSD people, but i still use FreeBSD for now since im only running i386 chips these days.
Re:Run it on FBSD (Score:2)
I read the word 'emulation' and I didn't see it specify which architecture, so one would assume its emulated.. sooo would run on i386 too..
I read it fast so I could have missed them saying it was ppc only..If so, then I guess I'm outta luck.
Neat but... (Score:2)
Re:Neat but... (Score:2, Interesting)
But, yes- you can only run PPC binaries. M68k or x86 will not work.
lr
Re:Neat but... (Score:1)
I'm running on an even older beige G3, no problem.
Re:Neat but... (Score:2)
Re:Neat but... (Score:1)
Solaris:Yes
Solaris PPC [google.com]
Linux port? (Score:1, Interesting)
Re:Linux port? (Score:1)
Re:Linux port? (Score:2)
Re:Linux port? (Score:2, Informative)
Re:Linux port? (Score:2, Insightful)
OK, but... (Score:2)
Re:OK, but... (Score:1)
Re:OK, but... (Score:1)
I don't really give a whiz about freedom. I'll use the best tool for the job. Sometimes it's a Mac, sometimes it's Linux, sometimes (but not very often) it's Windows. If I can use something with a BSD license, I will, but that doesn't govern my decision. Maybe I'm getting old, but I'm starting to think of all of this push for GNU, the Green Party, and the like as simple immaturity on the part of people who don't have enough other things to do in the real world. Call that a troll if you like, but it's about how I feel.
Re:OK, but... (Score:2)
Maybe I'm getting old, but I'm starting to think of all of this push for GNU, the Green Party, and the like as simple immaturity on the part of people who don't have enough other things to do in the real world.
Congratulations, and welcome to the real world. :)
Re:OK, but... (Score:3, Insightful)
Only idealists can make positive change.
That's overly simplistic. As usual, reality is a lot more complicated.
There is no doubt that idealists (radicals if you will) can be a catalyst for change. But it's extremely rare that they actually make the changes. Almost by definition, idealists are incapable of implementing change because they want instant gratification and are impatient with the realities of implementation. And even then, they are often incapable of seeing a larger picture that reasonable people can disagree with their "idealism". Take environmentalism. If the typical idealist enviro had their way, every forest would be off-limits to logging. Period. But the ignores the reality that logging is not intrinsically evil, and that wood is a renewable resource.
I'm reminded of one of my favorite scenes from Lawrence of Arabia:
Feisal: The world is delighted at the picture of Damascus liberated by the Arab army.
Allenby: Led, may I remind you, sir, by a British-serving officer.
Feisal: Ah yes. But then Lawrence is a sword with two edges. We are equally glad to be rid of him, are we not?
Allenby: I thought I was a hard man, sir.
Feisal: You are merely a general. I must be a king...
It's up to us realists to slowly, painfully -- but practically and fairly -- make the changes that society needs. We are the ones that are most capable of seeing all the sides of an issue and balancing everyone's needs.
Like I said, idealists have a place as catalysts to move things along quicker than they might have moved along, simply because they raise the priority of something. But it's unfair and untrue to say that realists never make changes without them, because its simply untrue. Idealists just believe that to be true because the pace is always slower than they want it, and they don't see the realists as having the "passion" of change.
I agree with you about opportunists to some extent, in that they aren't often dedicated to "progress". However, that doesn't mean it doesn't happen by accident. Opportunists create a lot of jobs, which is the single greatest resource that can be created when it comes to social progress.
Re:OK, but... (Score:2, Insightful)
Re:OK, but... (Score:2)
The line for me would be if I had to "subscribe" to my software to keep using it like MS wants. (I don't actually use Office, but bear with me.) If they ever did that, I'd standardize on a different program, or if none fulfilled my needs, I'd simply stick with Word 2000 or whatever the current version is.
Re:OK, but... (Score:2)
I don't recall ever claiming to be either official or correct. It's my opinion. Just like your opinion is yours. The statement of opinion embodies no claim to be officially correct or anything else along those lines.
Re:Linux port? (Score:5, Interesting)
Mac-On-Linux [maconlinux.org]
OK, it's not binary compatibility, but unlike COMPAT_MACH and COMPAT_DARWIN it does already work. But COMPAT_MACH and COMPAT_DARWIN are very interesting and worth keeping an eye on it.
Oh, BTW.... From the MOL-FAQ:
Re:Linux port? (Score:1)
"News Flash:
Sep 5: It is now possible to boot MacOS X in MOL."
Which links to..
"Hot News:
Sep 5: Boot MacOS X in MOL 0.9.65!
It is now possible to run MacOS X within MOL. Both MacOS 10.1 and 10.2 are supported. The new MOL version also contains support for little endian (remote) X displays. A couple of performance improvements have also gone into this release."
Q: Why don't they port this to BSD, instead of reinventing the wheel?
A: This is OpenSource dude, don't you get it?
Re:Linux port? (Score:2)
Re:Linux port? (Score:2)
Re:Linux port? (Score:2)
Basically, what the COMPAT stuff emulates is not the somewhat ill-defined layer between libraries and applications in Windows, but the very well defined (and open-sourced) layer between the kernel and user-land. In order to make it useful, I'd suspect you'd need almost a full OSX installation.
Re:Linux port? (Score:2)
Or, wait, what about devices? The biggest problem of MOL is that every device has to be reimplemented. As a result, today the MOL user can forget about virtually all USB and Firewire devices: printers, scanners, cameras. Is this the same problem with NetBSD's COMPAT?
Re:Linux port? (Score:2)
Under most versions of Unix, there is a very similar interface between the user application and the kernel. Basically, the COMPAT stuff just says "Well, this program is a MacOS X program so when it makes a call that looks like A, it really means B under NetBSD so go do that and I'll reformat the results back to what the binary is expecting". The result is that the OSX binary is really running natively under NetBSD so any device supported by the NetBSD kernel *should* be supported by OSX. It looks like their present state is trying to get enough of the OSX device interface working for that to happen.
Re:Linux port? (Score:1)
This is the most often reason for Linux not being adopted on the desktop that I see. Why does it matter? What would possess someone to switch OS's just to use the same program that has been shoehorned into a different OS? If something is working (i.e. Photoshop running on an Apple) there isn't a compelling reason to switch. The percieved lack of familiar programs is usually just preventing people that already using Linux from using it full time.
If Photoshop or Office was native to a Linux desktop then that may put a dent - but only a very small dent, look at Apple's success - in the desktop world. Why is it so hard for Linux advocates to accept that Linux belongs as a server, for now. Now that it has pretty, user-friendly UI's people want to force it on the desktop for everyone...maybe that isn't right, though.
It would take some killer app (or a significant outside influence) to get the regular Joe-user to switch from a system that works to the point they expect (i.e. Windows, with the occasional crash now in XP) to Linux.
Re:Linux port? (Score:3, Insightful)
You're making a lot of assumptions. Firstly, that such an emulation system could be completed in any reasonable amount of time, and could keep up with Apple. Obviously, that isn't the same kind of issue as it is with Wine as Apple is a lot smaller, and to be frank, Windows has far more APIs and features to the developer than OS X does (at present).
Secondly, you're assuming Apple would let this happen. They can't stop a cleanroom implementation, but they can copyright the artwork which is a big deal to Mac users. Wine has to have its own artwork for instance (but not for the widget toolkit, as the Win98 L&F is so basic it can't really be copyrighted). Not that nice distinctions like code vs art would bother Apple, they have a long history of abusive lawsuits.
Finally you're assuming that such an emulator could emulate PPC opcodes at a reasonable speed, which is a) hard and b) unlikely.
Bear in mind that doesn't say "You can run MacOS apps on NetBSD", far from it, they have some of the basics of Mach IPC working. They haven't even started on graphics support. If there's something we've all learnt from Wine (which has 2 companies working on it as well as hundreds of volunteers), it's that cloning another OS's APIs is a lot of work, and as most of the MacOS APIs are not simply lifts of their UNIX equivalents, they are Apple proprietary (iokit/coreaudio etc), that's no less amount of work.
Re:Linux port? (Score:2)
Re:Linux port? (Score:2)
Opcode emulation is probably the easiest part of emulating the PPC. Much harder is the emulation of all those registers with the handful in x86. This will be much easier with x86-64 (AMD) because you have twice as many registers, but you still have to determine which registers are being acted on and swap the contents of registers in and out as you go -- basically, the same thing modern CPUs do internally to reduce the cost of context switches (register renaming) except you're going to have to do it in software. You might be able to avoid that in the case of a transmeta CPU, but the proper way to do that with a TM chip is to make it emulate a PPC anyway. I really hope someday transmeta manages to emulate something other than x86, and further that we end up with systems with multiple TM CPUs on them so that we can emulate multiple CPUs of different architectures.
Incidentally, CPU-manufacturing companies are really goddamned annoying. Why oh why can the FACT SHEET for a processor not tell you in simple terms how many general purpose registers it has? You have to go all the way to the user manual... Anyway the G3 has 32 GPRs and 32 FPRs (floating point), I had that noted down already and didn't want to look up the G4 to see if it has more (it probably doesn't, except for altivec.) I'm only familiar with four GPRs on x86; [E]AX through [E]DX. There are a number of index registers, many of which can be used as GPRs, but which in practice nearly always must be used for their design purpose. Of course motorola uses GPRs for indexes so the real number of usable GPRs is closer to four times as many than eight times as many as it at first appears.
In any case that's a LOT more registers! You think context switches are bad now...
Still wining about lack of Word?! (Score:1)
Me and my whole organization use StarOffice/OpenOffice for a long time ago, and we don't need MS Office. When we want to send a document outside the company, we convert it to PDF. Whenever we receive a MS Office document from outside, we open it it StarOffice/OpenOffice. When we need to check if the conversion was well done, we open the document in Microsoft Word Viewer, Excel Viewer and Powerpoint viewer, which:
When will people realize that if compatibility was so crucial, then we would still be using Wordstar or an even older wordprocessor?
Regarding Photoshop, Corel Photopaint and Gimp are excellent replacements. I know they don't have all the prepress features of Photoshop. But most Photoshop users don't use prepress features!
Time to get a PPC computer (Score:1, Redundant)
Re:NO MORE EXPENSIVE APPLE HARDWARE!!! (Score:1)
It still requires that you have a PPC processor, so it just does software emulation, and not hardware emulation. So you STILL have to buy the expensive hardware.
That's great news but... (Score:5, Insightful)
Re:That's great news but... (Score:1)
That's awesome (Score:5, Insightful)
If you remember, they've been *very* anal in the past about some things they consider to be "their stuff", such as the look and feel of the OS. I can't see them just sitting around and watching while all their OS capabilities are matched (or, for that matter, exceeded).
If they sent C&D letters for freakin' themes, I doubt they'll just sit around while their API is emulated. They've show themselves to be rather devious, and I'd be a little worried if I was a NetBSD developer.
Re:That's awesome (Score:2)
We'll see if they start "Thinking Differently" about that approach now that it's OSX involved instead of Classic, but I'd be at least slightly optimistic: they haven't tried to shut down the GnuStep projet recently, and that's much more of a danger to them than this.
Re:That's awesome (Score:2)
Re:That's awesome (Score:3, Informative)
A GNUStep application if binary compatible with Mach/Darwin would run without recompilation or localization.
Re:That's awesome (Score:3, Insightful)
This project isn't emulating the MacOS APIs, they're getting the basics up and running so they can drop in actual code libraries from OS X. Unlike Wine which is actually recreating all the APIs, this is just a fun hack basically, no danger to Apple as you still need a Mac and a copy of MacOS for it to work.
I seriously doubt we'll see a Mac equivalent of Wine for a very long time, the amount of effort it takes is just too huge given the absence of any must have apps on the Mac (apps with no equivalent on other platforms). Wine is essential because of the huge amount of software that simply doesn't have Linux equivalents (or not very good ones) and probably never will, ie Lightwave, DreamWeaver, Flash and so on, and of course huge numbers of custom business apps. The Mac doesn't really have any such apps, the closest I can think of are the iApps, but there are lots of equivalents for them even on the Mac itself, and I don't know of any custom business apps that are Mac only.
Re:That's awesome (Score:1, Insightful)
So basically this is replacing the Darwin system with NetBSD to allow the proprietary OS X parts to run under a different kernel.
However, unlike emulating other monolithic Unixen, emulating Mach and Apple's driver frameworks requires a lot of extra functionality, so they are sort of re-creating the Darwin kernel backwards - instead of a Mach kernel with BSD functionality added, it'll be a BSD kernel with Mach functionality added. BSD and Mach have been related quite closely historically, anyhow, consider that the virtual memory subsystem of 4.4BSD was from Mach... And then there is Lites, the BSD kernel that runs as a user process under Mach.
So we can basically look at it this way - mixing Mach and BSD kernels in various ways has been something people have been doing for a long time, and it doesn't look like people will stop doing it.
Re:That's awesome (Score:2, Interesting)
Darwin with GNUstep implements approximately 75% of the functionality of OS X, right down to the resolution independant rendering (GNUstep uses Postscript, OS X uses PDF).
If everyone is so up in arms about running OS X on their Intel computer, just fucking get Linux or Darwin and run GNUstep. Most freeware for OS X should work just fine if you compile it. Due to the great object-oriented nature of Openstep, you could probably fix any that didn't in a matter of minutes or hours.
I was running GNUstep (with the Ghostscript back-end) and Windowmaker for a while before I got my Powerbook G4.
Re:That's awesome (Score:2)
'their API', is, to a very large extent, taken from NextStep, which they bought to get Steve Jobs back. It's already been cloned (pretty much) by the GNUStep project [gnustep.org].
Now look what you did (Score:5, Funny)
Of course it runs NetBSD! (Score:4, Funny)
~tell RAMMS+EIN (Score:2)
Is this a de facto x86 OSX? (Score:2)
Re:Is this a de facto x86 OSX? (Score:5, Informative)
I stand corrected, thanks! (Score:1)
Re:Is this a de facto x86 OSX? (Score:2)
What else? I shit load of cash in lawyer fees, that's what.
I've only "used" OS-X at a Mac Store a couple of times, but REALLY liked it. Like I'd even go so far as to dump all this OSS/Linux/M$/whatever stuff to have one Mac box. It left that great of an impression on me. But what you are suggesting is pure suicide. I would LOVE for Apple (read as: Steve Jobs...) to release an x86 version of OS-X. I'd buy it in a heart beat (I love KDE3.1, but OS-X... mmmm...). But I just don't see that happening. There's FAR too many hardware configs to consider. Apple as only one hardware config to think about: Apple's Hardware. That's REALLY easy to program for.
Aside, take a look at KDE-Look [kde-look.org]. There's a couple Window Decrations that are basically OS-X, and then there's Mosfet's widget set. OK, OK, there's more to OS-X than the look of it, I know. I'm just saying that there's MUCH cheaper ways to achive the same goal.
KDE3.1 + Aqua WD (I forget the exact name, I don't use it) + Mosfest's Liquid Widgets + CodeWeaver's Crossover + the dirt cheap prices of x86 hardware == Heaven (if it's a Mac you're looking for). Just thought I'd say it. We already have most of the parts available to us. It's just the matter of doing it...
The hardest part to imitate... (Score:2, Insightful)
The much appraised Mac 'look & feel' bases itself on all developers sticking to the UI conventions and guidelines, nicely outlined in this guide [apple.com] for porting over Win32 apps.
The longer you use Mac OS, the more you'll appreciate this 'cultural' aspect of the OS.
Having used Windows XP a lot lately, I've been quite happy with the OS and 'Window Manager' itself, but as soon as I actually use an other app, the whole experience breaks down.
Keyboard shortcuts vary, widget placement is random, the tone of dialog varies and in general, application interoperability seems harder.
Funny how so many people lust after the visual aspect of the UI, risking lawsuits from Apple, while the 'feel' part - the real magic of Mac OS - is quite publicly available AND applicable in form of UI guidelines [apple.com].
It won't hurt your Win/Linux app to apply some/all of these guidelines instead of no guidelines at all.
J
Wrong. (Score:1)
- No self contained applications. Installation process is _not_ "grab the app and drag it to your favourite place"
- No intelligent framework system. Try to use a KDE 1.0 app with your KDE 3.1 libraries. It breaks, because the goddamned _size_ of the _classes_ in fucking _C++_ has changed. Even if it were _source_compatible_ it wouldn't work, because of C++'s stupit ABI. (Note: Objective C doesn't have this problem
- No Project Builder. Use it, then you'll understand.
Those are only a few, but I'll stop here. It's indeed a Mac I'm looking for, and that's because it's thought out. It's not because I like the _look_ of the GUI. In fact, if you choose your tools by their looks, you probably have a larger problem than not having a Mac...
You still need a PowerPC machine (Score:5, Informative)
I know you can buy third party PowerPC computer, but they are more expense than Apple's machines.
I do appricated their effort, it is probably a good exercise in programming skill.
It would be useful if it was on x86, but there are plenty of problems with that; see
http://www.emaculation.com/ppc.shtml [emaculation.com]
(This is not a flame, just an observation)
Re:You still need a PowerPC machine (Score:1)
to use this ... You will still need to buy PowerPC based computers. And who is one of the largest and most noted for selling powerPC based PCs... Apple Computer; so why not just run MacOS X?
Buying an Apple computer complete with operating system means you're unlikely to want to install NetBSD if your already happy with MacOS X. However, have you seen the cost of MacOS X "upgrades"? £100+ in the UK for what is essentially bugfixes and performance improvements in the VM system. Then NetBSD in the long term starts to look very affordable, ignoring the fact that it outperforms MacOS X on the same hardware (quite remarkable until you consider how fundamentally poor Mach is as a desktop OS kernel).
Chris
Re:You still need a PowerPC machine (Score:1)
I'll bet you anything that OSX apps under NetBSD will be significantly buggier and worse performing than under OSX, even unupgraded versions. This looks a lot like Wine for PPC, and we all know how reliable Wine is, even after ten years of development.
Re:You still need a PowerPC machine (Score:2)
I'll bet you anything that OSX apps under NetBSD will be significantly buggier and worse performing than under OSX
If, and that's a big "if" at the moment, this compatability layer gets completed then expect OSX aps to run faster and as stable under NetBSD. Why? Well unlike Wine or GNUStep, NetBSD compatability layers don't emulate an environment like Win32 or OpenStep, but a Unix-like kernel. Look at the Linux or Irix compatability layers in NetBSD as an example. By enabling Linux compatability in my kernel, and installing a few application level libraries from SuSE Linux, I can run most Linux binaries on the same architecture.
So to be frank, you may still need a copy of OSX lying around from which to get those application level libraries (although GNUStep is fast approaching a state where that wont be necessary). On the performance and stability front, look to the glowing reputation of existing compatability layers in all three of the *BSD's.
Chris
Re:You still need a PowerPC machine (Score:1)
Re:You still need a PowerPC machine (Score:1)
Doing the reverse-- running X11 inside of OS X feels like too much overhead and complexity. Typing in X11 applications is often slow this way. Plus, OS X isn't completely open source, so it's hard to tinker with and debug.
Re:You still need a PowerPC machine (Score:3, Troll)
Re:You still need a PowerPC machine (Score:2, Informative)
(Cygwin is a poor pacifier for the real thing. I know, I still have to use it every day. At best, it works like it's supposed to, but much of the time, it's just a waste of time and effort.)
Re:You still need a PowerPC machine (Score:2, Informative)
Re:You still need a PowerPC machine (Score:2)
It would be amazingly ironic if netbsd's ability to run on every platform invented since the MMU ended up being coupled later with the ability to emulate a bunch of different processors and actually catapulted it to the top of the technology heap.
Nifty. (Score:5, Informative)
What works?
On NetBSD/i386: nothing. On NetBSD/powerpc, most UNIX binaries, such as ls, sh, or vi will work. No Graphical User Interface (GUI) based program will work for now. We are able to startup WindowServer up to the first attemps to use the IOKit. See the kernel traces for WindowServer and for mach_init to discover how far we have been.
Here is what have been implemented so far:
Mach-O binaries loading
Mach system calls handling
Minimal Mach ports, messages and rights support, so that simple program are able to link and run.
Signals handling (except for siginfo) Minimal multithreading support
Support in ktrace/kdump to display Mach messages (useful for debugging)
Hacks to get mach_init starting (and to get it behaving as bootstrap mach_init)
Support for port rights carried by Mach messages
Here is what is in the TODO list:
Implement Mach notifications for destroyed ports, dead names, and no sender ports
Re-implement enough of Darwin's IOKit to get
WindowServer actually displaying something.
Use COMPAT_MACH for COMPAT_OSF1 (Tru64 binary emulation on NetBSD/alpha), to get multithreading working.
Get Darwin binaries to link and run on NetBSD/i386
Re:Missing Apple libraries (Score:3, Insightful)
"Once we will have a fully functionnal Darwin binary compatibility on NetBSD/powerpc (if that happens some day), we will just have to grab Mac OS X libraries to run any MacOS X program"
I.e. you would still have to have the whole Mac OS windowing, graphical, and multimedia (QuickTime) environment for something like Photoshop to run. That's a far cry from just getting Darwin running.
The only legal way to get the Mac OS libraries is to buy Mac OS from Apple. Or reimplement them in a legally defensible way. Good freaking luck.
Re:Missing Apple libraries (Score:1, Insightful)
Re:Missing Apple libraries (Score:2)
I'm assuming that this NetBSD kernel+shim is being used to replace just Apple Open Sourced components , in which case, you seem to fall within the scope of section 2B of the Mac OS X License [apple.com].
To be totally careful, your step 2 would have to be Joe User nukes the shipped Darwin kernel with his new kernel, but I doubt it makes a difference, as long as it is the same computer; the computer can run only one of them at a time.
2. Permitted License Uses and Restrictions.
B. Certain components of the Apple Software have been or may be made available by Apple on its Open Source web site (http://www.opensource.apple.com/) (collectively the "Open-Sourced Components"). You may modify or replace only these Open-Sourced Components; provided that: (i) the resultant Apple Software is used, in place of the unmodified Apple Software, on a single Apple-labeled computer; and (ii) you otherwise comply with the terms of this License and any applicable licensing terms governing use of the Open-Sourced Components. Apple is not obligated to provide any maintenance, technical or other support for the resultant Apple Software.
Re:Nifty. (Score:2)
I'm betting that WindowServer is a PPC binary; good luck running it on x86.
What about... (Score:2, Insightful)
Re:What about... (Score:4, Interesting)
Running Gnustep on NetBSD? It has most of the NEXTStep/OS X libs already ported over to Linux (And therefore easily ported to NetBSD)...
GNUStep is already in the NetBSD packages collection, in several packages split across devel and x11. Install it along with WindowMaker and you've got a convincing NeXT clone ...
Chris
Re:What about... (Score:5, Informative)
Re:What about... (Score:1)
Re:What about... (Score:2)
I wonder if it will look as good as Aqua? (Score:2)
This will be one of those things where it's cool because you can do it, but is there really any reason to do it? Kinda like Mac on Linux [maconlinux.org].
MOL (Score:4, Interesting)
I have also found MOL to be far more reliable than Classic on OSX. Classic is much slicker in that OS 9 apps run directly on the Quartz desktop and one can cut and paste between apps. This also means it is more complex and therefore failure prone. My boss has no end of trouble with it. Classic icons go missing or change themselves into another apps icons. Some Classic apps will lock and won't release control to the Aqua UI. This means the machine is locked up for end user intents and purposes. Classic inflicts HFS metadata problems and some instability on OS X and kills much of OS X advantages if one has to make heavy use of OS <=9 apps. On the other hand if the OS 9 in my MOL sessions screws up then I can kill it and restart without affecting my Linux session. Since I boot my MOL session from an image I have an advantage normally only associated with virtual PC. If that boot image gets messed up, I can replace it from a backup quickly. Incidentally, MOL is very close to running OS X acceptably...eye candy and all.
MOL is can also be used as a user mode Linux. One can boot another acceptably fast Linux inside a virtual machine. This is useful for things like kernel development. MOL is far from pointless.
Re:I wonder if it will look as good as Aqua? (Score:2, Interesting)
Re:I wonder if it will look as good as Aqua? (Score:2)
In particular they aren't intending to recreate the widget toolkit it seems, or indeed, many of the libs at all, they just want Mach/Darwin compatability in NetBSD. You'd still need to buy a Mac with an OS X license for it to work.
That makes it fundamentally different to Wine by the way for those who are wondering - wine is a complete reimplementation of the Windows APIs so you can run Windows apps without buying Windows. This is just letting NetBSD use some OS X code, not quite the same thing.
Would It Be Faster Than OS X? (Score:2, Interesting)
Re:Would It Be Faster Than OS X? (Score:3, Interesting)
No, from the page:
Once we will have a fully functionnal Darwin binary compatibility on NetBSD/powerpc (if that happens some day), we will just have to grab MacOS X libraries to run any MacOS X program
This means, NetBSD might have the original OS X GUI (including overhead and eye candy effects ^_^) in the future.
Making GNUstep [gnustep.org] binary compatibe with Quartz should be the solution you're looking for (in that case, it would also work with the original Darwin).
Re:Would It Be Faster Than OS X? (Score:2)
OS X's GUI slow? Are you out of your mind? Of course it's not slow! The highly advanced Aqua GUI is the fastest GUI in existence because of OpenGL acceleration! I don't have a Mac but Slashdot says so so it must be true!
The Coolness (Score:1)
Not what Apple wanted (Score:2, Interesting)
Most FreeBSD users I know have no interest in Photoshop or Office anymore now that the alternatives are as mature as they are. I think users of any BSD would enjoy this new compatibility, but I think it could be just as valuable to everyone (except MS) if MacOS X gained some compatibility layers.
Re:Not what Apple wanted (Score:2)
It doesn't matter if someone writes an implementation of Cocoa and a Darwin binary compatibility layer for [insert kernel name here]. If you're running any of Apple's code it means you either bought the software from them or bought a machine from there that software came on. If I made cars and you bought one from me and promptly lit it on fire when you got home I would not car as long as your money was good.
Having a binary compatibility layer like this means NetBSD could act as a drop-in replacement for Darwin at some point. The OO fundamentals of OSX are designed to allow this, even if it is someone else who does it. This sort of stuff just gives Apple more cool factor among the compile everything from source open source project hacking geeks that two years ago spoke their name with a spite and bitterness reserved only for a special few.
iTunes? (Score:1)
ah How DUMB are slashdoters? (Score:4, Insightful)
The status report link is from 1/2002...
Did anybody bother to read it before posting?
70 people so far did not..
The actual project ot watch is not NetBSd..in that they don't have the nice Apple relationship like Darwin does..
In fact if my memory is right the proejct was stopped because they were duplicating Darwin's efforts..
To see if MacOSx will run under intel machines check Darwin porject site not NetBSD!
Come on People read once in awhile
Show yourself to better than those wintel geeks who don't even read but jsut spout what MS Gates wants..
WRONG (Score:1, Informative)
Re:ah How DUMB are slashdoters? (Score:2)
maybe the way to a cheap mac? (Score:2)
Anyone know what kind of speed a powerpc emulator running on a x86 would get?
If this OSX apps on BSD/PowerPC jazz works, what would you get if you coupled it to a powerpc to x86 emulator and had OSX running on a x86?
Even if it ran at half the speed you might end up getting a cheaper 'mac' because x86 hardware is cheaper?
Re:maybe the way to a cheap mac? (Score:1, Flamebait)
Re:maybe the way to a cheap mac? (Score:2)
Re:maybe the way to a cheap mac? (Score:2)
If i only had more time. (Score:2)
For those who think this is a dumb idea.. you're not seeing the bigger picture. Currently, MacOS X only runs on G3 and G4 apple machines designated by Apple unless you boot Linux and install Mac On Linux (similiar to Plex86 for PPC). If you can run OSX applications on Linux, NetBSD, etc.. then you wouldn't need the overhead of a VM. Your RS6000 could run OSX with minimum overhead. From NetBSD you could run from the same machine, binaries compiled for: OSX, Linux, FreeBSD, and NetBSD.
Personally, I don't like OSX; However, I wouldn't mind being able to run natively on Linux: Internet Explorer, Quarx Express, etc.. Not to mention that Quartz is a pretty neat looking, X11 compatable (with Xfree86-rootless) windowing system.
This is more important for Linux than NetBSD, only because NetBSD currently has poor support for devices on many PowerPC machines (compared to Linux), especially laptops.
Name for the project (Score:2)
How about "OSXE"? Pronounced "Oh sexy."