...and 'Linux won't succeed in the market due to all you "C" hackers refusing to support the COmmon Business Oriented Language.'
Heh. There's a page on IBM developerWorks about Cobol and open source, with links to various open-source Cobol compilers under development, and to vendors of Cobol implementations for Linux, including CobolScript which is "a COBOL based interpreter that allows Web development" and NetCobol which "is a COBOL compiler that generates Java bytecode-based applications/applets from existing COBOL programs".
(Yes, I still use ed on occasion, if I want to do a quick short editing job. I use KDE on my home machine, though; it mostly runs xterms and Netscape and xmms/xmcd, but I do find the folder icons more convenient for browsing through the pile of PDF standards documents than finding a free xterm or popping up a new one - or keeping one around, iconified - and cding around and firing up Acroread by hand.)
but you can definitely see that the kernel and much of the low-level system stuff takes its hints from SVR4
"Takes its hints" in what sense?
The implementation looks nothing like SVR4 (at least as of when I saw SVR4 code back at Sun and at Auspex).
And if you mean the interface, which interfaces are you referring to?
(Note that "signals" may be the wrong answer, given that the core signal interface on both Linux and current BSDs and just about every other UNIX on the planet is, err, umm, sigaction().
"tty driver" is probably the wrong answer, too, as, at least if you use the termios stuff rather than the ioctls atop which they're built, Linux, current BSDs, and, I think, just about every other UNIX on the planet look similar - the termios structure and the flag bits and control characters in it are pretty much those of SunOS 4.0 (which, in turn, I based on a POSIX draft when I implemented the SunOS 4.0 tty subsystem).
open(), close(), read(), and write() are pretty much the same everywhere, and the same applies to the socket calls.)
Oh, and just in case your claim that
POSIX is the official standard which defines UNIX (as in the trademarked, licensed kind).
wasn't just a troll on the order of "BSD is a code fork from Solaris", that simply ain't the case. You're thinking of the Single UNIX Specification, which is based on POSIX but has rather a lot of stuff in it beyond what's in POSIX 1003.1, and beyond what's in other POSIX standards as well.
SVR4 has stuff beyond what's in the SUS, much less what's in POSIX, so claiming that
A POSIX OS is essentially the same thing as SVR4. Close enough for this discussion, anyway.
is hardly "close enough for this discussion" - were a BSD release to make itself POSIX-compliant (assuming it isn't already so), it would not necessarily be "essentially the same thing as SVR4".
Actually, the post to which you're referring looks inaccurate enough to be a troll rather than just ignorance; I wouldn't rely on it to clear up confusion.
Well, it's sort of the intersection between various flavors of UNIX, with some stuff added on; it antedates SVR4.
with BSD signals and terminal handling.
The signal mechanism is derived from that of 4.2BSD (and also happens to be the "main" signal mechanism in SVR4; other ones are supported as well). The terminal handling is more SV-flavored than BSD-flavored (where "BSD-flavored" really means "Research UNIX V7-flavored"; BSD added a bunch of additional stuff, most of which is also in SVR4, albeit with a more SV-ish flavor). Modern BSDs, and Linux, also have SVR4-flavored terminal handling (i.e, termios, with the UI extensions such as ECHOKE, ECHOCTL, word-erase and reprint and... characters).
Solaris is SVR4 as you say, but has a BSD filesystem.
SVR4 itself has a BSD-based file system (as well as, at least when it first came out, the V7-flavored System V file system - but, then again, 4.1BSD's file system was also V7-flavored).
I am still a bit puzzled about what you said about Linux: if it is SVR4,
Linux is Linux, just as HP-UX is HP-UX, IRIX is IRIX, AIX is AIX, Digital UNIX is Digital UNIX, etc.. Most of them implement POSIX, and a pile of other stuff, over and above POSIX, which is mainly the same on all UNIX-flavored OSes.
Linux isn't SVR4; most Linux distributions have a System V-ish init, although Slackware, I think, has a more BSDish init. Linux looks SVR4-like in a number of ways, but it's not SVR4.
and it is also Posix which signals does it have: BSD (as it is Posix) or SVR4? Or both (is this possible)?
At least on the RH 6.x (for some value of x) system here, there's a sigaction man page, which means it has POSIX signals; sigaction is derived from, and similar to, the BSD sigvec mechanism, but is not identical to sigvec.
There's also a sigvec man page on that Linux system, but it says
Under Linux sigvec is #define'd to sigaction, and provides at best a rough approximation of the BSD sigvec interface.
SVR4 and modern BSDs also have sigaction(); one should use sigaction wherever possible, and fall back on 4.2BSD-style sigvec() or "traditional UNIX"-style signal() (whose behavior differs between BSD and other systems; I'm not sure which behavior Linux gives, and I'm not sure how much I should care, as one should use sigaction() if one is writing portable code - yes, I know, there are probably signal() calls in Ethereal, I'll fix them) or 4.1BSD/SVR3-style sigset() only if one cannot use sigaction()
In other words, the correct answer to your question is "it has POSIX signals, just as SVR4 and modern BSDs do; those aren't exactly the same as BSD signals, but they're like BSD signals."
To me, it's just the same old product witha flashy new box.
"Same old product" only in the sense that it executes the x86 instruction set. It has a new processor core, i.e. not the core used in the Pentium Pro, Pentium II, Pentium III, and Celeron; it's not just a tweaked PIII.
The major city-states of ancient Greece periodically held large celebrations which included contests among their best playwrights, musicians, orators and sportsmen. The prize awarded to the victors was called an athlon.
The athlon usually took the form of a large terracotta vase, known as a prize amphora, filled with olive oil. The outside of the vase was specially decorated with images of the contest, presided over by a deity such as Athena. The skilled competitors who strove after these prizes -- regardless of the field of endeavor -- were known as athletes. It is telling that the term athlon was used not only for the prize but for the contest as well, thus linking the struggle for excellence with the fruits of victory.
At Athlon Communications, we have adopted this ancient symbol of excellence as a fitting touchstone for today's business environment, in which competition is constant, the margin for error is slim, and the rewards of victory are great.
(Yeah, I know, the third paragraph falls under the heading of "blah blah blah blah blah".)
OK, so Duron may be an invitation for parodies
It sounds like a brand of paint or something - "New all-weather Duron - stands up to sun, rain, hail...."
I always liked the Compaq Contura, which sounded as if it belonged on the racks in the drugstore right next to the Durexes and Trojans ("ribbed for her pleasure").
That doesn't work right now; I don't know if that machine and its HTTP server are being kept up 24/7 (the machine is pingable, but it refuses connections to port 80) - if not, it might be worth looking into putting it somewhere else as well. (Or does that machine have a dynamic IP address, and is ns.dyndns.org not giving me its current IP address? The address it's giving me is a Pac Bell Internet ADSL address.)
What is being proposed here is a major kernel architectural change. The locking provided by SPLS in the traditional BSD kernel goes away and is replaced by mutexs. This model is very different. Interrupts do not in general get blocked. When interrupt service code needs access to some piece of data which is actively being modified by what is traditionally thought of as the "top half" the interrupt thread will block at that point. The finer grained the locking the less chance of a collision, but the number of locking operation goes up and a price has to be paid.
I assume that this is still the intent (I think I saw other stuff in "freebsd-arch" indicating so).
You might want to checkout the "freebsd-arch" archives going back to May, and the "freebsd-current" and "freebsd-smp" archives from 2000-06-18, for more information; here's the top-level page for the FreeBSD mail archives. There's a note in the "freebsd-current" archives (I'm loath to give a link, as the current URL, I suspect, will become invalid when the next weekly(?) archive rollover occurs; check out "freebsd-current" for 2000-06-19, looking for "HEADS UP: Destabilization due to SMP development", from Jason Evans) that says:
Greg Lehey will be working on the initial cutover to interrupt threads (as well as the lazy interrupt thread context switching code later on). spl()s will go away as soon as interrupt threads start working. Once interrupt threads are working, most of the remaining work of threading the kernel will be able to go on in parallel.
I forget whether there were any messages discussing interrupt threads.
Does the 2.2/2.4 Linux SMP implementation handle interrupts in a fashion similar to the one proposed?
Now when will it move into the 21st century and give us anti-aliasing?
Perhaps if and when the new rendering model discussed in this paper by Keith Packard, from USENIX 2000, is implemented; the paper suggests a number of enhancements to the X rendering model, including, but not limited to, anti-aliased fonts (alpha compositing; alpha-blending operations to improve, I infer, anti-aliasing of images; 32-bit coordinates with 8-bits of sub-pixel positioning; a fancier rendering primitive to draw objects out of trapezoids - see the article for a detailed explanation, I'm not a graphics expert; better text support, including access by the application to more information about the font such as pair kerning tables and raw outline data and metrics).
The paper doesn't say when this will happen, but I infer that this isn't just a wish list; Packard is, according to his page on the XFree86 Web site, working for SuSE on X.
(Presumably meaning "support for 64-bit file offsets on 32-bit platforms.) And so do the other BSDs, Solaris 2.6 and later, and, I think, Windows NT, and probably other OSes.
I ended up with a much simpler (and faster) program by doing my own buffering and using only relative 32-bit lseeks and blockreads instead of the llseek 64bit offset functions.
How much of the "and faster" was due to "doing [your] own buffering" rather than "using only relative 32-bit lseeks"? Many file systems probably turn 64-bit file offsets into 32-bit block numbers and 32-bit offsets within blocks fairly early in the process of doing an I/O operation.
Did he say anything about Java bytecode? Java doesn't necessarily imply Java bytecode; see, for example, The GNU Compiler for the Java(tm) Programming Language, which can either produce bytecode or native machine code. (Yes, it means you don't automatically get Write Once Run Anywhere if you compile to native machine code, but perhaps there are applications where that doesn't matter.)
If I recall it right. One of the VMS architect dude now works on NT.
You're probably thinking of Dave Cutler, who was one of the main architects, if not the main architect, of VMS (and RSX-11M, I think), and was one of the main architects, if not the main architect, of NT.
VMS also supports many features that Unix never will such as... asynchronous I/O
Depends on how you define "Unix" and "asynchronous I/O". The UNIX 98 spec includes asynchronous I/O calls, in the sense of "start an I/O operation, don't block waiting for it to finish, and deliver an indication (signal, in the case of UNIX) when it completes, e.g. aio_read() and aio_write; at least some implementations of the UNIX API provide async I/O calls. Are they sufficiently close to SYS$QIO? (Perhaps signals aren't as nice as ASTs, but....)
and second, they shouldn't be doing it for business reasons, since there already is UNIX on os/390
Meaning a native port of some flavor of UNIX, or S/390 Open Edition? If the latter, then you may already have given the reason:
It is very, very strange as UNIX goes.
meaning it may be easier to put Linux on an S/390 (or in a virtual machine or logical partition on an S/390) than to put some New Economy Dot Com applications on Open Edition.
Unfortunately, none of the architecture dependant GNU utilities will compile on this beast, since the hardware isn't even similar to anything unix boxes are used to running on.
General-register-based architecture, 16 general-purpose registers, 4 (or is it 8 or more, now?) floating-point registers, memory-to-register and register-to-register arithmetic instructions - not all that different from VAXes, 68Ks, x86's; it's just another general-register-based CISC box. (Yeah, it has specialized instructions, but so do the other CISCs for which GCC generates code; you don't necessarily have to use them.)
The relatively short offsets in instructions may be the biggest problem.
If suse is going to port linux
Linux has already been ported; presumably SuSE and TurboLinux will be integrating the kernel, glibc, GCC, binutils, GDB, etc. changes into their distributions.
they may encounter the hardest part in porting things like gas and gcc, since AFAIK they don't know how to spit out binary for this CPU as of now.
There's been S/370 support in GCC for a while,a s I remember; the S/3x0 config directory of the EGCS source includes notes and checkins that suggest support (e.g, the 1.3 version of the README file says that it currently "supports three different styles of assembly", including MVS using the HLASM assembler, S/390 Open Edition, and "ELF/Linux for use with the binutils/gas GNU assembler".
There's also, in the GAS CVS tree, tc-i370.c and tc-i370.h files (which are for S/360 and S/390 as well as S/370, according to the comment).
should two separate teams even be working on this?
No, of course not.
The same applies to Linux/x86, of course; let's pick the one distribution that should be the only one on x86.:-)
As far as I know, the "port", in the sense of "kernel, glibc, compiler, binutils (and perhaps gdb)" (i.e., the part of a Linux distribution that contains the most platform-dependent code - other than perhaps the X server) has already been done, just as it's been done for x86, Alpha, etc.; I presume what TurboLinux, SuSE, etc. will be doing will be combining that with their distributions to make S/390 versions, to go along with versions for whatever other processors the distributors in question support.
SGI is committed to continue selling and supporting the digital graphics cards that are bundled with the Silicon Graphics 1600SW flat panel display. Production of the Number Nine cards for SGI continues uninterrupted, and the card will remain part of the 1600SW digital flat panel solution.
(production by whom? S3?) and also says:
Are there any other video adapters that support the 1600SW? At this time there are not, but we hope to have something to announce by spring or summer of 2000.
and:
When will the 1600SW support DVI? Keep watching our Web page for more news on this.
System V R4.0 was the result of merging a few parts of BSD into System V R3.2 plus providing a compatability layer for much of the rest.
...as well as merging a fair bit of SunOS 4.x (the VM system, the VFS layer, the NFS code, and the dynamic linking mechanism, for example, although the versions in SVR4 had some additional changes, including renaming the as_hole() routine as_gap(), as I remember - yes, as_hole() was intentionally called that...) in as well.
yah yah I could use
netscape's copy and paste functionality, but that's skipping my argument that the x-style copy and paste is lame.
I think Netscape's copy-and-paste functionality is X-style copy-and-paste, in the sense that Alt+C copies to the X CLIPBOARD selection and Alt+V pastes that selection; I've copied-and-pasted between a GTK+-based application and Netscape.
When people think of "X-style copy and paste", however, they often are, in fact, referring not to copy-and-paste, but what I call "paste-current-selection", which is what the middle mouse button does.
As you note, paste-current-selection doesn't support pasting as replacement of a selection, given that selecting, well, changes what the current selection is.
However, there are a couple of ways of using paste-current-selection to copy a URL to Netscape:
highlight the URL, click in the Location: field, type control-U to erase the Location: field, and then paste the URL to the now-empty Location: field with the middle mouse button;
paste the selection to the HTML window, which appears to be interpreted as "go to that URL".
Copy-and-paste requires that the application from which you're copying support "copy to clipboard"; I don't know if xterm, for example, supports "copy to clipboard" by default (although you can probably configure it to do so by setting the appropriate translations for it).
(Now, if only a certain X toolkit whose name begins with the letter "Q" would use the X CLIPBOARD selection, as the ICCCM suggests; I couldn't see any use of it in either the 1.42 or 2.0 source for said toolkit, and its non-use of CLIPBOARD may explain why I've seen a couple of complaints in Slashdot threads about problems with cut-and-paste between KDE applications and Netscape.)
Slashdot Mirror
You're in luck - there's a link on the page I cited that indicates that "RM COBOL" is, in fact, supported on Linux.
Heh. There's a page on IBM developerWorks about Cobol and open source, with links to various open-source Cobol compilers under development, and to vendors of Cobol implementations for Linux, including CobolScript which is "a COBOL based interpreter that allows Web development" and NetCobol which "is a COBOL compiler that generates Java bytecode-based applications/applets from existing COBOL programs".
Absolutely.
(Yes, I still use ed on occasion, if I want to do a quick short editing job. I use KDE on my home machine, though; it mostly runs xterms and Netscape and xmms/xmcd, but I do find the folder icons more convenient for browsing through the pile of PDF standards documents than finding a free xterm or popping up a new one - or keeping one around, iconified - and cding around and firing up Acroread by hand.)
"Takes its hints" in what sense?
The implementation looks nothing like SVR4 (at least as of when I saw SVR4 code back at Sun and at Auspex).
And if you mean the interface, which interfaces are you referring to?
(Note that "signals" may be the wrong answer, given that the core signal interface on both Linux and current BSDs and just about every other UNIX on the planet is, err, umm, sigaction().
"tty driver" is probably the wrong answer, too, as, at least if you use the termios stuff rather than the ioctls atop which they're built, Linux, current BSDs, and, I think, just about every other UNIX on the planet look similar - the termios structure and the flag bits and control characters in it are pretty much those of SunOS 4.0 (which, in turn, I based on a POSIX draft when I implemented the SunOS 4.0 tty subsystem).
open(), close(), read(), and write() are pretty much the same everywhere, and the same applies to the socket calls.)
Oh, and just in case your claim that
wasn't just a troll on the order of "BSD is a code fork from Solaris", that simply ain't the case. You're thinking of the Single UNIX Specification, which is based on POSIX but has rather a lot of stuff in it beyond what's in POSIX 1003.1, and beyond what's in other POSIX standards as well.
SVR4 has stuff beyond what's in the SUS, much less what's in POSIX, so claiming that
is hardly "close enough for this discussion" - were a BSD release to make itself POSIX-compliant (assuming it isn't already so), it would not necessarily be "essentially the same thing as SVR4".
Actually, the post to which you're referring looks inaccurate enough to be a troll rather than just ignorance; I wouldn't rely on it to clear up confusion.
Well, it's sort of the intersection between various flavors of UNIX, with some stuff added on; it antedates SVR4.
The signal mechanism is derived from that of 4.2BSD (and also happens to be the "main" signal mechanism in SVR4; other ones are supported as well). The terminal handling is more SV-flavored than BSD-flavored (where "BSD-flavored" really means "Research UNIX V7-flavored"; BSD added a bunch of additional stuff, most of which is also in SVR4, albeit with a more SV-ish flavor). Modern BSDs, and Linux, also have SVR4-flavored terminal handling (i.e, termios, with the UI extensions such as ECHOKE, ECHOCTL, word-erase and reprint and... characters).
SVR4 itself has a BSD-based file system (as well as, at least when it first came out, the V7-flavored System V file system - but, then again, 4.1BSD's file system was also V7-flavored).
Linux is Linux, just as HP-UX is HP-UX, IRIX is IRIX, AIX is AIX, Digital UNIX is Digital UNIX, etc.. Most of them implement POSIX, and a pile of other stuff, over and above POSIX, which is mainly the same on all UNIX-flavored OSes.
Linux isn't SVR4; most Linux distributions have a System V-ish init, although Slackware, I think, has a more BSDish init. Linux looks SVR4-like in a number of ways, but it's not SVR4.
At least on the RH 6.x (for some value of x) system here, there's a sigaction man page, which means it has POSIX signals; sigaction is derived from, and similar to, the BSD sigvec mechanism, but is not identical to sigvec.
There's also a sigvec man page on that Linux system, but it says
SVR4 and modern BSDs also have sigaction(); one should use sigaction wherever possible, and fall back on 4.2BSD-style sigvec() or "traditional UNIX"-style signal() (whose behavior differs between BSD and other systems; I'm not sure which behavior Linux gives, and I'm not sure how much I should care, as one should use sigaction() if one is writing portable code - yes, I know, there are probably signal() calls in Ethereal, I'll fix them) or 4.1BSD/SVR3-style sigset() only if one cannot use sigaction()
In other words, the correct answer to your question is "it has POSIX signals, just as SVR4 and modern BSDs do; those aren't exactly the same as BSD signals, but they're like BSD signals."
This site, for a certain well-known free-software desktop project, has the same problem - Another Damn Refresh.
"Same old product" only in the sense that it executes the x86 instruction set. It has a new processor core, i.e. not the core used in the Pentium Pro, Pentium II, Pentium III, and Celeron; it's not just a tweaked PIII.
...even if it is the name of a sports magazine in the US (which much of the rest of the world would call a "sport magazine", I suspect :-)).
It's also the name of an "integrated marketing communications firm", who say, on their What is an Athlon? page:
(Yeah, I know, the third paragraph falls under the heading of "blah blah blah blah blah".)
It sounds like a brand of paint or something - "New all-weather Duron - stands up to sun, rain, hail...."
I always liked the Compaq Contura, which sounded as if it belonged on the racks in the drugstore right next to the Durexes and Trojans ("ribbed for her pleasure").
That doesn't work right now; I don't know if that machine and its HTTP server are being kept up 24/7 (the machine is pingable, but it refuses connections to port 80) - if not, it might be worth looking into putting it somewhere else as well. (Or does that machine have a dynamic IP address, and is ns.dyndns.org not giving me its current IP address? The address it's giving me is a Pac Bell Internet ADSL address.)
The page in question doesn't fully describe the architecture planned for FreeBSD SMPng; in, for example, the 2000-05-21 through 2000-05-28 freebsd-arch archives, there's a lot of discussion, including this "short summary" note, which start out saying:
I assume that this is still the intent (I think I saw other stuff in "freebsd-arch" indicating so).
You might want to checkout the "freebsd-arch" archives going back to May, and the "freebsd-current" and "freebsd-smp" archives from 2000-06-18, for more information; here's the top-level page for the FreeBSD mail archives. There's a note in the "freebsd-current" archives (I'm loath to give a link, as the current URL, I suspect, will become invalid when the next weekly(?) archive rollover occurs; check out "freebsd-current" for 2000-06-19, looking for "HEADS UP: Destabilization due to SMP development", from Jason Evans) that says:
I forget whether there were any messages discussing interrupt threads.
Does the 2.2/2.4 Linux SMP implementation handle interrupts in a fashion similar to the one proposed?
Perhaps if and when the new rendering model discussed in this paper by Keith Packard, from USENIX 2000, is implemented; the paper suggests a number of enhancements to the X rendering model, including, but not limited to, anti-aliased fonts (alpha compositing; alpha-blending operations to improve, I infer, anti-aliasing of images; 32-bit coordinates with 8-bits of sub-pixel positioning; a fancier rendering primitive to draw objects out of trapezoids - see the article for a detailed explanation, I'm not a graphics expert; better text support, including access by the application to more information about the font such as pair kerning tables and raw outline data and metrics).
The paper doesn't say when this will happen, but I infer that this isn't just a wish list; Packard is, according to his page on the XFree86 Web site, working for SuSE on X.
Remote displays such as the Windows Terminal Server displays?
(Presumably meaning "support for 64-bit file offsets on 32-bit platforms.) And so do the other BSDs, Solaris 2.6 and later, and, I think, Windows NT, and probably other OSes.
How much of the "and faster" was due to "doing [your] own buffering" rather than "using only relative 32-bit lseeks"? Many file systems probably turn 64-bit file offsets into 32-bit block numbers and 32-bit offsets within blocks fairly early in the process of doing an I/O operation.
Did he say anything about Java bytecode? Java doesn't necessarily imply Java bytecode; see, for example, The GNU Compiler for the Java(tm) Programming Language, which can either produce bytecode or native machine code. (Yes, it means you don't automatically get Write Once Run Anywhere if you compile to native machine code, but perhaps there are applications where that doesn't matter.)
You're probably thinking of Dave Cutler, who was one of the main architects, if not the main architect, of VMS (and RSX-11M, I think), and was one of the main architects, if not the main architect, of NT.
Well, it was one, in part, initially (and there may well still be Microsoft code in it).
Depends on how you define "Unix" and "asynchronous I/O". The UNIX 98 spec includes asynchronous I/O calls, in the sense of "start an I/O operation, don't block waiting for it to finish, and deliver an indication (signal, in the case of UNIX) when it completes, e.g. aio_read() and aio_write; at least some implementations of the UNIX API provide async I/O calls. Are they sufficiently close to SYS$QIO? (Perhaps signals aren't as nice as ASTs, but....)
Meaning a native port of some flavor of UNIX, or S/390 Open Edition? If the latter, then you may already have given the reason:
meaning it may be easier to put Linux on an S/390 (or in a virtual machine or logical partition on an S/390) than to put some New Economy Dot Com applications on Open Edition.
General-register-based architecture, 16 general-purpose registers, 4 (or is it 8 or more, now?) floating-point registers, memory-to-register and register-to-register arithmetic instructions - not all that different from VAXes, 68Ks, x86's; it's just another general-register-based CISC box. (Yeah, it has specialized instructions, but so do the other CISCs for which GCC generates code; you don't necessarily have to use them.)
The relatively short offsets in instructions may be the biggest problem.
Linux has already been ported; presumably SuSE and TurboLinux will be integrating the kernel, glibc, GCC, binutils, GDB, etc. changes into their distributions.
There's been S/370 support in GCC for a while,a s I remember; the S/3x0 config directory of the EGCS source includes notes and checkins that suggest support (e.g, the 1.3 version of the README file says that it currently "supports three different styles of assembly", including MVS using the HLASM assembler, S/390 Open Edition, and "ELF/Linux for use with the binutils/gas GNU assembler".
There's also, in the GAS CVS tree, tc-i370.c and tc-i370.h files (which are for S/360 and S/390 as well as S/370, according to the comment).
No, of course not.
The same applies to Linux/x86, of course; let's pick the one distribution that should be the only one on x86. :-)
As far as I know, the "port", in the sense of "kernel, glibc, compiler, binutils (and perhaps gdb)" (i.e., the part of a Linux distribution that contains the most platform-dependent code - other than perhaps the X server) has already been done, just as it's been done for x86, Alpha, etc.; I presume what TurboLinux, SuSE, etc. will be doing will be combining that with their distributions to make S/390 versions, to go along with versions for whatever other processors the distributors in question support.
Depends on the "they" to which you're referring, and on what "quite large" means. According to the S/390 Multiprise 3000 Reference Guide, the "Base (CPC) Frame" for said machine is 520mm wide, 1110mm deep, and 819mm high, or 20" wide, 43" deep, 31.5" high for us Yanks, and, according to this page from the S/390 Integrated Server Technical Application Brief, that box is about the same size (533mm wide, 1038mm deep, 819mm high).
Well, the Graphics/Video Cards section of the SGI Flat Panel Q&A on SGI's Web site says:
(production by whom? S3?) and also says:
and:
XFree86 4.0 doesn't support the Revolution IV-FP, according to the Number Nine page in the XFree86 4.0 driver status stuff:
I don't know if this means "has not yet been ported", i.e. that there is a port in progress, or not.
...as well as merging a fair bit of SunOS 4.x (the VM system, the VFS layer, the NFS code, and the dynamic linking mechanism, for example, although the versions in SVR4 had some additional changes, including renaming the as_hole() routine as_gap(), as I remember - yes, as_hole() was intentionally called that...) in as well.
To which CSRG work are you referring here?
STREAMS is a System Vism (influenced by the "streams" done by Dennis Ritchie at Bell Labs Research.
I think Netscape's copy-and-paste functionality is X-style copy-and-paste, in the sense that Alt+C copies to the X CLIPBOARD selection and Alt+V pastes that selection; I've copied-and-pasted between a GTK+-based application and Netscape.
When people think of "X-style copy and paste", however, they often are, in fact, referring not to copy-and-paste, but what I call "paste-current-selection", which is what the middle mouse button does.
As you note, paste-current-selection doesn't support pasting as replacement of a selection, given that selecting, well, changes what the current selection is.
However, there are a couple of ways of using paste-current-selection to copy a URL to Netscape:
Copy-and-paste requires that the application from which you're copying support "copy to clipboard"; I don't know if xterm, for example, supports "copy to clipboard" by default (although you can probably configure it to do so by setting the appropriate translations for it).
(Now, if only a certain X toolkit whose name begins with the letter "Q" would use the X CLIPBOARD selection, as the ICCCM suggests; I couldn't see any use of it in either the 1.42 or 2.0 source for said toolkit, and its non-use of CLIPBOARD may explain why I've seen a couple of complaints in Slashdot threads about problems with cut-and-paste between KDE applications and Netscape.)