An overview that includes "XFree86-style" software in the "free software" category:
Non-copylefted free software comes from the author with permission to redistribute and modify, and also to add additional restrictions to it.
If a program is free but not copylefted, then some copies or modified versions may not be free at all. A software company can compile the program, with or without modifications, and distribute the executable file as a proprietary software product.
The X Window System illustrates this. The X Consortium releases X11 with distribution terms that make it non-copylefted free software. If you wish, you can get a copy which has those distribution terms and is free. However, there are non-free versions as well, and there are popular workstations and PC graphics boards for which non-free versions are the only ones that work. If you are using this hardware, X11 is not free software for you.
This says that, err, umm, according to the overview of categories of software, somebody can take Free Software, modify it, distribute it, and keep the changes secret. (Anybody who believes otherwise either has not read, or does not understand, the "overview of categories of software" page in question.)
Slashdotters across the country should be informed of , with its inclusion of a bill by y Representative Billy Tauzin (R-LA) allowing BabyBells to prevent local ISPs from accessing their DSL lines.
ISPs typically don't, as far as I know, "access DSL lines", if by that you mean "provide 'DSLtone' on DSL lines"; that's done by the ILEC or a CLEC. (Covad and Rhythms are CLECs, and Northpoint was a CLEC).
A DSL customer can access an ISP over their DSL ; if that's what you mean, then, for what it's worth, H. R. 1542 says, according to the contents as shown on the US Library of Congress THOMAS service, says:
SEC. 5. INTERNET CONSUMERS FREEDOM OF CHOICE.
Part I of title II of the Communications Act of 1934, as amended by section 4, is amended by adding at the end the following new section:
`SEC. 233. INTERNET CONSUMERS FREEDOM OF CHOICE.
`(a) PURPOSE- It is the purpose of this section to ensure that Internet users have freedom of choice of Internet service provider.
`(b) OBLIGATIONS OF INCUMBENT LOCAL EXCHANGE CARRIERS- Each incumbent local exchange carrier has the duty to provide--
`(1) Internet users with the ability to subscribe to and have access to any Internet service provider that interconnects with such carrier's high speed data service;
`(2) any Internet service provider with the right to acquire the facilities and services necessary to interconnect with such carrier's high speed data service for the provision of Internet access service; and
`(3) any Internet service provider with the ability to collocate[sic] equipment in accordance with the provisions of section 251, to the extent necessary to achieve the objectives of paragraphs (1) and (2) of this subsection.
`(c) DEFINITIONS- As used in this section--
`(1) INTERNET SERVICE PROVIDER- The term `Internet service provider' means any provider of Internet access service.
`(2) INCUMBENT LOCAL EXCHANGE CARRIER- The term `incumbent local exchange carrier' has the same meaning as provided in section 251(h).'.
H. R. 1542 also says:
(b) CONFORMING AMENDMENT- Section 251 of the Communications Act of 1934 (47 U.S.C. 251) is amended by adding at the end thereof the following new subsection:
`(j) EXEMPTION-
`(1) IN GENERAL- Notwithstanding the provisions of subsections (c) and (d), the Commission shall not require an incumbent local exchange carrier to--
`(A) provide unbundled access to any network elements used in the provision of any high speed data service, other than those network elements described in section 51.319 of the Commission's regulations (47 C.F.R. 51.319), as in effect on January 1, 1999; or
`(B) offer for resale at wholesale rates any high speed data service.
It defines a "high-speed data service" thus:
SEC. 3. DEFINITIONS
(a) AMENDMENTS- Section 3 of the Communications Act of 1934 (47 U.S.C. 153) is amended--
(1) by redesignating paragraph (20) as paragraph (21);
(2) by redesignating paragraphs (21) through (52) as paragraphs (24) through (54), respectively;
(3) by inserting after paragraph (19) the following new paragraph:
`(20) HIGH SPEED DATA SERVICE- The term `high speed data service' means any service that consists of or includes the offering of a capability to transmit, using a packet-switched or successor technology, information at a rate that is generally not less than 384 kilobits per second in at least one direction.';
This all sounds as if it states that ILECs have the duty to let ISPs connect to their ATM cloud in such a way as to let them send cells to and receive cells from users connected to the central office via DSL.
I don't know whether merely stating that they have the duty to do so means that the government is empowered to force them to do so, however, nor do I know whether, even if they are empowered to do so, they'll bother doing so.
In any case, note that I Am Not A Lawyer, and don't even play one on TV, and it may require a lawyer with a Big Fat Book Of U.S. Code (or to, for example, the Web site for the Office of the Law Revision Counsel, which, it appears, will let you look up stuff in the U.S. Code), so that they can plow through the Communications Act of 1934 and all the various amendments to it, and figure out what the law would say after all the changes made to it by H. R. 1542, and with the law experience to say what the hell that would all mean.
I believe Bellsouth and GTE merged to form Verizon.
Then you believe something that isn't true, because Verizon is the result of Bell Atlantic and GTE merging (Bell Atlantic, BTW, bought Nynex several years ago). BellSouth are still independent.
However, in any case, the article wasn't presenting "facts", it was presenting the author's predictions for what the facts will be in 2004; to quote the article:
Here is what the United States telecommunications industry
may well look like in 2004[emphasis mine]:
Of the Baby Bell local phone carriers, once seven in number, three remain Qwest Communications, SBC Communications and Verizon Communications (NYSE:VZ - news) and they are by far the most powerful and important communications companies in the nation. The corporations once known as long-distance carriers, like AT&T, are shells of their former selves.
...
WorldCom, a highflier once worth more than $150 billion, now belongs to one of the Bells, making that company a major force in the business services market. Sprint was acquired by another Bell, or perhaps by a foreign carrier, but only after spinning off its wireless or local phone operations.
So he's not saying that Worldcom is now owned by a Baby Bell, he's saying that one possibility is that, by 2004, they could be owned by a Baby Bell.
Is DSL.net a CLEC or an ISP? The Baby Bells are competitors to both, but I don't know whether competitive ISPs (who don't, as far as I know, have to locate equipment in the Baby Bells' COs) are having as many problems competing as are the CLECs who use the Baby Bells' wires.
That's the reality of the telecom infrastructure folks. Wireline infrastructure involves massive expenditures that can only be absorbed by the companies that originally had heavy government funding to install the infrastructure in the first place.
Did AT&T, in the US, have government funding, or did they merely have (regulated) monopoly status and profits?
In Europe, most of the telephone systems were, I think, Government-run (typically by the post office, I think), although, at least according to one of Andrew Leonard's articles on Salon.com, Finland's government "chose to grant licenses to operate telephone companies to all applicants" so that the Tsar of all the Russias would have to take over a whole bunch of telephone companies in order to control phone service in the Autonomous Duchy of Finland.
It will be interesting to see how local loop unbundling works in Europe.
SBC is the only Baby Bell mentioned in the article that survives as such to my knowledge, though they tried to merge with AT&T a few years back, and come to think of it used to be BellSouth and SouthWestern Bell if I remember correctly.
You don't remember correctly. Southwestern Bell bought Pacific Telesis Group or whatever the hell the parent company of Pacific Bell was called, and became SBC Communications. They later bought Ameritech.
BellSouth is still, as far as I know, independent.
I assume you mean "ADSL" rather than "xDSL", as there are several technologies to which the term "xDSL" refers (HDSL, SDSL, and ADSL, for example), many of which appear to have in common only the fact that they send Digital signals over the Subscriber Line.
Could you please cite some references to support the assertion that "ADSL is an Alcatel technology", or explain what you mean by "ADSL is an Alcatel technology" if you don't mean to imply that Alcatel invented ADSL? I have seen, in several places (admittedly, the ones I found were all from companies in the USA, so perhaps they're all part of the plot to discredit Alcatel), claims that, in fact, ADSL was originally conceived by Bellcore, and, in this Texas Instruments application report (see section B.3. "History of ADSL standards"), a claim that "the DMT line-coding technique was developed around 1987 as a result of the research performed by Professor John M. Cioffi at Stanford University".
Perhaps Alcatel is the main manufacturer of ADSL equipment, and they may have contributed a lot to the development of ADSL technology, but I've yet to see any indication that they invented ADSL, or even DMT, so it does not appear to be an "Alcatel technology" in the sense that they are the originators of ADSL.
This story is only an attempt to break the image of company in USA. In fact all that thing was cleverly prepared : the "hacker" that discovered it made a public advertisement whereas, for security, usually people who found security holes are asked to contact the company first in order to avoid crackers take advantage of the information. Moreover he contacted some friends and the media even before the post on the Internet.
Indeed? Are you asserting that this is part of some plot by competitors to discredit Alcatel? If so, do you have any evidence to support that assertion? (There wasn't anything in the transfert article making any such claim.)
I got a user's manual with my ADSL 1000, which includes, err, umm, a discussion of the Web interface to it; as I remember, it even mentioned the 10.0.0.138 IP address. Maybe Sasktel weren't as nice as Pac Bell in that regard (or maybe he didn't check out the box the modem came in).
CDC built large mainframes in competition with IBM in the 60's. When they started, IBM didn't have anything near as powerful as the CDCs. So IBM announced the System 360, then tried to build it. The 360 hardware might have been on schedule, but the OS was several years late -- but still, many IBM customers waited for it instead of buying CDC. CDC filed an antitrust suit, claiming that selling vaporware was unfair competition. Long before the suit was settled, the full 360 line was out and delivering the promised power, and CDC was bankrupt.
This sounds like a mangled version of what I've heard was the story of a specific model in the System/360 line, the Model 91 (or maybe it was first called the Model 92).
In August, 1961, IBM started planning for two high-performance projects to exceed the capabilities of Stretch. The first project, called "Project X", was assigned to the IBM Poughkeepsie plant, and in 1963 the design became a member of the S/360 family. This machine was announced as the IBM System/360 Model 92 in 1964 and was delivered as the Model 91 (with core memory) in late 1967 and the Model 95 (with thin film memory) in early 1968. Project X had a goal of 10 to 30 times the performance of Stretch, with an initial cycle time goal of 50 nsec (the Model 91 shipped at a 60 nsec cycle time). The Model 91's floating-point unit is famous for executing instructions out-of-order, according to an algorithm devised by Robert Tomasulo.
This may have been a preemptive strike against the CDC 6600, which, according to this note, was announced in 1964 and shipped in 1965.
As far as I know:
IBM's announcement of the S/360 wasn't timed to get in the way of CDC, although the announcement of the S/360 model 92 (later to be the 91) may have been;
CDC wasn't bankrupted by that announcement - they eventually got out of the computer business, but that happened, as I remember, some time in the '90's.
OTOH, I had Flashcom for 2 years, and only had one unplanned outage for about 24 hrs (and that was because someone had unscrewed the outside connection). The connection was perfect, fast and very, very stable.
...and not provided by Flashcom, if you're referring to the DSL circuit; Flashcom are an ISP, not a CLEC.
I have (yes, have, present tense) DSL service with Flashcom as the ISP and Pac Bell as the circuit provider. (I first tried ordering DSL through Pac Bell Internet. They said "we'll get back to you in 5 business days" which, as I expected to be the case, they didn't. When I called them back, they gave me some crap about "you're too far from the central office" and "we don't have the facilities". I then tried Flashcom who managed to get me, within a few weeks, DSL service using Pac Bell as the provider of the DSL circuit, so Flashcom managed to do what Pacific Bell Internet hadn't managed to do - get me a circuit from, err, umm, Pacific Bell.)
Until recently, the circuit (from Pac Bell) has worked with few glitches. Recently, the circuit has been less reliable - the modem has been having problems getting sync; power-cycling helps, but sometimes it had problems even after power-cycling, but picking up my phone and hanging up appeared to have cleared them up.
My phone has also been somewhat noisy of late; I don't know if these are symptoms of the same underlying problem, but I'm loath to call Pac Bell because I'm afraid they'll "fix" it by, for example, noticing that my phone line gets hooked up to some weird device when it arrives at the central office, and disconnecting it - hey, guys, that weird device is called a DSL splitter, don't just disconnect it.
The Internet part of the service has generally worked pretty well; there was a mail problem a while ago due to the mail system bogusly thinking I was over quota, but that was a screwup by Critical Path, to whom Flashcom outsourced their mail services, and it's pretty much Just Worked since then.
Flashcom technical support, for a while, was slow about answering the phone, but recently they've been pretty good - I wonder whether somebody at the bankruptcy court came in and cracked the whip, especially because...
...the biggest Flashcom problem I've had is getting them to charge services to my credit card; they stopped charging me last July or so, and I've been calling them over and over again to get them to start charging me again (I don't want them cutting my service off because "I haven't been paying them"), and they finally manage to figure out how to change my account, which may also be the result of court-ordered cleanup.
(At least Pac Bell bills me, not Flashcom, for the DSL circuit charges, which is, I suspect, good, as it means Pac Bell, unlike the CLECs that Flashcom were using, is actually getting paid for the circuit. I suspect the CLECs, unlike the Baby Bells, had little or no infrastructure for billing individual consumers, and relied on the ISP to do that, which meant that if the ISP didn't pay their bills, they were screwed - which is, as I understand it, one problem the CLECs were having.)
So I'm reasonably happy with Pac Bell's DSL circuit, although, of late, I've been less happy, but, based both on general horror stories I've heard, and on a suspicion that the voice people may not have much of a clue about DSL, I'm somewhat loath to tell them about it.
Others may have had less luck with their DSL circuit.
The quality of their DSL circuit may have nothing to do with the quality of their Internet service; the ISP side of the house may, for example, have less of a clue than the DSL-circuit side of the house.
I bet you think that intel machines are the only ones that run Linux.
Sure, I'll bet you 5 million dollars that I don't.
Cough up, d00d. I've known about non-x86 Linux for ages.
The original article said nothing about requiring that the feed be available on non-x86 machines and, unless a "GNU/Linux" system really is a system with no non-free software (and I'll believe that only if somebody posts a reference; I don't see anything obvious on the FSF Web site about that), it didn't even say anything about requiring the feed to be viewable by free software.
(Saying that the feed had to be viewable by "GNU/Linux systems" seems a very odd way, indeed, to say "has to be viewable if you use only free software"; what about GNU/Hurd, for example? Why not just say "has to be viewable if you use only free software", as that is, I suspect, what Stallman meant?)
Depressingly like filling out forms in a web browser...
About 5-7 years ago, I read some magazine (I forget which one it was) that referred to Web stuff (or, at least, the forms-based version) as "3270 for the '90's". The host sends a form to the terminal, with fields to be filled in. The user at the terminal fills the forms in, and hits Transmit (or whatever it's called; perhaps they even called it "Submit":-)), and the contents of the fields are sent back to the host. The host then processes the transaction, and sends another screenful back to the terminal. Sounds familiar....
...meaning both number-crunching and business applications; the S/360 instruction set was, at its core, binary, but, in addition to the floating-point instructions, it also included decimal-arithmetic and character-string instructions. (The floating-point and decimal instructions were, I think, extra-cost options on the original S/360 models or, at least, on the lower-end models.)
The next version was OS/370
...because it ran on System/370. I suspect they might've bumped the system number because I think the first S/370's came out in, err, umm, the 1970's; they did make some instruction-set architecture changes, although the big change was the addition of an MMU (which was also in the System 360/67, but that wasn't a "mainstream" S/360). The very first S/370's didn't have the MMU, but later ones had it, and there were add-ons for those other models.
then came OS/380
Not as far as I know. The "S/380" machines - which, I think, came out in the '80's - were, I think, given names like "3081" and "4300", i.e. they were sold with just model numbers, rather than as "System/380's", and the OS was probably just being called "MVS" at the time. (I think MVS may originally have been called "OS/370 VS2 with Multiple Virtual Spaces", to distinguish it from the version of VS2 with a Single Virtual Space -
I think SVS just ran all processes in the same virtual address space, using the protection keys to keep them from stomping on each other, and using base-register relocation to allow programs to be run from wherever they happened to be loaded, just as was done on the non-virtual-memory OS/360, whereas MVS gave each process its own virtual address space.)
and finally OS/390
No prizes for guessing in what decade that came out. It ran on System/390's.
Unfortunately, that numbering scheme has, err, umm, a bit of a Y2K problem - would this decade's machines be "System/3100"s, or "System/3A0's", or "System/400"s (which would run the risk of confusion with AS/400's), or what?
So I guess they decided, now that they've introduced a 64-bit version of the architecture (not bad for an instruction set architecture whose design started in the early '60's, assuming it didn't start at the end of the '50's...), to come up with an Exciting New Name; I don't know whether that inspired this whole new "[a-z]Series" naming scheme, or not.
Stallman has stipulated that his interview must be able to be seen by GNU/Linux systems (i.e. just RealVideo is a no-no).
Yeah, I don't have RealPlayer installed on the Linux partition on my home machine, I have to boot another OS on it to run RealPlayer...
...oh, wait, that other OS is FreeBSD, and it's running RealPlayer in Linux emulation.
(I'm not at home right now, so I don't remember which version of RP it is, but I think it was an RP 8 beta - which doesn't seem to have expired.)
Go to Real's home page, click on "RealPlayer" on the bar at the top listing "Download"s, click on "RealPlayer 8 Basic" from that page, and proceed from there. Various Linux versions are available.
except vmware needs linux kernel modules to run. Those can't be run inside the BSD kernel, so vmware won't run at all.
Yes, it will; this FreeBSDzine article discusses it. (Hint: just because it requires help from the kernel, that doesn't mean FreeBSD's kernel can't provide that help, even if the kernel modules in question had to be written by somebody other than the people at VMware.)
The PowerPC has a 64-bit mode, added for the AS/400, that supports the 64-bit single address space
The 64-bit PowerPC architecture antedated the RISC AS/400's, as far as I know - as I remember, I saw a PowerPC architecture manual describing 64-bit mode before the RISC AS/400's came out (it was some time in 1994, I think, when I saw it).
The PowerPC 620 was supposed to be the first 64-bit PowerPC; I don't know whether any machines shipped with it. IBM now have 64-bit PowerPC's in both the AS/400 and RS/6000 machines (I think some of the RS/6000's use the same chip as some of the AS/400's, with the tag bits and other AS/400 extensions disabled in the RS/6000's).
Well, a 64-bit integer solves the Y2037 bug inherent in Unix.
...and a 64-bit integer can be manipulated on a 32-bit machine - and even fairly conveniently, if the compiler cooperates, and GCC does cooperate here (think long long int).
Is my memory going? Don't know about the Honywell 6180, but I thought I remembered that the GE 635 and GE 645 were 48-bit machines instead of 36-bit as one of the articles says.
General Electric's competitor to the IBM 7094 in the 1965 time frame. Like the 7094, the GE-635 had a 36-bit word, 18-bit addresses, and programmable data channels with direct memory access.
The computer system that Multics first ran on, produced by General Electric. Derived from the GE-635, a 36-bit word machine with accumulator, quotient register, and 8 index registers like the 7094. Basic execution speed was about 435 KIPS.
The 6180 was also 36-bit (its instruction and register set was largely a superset of the 645's, although I seem to remember the base register set was a little different - instead of pairing two base registers, so that you had 8 base registers but only 4 base pairs, you had 8 double-width base registers; programs that used the base pairs worked on either, but I think programs that tried to use the base registers independently rather than as part of a pair might not have worked).
If by "Gould" you're referring to the Gould 32-bit superminicomputers, then
your comment was not necessarily off-topic, the moderation it got to that effect nonwithstanding;
I don't remember, offhand, when they ditched those machines. I think Gould had bought SEL (Systems Engineering Laboratories, or something such as that), makers of that line of superminis, but the 1960's-to-1990's page in Gould's history stuff on their Web site doesn't mention it - it just mentions that, in the mid-1980's, "The overhaul and restructuring of Gould had proven to be financially disappointing. Many of the newer businesses the company acquired had failed to generate the earnings levels of some of Gould's more steady industrial businesses, which had been divested. As the financial condition of the company deteriorated, various business units were sold to generate cash.", and I suspect the computer business was sold or shut down then.
Re:no wonder flashcom is bankrupt...
on
DSL Woes
·
· Score: 2
I had Flashcom.com for a little less than a year, never was I sent a bill nor did I recieve a call. They went bust (aquired by Earthlink)
Reference? I've seen no indication that Earthlink have bought Flashcom.
Maybe one is faster than the other in some things, but so what?
And, besides, often "X is faster than Y" is better phrased as "release N of X is faster than release M of Y" - release M+1 of Y may well catch up to, or beat, release N of X (and then release N+1 of X may surpass release M+1 of Y, and then release M+1 of Y may surpass release N+1 of X, and so on, and so forth).
Slashdot Mirror
Uh, actually, SunOS 5.x has a STREAMS-based Internet protocol stack from Mentat, not BSD, as far as I know. Earlier SunOSes had the BSD stack.
As for Windows, do you have any evidence to support your assertion that it uses the BSD stack?
An overview that includes "XFree86-style" software in the "free software" category:
This says that, err, umm, according to the overview of categories of software, somebody can take Free Software, modify it, distribute it, and keep the changes secret. (Anybody who believes otherwise either has not read, or does not understand, the "overview of categories of software" page in question.)
ISPs typically don't, as far as I know, "access DSL lines", if by that you mean "provide 'DSLtone' on DSL lines"; that's done by the ILEC or a CLEC. (Covad and Rhythms are CLECs, and Northpoint was a CLEC).
A DSL customer can access an ISP over their DSL ; if that's what you mean, then, for what it's worth, H. R. 1542 says, according to the contents as shown on the US Library of Congress THOMAS service, says:
H. R. 1542 also says:
It defines a "high-speed data service" thus:
This all sounds as if it states that ILECs have the duty to let ISPs connect to their ATM cloud in such a way as to let them send cells to and receive cells from users connected to the central office via DSL.
I don't know whether merely stating that they have the duty to do so means that the government is empowered to force them to do so, however, nor do I know whether, even if they are empowered to do so, they'll bother doing so.
In any case, note that I Am Not A Lawyer, and don't even play one on TV, and it may require a lawyer with a Big Fat Book Of U.S. Code (or to, for example, the Web site for the Office of the Law Revision Counsel, which, it appears, will let you look up stuff in the U.S. Code), so that they can plow through the Communications Act of 1934 and all the various amendments to it, and figure out what the law would say after all the changes made to it by H. R. 1542, and with the law experience to say what the hell that would all mean.
Then you believe something that isn't true, because Verizon is the result of Bell Atlantic and GTE merging (Bell Atlantic, BTW, bought Nynex several years ago). BellSouth are still independent.
However, in any case, the article wasn't presenting "facts", it was presenting the author's predictions for what the facts will be in 2004; to quote the article:
So he's not saying that Worldcom is now owned by a Baby Bell, he's saying that one possibility is that, by 2004, they could be owned by a Baby Bell.
Is DSL.net a CLEC or an ISP? The Baby Bells are competitors to both, but I don't know whether competitive ISPs (who don't, as far as I know, have to locate equipment in the Baby Bells' COs) are having as many problems competing as are the CLECs who use the Baby Bells' wires.
Did AT&T, in the US, have government funding, or did they merely have (regulated) monopoly status and profits?
What about Bell Canada (which, according to this item on Bell Canada's timeline, was a private company since Day One)?
In Europe, most of the telephone systems were, I think, Government-run (typically by the post office, I think), although, at least according to one of Andrew Leonard's articles on Salon.com, Finland's government "chose to grant licenses to operate telephone companies to all applicants" so that the Tsar of all the Russias would have to take over a whole bunch of telephone companies in order to control phone service in the Autonomous Duchy of Finland.
It will be interesting to see how local loop unbundling works in Europe.
You don't remember correctly. Southwestern Bell bought Pacific Telesis Group or whatever the hell the parent company of Pacific Bell was called, and became SBC Communications. They later bought Ameritech.
BellSouth is still, as far as I know, independent.
I assume you mean "ADSL" rather than "xDSL", as there are several technologies to which the term "xDSL" refers (HDSL, SDSL, and ADSL, for example), many of which appear to have in common only the fact that they send Digital signals over the Subscriber Line.
Could you please cite some references to support the assertion that "ADSL is an Alcatel technology", or explain what you mean by "ADSL is an Alcatel technology" if you don't mean to imply that Alcatel invented ADSL? I have seen, in several places (admittedly, the ones I found were all from companies in the USA, so perhaps they're all part of the plot to discredit Alcatel), claims that, in fact, ADSL was originally conceived by Bellcore, and, in this Texas Instruments application report (see section B.3. "History of ADSL standards"), a claim that "the DMT line-coding technique was developed around 1987 as a result of the research performed by Professor John M. Cioffi at Stanford University".
Perhaps Alcatel is the main manufacturer of ADSL equipment, and they may have contributed a lot to the development of ADSL technology, but I've yet to see any indication that they invented ADSL, or even DMT, so it does not appear to be an "Alcatel technology" in the sense that they are the originators of ADSL.
Indeed? Are you asserting that this is part of some plot by competitors to discredit Alcatel? If so, do you have any evidence to support that assertion? (There wasn't anything in the transfert article making any such claim.)
...which I rather suspect they do using some non-IP protocol running, for example, atop ATM.
I got a user's manual with my ADSL 1000, which includes, err, umm, a discussion of the Web interface to it; as I remember, it even mentioned the 10.0.0.138 IP address. Maybe Sasktel weren't as nice as Pac Bell in that regard (or maybe he didn't check out the box the modem came in).
The manual didn't discuss the Telnet UI, though.
This sounds like a mangled version of what I've heard was the story of a specific model in the System/360 line, the Model 91 (or maybe it was first called the Model 92).
The Model 91 (or 92) was announced as a number-crunching supercomputer model, perhaps before it was actually read; this note on another IBM supercomputer project says
This may have been a preemptive strike against the CDC 6600, which, according to this note, was announced in 1964 and shipped in 1965.
As far as I know:
...and not provided by Flashcom, if you're referring to the DSL circuit; Flashcom are an ISP, not a CLEC.
I have (yes, have, present tense) DSL service with Flashcom as the ISP and Pac Bell as the circuit provider. (I first tried ordering DSL through Pac Bell Internet. They said "we'll get back to you in 5 business days" which, as I expected to be the case, they didn't. When I called them back, they gave me some crap about "you're too far from the central office" and "we don't have the facilities". I then tried Flashcom who managed to get me, within a few weeks, DSL service using Pac Bell as the provider of the DSL circuit, so Flashcom managed to do what Pacific Bell Internet hadn't managed to do - get me a circuit from, err, umm, Pacific Bell.)
Until recently, the circuit (from Pac Bell) has worked with few glitches. Recently, the circuit has been less reliable - the modem has been having problems getting sync; power-cycling helps, but sometimes it had problems even after power-cycling, but picking up my phone and hanging up appeared to have cleared them up.
My phone has also been somewhat noisy of late; I don't know if these are symptoms of the same underlying problem, but I'm loath to call Pac Bell because I'm afraid they'll "fix" it by, for example, noticing that my phone line gets hooked up to some weird device when it arrives at the central office, and disconnecting it - hey, guys, that weird device is called a DSL splitter, don't just disconnect it.
The Internet part of the service has generally worked pretty well; there was a mail problem a while ago due to the mail system bogusly thinking I was over quota, but that was a screwup by Critical Path, to whom Flashcom outsourced their mail services, and it's pretty much Just Worked since then.
Flashcom technical support, for a while, was slow about answering the phone, but recently they've been pretty good - I wonder whether somebody at the bankruptcy court came in and cracked the whip, especially because...
...the biggest Flashcom problem I've had is getting them to charge services to my credit card; they stopped charging me last July or so, and I've been calling them over and over again to get them to start charging me again (I don't want them cutting my service off because "I haven't been paying them"), and they finally manage to figure out how to change my account, which may also be the result of court-ordered cleanup.
(At least Pac Bell bills me, not Flashcom, for the DSL circuit charges, which is, I suspect, good, as it means Pac Bell, unlike the CLECs that Flashcom were using, is actually getting paid for the circuit. I suspect the CLECs, unlike the Baby Bells, had little or no infrastructure for billing individual consumers, and relied on the ISP to do that, which meant that if the ISP didn't pay their bills, they were screwed - which is, as I understand it, one problem the CLECs were having.)
So I'm reasonably happy with Pac Bell's DSL circuit, although, of late, I've been less happy, but, based both on general horror stories I've heard, and on a suspicion that the voice people may not have much of a clue about DSL, I'm somewhat loath to tell them about it.
Others may have had less luck with their DSL circuit.
The quality of their DSL circuit may have nothing to do with the quality of their Internet service; the ISP side of the house may, for example, have less of a clue than the DSL-circuit side of the house.
As I remember, that was paid for by the folks doing it, not by Sun.
Sure, I'll bet you 5 million dollars that I don't.
Cough up, d00d. I've known about non-x86 Linux for ages.
The original article said nothing about requiring that the feed be available on non-x86 machines and, unless a "GNU/Linux" system really is a system with no non-free software (and I'll believe that only if somebody posts a reference; I don't see anything obvious on the FSF Web site about that), it didn't even say anything about requiring the feed to be viewable by free software.
(Saying that the feed had to be viewable by "GNU/Linux systems" seems a very odd way, indeed, to say "has to be viewable if you use only free software"; what about GNU/Hurd, for example? Why not just say "has to be viewable if you use only free software", as that is, I suspect, what Stallman meant?)
About 5-7 years ago, I read some magazine (I forget which one it was) that referred to Web stuff (or, at least, the forms-based version) as "3270 for the '90's". The host sends a form to the terminal, with fields to be filled in. The user at the terminal fills the forms in, and hits Transmit (or whatever it's called; perhaps they even called it "Submit" :-)), and the contents of the fields are sent back to the host. The host then processes the transaction, and sends another screenful back to the terminal. Sounds familiar....
...meaning both number-crunching and business applications; the S/360 instruction set was, at its core, binary, but, in addition to the floating-point instructions, it also included decimal-arithmetic and character-string instructions. (The floating-point and decimal instructions were, I think, extra-cost options on the original S/360 models or, at least, on the lower-end models.)
...because it ran on System/370. I suspect they might've bumped the system number because I think the first S/370's came out in, err, umm, the 1970's; they did make some instruction-set architecture changes, although the big change was the addition of an MMU (which was also in the System 360/67, but that wasn't a "mainstream" S/360). The very first S/370's didn't have the MMU, but later ones had it, and there were add-ons for those other models.
Not as far as I know. The "S/380" machines - which, I think, came out in the '80's - were, I think, given names like "3081" and "4300", i.e. they were sold with just model numbers, rather than as "System/380's", and the OS was probably just being called "MVS" at the time. (I think MVS may originally have been called "OS/370 VS2 with Multiple Virtual Spaces", to distinguish it from the version of VS2 with a Single Virtual Space - I think SVS just ran all processes in the same virtual address space, using the protection keys to keep them from stomping on each other, and using base-register relocation to allow programs to be run from wherever they happened to be loaded, just as was done on the non-virtual-memory OS/360, whereas MVS gave each process its own virtual address space.)
No prizes for guessing in what decade that came out. It ran on System/390's.
Unfortunately, that numbering scheme has, err, umm, a bit of a Y2K problem - would this decade's machines be "System/3100"s, or "System/3A0's", or "System/400"s (which would run the risk of confusion with AS/400's), or what?
So I guess they decided, now that they've introduced a 64-bit version of the architecture (not bad for an instruction set architecture whose design started in the early '60's, assuming it didn't start at the end of the '50's...), to come up with an Exciting New Name; I don't know whether that inspired this whole new "[a-z]Series" naming scheme, or not.
Yeah, I don't have RealPlayer installed on the Linux partition on my home machine, I have to boot another OS on it to run RealPlayer...
...oh, wait, that other OS is FreeBSD, and it's running RealPlayer in Linux emulation.
(I'm not at home right now, so I don't remember which version of RP it is, but I think it was an RP 8 beta - which doesn't seem to have expired.)
Go to Real's home page, click on "RealPlayer" on the bar at the top listing "Download"s, click on "RealPlayer 8 Basic" from that page, and proceed from there. Various Linux versions are available.
Yes, it will; this FreeBSDzine article discusses it. (Hint: just because it requires help from the kernel, that doesn't mean FreeBSD's kernel can't provide that help, even if the kernel modules in question had to be written by somebody other than the people at VMware.)
No, that's not good enough - Wine runs native on FreeBSD.
You want to run Linux VMware on the FreeBSD running on VirtualPC, and then run NT on VMware.
Then you can run Hercules on NT (yes, it runs on Linux as well, so you could run Linux on VMware instead)...
...and boot the S/390 version of Linux on that.
No, wait, you do want to run Linux on VMware. Then you'd run the NT version of Hercules under Wine....
The 64-bit PowerPC architecture antedated the RISC AS/400's, as far as I know - as I remember, I saw a PowerPC architecture manual describing 64-bit mode before the RISC AS/400's came out (it was some time in 1994, I think, when I saw it).
The PowerPC 620 was supposed to be the first 64-bit PowerPC; I don't know whether any machines shipped with it. IBM now have 64-bit PowerPC's in both the AS/400 and RS/6000 machines (I think some of the RS/6000's use the same chip as some of the AS/400's, with the tag bits and other AS/400 extensions disabled in the RS/6000's).
...and a 64-bit integer can be manipulated on a 32-bit machine - and even fairly conveniently, if the compiler cooperates, and GCC does cooperate here (think long long int).
Your memory may be going; the item on the multicians.org site about the GE 635 says:
and the item on the 645 says:
The 6180 was also 36-bit (its instruction and register set was largely a superset of the 645's, although I seem to remember the base register set was a little different - instead of pairing two base registers, so that you had 8 base registers but only 4 base pairs, you had 8 double-width base registers; programs that used the base pairs worked on either, but I think programs that tried to use the base registers independently rather than as part of a pair might not have worked).
If by "Gould" you're referring to the Gould 32-bit superminicomputers, then
Reference? I've seen no indication that Earthlink have bought Flashcom.
And, besides, often "X is faster than Y" is better phrased as "release N of X is faster than release M of Y" - release M+1 of Y may well catch up to, or beat, release N of X (and then release N+1 of X may surpass release M+1 of Y, and then release M+1 of Y may surpass release N+1 of X, and so on, and so forth).