from what I remember, the vax(yes, old, but still 36 bit) could handle a max of 64 Gb.
You're either trolling or misremembering or think "N-bit" refers to the size of physical addresses. VAXes were 32-bit processors; I no longer remember what the page table entries looked like, so I don't know how large the physical addresses were (but the VAX-11/780 was designed in an era when 4GB was a lot of disk space, so VAXes may well not have had even 32 bits of physical address).
32-bit machines can handle more than 4GB of physical memory. (In fact, the Pentium {Pro, II, III} and successor x86 processors can support 36-bit physical addresses.) They just can't handle it conveniently within a single process (no, segmentation on x86 doesn't make things better; it's not even necessary).
There are some people who might be delighted to see 36-bit desktop machines, but I doubt you're likely to see any new 36-bit general-purpose processors any time soon.
Actually it has everything do to. MIPS is an SGI spinoff and MIPS are the processors it uses.
Yes, SGI uses MIPS processors.
But the MIPS processors mentioned by this article aren't necessarily the MIPS processors SGI are using. It's not as if there's only one family of 64-bit MIPS processors (heck, it's not as if there's only one family of 64-bit MIPS processors used by SGI - they've used R4000's and R4400's, as well as R10000s and so on).
Err, umm, I think the AIBOs have R4000's or R4400's or something such as that in them; they're 64-bit processors. This spec sheet for the AIBO ERS-220 says it has a "64bit RISC processor".
In fact, code compiled for a 64-bit chip will be slower than the same code compiled for a 32-bit chip, because you get fewer cache lines in your caches, so you have to go back to main memory more often.
The number of cache lines you get in your caches isn't necessarily connected with whether your CPU is a 32-bit or 64-bit CPU; cache lines are typically bigger than the word size of the processor, and not necessarily governed by the word size of the processor.
If you have 64-bit pointers or integers, your variables may take a larger fraction of a cache line, though, so that you get more cache misses and have to go back to memory more often.
You won't necessarily have 64-bit pointers just because your CPU is a 64-bit CPU, and you won't even necessarily have most or all integers be 64-bit. Compilers for 64-bit CPUs may still generate 32-bit code - except when you're processing 64-bit integral data types, in which case it may generate 64-bit code for those data items.
For example, the i860 and i960 were (and are, respectively) 64 bit processors.
...for suitable values of "64-bit". The 860 had, as far as I know, only a 32-bit address space, and may also have had only 32-bit integer arithmetic and 32-bit integer registers; the 960 had, in most versions, only a 32-bit address space, although the BiiN and military versions had a larger segmented address space, and I don't remember it having 64-bit integer registers or integer arithmetic, either.
There may be people who believe that 64-bit data paths to memory, for example, make a processor a 64-bit processor. I just don't happen to be one of those people (and will not ever be one - I'm a software guy, and what matters to me is not how many bits it can push into and out of memory at a time, what matters to me is how big the address space is, and, to a lesser degree, whether 64-bit arithmetic has to be synthesized from 32-bit operations).
NetApp has had this functionality available in their Filer appliances for a number of years - you can cd into a 'magic'.snapshot directory where hourly, daily, weekly, and monthly snapshots are kept.
However, although snapshot directories let you dredge up copies of files from snapshots in case you (or a program) screws up and trashes them, that's not a convenient way to roll back the state of the entire file system.
We did implement that later (atop the same mechanism); see SnapMirror and SnapRestore: Advances in Snapshot Technology - SnapRestore(TM)(R)(LSMFT) is the "roll back an entire file system to a snapshot" feature. (At times, all this SnapStuff makes me want to SnapTheNeckOfMarketing, but so it goes....) That paper doesn't discuss technical details to the extent that the other paper does, but it should be possible from the earlier paper to figure out at least some of how you'd do it.
There is a fundamental difference between an analog modem and a device that sends digital data like a cable-modem or isdn router. Sheesh.
Sure, they are different, but they are both modems, and they use some form of modulation (time or frequency domain) to send digital data over an analog channel.
BRI ISDN lines, however, use no carrier signal; instead, the voltage on the line, as I remember, directly indicates one of 00, 01, 10, and 11, so it's not a "modem" in the sense of something that modulates a carrier wave with a digital signal and demodulates the carrier wave to extract a digital signal.
DSL modems, however, do send signals over a carrier wave and extract signals from a carrier wave, as I remember. I don't know what scheme cable modems use, but they may also modulate a carrier signal.
All modern modems (including 56k, cable, etc.) are mixed-signal devices including an analog front-end along with digital processing.
Yes, but that has nothing to do with whether the digital signal is modulated atop a carrier wave or not.
And a 486 co-processor was an i486DX where the CPU had a problem.
I remember reading a claim that, in this case, a 486 co-processor was an i486DX with a signal coming out of it that plugged into the i486SX and told it to go to sleep, so that the "co-processor" was the CPU, doing all the work, both integer and floating-point.
I just found out at lunch (can you tell I'm a geek) that it has PAL units on it, too, among other things, emulate certain really usefull VAX instructions.
It's called PALcode ("PAL" standing for "Privileged Architecture Library"), it's code rather than hardware "units", and, to quote the second edition of the Alpha AXP Architecture Reference Manual:
To run both OpenVMS and UNIX without burdening the hardware implementation with elaborate (and sometimes conflicting) operating system underpnnings, we adopted an idea from a previous Digital RISC design. Alpha places the underpinnings for interrupt delivery and return, exceptions, context switching, memory management, and error handling in a set of privileged software routines called PALcode. PALcode subroutines have controlled entries, run with interrupts turned off, and have access to real hardware (implementation) registers. By having different sets of PALcode for different operating systems, the architecture itself is not biased toward a specific operating system or computing style.
PALcode allowed us to design an architecture that could run OpenVMS gracefully without elaborate hardware and without massively rewriting the VMS synchronization and protection mechanisms. PALcode lets the Alpha architecture support some completx VAX primitives (such as the interlocked queue instructions) that are heavily used by OpenVMS, without burdening a UNIX implementation in any way.
Traps and interrupts trap to PALcode, which does the first part of the trap and interrupt handling, and, in some cases, hands control to the OS. For example, I/O device interrupts are eventually handed to the OS. The existing Alpha processors all have software TLB (translation lookaside buffer) reloads; virtual addresses are run through the addresses are run through the TLB - if there's a match, permissions are checked (and a trap generated if the check fails), and the physical address is generated and used, but if there's no match, the processor traps to PALcode, which walks the page table and loads a new TLB entry (or generates a page fault if the page table entry isn't valid).
You could, I guess, think of it as a form of microcode, but written in an extended version of the regular instruction set, allowing access to various internal registers (which differ from processor to processor).
Or, alternatively, you could think of it as lifting some low-level OS code into the instruction set architecture, but implementing it in special privileged-mode machine code rather than in hardware or microcode. (On other RISC processors, some of the functions handled by PALcode on Alpha are handled instead by low-level OS software - e.g., TLB misses on a number of RISC processors, and some low-level trap handling.)
RISC design in and of itself doesn't make it easier or harder to add 64bit support, although the if you make all your instructions 64 bit you're going to take a MASSIVE code size hit.
Few, if any, 64-bit processors have 64-bit instructions; instructions are 32-bit on 64-bit MIPS, SPARC v9, 64-bit PowerPC, Alpha, and , I think, PA-RISC 2.0. (IA-64's instructions are, as I remember, 41 bits or so, with 3 of them packed in a 128-bit bundle.)
Also, DEC had developed something called FX!32 in order to run the 32 bit IA32 apps on their new 64 bit chip, when emulation was necessary. (Sounds a lot like the strategy in Hammer, actually).
No:
the strategy in FX!32 was interpretation plus binary-to-binary translation;
the strategy in Hammer is "the 64-bit instruction set is very much like 32-bit x86 and the hardware runs both x86 and x86-64 code".
Sure it can, that's why we have segment registers.
They won't help. 48-bit segmented addresses are mapped into 32-bit linear addresses, and then run through the page table, in the x86 MMU; your segments still live inside a 32-bit flat address space.
What could help are mmap() and MapViewOfFile(), i.e. mapping stuff in and out of your address space. A pain in the ass, but there's precedent for it in, for example, PDP-11 land....
I'm not even sure that Linux can be considered Unix
It's close enough for my purposes; it may behave unlike some other UNIXes in some ways, but that statement can probably be made about just about every UNIX out there, including the ones that have passed the Single UNIX Specification test suite (the SUS doesn't cover every single aspect of a UNIX system)
although it's pretty close to POSIX (but there again, so is Windows NT).
Linux distributions resemble other UNIX-flavored OSes significantly more than do any of the NT releases, even with Interix added (and without Interix, the difference is even greater).
There just might be an accidental line or two of Xenix code (I gather, an incredibly "standards compliant" 80286-compatible System V clone) that wound up getting published and licensed with this new policy from Caldera (the ultimate heir of MS-Xenix????).
Unlikely. The UNIXes they're releasing are AT&T UNIXes that predate System V picking up various bits of Xenix. (Heck, they predate System V, period.)
The original Xenix was a V7 port to the PC (and I think there was also a PDP-11 version, as well as a 68K version used by some Radio Shack/Tandy 68K-based machine); it predated System V, and wasn't a clone, it was based on AT&T code.
Mind you, this would not necessarily take very long since the elimination of X and adoption of Berlin would simplify the vast majority of graphical application code bases.
Mind you, this would not necessarily not take very long, as the elimination of X toolkits and adoption of Berlin would mean that all the toolkit-using code of applications would have to be rewritten, even if the rewritten code would be simpler than the original code.
It's worth noting that both Mac OS X and Windows leave L&F up to the widget library and handle window management in a separate program.
...although both MacOS X and Windows come with a single standard widget library (although I think Microsoft Office on Windows may use its own versions of some widgets).
As for the separate program, are you certain that's true for Windows? If it's true of Windows NT (4.0, and 5.0 a/k/a W2K), and if by "window management" you mean the stuff done by window managers on X, at least one of those things isn't done as well by that separate program as I'd like - on X desktops, I can minimize windows even if the application is busy and doesn't respond immediately to input events, but I don't seem to be able to minimize windows for busy applications on Windows.
Our broadband in Canada has a much higher installed base for the simple reasons that our cable TV companies are far more sophisticated and enjoy a far larger market penetration in Canada than in the United States.
So how does DSL in Canada compare to DSL in the States? Is there a difference (I think people were speaking of lower prices and greater availability in Canada)? If so, is that due to
more competition from cable;
different regulatory environment;
people being more likely to live close to the CO - or to a next-generation (DSL-capable) digital loop carrier remote terminal;
To wit, the last mile of wire to the house is owned by a heavily regulated monopoly.
Who owns the last mile in that country to the north of the US, a number of whose citizens take the opportunity, in every Slashdot thread discussing "broadband", to gloat about their more-widely-available and cheaper high-speed Internet access?
I have the impression that it's, err, umm, a heavily-regulated monopoly (or monopolies, if you count both the telcos and cable companies).
As such, I'm a tad skeptical of a claim that the problem is something as simple as "oh, the last mile is owned by a heavily regulated monopoly".
When I left Britain, I could have chosen from 11 phones companies for my local service.
Using BT's local loop and their own equipment attached to the wires, or using their own local loop? (For NTL - they provide phone service, as I remember - it's presumably the latter, using their cable infrastructure.)
It seems in the US, competition in broadband has been along technological lines, e.g. cable vs. DSL vs. wireless, etc. I'm now living in Toronto, and I can tell you in contradiction to your statement that there is plenty of competition just within DSL in parts of Canada. In this case, all of the ISPs (including Bell's Sympatico) lease DSLAM ports in the CO. Some of the ISPs go a step further and install their own equipment, which is why IStop has maximum residential speeds of 3mbs/800kbs, and business speeds of 6/1mbs.
I'm not sure what the terms of the arrangements between DSL ISPs and LECs is in the US - i.e., I don't know whether my ISP leases a DSLAM port from SBC Advanced Solutions Inc. (who, in turn, use the local loop of SBC Pacific Bell to send signals between that DSLAM port and my DSL modem at home - but, as you can guess from the TLA that appears in both their names, both those companies are parts of SBC Communications), or if they're instead purchasing from SBC ASI an ATM circuit between my home and their Redback or whatever.
In either case, what you're talking about sounds like competition between ISP's, all using the ILEC's DSLAM and local loop - but we have that in the US as well.
Now, the ISPs who have installed their own equipment are acting as CLECs; I assume they're using the ILEC's local loop. Given that, there may be more CLEC competition in Canada than in the US, given that the only remaining DSL CLEC in the US is, as far as I know, Covad, and they're not in all markets.
Now, can somebody explain how the DSL "resellers" work (worked?) in the US? Is that like here, where they lease DSLAM ports, or is it truly the "reselling" of the service?
If by "resellers" you're referring to CLECs such as Covad and the now-defunct Rhythms and Northpoint, they, as far as I know, leased space in the ILEC's CO and installed their own equipment, using the ILEC's local loop.
None of them were/are ISPs; they, in turn, sold/sell their services to ISPs.
When people refer to competition being superior to government owned monopolies...
...they are not, as far as I know, referring either to Canadian cable companies (neither Shaw nor Rogers are, as far as I know, government-owned) or to at least some of the Canadian telcos (Bell Canada, at least; I seem to remember that Telus was the result of BCTel and a company that was the Alberta government-owned telco, but was privatized, and SaskTel are owned by the Saskatchewan provincial government).
Still monopolies, but, then again, it's not as if I have several cable companies from which to choose; I have the choice between AT&T and, err, umm, AT&T. (This will eventually, I guess, become a choice between Comcast and, err, umm, Comcast.) For DSL service in my area, I guess there're probably ISPs that use Covad as a CLEC, but that's about it.
I.e., it's not as if
Canada has government-owned monopoly providers of bit streams to the home;
the US has tons of competition for providers of bit streams to the home.
(By "bit streams" I'm referring to the raw ATM or whatever bit stream, not to IP connectivity, for which there is competition, even over the same wires, in the US and, as far as I know, in Canada.)
We both, as far as I know, pretty much have competition between a single DSL circuit provider (or maybe two) and a single cable modem circuit provider in most local areas.
As such, I'm not inclined to believe a simple "competition vs. monopolies" argument about the differences between the US and Canada (much less a "free-market competition vs. government monopolies" argument).
There may be differences in government behavior that explain some or all of the difference (e.g., regulatory behavior), but that's a different matter.
Data General has unix and they sell X86 base machines.
Data General do not exist, so they can neither have UNIX nor sell x86-based machines. They were bought by EMC; if you go to the old DG Web site, you get taken to a site whose only mention of DG products is a link to the EMC Powerlink site, which appears to require you to have an account.
The main EMC site doesn't seem to feature the AViiON systems; perhaps you can still get AViiON machines running DG/UX, but it doesn't look particularly easy to do so.
And don't assume it requires a 64-bit instruction set, either. It may be faster on a machine with 64-bit registers and 64-bit instructions, but it's certainly possible on Boring Old 32-Bit Processors (many C compilers implement 64-bit arithmetic data types, even on 32-bit architectures, e.g. long long int or __int64).
The real version number of windows 9x is still 4.x,
98 and Me aren't 5.x? I'm curious what GetVersion() and GetVersionEx() return on those platforms. (I don't have any Windows OT machines handy, although I suppose I'll eventually manage to get it running on VMWare at home - I've no desire to run Windows OT, of any version, for real; the Windows partition on my home machine is running NT 4.0.)
the one of 2000 5.x
W2K on my work desktop machine claims to be version "5.00.2195", i.e. 5.0 build 2195.
I think XP is really NT 5.1.
Of course, this doesn't prevent RedHat/S.u.S.E. from using their own 7.x version numbers at the moment
Hmm. At times it'd be nice if there were a Linux API to get the name and version number of the distribution, rather than that of the kernel, if for no other reason than to let you more easily or more automatically get that information from users when reporting bugs.
Slashdot Mirror
You're either trolling or misremembering or think "N-bit" refers to the size of physical addresses. VAXes were 32-bit processors; I no longer remember what the page table entries looked like, so I don't know how large the physical addresses were (but the VAX-11/780 was designed in an era when 4GB was a lot of disk space, so VAXes may well not have had even 32 bits of physical address).
32-bit machines can handle more than 4GB of physical memory. (In fact, the Pentium {Pro, II, III} and successor x86 processors can support 36-bit physical addresses.) They just can't handle it conveniently within a single process (no, segmentation on x86 doesn't make things better; it's not even necessary).
There are some people who might be delighted to see 36-bit desktop machines, but I doubt you're likely to see any new 36-bit general-purpose processors any time soon.
Yes, SGI uses MIPS processors.
But the MIPS processors mentioned by this article aren't necessarily the MIPS processors SGI are using. It's not as if there's only one family of 64-bit MIPS processors (heck, it's not as if there's only one family of 64-bit MIPS processors used by SGI - they've used R4000's and R4400's, as well as R10000s and so on).
Err, umm, I think the AIBOs have R4000's or R4400's or something such as that in them; they're 64-bit processors. This spec sheet for the AIBO ERS-220 says it has a "64bit RISC processor".
The number of cache lines you get in your caches isn't necessarily connected with whether your CPU is a 32-bit or 64-bit CPU; cache lines are typically bigger than the word size of the processor, and not necessarily governed by the word size of the processor.
If you have 64-bit pointers or integers, your variables may take a larger fraction of a cache line, though, so that you get more cache misses and have to go back to memory more often.
You won't necessarily have 64-bit pointers just because your CPU is a 64-bit CPU, and you won't even necessarily have most or all integers be 64-bit. Compilers for 64-bit CPUs may still generate 32-bit code - except when you're processing 64-bit integral data types, in which case it may generate 64-bit code for those data items.
...for suitable values of "64-bit". The 860 had, as far as I know, only a 32-bit address space, and may also have had only 32-bit integer arithmetic and 32-bit integer registers; the 960 had, in most versions, only a 32-bit address space, although the BiiN and military versions had a larger segmented address space, and I don't remember it having 64-bit integer registers or integer arithmetic, either.
There may be people who believe that 64-bit data paths to memory, for example, make a processor a 64-bit processor. I just don't happen to be one of those people (and will not ever be one - I'm a software guy, and what matters to me is not how many bits it can push into and out of memory at a time, what matters to me is how big the address space is, and, to a lesser degree, whether 64-bit arithmetic has to be synthesized from 32-bit operations).
In fact, we've had that since we first shipped our machines. There's a paper on our Web site that discuss how this works, File System Design for an NFS File Server Appliance.
However, although snapshot directories let you dredge up copies of files from snapshots in case you (or a program) screws up and trashes them, that's not a convenient way to roll back the state of the entire file system.
We did implement that later (atop the same mechanism); see SnapMirror and SnapRestore: Advances in Snapshot Technology - SnapRestore(TM)(R)(LSMFT) is the "roll back an entire file system to a snapshot" feature. (At times, all this SnapStuff makes me want to SnapTheNeckOfMarketing, but so it goes....) That paper doesn't discuss technical details to the extent that the other paper does, but it should be possible from the earlier paper to figure out at least some of how you'd do it.
Well, the ITU Telecommunication Terminology Database defines "modulation" as A process by which a quantity which characterizes an oscillation or wave follows the variations of a signal or of another oscillation or wave.", which sounds like a signal being imposed on a carrier wave.
BRI ISDN lines, however, use no carrier signal; instead, the voltage on the line, as I remember, directly indicates one of 00, 01, 10, and 11, so it's not a "modem" in the sense of something that modulates a carrier wave with a digital signal and demodulates the carrier wave to extract a digital signal.
DSL modems, however, do send signals over a carrier wave and extract signals from a carrier wave, as I remember. I don't know what scheme cable modems use, but they may also modulate a carrier signal.
Yes, but that has nothing to do with whether the digital signal is modulated atop a carrier wave or not.
I remember reading a claim that, in this case, a 486 co-processor was an i486DX with a signal coming out of it that plugged into the i486SX and told it to go to sleep, so that the "co-processor" was the CPU, doing all the work, both integer and floating-point.
It's called PALcode ("PAL" standing for "Privileged Architecture Library"), it's code rather than hardware "units", and, to quote the second edition of the Alpha AXP Architecture Reference Manual:
Traps and interrupts trap to PALcode, which does the first part of the trap and interrupt handling, and, in some cases, hands control to the OS. For example, I/O device interrupts are eventually handed to the OS. The existing Alpha processors all have software TLB (translation lookaside buffer) reloads; virtual addresses are run through the addresses are run through the TLB - if there's a match, permissions are checked (and a trap generated if the check fails), and the physical address is generated and used, but if there's no match, the processor traps to PALcode, which walks the page table and loads a new TLB entry (or generates a page fault if the page table entry isn't valid).
You could, I guess, think of it as a form of microcode, but written in an extended version of the regular instruction set, allowing access to various internal registers (which differ from processor to processor).
Or, alternatively, you could think of it as lifting some low-level OS code into the instruction set architecture, but implementing it in special privileged-mode machine code rather than in hardware or microcode. (On other RISC processors, some of the functions handled by PALcode on Alpha are handled instead by low-level OS software - e.g., TLB misses on a number of RISC processors, and some low-level trap handling.)
Few, if any, 64-bit processors have 64-bit instructions; instructions are 32-bit on 64-bit MIPS, SPARC v9, 64-bit PowerPC, Alpha, and , I think, PA-RISC 2.0. (IA-64's instructions are, as I remember, 41 bits or so, with 3 of them packed in a 128-bit bundle.)
No:
They won't help. 48-bit segmented addresses are mapped into 32-bit linear addresses, and then run through the page table, in the x86 MMU; your segments still live inside a 32-bit flat address space.
What could help are mmap() and MapViewOfFile(), i.e. mapping stuff in and out of your address space. A pain in the ass, but there's precedent for it in, for example, PDP-11 land....
It's close enough for my purposes; it may behave unlike some other UNIXes in some ways, but that statement can probably be made about just about every UNIX out there, including the ones that have passed the Single UNIX Specification test suite (the SUS doesn't cover every single aspect of a UNIX system)
Linux distributions resemble other UNIX-flavored OSes significantly more than do any of the NT releases, even with Interix added (and without Interix, the difference is even greater).
Unlikely. The UNIXes they're releasing are AT&T UNIXes that predate System V picking up various bits of Xenix. (Heck, they predate System V, period.)
The original Xenix was a V7 port to the PC (and I think there was also a PDP-11 version, as well as a 68K version used by some Radio Shack/Tandy 68K-based machine); it predated System V, and wasn't a clone, it was based on AT&T code.
Mind you, this would not necessarily not take very long, as the elimination of X toolkits and adoption of Berlin would mean that all the toolkit-using code of applications would have to be rewritten, even if the rewritten code would be simpler than the original code.
...although both MacOS X and Windows come with a single standard widget library (although I think Microsoft Office on Windows may use its own versions of some widgets).
As for the separate program, are you certain that's true for Windows? If it's true of Windows NT (4.0, and 5.0 a/k/a W2K), and if by "window management" you mean the stuff done by window managers on X, at least one of those things isn't done as well by that separate program as I'd like - on X desktops, I can minimize windows even if the application is busy and doesn't respond immediately to input events, but I don't seem to be able to minimize windows for busy applications on Windows.
So how does DSL in Canada compare to DSL in the States? Is there a difference (I think people were speaking of lower prices and greater availability in Canada)? If so, is that due to
Who owns the last mile in that country to the north of the US, a number of whose citizens take the opportunity, in every Slashdot thread discussing "broadband", to gloat about their more-widely-available and cheaper high-speed Internet access?
I have the impression that it's, err, umm, a heavily-regulated monopoly (or monopolies, if you count both the telcos and cable companies).
As such, I'm a tad skeptical of a claim that the problem is something as simple as "oh, the last mile is owned by a heavily regulated monopoly".
Using BT's local loop and their own equipment attached to the wires, or using their own local loop? (For NTL - they provide phone service, as I remember - it's presumably the latter, using their cable infrastructure.)
I'm not sure what the terms of the arrangements between DSL ISPs and LECs is in the US - i.e., I don't know whether my ISP leases a DSLAM port from SBC Advanced Solutions Inc. (who, in turn, use the local loop of SBC Pacific Bell to send signals between that DSLAM port and my DSL modem at home - but, as you can guess from the TLA that appears in both their names, both those companies are parts of SBC Communications), or if they're instead purchasing from SBC ASI an ATM circuit between my home and their Redback or whatever.
In either case, what you're talking about sounds like competition between ISP's, all using the ILEC's DSLAM and local loop - but we have that in the US as well.
Now, the ISPs who have installed their own equipment are acting as CLECs; I assume they're using the ILEC's local loop. Given that, there may be more CLEC competition in Canada than in the US, given that the only remaining DSL CLEC in the US is, as far as I know, Covad, and they're not in all markets.
If by "resellers" you're referring to CLECs such as Covad and the now-defunct Rhythms and Northpoint, they, as far as I know, leased space in the ILEC's CO and installed their own equipment, using the ILEC's local loop.
None of them were/are ISPs; they, in turn, sold /sell their services to ISPs.
...they are not, as far as I know, referring either to Canadian cable companies (neither Shaw nor Rogers are, as far as I know, government-owned) or to at least some of the Canadian telcos (Bell Canada, at least; I seem to remember that Telus was the result of BCTel and a company that was the Alberta government-owned telco, but was privatized, and SaskTel are owned by the Saskatchewan provincial government).
Still monopolies, but, then again, it's not as if I have several cable companies from which to choose; I have the choice between AT&T and, err, umm, AT&T. (This will eventually, I guess, become a choice between Comcast and, err, umm, Comcast.) For DSL service in my area, I guess there're probably ISPs that use Covad as a CLEC, but that's about it.
I.e., it's not as if
(By "bit streams" I'm referring to the raw ATM or whatever bit stream, not to IP connectivity, for which there is competition, even over the same wires, in the US and, as far as I know, in Canada.)
We both, as far as I know, pretty much have competition between a single DSL circuit provider (or maybe two) and a single cable modem circuit provider in most local areas.
As such, I'm not inclined to believe a simple "competition vs. monopolies" argument about the differences between the US and Canada (much less a "free-market competition vs. government monopolies" argument).
There may be differences in government behavior that explain some or all of the difference (e.g., regulatory behavior), but that's a different matter.
Data General do not exist, so they can neither have UNIX nor sell x86-based machines. They were bought by EMC; if you go to the old DG Web site, you get taken to a site whose only mention of DG products is a link to the EMC Powerlink site, which appears to require you to have an account.
The main EMC site doesn't seem to feature the AViiON systems; perhaps you can still get AViiON machines running DG/UX, but it doesn't look particularly easy to do so.
And don't assume it requires a 64-bit instruction set, either. It may be faster on a machine with 64-bit registers and 64-bit instructions, but it's certainly possible on Boring Old 32-Bit Processors (many C compilers implement 64-bit arithmetic data types, even on 32-bit architectures, e.g. long long int or __int64).
98 and Me aren't 5.x? I'm curious what GetVersion() and GetVersionEx() return on those platforms. (I don't have any Windows OT machines handy, although I suppose I'll eventually manage to get it running on VMWare at home - I've no desire to run Windows OT, of any version, for real; the Windows partition on my home machine is running NT 4.0.)
W2K on my work desktop machine claims to be version "5.00.2195", i.e. 5.0 build 2195.
I think XP is really NT 5.1.
Hmm. At times it'd be nice if there were a Linux API to get the name and version number of the distribution, rather than that of the kernel, if for no other reason than to let you more easily or more automatically get that information from users when reporting bugs.
Or "Christos", as in "Jesus wants you to run this operating system", or perhaps "Jesus Christ, what is this thing?"
The IEEE 802.3ah Ethernet in the First Mile Task Force Web site has stuff on various first-mile-Ethernet proposals; I don't think they've chosen any of the proposals (LRE, or any of the others) as the Official 802.3ah Standard yet.
There's an ACPI module in 4.4-RELEASE? (That's what he's running, not 5.0-current.)