"The real selling point for these systems is data transfer and reliability."
Well, I think you missed the #1 and #2 selling points there: backward compatibility and bureaucratic inertia.;)
While the reliability is certainly excellent, I wonder about the data transfer rates. Have you seen (or performed) any benchmarks that support this claim?
I'm a Unix sysadmin in a shop with several S/390's and the only experience I have with them is network data transfer. Between the Sun 6000 and Sun 10000 I can get 66 Mbps using ftp across our 100bps network. From an S/390 I only get 21 Mbps.
Of course, you're talking about aggregate disk transfer rates, not network speeds. Do you know of any resource where test results are actually available?
Of course! I knew there had to be a good reason for it. Thanks for reminding us that every reason doesn't have to be a business reason. I'll go off and slap myself on the forehead now...;)
What is the value of a Linux port to the S/390? The price/performance ratio would be awful -- even before taking into account the hardware maintenance costs of an S/390.
I can see maybe a small scalability value in that the latest S/390's have quite fast processors, which, along with their small number (10? 12? on Hitachi?) of CPU's and Linux's limitations with large CPU counts might combine to be as fast an SMP Linux port as is available -- but surely not much faster than a Compaq 8400 (or whatever they call their high-end SMP Alpha box these days).
Well, not quite tradewars, but completely rewritten for the Internet. Check out starshiptraders.com either using a web browser, or, for you original BBSer's, telnet straight in to port 23.
The SST design is derived from Czarwars, one of several tradewars-genre BBS door programs from the '80s. SST has been online in various forms for three years and is still in beta testing. It's pretty solid but remains in testing due to endless feature creep.;)
We are currently running 10 games in an on-going ladder-style tournament. The games all reset on Thanksgiving (Thursday) and each has room for a few hundred more players. There are usually about 500 active players (well, active ships -- it's hard to tell how many actual people log in). The web mode serves about a half million pages a week and accounts for 75% of the traffic -- with the remainder of the activity being through telnet.
Operating Systems are those programs that provide, and control, access to a computer's resources.
Editors, file managers, and browsers are nice to have, but are not part of the OS proper. An operating system doesn't imply any particular type of usage -- such as interactive human control. An OS that controls an embedded system, for example, is no less an OS than the OS that controls the interactive sessions on a graphical workstation. An application program is just as valid a user to the OS whether or not it has a human behind it.
The proper definition of OS is the one that matches all instances of an OS -- without extensions and exceptions. The proper definition also draws a consistent line between applications and the OS. Otherwise we can dispense with the redundant terms.;)
I would suggest that what marketing calls an "operating system" today is more properly called a "distribution" of applications and an operating system. Further, if the strict definition of "controlling and providing access to resources" is used, some so-called operating systems don't actually qualify for the term. I don't consider that a problem. After all, we must have some standards.;)
Are these just characteristics of rapid change?
on
NetSlaves
·
· Score: 2
Is there anything unique to the computer industry that creates this situation or is it simply the fast pace and large size of the market? I tend to think that any other industry, booming on the same scale and schedule of our computer industries would show similar characteristics.
So true. Around 1990 I bought a copy of Esix Unix SVR3.2 for about $600. The big appeal of Esix was it included X and a C compiler and cost about half most other PC Unices. I wound up spending another $300 on the manuals. For less than a grand I had Unix, C, X, and a full set of manuals! I was in heaven.
I ran that Unix until 1995 when I picked up a copy of Slackware (with book, CD, and 1.2.8 kernel for $40) in a local bookstore. About 6 months later I retired Esix for good.
Now, shipping from Cheapbytes costs more than a CD of any of several much more modern distributions. Yep, we got it good alright.;)
I got the Intel copy of Solaris for about $20 last year under a developers program.
I'm not too sure how valuable these cheap SCO, Tru64 and Solaris OS's are with Linux and the *BSD's out there but, as a Sun admin, I had a particular interest. However, I run my own projects under Linux.
While I would love to see the practice of cybersquatting stopped, I think this blunt instrument is the wrong solution.
How about attacking cybersquatting where it lives; in the resale? If the law didn't ban anything except selling a "similar" name to a trademark holder, it would introduce far fewer hazards. While this might solve the cybersquatting problem, I don't expect it would get support from the big trademark holders.;)
Of course, this doesn't address the concern of someone registering a trademarked name and simply getting extra hits from people trying to reach the trademark holder.
Also, by allowing MSNBC to scoop the other networks, MS can control the spin that goes onto an original story -- while diminishing the appeal of the story to other networks as "old news". In addition to helping MSNBC, it also can help MS itself.;)
Note 1: *If* current trends continue. The trouble is, they tend not to. This article and the dramatic reversal it represents as more trends are considered in the projections, proves that point. Alas, there are more, smaller trends that will come to the fore by 2040. Will they have a significant impact? Which direction will they tilt the next projection? Stay tuned for updates as they happen...
It sounds to me like it will not allow GPL'd strong crypto to be exported at all and still comply with both the GPL and this export restriction.
This is great for Microsoft. This is terrible for Red Hat. While it doesn't actually add any new restrictions to RH, it allows MS to compete more effectively with RH Linux. Maybe it will also be a boon for offshore distributions such as SuSE and TurboLinux.
Hmmm... is this a first?
on
The Cat Cam
·
· Score: 2
Have we ever slashdotted a cat before?
I'm getting nothing. Never send a kitty to do a grown cat's job!;)
Imagine for a moment that a catastrophe destroyed *all* the memory production capacity except that from a single company. By your logic, that one company's prices shouldn't be affected by the disaster. Of course, that cannot be.
If the quake affected Micron's competition it affected Micron's market. If it affected Micron's market, it stands to affect Micron's prices.
The reality of markets is, of course, far more complicated than your argument (and mine) would have it be. Even a credible prediction of a quake in Taiwan would affect prices in the markets in which Taiwan is a major player.
Since each of the strings "PEZ", "Pez", "pez", etc will come up about once in 16.7MB of random 8-bit data, we have all probably violated it in "some way, shape, or form." Compressed data is pretty random but not so predictable as encrypted data where the once-per-16.7MB rule would hold pretty true.
At least I don't put encrypted or compressed data in my meta tags or they'd probably have sued me by now.;)
"...avoiding...[a man-in-the-middle attack]...is, in my opinion, an implementation detail"
Perhaps, but I would feel so much more comfortable with something that can be automated like contemporary public key protocols, which only require real authentication once and provide for public channel verification thereafter.
That "implementation detail" would seem to be a bit more difficult in a world where current public key cryptography is no longer effective, as in the case where we resort to using quantum cryptography.
No, I don't think the quoted piece of the article covers authenticating Bob (or Alice). It deals with the quantum improbability of both intercepting and accurately duplicating the key. If Bob and Alice have a reliable communications channel they can detect Eve intercepting the key with a reliability proportional to the key length. But the protocol seems to be incomplete here -- they do not describe the channel that guarantees that Alice is talking to Bob or that they can detect an imposter. How does Alice authenticate Bob and vice versa? Why is this protocol not vulnerable to a man-in-the-middle attack?
Yes, I understand that Eve can't both intercept the key and derive the values of each bit. That prevents Eve from simply intercepting and retransmitting the key undetected.
My question was how does Alice know she is talking to Bob and not Eve if Eve intercepts the key and pretends to be Bob to Alice and pretends to be Alice to Bob? The article assumes that Alice and Bob have a reliable method to communicate and can know they are talking to each other (the phone call). What is that method? It would seem to be a critical piece of the whole protocol. The article doesn't cover a cryptographically secure method of authentication -- and it wouldn't be fair to use current methods, since the justification for quantum cryptography is presented as current methods being crackable.;)
Something the article didn't cover or I missed completely. How does Alice know she is talkin to Bob and not Eve's agent when verifying a valid key was transmitted? In other words, can't Eve simply intercept the entire transmission and emulate Bob to verify the key? While the cryptography logic seemed solid to me, I fail to understand why the phone system is so casually used as an integral part of this system. Note that if something other than the phone call is used to verify the key, the problem remains: how to authenticate Bob in the verification step?
True, but the airline industry went through this and continues to face it every day. Their safety record is pretty amazing, I think, even compared to almost any government funded project.
Slashdot Mirror
"The real selling point for these systems is data transfer and reliability."
;)
Well, I think you missed the #1 and #2 selling points there: backward compatibility and bureaucratic inertia.
While the reliability is certainly excellent, I wonder about the data transfer rates. Have you seen (or performed) any benchmarks that support this claim?
I'm a Unix sysadmin in a shop with several S/390's and the only experience I have with them is network data transfer. Between the Sun 6000 and Sun 10000 I can get 66 Mbps using ftp across our 100bps network. From an S/390 I only get 21 Mbps.
Of course, you're talking about aggregate disk transfer rates, not network speeds. Do you know of any resource where test results are actually available?
Of course! I knew there had to be a good reason for it. Thanks for reminding us that every reason doesn't have to be a business reason. I'll go off and slap myself on the forehead now... ;)
What is the value of a Linux port to the S/390? The price/performance ratio would be awful -- even before taking into account the hardware maintenance costs of an S/390.
I can see maybe a small scalability value in that the latest S/390's have quite fast processors, which, along with their small number (10? 12? on Hitachi?) of CPU's and Linux's limitations with large CPU counts might combine to be as fast an SMP Linux port as is available -- but surely not much faster than a Compaq 8400 (or whatever they call their high-end SMP Alpha box these days).
Does this make solid business sense to anyone?
Well, not quite tradewars, but completely rewritten for the Internet. Check out starshiptraders.com either using a web browser, or, for you original BBSer's, telnet straight in to port 23.
;)
The SST design is derived from Czarwars, one of several tradewars-genre BBS door programs from the '80s. SST has been online in various forms for three years and is still in beta testing. It's pretty solid but remains in testing due to endless feature creep.
We are currently running 10 games in an on-going ladder-style tournament. The games all reset on Thanksgiving (Thursday) and each has room for a few hundred more players. There are usually about 500 active players (well, active ships -- it's hard to tell how many actual people log in). The web mode serves about a half million pages a week and accounts for 75% of the traffic -- with the remainder of the activity being through telnet.
Operating Systems are those programs that provide, and control, access to a computer's resources.
;)
;)
Editors, file managers, and browsers are nice to have, but are not part of the OS proper. An operating system doesn't imply any particular type of usage -- such as interactive human control. An OS that controls an embedded system, for example, is no less an OS than the OS that controls the interactive sessions on a graphical workstation. An application program is just as valid a user to the OS whether or not it has a human behind it.
The proper definition of OS is the one that matches all instances of an OS -- without extensions and exceptions. The proper definition also draws a consistent line between applications and the OS. Otherwise we can dispense with the redundant terms.
I would suggest that what marketing calls an "operating system" today is more properly called a "distribution" of applications and an operating system. Further, if the strict definition of "controlling and providing access to resources" is used, some so-called operating systems don't actually qualify for the term. I don't consider that a problem. After all, we must have some standards.
Is there anything unique to the computer industry that creates this situation or is it simply the fast pace and large size of the market? I tend to think that any other industry, booming on the same scale and schedule of our computer industries would show similar characteristics.
For how cheap can they be had?
So true. Around 1990 I bought a copy of Esix Unix SVR3.2 for about $600. The big appeal of Esix was it included X and a C compiler and cost about half most other PC Unices. I wound up spending another $300 on the manuals. For less than a grand I had Unix, C, X, and a full set of manuals! I was in heaven.
;)
I ran that Unix until 1995 when I picked up a copy of Slackware (with book, CD, and 1.2.8 kernel for $40) in a local bookstore. About 6 months later I retired Esix for good.
Now, shipping from Cheapbytes costs more than a CD of any of several much more modern distributions. Yep, we got it good alright.
I got the Intel copy of Solaris for about $20 last year under a developers program.
I'm not too sure how valuable these cheap SCO, Tru64 and Solaris OS's are with Linux and the *BSD's out there but, as a Sun admin, I had a particular interest. However, I run my own projects under Linux.
Agreed.
;)
While I would love to see the practice of cybersquatting stopped, I think this blunt instrument is the wrong solution.
How about attacking cybersquatting where it lives; in the resale? If the law didn't ban anything except selling a "similar" name to a trademark holder, it would introduce far fewer hazards. While this might solve the cybersquatting problem, I don't expect it would get support from the big trademark holders.
Of course, this doesn't address the concern of someone registering a trademarked name and simply getting extra hits from people trying to reach the trademark holder.
Also, by allowing MSNBC to scoop the other networks, MS can control the spin that goes onto an original story -- while diminishing the appeal of the story to other networks as "old news". In addition to helping MSNBC, it also can help MS itself. ;)
It is accessible as of this time. It is very slow, however. The almost totally text page took about 3 minutes to download through my fast connection.
;)
Be patient, be early, and you too might see the page.
I wonder how resistent those babies would be to a HERF gun... In my noisy environment, maybe I could use one too... ;)
Agreed.
Predicting the future is easy. [see note 1]
Note 1: *If* current trends continue. The trouble is, they tend not to. This article and the dramatic reversal it represents as more trends are considered in the projections, proves that point. Alas, there are more, smaller trends that will come to the fore by 2040. Will they have a significant impact? Which direction will they tilt the next projection? Stay tuned for updates as they happen...
Do you worry about, or plan for, being sued over losses resulting from an instability in NT?
It sounds to me like it will not allow GPL'd strong crypto to be exported at all and still comply with both the GPL and this export restriction.
This is great for Microsoft. This is terrible for Red Hat. While it doesn't actually add any new restrictions to RH, it allows MS to compete more effectively with RH Linux. Maybe it will also be a boon for offshore distributions such as SuSE and TurboLinux.
Have we ever slashdotted a cat before?
;)
I'm getting nothing. Never send a kitty to do a grown cat's job!
Imagine for a moment that a catastrophe destroyed *all* the memory production capacity except that from a single company. By your logic, that one company's prices shouldn't be affected by the disaster. Of course, that cannot be.
If the quake affected Micron's competition it affected Micron's market. If it affected Micron's market, it stands to affect Micron's prices.
The reality of markets is, of course, far more complicated than your argument (and mine) would have it be. Even a credible prediction of a quake in Taiwan would affect prices in the markets in which Taiwan is a major player.
Since each of the strings "PEZ", "Pez", "pez", etc will come up about once in 16.7MB of random 8-bit data, we have all probably violated it in "some way, shape, or form." Compressed data is pretty random but not so predictable as encrypted data where the once-per-16.7MB rule would hold pretty true.
;)
At least I don't put encrypted or compressed data in my meta tags or they'd probably have sued me by now.
"...avoiding...[a man-in-the-middle attack]...is, in my opinion, an implementation detail"
Perhaps, but I would feel so much more comfortable with something that can be automated like contemporary public key protocols, which only require real authentication once and provide for public channel verification thereafter.
That "implementation detail" would seem to be a bit more difficult in a world where current public key cryptography is no longer effective, as in the case where we resort to using quantum cryptography.
"Your question is answered in the article:"
;)
No, I don't think the quoted piece of the article covers authenticating Bob (or Alice). It deals with the quantum improbability of both intercepting and accurately duplicating the key. If Bob and Alice have a reliable communications channel they can detect Eve intercepting the key with a reliability proportional to the key length. But the protocol seems to be incomplete here -- they do not describe the channel that guarantees that Alice is talking to Bob or that they can detect an imposter. How does Alice authenticate Bob and vice versa? Why is this protocol not vulnerable to a man-in-the-middle attack?
Yes, I understand that Eve can't both intercept the key and derive the values of each bit. That prevents Eve from simply intercepting and retransmitting the key undetected.
My question was how does Alice know she is talking to Bob and not Eve if Eve intercepts the key and pretends to be Bob to Alice and pretends to be Alice to Bob? The article assumes that Alice and Bob have a reliable method to communicate and can know they are talking to each other (the phone call). What is that method? It would seem to be a critical piece of the whole protocol. The article doesn't cover a cryptographically secure method of authentication -- and it wouldn't be fair to use current methods, since the justification for quantum cryptography is presented as current methods being crackable.
Something the article didn't cover or I missed completely. How does Alice know she is talkin to Bob and not Eve's agent when verifying a valid key was transmitted? In other words, can't Eve simply intercept the entire transmission and emulate Bob to verify the key? While the cryptography logic seemed solid to me, I fail to understand why the phone system is so casually used as an integral part of this system. Note that if something other than the phone call is used to verify the key, the problem remains: how to authenticate Bob in the verification step?
Same code, same options on the RH Intel box, results: 5.47 seconds CPU, less than half as fast as the EV6 500 at 2.2 (using Compaq's compiler).
Code link is on page listed in above comment.
"...gcc on alpha is not terribly efficient."
;)
Yes, you're right on this one. I compiled with the Compaq compiler with -O and got much better results: 2.2 seconds CPU time.
Looks like the lowly Celeron is soundly beaten, after all.
BTW, the code is posted on my web page, listed in a comment above.
"Businesses do stuff cheap..."
True, but the airline industry went through this and continues to face it every day. Their safety record is pretty amazing, I think, even compared to almost any government funded project.