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?
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).
MacOS X as in Xcept the future
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/
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).
dude that is so not the point. Find out if you can run ppc code on x86 without emulation. Please im dying to find out. geez people on slashdot are getting dumber as more noobs flood in ..
The war with islam is a war on the beast
The war on terror is a war for peace
Erm, no. This is for NetBSD PPC. With rare exception, that means on mac hardware. There are exceptions though...IBM released some rather nice PPC970 hardware recently in 1U form factor....look here.
;)
If that works, then it would be of MARGINAL interest to me. Okay, I admit. More than that.
Karma: Chameleon (mostly due to the fact that you come and go).
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
That makes absolutely no sense. Buying a copy of OS X is going to give you a CD full of code compiled for PowerPC, with no way to make any use of it on Intel sort of emulation. Darwin itself already runs on x86 hardware, so clearly the kernel is not the stumbling block.
The goal is to run MacOS X's programs on NetBSD/powerpc. One of the problems is that thoses programs do not use X11, they use quartz.
We have no free software display server for Quartz. Emmanuel Dreyfus had three options to get the job done:
1) Write a Quartz display server
2) Write a Quartz to X11 bridge
3) Emulate enough of MacOS X to get MacOS X's Quartz display server to run on NetBSD.
He chose option 3. It is not an easy job since MacOS X I/O are done through the IOKit, which completely differs from UNIX I/O API.
XDarwin is the X11 server for MacOS X. It uses the IOKit to access the display, keyboard and mouse. Having XDarwin fully fonctionnal on NetBSD means that NetBSD IOKit emulation is in good shape. It is the first step on the right direction.
Next step is to run MacOS X's Quartz display server itself.
Knock yourself out, but I can tell you right now that it won't be nearly as impressive as it sounds. X86 cpus really look bad when they try to emulate PPC/SPARC/Alpha and the like. You'll be a hell of a lot better off just buying a PPC box.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
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
Ah, okay. I couldn't verify it because the article the story references is gone now.
If those boxes exist or will be released then I'd be interested.
Karma: Chameleon (mostly due to the fact that you come and go).
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.
Why would you want to X and one of its clumsy window managers instead of Aqua, the best user interface around?
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.)
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
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!
> These are serious questions. Who actually uses NetBSD? Why?
/usr/bin/* 2>/dev/null |grep NetBSD|wc -l /usr/bin/* 2>/dev/null |grep FreeBSD|wc -l /usr/bin/* 2>/dev/null |grep OpenBSD|wc -l
NetBSD is a stable, reliable, free, well-written, and administrator-friendly UNIX system. There are many reasons for running it.
> FreeBSD is stable and great as a Linux alternative.
So is NetBSD.
> OpenBSD is known for security.
This is what OpenBSD marketing claim, not the reality. OpenBSD web page claims one security hole in the default install for 7 years. They forget about 2 OpenSSH server bugs, one OpenSSH client bug, and 2 DNS client bugs. And anyway nobody uses an OS in its default install. Forget to apply the numerous OpenBSD patches and your system will be hcaked.
> NetBSD is multi-platform.
And as good for security as OpenBSD, and as good as a Linux alternative as FreeBSD is.
> So? Why would anyone want to use it? What has it really contributed to BSD? What has it really contributed to computing?
Many things actually. For instance, Apple claims that Darwin is based on FreeBSD. This is just untrue: they picked up the best known name in the FreeBSD world. Just peek at where the sources actually come from:
sh-2.05a$ ident
242
sh-2.05a$ ident
99
sh-2.05a$ ident
218
sh-2.05a$ uname -a
Darwin vip 6.8 Darwin Kernel Version 6.8: Wed Sep 10 15:20:55 PDT 2003; root:xnu/xnu-344.49.obj~2/RELEASE_PPC Power Macintosh powerpc
While there may be a lot of x86 boxes out there, the PPC is a decent chip installed in quite a few boxes, other than Apple boxen. Getting a solid OS (NetBSD) with widespread compatibility (across various areas) may spur on take-up of the PPC platform. It's not going to appeal to all x86 users but there are likely some who would want to switch to PPC.
panther:~ $ ident /usr/bin/* 2>/dev/null |grep NetBSD|wc -l /usr/bin/* 2>/dev/null |grep FreeBSD|wc -l /usr/bin/* 2>/dev/null |grep OpenBSD|wc -l
118
panther:~ $ ident
191
panther:~ $ ident
203
panther:~ $ uname -a
Darwin xynasha.local 7.0.0 Darwin Kernel Version 7.0.0: Wed Sep 24 15:48:39 PDT 2003; root:xnu/xnu-517.obj~1/RELEASE_PPC Power Macintosh powerpc
Its by the far the most easiest BSD to use and has alot of example files and scripts to hack with.
http://saveie6.com/
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.
I would like Carbon support the most, however I'm not sure how to implement FSRefs on other filesystems.
/etc/FileIDSs file which associated FileIDs with paths (which was less than ideal for a lot of reasons).
I don't know how Apple even does it. AUX did it by maintaining a
>80 column hard wrapped e-mail is not a sign of intelligent
>life
Because idiots out there feel that mixed case, spaces and tons of characters in the middle of filenames are somehow acceptable. now if you'd said darwin_compat that might be bet... oh wait a min...
Seriously, try typing your name and then compat_darwin 2000 times.
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
% ident -q /usr/bin/* | grep NetBSD | wc -l
120
% ident -q /usr/bin/* | grep FreeBSD | wc -l
191
% ident -q /usr/bin/* | grep OpenBSD | wc -l
203
% uname -a
Darwin ibook 7.0.0 Darwin Kernel Version 7.0.0: Wed Sep 24 15:48:39 PDT 2003; root:xnu/xnu-517.obj~1/RELEASE_PPC Power Macintosh powerpc
But yes, your point that Apple used code from a variety of BSDs is still correct.
The XNU kernel at the core of Darwin/Mac OS X actually ran on x86 long before it ever ran on PPC.
The PPC port only began after NeXT was absorbed into Apple, soon after which point Apple cancelled support for the other hardware platforms that OPENSTEP ran on.
One of the reasons progressive releases of OS X have been getting faster is that Apple is still optimizing the kernel and core frameworks for the PPC architecture.
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.
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
"COMPAT_DARWIN?" Was "Darwin Compatibility" something or other too ungeeky
It's a dark day on "News for Nerds".
May we never see th
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?
You know, you could make a better "shouldn't use it" argument about the systems you listed as vital above. I'd rather use Linux for any of the above things (secure system, stable system, desktop system), but while Linux runs on many, many devices, NetBSD still runs on systems that Linux can't. So if I needed a free *IX fix on some systems, I'd need to use NetBSD.
May we never see th
Personally, I don't use NetBSD much, but it's great on old 32-bit Sparc boxen. The Linux MMU code really sucks on this platform, and they feel much faster running NetBSD. A friend of mine uses a SparcStation 2 running NetBSD as a dumb X terminal, and it's very responsive. The same machine running Linux was quite painful. He's now decided to put NetBSD on his x86 laptop, since it will mean that he can use exactly the same OS on both machines.
I am TheRaven on Soylent News
I don't think you can call it a MicroKernel when your web browser lives in kernel space....
It's probably worth forking GNUStep and creating a version that isn't so ideologically sound (GNUStep implements an older version of OpenStep which makes people coding for both have to do things like implement menus in a different shape, et al. GNUStep also refuses on general principle to work with .nibs because the file format isn't officially documented.) Something like this would run a significant number of Mac OS X apps without having to anything on the programmer's part but select a different target architecture. Interestingly, it would also end up being sufficiently different to OS X that Apple would be unlikely to object - GNUStep runs over X11, for example.
You are not alone. This is not normal. None of this is normal.
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.
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.
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-
furthermore, why would I want to go to a platform that is filled with nasty ugly hardware kludges when I can use PPC platform? I prever Apple's easy access case, single handle openining, the design of the hardware I love.
I moved away form x86 not only because of Windows, but because of the cable mess of the cases..
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.
Wtf? TenCept the future? What does that mean?
Lama asita oti FOE? Ata tembel!
hemi
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?
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.
Huh? As I understood the LGPL, it was the same as the GPL, but allowing linking. So you can't redistribute a binary-only glibc, but you can link your app to it and distribute that. So what's the difference between the LGPL and the GPL with a linking exception?
It seems to me that dynamic linking versus static linking should be important. If I dynamically link with glibc, and distribute my app, then YOU have to provide the actual glibc shared libraries for the app to run--and therefore it's your responsibility to have a license to glibc (by being provided / willing to provide the source).
Same thing with Linux. Everyone agrees that writing an app which uses Linux system calls is not creating a derivative work. But writing a prepackaged all-in-one system/application which DOESN'T require you to have Linux installed would be a violation.
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.