Slashdot Mirror

No it's not. Darwin *only* runs on Intel BX chipsets.

Hmm... Open Darwin's hardware compatibility page says otherwise:

http://www.opendarwin.org/hardware/

I see motherboards from ASUS through to Shuttle and Tyan, all using a variety of chipsets, and both AMD and Intel CPUs. Any other naysayers?

http://www.opendarwin.org/

That [Mac WINE] does have interesting implications. But it's going to require a LOT of work to make that work, above and beyond what Wine's already doing. Wine will have to be practically rewritten for cocoa. Otherwise we'll be running the partially-incompatible wine translation layer inside the compatible-but-awkward X11 translation layer. Eww. I don't really expect wine for os x to get to the point your average person can run it for a long time, and I don't expect it to really work ever unless Apple themselves decide to put some work into it.

Take a look at Darwine, which runs on PPC/OS X. The immediate plan, which they seem to have working, is to use winelib as a sort of open-source Windows API, and recompile apps working on WINE/x86 for PPC, and run those on X11. This means that developers can start working now on moving these to Aqua instead of X11 and getting WINE "practically rewritten for Cocoa". When the x86 Macs get released, the recompiling stage won't be a problem, and closed-source apps should be able to run. Moreover, Darwine already works (as much as WINE does), so even if no further work is done on the project, it should be able to run on the x86 Macs under X11.

The future goal of Darwine seems to be using an emulator to run x86 code on PPC, but they don't seem to have that working yet. Anyway, it's irrrelevant for the x86 Macs.

I see alot of comments about how OS X will never run on commodity x86 hardware, how the x86 BIOS and OpenFirmware are too different, blah, blah. Newsflash! Darwin, the core of OS X has been running on x86 almost since it was first introduced to the public [1], [2], [3].

The core of OS X is booting and running on commodity hardware NOW. There is no speculation needed. It's here.

I also hear complaints about how now Apple is starting from scratch again with their software base, libraries, etc. Newsflash #2. They're almost starting from scratch, but with a much larger audience, AND a more enthusiastic developer base (see [1],[2],[3] yet again, and [4]).

Steve Jobs knows this. Why do you think he's releasing this preview for developer consumption now? Because by the time the x86 Apple machines actually ship, developers and users will have already been running full Darwin/OS X x86 system for quite awhile. He's leveraging early adopters and the OSS movement. This will be a far better transition than the m68k/PPC was.

[1] http://www.opendarwin.org/
[2] http://developer.apple.com/darwin/
[3] http://www.gnu-darwin.org/
[4] http://darwinports.opendarwin.org/

I see alot of comments about how OS X will never run on commodity x86 hardware, how the x86 BIOS and OpenFirmware are too different, blah, blah. Newsflash! Darwin, the core of OS X has been running on x86 almost since it was first introduced to the public [1], [2], [3].

The core of OS X is booting and running on commodity hardware NOW. There is no speculation needed. It's here.

I also hear complaints about how now Apple is starting from scratch again with their software base, libraries, etc. Newsflash #2. They're almost starting from scratch, but with a much larger audience, AND a more enthusiastic developer base (see [1],[2],[3] yet again, and [4]).

Steve Jobs knows this. Why do you think he's releasing this preview for developer consumption now? Because by the time the x86 Apple machines actually ship, developers and users will have already been running full Darwin/OS X x86 system for quite awhile. He's leveraging early adopters and the OSS movement. This will be a far better transition than the m68k/PPC was.

[1] http://www.opendarwin.org/
[2] http://developer.apple.com/darwin/
[3] http://www.gnu-darwin.org/
[4] http://darwinports.opendarwin.org/

I see alot of comments about how OS X will never run on commodity x86 hardware, how the x86 BIOS and OpenFirmware are too different, blah, blah. Newsflash! Darwin, the core of OS X has been running on x86 almost since it was first introduced to the public [1], [2], [3].

The core of OS X is booting and running on commodity hardware NOW. There is no speculation needed. It's here.

I also hear complaints about how now Apple is starting from scratch again with their software base, libraries, etc. Newsflash #2. They're almost starting from scratch, but with a much larger audience, AND a more enthusiastic developer base (see [1],[2],[3] yet again, and [4]).

