Anyways, since HP had a hand in with Intel in designing the Merced, will it also be able to emulate PA-RISC based software in addition to x86 software?
Binary compatibility between PA-RISC and IA-64 is handled through dynamic object code translation. This process is very efficient because there is such a high degree of correspondence between PA-RISC and IA-64 instructions. HP's performance studies show that on average the dynamic translator only spends 1-2% of its time in translation with 98-99% of the time spent executing native code. The dynamic translator actually performs optimizations on the translated code to take advantage of IA-64's wider instructions, and performance features such as predication, speculation and large register sets. In addition, if an application has been aggressively optimized for PA-RISC, some of the benefit of the optimizations will carry over to IA-64. In fact, an aggressively optimized PA-RISC application may actually perform faster on IA-64 using the dynamic translator than the same application recompiled at a low level of optimization on an IA-64 compiler. Of course, the best performance will result from a high level of optimization using a good native compiler.
The dynamic translator is designed to run all non-kernel intrusive code, handling both 64-bit and 32-bit instructions. This means operating systems and device drivers typically would not be supported, but all other applications will run. HP's dynamic translator will be bundled with all versions of HP-UX sold for IA-64 systems. When HP-UX encounters code compiled for PA-RISC, it will automatically and transparently invoke the dynamic translator which will allow the code to run on IA-64 without any intervention. Correctness of the dynamic translator has been verified with the same testing regimen used to validate PA-RISC processors.
If I remember correctly, HP used binary-to-binary translation to move code for the stack-based 16-bit HP 3000 machines to the PA-RISC-based 32-bit HP 3000 machines, so they've done this before.
Besides, I don't recall anyone in the Open Source community suggesting that the only good software comes from Open Source projects. Cathedrals are beautiful, after all.
As others have noted, "closed source" vs. "open source" is orthogonal to "tightly controlled" vs. "loosely controlled" - unfortunately, "www.opensource.org" appears to be unreachable from here right now, but I have the impression that the BSDs (other than BSD/OS) would qualify, given that you can get full source to them and you can freely distribute changes to that source. The non-commercial BSDs (i.e., all but BSD/OS) make their source available by anonymous CVS, and probably won't reject all changes sent to them.
One of the "problems" with Linux is that there are forces trying to make it all things to all people.
Does "Linux" here refer to the kernel, or to the various distributions? If it's the latter, there is no "it" - there's a pile of different distributions, some of which, arguably, specialize in something they're intended to do really well.
(And even if it does refer just to the kernel, not all useful kernel stuff is in the Official Kernel Source - that's another place where different distributions could do different things.)
I can see this comment being moderated down right now...)
We often see statements about how *BSD-positive comments are routinely moderated down, but it's funny, they usually are moderated UP, especially if they aren't just taunts.
I'm curious how many comments that start with "I'll bet this gets moderated down" or whatever get moderated down, how many don't get moderated at all, and how many get moderated up.
Perhaps "I'll bet this gets moderated down" is usually just a (sometimes a bit whiny) rhetorical comment, rather than a genuine prediction that the comment will be moderated down to Flamebait Hell.
In fact, the FreeBSD ports collection has both ports and binary packages for KDE 1.1.2, and binary GNOME packages as well.
The KDE news page also announced the availability of KDE 1.1.2 packages for NetBSD (as well as for Solaris - interestingly enough, the announcement said that Solaris x86 was available, and that SPARC would be available shortly; x86 first?).
The OpenBSD ports status page mentions KDE; I don't see any mention of GNOME other than the libghttp GNOME HTTP client library
The only TCO study I've ever seen showing that NT is cheaper than Unix
The page in question has a link to some TCO study, but Nutscrape on NT appears to lock up trying to fetch it; all I saw was that the title seemed to imply that the UNIX box in question was a Sun SPARC box - I sincerely hope a large part of the alleged TCO difference wasn't in the hardware, because, err, umm, last time I checked, Linux (and Solaris/x86, and various other UNIX-flavored OSes, for that matter...) ran on the same hardware that NT ran on.
Um, NT doesn't support PnP either.
Define "support". NT 4.0 does have a (perhaps not officially supported) ISA PnP module that, at least, let it recognize and use the PnP ISA sound card on my machine at home. Of course, at least one non-Microsoft OS also was able to do that (for what it's worth, it didn't happen to be Linux, unless I could've made it happen by setting up some isapnptools configuration file - given that I didn't have to set up that file, perhaps because NT somehow set the device up already, I didn't look into that particularly vigorously).
As far as I know, they support plug-and-play on less irritating buses than ISA (e.g., PCI), in the sense that, when the machine booted after I plugged in a PCI Ethernet card, it saw that the card was there (and may have, when I logged in, asked me to add a driver).
Of course, the other three (non-Microsoft) OSes on the box also recognized that the card was there (and already had drivers, which they enabled, as I remember - I might've had to tell Debian to load the module for it).
In addition, Linux does not support many of the modern operating system features that Windows NT 4.0 has pioneered such as asynchronous I/O...
Gee, maybe somebody oughta tell that Dave Cutler guy about this; he might be a little peeved at Microsoft for asserting that they pioneered asynchronous I/O, given that I seem to remember VMS, hell, RSX-11 supporting it.
and IIRC ext2 is asynchronous by default.
So are, as far as I know, NTFS and VFAT in NT, in that they'll do read-ahead and write-behind.
The "asynchronous I/O" to which they're referring is, I suspect, explicitly asynchronous I/O, e.g. Win32 ReadFile() or WriteFile() with a completion routine...
...or, in systems supporting POSIX asynchronous I/O, aio_read() or aio_write().
I bet their "x86 64" is a 64-bit version of the "RISC-86" internal op-set that Athlon uses, or something similar.
And I bet it's a 64-bit version of the "CISC-86" external instruction set that Athlon and K6 and K5 and Pentium {, Pro, II, III} and 486 and 386 use, given what they said in their press release:
"AMD plans to extend the x86 instruction set to include a 64-bit mode, delivering a simple yet powerful solution that enables all of the performance benefits associated with 64-bit computing, while maintaining compatability and a leading-edge performance roadmap for the existing installed base of x86 32-bit software applications and operating systems," said Weber. "No other 64-bit solution has full native x86 32- and 64-bit compatibility."
Yes, I guess one could, if one really wanted to, read that as saying "extend" in the sense of "add a different instruction set that only a little bit like x86", but I see no reason to believe that's likely to be interpretation AMD had in mind.
"AMD plans to extend the x86 instruction set to include a 64-bit mode, delivering a simple yet powerful solution that enables all of the performance benefits associated with 64-bit computing, while maintaining compatability and a leading-edge performance roadmap for the existing installed base of x86 32-bit software applications and operating systems," said Weber. "No other 64-bit solution has full native x86 32- and 64-bit compatibility."
There's also this random quote in there, also indicating that they don't plan to introduce some Exciting New 64-bit RISC Architecture:
"By extending the x86 instruction set to 64-bits, AMD's x86-64 technology should give us very fast compiler retargetting and the easiest kernel port so far," said Alan Cox, Linux Kernel Developer.
(Yeah, I just about dropped my teeth when I saw a quote from Cox in there....)
Also note that SledgeHammer might be able to run Win95/Win98/WNT4/Win2000 out of the box.
And so will, presumably, Willamette (which, at least as I infer from what I read in Microprocessor Report, will be the next IA-32 core from Intel; they may call it "Pentium IV" or whatever, but it appears it won't be a P6 tweak).
The questions then will be
Which of them will do a better job at running those 32-bit OSes? (The 64-bitness of SledgeHammer will probably be irrelevant for that job.)
To what extent will the ability to run 64-bit OSes be important to those buying SledgeHammer machines who buy them intent of running 32-bit OSes now?
whereas Pentium--which originally referred to its status as the i586--was used again for the i686 and i786 chips.
(i786? Wouldn't that be Willamette? The Pentium III, and the Xeon Warrior Princess flavors of the PII/PIII, are based on the same P6 CPU core, so I'd think of them as i686's.)
I suspect Intel decided to use Pentium as the brand name for (all but the lower-end) IA-32 processors, preserving brand equity or whatever the hell the marketoon term is; I wouldn't be surprised to see McKinley be the Itanium II or something such as that.
I thought that I read somewhere that Netscape was going to use GTK in future versions anyway.
I think they're using it as the UNIX toolkit for Mozilla, but that doesn't handle the DnD problem unless you run Netscape 5.0 or whatever Mozilla-derived release they put out (or run Mozilla).
...but it doesn't seem to be the point he thought he was making. He asked for "GNOME apps that don't require GNOME"; what it sounds as if he really wants are "non-GNOME GTK+ apps".
In most cases it would be sensible to make GNOME linking a compile-time option, if you use it at all.
Unfortunately "sensible" doesn't necessarily mean "easy"; somebody could rely on GNOME's libraries to handle a lot of things, and would have to re-implement those things and set up a "configure" option to control whether to use GNOME stuff or the app's private stuff. Perhaps they should do that, but it might require them to do more work.
easy, you go to the URL. do whatever the app is supposed to do. save locally.
Err, umm, go to which URL? The URL for the object being edited by the word processor, spreadsheet, image editing program, etc.? If so, how is this anything more than allowing URLs, not just file names, in a "File/Open" dialog box or in the app's command line? I'd hardly call that particularly "Web-centric" - you're still writing the app, you just write it so it can use HTTP to read and write files (isn't that something that many KDE apps can already do?).
And who "does whatever the app is supposed to do"? A program running on your machine - i.e., an app running on your machine, just as in that boring nasty old pre-Web-centric universe - or something running elsewhere - in which case how does it interact with you?
you don't HAVE to save your data on a server, you just use the app served to you to do the work and then save locally or remotely.
OK, what makes writing "the app served to you" "writing for the WEB"? If all that happened was that you got some Java app served to you, and it's running locally, perhaps reading local files, and saving the file locally, you haven't "written for the WEB", you've chosen Java/AWT or Java/Swing or whatever, rather than choosing KDE or GNOME or CDE or whatever.
And what if the application is the MP3 player I mentioned? How exactly do you "write that for the Web", other than writing it as a browser plug-in - but, as far as I know, browser plug-ins are cross-platform (unless browsers support Java plugins, but, in that case, see my previous comment about Java apps)?
The interface to everything? A Web browser can replace all the stuff in KOffice, can replace the GIMP, can replace XMMS, can replace Ethereal, can replace....?
Yes, there are a lot of applications that can work as client-server Web apps; I have yet to see anything even remotely resembling solid evidence that all applications can be recast in that fashion.
KDE seems to run fine on my FreeBSD partition; I installed the 1.1.2 binary package a few days ago. Solaris binary packages also exist; people probably run versions from source built on other OSes as well.
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 the lack of a certain word beginning with capital "L" in that; they're not targeting Linux, they're targeting UNIX-flavored OSes, including but not limited to Linux.
Currently, you need a machine with Unix or a Unix-like operating system installed, with the X Window System (X11R5 or later).
Again, note the use of the U word rather than the L word.
You're probably unlikely to get as much enthusiasm from free software developers for CDE as there is for KDE and GNOME until there's a free CDE implementation (speech, not just beer) - there's LessTif, but it's just a Motif implementation, not a full CDE implementation.
the Motif standard and the X standard that came along afterwards.
To which "X standard" are you referring? Xdnd is being adopted by at least three tookits, as far as I know (JX, where I think it originated; GTK+, which implements it in 1.2; Qt implemented it either in a late 1.4 release or 2.0, as I remember), but I don't think it's an Official X Consortium^H^H^H^H^H^H^H^H^H^H^H^HOpen Group^H^H^H^H^H^H^H^H^H^HX.org standard, as far as I know. Has it been adopted by X.org?
Both teams are working on interoperability
I think GTK+ 1.2 also implements the Motif drag-and-drop protocol (which may explain why dropping from the Motif-based Netscape to the GTK+-based GMC worked); what are Troll Tech's and/or the KDE team's plans to implement the Motif DnD protocol?
(acually, I was thinking about how the world needs a calendar/scheduling/intranet -type program that's cross-platform, instead of the Exchange/Bloatus Notes that exists right now), and though "what about a server-based app that used the browser for display."
Just out of curiousity, how would a "Web-based" word processor, or spreadsheet, or image editing program, or network packet capture and analysis program, or MP3 player program, or... work?
I'd be more interested in making Gnome programs compile on a system with just the Gtk+/glib libraries installed,
Given that a "GNOME program" is a program using GNOME facilities, how would compiling a GNOME program be possible on a system without the GNOME libraries and headers? That sounds sort of like wanting to be able to compile GTK+ programs without the GTK+/GLib libraries installed, or to compile X programs without the X libraries installed, or non-GUI programs without "libc" installed, or any programs without a compiler installed....
It sounds as if what you want are GTK+ programs (or Qt programs), not GNOME (or KDE) programs. Such programs do exist; to achieve the goal you want, you presumably want to encourage people to write more such programs.
Define "run over the net". Are we talking about, in effect, time-sharing, in which all the apps run on a server machine, and all interaction with them takes place via a browser?
If so, is it ipso facto the case that all applications
can be made to run in that fashion;
would work as well as, or better than, those not made to run in that fashion?
Note that citing some applications that can run in that fashion, or even that run better in that fashion, doesn't at all demonstrate either that all apps can, or should, be made to run in that fashion.
Indeed? Digital and Intel were involved in the original 3Mb Ethernet? Or were they just involved in producing the 10Mb standard? (Did Xerox have 10Mb Ethernet before the DIX standard came out?)
If, as the Register states in the article I linked to, the K8 is going to be a re-engineered K7, why in the world would they break its support for the IA-32 instruction set?
I have no reason to believe they would. (If you thought I did, you read more into what I said than I put there....)
Like the 486,
(Or the 386....)
the additonal bits aren't the primary selling feature
The additional bits in the 386 weren't the primary selling feature for 16-bit OSes. If there's never a 64-bit OS for x86-64, they might as well just do a really fast implementation of boring old 32-bit x86.
So the only thing that'd make a 64-bit version of the x86 instruction set worthwhile would be, err, umm, an OS that supports the 64-bit mode, and compilers to generate 64-bit code - and, for at least some applications, probably other 64-bit software, e.g. 64-bit database software.
And Linux, already with a single codebase supporting several 64-bit processors in addition to IA-32, would be a natural candidate for a K8-64 port, and it's a major OS for the kind of inexpensive servers the K8 would likely be found in initially.
Maybe a 64-bit Linux port, say, would give its 64-bit mode a use; however, I'm not sure "inexpensive servers" would need a processor with a 64-bit virtual address space (they might want a processor and OS that supports more than 32 bits of physical address, but you can get such an x86 processor from Intel and, presumably, AMD now; I'm not sure what OSes support it - allegedly, W2K will, and I assume Sequent's Dynix/PTX supports it, albeit probably only on Sequent's big NUMA machines.
While I know that lots of *nix's these days (IRIX, Solaris, RedHat) do everything in their power to make you run a GUI on the server, I still see that as a really bad move.
Anybody know whether it's possible to run an X Print server on a headless machine (i.e., a machine with no display on which an X display server could draw)?
Why should I run X on my print server?
XPRINT doesn't require you to do that, as far as I can tell; all an X Print server does is accept X drawing requests, generate page description language output to draw that stuff on paper, and then hand to the print spooler system a file containing that output. You could, as far as I can tell, run the X Print server on your desktop machine, and have it hand the file to the spooler system, which could send it to the print server.
If you're running the program doing the printing on a server, that program would have to talk to an X Print server somewhere, possibly on that machine, or possible on some other machine.
Slashdot Mirror
Not by itself; the code would be translated to IA-64 code by software. This part of HP's versionof the IA-64 Application Instruction Set Architecture Guide says:
If I remember correctly, HP used binary-to-binary translation to move code for the stack-based 16-bit HP 3000 machines to the PA-RISC-based 32-bit HP 3000 machines, so they've done this before.
As others have noted, "closed source" vs. "open source" is orthogonal to "tightly controlled" vs. "loosely controlled" - unfortunately, "www.opensource.org" appears to be unreachable from here right now, but I have the impression that the BSDs (other than BSD/OS) would qualify, given that you can get full source to them and you can freely distribute changes to that source. The non-commercial BSDs (i.e., all but BSD/OS) make their source available by anonymous CVS, and probably won't reject all changes sent to them.
Does "Linux" here refer to the kernel, or to the various distributions? If it's the latter, there is no "it" - there's a pile of different distributions, some of which, arguably, specialize in something they're intended to do really well.
(And even if it does refer just to the kernel, not all useful kernel stuff is in the Official Kernel Source - that's another place where different distributions could do different things.)
I'm curious how many comments that start with "I'll bet this gets moderated down" or whatever get moderated down, how many don't get moderated at all, and how many get moderated up.
Perhaps "I'll bet this gets moderated down" is usually just a (sometimes a bit whiny) rhetorical comment, rather than a genuine prediction that the comment will be moderated down to Flamebait Hell.
In fact, the FreeBSD ports collection has both ports and binary packages for KDE 1.1.2, and binary GNOME packages as well.
The KDE news page also announced the availability of KDE 1.1.2 packages for NetBSD (as well as for Solaris - interestingly enough, the announcement said that Solaris x86 was available, and that SPARC would be available shortly; x86 first?).
The OpenBSD ports status page mentions KDE; I don't see any mention of GNOME other than the libghttp GNOME HTTP client library
The page in question has a link to some TCO study, but Nutscrape on NT appears to lock up trying to fetch it; all I saw was that the title seemed to imply that the UNIX box in question was a Sun SPARC box - I sincerely hope a large part of the alleged TCO difference wasn't in the hardware, because, err, umm, last time I checked, Linux (and Solaris/x86, and various other UNIX-flavored OSes, for that matter...) ran on the same hardware that NT ran on.
Define "support". NT 4.0 does have a (perhaps not officially supported) ISA PnP module that, at least, let it recognize and use the PnP ISA sound card on my machine at home. Of course, at least one non-Microsoft OS also was able to do that (for what it's worth, it didn't happen to be Linux, unless I could've made it happen by setting up some isapnptools configuration file - given that I didn't have to set up that file, perhaps because NT somehow set the device up already, I didn't look into that particularly vigorously).
As far as I know, they support plug-and-play on less irritating buses than ISA (e.g., PCI), in the sense that, when the machine booted after I plugged in a PCI Ethernet card, it saw that the card was there (and may have, when I logged in, asked me to add a driver).
Of course, the other three (non-Microsoft) OSes on the box also recognized that the card was there (and already had drivers, which they enabled, as I remember - I might've had to tell Debian to load the module for it).
Gee, maybe somebody oughta tell that Dave Cutler guy about this; he might be a little peeved at Microsoft for asserting that they pioneered asynchronous I/O, given that I seem to remember VMS, hell, RSX-11 supporting it.
So are, as far as I know, NTFS and VFAT in NT, in that they'll do read-ahead and write-behind.
The "asynchronous I/O" to which they're referring is, I suspect, explicitly asynchronous I/O, e.g. Win32 ReadFile() or WriteFile() with a completion routine...
...or, in systems supporting POSIX asynchronous I/O, aio_read() or aio_write().
And I bet it's a 64-bit version of the "CISC-86" external instruction set that Athlon and K6 and K5 and Pentium {, Pro, II, III} and 486 and 386 use, given what they said in their press release:
Yes, I guess one could, if one really wanted to, read that as saying "extend" in the sense of "add a different instruction set that only a little bit like x86", but I see no reason to believe that's likely to be interpretation AMD had in mind.
That's precisely what the AMD press release says they're going to do:
There's also this random quote in there, also indicating that they don't plan to introduce some Exciting New 64-bit RISC Architecture:
(Yeah, I just about dropped my teeth when I saw a quote from Cox in there....)
And so will, presumably, Willamette (which, at least as I infer from what I read in Microprocessor Report, will be the next IA-32 core from Intel; they may call it "Pentium IV" or whatever, but it appears it won't be a P6 tweak).
The questions then will be
(i786? Wouldn't that be Willamette? The Pentium III, and the Xeon Warrior Princess flavors of the PII/PIII, are based on the same P6 CPU core, so I'd think of them as i686's.)
I suspect Intel decided to use Pentium as the brand name for (all but the lower-end) IA-32 processors, preserving brand equity or whatever the hell the marketoon term is; I wouldn't be surprised to see McKinley be the Itanium II or something such as that.
I think they're using it as the UNIX toolkit for Mozilla, but that doesn't handle the DnD problem unless you run Netscape 5.0 or whatever Mozilla-derived release they put out (or run Mozilla).
...but it doesn't seem to be the point he thought he was making. He asked for "GNOME apps that don't require GNOME"; what it sounds as if he really wants are "non-GNOME GTK+ apps".
Unfortunately "sensible" doesn't necessarily mean "easy"; somebody could rely on GNOME's libraries to handle a lot of things, and would have to re-implement those things and set up a "configure" option to control whether to use GNOME stuff or the app's private stuff. Perhaps they should do that, but it might require them to do more work.
Err, umm, go to which URL? The URL for the object being edited by the word processor, spreadsheet, image editing program, etc.? If so, how is this anything more than allowing URLs, not just file names, in a "File/Open" dialog box or in the app's command line? I'd hardly call that particularly "Web-centric" - you're still writing the app, you just write it so it can use HTTP to read and write files (isn't that something that many KDE apps can already do?).
And who "does whatever the app is supposed to do"? A program running on your machine - i.e., an app running on your machine, just as in that boring nasty old pre-Web-centric universe - or something running elsewhere - in which case how does it interact with you?
OK, what makes writing "the app served to you" "writing for the WEB"? If all that happened was that you got some Java app served to you, and it's running locally, perhaps reading local files, and saving the file locally, you haven't "written for the WEB", you've chosen Java/AWT or Java/Swing or whatever, rather than choosing KDE or GNOME or CDE or whatever.
And what if the application is the MP3 player I mentioned? How exactly do you "write that for the Web", other than writing it as a browser plug-in - but, as far as I know, browser plug-ins are cross-platform (unless browsers support Java plugins, but, in that case, see my previous comment about Java apps)?
The interface to everything? A Web browser can replace all the stuff in KOffice, can replace the GIMP, can replace XMMS, can replace Ethereal, can replace....?
Yes, there are a lot of applications that can work as client-server Web apps; I have yet to see anything even remotely resembling solid evidence that all applications can be recast in that fashion.
KDE seems to run fine on my FreeBSD partition; I installed the 1.1.2 binary package a few days ago. Solaris binary packages also exist; people probably run versions from source built on other OSes as well.
Note that the KDE home page says:
Note the lack of a certain word beginning with capital "L" in that; they're not targeting Linux, they're targeting UNIX-flavored OSes, including but not limited to Linux.
The GNOME site doesn't say "not for Linux only" on the home page, but the "What is GNOME" part of the GNOME FAQ says nothing about it being targeted only for Linux, and the "What are the system requirements for GNOME" part says
Again, note the use of the U word rather than the L word.
You're probably unlikely to get as much enthusiasm from free software developers for CDE as there is for KDE and GNOME until there's a free CDE implementation (speech, not just beer) - there's LessTif, but it's just a Motif implementation, not a full CDE implementation.
To which "X standard" are you referring? Xdnd is being adopted by at least three tookits, as far as I know (JX, where I think it originated; GTK+, which implements it in 1.2; Qt implemented it either in a late 1.4 release or 2.0, as I remember), but I don't think it's an Official X Consortium^H^H^H^H^H^H^H^H^H^H^H^HOpen Group^H^H^H^H^H^H^H^H^H^HX.org standard, as far as I know. Has it been adopted by X.org?
I think GTK+ 1.2 also implements the Motif drag-and-drop protocol (which may explain why dropping from the Motif-based Netscape to the GTK+-based GMC worked); what are Troll Tech's and/or the KDE team's plans to implement the Motif DnD protocol?
Is Yahoo Calendar such an application?
Just out of curiousity, how would a "Web-based" word processor, or spreadsheet, or image editing program, or network packet capture and analysis program, or MP3 player program, or... work?
Given that a "GNOME program" is a program using GNOME facilities, how would compiling a GNOME program be possible on a system without the GNOME libraries and headers? That sounds sort of like wanting to be able to compile GTK+ programs without the GTK+/GLib libraries installed, or to compile X programs without the X libraries installed, or non-GUI programs without "libc" installed, or any programs without a compiler installed....
It sounds as if what you want are GTK+ programs (or Qt programs), not GNOME (or KDE) programs. Such programs do exist; to achieve the goal you want, you presumably want to encourage people to write more such programs.
Define "run over the net". Are we talking about, in effect, time-sharing, in which all the apps run on a server machine, and all interaction with them takes place via a browser?
If so, is it ipso facto the case that all applications
Note that citing some applications that can run in that fashion, or even that run better in that fashion, doesn't at all demonstrate either that all apps can, or should, be made to run in that fashion.
Indeed? Digital and Intel were involved in the original 3Mb Ethernet? Or were they just involved in producing the 10Mb standard? (Did Xerox have 10Mb Ethernet before the DIX standard came out?)
Yup, as I said.
I have no reason to believe they would. (If you thought I did, you read more into what I said than I put there....)
(Or the 386....)
The additional bits in the 386 weren't the primary selling feature for 16-bit OSes. If there's never a 64-bit OS for x86-64, they might as well just do a really fast implementation of boring old 32-bit x86.
So the only thing that'd make a 64-bit version of the x86 instruction set worthwhile would be, err, umm, an OS that supports the 64-bit mode, and compilers to generate 64-bit code - and, for at least some applications, probably other 64-bit software, e.g. 64-bit database software.
Maybe a 64-bit Linux port, say, would give its 64-bit mode a use; however, I'm not sure "inexpensive servers" would need a processor with a 64-bit virtual address space (they might want a processor and OS that supports more than 32 bits of physical address, but you can get such an x86 processor from Intel and, presumably, AMD now; I'm not sure what OSes support it - allegedly, W2K will, and I assume Sequent's Dynix/PTX supports it, albeit probably only on Sequent's big NUMA machines.
Anybody know whether it's possible to run an X Print server on a headless machine (i.e., a machine with no display on which an X display server could draw)?
XPRINT doesn't require you to do that, as far as I can tell; all an X Print server does is accept X drawing requests, generate page description language output to draw that stuff on paper, and then hand to the print spooler system a file containing that output. You could, as far as I can tell, run the X Print server on your desktop machine, and have it hand the file to the spooler system, which could send it to the print server.
If you're running the program doing the printing on a server, that program would have to talk to an X Print server somewhere, possibly on that machine, or possible on some other machine.
That's what the XPRINT extension supports; it then hands the resulting output to whatever print spooler system you have.