IBM already has Unix(AIX) running on S/390. It is called Unix System Services
It is "UNIX" in the sense that it passed the UNIX 95 test suite, but it's not an AIX port - it's part of OS/390 and, as noted in another post, it's different from what you might think of as "real UNIX" in some ways; for example, it does not use ASCII as its character set.
Thus:
I guess my real question would be why would IBM want to port Linux for the mainframe when they already have AIX running smoothly there?? Can anyone tell me what you gain from running Linux instead of Unix????
...that question might better be phrased as "Can anyone tell me what you gain from running a native UNIX-compatible operating system instead of Unix System Services?", in which case the answer may be (as per the VNUNET article) that a native UNIX-compatible operating system such as Linux may look "more like real UNIX" than even the it-passed-the-UNIX-95-suite Unix System Services in some ways - ways that might make it easier to port to Linux than to Unix System Services.
One might ask why they'd want to port Linux rather than, say, revive the old "real UNIX" port of native AIX they once had (I don't know whether they still offer it or not); I don't know whether it's because
AIX/370 looked less like other current UNIXes than does Linux;
AIX/370 is a bit out of date now and they decided that a Linux port would be less work than modernizing AIX/370;
AIX/370 isn't "AIX/390", and would take a fair bit of work to get it to make full use of the capabilities of System/390;
Rather, this is probably closer to how FreeBSD "emulates" Linux: It provides a compatible Application Binary Interface
Given that the only "emulator" I saw mentioned in the article was for AIX, and that by AIX they probably mean AIX for RS/6000, and that most if not all current RS/6000's use the PowerPC member of the POWER family of architectures, and that Linux also supports PowerPC, that's possible.
However, what the article said was:
In September IBM announced software it described as a Linux emulator. This provides an application program interface which allows Linux applications to be
recompiled to run on IBM's own AIX variant of Unix.
(emphasis mine). That suggests that there's no ABI compatibility involved, just API - Application Programming Interface - compatibility.
In any case, the only ways to provide the ability for IBM mainframes running OS/390 to run Linux binaries would be
include code to "emulate one machine on another", e.g. emulating an x86 on an S/390;
run binaries intended to run on, say, a Linux port to an S/390.
IBM already have "a POSIX to OS/390 translation layer", in a sense - they have a UNIX-compatible environment, in the sense that it passed the UNIX 95 test suite, so at least some programs can presumably be recompiled to run in that environment...
I infer from the article that part of the rationale for a Linux/390 port is to make it easier to port applications from UNIX environments - OS/390's UNIX environment may not be enough like "Real UNIX", implemented, as it is, atop a different OS, and using a different native character set, and so on, to allow quick porting, whereas Linux systems look enough like "Real UNIX" to me, at least, for me to consider them to be "Real UNIX", even though the Open Group don't yet have any Official Certification Results for any Linux system but do have one for OS/390.
IBM's newer mainframes are all pretty standardised, consisting of multiple Power or PowerPC cores linked together.
Indeed? If so, then those "Power or PowerPC cores" are presumably interpretively executing the System/3x0 instruction set, which is not, and has never been, a derivative of POWER. (POWER and its descendants are load/store 32-general-register RISC architectures; S/3x0 is a 16-general-register CISC architecture with register/memory arithmetic instructions.)
They're mainframes. These are not normal computers.
Err, umm, once upon a time, mainframes were one of the few sorts of "normal computers" around. They don't look like PC's, but PC's are the only type of "normal" computers if you take "normal" literally, as in "average", as in "the average computer, by sheer numbers, is probably a PC" (I neglect embedded systems here, which I suspect may well outnumber even "IBM-compatible PC's").
They may not even have conventional CPUs at all.
The S/3x0 instruction set is pretty conventional - 32-bit, 16 general registers, register-register/register-memory/memory-memory instructions, most of which are boring old load, store, add, subtract, multiply, divide, etc., with various more exotic add-ons. Just because something's a mainframe, that doesn't mean its instruction set and CPU are immensely exotic.... (The Burroughs mainframes, and their Unisys A-series successors, have a fairly exotic instruction set, but IBM mainframes don't.) The ESA/390 Principles of Operation manual documents the S/390 instruction set.
That's why most mainframe programs are written for the VM which hides the actual hardware from the programmer.
If by "the VM" you mean "VM/390" or whatever it's called these days:
it doesn't hide the underlying user-mode instruction set from the programmer, it just provides a simulated "bare hardware" machine letting you run various S/390 OSes at the same time on the same machine;
I doubt that "most mainframe programs" are written for it - the programs that run atop VM are largely OSes, and the applications are presumably written for those OSes (OS/390, ESA/VM or whatever DOS/360 turned into, etc.).
Perhaps you're thinking of System/38 and AS/400, where the compilers used by application programmers don't generate native machine code, they generate code for a virtual machine, and the low-level OS code ("system licensed internal code") translates that code into the native machine code for the particular machine, if it hasn't already been done, in order to run it (that native machine code being a System/3x0-like instruction set on older machines, and an extended flavor of PowerPC on newer machines).
Perhaps porting the X server code would make no sense (although there do exist graphical terminals for mainframes - I think they're still used for engineering and scientific work), but the X client code might be useful.
SMP: this is really an Intel thing
As far as I know, "SMP", meaning "symmetrical multi-processing", as in "multiple processors, without particular processors being devoted to particular tasks such as 'one processor runs OS kernel code and another runs user-mode code' or 'only one of the processors is allowed to ever run kernel code' (as opposed to, say, a single kernel lock allowing only one processor at a time to run kernel code), has, as a term, been around longer than have SMP systems with Intel processors. SMP systems, whatever they've been called, have definitely been around longer than have SMP systems with Intel processors....
In what sense? The Transmeta patents, if they describe what Transmeta will be doing (as opposed to, say, something they looked at doing at one point, but abandoned), seem to imply that its native instruction set is not x86, and that, to run x86 code, it needs software that'll translate x86 code to native code, and run it.
(That also implies that it'd presumably be capable of translating code for other processors into its native instruction set at well.)
Of course, that might also permit different processors to have different native instruction sets - you'd have to recompile and/or rewrite the core native code (which would include the translating code), but other code could be translated to the native instruction set appropriate for the processor in question.
(This is not a new idea - IBM's AS/400 switched from a System/360-ish instruction set to PowerPC in that fashion, and I have the impression the 360ish instruction set also changed over the lifetime of System/38 and AS/400.)
Even in a case where the device support is built as a module, the kernel must know the module is there which requires it to be compiled in.
I suspect that, if it's not already possible to have the kernel find a driver module given only, say a PCI vendor/device ID for the device (I seem to remember, possibly in a Kernel Traffic summary, discussion of doing something along those lines for USB), it could be done, so I doubt this is inherent to Linux.
Whereas a system like MS Windows is message-based; an application can send a message saying "I need to print", the OS gets the message and simply passes it on; if there is anything on the system that listens for that type of message (i.e. a printer driver) it gets the message and handles the print job.
Is that kernel-mode code? Or is it something that could be implemented in userland atop the Linux kernel and API libraries (or atop other UNIX-flavored OSes kernel and API libraries)? I have the impression that the print subsystem largely lives in userland in Windows NT (I'm not sure there's a strict distinction between userland and kernel code in Windows OT).
I.e.,
I suspect this is not, in any way, an intrinsic characteristic of the Linux kernel;
not all drivers, in the sense of "software that knows how to make a given piece of hardware do something", live in the kernel (consider, for example, the video-card drivers that live in X servers).
Linux (and other OSes to which source is made widely available) may allow you to build kernels more finely tailored to particular hardware than other OSes (although I don't know what you get with, say, Embedded NT), but that doesn't mean that they're necessarily better suited for embedded use than general-purpose desktop use - I've seen nothing to indicate that it's intrinsically impossible to build an OS that can both be built for a specific hardware configuration and be built as a more "generic" OS with the ability to load arbitrary drivers, or, if it is possible, that the resulting OS would necessarily suffer from being so built.
That alien technology they are using is based on Field Gate Programmable Arrays.
They are building a chip that can reconfigure its circuitry
Upon what do you base your hypothesis that this involves reconfigurable circuitry? Not on
smart CPU, the first microprocessor built with software
given that one could do that with a CPU with a fixed instruction set and a pile of software to do binary-to-binary translation of instructions from various instruction sets to the native instruction set...
...along the lines of what the Transmeta patents mentioned by various Slashdot articles have described.
Now let's hope that IBM starts shipping only Linux machines w/ Apache web server software...
I think IBM's still making money selling the descendants of that line of computers they came out with in 1963 or so (System/360's descendant, the System/390), as well as the descendants of that line of computers they came out with in the middle or late '70's (System/3x's descendant, the AS/400), so I don't expect that to happen in the near future.
If customers are willing to pay them money for boxes that aren't Linux machines running Apache, it's not clear that it'd make sense for IBM to refuse to sell them those machines. Perhaps those are all legacy machines, but it may still cost somebody less to buy a non-Linux (or non-UNIX in general) machine than to convert their application right now. (Besides, I wouldn't be surprised to see Linux and Apache - along with Windows and Solaris and HP-UX and Digital^H^H^H^H^H^H^HTru64 UNIX and... and IIS and Netscape Enterprise Server and... - become "legacy systems" some day....)
However, Transmeta does seem to be the first to take the concept to this extreme
Which concept? The concept of doing the reconfigurability in software, rather than in hardware as is the case with an FPGA?
The patents they have all seem to imply that the processor does have a native instruction set, that code in other instruction sets is translated to the native instruction set by software, and that at least some of the fancy hardware features are intended to let the translators make very optimistic assumptions when they translate the code, with the code faulting if the assumptions aren't valid, and the software then recovering and re-translating with less optimistic assumptions.
This is to protect EU industries from the US's use of its suveillance technology to give US-based companies an industrial lead.
I'm curious whether any non-US countries have done this as well (no, this is not an attempt at a "well, everybody does it" argument - I'm just curious whether the US is the only major power indulging in that sort of activity).
Most apps will copy to the clipboard by simply selecting text, and paste from the clipboard with the middle mouse button.
They set the primary selection by selecting text, and paste the primary selection with the middle mouse button.
The primary selection is not the clipboard; I just tested that with both the Motif-based Netscape and the GTK+-based Ethereal; selecting text, doing Alt+C in Netscape or Ctrl+C in Ethereal, and then selecting some different text caused the latter text - i.e., the primary selection - to be pasted with the middle mouse button and the former text - i.e., the clipboard - to be pasted with Alt+V in Netscape and Ctrl+V in Ethereal.
Running xclipboard while doing this also indicated that selecting text does not copy it to the clipboard, but Alt+C/Ctrl+C does.
And, yes, the distinction is relevant - the person who complained that paste-current-selection requires you to clear the field to which you want to paste it (rather than just selecting and pasting the clipboard, which replaces the selected text with the clipboard) was complaining about not being able to copy to the clipboard so that you can paste it and replace the currently selected text. (Yes, many applications let you clear the target of the paste-current-selection with Ctrl+U, but....)
Qt (and thus KDE) has a class which allows for the sending of text to the X clipboard.
Indeed? I didn't find the string "CLIPBOARD" anywhere in the Qt 1.44 or Qt 2.0.2 source; it may be called QClipboard, but it only appears to refer to the PRIMARY selection, not the CLIPBOARD selection.
My guess is that Motif, Gtk+, and all the other widget sets and toolkits give the developer convenient access to the X clipboard, as well
Motif - yes, as I remember. GTK+ - GtkEditable and its subclasses appear to copy to the clipboard, and "gtk/gtkeditable.c" definitely interns the CLIPBOARD atom. I can't speak for other toolkits, although it'd be nice if they all did (including Qt...).
Sigh. Maybe Qt doesn't use the CLIPBOARD selection the way other toolkits/applications expect.
In fact, a quick look at the Qt 1.44 source suggests that the only selection it does anything with is the primary selection, and the same appears to apply to Qt 2.0.2, so if KDE 1.x or 2.x uses the CLIPBOARD selection, it's done by KDE code rather than Qt code.
For some reason, there's no XA_CLIPBOARD atom for the CLIPBOARD selection, as there are for the PRIMARY and SECONDARY selections - but the ICCCM does discuss the CLIPBOARD selection (section L.2.6.1.3, "The CLIPBOARD Selection", in the X11R5 version of the X Protocol Reference Manual in the O'Reilly series of X manuals), so the lack of an XA_CLIPBOARD atom is insufficient reason not to use that selection....
As for alt-vs-ctrl in Netscape: Why??? I can't think of any reason why alt would be used rather than ctrl.
Maybe it's a Motif quirk?
The Motif 1.2 Style Guide says, in section 4.3.1 Clipboard Transfer, that the "Cut" key (which they seem to imply could be implemented by a combination of other keys) or Shift+Delete "must cut selected elements of the target component to the clipboard", the "Copy" key or Ctrl+Insert "must copy selected elements of the target component to the clipboard", and the "Paste" key or Shift+Insert "must paste the contents of the clipboard at the insertion position of the target component", so it seems to be inclined towards Shift+Delete rather than Control+X or Alt+X for Cut, Ctrl+Insert rather than Control+C or Alt+C for Copy, and Shift+Insert rather than Control+V orAlt+V for Paste, so I don't think it's a Motif quirk - I think it's a Netscape quirk.
I've never been able to paste text into Netscape. You cannot use the menu options or shortcut keys to paste text from KWrite to Netscape.
If control-C copies text in KWrite, try using control-C to copy text in KWrite and using Alt+V to paste it in Netscape. Control-C copies text in GTK+, so I copied a bit of text from a GTK+ application using control-C, and pasted it to Netscape using Alt+V. (The text was "eat me", a phrase that sums up my personal attitude towards Netscape's Alt-oriented key bindings.... Yes, there's presumably some reason why Netscape works that way. That's unlikely to make those key bindings less irritating to me....)
Now, why didn't I *know* this other way? I've been using Linux since 1993. Maybe we need an X tutorial?
Probably not a bad idea.
Note that "X" has many levels - the core X protocol only specifies, as I remember, that the notion of "selections" exist, and the ICCCCCCCCCCCCCCCCM (Inter-Client Communications Conventions Manual, or so) specifies only that there exist selections with names such as PRIMARY ("the stuff that's inverse video because you selected it"), SECONDARY (does anything use this other than XView?), and CLIPBOARD ("the stuff that got copied to the clipboard, unless the CLIPBOARD selection holder exited - xclipboard will at least allow that to survive said owner exiting, although it may only preserver the text version of it) and, I think, the way they're intended to be used.
It's the toolkits and applications that implement stuff such as control-{X,C,V} as cut/copy/paste, and "paste primary selection" with the middle mouse button, so not everything running on X necessarily implements all those conventions, or implements them using the same mouse and keyboard bindings (for example, XView, being an OPEN LOOK toolkit, has its own keyboard and mouse bindings; the middle button, as I remember, means "extend selection" there, rather than "paste current selection").
You have to go through the AGONIZINGLY slow process of using the backspace or delete key and waiting for each and every character to be deleted individually.
Some (but not all) applications and/or toolkits support control-U as a way of erasing an entire text field (Netscape on UNIX being one of them; the GTK+ toolkit does as well).
I DO wish there were a TRUE global clipboard, that stored text regardless of whether or not it was still highlighted, and text has to be deliberately replaced there...
You mean like the X CLIPBOARD selection, which many - but, alas, not all - applications support. (Then again, not all applications necessarily support "paste primary selection" - the mechanism you describe, which is quite often mislabeled "cut and paste" - either.)
...control-c or something standard like that. (What's this alt-c garbage Netscape does?
I don't know why Netscape insists on using Alt for so many keyboard accelerators, unless it's an attempt to avoid colliding with the Emacs key bindings it offers in some situations. GTK+, at least for some text widgets, binds "copy to the CLIPBOARD selection" to...
...control-C. For example, you can use control-C to copy text from a text field, control-X to cut text from a text field, and control-V to paste text into a text field.
I wouldn't be surprised to find that Qt did so as well, at least when configured to provide a Windows-style UI (I think Motif might use some other bindings for cut/copy/paste - I heard a claim that they were pre-Windows 3.1 keys, used by Windows in an attempt to avoid getting beaten up by Apple, who appear to use +{C,V,X} for hose functions, and that 3.1 went to Control-{C,V,X} when Apple's suit ceased to be a threat - so maybe Qt uses those bindings when configured to provide a Motif-style UI).
At some point I noticed Sun called Solaris an "Operating Environment", and I've started using this convenient term to mean everything including utilities, window system etc. That way "OS" can just refer to the kernel.
...which isn't what Sun refers to when they say "OS"; "SunOS" includes more than just "/vmunix" plus loadable kernel modules (pre-5.0) or "/kernel/{gen}unix" plus loadable kernel modules (5.0 and later) - it includes a pile of shared libraries, as well as daemons and utilities.
"Solaris" is "SunOS" plus the window system (X server, API libraries, window managers, file managers, GUI utilities,...).
Note that the SunOS API is implemented by the shared libraries and kernel code below it - the API is more than just the system calls, and Sun may well change the implementation of those APIs in ways that would, say, cause statically-linked programs, or programs that duplicate the functions of those APIs by directly making system calls, not to work on later OS releases.
(I know, gtk is in the ports tree, but it is never up to date).
According to the X11-toolkits page in the FreeBSD ports collection, the current version in the collection is 1.2.6. and, according to the GTK web site and the GTK mirror FTP site I tried, at least, the current version is 1.2.6. (The main site was being too slow; maybe 1.2.7 just came out, but....)
FreeBSD works pretty well for me as a workstation OS; it appeared to be less of a pain to get my plug-and-play ISA sound card to work on it than it would be on Debian 2.1 (the 2.0[.x] kernel patch didn't work out of the box, and I didn't particularly want to spend a lot of time doing kernel debugging; I guess I could've tried the isapnptools stuff, but, at that point, I already had a free OS that handled the sound card, so...).
Your mileage may vary - others may find some particular Linux distribution (or some particular non-free OS, or even some particular non-UNIX-flavored OS) better as a workstation OS, or, for that matter, as a server OS, for their purpose than one of the BSDs, and others might find one of the BSDs better, and so on.
The NetApp is a BSD machine. NetBSD if I'm not mistaking.
You are mistaken. NetApp boxes do *N*O*T* run any flavor of BSD as their OS.
The underlying kernel is one written at NetApp; it doesn't support multiple address spaces, any notion of userland, or demand paging (heck, until recently, it didn't even change the page tables; it now uses the paging hardware, but only to make virtually contiguous physically-discontiguous pages, to make allocation of large chunks of memory a bit less painful).
A significant part of the of the code did from BSD - the networking stack came from BSD (4.4-Lite, with some bits of the FreeBSD and NetBSD stacks thrown in), as did many of the commands (although those had to be chainsawed a bit to run in kernel mode in a shared address space), as did the dump and restore code (although the dump code was significantly changed to work with our WAFL file system). Various support routines also came from various BSDs as well, and the NFS server code is somewhat remotely derived from the BSD code (although it was also significantly changed to fit into our environment as well).
However, that doesn't mean NetApp boxes run anything you'd recognize as "BSD" (and, in particular, the crash-dumping code isn't BSD-derived, although the savecore command is based on the BSD command, although, again, significantly modified to run in our environment, and to extract the core dump information from the core dump areas on the disks).
(Yes, I know this first hand. I'm one of the developers there, and have been since early 1994.)
IRIX machines have been doing this for quite a while....
IRIX isn't Sun's UNIX, it's SGI's UNIX. They're unlikely to sue themselves for stealing an idea from IRIX....
BSD, as others have noted, has had it for ages; many other flavors of UNIX probably got the idea (and, in some if not all cases, the code) from BSD.
Re:Yeah, but the Phantom Menace parody was better.
on
Quickie Fu
·
· Score: 2
"HTTP Error 403 Forbidden: Directory listing denied This Virtual Directory does not allow contents to be listed."
I'd say "another wonderful Microsoft innovation", but, although I have the impression that "Virtual Directories" may be an IISism, I think I've seen similarly useful responses to other attempts to trim URLs on sites not obviously using IIS.
<rant>After all, the purpose of a Web site isn't to provide lots of information - where's the profit in that, to a corporation or other organization providing a Web site? - it's to provide lots of advertising and persuasion to get you not only to buy the stuff the corporation sells, but to get you to buy the particular stuff they want you to buy.</rant>
Re:Yeah, but the Phantom Menace parody was better.
on
Quickie Fu
·
· Score: 2
"HTTP Error 403 Forbidden: Directory listing denied This Virtual Directory does not allow contents to be listed."
I'd say "another wonderful Microsoft innovation", but, although I have the impression that "Virtual Directories" may be an IISism, I think I've seen similarly useful responses to other attempts to trim URLs on sites not obviously using IIS.
<rant>After all, the purpose of a Web site isn't to provide lots of information - where's the profit in that, to a corporation or other organization providing a Web site - it's to provide lots of advertising and persuasion to get you not only to buy the stuff the corporation sells, but to get you to buy the particular stuff they want you to buy.</rant>
Re:Yeah, but the Phantom Menace parody was better.
on
Quickie Fu
·
· Score: 2
I don't know if there's an "official" site for it or not.
The official site is The Editing Room, which is the site where the Matrix parody was (geeze, doesn't anybody try trimming down URLs from the right to see what else is there any more?). They have an archives page, and the The Phantom Menace link takes you to the official home of that particular parody.
Slashdot Mirror
It is "UNIX" in the sense that it passed the UNIX 95 test suite, but it's not an AIX port - it's part of OS/390 and, as noted in another post, it's different from what you might think of as "real UNIX" in some ways; for example, it does not use ASCII as its character set.
Thus:
...that question might better be phrased as "Can anyone tell me what you gain from running a native UNIX-compatible operating system instead of Unix System Services?", in which case the answer may be (as per the VNUNET article) that a native UNIX-compatible operating system such as Linux may look "more like real UNIX" than even the it-passed-the-UNIX-95-suite Unix System Services in some ways - ways that might make it easier to port to Linux than to Unix System Services.
One might ask why they'd want to port Linux rather than, say, revive the old "real UNIX" port of native AIX they once had (I don't know whether they still offer it or not); I don't know whether it's because
Given that the only "emulator" I saw mentioned in the article was for AIX, and that by AIX they probably mean AIX for RS/6000, and that most if not all current RS/6000's use the PowerPC member of the POWER family of architectures, and that Linux also supports PowerPC, that's possible.
However, what the article said was:
(emphasis mine). That suggests that there's no ABI compatibility involved, just API - Application Programming Interface - compatibility.
In any case, the only ways to provide the ability for IBM mainframes running OS/390 to run Linux binaries would be
IBM already have "a POSIX to OS/390 translation layer", in a sense - they have a UNIX-compatible environment, in the sense that it passed the UNIX 95 test suite, so at least some programs can presumably be recompiled to run in that environment...
...as long as they, say, don't assume that the characters "A" through "Z" or "a" through "z" are encoded as a contiguous set of values; their UNIX environment uses EBCDIC, not ASCII, as its character set. (Here's the home page for the OS/390 UNIX System Services.)
I infer from the article that part of the rationale for a Linux/390 port is to make it easier to port applications from UNIX environments - OS/390's UNIX environment may not be enough like "Real UNIX", implemented, as it is, atop a different OS, and using a different native character set, and so on, to allow quick porting, whereas Linux systems look enough like "Real UNIX" to me, at least, for me to consider them to be "Real UNIX", even though the Open Group don't yet have any Official Certification Results for any Linux system but do have one for OS/390.
Indeed? If so, then those "Power or PowerPC cores" are presumably interpretively executing the System/3x0 instruction set, which is not, and has never been, a derivative of POWER. (POWER and its descendants are load/store 32-general-register RISC architectures; S/3x0 is a 16-general-register CISC architecture with register/memory arithmetic instructions.)
Err, umm, once upon a time, mainframes were one of the few sorts of "normal computers" around. They don't look like PC's, but PC's are the only type of "normal" computers if you take "normal" literally, as in "average", as in "the average computer, by sheer numbers, is probably a PC" (I neglect embedded systems here, which I suspect may well outnumber even "IBM-compatible PC's").
The S/3x0 instruction set is pretty conventional - 32-bit, 16 general registers, register-register/register-memory/memory-memory instructions, most of which are boring old load, store, add, subtract, multiply, divide, etc., with various more exotic add-ons. Just because something's a mainframe, that doesn't mean its instruction set and CPU are immensely exotic.... (The Burroughs mainframes, and their Unisys A-series successors, have a fairly exotic instruction set, but IBM mainframes don't.) The ESA/390 Principles of Operation manual documents the S/390 instruction set.
If by "the VM" you mean "VM/390" or whatever it's called these days:
Perhaps you're thinking of System/38 and AS/400, where the compilers used by application programmers don't generate native machine code, they generate code for a virtual machine, and the low-level OS code ("system licensed internal code") translates that code into the native machine code for the particular machine, if it hasn't already been done, in order to run it (that native machine code being a System/3x0-like instruction set on older machines, and an extended flavor of PowerPC on newer machines).
A port is in progress, according to the Linux on the IBM ESA/390 Mainframe Architecture page. ("A port of glibc has been started. System calls work. Signals don't.")
Perhaps porting the X server code would make no sense (although there do exist graphical terminals for mainframes - I think they're still used for engineering and scientific work), but the X client code might be useful.
As far as I know, "SMP", meaning "symmetrical multi-processing", as in "multiple processors, without particular processors being devoted to particular tasks such as 'one processor runs OS kernel code and another runs user-mode code' or 'only one of the processors is allowed to ever run kernel code' (as opposed to, say, a single kernel lock allowing only one processor at a time to run kernel code), has, as a term, been around longer than have SMP systems with Intel processors. SMP systems, whatever they've been called, have definitely been around longer than have SMP systems with Intel processors....
Nope. It's a 16-general-register CISC instruction set (dating back to the early 1960's). The Linux on the IBM ESA/390 Mainframe Architecture page has a link to the the ESA/390 Principles of Operation manual, which describes the instruction set.
...which presumably means "the best desktop for you is the one you prefer".
...for you. For others, of course, that is not necessarily the case, as per "the best desktop is the one you prefer".
(Or, to put it another way, be careful not to confuse personal taste with universal truth - a rule advocates of any choice should take to heart.)
Which vendors, if any, ship CDE 2.1 as their standard desktop, rather than CDE 1.x?
In what sense? The Transmeta patents, if they describe what Transmeta will be doing (as opposed to, say, something they looked at doing at one point, but abandoned), seem to imply that its native instruction set is not x86, and that, to run x86 code, it needs software that'll translate x86 code to native code, and run it.
(That also implies that it'd presumably be capable of translating code for other processors into its native instruction set at well.)
Of course, that might also permit different processors to have different native instruction sets - you'd have to recompile and/or rewrite the core native code (which would include the translating code), but other code could be translated to the native instruction set appropriate for the processor in question.
(This is not a new idea - IBM's AS/400 switched from a System/360-ish instruction set to PowerPC in that fashion, and I have the impression the 360ish instruction set also changed over the lifetime of System/38 and AS/400.)
I suspect that, if it's not already possible to have the kernel find a driver module given only, say a PCI vendor/device ID for the device (I seem to remember, possibly in a Kernel Traffic summary, discussion of doing something along those lines for USB), it could be done, so I doubt this is inherent to Linux.
Is that kernel-mode code? Or is it something that could be implemented in userland atop the Linux kernel and API libraries (or atop other UNIX-flavored OSes kernel and API libraries)? I have the impression that the print subsystem largely lives in userland in Windows NT (I'm not sure there's a strict distinction between userland and kernel code in Windows OT).
I.e.,
Linux (and other OSes to which source is made widely available) may allow you to build kernels more finely tailored to particular hardware than other OSes (although I don't know what you get with, say, Embedded NT), but that doesn't mean that they're necessarily better suited for embedded use than general-purpose desktop use - I've seen nothing to indicate that it's intrinsically impossible to build an OS that can both be built for a specific hardware configuration and be built as a more "generic" OS with the ability to load arbitrary drivers, or, if it is possible, that the resulting OS would necessarily suffer from being so built.
Upon what do you base your hypothesis that this involves reconfigurable circuitry? Not on
given that one could do that with a CPU with a fixed instruction set and a pile of software to do binary-to-binary translation of instructions from various instruction sets to the native instruction set...
...along the lines of what the Transmeta patents mentioned by various Slashdot articles have described.
I think IBM's still making money selling the descendants of that line of computers they came out with in 1963 or so (System/360's descendant, the System/390), as well as the descendants of that line of computers they came out with in the middle or late '70's (System/3x's descendant, the AS/400), so I don't expect that to happen in the near future.
If customers are willing to pay them money for boxes that aren't Linux machines running Apache, it's not clear that it'd make sense for IBM to refuse to sell them those machines. Perhaps those are all legacy machines, but it may still cost somebody less to buy a non-Linux (or non-UNIX in general) machine than to convert their application right now. (Besides, I wouldn't be surprised to see Linux and Apache - along with Windows and Solaris and HP-UX and Digital^H^H^H^H^H^H^HTru64 UNIX and... and IIS and Netscape Enterprise Server and... - become "legacy systems" some day....)
Which concept? The concept of doing the reconfigurability in software, rather than in hardware as is the case with an FPGA?
The patents they have all seem to imply that the processor does have a native instruction set, that code in other instruction sets is translated to the native instruction set by software, and that at least some of the fancy hardware features are intended to let the translators make very optimistic assumptions when they translate the code, with the code faulting if the assumptions aren't valid, and the software then recovering and re-translating with less optimistic assumptions.
I'm curious whether any non-US countries have done this as well (no, this is not an attempt at a "well, everybody does it" argument - I'm just curious whether the US is the only major power indulging in that sort of activity).
They set the primary selection by selecting text, and paste the primary selection with the middle mouse button.
The primary selection is not the clipboard; I just tested that with both the Motif-based Netscape and the GTK+-based Ethereal; selecting text, doing Alt+C in Netscape or Ctrl+C in Ethereal, and then selecting some different text caused the latter text - i.e., the primary selection - to be pasted with the middle mouse button and the former text - i.e., the clipboard - to be pasted with Alt+V in Netscape and Ctrl+V in Ethereal.
Running xclipboard while doing this also indicated that selecting text does not copy it to the clipboard, but Alt+C/Ctrl+C does.
And, yes, the distinction is relevant - the person who complained that paste-current-selection requires you to clear the field to which you want to paste it (rather than just selecting and pasting the clipboard, which replaces the selected text with the clipboard) was complaining about not being able to copy to the clipboard so that you can paste it and replace the currently selected text. (Yes, many applications let you clear the target of the paste-current-selection with Ctrl+U, but....)
Indeed? I didn't find the string "CLIPBOARD" anywhere in the Qt 1.44 or Qt 2.0.2 source; it may be called QClipboard, but it only appears to refer to the PRIMARY selection, not the CLIPBOARD selection.
Motif - yes, as I remember. GTK+ - GtkEditable and its subclasses appear to copy to the clipboard, and "gtk/gtkeditable.c" definitely interns the CLIPBOARD atom. I can't speak for other toolkits, although it'd be nice if they all did (including Qt...).
Sigh. Maybe Qt doesn't use the CLIPBOARD selection the way other toolkits/applications expect.
In fact, a quick look at the Qt 1.44 source suggests that the only selection it does anything with is the primary selection, and the same appears to apply to Qt 2.0.2, so if KDE 1.x or 2.x uses the CLIPBOARD selection, it's done by KDE code rather than Qt code.
For some reason, there's no XA_CLIPBOARD atom for the CLIPBOARD selection, as there are for the PRIMARY and SECONDARY selections - but the ICCCM does discuss the CLIPBOARD selection (section L.2.6.1.3, "The CLIPBOARD Selection", in the X11R5 version of the X Protocol Reference Manual in the O'Reilly series of X manuals), so the lack of an XA_CLIPBOARD atom is insufficient reason not to use that selection....
The Motif 1.2 Style Guide says, in section 4.3.1 Clipboard Transfer, that the "Cut" key (which they seem to imply could be implemented by a combination of other keys) or Shift+Delete "must cut selected elements of the target component to the clipboard", the "Copy" key or Ctrl+Insert "must copy selected elements of the target component to the clipboard", and the "Paste" key or Shift+Insert "must paste the contents of the clipboard at the insertion position of the target component", so it seems to be inclined towards Shift+Delete rather than Control+X or Alt+X for Cut, Ctrl+Insert rather than Control+C or Alt+C for Copy, and Shift+Insert rather than Control+V orAlt+V for Paste, so I don't think it's a Motif quirk - I think it's a Netscape quirk.
If control-C copies text in KWrite, try using control-C to copy text in KWrite and using Alt+V to paste it in Netscape. Control-C copies text in GTK+, so I copied a bit of text from a GTK+ application using control-C, and pasted it to Netscape using Alt+V. (The text was "eat me", a phrase that sums up my personal attitude towards Netscape's Alt-oriented key bindings.... Yes, there's presumably some reason why Netscape works that way. That's unlikely to make those key bindings less irritating to me....)
Probably not a bad idea.
Note that "X" has many levels - the core X protocol only specifies, as I remember, that the notion of "selections" exist, and the ICCCCCCCCCCCCCCCCM (Inter-Client Communications Conventions Manual, or so) specifies only that there exist selections with names such as PRIMARY ("the stuff that's inverse video because you selected it"), SECONDARY (does anything use this other than XView?), and CLIPBOARD ("the stuff that got copied to the clipboard, unless the CLIPBOARD selection holder exited - xclipboard will at least allow that to survive said owner exiting, although it may only preserver the text version of it) and, I think, the way they're intended to be used.
It's the toolkits and applications that implement stuff such as control-{X,C,V} as cut/copy/paste, and "paste primary selection" with the middle mouse button, so not everything running on X necessarily implements all those conventions, or implements them using the same mouse and keyboard bindings (for example, XView, being an OPEN LOOK toolkit, has its own keyboard and mouse bindings; the middle button, as I remember, means "extend selection" there, rather than "paste current selection").
Some (but not all) applications and/or toolkits support control-U as a way of erasing an entire text field (Netscape on UNIX being one of them; the GTK+ toolkit does as well).
You mean like the X CLIPBOARD selection, which many - but, alas, not all - applications support. (Then again, not all applications necessarily support "paste primary selection" - the mechanism you describe, which is quite often mislabeled "cut and paste" - either.)
I don't know why Netscape insists on using Alt for so many keyboard accelerators, unless it's an attempt to avoid colliding with the Emacs key bindings it offers in some situations. GTK+, at least for some text widgets, binds "copy to the CLIPBOARD selection" to...
...control-C. For example, you can use control-C to copy text from a text field, control-X to cut text from a text field, and control-V to paste text into a text field.
I wouldn't be surprised to find that Qt did so as well, at least when configured to provide a Windows-style UI (I think Motif might use some other bindings for cut/copy/paste - I heard a claim that they were pre-Windows 3.1 keys, used by Windows in an attempt to avoid getting beaten up by Apple, who appear to use +{C,V,X} for hose functions, and that 3.1 went to Control-{C,V,X} when Apple's suit ceased to be a threat - so maybe Qt uses those bindings when configured to provide a Motif-style UI).
...which isn't what Sun refers to when they say "OS"; "SunOS" includes more than just "/vmunix" plus loadable kernel modules (pre-5.0) or "/kernel/{gen}unix" plus loadable kernel modules (5.0 and later) - it includes a pile of shared libraries, as well as daemons and utilities.
"Solaris" is "SunOS" plus the window system (X server, API libraries, window managers, file managers, GUI utilities, ...).
Note that the SunOS API is implemented by the shared libraries and kernel code below it - the API is more than just the system calls, and Sun may well change the implementation of those APIs in ways that would, say, cause statically-linked programs, or programs that duplicate the functions of those APIs by directly making system calls, not to work on later OS releases.
According to the X11-toolkits page in the FreeBSD ports collection, the current version in the collection is 1.2.6. and, according to the GTK web site and the GTK mirror FTP site I tried, at least, the current version is 1.2.6. (The main site was being too slow; maybe 1.2.7 just came out, but....)
FreeBSD works pretty well for me as a workstation OS; it appeared to be less of a pain to get my plug-and-play ISA sound card to work on it than it would be on Debian 2.1 (the 2.0[.x] kernel patch didn't work out of the box, and I didn't particularly want to spend a lot of time doing kernel debugging; I guess I could've tried the isapnptools stuff, but, at that point, I already had a free OS that handled the sound card, so...).
Your mileage may vary - others may find some particular Linux distribution (or some particular non-free OS, or even some particular non-UNIX-flavored OS) better as a workstation OS, or, for that matter, as a server OS, for their purpose than one of the BSDs, and others might find one of the BSDs better, and so on.
You are mistaken. NetApp boxes do *N*O*T* run any flavor of BSD as their OS.
The underlying kernel is one written at NetApp; it doesn't support multiple address spaces, any notion of userland, or demand paging (heck, until recently, it didn't even change the page tables; it now uses the paging hardware, but only to make virtually contiguous physically-discontiguous pages, to make allocation of large chunks of memory a bit less painful).
A significant part of the of the code did from BSD - the networking stack came from BSD (4.4-Lite, with some bits of the FreeBSD and NetBSD stacks thrown in), as did many of the commands (although those had to be chainsawed a bit to run in kernel mode in a shared address space), as did the dump and restore code (although the dump code was significantly changed to work with our WAFL file system). Various support routines also came from various BSDs as well, and the NFS server code is somewhat remotely derived from the BSD code (although it was also significantly changed to fit into our environment as well).
However, that doesn't mean NetApp boxes run anything you'd recognize as "BSD" (and, in particular, the crash-dumping code isn't BSD-derived, although the savecore command is based on the BSD command, although, again, significantly modified to run in our environment, and to extract the core dump information from the core dump areas on the disks).
(Yes, I know this first hand. I'm one of the developers there, and have been since early 1994.)
IRIX isn't Sun's UNIX, it's SGI's UNIX. They're unlikely to sue themselves for stealing an idea from IRIX....
BSD, as others have noted, has had it for ages; many other flavors of UNIX probably got the idea (and, in some if not all cases, the code) from BSD.
I'd say "another wonderful Microsoft innovation", but, although I have the impression that "Virtual Directories" may be an IISism, I think I've seen similarly useful responses to other attempts to trim URLs on sites not obviously using IIS.
<rant>After all, the purpose of a Web site isn't to provide lots of information - where's the profit in that, to a corporation or other organization providing a Web site? - it's to provide lots of advertising and persuasion to get you not only to buy the stuff the corporation sells, but to get you to buy the particular stuff they want you to buy.</rant>
I'd say "another wonderful Microsoft innovation", but, although I have the impression that "Virtual Directories" may be an IISism, I think I've seen similarly useful responses to other attempts to trim URLs on sites not obviously using IIS.
<rant>After all, the purpose of a Web site isn't to provide lots of information - where's the profit in that, to a corporation or other organization providing a Web site - it's to provide lots of advertising and persuasion to get you not only to buy the stuff the corporation sells, but to get you to buy the particular stuff they want you to buy.</rant>
The official site is The Editing Room, which is the site where the Matrix parody was (geeze, doesn't anybody try trimming down URLs from the right to see what else is there any more?). They have an archives page, and the The Phantom Menace link takes you to the official home of that particular parody.
Perhaps it didn't show up for you in Netscape 4.7 (NT), but it showed up for me in Netscape 4.7 (NT).