Steve Jobs knows this. Why do you think he's releasing this preview for developer consumption now? Because by the time the x86 Apple machines actually ship, developers and users will have already been running full Darwin/OS X x86 system for quite awhile. He's leveraging early adopters and the OSS movement. This will be a far better transition than the m68k/PPC was.

[1] http://www.opendarwin.org/
[2] http://developer.apple.com/darwin/
[3] http://www.gnu-darwin.org/
[4] http://darwinports.opendarwin.org/

I see alot of comments about how OS X will never run on commodity x86 hardware, how the x86 BIOS and OpenFirmware are too different, blah, blah. Newsflash! Darwin, the core of OS X has been running on x86 almost since it was first introduced to the public [1], [2], [3].

The core of OS X is booting and running on commodity hardware NOW. There is no speculation needed. It's here.

I also hear complaints about how now Apple is starting from scratch again with their software base, libraries, etc. Newsflash #2. They're almost starting from scratch, but with a much larger audience, AND a more enthusiastic developer base (see [1],[2],[3] yet again, and [4]).

Steve Jobs knows this. Why do you think he's releasing this preview for developer consumption now? Because by the time the x86 Apple machines actually ship, developers and users will have already been running full Darwin/OS X x86 system for quite awhile. He's leveraging early adopters and the OSS movement. This will be a far better transition than the m68k/PPC was.

[1] http://www.opendarwin.org/
[2] http://developer.apple.com/darwin/
[3] http://www.gnu-darwin.org/
[4] http://darwinports.opendarwin.org/

Running Mac OS X on Intel will not be a difficult transition. In fact Darwin, the core of Mac OS X, already runs on x86 hardware. It will be very disappointing, however, if Apple--a company that has distinguishes itself with innovative products--looses its identity in the x86 washing machine. What about the Cell processor? If this process is based on the PowerPC core doesn't that mean that the new PowerPC IS the Cell? Why abandon the PowerPC just when massive speed advances are on the horizon? Why abandon a chip that seems perfect for multimedia applications when Macs are THE platform for creative purposes?

even if you use more or less standard pc parts its still pretty easy to change enough to break stuff look at the xbox for example

Yeh, it's a perfect example. All you need to do to unbreak the XBox is run some code... any code... on it. Once you can do that you're home free. The hard part about cracking the XBox is tricking it into running some code for you. A general-purpose operating system by definition does not have that protection, especially when you're trying to break it the other way: you're booting the OS into an environment you control.

and unless you have source to the os its bloody hard to deal with such breakages

That's why it's a ludicrous idea: we do have the source.

Sounds like you've never heard of Fink or Darwin Ports. Which is ironic given that you were berating the GP for not knowing about Linux useability features.

That's also what they would say if they were designing APIs in a XBox1 work-alike setup. Recompiling an Xbox1 game doesn't mean a complete rewrite. A lot of what they would be doing to get Xbox1 games to compile for the XBox360 is writing APIs that act exactly like they did on the XBox1. The XBox360 development enviroment is going to be very similar to the XBox1.

Creating a work-alike API for the XBox1 would be very hard, but definately possible. I'm not sure with the hardware they announced that a simple binary emulator(like the current Virtual PC) would work at all.

If they go with an emulator I'd guess they would pass as many API calls to the host as possible, similar to what DarWine is trying to do with QEMU. You can currently only use DarWine to compile windows programs on MacOSX, but x86 binary compatability is planned for the second phase.

Microsoft definately has their work cut out for them wether they are emulating or recompiling. If they can't get at least 75% of XBox1 games working on the XBox360 at launch, then announcing backwards compatability is going to hurt them rather then help them.

If you're worried about Apple learning where you live, get the files from opendarwin.org instead.

too true , and you can infact run the unix base of OS X on x86 http://www.opendarwin.org/ without the aid of an emulator.
What i find to be the charm of OS X is the coupling of a great unix core with a charming GUI and the applications therein(naturaly also the frameworks aswell)

