"knows enough about the web to download another browser if he/she wants to"
"is willingly using a more "primitive" product."
OK:
Have you ever thought about blind people who have to stick to lynx sice that is currently the only solution they can use?
There are still other platforms around. I remember how I hatet netscape for inventing frames before any Atari browser could view them, because I could not afford a new computer those days.
I still think that one only should use newest technology on web pages if one thinks about people who can't view it. Most new features at least allow to get around such problems
"Yes the problems begin when I don't want them to cache anything. Both IE and netscape are buggy there."
The question was if dynamically generated content needs to be slow. There is no reason to assume that. I know, that there are problems with really dynamically generated content.
Everyone can change his browser to use strong encryption. At least everyone using a platform that is supported by netscape, but on the Atari e.g there is also a solution.
Everyone can get and use a strong and legal copy of PGP or GnuPG, etc. That people don't do it doesn't relate to the US export restrictions.
So they can not prevent anyone from using strong encryption (who thinks he needs it).
As for Cell Phones: In GSM networks - which are almost any in Europe - an Encryption is used that is considered to be at least secure for this special purpous.
There have been published attacks that can clone the SIM card, but you need the card for about one day - people will know when they don't have it for such a long time. Also this attack only applies to a recomendation in the standard that has been used by only one Network in Germany (there is a new one and I don't knot if they use it).
Another attack is possible against the encryption itsself, but it is an adaptive chosen plaintext attack. You don't get that into the phone.
We get back to the point that everybody who thinks he needs it can use strong encryption and not care about US export restrictions.
>""what about older browsers?" I have to say, if a browser is so old it can't display frames, then it sure isn't going to handle a complex graphical navigation table either."
Lynx is not old...
On the Page I am currently building I have a graphical table based Navigation scheme with Javascript support. So there is amlost every buzz word exept frames in it. Still it works with Lynx.
The IMG tag allowes to set ALT for alternative text to be displayed if the image can not be displayed.
A carefull design allowes to make the navigation to be at least aceptable without tables (Lynx doesn't support tables as well).
By replacing empty Images with the real ones via ONLOAD in the BODY tag makes Javascript parts only visible when Javascript is enabled and not disturbing people with Javascript off, or another Browser.
It is all possible without frames. Of course it needs work, etc. but it results in Pages that are definately better viewed on many Browsers.
>""Use ssi,cgi,asp,php,lmnop,or xyz!" just because every slashdot reader (except me) can write perl, doesn't mean other people should have to. and compared to serving a plain frames page, server-side parsing is sloooooooooooooow."
So you're a "web developer" guy... Learn Perl and PHP at least before you call yourself one. BTW server-side parsing is not neccessarily slow. You can still make shure that people can cache the parsed Pages, You yourself can "cache" them by generating static Pages and delivering those via your CGI Script and only update them when the static Page is older than all the Pages nedded to create it.
>""search engines don't work" - so put tags in your index.html. And let's face it, unless you've been around for years, ir the customer knows how to use a search engine properly, and/or is looking for you in particular, chances are they aren't going to find you anyway. I love searching for "java programming" or something similar and getting "nasty teen amateur cheerleaders" or whatever"
There are many ways to improve that. Use Meta Tags, update your site as often as you can (forces the Spider to index it again), etc.
>""If you need a speed increase you suck anyway: I'm a web developer for a living, and I'm still stuck on a 33.6 connection. We don't all live in the US where access is cheap and fast."
My experience is that reusing images by using "../image.gif" like hrefs would speed up very many Pages much more than those frames.
Don't gert me wrong. If there was a significant improvement by using frames I may consider it (I hae a Page using Layers for a Game e.g.). But since I usually whant as many people as possible to view the Pages I create I also test them with "only for real Programmers" Browsers like Lynx. I never really got a frames empowered site working with Lynx without loosing any improovement I get from frames.
IIRC the german magazine c't did a Test (with existing systems, so no new RAMBUS etc. For the Intel and no 200MHz Frontside bus etc. for the Athlon. The result was that Coppermine running at 733MHz is still slightly slower than the Athlon at 700MHz.
Do you really think people from outside US can't make Crypto software that compares well to the one made by Network Assosiates?
Where does GnuPG come from? Where are OpenSSL and FreeSWAN developed. Not to speek of the russian, chineese and indish Math gurus.
I think the main mistake the American Government is making is that they assume they can prevent anyone from using strong encryption. Actually they cant.
Well, not all of them... Also you can make them strong by increasing Key Length.
"The "big idea" of public key algorithms is not that they're more secure but rather that they allow secure communications between parties without shared secrets."
That doesnt say that there is an authentication in it. You definately need some shared secrets for that (I know about zero knowledge etc. but actually they rely at some state on a possibility to prove the own identity to someone else, and you need shared secrets for that - the shared secret for the pizzy guy is the order).
Basically stream cyphers dont work byte-by-byte, but a bit-by-bit. Still one creates 8 bits simultaiously in most implementations for efficiency reasons.
There are public Key Systems based on Eliptic curves and hypereliptic curves wich use a rather short key lenth as well.
One could imagine a public Key stream cypher, but what for? Still public key systems are really slow (including eliptic curves and hypereliptic curves), and hybrid systems deliver the same functionality with methods considered secure.
So I think you are right in saying public key systems do not fit the need. Your analysis of the problem reducing it to key length is definately wrong.
Perl isnt that bad in my view. The point is, that any of the Languages you named (C and Java) actually have the same problem.
When I started C programming I did exactly what those "Perl or Dummies" guys do in C. I wrote Spagetti Code without reasonable coments just to get it running somehow. After a while I had to rewrite all my code and I learned hard what a good coding style is.
Now I also do Perl programming, and acctually I can use it much like an interpreted C with some nice additional features. I know, that there are other ways to do that, but why use them? If I get code by someone who did Pascal or sh programming before I can figure out what he ment, if he did it propperly. Can you figure out uncommented newby spagetti code in C?
What Im trying to say is that most languages share that problem with Perl. Still Perl is a nice and easy way of writing code for typical CGI scripts as long as someone with experience is writing the code. If the code is written by an unexperienced newby any result in any language may be awful.
The real problem you are facing is that there are too many newbys around writing CGI scripts. They start by having seen Frontpage once in a shop and begin to write websites with it. Then they grow into a job and have to do something dynamically because the Big Boss whants to have a chat on the Homepage.
I suggest to welcome those guys as hopefully good programmers in future. We should take them by their hands ant leed them to good code.
"...It would also mean that Perl would benefit from the portability of Java."
Jou don't get that from himplementing Perl in Java. You get that by implementing Perl to compile not to their own intermediate code, but to Java Byte code and then run the result through a Java VM.
So I guess that the implementation of Perl should never been thought of been done in Java.
Slashdot Mirror
- "knows enough about the web to download another browser if he/she wants to"
- "is willingly using a more "primitive" product."
OK:I still think that one only should use newest technology on web pages if one thinks about people who can't view it. Most new features at least allow to get around such problems
"Yes the problems begin when I don't want them to cache anything. Both IE and netscape are buggy there."
The question was if dynamically generated content needs to be slow. There is no reason to assume that. I know, that there are problems with really dynamically generated content.
absolutely unordered:
They really can't.
Everyone can change his browser to use strong encryption. At least everyone using a platform that is supported by netscape, but on the Atari e.g there is also a solution.
Everyone can get and use a strong and legal copy of PGP or GnuPG, etc. That people don't do it doesn't relate to the US export restrictions.
So they can not prevent anyone from using strong encryption (who thinks he needs it).
As for Cell Phones: In GSM networks - which are almost any in Europe - an Encryption is used that is considered to be at least secure for this special purpous.
There have been published attacks that can clone the SIM card, but you need the card for about one day - people will know when they don't have it for such a long time. Also this attack only applies to a recomendation in the standard that has been used by only one Network in Germany (there is a new one and I don't knot if they use it).
Another attack is possible against the encryption itsself, but it is an adaptive chosen plaintext attack. You don't get that into the phone.
We get back to the point that everybody who thinks he needs it can use strong encryption and not care about US export restrictions.
>""what about older browsers?" I have to say, if a browser is so old it can't display frames, then it sure isn't going to handle a complex graphical navigation table either."
... Learn Perl and PHP at least before you call yourself one. BTW server-side parsing is not neccessarily slow. You can still make shure that people can cache the parsed Pages, You yourself can "cache" them by generating static Pages and delivering those via your CGI Script and only update them when the static Page is older than all the Pages nedded to create it.
Lynx is not old...
On the Page I am currently building I have a graphical table based Navigation scheme with Javascript support. So there is amlost every buzz word exept frames in it. Still it works with Lynx.
The IMG tag allowes to set ALT for alternative text to be displayed if the image can not be displayed.
A carefull design allowes to make the navigation to be at least aceptable without tables (Lynx doesn't support tables as well).
By replacing empty Images with the real ones via ONLOAD in the BODY tag makes Javascript parts only visible when Javascript is enabled and not disturbing people with Javascript off, or another Browser.
It is all possible without frames. Of course it needs work, etc. but it results in Pages that are definately better viewed on many Browsers.
>""Use ssi,cgi,asp,php,lmnop,or xyz!" just because every slashdot reader (except me) can write perl, doesn't mean other people should have to. and compared to serving a plain frames page, server-side parsing is sloooooooooooooow."
So you're a "web developer" guy
>""search engines don't work" - so put tags in your index.html. And let's face it, unless you've been around for years, ir the customer knows how to use a search engine properly, and/or is looking for you in particular, chances are they aren't going to find you anyway. I love searching for "java programming" or something similar and getting "nasty teen amateur cheerleaders" or whatever"
There are many ways to improve that. Use Meta Tags, update your site as often as you can (forces the Spider to index it again), etc.
>""If you need a speed increase you suck anyway: I'm a web developer for a living, and I'm still stuck on a 33.6 connection. We don't all live in the US where access is cheap and fast."
My experience is that reusing images by using "../image.gif" like hrefs would speed up very many Pages much more than those frames.
Don't gert me wrong. If there was a significant improvement by using frames I may consider it (I hae a Page using Layers for a Game e.g.). But since I usually whant as many people as possible to view the Pages I create I also test them with "only for real Programmers" Browsers like Lynx. I never really got a frames empowered site working with Lynx without loosing any improovement I get from frames.
IIRC the german magazine c't did a Test (with existing systems, so no new RAMBUS etc. For the Intel and no 200MHz Frontside bus etc. for the Athlon. The result was that Coppermine running at 733MHz is still slightly slower than the Athlon at 700MHz.
:-)
Milk is bad because bad people can drink it...
AFAIK There is one way around that:
You should check the actual Laws before. You should be able to label your Book as "Scientific Work". AFAIK you allowed to export that.
Do you really think people from outside US can't make Crypto software that compares well to the one made by Network Assosiates?
Where does GnuPG come from? Where are OpenSSL and FreeSWAN developed. Not to speek of the russian, chineese and indish Math gurus.
I think the main mistake the American Government is making is that they assume they can prevent anyone from using strong encryption. Actually they cant.
Just you need to tell the reciever of the message where in all this the message is. Still you have to hide that Information from the Attacker...
BTW for 99% of all Applications bloating the Data is just not acceptable.
Well, the Problem of factoring does imlply the need for large keys which is - as someone else stated before - the main reason why RSA is so slow.
"Public key algorithms aren't cryptographically strong."
Well, not all of them... Also you can make them strong by increasing Key Length.
"The "big idea" of public key algorithms is not that they're more secure but rather that they allow secure communications between parties without shared secrets."
That doesnt say that there is an authentication in it. You definately need some shared secrets for that (I know about zero knowledge etc. but actually they rely at some state on a possibility to prove the own identity to someone else, and you need shared secrets for that - the shared secret for the pizzy guy is the order).
some remarks:
So I think you are right in saying public key systems do not fit the need. Your analysis of the problem reducing it to key length is definately wrong.
Perl isnt that bad in my view. The point is, that any of the Languages you named (C and Java) actually have the same problem.
When I started C programming I did exactly what those "Perl or Dummies" guys do in C. I wrote Spagetti Code without reasonable coments just to get it running somehow. After a while I had to rewrite all my code and I learned hard what a good coding style is.
Now I also do Perl programming, and acctually I can use it much like an interpreted C with some nice additional features. I know, that there are other ways to do that, but why use them? If I get code by someone who did Pascal or sh programming before I can figure out what he ment, if he did it propperly. Can you figure out uncommented newby spagetti code in C?
What Im trying to say is that most languages share that problem with Perl. Still Perl is a nice and easy way of writing code for typical CGI scripts as long as someone with experience is writing the code. If the code is written by an unexperienced newby any result in any language may be awful.
The real problem you are facing is that there are too many newbys around writing CGI scripts. They start by having seen Frontpage once in a shop and begin to write websites with it. Then they grow into a job and have to do something dynamically because the Big Boss whants to have a chat on the Homepage.
I suggest to welcome those guys as hopefully good programmers in future. We should take them by their hands ant leed them to good code.
AFAIK There is a standard Protocol called IIOP (Internet Inter ORB Protocol) That lets different orbs work together.
Im not really shure about that, but thats what Ive filtered out.
If that is true you can use different orbs on different machines and they still work together.
It would be a fascinating Idea of having a Perl Frontend for egcs. Then the last point would also speak for Perl.
One could also write and test perl code using the Interpreter, and when it comes to beeing productive and fast compile it.
Jou don't get that from himplementing Perl in Java. You get that by implementing Perl to compile not to their own intermediate code, but to Java Byte code and then run the result through a Java VM.
So I guess that the implementation of Perl should never been thought of been done in Java.