Telling the world your battleplan in advance makes as much sense as writing "the root password is XXXXX" on the door of the can.
The SAS gave the Mujahedin a lot of in-the-field training in the 1980's. The Soviets never learned; if you read Tom Clancy's non-fiction work "Into The Storm", co-written with Gen. Fred Franks, the US Army sometimes does learn.
A list of names of people to kill is being made; a strategy for checking the boxes next to those names is being devised by people who recognise those people qualified to offer advice, and heed them. Afghanistan has its own civil war already in progress; perhaps it just needs to be run through the Ft Bragg optimiser.
Why was it necessary to murder so many people? Hideki Tojo's insult killed a third as many, and they were mostly US servicemen at a military base, not men and women and children at desks. Hideki Tojo's insult was answered with atomic weapons, and it was Tojo's insult that pushed the US into war, and the atomic-weapon building 9and inventing) business.
Osama: If you say you weren't responsible, we don't believe you. We think of ourselves as decent upright and honorable people; if you can show it wasn't you, we will acknowledge this, amd the world's attention will focus elsewhere, away from you. Have you any idea what you started?
I have my own views on 'Nam. The US involvement was justified, in ways that French colonial involvement was not; it was the way the US armed forces conducted that war that was at fault. How many 2nd Lieutenants during the Somalia affair are now Majors in staff appointments?
...as in, some Royal Navy frigates were tasked to Persian Gulf air defence in 1990-1, and they have this bi-static radar (Type 909? don't quote me on that) for firecontrol of a SAM (Sea Dart? don't quote me on that either) and it was supposedly quite routine for persons in the Command Centre to report "oh look there go another four of those aeroplanes we're not supposed to be able to see; course this, speed that, altitude the other".
It's more than not reflecting back at the transmitter because that's where you expect the receiver to be; suppose someone put enough computer on the signal received and start edanalysing the transient anomalies?
Stealthy works, and is expensive but cost-effective. Full-stealth is horribly expensive and not significantly more effective than stealthy.
You hear the sound of the National Missile Defense lobby magically grinding their axe, and chanting "don't waste tax dollars on useful affordable workable stealth programs like Joint Strike Fighter"
It is likely that Terminal.app, which provides csh or similar in a window for those that want, will not be part of the MacOSX default install.
So, either installing it as an optional package is the first sensible thing you do, or you install the third-party replacement package instead. There will be a third-party replacement package if required; Slashdotters will find life of MacOSX without csh or similar just too horrible to contemplate.
You then build whatever your product is natively on MacOSX. 4.4bsd under the hood, right?
You then write an AppKit (ie, Cocoa) graphical app that works it. IPC is strong in many forms, and the AppKit is way cool (and has a strong future -- find out with what Apple are writing their MacOSX development tools with).
I have such apps that I have written already working on MacOSX Server. It's not a big deal; working the NSTask object is easier than working fork() and execve().
My employer, whom I shall not identify, is a reseller. We were once asked to quote on a set of big Sun systems for hosting big Sybase databases, as part of a bidding competition run by a vendor on behalf of the customer. My MD, being the sort of guy he is, read the spec, reverse-engineered the *actual* customer requirement, wrote a new spec, and submitted it with a quote. Significant features of the new spec: 60% less cost to the customer; substantially more functionality; higher margins for us.
Presently, the bidding competition was restarted by the vendor, with a spec remarkably like the one my MD had written, but priced with substantially lower margins.
Conclude: [1] Sun can be even worse than Apple at shafting their strategic partners. [2] Take your spec and the quote you got given to someone who actually knows what they're doing.
I think the new Aqua interface is, frankly, tits on a bull. I mean, besides looking pretty, what does it *do*?
When MacOSX Server came along, the MacOS people bitched because they didn't think BlueBox.app was enough. And they were probably right, and Carbon got invented.
So now those of us from the OPENSTEP community who just want Apple to keep shipping some of the existing code are being invited to take it up the ass? The WebObjects stuff is at present unspeakably cool -- and Apple plan to make it pure-Java, which makes it substantially less cool. This also means they're going to trash some of the other supporting code -- EOF in particular. I like the existing EOF, implemented in ObjectiveC, because when I find bugs, I report them and then in many cases I can patch them in the existing software using "categories" or subclassing or "posing"; my ability to do that with Java is reduced by about two orders of magnitude.
Apple seem to be doing their damnedest to make sure no-one can ship anything that isn't either pure-Java or a Carbonized existing MacOS app. Follow the link to Stepwise; Apple have even crippled the Installer application for God's sake!
We want to know how stable your chosen platform is!
OK. So "Sealand" is the former Roughs Tower naval fort off the Essex coast. This structure was erected in 1942 (and hey, let's slashdot someone: picture of this at http://freespace.virgin.net/line.design/forts/sea_forts.htm) and was not intended to be permanent. Tongue Sands Tower, a similar structure recently broke up and partially sank.
Sealand is a Maunsell Naval fort, formerly known as Roughs Tower, off Harwich on the Essex coast. Information about these should be more prevalent elsewhere.
You should pay particular importance to the facts that they were built in WWII, are entirely free-standing, and were not intended to be permanent.
I would judge them to be a most inhospitable location for a server farm; and suppose the weather was bad, there were big sea states, and it was not possible to make the dieso delivery for fuelling the generators that would be needed to power both the servers and the satellite transceivers?
There is also the matter of Tongue Sands Tower, an identical structure off the North Kent coast which broke up and sank about ten years ago. I really wouldn't want to even put my foot on one to lay cat5.
Look on the bright side: this data-haven would be over 20 miles from the UK's most dangerous wreck, the Liberty ship SS Richard Montgomery, which sank in 1944 with a cargo of 4000 tons of explosives, only half of which were salved.
Well, mostly I shall stick to reading the comments in the header files of the OPENSTEP, MacOSX-S, and MacOSX developer machines on or near my desk. You'll forgive me if I don't post URLs.
It is my understanding that MacOSX and Darwin *are* distinct, but that it intended that common areas are intended to converge. That might explain why Fred Sanchez was so keen on getting a bootable Darwin/Intel OS built, while MacOSX/Intel is already a discontinued project. It would also explain what is on the websites and in Fred's diary and what evidence is to be had from the CVS repositories.
If on the other hand I am completely wrong and someone out there working on Darwin is familiar enough with the relevant bit of code, could you identify why it is that I have to boot my G4 into MacOS 8.6 to set the screen resolution, and fix it? Doing it in MacOS.app or Preferences.app doesn't work, and developing on MacOSXS as 1024x768 or less isn't funny.
To recap: the underlying MacOSX operating system is Mach 4.4, which is bsd based, and (believe it or not) does *not* use the Mach microkernel. Ask Avie Tevanian if you have to. Mach ideas, microkernel ideas, but not the Mach microkernel.
This operating system has clever copy-on-write VM features and other things that mean that on some tasks it is severely performant.
The Darwin project is distinct from MacOSX.
To the best of my knowledge, Apple have never had any plans to ship their "tools", whatever they may be, on any but a few platforms -- MacOSX, and Win32 with some compatibility stuff running. The Win32 products appear now to be destined to become only a development platform for WebObjects. WebObjects deployment code, as distinct from the WebObjects or MacOSX developer tools, appears to be going highly-crossplatform with the pre-announcement of a pure-Java-only WebObjects5; but this has nothing to do with MacOSX.
Apple appears to remain committed to opensource development of Darwin, and the bsd-layer CLI stuff which will be common to MacOSX will presumably be opensource and kernel-independent.
Terminal.app will almost certainly ship with MacOSX; but probably as an optional administration package. Apple remains committed to a MacOSX in which the user need never see a command line unless they want to.
Yup, bsd, despite all the POSIX support that Wilfredo Sanchez has been building in.
IE5/MacOSX will be/is a Carbon app. As others have mentioned, this is a technology added by Apple so that people with existing MacOS projects can protect their investment by porting to the environment with "less than ten percent" change required to the codebase.
There are other, more exciting rumours about a version of Office being built on the (new, exciting, NEXTSTEP-derived) Cocoa APIs. This is only a wild rumour, which I personally do not believe, but either way, as with the Carbonised IE5, it would be only an infinitesimally small step on the way towards having it up and running on any sort of *nix other than MacOSX.
Bang on. It appears to be exactly the same license agreement as used with C++Builder when given away about once a month with PCPlus in the UK. I don't see how the license terms are enforceable; AFAIK the dev tools are not crippled (like the trainer edition of Visual Basic that ships with most learn-yourself-VB book+CD packages was/is). And AFAIK this license does not apply to BC++ 5.5; so if really pushed, develop with C++Builder, then compile your release candidate from clean using BC++ 5.5!
... where I hung out, there were these nice shiny new m68k Sun whelkstations -- someone lusted after the then new 386-based Roadrunners, but we'll forget him -- and there was a persistent rumour that one amongst us, his identity a dark secret, could hack his way to root status in under 90sec starting from % in a vanilla account.
It is also true that among us was one Alan Cox, an Amiga aficionado, who liked its OS, and used to do stuff to it so he could make the sound ASICs perform, as he put it, "chickens in minor sevenths". And Amigas were m68k-based.
I suspect that having the source code to look at, commented or not, is not enough for most of us, and having a fat commentary to advise us what we should be looking at, and whereabouts, will be a great boon to newbie kernelistas.
After all, I was an Atari ST aficionado, and they were m68k based, yet I never quite managed to perform an illegal su. The likes of Cox seem to be special, but let's not let that stop us from aspiring to bug-free kernels of our very own.
Presumably the BSD layer will allow BSD-compatible applications (apache, etc.) to compile and run
Yes. See previous remarks about Wilfredo Sanchez -- his definable goal is to give OSX the fastest out-of-the-box Apache on God's earth
and the Mac OS emulation layer similar capabilities for Mac OS software
It has been noticed that Classic apps run faster on MacOSX than on trad MacOS, if they run at all; and, as per Apple's docs, it's not an emulation layer, it's something else that does exactly the same thing. Go figure.
not embracing the new OS X-native libraries
The Carbon technology allows you to continue using your existing codebase with minimal changes. Migrating Classic->Carbon is easy for apps that don't need to bypass the OS
Nice rad environment; native Win32 code generation; pluggable VMs, with some support for Java2.
Market realities being what they are, anybody on a non-windoze platform wanting to use your product can probably figure out how to get the required Java2 support themself...
Major downsides? proprietary product; native code (if you use it) defeats dynamic bytecode loading -- so none of the infinite extensibility Sun promised with Java and NeXT^H^H^H^HApple delivered with their Objective-C based technologies.
And of course, all the other downers associated with developing in Java.
"Because the Sorensen codec has the best file size::picture quality ratio"
False. I'm an advocate of QuickTime; check my website to prove it. I also trawl certain USENET newsgroups, where Intel AVI i261 is the codec of choice, as it appears to outperform Sorenson2.
BSD X11 QT player already inside Apple? Forget it. If you're used to the AppKit (OSX and forerunners) or MFC, or whatever the default GUI library is for trad MacOS, x11 et al are *hateful*. The BSD QT player is called MoviePlayer.app, and it is an AppKit-based app.
Apple will not be opensourcing Sorenson2 etc as they don't own them. People like Sorenson do.
Software written for OS X's Cocoa API (read: Apple's updated version of the NeXT API) can be compiled as Java bytecode. The possibilities should be obvious. Of course, you probably wouldn't want to do this with games or graphics software, but for 90% of apps it would be just fine.
False. As someone using those APIs, there is tricky object morphing going on. Without the real native code libraries (mostly written in ObjC) underneath, there will be no dice with Java. If you write Java Cocoa apps, they'll still run only on platforms with full native Cocoa libraries. And, as someone using Java Cocoa apps on MacOSXServer, I have mixed feelings about their observed performance.
OpenStep ran on: NeXT's m68k; Intel; and 32bit Sparc. NeXTSTEP 3.3 ran on HP-PA Risc as well. And early PPC; but that never shipped. MacOS as people know it is not part of Darwin. Darwin is a full-featured BSD-based operating system which will eventually become one and the same as the BSD layer in MacOSX. MacOSX (PPC), in its current incarnations (and presumably its future ones will run most legacy MacOS PPC applications. There would be no support for such legacy ("Classic") or legacy-lite ("Carbon") applications in a version of Darwin not running on Apple PPC hardware; only for MacOSX apps based on the "Cocoa" technology acquired from NeXT. Some MacOSX technologies -- those not requiring a GUI -- run on other platforms such as Solaris and HPUX. This includes WebObjects (deployment), which is/should be/ought to be a major cash cow for Apple. I suspect the existence of non-PPC Darwin is to improve support for WebObjects on platforms other than Apple PPC, other platforms far more suited to life in server farms. Like maybe an Ultrasparc with hot-swappable 256-way redundancy in PSUs, CPUs, memory interface cards etc, complete with EMP protection and a neutronium-armoured casing.
I read about this. The man had a solid alibi; Parkinson's disease or some such, and since he couldn't dress unaided, could barely stand unaided, I doubt I as a juror would have convicted. But, the local police force -- not necessarily the brightest people on the planet -- were determined to prosecute anyway. That the six common loci test matched is a surprise; that the ten loci test did not match is not a surprise. We should all be on our guard for fatheads who don't understand what their scientists tell them, and for people who cannot understand that a tiny bit of cross contamination does matter when performing polymerase chain reactions.
Once upon a time, agriculture was a serious business. Growing crops was easier with fertilizer; manure, or something made from manure, preferably bird manure. Once things like the Haber process came on line -- speeded up by the Kaiser's need for explosives, I will concede -- ammonia and thus nitrates could be made industrially from air, and nowadays crop failures are a minor nuisance (to industrialised societies, at least) rather than a disaster.
Given that naval nuclear power is a means to threaten other nation states more effectively compared to the means you would otherwise have spent your naval nuclear budget on instead, I'm inclined to disagree. Rickover's Nuclear Navy did -- and I gather largely still does -- have some severe defects. See Tom Clancy's essay "Getting Our Money's Worth" in The Tom Clancy Companion. Rickover's unit commanders were skilled nuclear engineers -- but that was the Chief Engineer's job, the commanders should have been warriors, as is traditional.
Slashdot Mirror
Telling the world your battleplan in advance makes as much sense as writing "the root password is XXXXX" on the door of the can.
The SAS gave the Mujahedin a lot of in-the-field training in the 1980's. The Soviets never learned; if you read Tom Clancy's non-fiction work "Into The Storm", co-written with Gen. Fred Franks, the US Army sometimes does learn.
A list of names of people to kill is being made; a strategy for checking the boxes next to those names is being devised by people who recognise those people qualified to offer advice, and heed them. Afghanistan has its own civil war already in progress; perhaps it just needs to be run through the Ft Bragg optimiser.
Why was it necessary to murder so many people? Hideki Tojo's insult killed a third as many, and they were mostly US servicemen at a military base, not men and women and children at desks. Hideki Tojo's insult was answered with atomic weapons, and it was Tojo's insult that pushed the US into war, and the atomic-weapon building 9and inventing) business.
Osama: If you say you weren't responsible, we don't believe you. We think of ourselves as decent upright and honorable people; if you can show it wasn't you, we will acknowledge this, amd the world's attention will focus elsewhere, away from you. Have you any idea what you started?
I have my own views on 'Nam. The US involvement was justified, in ways that French colonial involvement was not; it was the way the US armed forces conducted that war that was at fault. How many 2nd Lieutenants during the Somalia affair are now Majors in staff appointments?
It's more than not reflecting back at the transmitter because that's where you expect the receiver to be; suppose someone put enough computer on the signal received and start edanalysing the transient anomalies?
Stealthy works, and is expensive but cost-effective. Full-stealth is horribly expensive and not significantly more effective than stealthy.
You hear the sound of the National Missile Defense lobby magically grinding their axe, and chanting "don't waste tax dollars on useful affordable workable stealth programs like Joint Strike Fighter"
It is likely that Terminal.app, which provides csh or similar in a window for those that want, will not be part of the MacOSX default install.
So, either installing it as an optional package is the first sensible thing you do, or you install the third-party replacement package instead. There will be a third-party replacement package if required; Slashdotters will find life of MacOSX without csh or similar just too horrible to contemplate.
You then build whatever your product is natively on MacOSX. 4.4bsd under the hood, right?
You then write an AppKit (ie, Cocoa) graphical app that works it. IPC is strong in many forms, and the AppKit is way cool (and has a strong future -- find out with what Apple are writing their MacOSX development tools with).
I have such apps that I have written already working on MacOSX Server. It's not a big deal; working the NSTask object is easier than working fork() and execve().
My employer, whom I shall not identify, is a reseller. We were once asked to quote on a set of big Sun systems for hosting big Sybase databases, as part of a bidding competition run by a vendor on behalf of the customer. My MD, being the sort of guy he is, read the spec, reverse-engineered the *actual* customer requirement, wrote a new spec, and submitted it with a quote. Significant features of the new spec: 60% less cost to the customer; substantially more functionality; higher margins for us.
Presently, the bidding competition was restarted by the vendor, with a spec remarkably like the one my MD had written, but priced with substantially lower margins.
Conclude: [1] Sun can be even worse than Apple at shafting their strategic partners. [2] Take your spec and the quote you got given to someone who actually knows what they're doing.
I was never much impressed with the old MacOS.
I think the new Aqua interface is, frankly, tits on a bull. I mean, besides looking pretty, what does it *do*?
When MacOSX Server came along, the MacOS people bitched because they didn't think BlueBox.app was enough. And they were probably right, and Carbon got invented.
So now those of us from the OPENSTEP community who just want Apple to keep shipping some of the existing code are being invited to take it up the ass? The WebObjects stuff is at present unspeakably cool -- and Apple plan to make it pure-Java, which makes it substantially less cool. This also means they're going to trash some of the other supporting code -- EOF in particular. I like the existing EOF, implemented in ObjectiveC, because when I find bugs, I report them and then in many cases I can patch them in the existing software using "categories" or subclassing or "posing"; my ability to do that with Java is reduced by about two orders of magnitude.
Apple seem to be doing their damnedest to make sure no-one can ship anything that isn't either pure-Java or a Carbonized existing MacOS app. Follow the link to Stepwise; Apple have even crippled the Installer application for God's sake!
We want to know how stable your chosen platform is!
OK. So "Sealand" is the former Roughs Tower naval fort off the Essex coast. This structure was erected in 1942 (and hey, let's slashdot someone: picture of this at http://freespace.virgin .net/line.design/forts/sea_forts.htm) and was not intended to be permanent. Tongue Sands Tower, a similar structure recently broke up and partially sank.
Sealand is a Maunsell Naval fort, formerly known as Roughs Tower, off Harwich on the Essex coast. Information about these should be more prevalent elsewhere.
You should pay particular importance to the facts that they were built in WWII, are entirely free-standing, and were not intended to be permanent.
I would judge them to be a most inhospitable location for a server farm; and suppose the weather was bad, there were big sea states, and it was not possible to make the dieso delivery for fuelling the generators that would be needed to power both the servers and the satellite transceivers?
There is also the matter of Tongue Sands Tower, an identical structure off the North Kent coast which broke up and sank about ten years ago. I really wouldn't want to even put my foot on one to lay cat5.
Look on the bright side: this data-haven would be over 20 miles from the UK's most dangerous wreck, the Liberty ship SS Richard Montgomery, which sank in 1944 with a cargo of 4000 tons of explosives, only half of which were salved.
ironduke-particle is an Essex nationalist
Yup. A typo that got past me, despite my use of the preview feature. Naturally I meant "Mach3.0, and 4.4bsd"
Well, mostly I shall stick to reading the comments in the header files of the OPENSTEP, MacOSX-S, and MacOSX developer machines on or near my desk. You'll forgive me if I don't post URLs.
It is my understanding that MacOSX and Darwin *are* distinct, but that it intended that common areas are intended to converge. That might explain why Fred Sanchez was so keen on getting a bootable Darwin/Intel OS built, while MacOSX/Intel is already a discontinued project. It would also explain what is on the websites and in Fred's diary and what evidence is to be had from the CVS repositories.
If on the other hand I am completely wrong and someone out there working on Darwin is familiar enough with the relevant bit of code, could you identify why it is that I have to boot my G4 into MacOS 8.6 to set the screen resolution, and fix it? Doing it in MacOS.app or Preferences.app doesn't work, and developing on MacOSXS as 1024x768 or less isn't funny.
To recap: the underlying MacOSX operating system is Mach 4.4, which is bsd based, and (believe it or not) does *not* use the Mach microkernel. Ask Avie Tevanian if you have to. Mach ideas, microkernel ideas, but not the Mach microkernel.
This operating system has clever copy-on-write VM features and other things that mean that on some tasks it is severely performant.
The Darwin project is distinct from MacOSX.
To the best of my knowledge, Apple have never had any plans to ship their "tools", whatever they may be, on any but a few platforms -- MacOSX, and Win32 with some compatibility stuff running. The Win32 products appear now to be destined to become only a development platform for WebObjects. WebObjects deployment code, as distinct from the WebObjects or MacOSX developer tools, appears to be going highly-crossplatform with the pre-announcement of a pure-Java-only WebObjects5; but this has nothing to do with MacOSX.
Apple appears to remain committed to opensource development of Darwin, and the bsd-layer CLI stuff which will be common to MacOSX will presumably be opensource and kernel-independent.
Terminal.app will almost certainly ship with MacOSX; but probably as an optional administration package. Apple remains committed to a MacOSX in which the user need never see a command line unless they want to.
Yup, bsd, despite all the POSIX support that Wilfredo Sanchez has been building in.
IE5/MacOSX will be/is a Carbon app. As others have mentioned, this is a technology added by Apple so that people with existing MacOS projects can protect their investment by porting to the environment with "less than ten percent" change required to the codebase.
There are other, more exciting rumours about a version of Office being built on the (new, exciting, NEXTSTEP-derived) Cocoa APIs. This is only a wild rumour, which I personally do not believe, but either way, as with the Carbonised IE5, it would be only an infinitesimally small step on the way towards having it up and running on any sort of *nix other than MacOSX.
Bang on. It appears to be exactly the same license agreement as used with C++Builder when given away about once a month with PCPlus in the UK. I don't see how the license terms are enforceable; AFAIK the dev tools are not crippled (like the trainer edition of Visual Basic that ships with most learn-yourself-VB book+CD packages was/is). And AFAIK this license does not apply to BC++ 5.5; so if really pushed, develop with C++Builder, then compile your release candidate from clean using BC++ 5.5!
... where I hung out, there were these nice shiny new m68k Sun whelkstations -- someone lusted after the then new 386-based Roadrunners, but we'll forget him -- and there was a persistent rumour that one amongst us, his identity a dark secret, could hack his way to root status in under 90sec starting from % in a vanilla account.
It is also true that among us was one Alan Cox, an Amiga aficionado, who liked its OS, and used to do stuff to it so he could make the sound ASICs perform, as he put it, "chickens in minor sevenths". And Amigas were m68k-based.
I suspect that having the source code to look at, commented or not, is not enough for most of us, and having a fat commentary to advise us what we should be looking at, and whereabouts, will be a great boon to newbie kernelistas.
After all, I was an Atari ST aficionado, and they were m68k based, yet I never quite managed to perform an illegal su. The likes of Cox seem to be special, but let's not let that stop us from aspiring to bug-free kernels of our very own.
Presumably the BSD layer will allow BSD-compatible applications (apache, etc.) to compile and run
Yes. See previous remarks about Wilfredo Sanchez -- his definable goal is to give OSX the fastest out-of-the-box Apache on God's earth
and the Mac OS emulation layer similar capabilities for Mac OS software
It has been noticed that Classic apps run faster on MacOSX than on trad MacOS, if they run at all; and, as per Apple's docs, it's not an emulation layer, it's something else that does exactly the same thing. Go figure.
not embracing the new OS X-native libraries
The Carbon technology allows you to continue using your existing codebase with minimal changes. Migrating Classic->Carbon is easy for apps that don't need to bypass the OS
Nice rad environment; native Win32 code generation; pluggable VMs, with some support for Java2.
Market realities being what they are, anybody on a non-windoze platform wanting to use your product can probably figure out how to get the required Java2 support themself...
Major downsides? proprietary product; native code (if you use it) defeats dynamic bytecode loading -- so none of the infinite extensibility Sun promised with Java and NeXT^H^H^H^HApple delivered with their Objective-C based technologies.
And of course, all the other downers associated with developing in Java.
"Because the Sorensen codec has the best file size::picture quality ratio"
False. I'm an advocate of QuickTime; check my website to prove it. I also trawl certain USENET newsgroups, where Intel AVI i261 is the codec of choice, as it appears to outperform Sorenson2.
BSD X11 QT player already inside Apple? Forget it. If you're used to the AppKit (OSX and forerunners) or MFC, or whatever the default GUI library is for trad MacOS, x11 et al are *hateful*. The BSD QT player is called MoviePlayer.app, and it is an AppKit-based app.
Apple will not be opensourcing Sorenson2 etc as they don't own them. People like Sorenson do.
False. As someone using those APIs, there is tricky object morphing going on. Without the real native code libraries (mostly written in ObjC) underneath, there will be no dice with Java. If you write Java Cocoa apps, they'll still run only on platforms with full native Cocoa libraries. And, as someone using Java Cocoa apps on MacOSXServer, I have mixed feelings about their observed performance.
OpenStep ran on: NeXT's m68k; Intel; and 32bit Sparc. NeXTSTEP 3.3 ran on HP-PA Risc as well. And early PPC; but that never shipped. MacOS as people know it is not part of Darwin. Darwin is a full-featured BSD-based operating system which will eventually become one and the same as the BSD layer in MacOSX. MacOSX (PPC), in its current incarnations (and presumably its future ones will run most legacy MacOS PPC applications. There would be no support for such legacy ("Classic") or legacy-lite ("Carbon") applications in a version of Darwin not running on Apple PPC hardware; only for MacOSX apps based on the "Cocoa" technology acquired from NeXT. Some MacOSX technologies -- those not requiring a GUI -- run on other platforms such as Solaris and HPUX. This includes WebObjects (deployment), which is/should be/ought to be a major cash cow for Apple. I suspect the existence of non-PPC Darwin is to improve support for WebObjects on platforms other than Apple PPC, other platforms far more suited to life in server farms. Like maybe an Ultrasparc with hot-swappable 256-way redundancy in PSUs, CPUs, memory interface cards etc, complete with EMP protection and a neutronium-armoured casing.
I read about this. The man had a solid alibi; Parkinson's disease or some such, and since he couldn't dress unaided, could barely stand unaided, I doubt I as a juror would have convicted. But, the local police force -- not necessarily the brightest people on the planet -- were determined to prosecute anyway. That the six common loci test matched is a surprise; that the ten loci test did not match is not a surprise. We should all be on our guard for fatheads who don't understand what their scientists tell them, and for people who cannot understand that a tiny bit of cross contamination does matter when performing polymerase chain reactions.
Once upon a time, agriculture was a serious business. Growing crops was easier with fertilizer; manure, or something made from manure, preferably bird manure. Once things like the Haber process came on line -- speeded up by the Kaiser's need for explosives, I will concede -- ammonia and thus nitrates could be made industrially from air, and nowadays crop failures are a minor nuisance (to industrialised societies, at least) rather than a disaster.
Given that naval nuclear power is a means to threaten other nation states more effectively compared to the means you would otherwise have spent your naval nuclear budget on instead, I'm inclined to disagree. Rickover's Nuclear Navy did -- and I gather largely still does -- have some severe defects. See Tom Clancy's essay "Getting Our Money's Worth" in The Tom Clancy Companion. Rickover's unit commanders were skilled nuclear engineers -- but that was the Chief Engineer's job, the commanders should have been warriors, as is traditional.
Hint - it's also a bad place to store your backups since it is kinda wet. Even the frost-free ones.