If all you care about is the unix base in os x then opendarwin is progresing steadily ( http://www.xdarwin.org/about/ may also be of intrest)

You seem a bit defensive. I think I was actually pretty fair. In any case.

I don't know how you are doing your counting, I'm not sure what the results for darwin would be if you were to use a similar method. Darwin ports isn't binary and they don't have minor variants so many of the seperate packages on fink wouldn't be seperate on darwinports. That being the case lets look at a few random examples:

Database fink, darwin.

Editors darwin fink

Development darwin fink.

I think my comment is fair. The fink list is loaded with slight variations while the darwin ports list contains more elements which are genuinely different. And darwin even has more catagories.

_________________________

Both projects are active. But again if I look at actual packages I tend to find the darwin version is more up to date than the fink version. Are you disagreeing and if so how would you propose we test?

You seem a bit defensive. I think I was actually pretty fair. In any case.

I don't know how you are doing your counting, I'm not sure what the results for darwin would be if you were to use a similar method. Darwin ports isn't binary and they don't have minor variants so many of the seperate packages on fink wouldn't be seperate on darwinports. That being the case lets look at a few random examples:

Database fink, darwin.

Editors darwin fink

Development darwin fink.

I think my comment is fair. The fink list is loaded with slight variations while the darwin ports list contains more elements which are genuinely different. And darwin even has more catagories.

_________________________

Both projects are active. But again if I look at actual packages I tend to find the darwin version is more up to date than the fink version. Are you disagreeing and if so how would you propose we test?

You seem a bit defensive. I think I was actually pretty fair. In any case.

I don't know how you are doing your counting, I'm not sure what the results for darwin would be if you were to use a similar method. Darwin ports isn't binary and they don't have minor variants so many of the seperate packages on fink wouldn't be seperate on darwinports. That being the case lets look at a few random examples:

Database fink, darwin.

Editors darwin fink

Development darwin fink.

I think my comment is fair. The fink list is loaded with slight variations while the darwin ports list contains more elements which are genuinely different. And darwin even has more catagories.

_________________________

Both projects are active. But again if I look at actual packages I tend to find the darwin version is more up to date than the fink version. Are you disagreeing and if so how would you propose we test?

Seems like you totally confused GNU-Darwin (which hosed your system) with OpenDarwin and it's DarwinPorts project.

And if you can't stomach the soul-eating registration, use the OpenDarwin mirror (or get the tarball).

And if you can't stomach the soul-eating registration, use the OpenDarwin mirror (or get the tarball).

I'm sitting on a Slackware box and I've downloaded the launchd code. First and foremost, it depends on CoreFoundation. I'm not sure what that is but the name alone leads me to believe that it's MacOS X specific which would make it tedious to port. Also, I couldn't find the CoreFoundation code at opendarwin.org so that was a dead end (my effort to find it was half-hearted).

It looks doable but I doubt anyone will be porting this to Linux. It would be far easier on one of the BSD's that may have some (of several) missing headers. The BSD's are, however, touchy about licenses so I wouldn't hold my breath and I seriously doubt you'll ever see this in any of the BSD base systems. Maybe in ports.

It's licensed under Apple Public Source License which makes me personally a bit nervous because I don't want to deal with yet-another-license. There may be patent implications too (honestly I don't know), and if so, no one will touch this even with a 10 foot pole.

In short, it would've been cool to have it but I don't think it's gonna happen. It's more likely we'll see some FOSS hackers re-inventing the wheel on this one. Keep in min that this is just my humble opinion and a lot of guessing (read: not to be taken as facts). Anyone in the know is free to speak up.

I'm sitting on a Slackware box and I've downloaded the launchd code. First and foremost, it depends on CoreFoundation. I'm not sure what that is but the name alone leads me to believe that it's MacOS X specific which would make it tedious to port. Also, I couldn't find the CoreFoundation code at opendarwin.org so that was a dead end (my effort to find it was half-hearted).

It looks doable but I doubt anyone will be porting this to Linux. It would be far easier on one of the BSD's that may have some (of several) missing headers. The BSD's are, however, touchy about licenses so I wouldn't hold my breath and I seriously doubt you'll ever see this in any of the BSD base systems. Maybe in ports.

It's licensed under Apple Public Source License which makes me personally a bit nervous because I don't want to deal with yet-another-license. There may be patent implications too (honestly I don't know), and if so, no one will touch this even with a 10 foot pole.

In short, it would've been cool to have it but I don't think it's gonna happen. It's more likely we'll see some FOSS hackers re-inventing the wheel on this one. Keep in min that this is just my humble opinion and a lot of guessing (read: not to be taken as facts). Anyone in the know is free to speak up.

Yeah, the FreeBSD part is a "kernel within a kernel" (kind of like the executive in Windows NT). And of course, there actually is an x86 port of the whole mess. It doesn't come with the GUI jazz, but if you slap on GNUStep, you've basically got a NeXT box, which ain't a bad start.

As for Apple entering the x86 arena full-force, don't look forward to it. I don't think Apple is eager to compete in the same razor-thin margin market that even IBM couldn't turn a profit on. Competing with Dell is dumb. Competing with Microsoft is dumb too; I'd rather see Apple relegated to perpetual niche status than perpetual death status like Be was or NeXT nearly was.

And the hardware's pretty nice in its own right too.

I just don't understand why an entire computer's hardware has to be emulated in software, and then the operating system, with all its polling and processing loops, interrupt handling, and background crap that it does, has to be emulated as well.

Darwine is going to eliminate that. It's going to have an application loader, so when you click a Windows .EXE in Mac OS, it will open it in a loader. QEMU will then run the executable, emulating only the processor. All system calls will convert data structures to Mac format and then call Wine functions, which will be compiled natively under Mac OS. I think this will bring about a tremendous speedup, as only the application will be running, and applications spend nearly all of their time just waiting for input, so it won't take hardly any processor resources; and finally, only the program's inner workings will run under emulation. This is exciting!

And screw Windows, SP2 and all... That OS is so full of vulnerabilities and bugs that it's not even funny anymore. Microsoft just patches upon fix forever. Their code probably contains functions 1000 lines long that have indents going so far to the right that they're voting Republican and attacking the Middle East for cheap oil, which keeps going up anyway. (Proof, as much as I hate to admit it, that Bush didn't lie about Iraq, 'cuz if he did, Gas would cost fifty cents a gallon by now. I hate to admit it, but I was wrong about him.)

Yeah. Windows sucks.

i imagine you'll be able to use xpostfacto to install it.

Ok, where is the souce code so I can compile this on my PC?

Well, first, you're confusing "open systems" with "open source", but since you insist... try here or here.

Want free software? What's wrong with the following:
Gentoo for OS X: http://www.metadistribution.org/macos/
Darwin Ports: http://darwinports.opendarwin.org/
Fink: http://fink.sourceforge.net/
Freshmeat: http://osx.freshmeat.net/
Sourceforge: http://sourceforge.net/softwaremap/trove_list.php? form_cat=309

I need clarification. Are we discussing Open Source Software or Open Source GUIs?

Mac OS X has an open source kernel, a closed source GUI, OSX specific frameworks and some apple specific drivers. I don't see what the problem is. They have to have something extra to entice people to buy their OS. Fortunately, they support open standards and document their APIs very well. I consider "open standards to be far more important that open source software. as the former help to prevent vendor lock in while the latter does not necessarily do that. What good is it to have open source software if it does not support interoperability?

Running Linux or FreeBSD on a mini will gain you nothing for software availability and you will lose WiFi support so I really don't see what is the point to not run OSX.

Mind reader.

1. Installing Linux or BSD takes time and experience; Mac OS X comes preinstalled.
2. You can run most Linux/BSD software on Mac OS X. X11 comes preinstalled, too.
3. Mac OS X doesn't lack any package management systems: Fink, DarwinPorts and now even Gentoo MacOS.
4. No need to compile and install drivers for any devices you have. They are preinstalled.
5. If you don't like the Mac OS X GUI, run X11 with your favourite window manager in fullscreen. It works perfectly.
6. You can easily use X11 and the Mac OS X GUI at the same time. It works perfectly, too.

The list goes on.

"Free Software on a Cheap Computer" doesn't mean getting rid of Mac OS X, dammit.

there's also Darwin, which is the BSD-core of Apple's Mac OS X. Darwin is Open Source, though Apple is pretty finnicky about who they let contribute for obvious reasons (it's the core of a commercial Operating System). There's also OpenDarwin which is basically a community controlled branch of Darwin that occasionally serves as a testbed for standard Darwin features. Darwin is based on a Mach 3.0 microkernel, though it's more of a hybrid than that simplistic description would suggest.

Any other names?

Feral Tabby.

I'm pretty sure it's possible to install on those machines with XPostFacto.

"wouldnt it be nice it they made OSX for a x86"

But they do, they just don't sell it.

In an interview last year, an Apple executive confirmed that an x86 port of OSX, aka Marklar does exist in Apple's labs and that they are keeping it on par with PPC development.

Before the release of the G5, Steve Jobs said in another interview that they do not plan to move to x86 but that they like to keep their options open.

If you take these two statements and add one and one together, it should become obvious that they have no intent to change their business model from making and selling "hardware including software" to "software including hardware" or even "software only". In other words, Marklar is just an insurance policy against unpredictable disaster scenarios where Apple would be forced to move to another CPU and as a result, Apple have a stronger negotiating position with IBM.

Consequently, for as long as IBM do a good job on fostering PPC, for as long as PPC is competitive, Apple have very little reason to move.

And should they ever decide to move, or should they decide to offer OSX on x86 in addition to PPC, their business model will almost certainly remain the same, meaning OSX will continue to be made to run on Apple hardware only, regardless of CPU compatibility.

So, you would then see an x86 Mac with exactly the same treats as today, from OpenFirmware to Apple's own motherboard designs, not compatible with other x86 hardware. In fact, such an x86 Mac might even have a custom x86 CPU, made only for Apple, ie bolted on AltiVec compatible SIMD. Without specific hacks, OSX would not run on other x86 machines. Likewise, Windows would probably not run on such an x86 Mac without some extra software from Microsoft, eg. Virtual PC or Mac/x86. Such an arrangement would also likely have Microsoft continue MS-Office development for the Mac - even more reason for Apple to choose such a path if they ever were to go x86.

So, whether or not Apple will release OSX on x86, if you want OSX on non-Apple x86 hardware, you will almost certainly have to rig your own.

Mind you, you can do this within limits already today. Darwin, the core of OSX, is available for x86 and it's a free download ...

http://www.opendarwin.org/en/downloads

You can get GNUstep and run it on top of Darwin x86

http://www.gnustep.org

GNUstep is the GNU implementation of OPENSTEP, the foundation on which Cocoa is build. In addition, GNUstep has some, but not all of the things Apple has added, so you get Cocoa compatibility within limits. This is as close as you can get OSX on x86 today. It's free, but it requires a little more effort than an OSX installation on a Mac. And if you want the OSX eye candy, you will also need to do a bit of DIY. If you do, consider becoming a contributor to the GNUstep project.

Thus, it comes down to paying a little extra for convenience or save some money and put in some work. You can't have it both ways. Remember, there ain't no such thing as a free lunch.

Open Source Projects:
BSD Ports http://darwinports.opendarwin.org/
APTGET http://fink.sourceforge.net/
X11 http://www.xdarwin.org/
A lot of OS X and cross-platform projects http://sourceforge.net/softwaremap/trove_list.php? form_cat=309
Gentoo anyone? http://www.metadistribution.org/macos/
Freshmeat has a lot of OS X and cross-platform projects http://freshmeat.net/browse/839/
http://www.opendarwin.org/
http://developer.apple.com/darwin/

As you can see, contributing the OS X platform does not mean abandoning OSS or cross-platform software development.

You can contribute to Open Darwin or to the many cross-platform software projects on freshment or sourceforge.

Open Source Projects:
BSD Ports http://darwinports.opendarwin.org/
APTGET http://fink.sourceforge.net/
X11 http://www.xdarwin.org/
A lot of OS X and cross-platform projects http://sourceforge.net/softwaremap/trove_list.php? form_cat=309
Gentoo anyone? http://www.metadistribution.org/macos/
Freshmeat has a lot of OS X and cross-platform projects http://freshmeat.net/browse/839/
http://www.opendarwin.org/
http://developer.apple.com/darwin/

As you can see, contributing the OS X platform does not mean abandoning OSS or cross-platform software development.

You can contribute to Open Darwin or to the many cross-platform software projects on freshment or sourceforge.

I can't, because "WINE IS NOT AN EMULATOR". *sigh*.

Here, Have a cookie and fuck off. I hate these karma-whoaring trolls.

The Darwine project has winelib running on OS X, and aims to tie QEMU to WINE to allow windows apps to run with the binaries in the emulated environments and the wine calls running on the native platform.

Wine does not work on a non-intel system.

Mind if I call bullshit?

So CompUSA is the gatekeeper of OSS project compliance? Wow, I hope we get one in my hometown soon.

Meanwhile, I'll have to visit Apple's Darwin Page for more information.

Or I can skip the education and go right to the download page at The Open Darwin Page

it's available for PPC and x86 (on the same ISO, presumably to facilitate packaging at CompUSA)

Crippled? Care to explain how? You can run http://opendarwin.org/ on more models of Macintosh than you can run OSX out of the box (utilizing XPostFacto). Plus, you can run it on several different x86 motherboards. It has a fully functional X system too for all the GUI goodness you could want. It has a rich and growing ports http://darwinports.org/ collection.

If OpenDarwin is crippled, then so is every *Linux and *BSD distribution out there.

Yeah, you definitely put your foot in your mouth.

cr

port install gtk2-clearlooks

You're a little hasty calling OS X lame on the desktop and server. Browse here and here and here. OS X covers a much wider range of uses than any other *nix out there. On the desktop it can run most of the X11 sw out there + the big name sw from Adobe, MS, Macromedia, etc. On the server, you can tweak it just like any other OSS *nix since you have a CLI and free access to the source. OTOH, the GUI is an option for those lacking your elite hacking skills who would have used MS Server but heard this was better...

afaik the only way to run wine on linux-ppc (WINE is not an emulator, and so is x86 dependent) is by using qemu...

also check out darwine... integrated qemu + wine under OS X so you can http://darwine.opendarwin.org/ click on windows apps and run them seamlessly in OS X

fabrice bellard is a processor emulating god imho

There is the fink http://fink.sourceforge.net/ project, Gentoo for Mac OS X http://www.metadistribution.org/macos/, Darwin ports http://darwinports.opendarwin.org/ or you could just install linux.

Also check out versiontracker.com for a lot of Open source software with pretty GUIs.

There actually is a PowerPC port of WINE. For obvious reasons, it only offers source compatibility with Windows.

First, install QEmu. (I prefer to install it through DarwinPorts)

Then download a x86 Linux Live CD ISO, for example Knoppix.

Then:
$ qemu -cdrom knoppix.iso -boot d

Simple as that. Networking will work out of the box.

You can also install Debian on a virtual harddrive using:
$ dd if=/dev/zero of=sarge.hdimage bs=1000000 count=2000
$ qemu -hda sarge.hdimage -cdrom debian-netinst.iso -boot d
When installed, start QEmu with:
$ qemu -hda sarge.hdimage

Even better, after installation, copy the kernel and the initrd to your Mac (using sftp) and start qemu with:

$ qemu -hda sarge.hdimage -kernel kernel-file -initrd initrd-file -append "root=/dev/hda1 console=ttyS0,38600" -nographics

Then you will get the console on a virtual serial port (which is your current terminal window) and it doesn't have to emulate any graphics at all.

There's nothing preventing you from installing OpenDarwin http://www.opendarwin.org/ on x86. This puts you effectively in an OS X environment on x86, only without the Aqua UI.

My Dad runs OS X 10.3 on my old Beige G3 Desktop. He used XPostFacto to get the 10.3 installer to work. It has 768 megs of ram, and has been upgraded with an ATI Rage 128, a 5-port USB 2.0 card, CD burner and 40 gig HD. It is surprisingly responsive.

And too bad if you're running Mono on a non-x86, non-Linux system since winelib is x86 only (for now).

From the Darwine FAQ:
It means that WineLib is now working on Mac OS X, and that developers should be able to recompile their Win32 Apps using WineLib and make them work in Mac OS X.

It's not really missing a ports tree. Now there is Darwin Ports which is written, at least in part, by Jordan Hubbard, who also created the ports system on FreeBSD. It uses Tcl as its scripting language, and all the "portfiles", which are similar to the port makefiles on FreeBSD, are written in Tcl. It's fuller featured than FreeBSD's ports, but has far fewer ports available. I personally prefer it over Fink.

Except that Apple released the entire source distribution of OS X to the community, minus the Aqua display system.

2. The kernel source is not available because it's the least complex part of the OS -- it's available partly because it's one of the more complex pieces, and a lot of really smart people who know their stuff in kernel space look at / debug / suggest additions for it.