"See, use Ctrl+C (sometimes?), but if you're in a console, just highlight it... But don't highlight anything otherwise, or you'll lose whats in your clipboard".
Those are two different mechanisms; Ctrl+C is "copy to clipboard", and you then paste from the clipboard, but "just highlight it" is followed by the middle-mouse-button "paste current selection".
I'd personally be a bit annoyed if Ctrl+C in a terminal window copied the selection to the clipboard rather than sending a ^C down the pseudo-terminal to interrupt the current program - but I'd be similarly annoyed if it did that in the terminal windows on a certain non-UNIX operating system as well. (In that OS, at least in the 5.0 version of the "New Technology" flavor of that OS, you can either select "Edit->Copy" on the window menu or, apparently, use the "Enter" key - I guess "Enter" acts as a CR/LF only if nothing is selected.)
And what about PASTING! Highlighting to overwrite in one sequence copies what you highlighted to your clipboard (overwriting your precious clipboard text)!
Not in any desktop that implements its primary and clipboard selections according to the X clipboard explanation, which says "selecting but with no explicit copy should only set PRIMARY, never CLIPBOARD."
The problem here is that people have gotten confused about what the "clipboard" is. The clipboard is not what selecting something with the mouse changes and not what your middle mouse button pastes. Selecting with the mouse changes the primary selection, and the middle mouse button pastes the primary selection. "Copy" copies the primary selection to the clipboard; merely selecting something doesn't, it just changes the primary selection to refer to what you selected. "Paste" inserts the contents of the clipboard in place of the current selection (which could be a "zero-length" selection, in which case it amounts to inserting at the point of the selection, e.g. insert at the text cursor in a text window).
(As I remember, the KDE people spoke of them both as "clipboards" when discussing the KDE 3.0/Qt 3.0 change to make the primary selection and clipboard work that way, in order to, I guess, avoid confusing people whose brains had become too locked into the notion of the middle mouse button pasting some kind of "clipboard"; however, the X11 Inter-Client Communication Conventions Manual calls the primary selection PRIMARY and the clipboard CLIPBOARD.)
HP Labs still exists; whether they're doing less, or just doing stuff other than the commodity stuff HP's using more of, is another matter.
But, as has been noted, there are some research departments in big companies that are doing interesting stuff, such as IBM and even a favorite whipping boy on Slashdot. How pure the research of any given company is might be a different matter.
And that makes me think that photons can self-gravitate:
They are affected by gravity
They "bend space" like mass, so produce a gravitational field.
You are entirely correct. A photon has energy and momentum, thus it generates a gravitational field, even though it has no rest mass. It is also subject to a gravitational field, as was found to be the case in 1919.
Hell, gravity should self-gravitate, and there was an experiment to try to determine whether it does, and they appear to have found that it does....
Couldn't you collide some matter and antimatter? If you had some mass and then it co-annihilates, it should be like turning gravity off.
No, it shouldn't. A matter-antimatter annihilation isn't really an "annihilation" in the sense that the "nihil" in "annihilation" might suggest; instead, if, for example, an electron and positron mutually annihilate, you get a pair of photons, and the total energy of the photons is equal to the total energy (rest energy, from rest mass, plus kinetic energy) of the incoming electron and positron.
However, the software is DOS/Windows-only, so it won't work on the Linux laptops he/she mentioned in a followup posting (without software work of some sort, unless the software requires nothing in the way of special kernel-mode driver code and can run under a DOS emulator or Wine).
The devices being replaced might also do more than just TDR, in which case that card might not do all the original poster needs.
Well, that depends on how you use them. Solaris does not, as far as I know, assign particular register windows to particular processes/threads, but uses them to avoid register saves/restores for short trips up and down the call stack. (For sufficiently long trips, of course, you'll need to do them.)
They may have a clever way of avoiding saving all of a process's windows on a context switch (it's been ages since I dealt with SPARC or context-switching code for SPARC), and they might be able to avoid that for threads running in the same address space, but I suspect register windows, used the way Solaris uses them, are, at best, no help for context switching, and they might hurt.
I don't know whether NetBSD uses them differently.
Is this related to the embedded Java processor Sun announced a while back?
No.
I never read up on that, and I wasn't sure if they really meant it was running Java bytecode, or if it was merely a processor that was well-suited for Java. Native bytecode sure sounded unlikely.
"Sounds unlikely" does not necessarily imply "not true"; picoJava does, indeed, run Java bytecode as a native instruction set - or, at least, did, or was intended to; I can't find anything from Sun's home page that speaks of them selling any processors other than UltraSPARCs. A Google search for "Sun Microelectronics" found, as the topmost hit, a page for UltraSPARC processors, so perhaps they've killed off picoJava and microJava (I think microJava might not have had bytecode as its native instruction set), along with the MAJC chip (some VLIW thing) they were working on at some point. (You can still find stuff about picoJava, microJava, and MAJC on Sun's web site from the search box, but the papers you find look suspiciously orphaned.)
Actually, GTK is a native widget set for OSes using X11 as the native window system, including but not limited to Linux. It is no more "the" native widget set for those systems than are Qt, FLTK, Motif, the Athena Widgets, etc., and it's not at all Linux-specific.
But your underlying point, namely that there is no "native" widget set for UNIX+X11 systems that GTK+ "should" be using, is correct.
I think Qt also replaces the native widgets on non-X11 platforms on which it runs and that have native widgets, such as Windows and MacOS X.
What I was told by the HP folks was different. They said that very little of the existing Intannium[sic] I will be evident in the new chip set.
And there's probably not much (if anything) left of the P6 core (Pentium Pro, Pentium II, Pentium III, many Celerons) in the Pentium IV, and not much left of the P5 core (Pentium, Pentium MMX) in the P6 core - but they all implement the x86^H^H^HIA-32 instruction set, albeit with various additions over time (MMX, SSE, and assorted other stuff such as conditional moves and a 64-bit compare and exchange).
The Itanium 2 implementation of the IA-64 instruction set might not share much with the original Itanium implementation IA-64 instruction set, but that doesn't mean that they don't implement the same core instruction set.
Q2. How is the Itanium 2 processor different than the original Itanium processor? What kind of performance can I expect?
A2. The Itanium 2 processor builds on the Itanium architecture with large integrated on-die cache and additional execution units while maintaining compatibility with Itanium-based software.
Now we go to Itannium[sic] II, which is about as close to Itannium[sic] I as Netscape 6 is to the latest Phoenix release.
...and both of which implement the IA-64 architecture. The FreeBSD port isn't to Itanium I, it's to IA-64, so it should be able to work on Itanium II as well (although there may be work needed if Itanium I and II different in any ways not covered by the IA-64 architecture spec that matter to the OS).
The next chips out of Intel IA2 (or whatever) will be largely based on the Alpha chip
They may use similar implementation techniques to ones used in various Alphas (there's no such thing as "the Alpha chip", there are multiple Alpha chipsinstruction set architecture will be dropped in favor of an ISA similar to Alpha.
Why support a POS architecture when the successor, due out in another year (GA), is vastly different? It may be a lot of work that won't translate over well.
I have seen nothing to indicate that the successor will be "vastly different" in its instruction-set architecture, so that work done to port to Itanium I-based machines "won't translate over very well" for Itanium II-based machines.
2. Those scripts do not relate to modprobe in Linux (kernel mode loader) or apt-get in Debian (install/upgrade package utility)
I don't think the poster to whom you're replying said they did. The poster said
...it uses an internal automatic sorting and dependency resolution comparable to apt-get or modprobe on GNU/Linux.
which just says the schemes are "comparable", presumably meaning they do similar types of (topological?) sort to figure out what depends on what and to make sure that if Y depends on X, X is "activated" (started, loaded, whatever) before Y.
No, a lot of it was written by the OSF members; remember, Motif came out of the whole "AT&T/Sun vs. OSF" wars, and it came from the OSF side - the AT&T/Sun side had the OPEN LOOK toolkits XView (SunView ported to run atop X11) and OLIT (AT&T's Xt-based OPEN LOOK toolkit).
I think SunOS 5.0 came out earlier than that - early 90's?
Sun switched from BSD with System VR4 extensions (a.k.a. SunOS)
More like "System V Release 3 extensions"; SVR4 didn't exist at the time. Actually, as of SunOS 3.2, a significant part of the userland code came from System V, and the fraction increased even more in 4.0.
o a microthreaded System V R4 with BSD extensions (Solaris 2.5 & up)
Try "Solaris 2.0 and up", although the early versions of Solaris 2.x weren't all that popular, so maybe 2.5 was the first version that started being used a lot.
Of course, Solaris 2.5, 2.6, 7 and 8 are also called SunOS 5.5, 5.6, 5.7 (which is also Solaris 2.7), and 5.8 (which is also Solaris 2.8)
Actually, it's the OS component of Solaris that's called SunOS; this item in the Sun Computer Administration FAQ has the mappings for releases prior to Solaris 2.5 - the mapping continued along the lines you mention until Solaris 7, when they stopped pretending that Solaris 3 would come out any time soon and got rid of the leading "2.". There's also the window system and desktop component (OpenWindows, at least until they abandoned the OPEN LOOK desktop in favor of the Motif+CDE desktop that they're now abandoning in favor of GTK+GNOME).
"Solaris" was a marketoon idea; when the SVR4 project started, we figured it was just going to be "SunOS 5.0". I guess (I left Sun in 1988) they decided to come up with the "Solaris" name for the OS+window system stuff; they retroactively applied it to SunOS 4.x, but there had been 4.x releases previously - there were no 5.x releases before the "Solaris" name was introduced, so people didn't get used to the idea of "SunOS 5.x" to the same degree, and that plus the changeover to an SVR4-derived code base probably got people to think of "SunOS" as the BSD-based versions and "Solaris" as the SVR4-based versions.
And the marketing department ran out of steam after having Sparc, Hypersparc, and Ultrasparc
Actually, the "HyperSPARC" name was Ross Technology/Cypress's marketoons idea, not Sun's marketoons idea; at the time, Sun were doing SuperSPARC, so I guess the Ross marketoons had to go one better.
and couldn't think of any more names so they just then went UltraSparc II, IIi, III
Yeah, where do you go from there? "MegaSPARC"? "UltimoSPARC"? "CosmoSPARC"? "SuperHyperUltraHumongoSPARC"?
...which finally has the SPARC V8 manual and the SPARC V9 manual online (online manuals appears to be what the original poster wanted), although they only seem to have the V9 manual online as compressed PostScript, not PDF. In the past, that documentation wasn't online; I heard a claim that it was due to copyright issues with whoever produced the printed versions (Addison-Wesley?).
A subset of the SCSI-3 standard, also known as IEEE 1394, Firewire is a new high speed data exchange protocol developed at Apple. Occasionally it is referred to as "serial SCSI" because it is a serial protocol and conforms to SCSI standards as well.
They stated that in a fashion that is, at best, a bit confusing. This draft specification for the SCSI architectural model shows on page 10 a diagram showing that there are several interconnect layers for SCSI, including the classic parallel SCSI bus (SPI), and three count 'em three serial layers, namely Fibre Channel (FC-PH), FireWire ("IEEE 1394 High Performance Serial Bus"), and IBM SSA (SSA-PH), with each interconnect layer having a protocol used to implement SCSI on that layer.
Then there are the SCSI commands, which are mostly if not entirely independent of the interconnect layer and protocol. They can be sent over parallel SCSI, Fibre Channel+FCP, FireWire+SBP, SSA-PH+SSP, {pick your link layer}+IP+TCP+iSCSI, Ethernet+HyperSCSI, or the Serial ATA link layer+serial attached SCSI, and, apparently USB+some way of sending SCSI commands over USB. (There certainly don't seem to be many bit-serial links over which you can send SCSI commands and replies....:-))
FireWire isn't "SCSI", it's an interconnect over which you can send SCSI commands and replies. It's also an interconnect over which you can send stuff that has nothing to do with SCSI, e.g. IP datagrams (we ignore here the possiblity of IP datagrams containing TCP segments that make up iSCSI PDUs:-)), just as Fibre Channel is an interconnect over which you can send SCSI commands and replies, as well as stuff that has nothing to do with SCSI, e.g. IP datagrams, and just as USB is an interconnect over which you can send SCSI commands and replies, as well as stuff that has nothing to do with SCSI, including network packets.
Well, I looked at their protocols that they're "opening" - nothing earth shuttering.. USB, FireWire, IPv6 and stuff like that are already available and running well under Linux and other open source OS's...
If the protocols used for communication between Windows 2000 and Windows XP client operating systems and Microsoft Windows NT Server, Windows 2000 Server and Windows.NET Server operating systems are already published by third parties, those protocols are listed below for your reference. Many of the reference documents for the protocols identified below are available online. For each of the communications protocols listed below, a link is included that points to either the most recent version of the specification document (of which Microsoft has been apprised at the time this listing was prepared) or, if not available, to the Web site of the source for the published documentation for the protocol. Third-party sources of this documentation and information are solely responsible for their published information and its availability at these links.
a list of already published protocols that they use.
Only one of them is a Microsoft-proprietary protocol, namely CIFS (and even that has been published elsewhere).
In fact, on the Microsoft Settlement Program Communications Protocol Program page, which links to that other page, they quite explicitly say that those protocols are not being licensed under this program:
In connection with the proposed
Consent Decree, Microsoft is making certain client-server communication protocols available for license by third parties. Many of the communications protocols used for communications between Windows client and server operating systems have been developed and are available through standards organizations or are published and available from third party sources. Microsoft is identifying the standards-based and other published protocols used by Microsoft Windows 2000 and Windows XP operating systems to interoperate or communicate with Microsoft server operating systems and is providing a link to a source for documentation of these published protocols, where available. These published protocols will not be licensed pursuant to the Communications Protocol Program license agreements. To view a list of these standards and other published protocols, click here.
There's probably some legal reason why they have to, or think they have to, enumerate all those protocols, even though you don't have to license most of them from Microsoft or sign an NDA or anything.
Unix from AT&T had a similar problem. they kept calling it "System N" and incrementing N. when they hit "System V" (the first to use a roman numeral, i think),
No, that was System III. (There were, I think, UNIX 4.x releases used inside AT&T, but they were never released as "System IV"; they went straight from "System III" to "System V".)
The page for the port says it's being done on Hercules, which is a System/390 and z/Architecture simulator; the Hercules page claims it runs on Linux and 32-bit Windows, but it can probably be made to run on UNIXes other than Linux as well, assuming it doesn't Just Work out of the box.
Re:Quick kudos to the XFree86 team
on
Xinerama Part of X
·
· Score: 3, Interesting
hat it has to do with is that xinerama will now be part of the main X consortium's tree.
This will (eventually) make commercial X servers (such as those in Solaris, AIX, etc.) slightly larger due to xinerama support being "backported".
Xinerama is already in Solaris 8's X server, at least according to this item on Solaris 8.
The actual item on the XFree86 Web site (go to their home page and search for "Xinerama"; the anchor tag for the Xinerama item is incorrect, with "name=anniversary", so at least with some browsers the "Xinerama" link doesn't work) says:
Public Review of the Draft Standard of the Xinerama Extension to the X Window System, sponsored by X.Org.
After its initial release, as part of X11R6.4, the Xinerama Extension API and code base splintered as many different developers ported it to their X Window System base. The Xinerama task force of X.Org has been working with a cross section of developers to create a new API that meets the needs of all, to replace the various versions currently available. The goal of this task force has been to create an API that can become an X Window System standard. The task force has been following the new Standards process defined by X.Org. The API is now at Stage 4 of that process: Public Review.
The Xinerama extension provides a mechanism for a multi-headed system to function as one large screen. Windows can span multiple screens and can move from one screen to another.
The review period for this proposed standard ends July 26, 2002. A mail list for discussion of the proposed standard has been created, xinerama-std-review@lists.sourceforge.net. This mail list is publicly available, and archived on the project website. The web site for this project is Xinerama@Sourceforge . Further documenation and code is available there.
This is the FIRST and ONLY case of XFree86 code going into the shared implementation. Previously all exchanges were bug fixes.
I don't know whether that means that code from XFree86 will be used as part or all of the implementation for the updated Xinerama, or that the item about new code going in belonged with some other item the bulk of which is missing, but I don't think the XFree86 folk originated Xinerama - they picked up their initial implementation from X11R6.4.
You could name a binary windowsxp but that doesn't mean it really is though.
Correct. Just because BSD happens to have cc as one of the names for the GNU C Compiler doesn't mean that it's some compiler other than GCC. As you will discover if you actually bother looking at the source that generates the C compiler on BSD, it is GCC.
gcc is used for compatibility for all the code writers that just make assumptions like you have been.
You are incorrect in your mistaken belief that I've been making some assumption that the C compiler on a system is called gcc; my makefiles use $(CC).
freshmeat.net can tell you about all sorts of BSDL projects. If you weren't busy on/. being a schmuck you would know that.
I'm quite aware that there are plenty of BSDLed projects; I'm just noting that the C compiler that comes with BSD isn't one of them.
But if you weren't busy on Slashdot being yet another worthless stupid brainless monkey, and actually had a brain to use and bothered using it, you could have figured that out.
Slashdot Mirror
Those are two different mechanisms; Ctrl+C is "copy to clipboard", and you then paste from the clipboard, but "just highlight it" is followed by the middle-mouse-button "paste current selection".
I'd personally be a bit annoyed if Ctrl+C in a terminal window copied the selection to the clipboard rather than sending a ^C down the pseudo-terminal to interrupt the current program - but I'd be similarly annoyed if it did that in the terminal windows on a certain non-UNIX operating system as well. (In that OS, at least in the 5.0 version of the "New Technology" flavor of that OS, you can either select "Edit->Copy" on the window menu or, apparently, use the "Enter" key - I guess "Enter" acts as a CR/LF only if nothing is selected.)
Not in any desktop that implements its primary and clipboard selections according to the X clipboard explanation, which says "selecting but with no explicit copy should only set PRIMARY, never CLIPBOARD."
The problem here is that people have gotten confused about what the "clipboard" is. The clipboard is not what selecting something with the mouse changes and not what your middle mouse button pastes. Selecting with the mouse changes the primary selection, and the middle mouse button pastes the primary selection. "Copy" copies the primary selection to the clipboard; merely selecting something doesn't, it just changes the primary selection to refer to what you selected. "Paste" inserts the contents of the clipboard in place of the current selection (which could be a "zero-length" selection, in which case it amounts to inserting at the point of the selection, e.g. insert at the text cursor in a text window).
(As I remember, the KDE people spoke of them both as "clipboards" when discussing the KDE 3.0/Qt 3.0 change to make the primary selection and clipboard work that way, in order to, I guess, avoid confusing people whose brains had become too locked into the notion of the middle mouse button pasting some kind of "clipboard"; however, the X11 Inter-Client Communication Conventions Manual calls the primary selection PRIMARY and the clipboard CLIPBOARD.)
It got broken into a number of pieces, just as AT&T split up.
The piece called Bell Labs did.
HP Labs still exists; whether they're doing less, or just doing stuff other than the commodity stuff HP's using more of, is another matter.
But, as has been noted, there are some research departments in big companies that are doing interesting stuff, such as IBM and even a favorite whipping boy on Slashdot. How pure the research of any given company is might be a different matter.
You are entirely correct. A photon has energy and momentum, thus it generates a gravitational field, even though it has no rest mass. It is also subject to a gravitational field, as was found to be the case in 1919.
Hell, gravity should self-gravitate, and there was an experiment to try to determine whether it does, and they appear to have found that it does....
No, it shouldn't. A matter-antimatter annihilation isn't really an "annihilation" in the sense that the "nihil" in "annihilation" might suggest; instead, if, for example, an electron and positron mutually annihilate, you get a pair of photons, and the total energy of the photons is equal to the total energy (rest energy, from rest mass, plus kinetic energy) of the incoming electron and positron.
The photons have a gravitational field just as the electron and positron did. (Mass isn't the source of gravity - energy and momentum, and the flow thereof, are.)
...but it does link to a commercial site that has information on that PC Card TDR.
However, the software is DOS/Windows-only, so it won't work on the Linux laptops he/she mentioned in a followup posting (without software work of some sort, unless the software requires nothing in the way of special kernel-mode driver code and can run under a DOS emulator or Wine).
The devices being replaced might also do more than just TDR, in which case that card might not do all the original poster needs.
Well, there's 10 gigabit Ethernet, and Intel are now sampling a card that supports it.
Well, that depends on how you use them. Solaris does not, as far as I know, assign particular register windows to particular processes/threads, but uses them to avoid register saves/restores for short trips up and down the call stack. (For sufficiently long trips, of course, you'll need to do them.)
They may have a clever way of avoiding saving all of a process's windows on a context switch (it's been ages since I dealt with SPARC or context-switching code for SPARC), and they might be able to avoid that for threads running in the same address space, but I suspect register windows, used the way Solaris uses them, are, at best, no help for context switching, and they might hurt.
I don't know whether NetBSD uses them differently.
There's also some on Fujitsu Semiconductor's Web site as well.
No.
"Sounds unlikely" does not necessarily imply "not true"; picoJava does, indeed, run Java bytecode as a native instruction set - or, at least, did, or was intended to; I can't find anything from Sun's home page that speaks of them selling any processors other than UltraSPARCs. A Google search for "Sun Microelectronics" found, as the topmost hit, a page for UltraSPARC processors, so perhaps they've killed off picoJava and microJava (I think microJava might not have had bytecode as its native instruction set), along with the MAJC chip (some VLIW thing) they were working on at some point. (You can still find stuff about picoJava, microJava, and MAJC on Sun's web site from the search box, but the papers you find look suspiciously orphaned.)
"Shannon and Dan", as I remember (Bill Shannon and Dan Walsh).
Actually, GTK is a native widget set for OSes using X11 as the native window system, including but not limited to Linux. It is no more "the" native widget set for those systems than are Qt, FLTK, Motif, the Athena Widgets, etc., and it's not at all Linux-specific.
But your underlying point, namely that there is no "native" widget set for UNIX+X11 systems that GTK+ "should" be using, is correct.
I think Qt also replaces the native widgets on non-X11 platforms on which it runs and that have native widgets, such as Windows and MacOS X.
DirectTV won't be around to complain, so bon appetit!
And there's probably not much (if anything) left of the P6 core (Pentium Pro, Pentium II, Pentium III, many Celerons) in the Pentium IV, and not much left of the P5 core (Pentium, Pentium MMX) in the P6 core - but they all implement the x86^H^H^HIA-32 instruction set, albeit with various additions over time (MMX, SSE, and assorted other stuff such as conditional moves and a 64-bit compare and exchange).
The Itanium 2 implementation of the IA-64 instruction set might not share much with the original Itanium implementation IA-64 instruction set, but that doesn't mean that they don't implement the same core instruction set.
In fact, the Intel FAQ on Itanium 2 explicitly says:
(emphasis mine).
...and both of which implement the IA-64 architecture. The FreeBSD port isn't to Itanium I, it's to IA-64, so it should be able to work on Itanium II as well (although there may be work needed if Itanium I and II different in any ways not covered by the IA-64 architecture spec that matter to the OS).
They may use similar implementation techniques to ones used in various Alphas (there's no such thing as "the Alpha chip", there are multiple Alpha chipsinstruction set architecture will be dropped in favor of an ISA similar to Alpha.
I have seen nothing to indicate that the successor will be "vastly different" in its instruction-set architecture, so that work done to port to Itanium I-based machines "won't translate over very well" for Itanium II-based machines.
I don't think the poster to whom you're replying said they did. The poster said
which just says the schemes are "comparable", presumably meaning they do similar types of (topological?) sort to figure out what depends on what and to make sure that if Y depends on X, X is "activated" (started, loaded, whatever) before Y.
No, a lot of it was written by the OSF members; remember, Motif came out of the whole "AT&T/Sun vs. OSF" wars, and it came from the OSF side - the AT&T/Sun side had the OPEN LOOK toolkits XView (SunView ported to run atop X11) and OLIT (AT&T's Xt-based OPEN LOOK toolkit).
I think SunOS 5.0 came out earlier than that - early 90's?
More like "System V Release 3 extensions"; SVR4 didn't exist at the time. Actually, as of SunOS 3.2, a significant part of the userland code came from System V, and the fraction increased even more in 4.0.
Try "Solaris 2.0 and up", although the early versions of Solaris 2.x weren't all that popular, so maybe 2.5 was the first version that started being used a lot.
Actually, it's the OS component of Solaris that's called SunOS; this item in the Sun Computer Administration FAQ has the mappings for releases prior to Solaris 2.5 - the mapping continued along the lines you mention until Solaris 7, when they stopped pretending that Solaris 3 would come out any time soon and got rid of the leading "2.". There's also the window system and desktop component (OpenWindows, at least until they abandoned the OPEN LOOK desktop in favor of the Motif+CDE desktop that they're now abandoning in favor of GTK+GNOME).
"Solaris" was a marketoon idea; when the SVR4 project started, we figured it was just going to be "SunOS 5.0". I guess (I left Sun in 1988) they decided to come up with the "Solaris" name for the OS+window system stuff; they retroactively applied it to SunOS 4.x, but there had been 4.x releases previously - there were no 5.x releases before the "Solaris" name was introduced, so people didn't get used to the idea of "SunOS 5.x" to the same degree, and that plus the changeover to an SVR4-derived code base probably got people to think of "SunOS" as the BSD-based versions and "Solaris" as the SVR4-based versions.
Actually, the "HyperSPARC" name was Ross Technology/Cypress's marketoons idea, not Sun's marketoons idea; at the time, Sun were doing SuperSPARC, so I guess the Ross marketoons had to go one better.
Yeah, where do you go from there? "MegaSPARC"? "UltimoSPARC"? "CosmoSPARC"? "SuperHyperUltraHumongoSPARC"?
...which finally has the SPARC V8 manual and the SPARC V9 manual online (online manuals appears to be what the original poster wanted), although they only seem to have the V9 manual online as compressed PostScript, not PDF. In the past, that documentation wasn't online; I heard a claim that it was due to copyright issues with whoever produced the printed versions (Addison-Wesley?).
See the SPARC Standards Documents Depository for the standards documents at sparc.org.
They stated that in a fashion that is, at best, a bit confusing. This draft specification for the SCSI architectural model shows on page 10 a diagram showing that there are several interconnect layers for SCSI, including the classic parallel SCSI bus (SPI), and three count 'em three serial layers, namely Fibre Channel (FC-PH), FireWire ("IEEE 1394 High Performance Serial Bus"), and IBM SSA (SSA-PH), with each interconnect layer having a protocol used to implement SCSI on that layer.
Then there are the SCSI commands, which are mostly if not entirely independent of the interconnect layer and protocol. They can be sent over parallel SCSI, Fibre Channel+FCP, FireWire+SBP, SSA-PH+SSP, {pick your link layer}+IP+TCP+iSCSI, Ethernet+HyperSCSI, or the Serial ATA link layer+serial attached SCSI, and, apparently USB+some way of sending SCSI commands over USB. (There certainly don't seem to be many bit-serial links over which you can send SCSI commands and replies.... :-))
FireWire isn't "SCSI", it's an interconnect over which you can send SCSI commands and replies. It's also an interconnect over which you can send stuff that has nothing to do with SCSI, e.g. IP datagrams (we ignore here the possiblity of IP datagrams containing TCP segments that make up iSCSI PDUs :-)), just as Fibre Channel is an interconnect over which you can send SCSI commands and replies, as well as stuff that has nothing to do with SCSI, e.g. IP datagrams, and just as USB is an interconnect over which you can send SCSI commands and replies, as well as stuff that has nothing to do with SCSI, including network packets.
...and UNIX came from Murray Hill, New Jersey.
If what you looked at was the list of "Microsoft Communications Protocol Program Standards and Other Published Protocols", that's not a list of the formerly-closed protocols for which they're publishing information, it is, as they say on that page:
a list of already published protocols that they use.
Only one of them is a Microsoft-proprietary protocol, namely CIFS (and even that has been published elsewhere). In fact, on the Microsoft Settlement Program Communications Protocol Program page, which links to that other page, they quite explicitly say that those protocols are not being licensed under this program:
There's probably some legal reason why they have to, or think they have to, enumerate all those protocols, even though you don't have to license most of them from Microsoft or sign an NDA or anything.
No, that was System III. (There were, I think, UNIX 4.x releases used inside AT&T, but they were never released as "System IV"; they went straight from "System III" to "System V".)
The page for the port says it's being done on Hercules, which is a System/390 and z/Architecture simulator; the Hercules page claims it runs on Linux and 32-bit Windows, but it can probably be made to run on UNIXes other than Linux as well, assuming it doesn't Just Work out of the box.
Umm, this blurb on the Xinerama task force at X.org seems to indicate that it's been "part of the main X consortium's tree" since X11R6.4.
Xinerama is already in Solaris 8's X server, at least according to this item on Solaris 8.
The actual item on the XFree86 Web site (go to their home page and search for "Xinerama"; the anchor tag for the Xinerama item is incorrect, with "name=anniversary", so at least with some browsers the "Xinerama" link doesn't work) says:
I don't know whether that means that code from XFree86 will be used as part or all of the implementation for the updated Xinerama, or that the item about new code going in belonged with some other item the bulk of which is missing, but I don't think the XFree86 folk originated Xinerama - they picked up their initial implementation from X11R6.4.
Correct. Just because BSD happens to have cc as one of the names for the GNU C Compiler doesn't mean that it's some compiler other than GCC. As you will discover if you actually bother looking at the source that generates the C compiler on BSD, it is GCC.
You are incorrect in your mistaken belief that I've been making some assumption that the C compiler on a system is called gcc; my makefiles use $(CC).
I'm quite aware that there are plenty of BSDLed projects; I'm just noting that the C compiler that comes with BSD isn't one of them.
But if you weren't busy on Slashdot being yet another worthless stupid brainless monkey, and actually had a brain to use and bothered using it, you could have figured that out.