Slashdot Mirror
NetBSD's COMPAT_DARWIN Adds XDarwin Support
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."
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?
Is this truly the only Earth I can live on?
So in plain English this means that Mac OSX programs will soon be able to run on BSD and eventually Linux?
You say things that offend me and I can deal with it. Can you?
I'm not a complete tech-idiot, but this article made my head spin. Can someone explain what this means and what the impact of it is?
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?
Karma: Chameleon (mostly due to the fact that you come and go).
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.
Brennan Stehling - http://brennan.offwhite.net/blog/
[ed. note: in the following text, former FreeBSD developer Mike Smith gives his reasons for abandoning FreeBSD]
When I stood for election to the FreeBSD core team nearly two years ago, many of you will recall that it was after a long series of debates during which I maintained that too much organisation, too many rules and too much formality would be a bad thing for the project.
Today, as I read the latest discussions on the future of the FreeBSD project, I see the same problem; a few new faces and many of the old going over the same tired arguments and suggesting variations on the same worthless schemes. Frankly I'm sick of it.
FreeBSD used to be fun. It used to be about doing things the right way. It used to be something that you could sink your teeth into when the mundane chores of programming for a living got you down. It was something cool and exciting; a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile.
It's not anymore. It's about bylaws and committees and reports and milestones, telling others what to do and doing what you're told. It's about who can rant the longest or shout the loudest or mislead the most people into a bloc in order to legitimise doing what they think is best. Individuals notwithstanding, the project as a whole has lost track of where it's going, and has instead become obsessed with process and mechanics.
So I'm leaving core. I don't want to feel like I should be "doing something" about a project that has lost interest in having something done for it. I don't have the energy to fight what has clearly become a losing battle; I have a life to live and a job to keep, and I won't achieve any of the goals I personally consider worthwhile if I remain obligated to care for the project.
Discussion
I'm sure that I've offended some people already; I'm sure that by the time I'm done here, I'll have offended more. If you feel a need to play to the crowd in your replies rather than make a sincere effort to address the problems I'm discussing here, please do us the courtesy of playing your politics openly.
From a technical perspective, the project faces a set of challenges that significantly outstrips our ability to deliver. Some of the resources that we need to address these challenges are tied up in the fruitless metadiscussions that have raged since we made the mistake of electing officers. Others have left in disgust, or been driven out by the culture of abuse and distraction that has grown up since then. More may well remain available to recruitment, but while the project is busy infighting our chances for successful outreach are sorely diminished.
There's no simple solution to this. For the project to move forward, one or the other of the warring philosophies must win out; either the project returns to its laid-back roots and gets on with the work, or it transforms into a super-organised engineering project and executes a brilliant plan to deliver what, ultimately, we all know we want.
Whatever path is chosen, whatever balance is struck, the choosing and the striking are the important parts. The current indecision and endless conflict are incompatible with any sort of progress.
Trying to dissect the above is far beyond the scope of any parting shot, no matter how distended. All I can really ask of you all is to let go of the minutiae for a moment and take a look at the big picture. What is the ultimate goal here? How can we get there with as little overhead as possible? How would you like to be treated by your fellow travellers?
Shouts
To the Slashdot "BSD is dying" crowd - big deal. Death is part of the cycle; take a look at your soft, pallid bodies and consider that right this very moment, parts of you are dying. See? It's not so bad.
To the bulk of the FreeBSD committerbase and the developer community at large - keep your eyes on the real goals. I
Apple won't port OS X to i386 so we'll do it for them. That's the point. Even if we have to buy a copy of OS X and hack the install, we'd still be able to run it on i386. That's the point, and a damn good one if you ask me.
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...
Karma: Chameleon (mostly due to the fact that you come and go).
How good could it be? You don't see people bombing Sizzler, now do you?
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, 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 desired changes to the OS.
Running mass-market programs on an open source OS (and not under some sort of abstracted emulation layer) is an important holy grail. It'd be good to see, but I wouldn't be surprised if Apple started playing games like using digital signatures to thwart (or at least impede) these efforts.
"It is our blasphemy which has made us great, and will sustain us, and which the gods secretly admire in us." - Zelazny
Although the post by Emmanual Dreyfus indicates that XDarwin is essentially a test case, this is a rather important 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 like the fink working equally well on OSX and NetBSD. You could develop on OSX with its comfortable GUI and deploy to NetBSD with its comfortable price.
http://tinyurl.com/4ny52
It's for NetBSD/powerpc, not NetBSD/i386.
There's no emulation happening.
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.
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 :)
The war with islam is a war on the beast
The war on terror is a war for peace
IOKit points to drivers. So if someone crafts a driver for the Macintosh (popular consumer hardware platform, that), it should work:
... Remember, the existing Mac ports don't let you use Mac drivers any more than you can use Windows drivers on Linux/i386.
-On PowerPC machines running NetBSD, be they Macs or the few open PowerPC boards (AmigaOne, Pegasos) cropping up.
-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.)
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.
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.
Karma: Chameleon (mostly due to the fact that you come and go).
yes. the OS by the same company whose death has been proclaimed every 6 months for the last 20 years.
only problem with these proclamations of death is that they are, um... FALSE!
either you are a young tyke who has never used a Mac, or you are an old fart who should retire.
go away. just go away.
I am hopeful this means that at least Microsoft apps made for mac and Mac apps in general will "just work" on netbsd, and soon on linux. This alone is reason to celebrate.
However if there is the possibility of a Carbon/Aqua compatible GUI system, then an alternative to X/KDE/GNOME/FLUXBOX/ETC.... would be nice, if only to mess with peoples heads... "Yeah, it's a mac...A very special kind of mac...."
Why would you want to X and one of its clumsy window managers instead of Aqua, the best user interface around?
I think in this case he was talking about BSD.
Slashdot is very fond of declaring BSD dead.
-fred
Sign #11 of Slashdot overdose: You see the phrase 'moderate Republican' and you wonder if that would be a +1 or a -1.
LINE Is Not an Emulator
LINE executes unmodified Linux applications on Windows by intercepting Linux system calls. The Linux applications themselves are not emulated. They run directly on the CPU just like all other Windows applications.
Funny, I thought BSD's popularity was skyrocketing.
After all, all those MacOS X boxes... 3% market share... millions of people... plus, since Macs from back in 1998 can run the latest version of MacOS X (I'm typing on one now), and lots of people do that, probably significantly more than 3% of the installed base.
BSD sure isn't in any danger from where I'm standing, although who'd'a thunk that Apple would be its saviour?
-fred
Sign #11 of Slashdot overdose: You see the phrase 'moderate Republican' and you wonder if that would be a +1 or a -1.
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. 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.)
"COMPAT_DARWIN?" Was "Darwin Compatibility" something or other too ungeeky and accessible and English? If so then why not go full tilt and call it __CMPT_xxDKHSKH_DRWNXOJSOJ or something?
Dear family, friends, and associates of Anonymous Coward:
I regret to inform you that recently Mr. Coward has fallen ill with an unknown affliction, whose diverse symptoms include nausea, bleeding orifices, and trolling. In fact, the doctors have recently confirmed it: Anonymous Coward is dying.
Therefore, for when such time comes to pass, I formally invite you to come dance on the grave of Anonymous Coward.
Sincerely,
bersl2
That was funny (the BSD DYING punchline)
But more people use FreeBSD in the form of Linux than all linux users combined adn multiplied by 5.
source : Google Zeitgeist measures user search clicks and MacOS for 5 straight years, including this month, is always 5 times more popular than people using linux.
This is GREAT news...SCSI features apple took are back!
Apple made it illegal for even root processes to issue ANY scsi commands to a device if the device is a hard disk and the drive is hosting a mounted volume.
they said it was for security, HA!
Only one flavor of Solaris and the OSX prevent sending any scsi commands to hard drives.
without it you cannot log in or out of shared SAN sotrage devices.
SAN all has to be laboriously done over IP on macs and has huge latencies for distributed locking models (GFS) on-platter.
Now I can deploy IOKIT + powerpc binaries and STILL issue scsi coomands by merely using FreeBSD (the origin of the gutted Apple Darwin)
HURRAY FreeBSD
THANK YOU!!!!
But didn't answer the question. What's it useful for?
"Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house."
Really? I never thought FreeBSD was bought out, since it seems to be running completely seperate from BSDi, check your facts and grow up. It doesn't matter if there are 500,000 users, or 50,000 users. People who like BSD will use BSD, people who like Windows will run Windows, people who like Linux will run Linux. So end that bullshit and move on. BSD is not dead, and will never be dead.
NetBSD is multi-platform. So? Why would anyone want to use it? What has it really contributed to BSD? What has it really contributed to computing?
Exactly, because Everybody Knows that microkernels are slow.
... then Macs would take over the world!
(Does it count as a troll if you're serious?)
Wait, let me see if I can connect some of them...
Microkernels being slow are the reason Macs are so much slower than PC's! And if Apple would just:
(a) port to x86
(b) drop the microkernel in favor of Linux
(c) allow clones
(d) run Windows apps
(e) use Windows drivers
(f) eliminate their greedy 75% profit margins
Hey, this is fun!
Microkernels being slow are the reason Macs are so much slower than PC's! And if Apple would just:
... then Macs would take over the world!
(a) port to x86
It already runs on generic x86. I don't think Apple has the resource to write drivers for all the x86 hardware and hardware vendor will not do it either as they usually not do it for Linux.
(b) drop the microkernel in favor of Linux
BTW, I read somewhere (don't remember where) that context switching are a lot more expensive on x86 than PowerPC. So the extra advantages of microkernels comes at a much lower cost on PowerPCs than x86 wich may explained why a microkernel was chosen.
(c) allow clones
Mac OS X will run on non-Mac PowerPC hardware with Mac-on-Linux (because of drivers issues). Writing drivers for non-Mac hardware will allow running Mac OS X on non-Mac hardware natively.
Though it is illegal to run it on non-Mac hardware.
(d) run Windows apps
Why? Windows will run Windows apps and is pre-installed.
(e) use Windows drivers
Why? Drivers are very OS specific.
(f) eliminate their greedy 75% profit margins
I don't think they do that much money. MS will still have control since most people prefer MS products.
Its by the far the most easiest BSD to use and has alot of example files and scripts to hack with.
http://saveie6.com/
Oviously the person sitting there, waiting for BSD news has more than no life. I actually pretty sad for him/her.
Oh well, no link to netcraft stating this anywhere, but of course if you check netcraft, BSD is #1 still! LOLz!
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!]
Read Pynchon.
Don't forget, BeOS used a microkernel, and we all know how slow it was. It took almost 15 seconds to boot! I couldn't stand it. I remember how I used to play video games on my game boy to keep me entertained while I waited. And don't get me started on how it could only run Quake 2 25%-50% faster than any other OS. I mean, really, it was unplayable at such speeds. No wonder Be went out of business.
Linus says microkernels suck. I think we should all place our blind faith in whatever he says. So, next time someone comes around offering you a shiney new microkernel, remember to just say "no".
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.
... Remember, the existing Mac ports don't let you use Mac drivers any more than you can use Windows drivers on Linux/i386.
:)
So if you appreciate this, please do whatever Slashmojo it takes to make it visible, or do the same for the original?
---
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.
-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. Choose your poison based on the kernels, not subjective nonissues with userland.
Oh.
Well thats good too, at least in terms of avoiding all the foolish intel x86 oriented code crammed in the freeBSD OS.
long live portable c code
Are the Slashdot crowd really that Linux and x86 biased that they really do not know that there is news and progress on stuff that is neither x86 nor Linux? Come on - read the posting!
This is simply about this:
1) Mac OS X (and Darwin) has and will have lots of good commerical software developed for it. Of particular interest to the kind of people that run NetBSD are software packages which have no GUI; ie, will run on a headless, colocated box, which, incidentally, would be called a "server".
2) The ability to run Mac OS X and Darwin binaries on NetBSD means that the availability of good commercial software which can runs on NetBSD increases (obviously), plus other bonuses (such as, for instance, Apple's very decent JVM).
3) That NetBSD's ABI emulation (NetBSD emulates the ABI of OS X / Darwin) can run XDarwin is a very good sign of the progress of the work on the ABI emulation.
This just makes the idea of hosting / serving using PowerPC hardware that much more attractive.
This means that there are a couple of crufty stubs that look like the framebuffer and HID drivers.
Replicating the entire IOKit infrastructure would require, well, the entire IOKit infrastructure. Which could be done, since it's all open-sourced, but would be a lot of work.
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 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.
[)amien
Microkernels being slow are the reason Macs are so much slower than PC's!
My PC runs a microkernel OS (Windows 2000), but I didn't notice any slow-downs when I switched from Windows 98.
Not meaning to spur another round of *BSD is dying trolls, but there really does seem to be a huge lack of commercial interest in using *BSD for anything. FreeBSD is used sometimes for high capacity web servers running free open source servers like Apache, but when it comes to commercial software development it's really lacking. Where is the VMware for FreeBSD or NetBSD? Where is StarOffice for FreeBSD? *BSD has no commercial applications and it just seemed to have never taken off. Why does anyone bother to use it anymore?
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.
May we never see th
Even more entertaining, you appear to have been modded "Redundant", so apparently there is an excess of folks calling Slashdot posters "functionally illiterate". :-)
Understand -- most folks (sadly enough, including those on Slashdot) are not particularly technically-minded, aren't interested in learning how things work and aren't interested thinking about anything. They want their questions answered, preferably quickly and by someone else. They certainly don't want to read anything.
May we never see th
Wait wait wait wait... I wait for BSD news? What are you on? What makes you think I wait for any news at all? What if this news just happened to be up when I checked /.? How do you know I don't also read Linux news, Windows news, etc? Stop making acusations about people unless you know they're true.
I don't think you can call it a MicroKernel when your web browser lives in kernel space....
All you fags want to sit around and have a knitting circle with your ultra-gay 'free' excuse for an operating system. Go get a real operating system and just kill yourself...
Die already you dumb fuck!!! Go suck on Linus dick some more you Linux-wanabee...
FreeBSD runs linux binaries faster than linux does
*cough*hack*sputter*wheeze*
Flaven! Dead.
i'm Mr. Coward, you insensitive clod.
I'm not sure many people would want to go to court over it, but even assuming the EULA is legal, I'm not certain it's enforcable even if it's legit and users do have to agree to it (if you plug in an official Apple mouse, does that count as "running it on Apple-branded hardware"?)
You are not alone. This is not normal. None of this is normal.
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, especially if your Mac OS X apps will actually run on NetBSD. Then you can continue to use your existing machine and get new drivers and up-to-date software, even after Apple "Steves" your Mac (EOL's it).
Democracy. Whiskey. Sexy. Pick any two.
Why does it seems like anonymous cowards never get modded up, and only registered users do, regardless of the substance of their posts?
What kind of a half-breed are you?
/. after you recover from the concussion...Asshole...
In what piece-of-crap Apalachian inbreed town do you hail from?
Where do they skim the scum off of septic tanks and mold it into the likes of yourself?
How small is your dick and your brain to find your brand of 'humor' amusing?
How worthless is your existence that spewing insults is your idea of 'fun'?
Go back to taking the bus to Wal-Mart to hang out with the other inbreeds -- better yet, go down to the local swamp, and kill yourself sooner than later...actually, go into whatever nearby small town you call a city, and pull that 'negro' shit with some local 'brothers'...then check back in with all of us here on
You should have saved yourself the typing and just said "I didn't notice you were joking."
>It already runs on generic x86.
Mac OS X does not run on generic x86. I didn't specify, but you knew that's what I was talking about; don't pretend. The people bitching about Apple not porting its OS to x86 aren't going to use a bare Darwin system.
>I don't think Apple has the resource to write drivers for all the x86 hardware and hardware vendor will not do it either as they usually not do it for Linux.
Exactly! That's why I added the (e) troll in with my list...
>I read somewhere (don't remember where) that context switching are a lot more expensive on x86 than PowerPC.
Interesting! But my point was that for the stuff that most people do on the DESKTOP where bleeding-edge performance is required, they're not spending all their time in kernel calls (especially not lots of little ones); they're spending it in user space crunching data. OK, so if you benchmark a microkernel there's probably some overhead, but this is just another example of where geeks freak out about optimizing something unimportant in the larger performance picture.
Example: "god damn all these buffer overflow bugs, but I'll never use anything but C because I need maximum speed." Either you have time to track down all those bugs and write bulletproof code, or you should just move up one level of abstraction and program in an environment that burns some CPU time checking up after you at runtime. The extra time you have left over (from not having to debug all that buffer code that you wrote by hand with pointer arithmetic, because b4r3 m3t4l c0d3rz r00l!!) could be spend in actual performance testing of high-level functions, with a profiler, making high-level optimizations like not opening the same file 10000 times, or not calculating the same result 10000 times, etc. instead of just writing it all in C.
Likewise, unless folks KNOW that the microkernel is a major problem for their use of the OS, they should STFU. It's like bitching that the installer for an application isn't a true 64-bit program. Why doesn't the god damn installer use the SIMD instructions in my CPU? Waaaah!
>Mac OS X will run on non-Mac PowerPC hardware with Mac-on-Linux (because of drivers issues).
Awesome! So I can get the lower price/performance of a PPC processor, AND my hardware won't Just Work, AND I'll get no vendor support! Where do I sign?
> Why? Windows will run Windows apps and is pre-installed.
No shit. But that's one of the tired old gripes about Macs... "but there's all those apps that only run on Windows! I can't switch!" Combine that with an x86 Mac port (another gripe, remember?) and it's clear that the x86 port would have to run win32 apps to make people STFU.
>>(e) use Windows drivers
>Why? Drivers are very OS specific.
Because as you mentioned, if there were an x86 port of Mac OS X, "nobody would write drivers". Of course, they write PPC drivers for Mac OS X, so it's not necessarily true that they wouldn't write them for x86. But again, the "port OS X to x86" folks are thinking of their l33t Opteron PC with all sorts of funky hardware, and chances are that won't all work with an imagined OS X x86 port. So why not cry about that too?
This is tiresome. I can't defend every stupid troll that I posted, because the whole point is that I was just repeating stupid trolls all at once to be even more shrill.
Is it possible then to implemente the cocoa API in a similar way WINE has?
What alot of people are missing is that NetBSD runs on OLDER Mac's, it doesn't drop support for hardware just because its older that X years like Apple does.
So, if you've just become the proud owner of dropped hardware under MacOS X.N+1 you can load in NetBSD as the OS part, load in the MacOS X N+1 software on top of NetBSD and keep using your perfectly good older Mac hardware without the forced hardware upgrade Apple is doing for MacOS X itself.
THAT'S what so big about IOKIT support in NetBSD/ppc. The support of MacOS X software on older hardware that Apple doesn't want to support anymore.
The Price/Performance deficit does not lie
with PPC hardware. It lies with Apple
hardware. The economies of scale that one
might expect with x86 motherboards just don't
exist, really, because the market is so
fragmented -- and the G5 power is hot.
-I like my women like I like my tea: green-
Latest versions of glibc use the GPL with a special exception clause allowing programs to be linked to it without requiring source to be distributed under the GPL. The exception doesn't invalidate any other reason you have would have to use the GPL to distribute your program -- say, if you linked to readline.
All contributors to glibc have to agree to the exception for it to apply. As the FSF does copyright assignment, this isn't a problem.
Also, note that it's possible to get away with linking to readline and not using the GPL if you don't distribute readline. Then, whether or not your program must be under the GPL depends on whether your program is a derived work in the view of copyright law, which is not as strict as the GPL (Question: if you link the Windows kernel to libreadline, must you distribute the source to the Windows kernel because it's then a derived work? If you distribute readline with the kernel, yes, because of clauses in the GPL that require everything distributed to be GPL. If not, not likely, because the functionality of the kernel is mostly orthogonal to what readline does, and most of the functionality was existing previous to the linking.)
Here kitty kitty... bring your kids too. It's COLUMBINE TIME for the BSD trolls!
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 reasons to stay the heck away from it if it's not what you need. But it's still a cool hack, and I'm happy that Emmanuel is working on it.
Agreed. In any case, there's nothing particularly "micro" about Mach. It is huge.
Lama asita oti FOE? Ata tembel!
hemi
That's got to be the most misleading thing I've ever seen about Internet Explorer, and that includes the pro-microsoft garbage I've read.
Congratulations.
The trolls they are a-posting
it makes me feel sick
to see a grown person
act like such a dick
Wow! a tourettes syndrome filter. Where can I get one?
Lucky for you then huh? must be the only thing you can get to give you a blow-job down there in mom's basement.
inimicus fiebas ob ista mendacia quae tu vulgavisti de anthropomorphicis. nisi (sciliet) iocavisti.
--bersl2
Think Ranting Zealot.
You forgot to take your lithium today didn't you? The fact that Linux and NetBSD currently, or may one day be able to run OS X binaries isn't a threat.
No one is suggesting that YOU have to do anything, just bear in mind that these efforts may save your Mac one day when Apple decide it's not current enough to support.
Just because this isn't your cup of tea doesn't grant you a right to criticize how NetBSD/PPC developers spend their time. Maybe they just want to run photoshop on their Apple manufactured NetBSD box.
Here're the numbers I get (under Panther): /usr/bin/* 2>/dev/null |grep FreeBSD|wc -l /usr/bin/* 2>/dev/null |grep OpenBSD|wc -l /usr/bin/* 2>/dev/null |grep NetBSD|wc -l
PigsInSpace:~ brandon$ ident
191
PigsInSpace:~ brandon$ ident
203
PigsInSpace:~ brandon$ ident
118
PigsInSpace:~ brandon$
So, unlike your numbers (perhaps old--from jaguar) OpenBSD is barely first, FreeBSD just behind it, and NetBSD, far last.
My previous comment was in Hebrew. Aren't you supposed to know that language?
hemi
I spent many years at Sunday and Hebrew schools, and I prepared for my bar mitzvah; but you know what? I could never figure that language out.
BTW: 'Tis very silly why you are foed. You recently displayed a less-than-positive attitude (via a subject and link) towards a certain subculture, implying that all members of that subculture are sex fiends. You might have been joking, but you might not have. So, were you?
If you still can't understand: look at our recent posting histories, and compare.
Are you talking about this thing in the AWOL Surak's journal? I didn't imply they are sex fiends. But I do believe that the comic shows the lack of logic in furries. I don't like the idea of those hybrids. Talking animals are fine and humans are fine, but half-animals? It is gross and hairy!
And it's a pity you don't know Hebrew..
hemi
Heh. It's not *microkernels* that are the problem. It's specifically the Mach microkernel upon which Dawrin is based.
It would have been a lot of fun to see Apple use the l4 microkernel instead of the academically uninteresting and performance-poor Mach-based kernel now used.