I'm curious how much recognizably-AT&T-derived code is in the current commercial UNIXes; probably more than in Linux distributions, but it might not be as much more than people think. UNIX's legacy is more the APIs and command-line interface than the actual code, and Linux has that stuff.
I remember the first time I saw Unix, in 1976. The first step in installing it was to compile the C compiler (supplied IIRC in PDP-11 assembler)
As I remember, and as the "SETTING UP UNIX - Sixth Edition" document says (see the start *roff document in this V6 documentation tarball - yes, I know, tarballs are an anachronism here:-)), V6 came in a binary distribution that you read from a 9-track tape onto a disk:
If you are set up to do it, it might be a good idea immediately to make a copy of the disk or tape to guard against disaster. The tape contains 12100 512-byte records followed by a single file mark; only the first 4000 512-byte blocks on the disk are significant.
The system as distributed corresponds to three fairly full RK packs. The first contains the binary version of all programs, and the source for the operating system itself; the second contains all remaining source programs; the third contains manuals intended to be printed using the formatting programs roff or nroff. The `binary' disk is enough to run the system, but you will almost certainly want to modify some source programs.
You didn't have to recompile anything (at least not if you had more than 64KB; I had to do some hackery with the assembler to get it to run on a 64KB machine, as there wasn't enough memory to run the C compiler - I had to stub out the pipe code with an assembler-language replacement for pipe.c, and then recompile the kernel with a smaller buffer cache and the regular pipe code). Most users probably either had to or had good reasons to recompile the kernel (different peripherals, more memory for the buffer cache - or less memory in my case, so I had to shrink it from 8 whole disk blocks to 6 - etc.), and if you weren't in the US eastern time zone or didn't have daylight savings time you had to change ctime.c, or whatever it was called, in the C library for your time zone, recompile the C library, and then rebuild all utilities with the new C library (no Olson code and database, no shared libraries, no environment variables so no TZ environment variable).
All major processors except Itanium use microcode, including most ARM implementations. It's not an x86-specific thing.
The second sentence is true. The first one, well, do you consider SPARC and Power Architecture processors to be "major processors"? If so, where's a citation to indicate that they use microcode? Even if not, where's a citation to indicate that most ARM processors use microcode?
Also, what "run RISC cores with shenanigans wrapped around to implement the x86 legacy" means is that, on at least some modern x86 processors (dunno about Atom, but Intel's other processors since Pentium Pro, as well as, I think, all AMD processors since the K5), the x86 instructions are decoded into one or more presumably-RISCy "microoperations" which are what are scheduled and executed by the execution units. Some of them might be implemented with "microcode" in the sense of microoperations fetched from a ROM rather than generated on the fly by the decoder.
Limited Transistor counts and physical limitations of die size to start. Much of the current x64 chip is just to keep legacy x86 shit running.
[Citation needed]. At least going by area on the chip, a significant amount on a quad-core Sandy Bridge processor goes to graphics and memory and I/O access and to the shared L3 cache. How many transistors go to, for example, support for segmentation and references to AH and AL and so on? If you're talking about "legacy" in the sense of stuff x86-64 keeps around because it's in the x86 family, rather than its support for 32-bit code, that's another matter - but that's not an issue of being a chip with support for 32-bit code, it's an issue of being a chip with support for x86 CISC code. A reasonably clean 32-bit architecture could, I suspect, be extended to 64 bits without a lot of transistors lost to support for 32-bit code as well.
You're talking Windows 7 x64, which is just x86 extended a bit. What I'm talking about is 64 bit Chip, not x86 with 64bit extensions, and all the baggage that comes with it.
If "a 64-bit chip" is a chip with an instruction set that's not derived from an earlier 32-bit instruction set, why do we "need" such a chip? What problems does the "baggage" of 32-bit instruction set support that all x86-64 chips, all 64-bit PowerPC chips, all 64-bit SPARC chips, all 64-bit MIPS chips, all PA-RISC 2.0 chips, and all z/Architecture chips have, and that future ARMv8 chips will have (look for "Allows AArch32 applications under AArch64 OS Kernel" in the ARMv8 presentation), cause that are so severe that we "need a whole class of computers designed and built for 64bit architectures", with "64bit architectures" being those that lack that "baggage" (and thus meaning "IA-64" at this point, unless you know of a plain to resuscitate Alpha)?
And why would that require "a complete redesign" of Windows, rather than a rewrite of the low-level platform support code and a new compiler for the new architecture, given that, for example, Windows did support IA-64, and supported it as a 64-bit architecture (unlike its old support for Alpha with a 32-bit address space and 32-bit pointers)?
The Pentium Pro wasn't the *last* of Intel's "real" x86 processors, it was the *first* of the RISC-with-x86-wrapper (*) designs that make up all chips today. AFAIK the original Pentium line was the last.
The poster to whom you're responding said
When the Pentium 4 came out, it was frequently called the "7th generation", but it was never called the 786 or 80786, either formally or informally. Sure, it's just naming conventions, but that's exactly what x86 is about, it's about a trend in naming conventions.
in which case the last "x86 processor" was the 80486 - the Pentium wasn't sold as the 80586, it was sold as the Pentium.
And, given that the internal microops in Pentium Pro and later are not exposed to programs running on the processor, it's irrelevant to a discussion of whether those chips are "real" x86's or not. About the only processors where the question could reasonably be raised as to whether they're "really" x86 or not were the Transmeta chips, where an x86 interpreter and x86-to-native-code translator were, presumably, written in or compiled to the native instruction set and ran from, as I remember, a reserved chunk of main memory.
x64 is an extension to x86. What we need a a whole new class of computers designed and built for 64bit architectures.
How would "[designing] and [building]" a computer "for 64bit architectures" differ from what's being done now?
But that calls for a complete redesign of the most popular OS
I know of no desktop, notebook, or server OSes that would need "a complete redesign" to work on 64-bit architectures - they already work on them; presumably whatever would make the "whole new class of computers" different from the 64-bit computers being sold now is what would require that "complete redesign".
Can we just agree that a huge number of articles on Slashdot, period, are flamebait by default?
Your "flamebait" is my "topical", "interesting" and "discussion-worthy".
It is a sad world-view that sees any topic that engenders a lot of comments, even argument as necessarily "flamebait".
A topic that engenders comments and argument based on facts isn't flamebait. A topic that engenders comments from, for example Apple haters who assert that the only reason anybody buys Apple products is that they're idiots bedazzled by shiny objects or that the only reason anybody doesn't like {Macs, iPhones/iPads/etc. Mac OS X, iOS} is that they Just Don't Get It, not so much.
Can we just agree that Apple hardware articles are flamebait by default, especially the ones about the mere possibility of new Apple hardware, and stop frickin posting them?
Can we just agree that a huge number of articles on Slashdot, period, are flamebait by default? Anything that mentions {Apple,Microsoft,the Linux community,BSD} will probably get the usual pile of shouting from both sides, anything that mentions global warming will probably get the usual pile of shouting from both sides, anything about Gummint {forcing people to do XXX, nudging people to do XXX, refusing to give money to people who don't do XXX, encouraging people to do XXX} will probably get the usual pile of shouting from both sides, anything about the RIAA/MPAA will probably get the usual pile of shouting (mostly against the RIAA/MPAA in this case),, etc., etc., etc..
All x86 processors are CISC (regardless of whether they internally turn the instructions into sequences of 1 or more RISCy micro-ops and schedule and execute those independently).
should be called Pentiums
Presumably meaning "Only 32-bit x86 CPUs should be called Pentiums", as you presumably don't intend to call the 80386 and 80486 Pentiums.
(Not that Intel's marketing department has any good reason whatsoever to care what any of us think is the proper use for their "Pentium" brand.)
Because the ageing pentium architecture was a mess, and they needed to redesign from scratch for the Core 2 architecture - which was a great improvement. They stopped using the pentium brand because they stopped selling chips with any pentium-based technology in.
What is the "Pentium architecture"? The microarchitecture of the original Pentium (P5) was different from the microarchitecture of the Pentium Pro/Pentium II/Pentium III (P6), and P6 was different from the microarchitecture of the Pentium 4 (NetBurst), and NetBurst was different from the microarchitecture of the Pentium M (which was, I think, P6-derived). The microarchitecture of the Core 2 (Core) was, I think, Pentium M-derived.
So there's Pentium-the-chip (P5), and there's Pentium-the-brand, which was first used with the P5 chip but was also used with chips with significantly different microarchitectures from the P5 chip.
The Pentium 350 apparently uses the Sandy Bridge microarchitecture, along with a bunch of other microprocessors, some named Core, some named Xeon, some named Celeron, and some named Pentium. Some of the ones named Pentium were launched in Q3 2011, before the Pentium 350, so "Intel Breathes New Life Into Pentium" is, to use the technical term, a "complete bullshit headline".
Do you know what all your icons represent, without the text there to help you?
Or, to put it another way, if your icon is incomprehensible without a tooltip or title, You're Doing It Wrong.
Now, maybe once you've learned that, for example, the small image of the man with his head up his ass represents "send message to upper management", it's easier to find the picture on the toolbar than to find the text on the toolbar if that's the function you're looking for. If that's the case, it'd be a small irony, as it'd be "text for the newbies, icons for the power users...".
Is this the same Apple that provided 68K emulation on their PowerPC systems so people could run their old apps on a completely new processor architecture?
Yes, and that's the same Apple that, for example, got rid of native PPC support in Snow Leopard so it wouldn't run on PPC Macs and got rid of 32-bit processor support in Lion so it wouldn't run on Macs with 32-bit x86 processors, so they have, in fact, dropped support for hardware platforms on at least two occasions (and the 68K emulation and PPC emulation were also dropped at various points).
Except that in most cases you can buy more X64 systems for the same price or less to compensate for the performance difference... Also you can use GPUs if that is beneficial for what your doing.
Or you can run Linux on a SPARC machine or a POWER machine or a z/Architecture machine. Itanium isn't your only high-end alternative to x86.
What about Apple?
Their OSs drop support for hardware platforms on a regular basis. (I know it's an Itanium discussion, but...)
Apple sell computers mainly to home computer users and some professionals; they don't sell enterprise-class servers, and I have the impression that "sorry, that machine you bought a few years ago has been kicked to the curb in our new release" might not go over as well in that market (although I also have the impression that "here's a shiny new release of our {OS, database, etc.}, you should upgrade to it right now" doesn't exactly go over well in that market, either).
The AMD64 has 16 64-bit registers, which is merely a logical next step from the 8 32-bit registers of the prior generation. According to Wikipedia: AMD64 still has fewer registers than many common RISC ISAs (which typically have 32–64 registers)
Except for one rather common RISC ISA, but that one's mainly used in stuff like mobile phones, not Big Honking Servers (although with ARM64 they're at least thinking about servers - it might be more "tons of blade processors" than "a smaller number of Big Honking Processor Engines", though).
TheAMD64 is not a "pure" 64-bit chip. It is a chip that operates in 64-bits but has an internal architecture that has not significantly changed since the days of the 4040.
Internal architecture, not instruction-set architecture? If you truly mean "internal architecture" in the sense of "implementation of the instruction set", do you really mean to say that a superscalar out-of-order pipelined processor that breaks instructions down into micro-operations and schedules the micro-operations is not "significantly changed" from an in-order one-instruction-at-a-time (and, I think, not even pipelined) processor that just fetches and executes instructions in sequence?
It has merely been scaled. Scaling is not engineering.
Presumably "is not engineering" is something other than "requires no engineering work to accomplish", unless you have a definition of "engineering" different from what I and I suspect a lot of processor designers have.
Which, as I understand it, is why HP partnered with Intel (not the other way around).
At the same time, they can convince HP to transition away from their existing RISC architectures (PA-RISC
Which, as I understand it, was HP's intent even before they got Intel involved.
and Alpha)
Which was, at the time the HP-Intel partnership was announced, DEC's RISC architecture - DEC hadn't even been bought by Compaq yet, much less Compaq bought by HP.
The mac80211 stack? It's not "generic" enough to handle "FullMAC" devices (devices where the Media Access Control (MAC) Sublayer Management Entity (MLME) is handled by the device's hardware or firmware), but, as they say, "FullMAC devices have become scarce". I don't know whether any of the *BSD's 802.11 stacks handle both FullMAC and SoftMAC adapters; if so, those *BSDs have a more generic 802.11 stack, but if, as the mac80211 people note, there aren't many FullMAC devices (which I suspect means "there are few if any newer FullMAC devices", i.e. newer devices will leave the MLME to the OS), that's not a big difference these days.
and I have not idea why it would behave in a significantly different manner.
Because it was developed independently, and its developers had their own ideas about how things should be done (whether those ideas were "this is better", "Not Invented Here", or a combination of the two)?
The Panel notes that dehydration was identified as the disease by the applicant. Dehydration is a condition of body water depletion. Upon request for clarification on the risk factor, the applicant proposed “water loss in tissues” or “reduced water content in tissues” as risk factors, the reduction of which was proposed to lead to a reduction of the risk of development of dehydration. The Panel notes that the proposed risk factors are measures of water depletion and thus are measures of the disease (dehydration).
from the decision that The Panel are basically saying "water loss in tissues isn't a risk factor for dehydration, it is dehydration".
In order to ensure that the claims made are truthful, it is necessary that the substance that is the subject of the claim is present in the final product in quantities that are sufficient, or that the substance is absent or present in suitably reduced quantities, to produce the nutritional or physiological effect claimed. The substance should also be available to be used by the body. In addition, and where appropriate, a significant amount of the substance produ- cing the claimed nutritional or physiological effect should be provided by a quantity of the food that can reasonably be expected to be consumed.
I find it very ironic that the only reason that a lot of people give for switching to Mac is that OSX is the very reason that Apple is much maligned: locking the OS into their hardware. Nobody else would even consider doing such an insidious thing.
There's "locking the OS to their hardware", and there's "only developing the OS for their hardware". Apple does both, but it's the latter, not the former, that people are giving, if by "the only reason that a lot of people give for switching to Mac" you're referring to "you don't have to fiddle with the OS to make it work with your hardware". There may be something "insidious" about the former, but not the latter.
Slashdot Mirror
The heydays ended ten years ago:
http://en.wikipedia.org/wiki/File:Operating_systems_used_on_top_500_supercomputers.svg
The culprit? Linux.
...which is a UNIX-compatible OS.
I'm curious how much recognizably-AT&T-derived code is in the current commercial UNIXes; probably more than in Linux distributions, but it might not be as much more than people think. UNIX's legacy is more the APIs and command-line interface than the actual code, and Linux has that stuff.
I remember the first time I saw Unix, in 1976. The first step in installing it was to compile the C compiler (supplied IIRC in PDP-11 assembler)
As I remember, and as the "SETTING UP UNIX - Sixth Edition" document says (see the start *roff document in this V6 documentation tarball - yes, I know, tarballs are an anachronism here :-)), V6 came in a binary distribution that you read from a 9-track tape onto a disk:
You didn't have to recompile anything (at least not if you had more than 64KB; I had to do some hackery with the assembler to get it to run on a 64KB machine, as there wasn't enough memory to run the C compiler - I had to stub out the pipe code with an assembler-language replacement for pipe.c, and then recompile the kernel with a smaller buffer cache and the regular pipe code). Most users probably either had to or had good reasons to recompile the kernel (different peripherals, more memory for the buffer cache - or less memory in my case, so I had to shrink it from 8 whole disk blocks to 6 - etc.), and if you weren't in the US eastern time zone or didn't have daylight savings time you had to change ctime.c, or whatever it was called, in the C library for your time zone, recompile the C library, and then rebuild all utilities with the new C library (no Olson code and database, no shared libraries, no environment variables so no TZ environment variable).
Somehow it missed all of the racist rants.
And I saw none of "naked", "petrified", "hot", or "grits" in there.
All major processors except Itanium use microcode, including most ARM implementations. It's not an x86-specific thing.
The second sentence is true. The first one, well, do you consider SPARC and Power Architecture processors to be "major processors"? If so, where's a citation to indicate that they use microcode? Even if not, where's a citation to indicate that most ARM processors use microcode?
Also, what "run RISC cores with shenanigans wrapped around to implement the x86 legacy" means is that, on at least some modern x86 processors (dunno about Atom, but Intel's other processors since Pentium Pro, as well as, I think, all AMD processors since the K5), the x86 instructions are decoded into one or more presumably-RISCy "microoperations" which are what are scheduled and executed by the execution units. Some of them might be implemented with "microcode" in the sense of microoperations fetched from a ROM rather than generated on the fly by the decoder.
Limited Transistor counts and physical limitations of die size to start. Much of the current x64 chip is just to keep legacy x86 shit running.
[Citation needed]. At least going by area on the chip, a significant amount on a quad-core Sandy Bridge processor goes to graphics and memory and I/O access and to the shared L3 cache. How many transistors go to, for example, support for segmentation and references to AH and AL and so on? If you're talking about "legacy" in the sense of stuff x86-64 keeps around because it's in the x86 family, rather than its support for 32-bit code, that's another matter - but that's not an issue of being a chip with support for 32-bit code, it's an issue of being a chip with support for x86 CISC code. A reasonably clean 32-bit architecture could, I suspect, be extended to 64 bits without a lot of transistors lost to support for 32-bit code as well.
You're talking Windows 7 x64, which is just x86 extended a bit. What I'm talking about is 64 bit Chip, not x86 with 64bit extensions, and all the baggage that comes with it.
If "a 64-bit chip" is a chip with an instruction set that's not derived from an earlier 32-bit instruction set, why do we "need" such a chip? What problems does the "baggage" of 32-bit instruction set support that all x86-64 chips, all 64-bit PowerPC chips, all 64-bit SPARC chips, all 64-bit MIPS chips, all PA-RISC 2.0 chips, and all z/Architecture chips have, and that future ARMv8 chips will have (look for "Allows AArch32 applications under AArch64 OS Kernel" in the ARMv8 presentation), cause that are so severe that we "need a whole class of computers designed and built for 64bit architectures", with "64bit architectures" being those that lack that "baggage" (and thus meaning "IA-64" at this point, unless you know of a plain to resuscitate Alpha)?
And why would that require "a complete redesign" of Windows, rather than a rewrite of the low-level platform support code and a new compiler for the new architecture, given that, for example, Windows did support IA-64, and supported it as a 64-bit architecture (unlike its old support for Alpha with a 32-bit address space and 32-bit pointers)?
The Pentium Pro wasn't the *last* of Intel's "real" x86 processors, it was the *first* of the RISC-with-x86-wrapper (*) designs that make up all chips today. AFAIK the original Pentium line was the last.
The poster to whom you're responding said
in which case the last "x86 processor" was the 80486 - the Pentium wasn't sold as the 80586, it was sold as the Pentium.
And, given that the internal microops in Pentium Pro and later are not exposed to programs running on the processor, it's irrelevant to a discussion of whether those chips are "real" x86's or not. About the only processors where the question could reasonably be raised as to whether they're "really" x86 or not were the Transmeta chips, where an x86 interpreter and x86-to-native-code translator were, presumably, written in or compiled to the native instruction set and ran from, as I remember, a reserved chunk of main memory.
x64 is an extension to x86. What we need a a whole new class of computers designed and built for 64bit architectures.
How would "[designing] and [building]" a computer "for 64bit architectures" differ from what's being done now?
But that calls for a complete redesign of the most popular OS
I know of no desktop, notebook, or server OSes that would need "a complete redesign" to work on 64-bit architectures - they already work on them; presumably whatever would make the "whole new class of computers" different from the 64-bit computers being sold now is what would require that "complete redesign".
Your "flamebait" is my "topical", "interesting" and "discussion-worthy".
It is a sad world-view that sees any topic that engenders a lot of comments, even argument as necessarily "flamebait".
A topic that engenders comments and argument based on facts isn't flamebait. A topic that engenders comments from, for example Apple haters who assert that the only reason anybody buys Apple products is that they're idiots bedazzled by shiny objects or that the only reason anybody doesn't like {Macs, iPhones/iPads/etc. Mac OS X, iOS} is that they Just Don't Get It, not so much.
Can we just agree that Apple hardware articles are flamebait by default, especially the ones about the mere possibility of new Apple hardware, and stop frickin posting them?
Can we just agree that a huge number of articles on Slashdot, period, are flamebait by default? Anything that mentions {Apple,Microsoft,the Linux community,BSD} will probably get the usual pile of shouting from both sides, anything that mentions global warming will probably get the usual pile of shouting from both sides, anything about Gummint {forcing people to do XXX, nudging people to do XXX, refusing to give money to people who don't do XXX, encouraging people to do XXX} will probably get the usual pile of shouting from both sides, anything about the RIAA/MPAA will probably get the usual pile of shouting (mostly against the RIAA/MPAA in this case),, etc., etc., etc..
It's not the "sorta Celeron" it's the "Celeron of their server CPUs"
"It" presumably means "the Pentium 350"; there are other, non-server, Pentiums in the Intel Sandy Bridge-architecture product line.
32-bit x86 CISC instruction set based CPUs
All x86 processors are CISC (regardless of whether they internally turn the instructions into sequences of 1 or more RISCy micro-ops and schedule and execute those independently).
should be called Pentiums
Presumably meaning "Only 32-bit x86 CPUs should be called Pentiums", as you presumably don't intend to call the 80386 and 80486 Pentiums.
(Not that Intel's marketing department has any good reason whatsoever to care what any of us think is the proper use for their "Pentium" brand.)
Because the ageing pentium architecture was a mess, and they needed to redesign from scratch for the Core 2 architecture - which was a great improvement. They stopped using the pentium brand because they stopped selling chips with any pentium-based technology in.
What is the "Pentium architecture"? The microarchitecture of the original Pentium (P5) was different from the microarchitecture of the Pentium Pro/Pentium II/Pentium III (P6), and P6 was different from the microarchitecture of the Pentium 4 (NetBurst), and NetBurst was different from the microarchitecture of the Pentium M (which was, I think, P6-derived). The microarchitecture of the Core 2 (Core) was, I think, Pentium M-derived.
So there's Pentium-the-chip (P5), and there's Pentium-the-brand, which was first used with the P5 chip but was also used with chips with significantly different microarchitectures from the P5 chip.
The Pentium 350 apparently uses the Sandy Bridge microarchitecture, along with a bunch of other microprocessors, some named Core, some named Xeon, some named Celeron, and some named Pentium. Some of the ones named Pentium were launched in Q3 2011, before the Pentium 350, so "Intel Breathes New Life Into Pentium" is, to use the technical term, a "complete bullshit headline".
Do you know what all your icons represent, without the text there to help you?
Or, to put it another way, if your icon is incomprehensible without a tooltip or title, You're Doing It Wrong.
Now, maybe once you've learned that, for example, the small image of the man with his head up his ass represents "send message to upper management", it's easier to find the picture on the toolbar than to find the text on the toolbar if that's the function you're looking for. If that's the case, it'd be a small irony, as it'd be "text for the newbies, icons for the power users...".
Is this the same Apple that provided 68K emulation on their PowerPC systems so people could run their old apps on a completely new processor architecture?
Yes, and that's the same Apple that, for example, got rid of native PPC support in Snow Leopard so it wouldn't run on PPC Macs and got rid of 32-bit processor support in Lion so it wouldn't run on Macs with 32-bit x86 processors, so they have, in fact, dropped support for hardware platforms on at least two occasions (and the 68K emulation and PPC emulation were also dropped at various points).
What's wrong with the lancer?
It's not an valid replacement when [Citation needed].
Except that in most cases you can buy more X64 systems for the same price or less to compensate for the performance difference... Also you can use GPUs if that is beneficial for what your doing.
Or you can run Linux on a SPARC machine or a POWER machine or a z/Architecture machine. Itanium isn't your only high-end alternative to x86.
What about Apple? Their OSs drop support for hardware platforms on a regular basis. (I know it's an Itanium discussion, but...)
Apple sell computers mainly to home computer users and some professionals; they don't sell enterprise-class servers, and I have the impression that "sorry, that machine you bought a few years ago has been kicked to the curb in our new release" might not go over as well in that market (although I also have the impression that "here's a shiny new release of our {OS, database, etc.}, you should upgrade to it right now" doesn't exactly go over well in that market, either).
MSSQL may currently run on Itanium but support is rapidly being dropped.. Not sure about DB2 but i doubt it runs on Itanium..
It does run on HP-UX Itanium systems, but doesn't run on Linux Itanium systems. The latter might not be all that surprising, given that the majority of Itanium systems come from HP; if you want to run Linux rather than HP-UX, you have more choices, so I suspect relatively few Linux servers are Itanium boxes.
The AMD64 has 16 64-bit registers, which is merely a logical next step from the 8 32-bit registers of the prior generation. According to Wikipedia: AMD64 still has fewer registers than many common RISC ISAs (which typically have 32–64 registers)
Except for one rather common RISC ISA, but that one's mainly used in stuff like mobile phones, not Big Honking Servers (although with ARM64 they're at least thinking about servers - it might be more "tons of blade processors" than "a smaller number of Big Honking Processor Engines", though).
TheAMD64 is not a "pure" 64-bit chip. It is a chip that operates in 64-bits but has an internal architecture that has not significantly changed since the days of the 4040.
Internal architecture, not instruction-set architecture? If you truly mean "internal architecture" in the sense of "implementation of the instruction set", do you really mean to say that a superscalar out-of-order pipelined processor that breaks instructions down into micro-operations and schedules the micro-operations is not "significantly changed" from an in-order one-instruction-at-a-time (and, I think, not even pipelined) processor that just fetches and executes instructions in sequence?
It has merely been scaled. Scaling is not engineering.
Presumably "is not engineering" is something other than "requires no engineering work to accomplish", unless you have a definition of "engineering" different from what I and I suspect a lot of processor designers have.
So they come up with this crazy VLIW idea
Who's "they"? Intel, or HP?
and realize it will cost a ton of money.
Which, as I understand it, is why HP partnered with Intel (not the other way around).
At the same time, they can convince HP to transition away from their existing RISC architectures (PA-RISC
Which, as I understand it, was HP's intent even before they got Intel involved.
and Alpha)
Which was, at the time the HP-Intel partnership was announced, DEC's RISC architecture - DEC hadn't even been bought by Compaq yet, much less Compaq bought by HP.
I'm fairly sure Linux has a generic 802.11 stack
The mac80211 stack? It's not "generic" enough to handle "FullMAC" devices (devices where the Media Access Control (MAC) Sublayer Management Entity (MLME) is handled by the device's hardware or firmware), but, as they say, "FullMAC devices have become scarce". I don't know whether any of the *BSD's 802.11 stacks handle both FullMAC and SoftMAC adapters; if so, those *BSDs have a more generic 802.11 stack, but if, as the mac80211 people note, there aren't many FullMAC devices (which I suspect means "there are few if any newer FullMAC devices", i.e. newer devices will leave the MLME to the OS), that's not a big difference these days.
and I have not idea why it would behave in a significantly different manner.
Because it was developed independently, and its developers had their own ideas about how things should be done (whether those ideas were "this is better", "Not Invented Here", or a combination of the two)?
And I infer, perhaps incorrectly, from
from the decision that The Panel are basically saying "water loss in tissues isn't a risk factor for dehydration, it is dehydration".
And here's REGULATION (EC) No 1924/2006 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL, as referred to by the decision. Article 14 is
I find it very ironic that the only reason that a lot of people give for switching to Mac is that OSX is the very reason that Apple is much maligned: locking the OS into their hardware. Nobody else would even consider doing such an insidious thing.
There's "locking the OS to their hardware", and there's "only developing the OS for their hardware". Apple does both, but it's the latter, not the former, that people are giving, if by "the only reason that a lot of people give for switching to Mac" you're referring to "you don't have to fiddle with the OS to make it work with your hardware". There may be something "insidious" about the former, but not the latter.