It is (it's a component of GM USA, even if they at least used not to tout that fact; I think the larger Saturn is based on an Opel design, Opel being a component of GM Europe), but I don't think the person to whom you were replying was saying it wasn't - he said "it's lasted much longer than I thought an American car would last," which I assume means "it's an American car, and, given that, it's lasted longer than I thought it would".
Actually, I think "FasTrak" was just a name PacBell used for many of their higher-speed bit pipes, one of which was consumer ADSL. Project Pronto was the project you were thinking of.
and pacific bell began deploying some hardware which I know nothing about which nonetheless puts part of the DSLAM in the box on your corner
In case you're curious, the hardware is a "next-generation digital loop carrier".
A "digital loop carrier" is a scheme to let a telco run, for example, T-1s between a central office a neighborhood and multiplex 24 or so phone loops over the T-1. The subscribers would hook up to a "remote terminal", which would digitize the voice and run it to the central office over one channel of the T-1, and un-digitize voice coming over the T-1 and deliver it to the subscriber.
That gets in the way of providing DSL to those customers, as the high-frequency part of any signal over their local loop would stop at the remote terminal and not go back to the central office.
A next-generation digital loop carrier puts DSL devices (DSL Access Multiplexors, or DSLAMs) in the remote terminal box, and has a higher-capacity fiber connection back to the central office - the ATM cells running on the high-frequency DSL stuff on the subscriber line get sent over the fiber back to the central office.
Qwest doesn't have to let other DSL providing ISPs use the high-frequency portion of the copper loops.
Other DSL-providing ISPs don't necessarily need to use the high-frequency portion themselves. They merely need to be able to purchase access to the ATM cells going over that portion - my ISP doesn't have their own DSLAMs blah blah blah at the CO, they let SBC provide that portion, and they run bridged Ethernet over it.
Now, perhaps allowing other ATM-cell-stream providers use the high-frequency portion of the copper loops makes it more likely that ISPs other than the Baby Bell's own ISP or the Baby Bell's official partner ISP will be able to get access to an ATM cell stream over the local loop, but that's another matter.
I don't know if the line cards are owned by Nexxia or by the DSL provider.
Well, if all that Bell Canada provides is rack space for the DSL provider's equipment, splitters on the user's phone line, and a wire coming out of the splitter, carrying the high-frequency signal and feeding it to the DSL provider's equipment, and if the DSL provider runs their own ATM circuits out the back end of their equipment, they sound like CLECs. If all they get is an ATM pipe from Bell Canada, they sound like ISPs.
I'm pretty sure the transit from the line card to the DSL provider location is over Nexxia circuits, and Nexxia is a subsiduary of the big Bell, as is Sympatico (the Bell DSL provider), so it's not exactly like they're the one and the same company.
If "they" in "they're" refers to Nexxia and Sympatico, they may not be the same company, but they're parts of the same company, so there would be the risk of, say, Nexxia providing better service to Sympatico than to other DSL providers.
The thing that differentiates them from plain-jane ISPs for me is the fact that I the consumer have no contact what-so-ever with Bell. If they were plain ISPs I would "rent the wire aka circuit" from Bell and get ISP services from the ISP.
The amount of contact you have with Bell might depend on nothing more than quirks of Bell policy. The service for my ADSL circuit used to be part of my phone bill from Pacific Bell/SBC, and I only paid a fee for Internet service to my ISP; then SBC (the company that owns my local phone company, the company that provides ADSL services over my local phone company's wires, and an ISP that uses that ADSL service but that isn't my ISP) decided to require competitive ISPs to do that billing, so I now pay a lower (as it doesn't include an ADSL charge) phone bill for phone service and a higher (because it does include an ADSL charge) bill for my Internet service.
Both when the ADSL charge was on my phone bill and when the ADSL charge was part of my ISP fee, I'd contact my ISP if I had a technical support question (...although I'm having trouble remembering the last time I had a problem with the DSL circuit).
I would not, however, say the change in question transformed Sonic.net from a "plain-jane ISP" to some other type of ISP.
Are you saying that in the US the CLEC DSL providers actually have to run wire/fiber all the way to the head ends where the line cards are located, and they only "share" (or whatever you want to call it) the last mile of ILEC twisted POTS wire to your home?
What do you mean by "CLEC DSL provider"? If you're a CLEC, your whole raison d'etre is to provide an alternative service to the ILEC (phone company), so part of the service you might provide is wire all the way to the head ends, to plug into your own ATM network, for example. (I'm talking about ADSL CLECs here; there are other types of CLECs, such as those providing voice service.)
If, however, you're a competitive ISP using the ILEC's services, you just have to get ATM service plus ADSL service from the ILEC, and don't have to run your own fiber. (That's what my ISP was when the ADSL circuit charge appeared on my phone bill, and what it still is now that their fee includes the ADSL circuit charge.)
If so, the US ILEC's sure are a bunch of whiny baby's, considering what Bell is being forced to share here in the name of competition:)
I suspect a true CLEC would be forced to do that in Canada as well - if all the ADSL/ATM transport were being done by Bell, I'm not sure how the other entity would qualify as a local exchange carrier.
An independent ISP using the ILEC's ADSL and ATM transport infrastructure doesn't have to do that; they just plug into the ILEC's ATM network.
Bell Canada (and Bell Nexxia, their backbone infrastructure division) has the last mile wiring and a big backbone all over the metro areas. Bell Sympatico is the DSL/internet/dialup-ISP subsiduary of Bell Canada. Other DSL providers gets themselves a rack/room downtown, and buys transit over the Nexxia network, and place orders with Bell Nexxia to do the adds/deletes of the line cards for DSL customers, and pay Nexxia/Bell an install fee and (rough guess - $20 a month) for the transit/last-mile service. There are 46 of these companies.
If the line cards/DSLAMs, and the ATM traffic through them, are owned and managed by some piece of Bell Canada, and the other DSL providers just get some bit stream from the central office containing the traffic from those DSLAMs, that sounds as if the other DSL providers are ISPs, not CLECs.
ILEC are required to share their lines to CLEC's, that's why I have 46 choices for DSL here in Toronto,
You have 46 different LECs in Toronto? Or you have 46 different ISPs in Toronto? If the latter, how much of that is due to CLECs (e.g., independent ISPs finding it easier to deal with the CLEC than with the ILEC)?
Yup, the CAIP site is interesting; at least you guys seem to make the cable companies let other ISPs onto the network - I think there might be some cases where we Yanks do, but there doesn't appear to be a general requirement for them to do so. (It also appears that Canadian ILECs do some of the same tricks US ILECs do, e.g. one item about somebody whose line magically became DSL-capable once they decided to go with Sympatico....)
However, most of it (perhaps not surprisingly) seems to deal with issues for competitive ISPs rather than issues for CLECs.
With only around 12k customers, it's not economically feasable for us to offer voice communcation service. So, our DSL service goes "poof". If ILECs aren't forced to share, they won't!
There's more than one form of sharing involved here. There's the ILEC offering access to its copper pairs and central office space to CLECs, and there's the ILEC offering access to its ADSL transport to ISPs.
I'm not sure I see anything in the attachment to the press release discussing anything having to do with the latter (are any requirements on ILECs to offer access to ISPs other than any ISP owned by the ILEC or the ILEC's parent federal requirements, state requirements, or both?).
The attachment seems to discuss issues for CLECs, not ISPs; my DSL circuit is provided by SBC , but my Internet access is provided by Sonic.net, and I'm quite happy with both (and would prefer not to have to switch the latter to SBC).
In Canada the local phone company basically has a monopoly over the last mile
Do you mean that there is no local loop unbundling of any sort (no CLECs either leasing the last mile or leasing access to, for example, the high-frequency portion to the last mile)?
Bell Canada's tariff for ADSL speaks of "Service providers wishing to offer a competitive
alternative to the Company's ADSL Access service" doing so by "co-locating their ADSL transmission equipment in a Company serving wire centre in accordance with the terms, conditions, rates and charges specified in the Company's Access Services Tariff (AST) Item 110 - Co-location Arrangements for Interconnecting Canadian Carriers and Digital Subscriber Line Service Providers
(DSLSPs)"; the next paragraph appears to speak of that being done over "a particular end-user's Company-provided, individual line", which sounds like line-sharing to me.
(That tariff also appears to speak of Bell Canada providing the ADSL Access service to service providers, rather than having the service provider offering an alternative to ADSL Access service; those service providers might be ISPs, rather than the CLECs who would provide competitive alternatives to ADSL Access.)
That tariff item refers to an item for Local Network Interconnection and Component Unbundling, which speaks of "Digital Subscriber Line Service Providers", who are explicitly described as not being CLECs (that would probably include ISPs competitive with Bell Sympatico), and of CLECs.
It is all done over the phonelines, but there many many DSL companies competing (although only a few get mainstream attention). The competition gives the 'hardcore' internet users much choice, but in the end the DSL network is all owned by BT.
So are the "DSL companies" what would be called "competitive local exchange carriers", or CLECs, here in the US, or ISPs, or both?
A CLEC (for DSL) provides its own DSL circuit, possibly using some of the ILEC's equipment (phone lines, possibly central office DSL equipment - that's "local loop unbundling", where the "local loop", or phone lines between the ILEC's central office and the subscriber, are used, in part or in whole by a CLEC; that can involve "line sharing", where the ILEC offers voice telephone service on the wire to the subscriber and a CLEC offers a DSL circuit at higher frequency over the same wire, or can involve only the CLEC using the wire). An ISP uses either the ILEC's or a CLEC's DSL circuit to provide Internet access. The ISP might be part of the ILEC (or the CLEC, if there are any CLECs that are also ISPs) or not.
For example, I get my DSL service through the ILEC, which is one of the pieces left over after AT&T was broken up (so it's roughly equivalent to BT, in my area). However, I get my Internet access from Sonic.net, not from the ISP that's part of the same company as my ILEC is.
The Canadian push to get the entire country onto the Internet most likely means that regulations such as this one will be few and far between.
Or, if the current situation in Canada with DSL is (as the Baby Bells appear to allege is the case in the US) that there are line-sharing and/or co-location requirements that mean that the ILECs can't make enough money to justify investing in expanding coverage, maybe there will be more regulatory changes such as that.
(I am not saying any of that is the case. I don't know for certain, although I'm somewhat skeptical of the Baby Bell's claims that it is. I'm just noting that the correct conclusion to draw isn't necessarily the "obvious" one.)
So, being a user of EarthLink DSL for the past two and a half years, does this mean I should start looking into Verizon's DSL price plans?
That depends on whether any of the items that no longer have to be unbundled are the ones that EarthLink could use to provide Internet access over Verizon's ATM transport. (Does "packet switching" count? The document with the new rules says
Packet Switching - Incumbent LECs are not required to unbundle packet switching,
including routers and DSLAMs, as a stand-alone network element. The order eliminates
the current limited requirement for unbundling of packet switching.
but I don't know whether that's what's used by competitive ISPs.)
Some articles discussing this speak of it limiting the ability of competitors to provide "high-speed Internet access", but the authors of those articles might not understand the difference between a LEC and an ISP - my DSL service is provided by SBC Advanced Services, over the wires owned by Pacific Bell^H^H^H^H^H^H^H^H^H^H^H^HSBC California, but my Internet access is provided by Sonic.net.
So what are the Canadian requirements on ILECs concerning CLECs (line-sharing, colocation, etc.), non-carrier ISPs, etc.? I went to the CRTC Web site, but none of the "Statutes and Regulations" appeared to address that, and there are a ton of "Decisions, Notices and Orders" but I'm not going to plow through all of them. (Even a Google search for
canadian regulations CLEC line-sharing
turned up a pile of stuff the first items of which didn't seem to directly address the question.)
And the US has never used it's economic power to force other countries to revise their economies in tune with American interests instead of their own self interest. (Can we say landmine treaty boys and girls? I knew you could!)
I'm not sure how the US not signing the land mine treaty involves forcing other countries to revise their economies; that sounds more like a case of the US applying pressure for "structural adjustment" through the IMF.
the NT kernel is a microkernel much like the mach kernel in MacOS 10.x
Yeah, both of them keep a ton of stuff in kernel-mode code, such as file sysstems, network stacks, etc.. They're not microkernels much like, say, QNX, however.
When pretty much everything lives in userland, portability is pretty easy.
Perhaps Microsoft should've done that, then, rather than doing an OS with file systems, networking stacks, and device drivers for the devices used by those components running in kernel mode. (See "Inside Windows NT" and its successors.)
Heck, most UNIX systems (including, I have the impression, the fruit-flavored one) have managed to keep most of the graphics subsystem out of the kernel; does that make them more microkernelish than NT 4.0 and later?
Also, even when lots of stuff doesn't live in userland, portability isn't necessarily made much worse, if it's made worse at all - parsing pathnames, checking free-block bitmaps, cracking IP or TCP headers, constructing IP or TCP headers, looking up routes, etc. aren't exactly processor-dependent (and if you want to do processor-specific optimizations such as, for example, fast Internet checksum routines, that's something you can do in the same fashion in the kernel or in userland, and probably would do in userland as well as in the kernel).
Now, Windows doesn't look like a microkernel at all.
As far as I know, it never did look anything like what I'd call a microkernel. Yes, some parts of the userland APIs are implemented by sending messages to subsystem processes, but many other parts are just implemented by library calls to NT native system calls, and even on Boring Old Monolithic Kernel UNIX Systems you have processes such as userland automounters involved in the implementation of open().
And it's not at all portable, either. From what I understand, the Itanic port is giving them big headaches, and Intel is none-too-pleased about it.
Is it giving them any bigger headaches than other IA-64 ports, such as the Linux port or the FreeBSD port?
After that, the coders didn't have to bother with endian neutral code
As far as I know, both the MIPS and PowerPC versions of NT expected a little-endian byte order, as did the Alpha port (yes, you can do big-endian on Alpha).
Thanks for informing me, but something is seriously wrong with that approach. It might look and feel tasty to experts, but it's a seriously complicated and messy way to have two slightly differing ways of doing what is, in most respects, the same thing.
Well:
the cut/copy-to-clipboard and paste from clipboard approach is probably nto going away any time soon, given that it's the way things work on Windows and MacOS;
maybe the middle-mouse-button paste-current-selection can be made to go away, but not without a lot of complaints;
so if it is the case that the problem can only be fixed by getting rid of one of the mechanisms, I wouldn't hold my breath waiting for the problem to be fixed.
I'm also completely unconvinced, at this point, that getting rid of the paste-current-selection mechanism is necessary.
And as long as the middle mouse button is used to paste, she won't be able to ignore it either, she'll just be terminally confused. I know I've been.
She'd only be confused if she knows about it and has trouble understanding it; I'm unconvinced that either will necessarily be the case. Heck, give most users of desktop UNIX+X two-button mice and turn off the "click both buttons to emulate the third button" option by default in the GUI, and they won't even be able to use it. Those of us who can handle paste-current-selection can order 3-button mice and still use it.
Do you have any idea about how many of the complaints about X copying/pasting that comes from this issue? I'd wager it's a huge part of them.
I wouldn't wager that without more data. I'd bet a huge part of it comes from the fact that some applications and toolkits don't implement cut and copy as "cut/copy to the clipboard", but instead change the primary selection, and implement paste as "paste primary selection" rather than as "paste clipboard"; if so, as KDE 3.x displaces earlier versions of KDE, a lot of that will go away.
But
seeing that it be solved (in a minimal, functional set of apps) is, to me, an issue for the distros -- something that I'd hope the effort under discussion will solve.
The distributors might not entirely agree with that. They might not be willing to supply modified versions of those applications (or toolkits) in the name of consistency, as that means more stuff to maintain and sync with the upstream software.
They might be willing to support efforts such as freedesktop.org, and let them try to encourage consistency, and they might even be willing to pay some developers to contribute code upstream.
Do Edit > Copy (or ctrl-C) in Mozilla, Edit > Paste (or ctrl-V) in Nedit. Nothing happens. Same with Kedit. Only right-click works.
7.0 is an older release, and at least some of that problem is due to the disagreement between older (pre-3.0) versions of Qt and GTK+ in the interpretation of the clipboard. SuSE's list of press releases speaks of 7.1 coming out in early 2001, and doesn't speak of 7.0 at all in 2001 (their archive doesn't appear to go back further than 2001); Qt 3.0 came out in October 2001, according to the Trolltech press release archive, so SuSE 7.0 was probably incapable of being bundled with a KDE release that included Qt 3.0 as it appears that no such release existed at the time 7.0 came out.
That means that KDE was, unfortunately, simply not going to play well with many applications when using the clipboard.
The inability of Mozilla and Nedit to play together is somewhat more of a surprise; I don't know where Mozilla uses GTK+ rather than rolling its own widgets, but the GTK+ parts should work together with Nedit, as Nedit uses Motif, and Motif uses the same interpretation of the clipboard as GTK+.
In the case of Mozilla and KEdit, it's not as if there's some configuration file that the SuSE folks set up incorrectly, and if they'd just fixed that those two apps would work together. The same is probably true of Mozilla and Nedit. It's also not as if they could've hopped into the time machine and shipped SuSE 7.0 with KDE 3.0....
Perhaps these are just technical details, but, regardless of whether a user wants to hear the technical details or not, they sometimes control whether the user's problem can be solved, when it can be solved, and how it can be solved.
Ultimately, much of the reasoning has to be developer's reasoning, because unless the developers can do something about the problem, and do so, the problem isn't going to get solved.
1: Yes! In other words, have something that works for overwrite always work consistently. Then paste-current-selection is welcome gravy--but not otherwise. And it's still far from true of current distros even in their default state.
It's not an issue of the distribution, it's an issue of the applications and of the underlying toolkit, etc.. If application X doesn't have cut/copy/paste operations, it's probably because the developer didn't bother implementng it or the widget they're using doesn't support it.
They also don't suggest what to do in those (probably rare) cases where using those keys for those purposes wouldn't necessarily be the best idea. I'd vote for a right-mouse-button menu that offers Cut, Copy, and Paste; I'm not sure why Microsoft didn't do that in the NT 5.0^H^H^H^H^H^HWindows 2000 Command Prompt window - perhaps that's fixed in NT 5.1^H^H^H^H^H^HWindows XP.
2: For developers, yes. But for users, they could care less about such terminology.
OK, as long as "developers" includes anybody who writes documentation - and anybody who tells their friends how to use the system, etc..
I.e., the users would care about the terminology if it confused them, for example if it let them to think that selecting text on the screen automatically caused it to be copied to the clipboard, so that if they used Ctrl+V the stuff they selected, rather than the stuff they last copied with Ctrl+C or cut with Ctrl+X, would be pasted, and so that they thought that selecting stuff automatically discarded what they'd copied to the clipboard in favor of the new stuff.
I consider myself reasonably computer literate, and I was completely confused by this explanation. If I have to read this twice to understand how the X clipboard works, the average user is never going to understand why Control-C doesn't work...
Is the "average user" going to be using an terminal window at all? Presumably much of the reason for the desktop GUI environments is to allow users to be able to use {pick your favorite UNIX flavor} without having to use the CLI. If they're not going to be using terminal windows, they're not even going to know that control-C doesn't mean "copy" in such a window.
All a user who uses only the GUI would need to know is that:
there's text you select, and there's a clipboard, and they're not the same thing;
"cut" copies the currently-selected text in the window you're in to the clipboard and then deletes the selected copy;
"copy" copies the currently-selected text in the window you're in to the clipboard but leaves the selected copy alone;
"paste" pastes the clipboard in place of the currently-selected text in the window you're in, if there is any, or inserts it at the current insertion cursor of the window you're in, if there is no currently-selected text;
the middle mouse button pastes the currently selected text at the current insertion cursor in the window you're in.
Anybody who can't understand all but the last clause of that is going to have trouble with cut/copy-and-paste with X or with Windows or with MacOS, as that's the way all their clipboards work. The last clause would be a problem only with X, as the other GUIs I mentioned don't have middle-mouse-button paste-current-selection.
As for the users who would use the CLI, all they'd need to know is that, for better or worse, terminal windows don't support control+C - or most of the other control+{key} operations - because they pass those key combinations to the terminal as if the user'd typed control+{key} at a dumb terminal. They either have to use mouse-based copy and paste, as they can't use control+C and control+V, or, on X, using middle-mouse-button paste-current-selection.
Who cares if it's called PRIMARY or CLIPBOARD? The end result is the same: a user is merrily copying and pasting with one method, only to find that, sorry, it shall break down when it comes to overwriting. Talk about interface consistency...
The only method you can copy and paste with is the one involving the clipboard; you cannot cut and paste with the middle mouse button, you can only paste-current-selection. When phrased that way, it's pretty obvious why you can't overwrite - the "current-selection" part is a bit of a giveaway, as overwriting is pasting something on top of, err, umm, the current selection, which is what the middle mouse button pastes.
I suspect a LOT of the confusion would disappear if:
there were few applications (or maybe no applications) that support middle-mouse-button paste-current-selection but don't support clipboard-based cut/copy-and-paste;
people no longer spoke of selection changing the clipboard or the middle mouse button pasting the clipboard or of the paste-current-selection stuff being "copy and paste";
as then people wouldn't expect the middle mouse button operation to behave like "cut and paste".
Middle-mouse-button paste is a very useful operation. One should not, however, be particularly surprised that it doesn't support replacing one selection with the other, given that what it pastes is the selection.
(That's why I do care what the selections are called; blurring the distinction between cut/copy-and-paste and paste-current-selection can lead to people being surprised that you can't use paste-current-selection to do all the things you can do with copy-and-paste.)
Slashdot Mirror
It is (it's a component of GM USA, even if they at least used not to tout that fact; I think the larger Saturn is based on an Opel design, Opel being a component of GM Europe), but I don't think the person to whom you were replying was saying it wasn't - he said "it's lasted much longer than I thought an American car would last," which I assume means "it's an American car, and, given that, it's lasted longer than I thought it would".
Actually, I think "FasTrak" was just a name PacBell used for many of their higher-speed bit pipes, one of which was consumer ADSL. Project Pronto was the project you were thinking of.
In case you're curious, the hardware is a "next-generation digital loop carrier".
A "digital loop carrier" is a scheme to let a telco run, for example, T-1s between a central office a neighborhood and multiplex 24 or so phone loops over the T-1. The subscribers would hook up to a "remote terminal", which would digitize the voice and run it to the central office over one channel of the T-1, and un-digitize voice coming over the T-1 and deliver it to the subscriber.
That gets in the way of providing DSL to those customers, as the high-frequency part of any signal over their local loop would stop at the remote terminal and not go back to the central office.
A next-generation digital loop carrier puts DSL devices (DSL Access Multiplexors, or DSLAMs) in the remote terminal box, and has a higher-capacity fiber connection back to the central office - the ATM cells running on the high-frequency DSL stuff on the subscriber line get sent over the fiber back to the central office.
Other DSL-providing ISPs don't necessarily need to use the high-frequency portion themselves. They merely need to be able to purchase access to the ATM cells going over that portion - my ISP doesn't have their own DSLAMs blah blah blah at the CO, they let SBC provide that portion, and they run bridged Ethernet over it.
Now, perhaps allowing other ATM-cell-stream providers use the high-frequency portion of the copper loops makes it more likely that ISPs other than the Baby Bell's own ISP or the Baby Bell's official partner ISP will be able to get access to an ATM cell stream over the local loop, but that's another matter.
Are you thinking of the Honda DUALNOTE (NorthAmericanized into the Acura DN-X)? (Although the horsepower and fuel economy values are "calculated", which presumably means "we hadn't gotten enough working as of the 2001 Tokyo Motor Show to be able to try it to see what we could get".)
Well, if all that Bell Canada provides is rack space for the DSL provider's equipment, splitters on the user's phone line, and a wire coming out of the splitter, carrying the high-frequency signal and feeding it to the DSL provider's equipment, and if the DSL provider runs their own ATM circuits out the back end of their equipment, they sound like CLECs. If all they get is an ATM pipe from Bell Canada, they sound like ISPs.
If "they" in "they're" refers to Nexxia and Sympatico, they may not be the same company, but they're parts of the same company, so there would be the risk of, say, Nexxia providing better service to Sympatico than to other DSL providers.
The amount of contact you have with Bell might depend on nothing more than quirks of Bell policy. The service for my ADSL circuit used to be part of my phone bill from Pacific Bell/SBC, and I only paid a fee for Internet service to my ISP; then SBC (the company that owns my local phone company, the company that provides ADSL services over my local phone company's wires, and an ISP that uses that ADSL service but that isn't my ISP) decided to require competitive ISPs to do that billing, so I now pay a lower (as it doesn't include an ADSL charge) phone bill for phone service and a higher (because it does include an ADSL charge) bill for my Internet service.
Both when the ADSL charge was on my phone bill and when the ADSL charge was part of my ISP fee, I'd contact my ISP if I had a technical support question (...although I'm having trouble remembering the last time I had a problem with the DSL circuit).
I would not, however, say the change in question transformed Sonic.net from a "plain-jane ISP" to some other type of ISP.
What do you mean by "CLEC DSL provider"? If you're a CLEC, your whole raison d'etre is to provide an alternative service to the ILEC (phone company), so part of the service you might provide is wire all the way to the head ends, to plug into your own ATM network, for example. (I'm talking about ADSL CLECs here; there are other types of CLECs, such as those providing voice service.)
If, however, you're a competitive ISP using the ILEC's services, you just have to get ATM service plus ADSL service from the ILEC, and don't have to run your own fiber. (That's what my ISP was when the ADSL circuit charge appeared on my phone bill, and what it still is now that their fee includes the ADSL circuit charge.)
I suspect a true CLEC would be forced to do that in Canada as well - if all the ADSL/ATM transport were being done by Bell, I'm not sure how the other entity would qualify as a local exchange carrier.
An independent ISP using the ILEC's ADSL and ATM transport infrastructure doesn't have to do that; they just plug into the ILEC's ATM network.
If the line cards/DSLAMs, and the ATM traffic through them, are owned and managed by some piece of Bell Canada, and the other DSL providers just get some bit stream from the central office containing the traffic from those DSLAMs, that sounds as if the other DSL providers are ISPs, not CLECs.
Yes, they do, and have done so ever since they invented Open Boot, which was the basis for OpenFirmware.
You have 46 different LECs in Toronto? Or you have 46 different ISPs in Toronto? If the latter, how much of that is due to CLECs (e.g., independent ISPs finding it easier to deal with the CLEC than with the ILEC)?
Yup, the CAIP site is interesting; at least you guys seem to make the cable companies let other ISPs onto the network - I think there might be some cases where we Yanks do, but there doesn't appear to be a general requirement for them to do so. (It also appears that Canadian ILECs do some of the same tricks US ILECs do, e.g. one item about somebody whose line magically became DSL-capable once they decided to go with Sympatico....)
However, most of it (perhaps not surprisingly) seems to deal with issues for competitive ISPs rather than issues for CLECs.
That wouldn't happen to be my ISP, would it?
There's more than one form of sharing involved here. There's the ILEC offering access to its copper pairs and central office space to CLECs, and there's the ILEC offering access to its ADSL transport to ISPs.
I'm not sure I see anything in the attachment to the press release discussing anything having to do with the latter (are any requirements on ILECs to offer access to ISPs other than any ISP owned by the ILEC or the ILEC's parent federal requirements, state requirements, or both?).
The attachment seems to discuss issues for CLECs, not ISPs; my DSL circuit is provided by SBC , but my Internet access is provided by Sonic.net, and I'm quite happy with both (and would prefer not to have to switch the latter to SBC).
Do you mean that there is no local loop unbundling of any sort (no CLECs either leasing the last mile or leasing access to, for example, the high-frequency portion to the last mile)? Bell Canada's tariff for ADSL speaks of "Service providers wishing to offer a competitive alternative to the Company's ADSL Access service" doing so by "co-locating their ADSL transmission equipment in a Company serving wire centre in accordance with the terms, conditions, rates and charges specified in the Company's Access Services Tariff (AST) Item 110 - Co-location Arrangements for Interconnecting Canadian Carriers and Digital Subscriber Line Service Providers (DSLSPs)"; the next paragraph appears to speak of that being done over "a particular end-user's Company-provided, individual line", which sounds like line-sharing to me.
(That tariff also appears to speak of Bell Canada providing the ADSL Access service to service providers, rather than having the service provider offering an alternative to ADSL Access service; those service providers might be ISPs, rather than the CLECs who would provide competitive alternatives to ADSL Access.)
That tariff item refers to an item for Local Network Interconnection and Component Unbundling, which speaks of "Digital Subscriber Line Service Providers", who are explicitly described as not being CLECs (that would probably include ISPs competitive with Bell Sympatico), and of CLECs.
So are the "DSL companies" what would be called "competitive local exchange carriers", or CLECs, here in the US, or ISPs, or both?
A CLEC (for DSL) provides its own DSL circuit, possibly using some of the ILEC's equipment (phone lines, possibly central office DSL equipment - that's "local loop unbundling", where the "local loop", or phone lines between the ILEC's central office and the subscriber, are used, in part or in whole by a CLEC; that can involve "line sharing", where the ILEC offers voice telephone service on the wire to the subscriber and a CLEC offers a DSL circuit at higher frequency over the same wire, or can involve only the CLEC using the wire). An ISP uses either the ILEC's or a CLEC's DSL circuit to provide Internet access. The ISP might be part of the ILEC (or the CLEC, if there are any CLECs that are also ISPs) or not.
For example, I get my DSL service through the ILEC, which is one of the pieces left over after AT&T was broken up (so it's roughly equivalent to BT, in my area). However, I get my Internet access from Sonic.net, not from the ISP that's part of the same company as my ILEC is.
Or, if the current situation in Canada with DSL is (as the Baby Bells appear to allege is the case in the US) that there are line-sharing and/or co-location requirements that mean that the ILECs can't make enough money to justify investing in expanding coverage, maybe there will be more regulatory changes such as that.
(I am not saying any of that is the case. I don't know for certain, although I'm somewhat skeptical of the Baby Bell's claims that it is. I'm just noting that the correct conclusion to draw isn't necessarily the "obvious" one.)
That depends on whether any of the items that no longer have to be unbundled are the ones that EarthLink could use to provide Internet access over Verizon's ATM transport. (Does "packet switching" count? The document with the new rules says
but I don't know whether that's what's used by competitive ISPs.)
Some articles discussing this speak of it limiting the ability of competitors to provide "high-speed Internet access", but the authors of those articles might not understand the difference between a LEC and an ISP - my DSL service is provided by SBC Advanced Services, over the wires owned by Pacific Bell^H^H^H^H^H^H^H^H^H^H^H^HSBC California, but my Internet access is provided by Sonic.net.
So what are the Canadian requirements on ILECs concerning CLECs (line-sharing, colocation, etc.), non-carrier ISPs, etc.? I went to the CRTC Web site, but none of the "Statutes and Regulations" appeared to address that, and there are a ton of "Decisions, Notices and Orders" but I'm not going to plow through all of them. (Even a Google search for canadian regulations CLEC line-sharing turned up a pile of stuff the first items of which didn't seem to directly address the question.)
I'm not sure we can take "credit" for Saddam Hussein getting into power, although we can certainly take credit for providing some assistance in making Weapons of Mass Destruction(TM).
Khomeini? No, I don't think so.
Carlos Castillo Armas? Yes.
Augusto Pinochet? Probably.
I'm not sure how the US not signing the land mine treaty involves forcing other countries to revise their economies; that sounds more like a case of the US applying pressure for "structural adjustment" through the IMF.
Why not?
Yeah, both of them keep a ton of stuff in kernel-mode code, such as file sysstems, network stacks, etc.. They're not microkernels much like, say, QNX, however.
Perhaps Microsoft should've done that, then, rather than doing an OS with file systems, networking stacks, and device drivers for the devices used by those components running in kernel mode. (See "Inside Windows NT" and its successors.)
Heck, most UNIX systems (including, I have the impression, the fruit-flavored one) have managed to keep most of the graphics subsystem out of the kernel; does that make them more microkernelish than NT 4.0 and later?
Also, even when lots of stuff doesn't live in userland, portability isn't necessarily made much worse, if it's made worse at all - parsing pathnames, checking free-block bitmaps, cracking IP or TCP headers, constructing IP or TCP headers, looking up routes, etc. aren't exactly processor-dependent (and if you want to do processor-specific optimizations such as, for example, fast Internet checksum routines, that's something you can do in the same fashion in the kernel or in userland, and probably would do in userland as well as in the kernel).
As far as I know, it never did look anything like what I'd call a microkernel. Yes, some parts of the userland APIs are implemented by sending messages to subsystem processes, but many other parts are just implemented by library calls to NT native system calls, and even on Boring Old Monolithic Kernel UNIX Systems you have processes such as userland automounters involved in the implementation of open().
Is it giving them any bigger headaches than other IA-64 ports, such as the Linux port or the FreeBSD port?
As far as I know, both the MIPS and PowerPC versions of NT expected a little-endian byte order, as did the Alpha port (yes, you can do big-endian on Alpha).
Well:
so if it is the case that the problem can only be fixed by getting rid of one of the mechanisms, I wouldn't hold my breath waiting for the problem to be fixed.
I'm also completely unconvinced, at this point, that getting rid of the paste-current-selection mechanism is necessary.
She'd only be confused if she knows about it and has trouble understanding it; I'm unconvinced that either will necessarily be the case. Heck, give most users of desktop UNIX+X two-button mice and turn off the "click both buttons to emulate the third button" option by default in the GUI, and they won't even be able to use it. Those of us who can handle paste-current-selection can order 3-button mice and still use it.
I wouldn't wager that without more data. I'd bet a huge part of it comes from the fact that some applications and toolkits don't implement cut and copy as "cut/copy to the clipboard", but instead change the primary selection, and implement paste as "paste primary selection" rather than as "paste clipboard"; if so, as KDE 3.x displaces earlier versions of KDE, a lot of that will go away.
The distributors might not entirely agree with that. They might not be willing to supply modified versions of those applications (or toolkits) in the name of consistency, as that means more stuff to maintain and sync with the upstream software.
They might be willing to support efforts such as freedesktop.org, and let them try to encourage consistency, and they might even be willing to pay some developers to contribute code upstream.
7.0 is an older release, and at least some of that problem is due to the disagreement between older (pre-3.0) versions of Qt and GTK+ in the interpretation of the clipboard. SuSE's list of press releases speaks of 7.1 coming out in early 2001, and doesn't speak of 7.0 at all in 2001 (their archive doesn't appear to go back further than 2001); Qt 3.0 came out in October 2001, according to the Trolltech press release archive, so SuSE 7.0 was probably incapable of being bundled with a KDE release that included Qt 3.0 as it appears that no such release existed at the time 7.0 came out.
That means that KDE was, unfortunately, simply not going to play well with many applications when using the clipboard.
The inability of Mozilla and Nedit to play together is somewhat more of a surprise; I don't know where Mozilla uses GTK+ rather than rolling its own widgets, but the GTK+ parts should work together with Nedit, as Nedit uses Motif, and Motif uses the same interpretation of the clipboard as GTK+.
In the case of Mozilla and KEdit, it's not as if there's some configuration file that the SuSE folks set up incorrectly, and if they'd just fixed that those two apps would work together. The same is probably true of Mozilla and Nedit. It's also not as if they could've hopped into the time machine and shipped SuSE 7.0 with KDE 3.0....
Perhaps these are just technical details, but, regardless of whether a user wants to hear the technical details or not, they sometimes control whether the user's problem can be solved, when it can be solved, and how it can be solved.
Ultimately, much of the reasoning has to be developer's reasoning, because unless the developers can do something about the problem, and do so, the problem isn't going to get solved.
It's not an issue of the distribution, it's an issue of the applications and of the underlying toolkit, etc.. If application X doesn't have cut/copy/paste operations, it's probably because the developer didn't bother implementng it or the widget they're using doesn't support it.
The KDE User Interface Guidelines suggest in the predefined shortcuts section, and the GNOME Human Interface Guidelines suggest in the standard application shortcut keys section, that Ctrl+C be used for "copy", Ctrl+X be used for "cut", and Ctrl+V be used for "paste"; however, I don't know whether they suggest that those operations exist in the first place.
They also don't suggest what to do in those (probably rare) cases where using those keys for those purposes wouldn't necessarily be the best idea. I'd vote for a right-mouse-button menu that offers Cut, Copy, and Paste; I'm not sure why Microsoft didn't do that in the NT 5.0^H^H^H^H^H^HWindows 2000 Command Prompt window - perhaps that's fixed in NT 5.1^H^H^H^H^H^HWindows XP.
OK, as long as "developers" includes anybody who writes documentation - and anybody who tells their friends how to use the system, etc..
I.e., the users would care about the terminology if it confused them, for example if it let them to think that selecting text on the screen automatically caused it to be copied to the clipboard, so that if they used Ctrl+V the stuff they selected, rather than the stuff they last copied with Ctrl+C or cut with Ctrl+X, would be pasted, and so that they thought that selecting stuff automatically discarded what they'd copied to the clipboard in favor of the new stuff.
Is the "average user" going to be using an terminal window at all? Presumably much of the reason for the desktop GUI environments is to allow users to be able to use {pick your favorite UNIX flavor} without having to use the CLI. If they're not going to be using terminal windows, they're not even going to know that control-C doesn't mean "copy" in such a window.
All a user who uses only the GUI would need to know is that:
Anybody who can't understand all but the last clause of that is going to have trouble with cut/copy-and-paste with X or with Windows or with MacOS, as that's the way all their clipboards work. The last clause would be a problem only with X, as the other GUIs I mentioned don't have middle-mouse-button paste-current-selection.
As for the users who would use the CLI, all they'd need to know is that, for better or worse, terminal windows don't support control+C - or most of the other control+{key} operations - because they pass those key combinations to the terminal as if the user'd typed control+{key} at a dumb terminal. They either have to use mouse-based copy and paste, as they can't use control+C and control+V, or, on X, using middle-mouse-button paste-current-selection.
The only method you can copy and paste with is the one involving the clipboard; you cannot cut and paste with the middle mouse button, you can only paste-current-selection. When phrased that way, it's pretty obvious why you can't overwrite - the "current-selection" part is a bit of a giveaway, as overwriting is pasting something on top of, err, umm, the current selection, which is what the middle mouse button pastes.
I suspect a LOT of the confusion would disappear if:
as then people wouldn't expect the middle mouse button operation to behave like "cut and paste".
Middle-mouse-button paste is a very useful operation. One should not, however, be particularly surprised that it doesn't support replacing one selection with the other, given that what it pastes is the selection.
(That's why I do care what the selections are called; blurring the distinction between cut/copy-and-paste and paste-current-selection can lead to people being surprised that you can't use paste-current-selection to do all the things you can do with copy-and-paste.)