This is only partly correct. The correct part is the technical/vocational schools are not accredited by the same boards as traditional universities. The incorrect (and slanted) part of this is that technical schools are legally required to be accredited by other boards set up for them, and are legally prohibited from being accredited by the boards which accredit traditional universities. _None_ of them have no outside accreditation; it's a legal requirement that they be accredited. Most of what you wrote _was_ correct through the mid-1990's, when there were some spectacular problems in the technical school industry. As a result of these problems, these schools came under tight scrutiny and regulation and the rules and outcomes are very different now.
You can make the case that they only want your money, but that's not entirely accurate either. Part of their accreditation process measures their graduation rates and placement rates (placement meaning a student is working in a job in the field for which they were trained). If either of these fall out of norm (which is roughly mid-80% on both measures) the school loses accreditation. Losing accreditation means the school is out of business. So, in order to keep getting your money, there's a _very_ strong incentive to actually get people graduated and out there working.
It also means that technical schools tend to set up strong employer relationships so that their students can get placed. The ones I'm familiar with have an "advisory board" of 50-100 local companies (small business to Fortune 500) who come in regularly, do their own audits and inspections, suggest changes, etc. In return, these companies take graduates from these schools seriously.
You are correct that the standards are very different. Technical schools are interested in one thing only: taking a student and getting them graduated and placed in the field of their training. They're not interested in well-rounded students, they're not interested in teaching English, math, sciences, etc. beyond those required for the job. Their mission is to educate students who aren't well suited to traditional university programs. Most people who _are_ well suited to traditional university programs would feel slighted by a technical school, but that doesn't mean they're not highly valuable to the population who can't handle a university program (due to lack of prerequisite education, life pressures, access, or whatever else).
I have no stake at all in the technical school area -- I just know several people who work in it and have gone over all of this in detail. They're quite sensitive to it, because the common perception of what they do is completely wrong.
This is actually completely factually incorrect -- and I say that from the perspective of someone with a graduate degree in CS from a top-tier university program. Most of the technical schools do a very good job for the students they educate. They're legally required to -- unlike traditional universities, technical schools are judged primarily on two criteria _only_: graduation rate and placement rate. Fall out of the norm on either of those and you lose the ability to enroll students with federal matching funds, grants, etc. -- which is _immediate_ death for the school in question. Most students attending a technical school have already tried traditional university (or community college) programs and can't make it there; a technical school program is their last chance.
The only way for the technical schools to stay in business is to graduate a high percentage of their students and place a high percentage into jobs related to the educational program the student completed. Fail to do that, they're shut down, cold. As part of this, technical schools are _far_ more likely than larger universities to give individual attention and work with students in a personalized fashion to handle outside issues, etc. They are also certain to teach only material required for the specific job -- a technical school is not going to require any math, science, English, etc. that's not specifically job-related.
University education is an entirely different thing. Most university programs, when you boil them down, are about teaching you to learn, about making you a well-rounded person, about exposing you to new ideas and concepts, teaching critical thinking, etc. They're not about specific job preparation. Universities would crash and burn if evaluated by the standards used for technical schools; technical schools would go wild and waste everyone's time and money if evaluated by the standards used for traditional universities.
According to most surveys, University of Phoenix (not a technical school, but a university offering a nontraditional program) does quite a good job of teaching MBA students. However, there's a huge glut of MBA's out there, and Phoenix doesn't have the name of a top-flight MBA program. For that reason their value is questionable -- but it's not because of questionable standards.
Heavenly Creatures had numerous "claymation" sequences that blended clay-figure characters with human faces. I suspect that much of that was done digitally.
The answer can be found here:
http://www.help.rr.com/faqs/e_lans.html?topic=Bill ing+and+Services,selfhelp
and is that Road Runner (including Austin, Texas -- that's how I got to this link in the first place, and it's where I live too) allows home LANs, it just doesn't support them. Note that the page doesn't mention NAT or routers (it makes reference to "hubs"), but it does discuss "multiple computers/users [] using the service simultaneously".
This article reminds me of what I hated most about Jurassic Park (the novel -- the movie blessly omits the worst of it) -- Ian Malcolm's runaway pessimism. The arguments boil down to be very similar. Ian Malcolm says that complex systems are so complex we can't ever understand them all, so they're doomed to fail. Joel Spolsky says that our high-level abstractions will fail and because of that we're doomed to need to understand the lower-level stuff. I have problems with both -- they're a sort of technopessimism that I find particularly offensive, because they make the future sound bleak and hopeless despite volumes of evidence that, in fact, we've been dealing successfully with these issues for decades and they're just not all that bad.
We have examples of massively complex systems that work very reliably day-in and day-out. Jet airplanes, for one; the national communications infrastructure, for another. Airplanes are, on the whole, amazingly reliable. The communications infrastructure, on the other hand, suffers numerous small faults, but they're quickly corrected and we go on. Both have some obvious leaky abstractions.
The argument works out to be pessimism, pure and simple -- and unwarrented pessimism to boot. If it were true that things were all that bad, programmers would all _need_ to understand, in gruesome detail, the microarchitectures they're coding to, how instructions are executed, the full intricacies of the compiler, etc. All of these are leaky abstractions from time to time. They'd also need to understand every line of libc, the entire design of X11 top to bottom, and how their disk device driver works. For almost everyone, this simply isn't true. How many web designers, or even communications applications writers, know -- to the specification level -- how TCP/IP works? How many non-commo programmers?
The point is that sometimes you need to know a _little bit_ about the place where the abstraction can leak. You don't need to know the lower layer exhaustively. A truly competant C programmer may need to know a bit about the architecture of their platform (or not -- it's better to write portable code) but they surely do not need to be a competant assembly programmer. A competant web designer may need to know something about HTML, but not the full intricacies of it. And so forth.
Yes, the abstractions leak. Sometimes you get around this by having one person who knows the lower layer inside and out. Sometimes you delve down into the abstraction yourself. And sometimes, you say that, if the form fails because it needs JavaScript and the user turned off JavaScript, it's the user's fault and mandate JavaScript be turned on -- in fact, a _good_ high-level tool would generate defensive code to put a message on the user's screen telling them that, in the absence of JavaScript, things will fail (i.e. the tool itself can save the programmer from the leaky abstraction).
What Ian Malcolm says, when you boil it all down, is that complex systems simply can't work in a sustained fashion. We have numerous examples which disprove the theory. That doesn't mean that we don't need to worry about failure cases, it means we overengineer and build in failsafes and error-correcting logic and so forth. What Joel Spolsky says is that you can't abstract away complexity because the abstractions leak. Again, there are numerous examples where we've done exactly that, and the abstraction has performed perfectly adequately for the vast majority of users. Someone needs to understand the complex part and maintain the abstraction -- the rest of us can get on with what we're doing, which may be just as complex, one layer up. We can, and do, stand on the shoulders of giants all the time -- we don't need to fully understand the giants to make use of their work.
You're right -- someone will correct you. 10.2 does in fact contain major changes to the kernel, including updated I/O, networking, and VM. 10.2.1 includes further performance improvements (to the level that 10.2.1 is visably, noticably faster than 10.2, which is in turn faster than 10.1.5).
One part of the improvement in 10.2(.1), though not all of it, is that the majority of the system is built with gcc 3.1 instead of 2.9.5. According to most sources (including the gcc team themselves), 3.1-generated code is roughly 6% or so faster than 2.9.5-generated code. Apple has made quite a number of performance improvements in gcc as well, which fold into code built for 10.2.
The google.com link quoted by the original poster shows how to remap caps-lock as control under MacOS; I've done it before, and it doesn't result in any ill effects. The technique presented is to transpose the mapping from two key codes; I'm not sure in what way that could be described as a "horrible kludge". Many old Apple keyboards have locking caps lock keys; this is an annoyance, as you need to remove the locking mechanism.
That said, I'm a Unix professional (kernel; device drivers, right now); have been for many years. My _entire_ professional life has been spent working on keyboards that have control on the lower left, and caps lock next to A. It is _entirely_ possible to use Unix with control in lower-right. I have small hands; I can still use control and not have any trouble reaching other keys. I'm currently typing this on an IBM keyboard that ships with RS/6000 workstations; control is in lower-left. My officemate's IBM PC-influenced keyboard (Windows key, etc) has control in lower-left; his Dell laptop has control in lower-left. One of my co-worker's IBM laptop? Control's in lower-left.
Control in lower-right is an ISO standard; Apple didn't come up with it because of any desire to spite Unix users.
Apple has been a Unix vendor for at least 14 years. Anyone remember A/UX? I do... loooong experience with it, including years as GNU ports maintainer when Apple was still persona non grata with the FSF. Anyone remember the workgroup servers running AIX? I wrote the serial driver. Any claim that Apple has been ignoring Unix users needs to take into account that Apple's been a Unix vendor for a very long time _and_ that they've now moved their entire platform to a Unix(/Mach)-based system.
I do sympathize with muscle memory -- my current laptop has a key to the left of control (fn, for those who're curious). It was a bit of pain getting my finger to shift over one position -- about a week's worth. After that, all's well. You may have harder to retrain muscle memory.
The most interesting part of the parent post is the reference to uControl. uControl remaps control to caps-lock _exactly_ the way the poster wants. It's free software (GPL). _If_ ADB were "broken-by-design" as claimed, uControl wouldn't be able to do this. If anyone wanted control -> caps lock remapping on the *BSD's, it shouldn't be hard to look at a piece of GPL'd software and figure out to, e.g., modify the X server to do the same thing.
It seems to me that the poster himself has presented two solutions, one for Debian and one for Apple's own Unix product, that would let him use Unix on an Apple laptop with control where he wants it (assuming they work, and comments indicate they do). Why should it matter if these products need to resort to kludges, horrible or otherwise -- do you _need_ to know how your keyboard-mapping software works to be able to type? Should you _care_ how it works, as long as the keys do what you want?
_Exactly_ what more do you expect Apple to do -- provide remapping software for *BSD? I understand that it might be nice for the builtin keyboard to be USB, but given that working solutions exist for two flavors of Unix, I don't really understand the urgency of a major hardware design change to fix a problem that it's already agreed has a ready fix available in software.
As the rest of the discussion notes, it's trivial to copy MP3's off the iPod with standard, included tools; there are plenty of freeware third-party solutions to do it, if you don't like the included tools.
The only catch is that the included iTunes application only syncs _to_ the iPod, not _from_ it. This is a simple design decision, and hardly an unreasonable one. For example, iPhoto only syncs pictures _from_ a digital camera, not _to_ it. I can think of situations where it'd be nice to send pictures to a camera, but it's hardly common and they didn't choose to support it.
The point is, no one "Forced" a "no copy off the iPod". It's trivial to copy from the iPod. One included application doesn't copy from the iPod, that's it.
The BSD code in Mac OS X has not been "proprietized". Apple makes changes to all BSD-derived code publically available under the APSL and almost always returns them to the FreeBSD project under the BSD license. The proprietary code in Mac OS X was written by Apple (or NeXT, now part of Apple). Granted that it doesn't advance the goal of freedom over tech for them to keep their own code private, but they're _not_ taking the route allowed by the BSD license and forking development into an Apple-FreeBSD fork; their BSD code is free in the same sense that BSD is free.
In that sense, the BSD layers of Mac OS X are roughly as free as GNU/Linux; you can get the code, use it without any grief (except the need to release changes you make should you distribute the resulting software), even sell a distribution based on the BSD layers of Mac OS X. What you _can't_ do is use Apple's proprietary code freely. A number of Linux distros do the same thing; the difference is that Apple's proprietary code represents the entire user-visable interface of Mac OS X, and therefore (to most users) the real value-add of the system.
It's also probably true to say that, while GNU/Linux does indeed dream about being free, Linux itself simply dreams about being a widely used OS (witness both Linus' activities and the desire of many in the Linux community to see it as a desktop capable of "squashing Microsoft"). Linus is quite comfortable with close-source code being used on top of Linux; it's a matter of conjecture whether he'd be comfortable with a close-source graphics environment taking over as the premiere Linux desktop, but there's no reason to automatically assume he wouldn't. Linux is the kernel; the reason it's GNU/Linux is because of the GNU tools. Replace them with a FreeBSD toolchain and a proprietary graphics subsystem and you don't have GNU/Linux nor the philosophical goal of freedom.
At least there, you're dealing with what used to be Alpha to a certain extent.
HP-PA, not Alpha. While, thanks to all the mergers, HPCompaq now owns the Alpha architecture, Itanium is more-or-less a strange VLIW descendant of HP-PA.
I'm not sure what advantage Itanium would have over PowerPC, for Apple. The main source of grief for Apple is that Motorola provides Altivec while IBM does not. However, Itanium doesn't provide anything particularly similar to Altivec either. For 32 and 64-bit non-Altivec, IBM makes very nice Power architecture (compatible with PowerPC for all reasonable purposes) chips with plenty of headroom to compete flat-out with Intel.
Given the amount of grief Apple would get from developers about porting applications _again_ to a hypothetical MacOS X-on-Intel (x86 or Itanium), I can't see that happening soon. Even if everything from Apple's side is seamless, a lot of developers would need to consider endianness, performance issues, etc. Also, you lose Carbon (MacOS APIs need work moving to a little-endian architecture) and Classic (unless there's a high-quality emulator built in).
Overall, there's plenty of headroom in PowerPC -- the issue is getting the chip vendors to push it to consumer parts that Apple can use. Their volumes are high enough (and growing) that there's motivation to do that. Any concerns about Motorola's committment aside, IBM _needs_ to keep developing Power-architecture parts for the foreseeable future. As long as they're designing them, why not spend a small delta to make a consumer-grade version and sell an extra couple million chips (compared to the 5-or-maybe-6-digit numbers they'll sell for iSeries and pSeries servers otherwise)?
Between those factors, I don't see MacOS moving to Intel. Apple is likely keeping it on a far-back burner for contingency purposes, but market realities make it the sort of thing you'd see if they were flailing on the verge of extinction and simply had nowhere else to go.
The fallacy to all of this is the assumption that designers are interested in _bigger_ bombs. Bigger bombs are easy; we've known for years how to build very big bombs. No one's interested.
Most of the work done on nuclear weapons at these labs falls into two categories: verifying that aging weapons still work (instead of testing them) as already mentioned, and designing new, _smaller_ bombs. Smaller bombs are considered more destabilizing by the anti-nuclear movement -- hence all the protestation. However, the general public doesn't see smaller as a threat, so the misconception that bomb designers have any interest in bigger bombs goes unchecked.
If you do the research, you'll find out that during the 80's, the number of nuclear weapons in the US arsenal went up several times, but the aggregate megatonnage went _down_ by a factor of 10. Weapons were converted to MIRV's, large bombs were discontinued entirely, and a number of smaller (field artillery, SAM supression, etc) weapons were added. Since the 80's, this trend has continued, though cutbacks in weapons production have curtained the trend.
Personally, my feeling is that the world is safer with the enormous decrease in megatonnage, even if smaller weapons slightly increase the liklihood some nuclear weapon will be used ("it's only a small bomb"). Smaller weapons are, as a general rule (easy to violate, but as a general rule) cleaner, more precise, and more likely to be used against a military target (missile launcher, ship, base) than indiscriminately against a large urban target. The problem with that is that it takes out the Mutual Assured Destruction doctrine; if neither side is losing cities, they might fight a limited nuclear war. I come down on the side that says MAD was useful, but lost relevance a long time ago -- and that it's better to be physically incapable of large-scale destruction than to be limited merely by the fear "they'll do it back to us!"
Slashdot Mirror
This is only partly correct. The correct part is the technical/vocational schools are not accredited by the same boards as traditional universities. The incorrect (and slanted) part of this is that technical schools are legally required to be accredited by other boards set up for them, and are legally prohibited from being accredited by the boards which accredit traditional universities. _None_ of them have no outside accreditation; it's a legal requirement that they be accredited. Most of what you wrote _was_ correct through the mid-1990's, when there were some spectacular problems in the technical school industry. As a result of these problems, these schools came under tight scrutiny and regulation and the rules and outcomes are very different now.
You can make the case that they only want your money, but that's not entirely accurate either. Part of their accreditation process measures their graduation rates and placement rates (placement meaning a student is working in a job in the field for which they were trained). If either of these fall out of norm (which is roughly mid-80% on both measures) the school loses accreditation. Losing accreditation means the school is out of business. So, in order to keep getting your money, there's a _very_ strong incentive to actually get people graduated and out there working.
It also means that technical schools tend to set up strong employer relationships so that their students can get placed. The ones I'm familiar with have an "advisory board" of 50-100 local companies (small business to Fortune 500) who come in regularly, do their own audits and inspections, suggest changes, etc. In return, these companies take graduates from these schools seriously.
You are correct that the standards are very different. Technical schools are interested in one thing only: taking a student and getting them graduated and placed in the field of their training. They're not interested in well-rounded students, they're not interested in teaching English, math, sciences, etc. beyond those required for the job. Their mission is to educate students who aren't well suited to traditional university programs. Most people who _are_ well suited to traditional university programs would feel slighted by a technical school, but that doesn't mean they're not highly valuable to the population who can't handle a university program (due to lack of prerequisite education, life pressures, access, or whatever else).
I have no stake at all in the technical school area -- I just know several people who work in it and have gone over all of this in detail. They're quite sensitive to it, because the common perception of what they do is completely wrong.
This is actually completely factually incorrect -- and I say that from the perspective of someone with a graduate degree in CS from a top-tier university program. Most of the technical schools do a very good job for the students they educate. They're legally required to -- unlike traditional universities, technical schools are judged primarily on two criteria _only_: graduation rate and placement rate. Fall out of the norm on either of those and you lose the ability to enroll students with federal matching funds, grants, etc. -- which is _immediate_ death for the school in question. Most students attending a technical school have already tried traditional university (or community college) programs and can't make it there; a technical school program is their last chance.
The only way for the technical schools to stay in business is to graduate a high percentage of their students and place a high percentage into jobs related to the educational program the student completed. Fail to do that, they're shut down, cold. As part of this, technical schools are _far_ more likely than larger universities to give individual attention and work with students in a personalized fashion to handle outside issues, etc. They are also certain to teach only material required for the specific job -- a technical school is not going to require any math, science, English, etc. that's not specifically job-related.
University education is an entirely different thing. Most university programs, when you boil them down, are about teaching you to learn, about making you a well-rounded person, about exposing you to new ideas and concepts, teaching critical thinking, etc. They're not about specific job preparation. Universities would crash and burn if evaluated by the standards used for technical schools; technical schools would go wild and waste everyone's time and money if evaluated by the standards used for traditional universities.
According to most surveys, University of Phoenix (not a technical school, but a university offering a nontraditional program) does quite a good job of teaching MBA students. However, there's a huge glut of MBA's out there, and Phoenix doesn't have the name of a top-flight MBA program. For that reason their value is questionable -- but it's not because of questionable standards.
Heavenly Creatures had numerous "claymation" sequences that blended clay-figure characters with human faces. I suspect that much of that was done digitally.
The answer can be found here: http://www.help.rr.com/faqs/e_lans.html?topic=Bill ing+and+Services,selfhelp
and is that Road Runner (including Austin, Texas -- that's how I got to this link in the first place, and it's where I live too) allows home LANs, it just doesn't support them. Note that the page doesn't mention NAT or routers (it makes reference to "hubs"), but it does discuss "multiple computers/users [] using the service simultaneously".
We have examples of massively complex systems that work very reliably day-in and day-out. Jet airplanes, for one; the national communications infrastructure, for another. Airplanes are, on the whole, amazingly reliable. The communications infrastructure, on the other hand, suffers numerous small faults, but they're quickly corrected and we go on. Both have some obvious leaky abstractions.
The argument works out to be pessimism, pure and simple -- and unwarrented pessimism to boot. If it were true that things were all that bad, programmers would all _need_ to understand, in gruesome detail, the microarchitectures they're coding to, how instructions are executed, the full intricacies of the compiler, etc. All of these are leaky abstractions from time to time. They'd also need to understand every line of libc, the entire design of X11 top to bottom, and how their disk device driver works. For almost everyone, this simply isn't true. How many web designers, or even communications applications writers, know -- to the specification level -- how TCP/IP works? How many non-commo programmers?
The point is that sometimes you need to know a _little bit_ about the place where the abstraction can leak. You don't need to know the lower layer exhaustively. A truly competant C programmer may need to know a bit about the architecture of their platform (or not -- it's better to write portable code) but they surely do not need to be a competant assembly programmer. A competant web designer may need to know something about HTML, but not the full intricacies of it. And so forth.
Yes, the abstractions leak. Sometimes you get around this by having one person who knows the lower layer inside and out. Sometimes you delve down into the abstraction yourself. And sometimes, you say that, if the form fails because it needs JavaScript and the user turned off JavaScript, it's the user's fault and mandate JavaScript be turned on -- in fact, a _good_ high-level tool would generate defensive code to put a message on the user's screen telling them that, in the absence of JavaScript, things will fail (i.e. the tool itself can save the programmer from the leaky abstraction).
What Ian Malcolm says, when you boil it all down, is that complex systems simply can't work in a sustained fashion. We have numerous examples which disprove the theory. That doesn't mean that we don't need to worry about failure cases, it means we overengineer and build in failsafes and error-correcting logic and so forth. What Joel Spolsky says is that you can't abstract away complexity because the abstractions leak. Again, there are numerous examples where we've done exactly that, and the abstraction has performed perfectly adequately for the vast majority of users. Someone needs to understand the complex part and maintain the abstraction -- the rest of us can get on with what we're doing, which may be just as complex, one layer up. We can, and do, stand on the shoulders of giants all the time -- we don't need to fully understand the giants to make use of their work.
One part of the improvement in 10.2(.1), though not all of it, is that the majority of the system is built with gcc 3.1 instead of 2.9.5. According to most sources (including the gcc team themselves), 3.1-generated code is roughly 6% or so faster than 2.9.5-generated code. Apple has made quite a number of performance improvements in gcc as well, which fold into code built for 10.2.
That said, I'm a Unix professional (kernel; device drivers, right now); have been for many years. My _entire_ professional life has been spent working on keyboards that have control on the lower left, and caps lock next to A. It is _entirely_ possible to use Unix with control in lower-right. I have small hands; I can still use control and not have any trouble reaching other keys. I'm currently typing this on an IBM keyboard that ships with RS/6000 workstations; control is in lower-left. My officemate's IBM PC-influenced keyboard (Windows key, etc) has control in lower-left; his Dell laptop has control in lower-left. One of my co-worker's IBM laptop? Control's in lower-left.
Control in lower-right is an ISO standard; Apple didn't come up with it because of any desire to spite Unix users.
Apple has been a Unix vendor for at least 14 years. Anyone remember A/UX? I do... loooong experience with it, including years as GNU ports maintainer when Apple was still persona non grata with the FSF. Anyone remember the workgroup servers running AIX? I wrote the serial driver. Any claim that Apple has been ignoring Unix users needs to take into account that Apple's been a Unix vendor for a very long time _and_ that they've now moved their entire platform to a Unix(/Mach)-based system.
I do sympathize with muscle memory -- my current laptop has a key to the left of control (fn, for those who're curious). It was a bit of pain getting my finger to shift over one position -- about a week's worth. After that, all's well. You may have harder to retrain muscle memory.
The most interesting part of the parent post is the reference to uControl. uControl remaps control to caps-lock _exactly_ the way the poster wants. It's free software (GPL). _If_ ADB were "broken-by-design" as claimed, uControl wouldn't be able to do this. If anyone wanted control -> caps lock remapping on the *BSD's, it shouldn't be hard to look at a piece of GPL'd software and figure out to, e.g., modify the X server to do the same thing.
It seems to me that the poster himself has presented two solutions, one for Debian and one for Apple's own Unix product, that would let him use Unix on an Apple laptop with control where he wants it (assuming they work, and comments indicate they do). Why should it matter if these products need to resort to kludges, horrible or otherwise -- do you _need_ to know how your keyboard-mapping software works to be able to type? Should you _care_ how it works, as long as the keys do what you want?
_Exactly_ what more do you expect Apple to do -- provide remapping software for *BSD? I understand that it might be nice for the builtin keyboard to be USB, but given that working solutions exist for two flavors of Unix, I don't really understand the urgency of a major hardware design change to fix a problem that it's already agreed has a ready fix available in software.
The only catch is that the included iTunes application only syncs _to_ the iPod, not _from_ it. This is a simple design decision, and hardly an unreasonable one. For example, iPhoto only syncs pictures _from_ a digital camera, not _to_ it. I can think of situations where it'd be nice to send pictures to a camera, but it's hardly common and they didn't choose to support it.
The point is, no one "Forced" a "no copy off the iPod". It's trivial to copy from the iPod. One included application doesn't copy from the iPod, that's it.
In that sense, the BSD layers of Mac OS X are roughly as free as GNU/Linux; you can get the code, use it without any grief (except the need to release changes you make should you distribute the resulting software), even sell a distribution based on the BSD layers of Mac OS X. What you _can't_ do is use Apple's proprietary code freely. A number of Linux distros do the same thing; the difference is that Apple's proprietary code represents the entire user-visable interface of Mac OS X, and therefore (to most users) the real value-add of the system.
It's also probably true to say that, while GNU/Linux does indeed dream about being free, Linux itself simply dreams about being a widely used OS (witness both Linus' activities and the desire of many in the Linux community to see it as a desktop capable of "squashing Microsoft"). Linus is quite comfortable with close-source code being used on top of Linux; it's a matter of conjecture whether he'd be comfortable with a close-source graphics environment taking over as the premiere Linux desktop, but there's no reason to automatically assume he wouldn't. Linux is the kernel; the reason it's GNU/Linux is because of the GNU tools. Replace them with a FreeBSD toolchain and a proprietary graphics subsystem and you don't have GNU/Linux nor the philosophical goal of freedom.
HP-PA, not Alpha. While, thanks to all the mergers, HPCompaq now owns the Alpha architecture, Itanium is more-or-less a strange VLIW descendant of HP-PA.
I'm not sure what advantage Itanium would have over PowerPC, for Apple. The main source of grief for Apple is that Motorola provides Altivec while IBM does not. However, Itanium doesn't provide anything particularly similar to Altivec either. For 32 and 64-bit non-Altivec, IBM makes very nice Power architecture (compatible with PowerPC for all reasonable purposes) chips with plenty of headroom to compete flat-out with Intel.
Given the amount of grief Apple would get from developers about porting applications _again_ to a hypothetical MacOS X-on-Intel (x86 or Itanium), I can't see that happening soon. Even if everything from Apple's side is seamless, a lot of developers would need to consider endianness, performance issues, etc. Also, you lose Carbon (MacOS APIs need work moving to a little-endian architecture) and Classic (unless there's a high-quality emulator built in).
Overall, there's plenty of headroom in PowerPC -- the issue is getting the chip vendors to push it to consumer parts that Apple can use. Their volumes are high enough (and growing) that there's motivation to do that. Any concerns about Motorola's committment aside, IBM _needs_ to keep developing Power-architecture parts for the foreseeable future. As long as they're designing them, why not spend a small delta to make a consumer-grade version and sell an extra couple million chips (compared to the 5-or-maybe-6-digit numbers they'll sell for iSeries and pSeries servers otherwise)?
Between those factors, I don't see MacOS moving to Intel. Apple is likely keeping it on a far-back burner for contingency purposes, but market realities make it the sort of thing you'd see if they were flailing on the verge of extinction and simply had nowhere else to go.
The fallacy to all of this is the assumption that designers are interested in _bigger_ bombs. Bigger bombs are easy; we've known for years how to build very big bombs. No one's interested.
Most of the work done on nuclear weapons at these labs falls into two categories: verifying that aging weapons still work (instead of testing them) as already mentioned, and designing new, _smaller_ bombs. Smaller bombs are considered more destabilizing by the anti-nuclear movement -- hence all the protestation. However, the general public doesn't see smaller as a threat, so the misconception that bomb designers have any interest in bigger bombs goes unchecked.
If you do the research, you'll find out that during the 80's, the number of nuclear weapons in the US arsenal went up several times, but the aggregate megatonnage went _down_ by a factor of 10. Weapons were converted to MIRV's, large bombs were discontinued entirely, and a number of smaller (field artillery, SAM supression, etc) weapons were added. Since the 80's, this trend has continued, though cutbacks in weapons production have curtained the trend.
Personally, my feeling is that the world is safer with the enormous decrease in megatonnage, even if smaller weapons slightly increase the liklihood some nuclear weapon will be used ("it's only a small bomb"). Smaller weapons are, as a general rule (easy to violate, but as a general rule) cleaner, more precise, and more likely to be used against a military target (missile launcher, ship, base) than indiscriminately against a large urban target. The problem with that is that it takes out the Mutual Assured Destruction doctrine; if neither side is losing cities, they might fight a limited nuclear war. I come down on the side that says MAD was useful, but lost relevance a long time ago -- and that it's better to be physically incapable of large-scale destruction than to be limited merely by the fear "they'll do it back to us!"