No, I recall regular commercial offerings of self-contained PCs in keyboards, diskless, for network boot, in the second half of the 1980s. Nothing to do with Atari or game stuff.
I have a server-grade Dell Precision 690 with two monitors. I had been using XP Pro for years and didn't have any really serious complaints with it until I tried to run multiple Eve Online instances. It became obvious that I needed to move up to a 64-bit OS, and for Eve, it would have to be Windows. I didn't consider Vista due to all the bad press it was getting. I bought WinXP Pro 64-bit.
I knew the Dell Precision would require some Dell drivers. The SATA disk driver was needed at the beginning of the install (F6?) and the NIC and audio drivers were needed for everything to work. The NVIDIA 64-bit driver was needed for the 8800 GT 512 MB vid card.
One install, no glitches, and everything worked. Even better, 64-bit XP is cleaner and better behaved than the 32-bit, and lets me use the 8 GB I have on the Dell. I can now run all nine Eve accounts on the 4-core, 3.0 GHz Dell. Joy, joy.
Oddly, every single app I have installed that I was accustomed to using on the old XP works, whether 32-bit or not. Except one, and the irony is that the one is my company's product with a crappy installer.
This system is extremely stable, has BSoD'd just once since installing 64-bit XP Pro, and I only reboot it to reduce the application footprints of all the crap that clogs memory, and only do that when I want to run those nine Eve instances. The system just works, and all my apps work.
I should point out that I have never liked MS and have never liked, have even hated, Windows, but it's certainly true that I have installed XP 32 many times without any difficulty and have only had to install XP 64 once because it went perfectly and there has been no need to reinstall it.
Meanwhile, over on the job side, we make a software product that runs only in Linux. We never even considered making our product work with Windows. After trying Mandrake we finally settled on SUSE, and eventually SLES to satisfy customers who wanted to run enterprise backup products.
Working with SUSE and SLES has been a total horror. Fortunately our app uses Linux as an appliance and no other apps are allowed to run on our customers' boxes. Any update of Linux is likely to break something, and our app is mission critical, often running entire enterprises. Nothing can be allowed to break it. Novell displays total lack of comprehension of what they claim is their enterprise Linux distribution. Even in service packs they change stuff we are using, breaking it. From major version to major version they are likely to change components in ways that not only would break our customers' systems but would require us to do major work to accommodate what they have changed.
This is SO bad that we have to consider rolling our own Linux distribution just to get away from Novell breaking stuff with each and every new version. Not to mention that even SLES is bloated with tons of stuff we don't want or need.
In principle I favor open source and Linux. As a practical matter I have been appalled at how much of open source software is broken, how bad the documentation is (if and where it even exists) and how little the folks distributing the stuff understand about "mission critical." Aside from tons of little stuff that doesn't work, perhaps the worst thing about Linux is the dependency hell that arises almost anytime we have tried to install something that didn't come packaged in the distribution. An example is trying to get WINE working in SLES. WINE is packaged in SUSE, but not in SLES. Eventually we gave up. We've run into that a number of times with various packages.
I was a happy user of IBM's AIX on RS/6000 from late 1999 onward. As AIX versions progressed and eventually stopped supporting the affordable 43P machines I used, I developed a severe dislike of IBM and proprietary OS software. I will never use AIX again, nor recommend it. But while AIX supported my favored RS/6000 models I never ran into any of the difficulties I've seen in Linux or Linux apps. I've installed AIX on bunches of 43P mac
I work in the Wang VS world, a type of system originally patterned after the IBM 360/370 but with an OS designed from the ground up to be interactive. We have multiple file types at the OS file system level... consecutive, indexed, object, print, relative, etc. Indexed files not only store data retrievable by a key, but by up to 17 keys. Unlike some juvenile "database" products that stored data in a.DAT file and indices in separate files, our indexed files contain a mini-db structure inside, with chains of data blocks, index blocks and free blocks, all managed by the file system. It's impossible for the various parts to get out of sync because they are all integrated within the indexed file.
We also have file compression at the OS file system level. Most file types except object can be tagged to be compressed and some are compressed by default. The OS file system uses machine instructions to compress before writing and expand after reading. It's completely transparent to the app code.
We also have PACE, a native 4GL / RDBMS that was developed by Wang in the mid-1980s and had referential integrity rules in the data dictionary and distributed database with two-phase commit, all from the beginning.
I used Oracle 5.1 from 1989 through 1992 and was shocked to learn that Oracle had no referential integrity at the time. What Oracle did was fake it by generating SQL*Forms triggers in their CASE tool. Heaven help anyone trying to build apps without the CASE tool or anyone touching any of the generated triggers.
I also recall reading of the struggles of the mainstream db vendors with distributed database technology and the eventual development and adoption of two-phase commit, many years after Wang had it as a standard feature in their clustered environments.
In 2004 I co-founded a company to virtualize the aging Wang VS. We have been very successful and are now the official source for all Wang VS systems and software. Our virtual Wang VS ranges up to 220% of the performance of the legacy high-end VS18950 released in 1999 and runs in Linux mostly on Dell PowerEdges. The high end supports 500-1000 users, not quite in the IBM mainframe arena but far, far easier to program, operate and use.
The original Wang VS80, released in 1977, supported up to 32 users and scores of devices in no more than 512KB of memory. Right... KiloBytes. Half a MegaByte. Later models grew to be much more capacious but try to imagine supporting 32 connected users running real apps and manipulating real data in half a MB of memory.
All of this reminds me of the horrible disconnect that occurred with the introduction of microcomputers. The folks who worked in the microcomputer field either didn't know about or ignored all the existing OS technologies and reinvented everything. PC users had to wait 10-15 years before MS discovered "pre-emptive multitasking," which was the rule in large systems, even in minicomputers, from the 1960s forward.
Microcomputers, while very enabling of individuals, actually took us backward in OS technology and caused us to have to live through a 10-15 year hiatus while the microcomputer engineers and OS developers rediscovered things that had been standard stuff in the mini and mainframe worlds.
BSG was a total bust and the end was unbelievably bad. For the effort invested in it, BSG might even be the most epic fail in the history of TV.
BSG wasn't sci-fi... it was a soap opera against a little-used space background. Anytime I tuned in it was just like a daytime soap.
I think they got way too full of themselves and lost all perspective. I saw a documentary about the show and couldn't believe the extent to which they patted themselves on their backs while an objective look at the production revealed it to be a mess of a dreary soap opera -- all talk and little action.
And any series that has to resort to promos like "All will be revealed" or "All will be explained" has clearly overcomplicated itself to the point where it can't be understood.
Yeah, but I haven't bought from them and my website still has a Belkin with the international negation symbol over it and a link to an explanation of their faux pas.
I think the real point is that "players" invest both time and money in the virtual characters and property they have in MMOGs. That alone gives them an interest in those characters and property, and will eventually bulldoze all obstacles to them exercising all normal rights in property. It matters not at all whether real bank accounts are legal claims or whether real banking substitutes bits and bytes for paper currency and coin. If someone spends hundreds of dollars and hundreds of hours building skills in a character and/or earning in-game money and buying in-game property, that someone has an interest in those things that will sooner or later have to be recognized and dealt with as with other types of property.
Shampage or whatever it was was a "door" for BBSs that pretended to be the sysop, for times when the sysop wasn't available for chat or didn't want to be bothered. It was light years better than ELIZA. A sysop friend send me a few transcripts, which were hilarious. Users generally could not tell they were talking to a bot.
I started writing one called Dr. Door, for the Remote Access BBS. I got it as far as holding basic ELIZA-type conversation, including picking up references in the user's convo and turning around parts of speech to form leading questions, whereas ELIZA did little more than say things like "Tell me more about that." I had intended to go on to build a knowledge database with veracity weighting, starting to get into real AI, but never did. Since then life has kept me busy with other things. My embryonic Dr. Door fooled a bunch of people, but the transcripts were not quite as hilarious as those of Shampage.
One guy in a Shampage transcript was asking for some kind of help with software, or getting some software, and in the course of a very long conversation admitted he wasn't entitled to the help he was looking for and at the end apologized profusely for having bothered the sysop. Great stuff. Couldn't make it up as good. I might even still have the stuff on an older computer if I ever get it fired up again. Even though Shampage obviously randomized its responses whenever it couldn't identify a specific to use to tailor the response, it was uncanny how often its randomized responses were right on the mark, perfect for what the user had said or asked.
I tried the winner mentioned in TFA. It's awful. I've written better stuff than that myself. In fact, 15+ years ago, Shamchat for BBSs was far better than the winner.
No, I must have missed that. Damn. It goes a long way to explaining all the DRM stuff, though. Piracy of BSoD could be a serious problem in Redmond's view, considering how integral fatal errors are to the whole Windows experience.
It was actually surprisingly easy. Was it my first choice? No. Well, that's not quite accurate. COBOL was my first choice for one reason: other than Assembler, COBOL is the most efficient language for the type of mainframe that the Wang VS is. Most COBOL statements compile to one or two machine instructions on that type of machine. I ultimately wrote the full-blown Web server in another language but only because the Wang VS TCP/IP API was giving me some grief and I was more comfortable dealing with that in another language. Ultimately the TCP/IP stack was the weak link, an awful port of someone else's stack that had been done by outsiders unfamiliar with the VS and its OS environment. TCP/IP was limited to a total of 256 connections and active connections couldn't be handed off to other processes. Still, it found use and was successfully employed by some VS sites. Wang released it as open source because they didn't want to support it... probably the only thing Wang ever released as open source in their entire history.
I subscribe to audible.com, a source of downloadable audio books. I get two books per month for my $22. Occasionally I buy additional books during the month. Books are typically 80-120 MB in audible.com's format. Due to my small player I select a format that breaks the books into 2 or 3 separate files, each individually downloaded. I don't download any other significant data from any sources.
So... after Comcast took over the Houston market from Time Warner and got settled in, I noticed that my audiobook downloads were crawling... at slug speed, with predicted completions of hours or even days. Whenever this happened I switched over to my DSL feed and the same books downloaded briskly at over 600 MBytes/sec.
I don't know what protocol these downloads use, but there is no inherent P2P as these are paid downloads. There is no upload traffic whatsoever.
So I have to conclude that Compaq's assertions of somewhat complex analysis of traffic resulting in throttling of P2P traffic are bullshit. Whatever they are doing, at least in my area, is so moronic and simple-minded that it affects my simple downloads of paid audiobooks amounting to a total of a few hundred MB per month.
...though if you want games online, you'll still have to have dialup
It's an outmoded concept that games consume a lot of bandwidth. Some stupidly written ones still may, but modern games make the client do all the heavy lifting, with cached object images and very terse traffic between server and client. I sometimes have nine Eve-Online windows open and my network traffic averages less than a few KB/sec, far less than a single VoIP phone connection.
My threats are not hollow. I actively punish vendors who offend me. I reduce or eliminate the money I pay to them. Fortunately I have four ways to connect to the Internet without satellite latency. I have had both static IP cable and DSL for years, and have been able to compare them. Since Comcast took over in the Houston area, any downloads I attempt via Comcast suck, with predicted completion times of hours or even days. My DSL zips along at a steady rate of close to 620 KBytes/sec. I'm about to give Comcast the heave-ho now that Uverse is available on my block.
I would NEVER have subscribed to VoIP from a cable company. I have been using Vonage since early in their history and long before any of the cable companies offered VoIP. Not only is Comcast's VoIP much more expensive than Vonage, you can't take the VoIP box with you. I've taken Vonage boxes to hotels and I know people who have taken them to other countries. Your number rings where your Vonage box is, and your calls are charged (or not charged) according to where your account is.
A friend took his Vonage box to South America, where his U.S. telephone number rings and from where he can call the U.S., Canada and several countries in Europe at no charge and can call the rest of the world at very low charges.
I'll be signing up with Uverse to replace Comcast while keeping my 6 Mbit/sec DSL, which performs vastly better than Comcast does.
The only thing that will cure Comcast's stupidity and arrogance is going out of business.
Comcast doesn't even provide me with the minimum service they are supposed to provide. If I download ONE audiobook in a month, it slows to a crawl, obviously throttled, while the same book downloaded through my DSL feed runs at close to 620 KB/sec and finishes in a very few minutes while on the cable feed the predicted completion is hours or days.
...If the phone companies were smart they would drive a stake through Comcast's heart and jump on this as an ad campaign. Of course big companies are generally NOT smart at all...
The only thing more stupid than a telco is a cable company. It's in their genes. The cable Internet technology made available to them is fantastic but they are so stupid that they would rather offer 200 pay per view channels and 30 home shopping channels than dedicate even 2 channels to cable Internet. Unless they have wised up very recently, all cable Internet is delivered over only one TV channel, while the equipment they use makes it very easy to use multiple channels to, say, segregate residential from business class customers. But no. They're just congenitally stupid.
The reality for me is this: the only significant downloads I do are from a paid audiobook site a few times a month, maybe a couple hundred MB each time. Since Comcast took over this area from Time Warner and got settled in, I can no longer download even those few audiobooks. Although my Comcast feed seems to work OK for regular surfing, the books crawl, with predicted completion times of hours or even days. I switch to my 6 Mbps DSL and the books download at a steady 600+ KBytes/sec. Those Comcast TV ads about how much faster they are than DSL are a sick joke in this household.
This is particularly distressing because I pay close to $140/mo for static IP cable Internet from Comcast. My static IP DSL, always much faster than Comcast, is significantly less expensive.
So... soon I will switch the near-zero-traffic servers I have over to my static IP DSL and tell Comcast to shove their service up their collective asses. I will replace them with Uverse, as I really do need the reliability of more than one feed.
Never heard of a Burroughs 78. All I can tell you is that the mainframe model separates code space and modifiable (data) space, and programs cannot modify themselves such as by storing a return address at the beginning of a procedure section or paragraph. The real reason, though, that COBOL has not generally beeen recursive is that it was never specified to be recursive. In the Wang COBOL manuals, derived directly from the rigorous COBOL standards, there is a warning that COBOL is not recursive and that there will be unpredictable results from recursion.
Wang BASIC, otoh, is fully recursive. In one manufacturing system in which I worked on maintaining and enhancing the internals, multilevel Bills of Material (BOMs) involved recursing to process nested BOMs, very elegant indeed.
Hey! I worked on the Burroughs B300 in 1967! It had three memory options: 4,800 characters (BCD, not ASCII), 9,600 or 19,200 characters. That was it. And it did tons of useful work. Try that today.
My mainframe is the Wang VS, now reborn as a virtual machine running in Linux on modern x86, x64 servers (and the article I submitted on the changeover from legacy to Linux-based virtual Wang VS rejected by Slashdot's pinhead editors). The Wang VS was based on the IBM 360, the prototypical "mainframe," and updated when the IBM 370 came out. COBOL is almost an assembler for this kind of machine. Most simple COBOL statements translate to one or two machine instructions. In the Wang VS, moving a numeric value into a formatted variable (leading zeroes, optional dollar sign, commas, decimal point, etc.) is a single machine instruction. Bulk moves of data are single instructions. Add, subtract, multiply and divide of decimal fields are single instructions.
Ever tried doing recursion in early Cobol? Maybe they've fixed this in later versions, but in the past the return pointer was stored in program space at the head of the function.
You must come from the crappy-COBOL-on-PCs world. In Wang mainframes code space is "pure," meaning that nothing can be written into code space except by the OS when loading a program into memory. Wang mainframes are also stack-based. But COBOL was not specified to be recursive.
Slashdot Mirror
No, I recall regular commercial offerings of self-contained PCs in keyboards, diskless, for network boot, in the second half of the 1980s. Nothing to do with Atari or game stuff.
At least 25 years if you are talking about a diskless PC built into a keyboard and booting from a network.
I have a server-grade Dell Precision 690 with two monitors. I had been using XP Pro for years and didn't have any really serious complaints with it until I tried to run multiple Eve Online instances. It became obvious that I needed to move up to a 64-bit OS, and for Eve, it would have to be Windows. I didn't consider Vista due to all the bad press it was getting. I bought WinXP Pro 64-bit.
I knew the Dell Precision would require some Dell drivers. The SATA disk driver was needed at the beginning of the install (F6?) and the NIC and audio drivers were needed for everything to work. The NVIDIA 64-bit driver was needed for the 8800 GT 512 MB vid card.
One install, no glitches, and everything worked. Even better, 64-bit XP is cleaner and better behaved than the 32-bit, and lets me use the 8 GB I have on the Dell. I can now run all nine Eve accounts on the 4-core, 3.0 GHz Dell. Joy, joy.
Oddly, every single app I have installed that I was accustomed to using on the old XP works, whether 32-bit or not. Except one, and the irony is that the one is my company's product with a crappy installer.
This system is extremely stable, has BSoD'd just once since installing 64-bit XP Pro, and I only reboot it to reduce the application footprints of all the crap that clogs memory, and only do that when I want to run those nine Eve instances. The system just works, and all my apps work.
I should point out that I have never liked MS and have never liked, have even hated, Windows, but it's certainly true that I have installed XP 32 many times without any difficulty and have only had to install XP 64 once because it went perfectly and there has been no need to reinstall it.
Meanwhile, over on the job side, we make a software product that runs only in Linux. We never even considered making our product work with Windows. After trying Mandrake we finally settled on SUSE, and eventually SLES to satisfy customers who wanted to run enterprise backup products.
Working with SUSE and SLES has been a total horror. Fortunately our app uses Linux as an appliance and no other apps are allowed to run on our customers' boxes. Any update of Linux is likely to break something, and our app is mission critical, often running entire enterprises. Nothing can be allowed to break it. Novell displays total lack of comprehension of what they claim is their enterprise Linux distribution. Even in service packs they change stuff we are using, breaking it. From major version to major version they are likely to change components in ways that not only would break our customers' systems but would require us to do major work to accommodate what they have changed.
This is SO bad that we have to consider rolling our own Linux distribution just to get away from Novell breaking stuff with each and every new version. Not to mention that even SLES is bloated with tons of stuff we don't want or need.
In principle I favor open source and Linux. As a practical matter I have been appalled at how much of open source software is broken, how bad the documentation is (if and where it even exists) and how little the folks distributing the stuff understand about "mission critical." Aside from tons of little stuff that doesn't work, perhaps the worst thing about Linux is the dependency hell that arises almost anytime we have tried to install something that didn't come packaged in the distribution. An example is trying to get WINE working in SLES. WINE is packaged in SUSE, but not in SLES. Eventually we gave up. We've run into that a number of times with various packages.
I was a happy user of IBM's AIX on RS/6000 from late 1999 onward. As AIX versions progressed and eventually stopped supporting the affordable 43P machines I used, I developed a severe dislike of IBM and proprietary OS software. I will never use AIX again, nor recommend it. But while AIX supported my favored RS/6000 models I never ran into any of the difficulties I've seen in Linux or Linux apps. I've installed AIX on bunches of 43P mac
I work in the Wang VS world, a type of system originally patterned after the IBM 360/370 but with an OS designed from the ground up to be interactive. We have multiple file types at the OS file system level... consecutive, indexed, object, print, relative, etc. Indexed files not only store data retrievable by a key, but by up to 17 keys. Unlike some juvenile "database" products that stored data in a .DAT file and indices in separate files, our indexed files contain a mini-db structure inside, with chains of data blocks, index blocks and free blocks, all managed by the file system. It's impossible for the various parts to get out of sync because they are all integrated within the indexed file.
We also have file compression at the OS file system level. Most file types except object can be tagged to be compressed and some are compressed by default. The OS file system uses machine instructions to compress before writing and expand after reading. It's completely transparent to the app code.
We also have PACE, a native 4GL / RDBMS that was developed by Wang in the mid-1980s and had referential integrity rules in the data dictionary and distributed database with two-phase commit, all from the beginning.
I used Oracle 5.1 from 1989 through 1992 and was shocked to learn that Oracle had no referential integrity at the time. What Oracle did was fake it by generating SQL*Forms triggers in their CASE tool. Heaven help anyone trying to build apps without the CASE tool or anyone touching any of the generated triggers.
I also recall reading of the struggles of the mainstream db vendors with distributed database technology and the eventual development and adoption of two-phase commit, many years after Wang had it as a standard feature in their clustered environments.
In 2004 I co-founded a company to virtualize the aging Wang VS. We have been very successful and are now the official source for all Wang VS systems and software. Our virtual Wang VS ranges up to 220% of the performance of the legacy high-end VS18950 released in 1999 and runs in Linux mostly on Dell PowerEdges. The high end supports 500-1000 users, not quite in the IBM mainframe arena but far, far easier to program, operate and use.
The original Wang VS80, released in 1977, supported up to 32 users and scores of devices in no more than 512KB of memory. Right... KiloBytes. Half a MegaByte. Later models grew to be much more capacious but try to imagine supporting 32 connected users running real apps and manipulating real data in half a MB of memory.
All of this reminds me of the horrible disconnect that occurred with the introduction of microcomputers. The folks who worked in the microcomputer field either didn't know about or ignored all the existing OS technologies and reinvented everything. PC users had to wait 10-15 years before MS discovered "pre-emptive multitasking," which was the rule in large systems, even in minicomputers, from the 1960s forward.
Microcomputers, while very enabling of individuals, actually took us backward in OS technology and caused us to have to live through a 10-15 year hiatus while the microcomputer engineers and OS developers rediscovered things that had been standard stuff in the mini and mainframe worlds.
BSG was a total bust and the end was unbelievably bad. For the effort invested in it, BSG might even be the most epic fail in the history of TV.
BSG wasn't sci-fi... it was a soap opera against a little-used space background. Anytime I tuned in it was just like a daytime soap.
I think they got way too full of themselves and lost all perspective. I saw a documentary about the show and couldn't believe the extent to which they patted themselves on their backs while an objective look at the production revealed it to be a mess of a dreary soap opera -- all talk and little action.
And any series that has to resort to promos like "All will be revealed" or "All will be explained" has clearly overcomplicated itself to the point where it can't be understood.
My XP Pro 64-bit is still running and the file is still there, with no infection hits reported in recent days.
Yeah, but I haven't bought from them and my website still has a Belkin with the international negation symbol over it and a link to an explanation of their faux pas.
I think the real point is that "players" invest both time and money in the virtual characters and property they have in MMOGs. That alone gives them an interest in those characters and property, and will eventually bulldoze all obstacles to them exercising all normal rights in property. It matters not at all whether real bank accounts are legal claims or whether real banking substitutes bits and bytes for paper currency and coin. If someone spends hundreds of dollars and hundreds of hours building skills in a character and/or earning in-game money and buying in-game property, that someone has an interest in those things that will sooner or later have to be recognized and dealt with as with other types of property.
Shampage or whatever it was was a "door" for BBSs that pretended to be the sysop, for times when the sysop wasn't available for chat or didn't want to be bothered. It was light years better than ELIZA. A sysop friend send me a few transcripts, which were hilarious. Users generally could not tell they were talking to a bot.
I started writing one called Dr. Door, for the Remote Access BBS. I got it as far as holding basic ELIZA-type conversation, including picking up references in the user's convo and turning around parts of speech to form leading questions, whereas ELIZA did little more than say things like "Tell me more about that." I had intended to go on to build a knowledge database with veracity weighting, starting to get into real AI, but never did. Since then life has kept me busy with other things. My embryonic Dr. Door fooled a bunch of people, but the transcripts were not quite as hilarious as those of Shampage.
One guy in a Shampage transcript was asking for some kind of help with software, or getting some software, and in the course of a very long conversation admitted he wasn't entitled to the help he was looking for and at the end apologized profusely for having bothered the sysop. Great stuff. Couldn't make it up as good. I might even still have the stuff on an older computer if I ever get it fired up again. Even though Shampage obviously randomized its responses whenever it couldn't identify a specific to use to tailor the response, it was uncanny how often its randomized responses were right on the mark, perfect for what the user had said or asked.
I tried the winner mentioned in TFA. It's awful. I've written better stuff than that myself. In fact, 15+ years ago, Shamchat for BBSs was far better than the winner.
No, I must have missed that. Damn. It goes a long way to explaining all the DRM stuff, though. Piracy of BSoD could be a serious problem in Redmond's view, considering how integral fatal errors are to the whole Windows experience.
No, BSoD is a free, bundled feature of Windows.
It was actually surprisingly easy. Was it my first choice? No. Well, that's not quite accurate. COBOL was my first choice for one reason: other than Assembler, COBOL is the most efficient language for the type of mainframe that the Wang VS is. Most COBOL statements compile to one or two machine instructions on that type of machine. I ultimately wrote the full-blown Web server in another language but only because the Wang VS TCP/IP API was giving me some grief and I was more comfortable dealing with that in another language. Ultimately the TCP/IP stack was the weak link, an awful port of someone else's stack that had been done by outsiders unfamiliar with the VS and its OS environment. TCP/IP was limited to a total of 256 connections and active connections couldn't be handed off to other processes. Still, it found use and was successfully employed by some VS sites. Wang released it as open source because they didn't want to support it... probably the only thing Wang ever released as open source in their entire history.
I subscribe to audible.com, a source of downloadable audio books. I get two books per month for my $22. Occasionally I buy additional books during the month. Books are typically 80-120 MB in audible.com's format. Due to my small player I select a format that breaks the books into 2 or 3 separate files, each individually downloaded. I don't download any other significant data from any sources.
So... after Comcast took over the Houston market from Time Warner and got settled in, I noticed that my audiobook downloads were crawling... at slug speed, with predicted completions of hours or even days. Whenever this happened I switched over to my DSL feed and the same books downloaded briskly at over 600 MBytes/sec.
I don't know what protocol these downloads use, but there is no inherent P2P as these are paid downloads. There is no upload traffic whatsoever.
So I have to conclude that Compaq's assertions of somewhat complex analysis of traffic resulting in throttling of P2P traffic are bullshit. Whatever they are doing, at least in my area, is so moronic and simple-minded that it affects my simple downloads of paid audiobooks amounting to a total of a few hundred MB per month.
FCC complaint filed. Go thou and do likewise.
Ah, you were implicitly referring to latency. My mistake.
It's an outmoded concept that games consume a lot of bandwidth. Some stupidly written ones still may, but modern games make the client do all the heavy lifting, with cached object images and very terse traffic between server and client. I sometimes have nine Eve-Online windows open and my network traffic averages less than a few KB/sec, far less than a single VoIP phone connection.
My threats are not hollow. I actively punish vendors who offend me. I reduce or eliminate the money I pay to them. Fortunately I have four ways to connect to the Internet without satellite latency. I have had both static IP cable and DSL for years, and have been able to compare them. Since Comcast took over in the Houston area, any downloads I attempt via Comcast suck, with predicted completion times of hours or even days. My DSL zips along at a steady rate of close to 620 KBytes/sec. I'm about to give Comcast the heave-ho now that Uverse is available on my block.
I would NEVER have subscribed to VoIP from a cable company. I have been using Vonage since early in their history and long before any of the cable companies offered VoIP. Not only is Comcast's VoIP much more expensive than Vonage, you can't take the VoIP box with you. I've taken Vonage boxes to hotels and I know people who have taken them to other countries. Your number rings where your Vonage box is, and your calls are charged (or not charged) according to where your account is.
A friend took his Vonage box to South America, where his U.S. telephone number rings and from where he can call the U.S., Canada and several countries in Europe at no charge and can call the rest of the world at very low charges.
I'll be signing up with Uverse to replace Comcast while keeping my 6 Mbit/sec DSL, which performs vastly better than Comcast does.
The only thing that will cure Comcast's stupidity and arrogance is going out of business.
Comcast doesn't even provide me with the minimum service they are supposed to provide. If I download ONE audiobook in a month, it slows to a crawl, obviously throttled, while the same book downloaded through my DSL feed runs at close to 620 KB/sec and finishes in a very few minutes while on the cable feed the predicted completion is hours or days.
The only thing more stupid than a telco is a cable company. It's in their genes. The cable Internet technology made available to them is fantastic but they are so stupid that they would rather offer 200 pay per view channels and 30 home shopping channels than dedicate even 2 channels to cable Internet. Unless they have wised up very recently, all cable Internet is delivered over only one TV channel, while the equipment they use makes it very easy to use multiple channels to, say, segregate residential from business class customers. But no. They're just congenitally stupid.
The reality for me is this: the only significant downloads I do are from a paid audiobook site a few times a month, maybe a couple hundred MB each time. Since Comcast took over this area from Time Warner and got settled in, I can no longer download even those few audiobooks. Although my Comcast feed seems to work OK for regular surfing, the books crawl, with predicted completion times of hours or even days. I switch to my 6 Mbps DSL and the books download at a steady 600+ KBytes/sec. Those Comcast TV ads about how much faster they are than DSL are a sick joke in this household.
This is particularly distressing because I pay close to $140/mo for static IP cable Internet from Comcast. My static IP DSL, always much faster than Comcast, is significantly less expensive.
So... soon I will switch the near-zero-traffic servers I have over to my static IP DSL and tell Comcast to shove their service up their collective asses. I will replace them with Uverse, as I really do need the reliability of more than one feed.
Never heard of a Burroughs 78. All I can tell you is that the mainframe model separates code space and modifiable (data) space, and programs cannot modify themselves such as by storing a return address at the beginning of a procedure section or paragraph. The real reason, though, that COBOL has not generally beeen recursive is that it was never specified to be recursive. In the Wang COBOL manuals, derived directly from the rigorous COBOL standards, there is a warning that COBOL is not recursive and that there will be unpredictable results from recursion.
Wang BASIC, otoh, is fully recursive. In one manufacturing system in which I worked on maintaining and enhancing the internals, multilevel Bills of Material (BOMs) involved recursing to process nested BOMs, very elegant indeed.
Hey! I worked on the Burroughs B300 in 1967! It had three memory options: 4,800 characters (BCD, not ASCII), 9,600 or 19,200 characters. That was it. And it did tons of useful work. Try that today.
My mainframe is the Wang VS, now reborn as a virtual machine running in Linux on modern x86, x64 servers (and the article I submitted on the changeover from legacy to Linux-based virtual Wang VS rejected by Slashdot's pinhead editors). The Wang VS was based on the IBM 360, the prototypical "mainframe," and updated when the IBM 370 came out. COBOL is almost an assembler for this kind of machine. Most simple COBOL statements translate to one or two machine instructions. In the Wang VS, moving a numeric value into a formatted variable (leading zeroes, optional dollar sign, commas, decimal point, etc.) is a single machine instruction. Bulk moves of data are single instructions. Add, subtract, multiply and divide of decimal fields are single instructions.
Ever tried doing recursion in early Cobol? Maybe they've fixed this in later versions, but in the past the return pointer was stored in program space at the head of the function.
You must come from the crappy-COBOL-on-PCs world. In Wang mainframes code space is "pure," meaning that nothing can be written into code space except by the OS when loading a program into memory. Wang mainframes are also stack-based. But COBOL was not specified to be recursive.