Re:not much info about the chip
on
K8 Details
·
· Score: 2
Does one need supportive evidence to predict that a duck will quack rather than bark?
Intel have quacked and barked in the past; they may be more likely to quack than bark, but that doesn't prove beyond the shadow of a doubt that they will.
I don't think Intel has any plans to make it easy for anybody other than themselves or HP to build IA-64 implementations; I have no reason to believe that this necessarily means that they'll keep stuff secret forever - I suspect they'll make heavy use of patents, instead.
So, an AMD K8 that simply extends x86 to 64-bit... Requires minimal re-engineering of support software like compilers
It requires more support software than just compilers.
It also requires operating system support, and could require application vendors to port their software to it - this might mainly just be a recompile, but it's still another platform they have to support.
Maybe they're doing that, but it's hardly a trivial task from the software standpoint; I've no idea which OS suppliers (the free UNIX-flavored OSes, perhaps, but what about Microsoft, Sun, SCO, etc.?), compiler suppliers (GCC, perhaps), and other software suppliers (e.g., Oracle) will be willing to back them.
Windows uses the same API for screen and printer output.
The XPRINT extension for X11R6.1 and later follows a similar model - there are some added calls to start and end pages, select a particular printer, etc., but most of the drawing can be done with Xlib calls (or, if one can get an some toolkit for X to use a particular X display for particular calls, with higher-level toolkit calls)
The GDI subsystem sends the drawing primitives to the driver corresponding to the selected device context which is responsible for converting these to whatever commands needed for your particular hardware. The output then is send to the spooler.
XPRINT is also similar, in that the X Print server to which you connect generates PCL, PostScript, or whatever page description language, and hands it to your system's print spooler.
UNIX print spooler systems may also have their own mechanisms for turning various file formats into commands for a particular printer, e.g. filters to turn PostScript into rasters for printers that don't support PostScript.
In case of network printers, the actual mapping of your job to a remote printer is done somewhere at the spooler level. i.e., below the printer driver. That has two implications:
Printer driver must be installed on each client machine. When you install a remote printer, Windows actually copies driver files from the server machine to yours.
The actual data sent on the network are binary printer commands, not any higher level primitives.
If the X Print server you connect to is on a local machine, printing would work that way with XPRINT, although there's no mechanism for automatically copying printer drivers from the server (it may, after all, not be running the same OS as your machine, or, even if it is, it may not have the same instruction set; how well does that copied print driver stuff work with, say, an Alpha server running NT and x86 clients running NT or W9x?).
If the server's running an X Print server, it could also be done by connecting to an X Print server on that machine, and sending it the X and XPRINT requests to draw stuff over the wire.
Re:not much info about the chip
on
K8 Details
·
· Score: 2
Contrast that with IA-64 where much of the ISA will be hidden in secret "Appendix H's"
And your evidence that this will be the case, rather than that just being a possibility (Intel has, of course, done that in the past), being?
(No, the fact that they currently aren't documenting the stuff needed to do an OS kernel doesn't count; I think they've said that All Will Be Revealed, at least to the extent that the source to ports like the Linux port will be available, by the time they ship.)
Re:not much info about the chip
on
K8 Details
·
· Score: 2
However, if AMD wants to clone IA-64, they would have to start by basically cloning PA-RISC and adding the same extentions to that architecture as Intel is.
IA-64 is not PA-RISC 2.0 plus some stuff added on; some aspects of it may be inspired by PA-RISC, but PA-RISC didn't, last I looked, have 128-bit bundles containing 3 instructions plus template bits.
As such, it's not clear to what extent AMD, were they to try to create an IA-64 implementation, would benefit from first doing a PA-RISC implementation, rather than just going straight to IA-64.
This is just pure speculation, but if the K8 is going to be a 64bit chip it'll need a new instruction set
Why? It could just extend the x86 instruction set to 64 bits
Which amounts to, in effect, a new instruction set, in that it adds new instructions, or a new 64-bit mode.
That would require people to write or compile their code for 64-bit x86 in order for it to be useful; I'm not sure whether how much interest there'd be in Yet Another New Instruction Set whose name doesn't begin with "IA-".
a 64-bit x86-optimized chip would outperform anything else running x86 software.
But if the chip never runs any of the new instructions (or, if it's done with a mode bit, never runs in the new mode), what does the extension of the instruction set buy you?
RFC 791, "INTERNET PROTOCOL, DARPA INTERNET PROGRAM, PROTOCOL SPECIFICATION", says that it was "prepared for Defense Advanced Research Projects Agency Information Processing Techniques Office, 1400 Wilson Boulevard, Arlington, Virginia 22209, by Information Sciences Institute, University of Southern California, 4676 Admiralty Way, Marina del Rey, California 90291", and RFC 793 "TRANSMISSION CONTROL PROTOCOL, DARPA INTERNET PROGRAM, PROTOCOL SPECIFICATION" says the same thing.
I have the impression Cerf wasn't the sole author; I think Jon Postel, for one, was involved, and RFC 793 says
TCP is based on concepts first described by Cerf and Kahn in [Cerf, V., and R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Transactions on Communications, Vol. COM-22, No. 5, pp 637-648, May 1974]"
so presumably Robert(?) Kahn was involved as well.
In any case, as you note, Bob Metcalfe didn't invent TCP/IP.
This would work great, except that I don't think the X graphical model is flexible enough to be useful for general document printing.
For example, font handling. Win32 and MacOS provide a lot of detail about fonts that is necessary for good quality text layout and printing. X does not.
Text layout, for example, is done on the display as well; are X's facilities sufficient for display but not for printing, or does X need to be improved (or replaced...) for display as well?
The second is that a common printing system for UNIX does exist--but not for Linux. It's called XPRINT,
Define "printing system". Section 1.1 of the X Print Service Extension Library documentation says
Several keywords and concepts used in this specification were borrowed from the abstract standard ISO 10175, the subsetted standard and implementation represented by POSIX 1387.4, and the yet further subsetted implementation represented by OSF Palladium. The X Print Service does not attempt to duplicate the functionality or APIs provided by any of these print subsystems, or by any other print subsystems such as System V lp or BSD lp. It does, however, attempt to allow implementations to work with these print subsystem, and its architecture is open enough to allow tighter binding to a specific print subsystem in the future.
CUPS is a "print subsystem such as System V lp or BSD lp[sic]"; XPRINT generates stuff to feed to a printer, and a print subsystem such as the SV or BSD one, or CUPS, queues up that stuff when handed it, and feeds it to a printer.
So XPRINT isn't enough to do printing; you need a print spooling system, as well as a system for actually generating a file containing instructions to a printer telling it what marks to put on a sheet of paper (or what stuff to send over a fax modem, or whatever). CUPS is, among other things, a print spooling system; an X Print Server will probably assume that a print spooling system exists and that it should hand print jobs to that system.
You could debate whose job it should be to turn printer-independent drawing instructions into the appropriate drawing instructions for a particular printer; if somebody wants to argue that XPRINT should do that, they'll have to demonstrate that it's OK to require all programs that print more than just plain text to be linked with Xlib and company, and to be run in an environment that has X Print Servers handy (be prepared to have to respond to people who do not want to be required to do that, and may even have good reasons not to want that).
Oh, and I don't consider it a "UNIX standard" until I can rely on it being on all UNIX systems, even if I'm, say, in an environment where all the UNIX systems are headless servers.
before anyone flames me, read the docs for XPRINT,
I did (which I was able to do, because I happen to have Frame Maker; has anybody converted the various X specs written in Frame into a format that those who don't have Frame can read, and made them publicly available?), and they specifically indicate that XPRINT isn't a print spooling system.
XFree86 releases starting with the 3.2A beta are based on the X Consortium's X11R6.3 (the final release from the X Consortium).
R6.3 is an update to R6.1, and is intended to be compatible with R6.1 and R6 at the source and protocol levels. Binaries should be upward-compatible. X11R6.3 includes some new Xserver extensions: SECURITY, XC-APPGROUP, XpExtension (print extension),...
It doesn't help apps determine what fonts are ok, it doesn't help them create the output, it doesn't give them a working font model, font metrics, the kind of info in afm files, etc.
To what extent does the XPRINT extension provide that (at least for X applications), and in what ways doesn't it provide that? ("In what ways doesn't it provide that" could include ways in which X itself is deficient - and which might be ways in which apps don't have good enough display support as well.)
That'd work, of course, only if you have an X Print Server available, which not all UNIX systems necessarily do.
I was simply offering some pure conjecture, nothing more.
Yes, but the patent seems not to support the conjecture - which was made after the patent was mentioned in a Slashdot thread, complete with a link to the patent's text.
if all they're doing is software emulation
From the patent, it appears that they're doing hardware to let software translation make optimistic assumptions about what the code might do, and recover if the assumptions were overly optimistic, rather than having the software have to assume that (to give an example that I think was mentioned in the patent) the code might make an unaligned reference that crosses a page boundary.
For example, Digital's x86-to-Alpha translation system (I forgot the name, something with "W" and "X" and "32" in it I believe)
"FX!32".
which saves translated code and uses that one the next time around is quite brilliant and works very well from what I've heard.
I'm curious whether it ever has to make overly-cautious assumptions that hardware assists along the lines of the ones mentioned in the Transmeta patents would let it avoid, and whether those assumptions actually cost it enough that those hardware assists would be worth it or not.
The Linux threading model is not terribly clean, and there are still way too many huge locks in the current kernels.
I had the impression that the "threading" being talked about here is the threading model as made available in userland (e.g., Solaris's model with N threads per process implemented atop M LWPs) rather than the degree to which the kernel itself is multi-threaded.
Linux had kernel threading retrofitted instead of woven into the OS like Solaris
I was under the impression that the SVR4.0 kernel Sun started with had neither MP nor userland threading support, and that Sun added both of them. (Yes, there were SVR4.x releases that had both MP and threading - I think there were even SVR4.0 versions with them - but, as far as I know, that wasn't what Sun started with; as of when I left Sun in 1988 we were getting pre-release loads of SVR4 from AT&T.)
Coming from a religious camp, if I live in a country where religion is taught in school (and I do), and my goverment suddenly that mandate that school children no longer need to believe in God, I would freak out the same way as they do.
I don't particularly care whether people would be bothered by the government disallowing public schools to require that people believe in some religion; I refuse to consider it proper for any government to enforce adherence to any religion, or even to religion in general, in its institutions.
Besides, plenty of religious people seem to manage to reconcile a belief in their religion with a belief that an evolutionary model for the generation and development of life on earth is the best model we have so far; teaching evolution is inequivalent to teaching atheism, no matter what some folks might think.
Why is the spontenous generation theory is sooo important? It supports the idea that humans are not created but evolved from bacteria spontenously created out of thin air.
And who has hypothesized that "humans... evolved from bacteria spontaneously created out of thin air"? I am unaware that any of the current hypotheses for the appearance of life on earth posit that bacteria were "spontaneously created out of thin air".
(In addition, even if you do posit that some diety or dieties somehow put the first forms of life on earth, that doesn't mean that said life forms couldn't have evolved into other life forms.
A lot of the problem some religious people seem to have with evolution appears to be that they believe it implies that there must be no god or gods; as far as I can tell, it is possible to be religious and believe that evolution is the best explanation for the way live exists on earth now and apparently existed in the past, just as it's possible for nonbelievers like me.)
The patent is not on a chip that translates instructions from one set to another
Err, umm, perhaps that's because they're not implementing a chip that translates instructions from one instruction set to another, but are implementing a chip with hardware features to allow software to do said translation in an optimistic fashion, and to handle cases where said optimism is unwarranted (e.g., trap, and not make persistent state changes to e.g. memory, so that software can re-translate in a less optimistic fashion).
watch for that one, it should be coming soon
I'll be surprised if it does come, given that in the most recent patent they quite explicitly referred to translation software.
Now I don't think that the first iteration of merced is going to be widely adopted. But I think that the second will move it's way into the market extremely quickly and after that x86 is going to fade fairly rapidly.
The fact that "the second [iteration of merced]" (Are you referring to McKinley here? "Merced" is the code name for an implementation of the IA-64 instruction set, as is McKinley; they're two generations of IA-64 implementation, not two generations of the Merced implementation of IA-64, as far as I know.) moves into the market quickly doesn't imply that "after that x86 is going to fade fairly rapidly". Fred Pollack's slides from the October 1997 Microprocessor Forum indicate that, at least at that time, Intel planned to continue IA-32(x86) development for a while; perhaps they've changed their minds since then, and perhaps IA-64 will be so successful that they quickly drop prices on IA-64 implementations and kill off x86, but I have no reason to believe that this is guaranteed to happen - IA-64 may well stay high-end for a while.
I don't know at which market(s) Transmeta would aim the processors that they're presumed to be designing; it may well be that said market(s) will switch so quickly to IA-64 that x86 emulation is irrelevant to it, but I'm not about to assume that - and perhaps Transmeta aren't assuming it, either.
Will Transmeta produce the chip themselves, and start their own line of desktops, servers, laptops, etc?
Just out of curiosity, how many vendors have in the past couple of years succeeded in coming out with a new chip with a new native instruction set, a new OS, and a line of computers based on those chips running that OS?
If the answer is "none", or some very small number, this doesn't mean that Transmeta couldn't succeed at doing that, but it suggests that doing so might not be easy, and that the machines might have to have some major advantage over existing machines to convince people to buy them rather than, say, PCs running any of the N operating systems that run on them, or Suns, or HP-UX machines, or RS/6000's, or Alpha boxes, or....
That, in turn, doesn't say that they're not planning on doing that, but it suggests that they might not want to be quite so ambitious, and might realize that, and thus might not be quite so ambitious.
Personally, I believe they're working on a meta-CPU which doesn't have a native general purpose instruction set of its own
Personally, assuming the patents they've been getting are for ideas they're planning on using in whatever they make (rather than, say, ideas they came up with for a product they were working on at one point, but that they abandoned in favor of another product), I suspect they're working on a CPU that does have a native instruction set of its own, plus software to translate other instruction sets into native instruction sets, given that they talked about such translation software in the patent most recently mentioned on Slashdot (see my postings on the thread for that patent for quotes from that patent).
I have seen nothing whatsoever to indicate that they plan to have the chips' hardware be reconfigurable to directly execute different instruction sets.
I rember Ralph Brown's interrupt list had all the specs on it, but it is sorta an arcane way to go about it... (although someone eventually has to code it at the assembler level)
Eh? Are you saying that the only way to get DDC information from a video card is to talk to the BIOS? I'll have to go grab the source to the XFree86 release in question and see how they do it, but I'm skeptical that you have to go to the BIOS to do it....
Not all that tricky if the video card and monitor support the VESA Display Data Channel standard and the video card can get enough information from the monitor that way to let the host identify it.
I haven't bought the standards in question from VESA (they aren't cheap), so I don't know what sort of information you can get from plug-and-play monitors, but check out the VESA standards page.
No, I trust a good hardware specification and electronic engineering practices MUCH more than I would trust the general state of software production practices in the computer segment of the computing market.
And you trust folks writing BIOS code to act like electronic engineers rather than like software engineers "in the computer segment of the computing market"?
If my hardware is going to be reliably auto-detected it will be done so at the BIOS level.
I.e., you trust the code written by the BIOS vendor more than you trust the code written by the OS supplier (which isn't necessarily Microsoft...)?
Those same facilities can be and are exploited by any other PC OS, including Linux.
...although the Linux on my machine (Debian Slink) doesn't, out of the box, manage to handle the plug-and-play ISA soundcard on my box (no, I have no interest in devoting a PCI slot to a sound card).
Another PC OS - which doesn't come from Redmond - does manage to recognize and support the card, however.
Now the software being written for GNU/Linux is taking off in every direction imaginable.
...including being run on other UNIX-flavored OSes (and, in many cases, developed by people working on a variety of UNIX-flavored OSes, including but not limited to Linux).
Note that the first place the word "Linux" appears on the KDE home page is when it says
KDE wins "LinuxWorld's Editor Choice" award in "Desktop Environment" category
Earlier on that page, it says
KDE is a powerful graphical desktop environment for Unix workstations. It combines ease of use, contemporary functionality and outstanding graphical design with the technological superiority of the Unix operating system.
Note that "Unix" appears twice in that quote, and "Linux" appears zero times; they should arguably replace "Unix operating system" with "Unix-flavored operating systems", or something such as that, given that there is no single collection of software that is the "Unix operating system", i.e. in that context, "Unix operating system" includes Linux, just as much as it includes {Free,Net,Open}BSD, Solaris, HP-UX, etc..
Soon the differences between Unix and GNU/Linux will dwarf the similarities for many.
I'm still waiting.... (When I log into a Linux box here, it feels pretty much like any of the other UNIX boxes; it's not exactly the same as any of the others, but Solaris and Digital UNIX aren't exactly the same, either.)
Personally, I can't wait until Berlin is ready for some serious action.
Our long term goal is to produce the most powerful and flexible GUI possible, and to release it on as many hardware platforms and OSs as can be found.
Nothing on the home page says "this is a windowing system for Linux"; the developers may be working on Linux, but they pretty clearly state that it isn't their intent to make this something just for Linux.
You don't sound like any IT person who has to hop from desktop to desktop in a large company: in such a place
consistency is a godsend (unless you're paid by the hour;).
Then perhaps you want a way of disabling the tweakable knobs and buttons on machines that the IT folks are managing (I have the impression that Windows NT, at least, has ways of doing so, by setting the appropriate, well, knobs in the registry), or, at least, requiring people to forego centralized management if they want to tweak their boxes.
Slashdot Mirror
Intel have quacked and barked in the past; they may be more likely to quack than bark, but that doesn't prove beyond the shadow of a doubt that they will.
I don't think Intel has any plans to make it easy for anybody other than themselves or HP to build IA-64 implementations; I have no reason to believe that this necessarily means that they'll keep stuff secret forever - I suspect they'll make heavy use of patents, instead.
It requires more support software than just compilers.
It also requires operating system support, and could require application vendors to port their software to it - this might mainly just be a recompile, but it's still another platform they have to support.
Maybe they're doing that, but it's hardly a trivial task from the software standpoint; I've no idea which OS suppliers (the free UNIX-flavored OSes, perhaps, but what about Microsoft, Sun, SCO, etc.?), compiler suppliers (GCC, perhaps), and other software suppliers (e.g., Oracle) will be willing to back them.
The XPRINT extension for X11R6.1 and later follows a similar model - there are some added calls to start and end pages, select a particular printer, etc., but most of the drawing can be done with Xlib calls (or, if one can get an some toolkit for X to use a particular X display for particular calls, with higher-level toolkit calls)
XPRINT is also similar, in that the X Print server to which you connect generates PCL, PostScript, or whatever page description language, and hands it to your system's print spooler.
UNIX print spooler systems may also have their own mechanisms for turning various file formats into commands for a particular printer, e.g. filters to turn PostScript into rasters for printers that don't support PostScript.
If the X Print server you connect to is on a local machine, printing would work that way with XPRINT, although there's no mechanism for automatically copying printer drivers from the server (it may, after all, not be running the same OS as your machine, or, even if it is, it may not have the same instruction set; how well does that copied print driver stuff work with, say, an Alpha server running NT and x86 clients running NT or W9x?).
If the server's running an X Print server, it could also be done by connecting to an X Print server on that machine, and sending it the X and XPRINT requests to draw stuff over the wire.
And your evidence that this will be the case, rather than that just being a possibility (Intel has, of course, done that in the past), being?
(No, the fact that they currently aren't documenting the stuff needed to do an OS kernel doesn't count; I think they've said that All Will Be Revealed, at least to the extent that the source to ports like the Linux port will be available, by the time they ship.)
IA-64 is not PA-RISC 2.0 plus some stuff added on; some aspects of it may be inspired by PA-RISC, but PA-RISC didn't, last I looked, have 128-bit bundles containing 3 instructions plus template bits.
As such, it's not clear to what extent AMD, were they to try to create an IA-64 implementation, would benefit from first doing a PA-RISC implementation, rather than just going straight to IA-64.
Which amounts to, in effect, a new instruction set, in that it adds new instructions, or a new 64-bit mode.
That would require people to write or compile their code for 64-bit x86 in order for it to be useful; I'm not sure whether how much interest there'd be in Yet Another New Instruction Set whose name doesn't begin with "IA-".
But if the chip never runs any of the new instructions (or, if it's done with a mode bit, never runs in the new mode), what does the extension of the instruction set buy you?
RFC 791, "INTERNET PROTOCOL, DARPA INTERNET PROGRAM, PROTOCOL SPECIFICATION", says that it was "prepared for Defense Advanced Research Projects Agency Information Processing Techniques Office, 1400 Wilson Boulevard, Arlington, Virginia 22209, by Information Sciences Institute, University of Southern California, 4676 Admiralty Way, Marina del Rey, California 90291", and RFC 793 "TRANSMISSION CONTROL PROTOCOL, DARPA INTERNET PROGRAM, PROTOCOL SPECIFICATION" says the same thing.
I have the impression Cerf wasn't the sole author; I think Jon Postel, for one, was involved, and RFC 793 says
so presumably Robert(?) Kahn was involved as well.
In any case, as you note, Bob Metcalfe didn't invent TCP/IP.
Correct.
(Or, rather, he and Dave Boggs invented it; I have the impression Metcalfe isn't the sole inventor.)
Text layout, for example, is done on the display as well; are X's facilities sufficient for display but not for printing, or does X need to be improved (or replaced...) for display as well?
Define "printing system". Section 1.1 of the X Print Service Extension Library documentation says
CUPS is a "print subsystem such as System V lp or BSD lp[sic]"; XPRINT generates stuff to feed to a printer, and a print subsystem such as the SV or BSD one, or CUPS, queues up that stuff when handed it, and feeds it to a printer.
So XPRINT isn't enough to do printing; you need a print spooling system, as well as a system for actually generating a file containing instructions to a printer telling it what marks to put on a sheet of paper (or what stuff to send over a fax modem, or whatever). CUPS is, among other things, a print spooling system; an X Print Server will probably assume that a print spooling system exists and that it should hand print jobs to that system.
You could debate whose job it should be to turn printer-independent drawing instructions into the appropriate drawing instructions for a particular printer; if somebody wants to argue that XPRINT should do that, they'll have to demonstrate that it's OK to require all programs that print more than just plain text to be linked with Xlib and company, and to be run in an environment that has X Print Servers handy (be prepared to have to respond to people who do not want to be required to do that, and may even have good reasons not to want that).
Oh, and I don't consider it a "UNIX standard" until I can rely on it being on all UNIX systems, even if I'm, say, in an environment where all the UNIX systems are headless servers.
I did (which I was able to do, because I happen to have Frame Maker; has anybody converted the various X specs written in Frame into a format that those who don't have Frame can read, and made them publicly available?), and they specifically indicate that XPRINT isn't a print spooling system.
What's missing? The XFree86 3.3.5 release notes say
To what extent does the XPRINT extension provide that (at least for X applications), and in what ways doesn't it provide that? ("In what ways doesn't it provide that" could include ways in which X itself is deficient - and which might be ways in which apps don't have good enough display support as well.)
That'd work, of course, only if you have an X Print Server available, which not all UNIX systems necessarily do.
Yes, but the patent seems not to support the conjecture - which was made after the patent was mentioned in a Slashdot thread, complete with a link to the patent's text.
From the patent, it appears that they're doing hardware to let software translation make optimistic assumptions about what the code might do, and recover if the assumptions were overly optimistic, rather than having the software have to assume that (to give an example that I think was mentioned in the patent) the code might make an unaligned reference that crosses a page boundary.
"FX!32".
I'm curious whether it ever has to make overly-cautious assumptions that hardware assists along the lines of the ones mentioned in the Transmeta patents would let it avoid, and whether those assumptions actually cost it enough that those hardware assists would be worth it or not.
I had the impression that the "threading" being talked about here is the threading model as made available in userland (e.g., Solaris's model with N threads per process implemented atop M LWPs) rather than the degree to which the kernel itself is multi-threaded.
I was under the impression that the SVR4.0 kernel Sun started with had neither MP nor userland threading support, and that Sun added both of them. (Yes, there were SVR4.x releases that had both MP and threading - I think there were even SVR4.0 versions with them - but, as far as I know, that wasn't what Sun started with; as of when I left Sun in 1988 we were getting pre-release loads of SVR4 from AT&T.)
I don't particularly care whether people would be bothered by the government disallowing public schools to require that people believe in some religion; I refuse to consider it proper for any government to enforce adherence to any religion, or even to religion in general, in its institutions.
Besides, plenty of religious people seem to manage to reconcile a belief in their religion with a belief that an evolutionary model for the generation and development of life on earth is the best model we have so far; teaching evolution is inequivalent to teaching atheism, no matter what some folks might think.
And who has hypothesized that "humans ... evolved from bacteria spontaneously created out of thin air"? I am unaware that any of the current hypotheses for the appearance of life on earth posit that bacteria were "spontaneously created out of thin air".
(In addition, even if you do posit that some diety or dieties somehow put the first forms of life on earth, that doesn't mean that said life forms couldn't have evolved into other life forms.
A lot of the problem some religious people seem to have with evolution appears to be that they believe it implies that there must be no god or gods; as far as I can tell, it is possible to be religious and believe that evolution is the best explanation for the way live exists on earth now and apparently existed in the past, just as it's possible for nonbelievers like me.)
Err, umm, perhaps that's because they're not implementing a chip that translates instructions from one instruction set to another, but are implementing a chip with hardware features to allow software to do said translation in an optimistic fashion, and to handle cases where said optimism is unwarranted (e.g., trap, and not make persistent state changes to e.g. memory, so that software can re-translate in a less optimistic fashion).
I'll be surprised if it does come, given that in the most recent patent they quite explicitly referred to translation software.
The fact that "the second [iteration of merced]" (Are you referring to McKinley here? "Merced" is the code name for an implementation of the IA-64 instruction set, as is McKinley; they're two generations of IA-64 implementation, not two generations of the Merced implementation of IA-64, as far as I know.) moves into the market quickly doesn't imply that "after that x86 is going to fade fairly rapidly". Fred Pollack's slides from the October 1997 Microprocessor Forum indicate that, at least at that time, Intel planned to continue IA-32(x86) development for a while; perhaps they've changed their minds since then, and perhaps IA-64 will be so successful that they quickly drop prices on IA-64 implementations and kill off x86, but I have no reason to believe that this is guaranteed to happen - IA-64 may well stay high-end for a while.
I don't know at which market(s) Transmeta would aim the processors that they're presumed to be designing; it may well be that said market(s) will switch so quickly to IA-64 that x86 emulation is irrelevant to it, but I'm not about to assume that - and perhaps Transmeta aren't assuming it, either.
Just out of curiosity, how many vendors have in the past couple of years succeeded in coming out with a new chip with a new native instruction set, a new OS, and a line of computers based on those chips running that OS?
If the answer is "none", or some very small number, this doesn't mean that Transmeta couldn't succeed at doing that, but it suggests that doing so might not be easy, and that the machines might have to have some major advantage over existing machines to convince people to buy them rather than, say, PCs running any of the N operating systems that run on them, or Suns, or HP-UX machines, or RS/6000's, or Alpha boxes, or....
That, in turn, doesn't say that they're not planning on doing that, but it suggests that they might not want to be quite so ambitious, and might realize that, and thus might not be quite so ambitious.
Personally, assuming the patents they've been getting are for ideas they're planning on using in whatever they make (rather than, say, ideas they came up with for a product they were working on at one point, but that they abandoned in favor of another product), I suspect they're working on a CPU that does have a native instruction set of its own, plus software to translate other instruction sets into native instruction sets, given that they talked about such translation software in the patent most recently mentioned on Slashdot (see my postings on the thread for that patent for quotes from that patent).
I have seen nothing whatsoever to indicate that they plan to have the chips' hardware be reconfigurable to directly execute different instruction sets.
Eh? Are you saying that the only way to get DDC information from a video card is to talk to the BIOS? I'll have to go grab the source to the XFree86 release in question and see how they do it, but I'm skeptical that you have to go to the BIOS to do it....
Yes, he probably did, in fact.
Not all that tricky if the video card and monitor support the VESA Display Data Channel standard and the video card can get enough information from the monitor that way to let the host identify it.
I haven't bought the standards in question from VESA (they aren't cheap), so I don't know what sort of information you can get from plug-and-play monitors, but check out the VESA standards page.
It looks as if support for DDC, and at least some of the information you can get from it, may show up in XFree86 4.0; see this item in the XFree86 3.9.16 release notes.
And you trust folks writing BIOS code to act like electronic engineers rather than like software engineers "in the computer segment of the computing market"?
I.e., you trust the code written by the BIOS vendor more than you trust the code written by the OS supplier (which isn't necessarily Microsoft...)?
...although the Linux on my machine (Debian Slink) doesn't, out of the box, manage to handle the plug-and-play ISA soundcard on my box (no, I have no interest in devoting a PCI slot to a sound card).
Another PC OS - which doesn't come from Redmond - does manage to recognize and support the card, however.
...including being run on other UNIX-flavored OSes (and, in many cases, developed by people working on a variety of UNIX-flavored OSes, including but not limited to Linux).
Note that the first place the word "Linux" appears on the KDE home page is when it says
Earlier on that page, it says
Note that "Unix" appears twice in that quote, and "Linux" appears zero times; they should arguably replace "Unix operating system" with "Unix-flavored operating systems", or something such as that, given that there is no single collection of software that is the "Unix operating system", i.e. in that context, "Unix operating system" includes Linux, just as much as it includes {Free,Net,Open}BSD, Solaris, HP-UX, etc..
I'm still waiting.... (When I log into a Linux box here, it feels pretty much like any of the other UNIX boxes; it's not exactly the same as any of the others, but Solaris and Digital UNIX aren't exactly the same, either.)
Hmm. Let's take a look at the Berlin Consortium Home Page:
Nothing on the home page says "this is a windowing system for Linux"; the developers may be working on Linux, but they pretty clearly state that it isn't their intent to make this something just for Linux.
Then perhaps you want a way of disabling the tweakable knobs and buttons on machines that the IT folks are managing (I have the impression that Windows NT, at least, has ways of doing so, by setting the appropriate, well, knobs in the registry), or, at least, requiring people to forego centralized management if they want to tweak their boxes.