Speaking the X protocol is key to interoperability from Unix to Unix.
Um no, that would be POSIX. Speaking the X protocol is the key to being able to stick your spiffy graphical installer jobby on the screen of pretty much anyone in the world, except a large number of NeWS/NeXT/Rhapsody/OS X/Windows/VMS users who don't have X servers. Although they are available. Actually, not sure there is one for NeWS or Rhapsody.
ARexx wasn't available until the 2.0 days, was it? This would've been at a time when NeXTs were the only machines to have WWW servers and browsers. Oh, and let us not forget that NeXTSTEP had integral TCP/IP networking, which CBM never got around to on the AmigaDOS, so while Envoy could network between Amigas, it couldn't network across to anything else (except perhaps some IBM systems).
It also took much longer for Doom to be ported to Amiga than to NeXT, what with Omni Group working on the project:-)
I agree that we weaken our immune systems by vigourous application of disinfectant, but I disagree that this makes the germs stronger. It's antibiotics that do that; by wiping out all bacteria that are susceptible to, say, eurythromycin, we are selectively breeding those bacteria that are immune to its effects. Consider it a pandemic exercise in experimental evolution:-).
It's a grammar mistake, not a spelling one. Perhaps we ought to consult a dictionary to see that loosing is a perfectly acceptable English word. Yeah, too bad you don't know wtf you're talking about.
The 68020 definitely was worth complaining about, as the NeXT cubes had the 25/33 MHz 68040 processors in 1989. Now there was a UNIX workstation! Oh, and there one is, right in front of me with/. open in OmniWeb:-). The Amiga 3000UX was a very nice machine, pity I never had one. My trusty A600 is still going twelve years on though; little 80Mb HDD purring away. The A1200 gets a little more use, and the A500's been consigned to the attic:-(.
Are we close to loosing our anonymity online in Canada?
They're letting anonymous Canadians loose? RUN TO THE HILLS!! "But they're coming from the hills" Run AWAY from the hills! If you see a hill, run in the other direction!
Yet another example of how Microsoft refuse to interoperate - I'm a UNIX hacker and my days have 24 hours in them, as required by ISO 8601. What annoys me is that so many people use MS stuff that they'll start thinking that days are supposed to be 12 hours long, and that everyone doing it the old 24-hour way is just being belligerent.
Re:Does switching to Free Software save us money?
on
Rome Moving to Linux
·
· Score: 2, Informative
OpenSSL/0.9.6g
Oh dear. Looks like it might be quite easy to 0wn the pope, then.
No, but HP one.
OTOH, the Vatican observatory use Suns. But then it's run by Jesuits, not directly by the Vatican.
Does switching to Free Software save us money?
on
Rome Moving to Linux
·
· Score: 0, Troll
Of course, I bet in the end they just come up with a great SETI score, or something similar - something that would actually scale at all on a cluster like this.
i.e. something that doesn't actually use the network particularly heavily. Yes, I concur.
The goal is to run Linpack and "build a home-brew computer powerful enough to be added to a list of the world's 500 fastest computers."
Yes, but you require a minimum of a 100 Base-T connection. You want to create one of the world's top 100 supercomputers using Ethernet? Good luck in beating that latency, guys....next time, see if you can get a flash mob of infiniband vendors to come along for the ride.
I think with all seriousness that an appropriate analogy is 'parasitic', but of course that has pejorative connotations and therefore won't be accepted widely. Perhaps it could be referred to as 'the Stallman touch', in analogy with King Midas. Only in this case things don't turn to gold when he touches them, they turn to GPL.
This is exactly why the GPL is a/the problem. Don't get me wrong, open source is great. Credit should given where it is due. However the GPL tries to control how you develop and deploy your software. Sometimes you may link against GPL'd code, or you may simply include a binary in a release. Either way, you have a good chance of breaking the GPL depending your approach.
Agreed. Many of the 'edge states' of the GPL are not fully understod, and of course there aren't any precedents to have a gander at.
If the GPL was really about freedom "they" wouldnt care what you did with it as long as you explicitly stated where the code or binary came from and submitted updates to the software back to the original author or maintainer.
Disagreed. RMS' stated aim with copyleft was to ensure that once software becomes Free, it is Free for ever more. Giving people the freedom to restrict the Freedom of the software is less ethically favourable in that scheme than ensuring Freedom at the expense of freedom - hence the viral clause.
Anyway, I'd be interested to hear the justification for your clauses "as you explicitly stated where the code or binary came from and submitted updates to the software back to the original author or maintainer" - these are as much a restriction of personal freedom as clause 2 of the GPL.
I'm not so sure about that, although you may be right; I have very little >user experience on Classic Mac. My understanding is that when the switch from M68k to PPC was made, much of the Operating System wasn't actually ported but ran inside a 68k virtual machine, especially legacy APIs that were superceded but not actually removed. It was thus possible for 68k binaries to run within this environment, but they couldn't use new system calls.
As the system was revised, through system 7, mac os 8 and 9, the crufty 68k layers were still present but even more new APIs were added on top. The original goal of the Carbon project was to strip out as much of the cruft as possible while still leaving workable APIs. In fact, according to the head honcho at Black Hole, one of the original aims of Carbon was just meant to be an assistant, to show OS <=9 developers how to properly Yellow Box (i.e. Cocoa) their apps.
Except you skirt around the little detail that Debian and other distros package a massive set of packages, and Apple Update handles a tiny handful.
In this very thread I covered the fact that 'massive' does not mean 'omnipresent'. There will be packages that are not covered, as you indeed go on to talk about.
Furthermore, I use checkinstall, and when the distro vendor *starts* packaging a package, it automatically starts handling that package if I have it installed.
You can do that on Mac systems too, using mkbom and the developer tools for package management.
The only people that complain about SysV init are hardcore BSDites that don't like anything that differs from The Way They Are Used To Things Working. SysV init is hardly "clunky".
And me. Most of my systems management experience is in Solaris, and Linux. I hate SysV init. You've never fully appreciated overkill until you observe that their are eleven states you can put your server into.
What do you like so much about BSD signal handling? I don't see too much extra stuff you could do with it without violating POSIX.
One can't violate POSIX. One can implement it, or not. BSD does implement POSIX and also supplements it just as some SysVs do. Ignoring that oversight for the moment, let's have a look at why the BSD signal handler mechanism is superior (indeed, many SysVs now implement it in acknowledgement of this, though I'd be wary about claiming that all SysVs do). In the SysV/SysIII/VIIed signals API, once a signal has been received, the signal handler is reset to its default value. This means that if I'm expecting SIGHUP to be overloaded somehow, and send my process two SIGHUP signals, I cannot guarantee that the second is handled in the expected manner. Not so with the BSD handler mechanism, which does not reset the signal handlers. Then what happens if you receive a signal while within a signal handler? Well, in SysV, you've got an interesting race condition on your hands. The BSD signal handler introduce ways in which signals could be vetoed or suspended over blocks of code.
Oh, it was a sexy feature back in Mac OS classic days
Yes it was, although Classic MacOS didn't have fat binaries. Todays topic: NeXT Computer, Inc. (later NeXT Software, Inc.)
And why exactly would this be of value?[...]it's not very frequently that I rip a binary out of my system and dump it on another.
No it's not. But that's only because you're using a system that doesn't support it. Think of this: I can develop an application on my black slab, then bundle it up and distribute that one bundle to people using SPARC, M68k, Intel and HP-PA. This saves me a lot of work. Have a look too at the Darwin installation CD available from Apple. That one CD will install on both PowerPC and IA32 architectures. Let's say I decided that I didn't like any of the systems available today, and went out to create uber-UNIX for IA32, IA64, PowerPC, Itanium, SPARC, M68k, ARM, HP-PA, PDP-7 and Alpha. Wouldn't it be great if I only had one distribution set to maintain? Wouldn't it be great if all of my developers could compile for all supported platforms, without the tedium involved with cross-compiling on less aware systems?
Instead of making random, unsupported claims, why not take a look at some benchmarks? Note the context switching time of your vaunted Mach kernel.
I'm sorry, but the article you linked to doesn't give enough information for those benchmarks to be supported. For instance, when comparing file system latencies, why does the benchmarker not tell us which filesystem he is using on each system? My guess is that he's using e2fs on Linux and HFS+ on Darwin. Why not use UFS on both, to actually determine whether the Operating System is the source of the bottlen
You forgot to mention the fact that OS X doesn't even use X, but instead uses the heavily modified NeXT environment. Ooops!
That would be because that is incorrect. Rhapsody and the earliest release of OS X, OS X Server 1, did indeed use the Display PostScript system from NeXTSTEP, modified to present a slightly more Mac-esque user interface. But when Adobe bumped up the licensing costs for DPS, Apple were forced to go back and effectively write a new graphics system from scratch. They based it on Portable Document Format, it's called Quartz and the user interface is known as Aqua.
I find your assertion that OS X does not use X laughable. The latest version of OS X comes bundled with an X server that will run rootless right on top of the Aqua screen. The XFree86 distribution will build from unmodified source and work on earlier OS Xs too: have a look at X11 running in Aqua on a Beige G3 with Jaguar. I develop software for a network of Linux PCs, OPENSTEP PCs, NeXTs, Macs, Suns and assorted other systems. If it wasn't for OS X's support for X11 there would be much less portability between the systems (although GNUstep helps a great deal in that regard). So OS X does use X11, even if you and some other users choose not to.
Debian has the most comprehensive package selection (and a rabidly fanatic user base that keeps debianizing every damn packages they see), and dpkg allows you to easily upgrade, install, remove just by knowing the name (or part of name) of a program.
Actually I'm talking from the perspective of a Debian user here. Debian's package hierarchy is good, but it's still far from exhaustive. There will come times when the program you would like has not been Debianised. And when it does, you have to install that program yourself and maintain it yourself, just as you would on any other operating system.
Also - OS X is not BSD. Is that so freaking hard to understand? It has BSD services running on top of Darwin. Darwin is the kernel, not BSD.
Darwin is not the kernel. Is that so freaking hard to understand? XNU is the kernel, which is a part of the Darwin Operating System. Darwin is a BSD operating system which includes the Mach microkernel running in monolith mode, with features from the BSD kernel added in. The BSD subsystem does not as some people think run as a personality on top of Mach; the two have been combined by Apple.
"Fat" binaries are nothing new, and in fact are something that Apple acquisitioned (along with the OS that was formed into OS X) from NeXT. I am sure you're old enough to remember good ol' NeXT - which ran on many, many architectures aside from the good' ol black boxen.
Yes indeed I am. This post comes to you from a turbo colour slab running OmniWeb 2.0 on top of NeXTSTEP 3.3. Acquisitioned is not a real word, acquired is. Yes, I know that fat binaries came from NeXT. They're still in use today, in OS X. OS X is the only modern operating system to use this technology, in which it is far superior to other offerings. It's jsut a pity that Apple don't make more of it.
Drool over the dynamic loader? Roflmao... That has to be the most idiotic comment I heard by far. yeah man - what an achievement, resolving unresolved symbols, loading shared libraries, and performing relocation. Yay. Need I tell you that OS X doesn't even do ELF? Yay. *cough*
No you don't, and frankly I don't give a monkey's because ELF is getting old. The Mach_O binary format provides portability as well as small executables when compiled thin. It provides superior threading by realising processes, LWPs and threads as kernel-scheduled Mach threads. It's better than ELF.
It appears that more homework is required on your part regarding the various parts that go to make up OS X. Find out about Xnu, Mach, Darwin and FreeBSD, then report back on your progress. The second assignment will focus on Cocoa, Quartz, Aqua, CoreFoundation, IOKit and possibly WebObjects if we have time.
OK, here's something I haven't tried: if I create another System Folder (not that I particularly want to, I'm just curious about the ins and outs) do I have to 'bless' it in that strange OS <= 9 manner? Or can Classic.app (MacOS.app on Rhapsody boxen) deal with that?
Try Jaguar on a 7300. Or Panther on a 9600. Or even Panther on a beige G3. For those of us who love Apple hardware, can't afford gear more recent than four years old, and want to get some UNIX out of it, Linux just blows OS X right out of the water.
I have Puma on my 8600 and Jaguar on my Beige G3, atm. Have a look at X Post Facto.
Linux doesn't care about my video chipset.
If you want to run X11, then yes it does. Have a look at/etc/X11/XFree86Config-4 on your Linux box. Now go and install X11 on Darwin, and look at the same file. Oops! It isn't there. That's right; it doesn't need you to tell it what blinking graphics card you have, it can just ask the kernel.
The Debian "Software Update" (apt) updates EVERY APPLICATION ON THE SYSTEM.
Only if you only install Debian packages. As soon as you install something from another source, you have to maintain it yourself. Just as you would on OS X.
OS X also has the benefits of being a BSD: no ugly klunky SysV init, a classy signal handling mechanism, and Ceren. But it's a ++BSD; have a look at the System Starter. Marvel at the way you can compile a single binary that will run on multiple architectures. Drool over the dynamic loader. Whimper in awe at the Mach threading system.
To change that, you'd need the server apps, TCP/IP stack, and kernel to stay awake. I.e. you need the machine to not go to sleep. Have a gander at the energy saving panel in System Prefs, and see if you can't get the display and disks to switch off when they're not needed, but leave the system up.
One thing in particular that can be confusing to Linux developers about OS X is its overlay of two distinct directory organizations -- the traditional/etc/,/usr/local/,/sbin/, and so on of Linux/Unix systems, and the/Application/,/Library/,/System/ from Mac OS 9.
That second hierarchy actually comes from NeXTSTEP, where it was called/NextApplications,/NextLibrary,/NextDeveloper, etc. Mac OS 9 did not have a particular imposition of hierarchy in the same way that UNIX might; applications can live just about anywhere.
Secondly there's a very conscious and IMHO good reason to farm off the NeXTish stuff into a different hierarchy - that is that it's a different system. All of the files in/etc,/usr,/var etc. are in the same places that you would expect to find them on any UNIX. Looking for the run control scripts? They're in/etc/rc*.
The OPENSTEP-derived APIs, the Aqua GUI, Cocoa applications etc. are orthogonal to UNIX. They just happen to be running on a UNIX system (unless you're using Yellow Box for Windows NT). Keeping them in their own hierarchies so that they don't intrude on or get confused with UNIX stuff is a good idea.
There is an anti-case-study: GNUstep does indeed put all of its files into the UNIX hierarchy, but it still partitions them into separate subdirectories, namely/usr/GNUstep and ~/GNUstep. Again, because it's orthogonal to the underlying UNIX system, it tries to keep out of its way.
But isn't that mostly because people have faster hardware to bog down with Java now, rather than Java itself really improving it's performance?
Mainly, yes (though don't forget -Xoptimize). But in the UNIX world, that's OK (and ESR agrees with me here, in his book "The Art of UNIX Programming"); what's the point of spending 18 months optimising your code? The computer it's running on will be twice as fast anyway, so you'll get a 50% decrease in execution time.
IMHO that's a particularly restrictive definition of 'app', but so be it. Have a look at Solaris' configuration stuff, the HotJava browser, the Java bits of OpenOffice.org, and check the Java section of sourceforge. I will agree though, that's a particularly Sun-dominated list of uses:-). The thing is, Java's only real wins are OO, built-in garbage collection and portability. The last of those can be met in C or C++ and the benefits of the first two aren't significant enough to be a clincher. Java is also unfortunately permanently tarred with the 'slow' brush. That's just not true any more, especially on Solaris and Mac OS X. It was true of the JVM in Windows as employed by Internet Explorer, which was many people's first impression of Java, and it was true of that JVM on 90 MHz Pentiums running Windows 95.
WebObjects is a huge Java system for developing server applications, used in many places including the Apple store online. You have a 1997 FUBAR from Apple to thank for it being Java instead of Objective-C, but Java it is.
Slashdot Mirror
ARexx wasn't available until the 2.0 days, was it? This would've been at a time when NeXTs were the only machines to have WWW servers and browsers. Oh, and let us not forget that NeXTSTEP had integral TCP/IP networking, which CBM never got around to on the AmigaDOS, so while Envoy could network between Amigas, it couldn't network across to anything else (except perhaps some IBM systems).
It also took much longer for Doom to be ported to Amiga than to NeXT, what with Omni Group working on the project :-)
I agree that we weaken our immune systems by vigourous application of disinfectant, but I disagree that this makes the germs stronger. It's antibiotics that do that; by wiping out all bacteria that are susceptible to, say, eurythromycin, we are selectively breeding those bacteria that are immune to its effects. Consider it a pandemic exercise in experimental evolution :-).
Oh, I've got one of those, but there's nowhere to fit the NeXTDimension card ;-).
It's a grammar mistake, not a spelling one. Perhaps we ought to consult a dictionary to see that loosing is a perfectly acceptable English word. Yeah, too bad you don't know wtf you're talking about.
The 68020 definitely was worth complaining about, as the NeXT cubes had the 25/33 MHz 68040 processors in 1989. Now there was a UNIX workstation! Oh, and there one is, right in front of me with /. open in OmniWeb :-). The Amiga 3000UX was a very nice machine, pity I never had one. My trusty A600 is still going twelve years on though; little 80Mb HDD purring away. The A1200 gets a little more use, and the A500's been consigned to the attic :-(.
That wouldn't work; 'loosing' is a correctly spelt word. A grammar checker handy be may.
They're letting anonymous Canadians loose? RUN TO THE HILLS!! "But they're coming from the hills" Run AWAY from the hills! If you see a hill, run in the other direction!
Yet another example of how Microsoft refuse to interoperate - I'm a UNIX hacker and my days have 24 hours in them, as required by ISO 8601. What annoys me is that so many people use MS stuff that they'll start thinking that days are supposed to be 12 hours long, and that everyone doing it the old 24-hour way is just being belligerent.
Oh dear. Looks like it might be quite easy to 0wn the pope, then.
OTOH, the Vatican observatory use Suns. But then it's run by Jesuits, not directly by the Vatican.
Ummm, duh, is the Pope a Linux user?
i.e. something that doesn't actually use the network particularly heavily. Yes, I concur.
Yes, but you require a minimum of a 100 Base-T connection. You want to create one of the world's top 100 supercomputers using Ethernet? Good luck in beating that latency, guys....next time, see if you can get a flash mob of infiniband vendors to come along for the ride.
I think with all seriousness that an appropriate analogy is 'parasitic', but of course that has pejorative connotations and therefore won't be accepted widely. Perhaps it could be referred to as 'the Stallman touch', in analogy with King Midas. Only in this case things don't turn to gold when he touches them, they turn to GPL.
Agreed. Many of the 'edge states' of the GPL are not fully understod, and of course there aren't any precedents to have a gander at.
Disagreed. RMS' stated aim with copyleft was to ensure that once software becomes Free, it is Free for ever more. Giving people the freedom to restrict the Freedom of the software is less ethically favourable in that scheme than ensuring Freedom at the expense of freedom - hence the viral clause.
Anyway, I'd be interested to hear the justification for your clauses "as you explicitly stated where the code or binary came from and submitted updates to the software back to the original author or maintainer" - these are as much a restriction of personal freedom as clause 2 of the GPL.
I'm not so sure about that, although you may be right; I have very little >user experience on Classic Mac. My understanding is that when the switch from M68k to PPC was made, much of the Operating System wasn't actually ported but ran inside a 68k virtual machine, especially legacy APIs that were superceded but not actually removed. It was thus possible for 68k binaries to run within this environment, but they couldn't use new system calls.
As the system was revised, through system 7, mac os 8 and 9, the crufty 68k layers were still present but even more new APIs were added on top. The original goal of the Carbon project was to strip out as much of the cruft as possible while still leaving workable APIs. In fact, according to the head honcho at Black Hole, one of the original aims of Carbon was just meant to be an assistant, to show OS <=9 developers how to properly Yellow Box (i.e. Cocoa) their apps.
In this very thread I covered the fact that 'massive' does not mean 'omnipresent'. There will be packages that are not covered, as you indeed go on to talk about.
You can do that on Mac systems too, using mkbom and the developer tools for package management.
And me. Most of my systems management experience is in Solaris, and Linux. I hate SysV init. You've never fully appreciated overkill until you observe that their are eleven states you can put your server into.
One can't violate POSIX. One can implement it, or not. BSD does implement POSIX and also supplements it just as some SysVs do. Ignoring that oversight for the moment, let's have a look at why the BSD signal handler mechanism is superior (indeed, many SysVs now implement it in acknowledgement of this, though I'd be wary about claiming that all SysVs do). In the SysV/SysIII/VIIed signals API, once a signal has been received, the signal handler is reset to its default value. This means that if I'm expecting SIGHUP to be overloaded somehow, and send my process two SIGHUP signals, I cannot guarantee that the second is handled in the expected manner. Not so with the BSD handler mechanism, which does not reset the signal handlers. Then what happens if you receive a signal while within a signal handler? Well, in SysV, you've got an interesting race condition on your hands. The BSD signal handler introduce ways in which signals could be vetoed or suspended over blocks of code.
Yes it was, although Classic MacOS didn't have fat binaries. Todays topic: NeXT Computer, Inc. (later NeXT Software, Inc.)
No it's not. But that's only because you're using a system that doesn't support it. Think of this: I can develop an application on my black slab, then bundle it up and distribute that one bundle to people using SPARC, M68k, Intel and HP-PA. This saves me a lot of work. Have a look too at the Darwin installation CD available from Apple. That one CD will install on both PowerPC and IA32 architectures. Let's say I decided that I didn't like any of the systems available today, and went out to create uber-UNIX for IA32, IA64, PowerPC, Itanium, SPARC, M68k, ARM, HP-PA, PDP-7 and Alpha. Wouldn't it be great if I only had one distribution set to maintain? Wouldn't it be great if all of my developers could compile for all supported platforms, without the tedium involved with cross-compiling on less aware systems?
I'm sorry, but the article you linked to doesn't give enough information for those benchmarks to be supported. For instance, when comparing file system latencies, why does the benchmarker not tell us which filesystem he is using on each system? My guess is that he's using e2fs on Linux and HFS+ on Darwin. Why not use UFS on both, to actually determine whether the Operating System is the source of the bottlen
That would be because that is incorrect. Rhapsody and the earliest release of OS X, OS X Server 1, did indeed use the Display PostScript system from NeXTSTEP, modified to present a slightly more Mac-esque user interface. But when Adobe bumped up the licensing costs for DPS, Apple were forced to go back and effectively write a new graphics system from scratch. They based it on Portable Document Format, it's called Quartz and the user interface is known as Aqua.
I find your assertion that OS X does not use X laughable. The latest version of OS X comes bundled with an X server that will run rootless right on top of the Aqua screen. The XFree86 distribution will build from unmodified source and work on earlier OS Xs too: have a look at X11 running in Aqua on a Beige G3 with Jaguar. I develop software for a network of Linux PCs, OPENSTEP PCs, NeXTs, Macs, Suns and assorted other systems. If it wasn't for OS X's support for X11 there would be much less portability between the systems (although GNUstep helps a great deal in that regard). So OS X does use X11, even if you and some other users choose not to.
Actually I'm talking from the perspective of a Debian user here. Debian's package hierarchy is good, but it's still far from exhaustive. There will come times when the program you would like has not been Debianised. And when it does, you have to install that program yourself and maintain it yourself, just as you would on any other operating system.
Darwin is not the kernel. Is that so freaking hard to understand? XNU is the kernel, which is a part of the Darwin Operating System. Darwin is a BSD operating system which includes the Mach microkernel running in monolith mode, with features from the BSD kernel added in. The BSD subsystem does not as some people think run as a personality on top of Mach; the two have been combined by Apple.
Yes indeed I am. This post comes to you from a turbo colour slab running OmniWeb 2.0 on top of NeXTSTEP 3.3. Acquisitioned is not a real word, acquired is. Yes, I know that fat binaries came from NeXT. They're still in use today, in OS X. OS X is the only modern operating system to use this technology, in which it is far superior to other offerings. It's jsut a pity that Apple don't make more of it.
No you don't, and frankly I don't give a monkey's because ELF is getting old. The Mach_O binary format provides portability as well as small executables when compiled thin. It provides superior threading by realising processes, LWPs and threads as kernel-scheduled Mach threads. It's better than ELF.
It appears that more homework is required on your part regarding the various parts that go to make up OS X. Find out about Xnu, Mach, Darwin and FreeBSD, then report back on your progress. The second assignment will focus on Cocoa, Quartz, Aqua, CoreFoundation, IOKit and possibly WebObjects if we have time.
OK, here's something I haven't tried: if I create another System Folder (not that I particularly want to, I'm just curious about the ins and outs) do I have to 'bless' it in that strange OS <= 9 manner? Or can Classic.app (MacOS.app on Rhapsody boxen) deal with that?
I have Puma on my 8600 and Jaguar on my Beige G3, atm. Have a look at X Post Facto.
If you want to run X11, then yes it does. Have a look at /etc/X11/XFree86Config-4 on your Linux box. Now go and install X11 on Darwin, and look at the same file. Oops! It isn't there. That's right; it doesn't need you to tell it what blinking graphics card you have, it can just ask the kernel.
Only if you only install Debian packages. As soon as you install something from another source, you have to maintain it yourself. Just as you would on OS X.
OS X also has the benefits of being a BSD: no ugly klunky SysV init, a classy signal handling mechanism, and Ceren. But it's a ++BSD; have a look at the System Starter. Marvel at the way you can compile a single binary that will run on multiple architectures. Drool over the dynamic loader. Whimper in awe at the Mach threading system.
To change that, you'd need the server apps, TCP/IP stack, and kernel to stay awake. I.e. you need the machine to not go to sleep. Have a gander at the energy saving panel in System Prefs, and see if you can't get the display and disks to switch off when they're not needed, but leave the system up.
That second hierarchy actually comes from NeXTSTEP, where it was called /NextApplications, /NextLibrary, /NextDeveloper, etc. Mac OS 9 did not have a particular imposition of hierarchy in the same way that UNIX might; applications can live just about anywhere.
Secondly there's a very conscious and IMHO good reason to farm off the NeXTish stuff into a different hierarchy - that is that it's a different system. All of the files in /etc, /usr, /var etc. are in the same places that you would expect to find them on any UNIX. Looking for the run control scripts? They're in /etc/rc*.
The OPENSTEP-derived APIs, the Aqua GUI, Cocoa applications etc. are orthogonal to UNIX. They just happen to be running on a UNIX system (unless you're using Yellow Box for Windows NT). Keeping them in their own hierarchies so that they don't intrude on or get confused with UNIX stuff is a good idea.
There is an anti-case-study: GNUstep does indeed put all of its files into the UNIX hierarchy, but it still partitions them into separate subdirectories, namely /usr/GNUstep and ~/GNUstep. Again, because it's orthogonal to the underlying UNIX system, it tries to keep out of its way.
Mainly, yes (though don't forget -Xoptimize). But in the UNIX world, that's OK (and ESR agrees with me here, in his book "The Art of UNIX Programming"); what's the point of spending 18 months optimising your code? The computer it's running on will be twice as fast anyway, so you'll get a 50% decrease in execution time.
IMHO that's a particularly restrictive definition of 'app', but so be it. Have a look at Solaris' configuration stuff, the HotJava browser, the Java bits of OpenOffice.org, and check the Java section of sourceforge. I will agree though, that's a particularly Sun-dominated list of uses :-). The thing is, Java's only real wins are OO, built-in garbage collection and portability. The last of those can be met in C or C++ and the benefits of the first two aren't significant enough to be a clincher. Java is also unfortunately permanently tarred with the 'slow' brush. That's just not true any more, especially on Solaris and Mac OS X. It was true of the JVM in Windows as employed by Internet Explorer, which was many people's first impression of Java, and it was true of that JVM on 90 MHz Pentiums running Windows 95.
WebObjects is a huge Java system for developing server applications, used in many places including the Apple store online. You have a 1997 FUBAR from Apple to thank for it being Java instead of Objective-C, but Java it is.