I don't know how to use a PC. Give me OSX or a CLI and I'm fine. But I only used a PC for the only two weeks I worked in a cube.
I worked in a mac-based office (not a design firm, a real office) and have done years of development exclusively on macs. My servers are OS X servers.
I do not know how to use a PC more than basic point and click. I have no idea what a DLL is.
It's a dylib.:-)
(Yes, you have them on OS X. Look for all the files named ".dylib" on your machine. You also have them on a pile of other UN*Xes - look for files named ".so" or ".so.{numbers}", unless you're on, for example, HP-UX, where they're ".sl", or AIX, where I think they're called ".a" even though they're not just archives.)
other countries (esp the ones that always show the highest test scores) let kids out of school as early as age 10 if they aren't suited to education
Could you please name the countries that 1) always show the highest test scores and 2) let kids out of school as early as age 10?
Finland is, as I remember, one of those high-scoring countries, but the Basic Education page at the Finnish National Board of Education site says "Basic Education means the general education provided for each age group in its entirety. It is intended for children from seven to sixteen years of age, and its completion in comprehensive school takes nine years."
Japan is another of the high-scoring countries; the US Library of Congress Country Studies information on Japan says under "Primary and Secondary Education" that, at least as of 1994, "Education is compulsory and free for all schoolchildren from the first through the ninth grades" and a diagram in the report (PDF) indicates that this runs up to age 14. (The page on "Upper-Secondary Education" indicates that, even after age 14, "94 percent of all lower-secondary school graduates entered uppersecondary schools in 1989".)
The first such articles complains of the censorship of operation clambake but googling on "clambake": first result: "Operation Clambake - The Inner Secrets of Scientology"
Heck, Googling on "scientology" turns up Operation Clambake as the second result.
So, the problem with Network neutrality is that it opens up the DSL and Cable providers up to competition for their other service, and that'a a big disincentive for them to roll it out.
So how is this handled in other countries? Do any other countries require network neutrality on the part of circuit providers (i.e., providers of raw pipes to the customer) or ISPs (who could be the same entity as the raw pipe provider, or could be somebody buying raw pipe capacity)? If so, how has that affected the rollout of broadband services?
Googling for
crtc "network neutrality"
found this Toronto Star piece by Michael Geist, which argues in favor of Canada adopting a policy requiring network neutrality (and says that one telco, Telus, brieftly blocked access by its customers to a Web site set up by a union with which it was having a dispute), so I presume there was, at least at that time, no regulatory requirement for network neutrality in Canada.
Googling for
europe "network neutrality"
found other pieces by Michael Geist, which indicate that some European carriers are blocking VoIP traffic, so I assume there's no regulatory requirement for network neutrality in the countries in which they're doing that.
On the other hand, Googling for
france "network neutrality"
found a piece by Lawrence Lessig arguing that France and Japan offer better high-speed broadband than is available in the US (which might even be true in areas of comparable housing density) and required "strict unbundling", which Lessig describes as even more stringent than network neutrality.
So a quick Google found no obvious single conclusion about this issue. I'd be curious to see what people who aren't strong advocates of either position have to say about the raw(er) data.
Do you mean to say that HTML, CSS, JavaScript, JPEG, GIF, PNG, Flash, and PDF aren't safe?
Unless it's run in a sufficiently restrictive sandbox, and is limited in its abilities to interact with the user (e.g., no popping up dialog boxes that look like standard system dialog boxes asking for your password), no, JavaScript is not safe. I don't know how powerful Flash is, so I don't know whether it's unsafe. The others might be safe (assuming no buffer-overflow or other such vulnerabilities in the code to process them).
That's funny, it seems that most browsers will open these types of files on the fly, without asking the user's permission.... so maybe some files ARE "safe".
He said "The user should always make an explicit request to open any file not handled by the browser itself."
If it only offered "Yes" and "No", what would you click when you didn't want to exit at all?
The button in my mail reader that sends a message - in particular, a message to the "report a bug/deficiency here" address for the application in question - or the button in my mail browser to submit such a bug; if it only offered "Yes" and "No", that'd be a deficiency.
"Yes", "No", and "Cancel" might be an improvement, but the human interface guidelines for the desktop I referred tosuggest that "Button names should correspond to the action the user performs when pressing the button--for example, Erase, Save, or Delete", so "Don't Save", "Cancel", and "Save" are even more of an improvement.
Write button labels as imperative verbs, for example Save, Print. This allows users to select an action with less hesitation. An active phrase also fits best with the button's role in initiating actions, as contrasted with a more passive phrase. For example Find and Log In are better buttons than than Yes and OK.
so "Yes" and "No" aren't the labels that should be used in most GNOME alert boxes. I'd say they aren't the labels that should be used in most alert boxes in any GUI; the KDE User Interface Guidelinesmake that suggestion:
Although Yes-No questions have an appealing simplicity, they do have a downside. While the implications of the Yes answer are usually very clear, the implications of the No answer are often not clear at all. The question "Do you want to save your changes?" serves as a good example. Pressing "Yes" will get the changes saved, but what happens when the user presses the "No" button? Rephrasing the question as an Either-Or question will help make this more clear: "Do you want to save or discard your changes?". Now there can be buttons labeled "Save" and "Discard", and the consequences of both are equally clear.
One could debate which of the Macintosh/GNOME convention of "affirmative button on the right" and the Windows convention of "OK as the default button and default button on the left" is better (and perhaps the Windows convention is "better" by virtue of being the one familiar to more people), but neither of them are something done by "NO ONE ELSE ON THE PLANET".
I'd also love to know why they decided that the proper order for buttons is "No/Yes". I just love how NO ONE ELSE ON THE PLANET orders things that way
Yeah, the desktop I use on my main UN*X machines has the buttons for the "Do you want to save changes to this document before closing?" dialog in the order "Don't Save", "Cancel", and "Save", rather than "Yes" and "No" or "No" and "Yes". Similarly, the buttons for "Are you sure you want to remove the items in the Trash permanently?" are in the order "Cancel" and "OK", rather than "Yes" and "No" or "No" and "Yes".
They have POWER chips in them, which is something (almost) completely different.
The System i5's and System p5's do. Previous iSeries machines had processors that IBM at least touted as being PowerPC-based (although they had the AS/400 extensions, and weren't merchant-market PowerPC chips), and at least some RS/6000 and perhaps pSeries machines did user PowerPC processors (in the sense of merchant-market PowerPC chips rather than chips IBM only makes available in their own hardware).
Instruction-set-wise, I don't think IBM sell any machines any more that have processors that implement the POWER or POWER2 instruction set but lack all the PowerPC additions, so they all implement, at least at user level, the full PowerPC instruction set.
Now why they went with a 32bit Intel part is still a mystery to me. 32bit processors are so last millenium....
There are two parts to that question: "...went with a 32-bit part" and "...went with an Intel part".
I have no information on why Intel was chosen. Plenty of people probably have their own theories about that.
Once Intel was chosen, however, at least for the MacBook Pro, a 32-bit part was the obvious choice if you don't want a Pentium 4 (e.g., too much power, too much heat) and want to ship machines before Merom ships; it's not as if the PowerBooks were 64-bit.
The iMac might not have the same power and heat concerns, and the previous version was already 64-bit, so perhaps a case could've been made for using an EM64T P4 there. I'm not a hardware or business guy, though, so I'm not sure whether that would've made sense or not.
Now in true Intel fashion, I don't just want to tell you about these
products. I'd like to show it to you. I'm happy to say that the silicon
from these three products is really running very, very well. In fact, so
well that this presentation today has been running on this [Merom]-
based notebook. Let me show you what we've got here. You'll see the
presentation there. Let me minimize that. In this chart here we have
performance monitor. You can see it's got two cores, two processors
running. Over here you can see it's a Windows 64-bit edition, so we've
enabled the 64-bit extensions, dual-core, and perfect compatibility.
We've also got a second product called Conroe. Conroe is a desktop
product, and this one, in this case, is running in a [reference] platform
here. And it's running Fedora Linux 64. And there's a third product
here called Woodcrest, which is a server product. It's actually in a DP
- a dual processor configuration, and if you look up at the performance
monitor here, what is showing is that it's essentially four cores
running. So two processors, two cores each...
showing 64-bit OSes running on Merom and Conroe prototype boxes), so any Macs with next-generation x86's will have 64-bit processors.
I work in a world where a variation of the PowerPC drives a business. From iSeries (AS/400 new name) to xSeries and eventually the pSeries.
I doubt you have many PowerPC processors in any xSeries machines you have.:-)
(That's the name for the x86-based servers; iSeries/System i5/whatever IBM marketing is calling it this week and pSeries/System p5/whatever IBM marketing is calling it this week do have PowerPC in them.)
The operating system automagically retranslated everything to the new processor architecture when you restored your old software on the new hardware.
Or, rather, automatically generated PowerPC code from the "machine-independent" code for the software, just as IMPI code had been generated from the MI code to make it run on the old CISC systems. (Or was there direct IMPI-to-PowerPC-AS translation involved as well?)
if you draw the line-of-best-fit for Google's actions over the next few years, you will find it fits the function of self-interest.
And a company offering a search engine might be likely to have its search engine used more if it's perceived as being more trustworthy, i.e. if searching for something is likely to give you, at the top of the list of results, "better" hits rather than hits on pages the maintainer of which has rigged to show up first.
I.e., a premise of "they're doing it because it's better for Google" doesn't ipso facto mean "they're screwing the user".
And the major security feature of the NX bit doesn't seem to be being backported to 32-bit archtectures.
"Backported" to the processors, or "backported" to the 32-bit versions of the OSes? According to the Intel® Centrino® Duo Mobile Technology Performance Brief, the 32-bit Core Duo has the NX bit (or, as Intel calls it, the XD, or Execute Disable, bit).
But, as you note, the recently-released Core Duo and Core Solo might be the last new 32-bit-only x86 processors from Intel; as far as I know, Merom and its siblings are all 64-bit.
The only "tangible" advantage is the ability to manage more system RAM.
More easily manage more system RAM. Plenty of processors with 32-bit registers and pointers support more than 4GB of main memory; they just make it hard for a single process to use more than 4GB (it'd have to map stuff in and out of the address space).
According to prior posters, the IRS's system was implemented back in the early 70s. IIRC, 32-bit processors were still a long way coming at that point
YDRC. 32-bit microprocessors might have been a long way coming, but, at that point, mainframes were 32-bit (e.g., S/360 and S/370), 36-bit (e.g., Univac), or whatever the Burroughs machines were if you ignore the tag bits (48-bit, I think).
Also, they might have used decimal rather than binary, in which case the word length wouldn't have mattered.
Now, perhaps the problem is software, but the software problem might have been due to the author of the tax-processing software not bothering to do multiprecision arithmetic, or the compiler developers not bothering to provide it.
Or it might have been due to the software having been developed in a time when income, etc. levels were an inflationary factor of N away from current levels.
Or it might just have been Gates oversimplifying, or of somebody mishearing what he heard (the quotation marks in the article nonwithstanding).
if you stop and think long enough to remember that visible light is part of the EM spectrum too
So's ultraviolet light.
Heck, so are gamma rays. Did Gen. Thaddeus Ross contribute to the original paper? And are they prepared to deal with the possible consequences of a gamma bomb?
(The authors of the paper probably either thought of "the electromagnetic spectrum" as meaning "radio frequencies" or decided to oversimplify for the benefit of an audience most of whose members either never took electricity and magnetism in college or forgot it.)
And how is going to church "right-wing brainwashing?" I haven't gone to a church that used Milton Friedman and Hayek books as a Bible and preached the virtures of free-markets. Do you even understand what right-wing means?
By citing the Wikipedia article on "Right-wing", are you endorsing its idea of what "right-wing" means? If so, then presumably you consider the relgious right to be part of the "right wing", given that said article says
In politics, right-wing, the political right, or simply The Right, are terms that refer to the segment of the political spectrum typically associated with any of several strains of conservatism, classical liberalism, the religious right;...
(emphasis mine). Hayek and Friedman are probably best thought of as being in the "classical liberalism" strain (the Wikipedia article on classical liberalism, at least, mentions both of them as modern "classical liberals"); M. Hogger was probably referring to the "religious right" strain.
That doesn't mean it can't be/is not "more CISC-like" than the P4.
One thing it does mean is that it has the same "translate to micro-ops" notion that the P4 does, and that's what the person to whom you were responding was talking about, so, given his view of what's "RISC-like", the PPro, not the P4, was the first of the "RISC-like" x86 processors from Intel (i.e., he was not describing only NetBurst, he was describing the way the P6, NetBurst, and Pentium M microarchitectures all work).
As far as I'm concerned, processors aren't "RISC-like" or "CISC-like", instruction sets are. The x86 instruction set isn't RISC, given that it has complicated instructions such as CALL (especially in its full generality, even if that's not much used), and given that it has memory-reference arithmetic instructions.
However, in recent implementations of x86 from Intel and AMD, the execution engine processes micro-operations that are perhaps at the same level of complexity as RISC instructions, so that techniques used to do superscalar and out-of-order execution of RISC instruction sets can be used (or used more straightforwardly) internally on those micro-operations. If those micro-operations form an instruction set, one could perhaps think of that instruction set as a RISC instruction set, but you can't program the processor in that instruction set, so it's not the native instruction set of the processor (and Intel probably doesn't guarantee that the set of micro-ops, or the way they're represented internally in the processor, will remain the same from processor to processor).
So, while I might say that the Pentium Pro and subsequent x86 chips from Intel, and the Nx586 and the K6 and subsequent chips from AMD, have internal implementations similar to those of superscalar OOO RISC processors, I wouldn't say they're "RISC-like" - especially if I were, as the person to whom you're replying appears to have been doing, trying to respond to a claim that Apple "said... CISC processors sucked until they switched to them" by saying "well, they still suck - x86 processors are now RISC". Intel didn't change the core x86 instruction set (other than adding conditional move and some other instructions) when they went from Pentium to Pentium Pro, they just changed the implementation technique.
The "CISC sucks, RISC rules" arguments were, at least as I remember them, arguments that implementations of CISC instruction sets were doomed to be slower than implementations of RISC instruction sets (assuming they even had that level of technical detail - how much detail did the infamous "CISC vs. RISC" graph ad have?), due to the nature of CISC and RISC. Perhaps it's just that the size of the market for chips that execute the x86 instruction set allowed Intel to throw cubic dollars at the problem and close the gap, the claims about the nature of CISC and RISC nonwithstanding.
No, it's not. The distinction is between the way the P6 and subsequent x86 cores from Intel (and the NexGen Nx586 and subsequent x86 cores from the company that bought NexGen, AMD) implement the CISC x86 instruction set, i.e. by carving instructions into micro-ops and executing the micro-ops mainly in hardware as individual operations, and the way the microcoded S/360's implemented the CISC S/360 instruction set, i.e. by using the opcode to dispatch to a routine in microcode.
The first is sort of like binary-to-binary translation; the latter is like interpretation.
or it to deserve an exclamation point.
To what exclamation point are you referring? There was none in my posting (there was one in the subject line of the posting to which I responded, but I didn't put that one there, so I wasn't the one who decided that something deserved an exclamation point).
I'm not saying that modern chips are exactly the same as microcode in previous generations; I'm saying that the notion that it's not a complex instruction set because it's decoded into a simple instruction set is mistaken.
Then why bring up the S/360's? They didn't decode S/360 instructions into a simpler instruction set; the microcoded ones implemented them as something like calls to routines in a lower-level instruction set - they didn't have a decoder that generated streams of microinstructions on the fly.
The real point is that "CISC" and "RISC" are terms that apply to the instruction set architecture, independent of implementation. The latest shiniest x86 processors execute a "core" instruction set (leaving all the SIMD stuff out) that's very similar to that of the 80386; you don't get access to, for example, the full set of hardware registers used for register renaming, or the micro-ops, so you can't generate code for the "micro-op machine". The micro-op scheme might allow similar implementation techniques to those used in fancy superscalar and OOO RISC processors to be more easily used on CISC processors, but, as you note, that doesn't turn them into RISC processors, because the native instruction set, i.e. the one the processor fetches from memory and runs, isn't RISC. That's the way to make the point that modern x86 chips are still CISC processors.
Slashdot Mirror
How about a mutation that results in a decreased risk of arteriosclerosis, heart attack, and stroke?
It's a dylib. :-)
(Yes, you have them on OS X. Look for all the files named ".dylib" on your machine. You also have them on a pile of other UN*Xes - look for files named ".so" or ".so.{numbers}", unless you're on, for example, HP-UX, where they're ".sl", or AIX, where I think they're called ".a" even though they're not just archives.)
Could you please name the countries that 1) always show the highest test scores and 2) let kids out of school as early as age 10?
Finland is, as I remember, one of those high-scoring countries, but the Basic Education page at the Finnish National Board of Education site says "Basic Education means the general education provided for each age group in its entirety. It is intended for children from seven to sixteen years of age, and its completion in comprehensive school takes nine years."
Japan is another of the high-scoring countries; the US Library of Congress Country Studies information on Japan says under "Primary and Secondary Education" that, at least as of 1994, "Education is compulsory and free for all schoolchildren from the first through the ninth grades" and a diagram in the report (PDF) indicates that this runs up to age 14. (The page on "Upper-Secondary Education" indicates that, even after age 14, "94 percent of all lower-secondary school graduates entered uppersecondary schools in 1989".)
Yes. (Well, modulo tachyons, which would have a non-zero but imaginary rest mass.)
So color symmetry is broken?
Heck, Googling on "scientology" turns up Operation Clambake as the second result.
So how is this handled in other countries? Do any other countries require network neutrality on the part of circuit providers (i.e., providers of raw pipes to the customer) or ISPs (who could be the same entity as the raw pipe provider, or could be somebody buying raw pipe capacity)? If so, how has that affected the rollout of broadband services?
Googling for
found this Toronto Star piece by Michael Geist, which argues in favor of Canada adopting a policy requiring network neutrality (and says that one telco, Telus, brieftly blocked access by its customers to a Web site set up by a union with which it was having a dispute), so I presume there was, at least at that time, no regulatory requirement for network neutrality in Canada.
Googling for
found other pieces by Michael Geist, which indicate that some European carriers are blocking VoIP traffic, so I assume there's no regulatory requirement for network neutrality in the countries in which they're doing that.
On the other hand, Googling for
found a piece by Lawrence Lessig arguing that France and Japan offer better high-speed broadband than is available in the US (which might even be true in areas of comparable housing density) and required "strict unbundling", which Lessig describes as even more stringent than network neutrality.
However, it also found this blog item on the Progress and Freedom Foundation site, citing arguments before congress that a key point, at least in the case of France, was that "France operated in a monopoly environment".
So a quick Google found no obvious single conclusion about this issue. I'd be curious to see what people who aren't strong advocates of either position have to say about the raw(er) data.
Unless it's run in a sufficiently restrictive sandbox, and is limited in its abilities to interact with the user (e.g., no popping up dialog boxes that look like standard system dialog boxes asking for your password), no, JavaScript is not safe. I don't know how powerful Flash is, so I don't know whether it's unsafe. The others might be safe (assuming no buffer-overflow or other such vulnerabilities in the code to process them).
He said "The user should always make an explicit request to open any file not handled by the browser itself."
The button in my mail reader that sends a message - in particular, a message to the "report a bug/deficiency here" address for the application in question - or the button in my mail browser to submit such a bug; if it only offered "Yes" and "No", that'd be a deficiency.
"Yes", "No", and "Cancel" might be an improvement, but the human interface guidelines for the desktop I referred to suggest that "Button names should correspond to the action the user performs when pressing the button--for example, Erase, Save, or Delete", so "Don't Save", "Cancel", and "Save" are even more of an improvement.
The GNOME Human Interface Guidelines make a similar suggestion:
so "Yes" and "No" aren't the labels that should be used in most GNOME alert boxes. I'd say they aren't the labels that should be used in most alert boxes in any GUI; the KDE User Interface Guidelines make that suggestion:
One could debate which of the Macintosh/GNOME convention of "affirmative button on the right" and the Windows convention of "OK as the default button and default button on the left" is better (and perhaps the Windows convention is "better" by virtue of being the one familiar to more people), but neither of them are something done by "NO ONE ELSE ON THE PLANET".
Yeah, the desktop I use on my main UN*X machines has the buttons for the "Do you want to save changes to this document before closing?" dialog in the order "Don't Save", "Cancel", and "Save", rather than "Yes" and "No" or "No" and "Yes". Similarly, the buttons for "Are you sure you want to remove the items in the Trash permanently?" are in the order "Cancel" and "OK", rather than "Yes" and "No" or "No" and "Yes".
LGPL, as noted in another reply.
Because non-free software can be linked with LGPL software without having to be made free.
The System i5's and System p5's do. Previous iSeries machines had processors that IBM at least touted as being PowerPC-based (although they had the AS/400 extensions, and weren't merchant-market PowerPC chips), and at least some RS/6000 and perhaps pSeries machines did user PowerPC processors (in the sense of merchant-market PowerPC chips rather than chips IBM only makes available in their own hardware).
Instruction-set-wise, I don't think IBM sell any machines any more that have processors that implement the POWER or POWER2 instruction set but lack all the PowerPC additions, so they all implement, at least at user level, the full PowerPC instruction set.
There are two parts to that question: "...went with a 32-bit part" and "...went with an Intel part".
I have no information on why Intel was chosen. Plenty of people probably have their own theories about that.
Once Intel was chosen, however, at least for the MacBook Pro, a 32-bit part was the obvious choice if you don't want a Pentium 4 (e.g., too much power, too much heat) and want to ship machines before Merom ships; it's not as if the PowerBooks were 64-bit.
The iMac might not have the same power and heat concerns, and the previous version was already 64-bit, so perhaps a case could've been made for using an EM64T P4 there. I'm not a hardware or business guy, though, so I'm not sure whether that would've made sense or not.
In any case, as the next-generation x86 chips from Intel will be 64-bit (if Paul Otellini wasn't lying in his presentation at the Intel Developer Forum, where he said
showing 64-bit OSes running on Merom and Conroe prototype boxes), so any Macs with next-generation x86's will have 64-bit processors.
I doubt you have many PowerPC processors in any xSeries machines you have. :-)
(That's the name for the x86-based servers; iSeries/System i5/whatever IBM marketing is calling it this week and pSeries/System p5/whatever IBM marketing is calling it this week do have PowerPC in them.)
Or, rather, automatically generated PowerPC code from the "machine-independent" code for the software, just as IMPI code had been generated from the MI code to make it run on the old CISC systems. (Or was there direct IMPI-to-PowerPC-AS translation involved as well?)
And a company offering a search engine might be likely to have its search engine used more if it's perceived as being more trustworthy, i.e. if searching for something is likely to give you, at the top of the list of results, "better" hits rather than hits on pages the maintainer of which has rigged to show up first.
I.e., a premise of "they're doing it because it's better for Google" doesn't ipso facto mean "they're screwing the user".
"Backported" to the processors, or "backported" to the 32-bit versions of the OSes? According to the Intel® Centrino® Duo Mobile Technology Performance Brief, the 32-bit Core Duo has the NX bit (or, as Intel calls it, the XD, or Execute Disable, bit).
But, as you note, the recently-released Core Duo and Core Solo might be the last new 32-bit-only x86 processors from Intel; as far as I know, Merom and its siblings are all 64-bit.
More easily manage more system RAM. Plenty of processors with 32-bit registers and pointers support more than 4GB of main memory; they just make it hard for a single process to use more than 4GB (it'd have to map stuff in and out of the address space).
YDRC. 32-bit microprocessors might have been a long way coming, but, at that point, mainframes were 32-bit (e.g., S/360 and S/370), 36-bit (e.g., Univac), or whatever the Burroughs machines were if you ignore the tag bits (48-bit, I think).
Also, they might have used decimal rather than binary, in which case the word length wouldn't have mattered.
Now, perhaps the problem is software, but the software problem might have been due to the author of the tax-processing software not bothering to do multiprecision arithmetic, or the compiler developers not bothering to provide it.
Or it might have been due to the software having been developed in a time when income, etc. levels were an inflationary factor of N away from current levels.
Or it might just have been Gates oversimplifying, or of somebody mishearing what he heard (the quotation marks in the article nonwithstanding).
Or it might just have been somebody making something up; that's not exactly unheard of.
Probably not, for the reasons stated, just as I don't expect another company to get rid of its "NS" prefix in its code to sever itself from that code's history.
So's ultraviolet light.
Heck, so are gamma rays. Did Gen. Thaddeus Ross contribute to the original paper? And are they prepared to deal with the possible consequences of a gamma bomb?
(The authors of the paper probably either thought of "the electromagnetic spectrum" as meaning "radio frequencies" or decided to oversimplify for the benefit of an audience most of whose members either never took electricity and magnetism in college or forgot it.)
...and SonyEricsson make handsets rather than CO equipment in any case.
By citing the Wikipedia article on "Right-wing", are you endorsing its idea of what "right-wing" means? If so, then presumably you consider the relgious right to be part of the "right wing", given that said article says
(emphasis mine). Hayek and Friedman are probably best thought of as being in the "classical liberalism" strain (the Wikipedia article on classical liberalism, at least, mentions both of them as modern "classical liberals"); M. Hogger was probably referring to the "religious right" strain.
One thing it does mean is that it has the same "translate to micro-ops" notion that the P4 does, and that's what the person to whom you were responding was talking about, so, given his view of what's "RISC-like", the PPro, not the P4, was the first of the "RISC-like" x86 processors from Intel (i.e., he was not describing only NetBurst, he was describing the way the P6, NetBurst, and Pentium M microarchitectures all work).
As far as I'm concerned, processors aren't "RISC-like" or "CISC-like", instruction sets are. The x86 instruction set isn't RISC, given that it has complicated instructions such as CALL (especially in its full generality, even if that's not much used), and given that it has memory-reference arithmetic instructions.
However, in recent implementations of x86 from Intel and AMD, the execution engine processes micro-operations that are perhaps at the same level of complexity as RISC instructions, so that techniques used to do superscalar and out-of-order execution of RISC instruction sets can be used (or used more straightforwardly) internally on those micro-operations. If those micro-operations form an instruction set, one could perhaps think of that instruction set as a RISC instruction set, but you can't program the processor in that instruction set, so it's not the native instruction set of the processor (and Intel probably doesn't guarantee that the set of micro-ops, or the way they're represented internally in the processor, will remain the same from processor to processor).
So, while I might say that the Pentium Pro and subsequent x86 chips from Intel, and the Nx586 and the K6 and subsequent chips from AMD, have internal implementations similar to those of superscalar OOO RISC processors, I wouldn't say they're "RISC-like" - especially if I were, as the person to whom you're replying appears to have been doing, trying to respond to a claim that Apple "said ... CISC processors sucked until they switched to them" by saying "well, they still suck - x86 processors are now RISC". Intel didn't change the core x86 instruction set (other than adding conditional move and some other instructions) when they went from Pentium to Pentium Pro, they just changed the implementation technique.
The "CISC sucks, RISC rules" arguments were, at least as I remember them, arguments that implementations of CISC instruction sets were doomed to be slower than implementations of RISC instruction sets (assuming they even had that level of technical detail - how much detail did the infamous "CISC vs. RISC" graph ad have?), due to the nature of CISC and RISC. Perhaps it's just that the size of the market for chips that execute the x86 instruction set allowed Intel to throw cubic dollars at the problem and close the gap, the claims about the nature of CISC and RISC nonwithstanding.
No, it's not. The distinction is between the way the P6 and subsequent x86 cores from Intel (and the NexGen Nx586 and subsequent x86 cores from the company that bought NexGen, AMD) implement the CISC x86 instruction set, i.e. by carving instructions into micro-ops and executing the micro-ops mainly in hardware as individual operations, and the way the microcoded S/360's implemented the CISC S/360 instruction set, i.e. by using the opcode to dispatch to a routine in microcode.
The first is sort of like binary-to-binary translation; the latter is like interpretation.
To what exclamation point are you referring? There was none in my posting (there was one in the subject line of the posting to which I responded, but I didn't put that one there, so I wasn't the one who decided that something deserved an exclamation point).
Then why bring up the S/360's? They didn't decode S/360 instructions into a simpler instruction set; the microcoded ones implemented them as something like calls to routines in a lower-level instruction set - they didn't have a decoder that generated streams of microinstructions on the fly.
The real point is that "CISC" and "RISC" are terms that apply to the instruction set architecture, independent of implementation. The latest shiniest x86 processors execute a "core" instruction set (leaving all the SIMD stuff out) that's very similar to that of the 80386; you don't get access to, for example, the full set of hardware registers used for register renaming, or the micro-ops, so you can't generate code for the "micro-op machine". The micro-op scheme might allow similar implementation techniques to those used in fancy superscalar and OOO RISC processors to be more easily used on CISC processors, but, as you note, that doesn't turn them into RISC processors, because the native instruction set, i.e. the one the processor fetches from memory and runs, isn't RISC. That's the way to make the point that modern x86 chips are still CISC processors.