one big thing to consider is the interface to the db you'll be using. i chose postgres for a large server-side java web-application, and while i have zero complaints about postgres the database, the jdbc postgres interface is a complete mess. if you're doing anything beyond the most basic operations, you'll find a _lot_ of the jdbc-2 spec completely or partially unimplimented (and these shortcomings are, of course, undocumented). i've put far too many hours pouring through jdbc driver code in the last year with postgres. though, i give the developers credit for making steady progress in the last year, it just isn't there yet.
like you, i've been pondering the switch to SAP-DB - from looking through the source, their jdbc implementation seems to be very complete. the only problem i've run into with SAP is the lack of readable documentation... the manual seems to have lots of information, but it isn't exactly developer-friendly.
if this is an "enterprise" level application, i see little choice but to dive into SAP and figure it all out - otherwise i think you'll run into bigger problems down the road.
pickup a few intel ee-pro/100 adaptors, and then use intel's advanced networking services module - the cards will support fault tolerance, load balancing, and link aggregation. you'll need to use intel's own e100 kernel module (not the eepro100 module included in the main kernel tree), though i haven't had any problems with it.
Re:When will Mozilla Innovate?
on
Mozilla 0.9.5
·
· Score: 1
if a site operator wants the username field shielded, all they have to do is make both inputs of the password type. it doesn't make any sense to break away from the w3 specs and make all input boxes obfuscated, does it? the wallet feature will already prefill any forms you save data for, and i believe there is progress on form autocomplete just like in the URL bar (anyone else have the bug id handy?)
if you don't think the mozilla project has innovated, you need to look a little closer. how about a rendering engine that works so well that it not only renders the markup, but the entire UI. which also makes the entire application not only easily themeable, but also extensible (see all of the open projects at mozdev.org). how many other browers out there support a UI for html link elements? have you tried the new javascript debugger, or maybe mathML or SVG support? and as of almost _3 months_ ago, crash data showed mozilla as being more stable than netscape-4.x.
i think the mozilla.org team is doing a fine job. think before you speak.
it seems what you are trying to express is that ecstasy was not good for you. that is unfortunate, but it's great that you were able to see that, and make a change in your life for the better. some people, however, don't have the same horrible experiences you have had. perhaps it is unwise to think that because you have had a poor experience, that everyone else will, and therefore the substance should be outlawed, and those experimenting with it should be put in jail.
as you well know, i'm sure, it is not a chemically addictive substance. i find it strange that opponents of it continually refer to it as addictive when there is no evidence to back this up. if you're talking about it possibly being psychologically addictive, then i don't understand why you wouldn't also advocate laws barring video games and chocolates.
this story is almost offensive. maybe instead of making fun of america's "war on drugs" as a journalist you should take the time to educate your readers. if the kids who are here are told the truth and given facts about drug use, then they will grow up and elect officials who will pass fair legislation.
by the way, here's a really interesting letter by john gilmore (of the EFF) on the "emergency re-sentencing of ecstasy" called for in february:
http://www.toad.com/gnu/ecstacy-sentencing.html
i hope CRC is happy, now that they have forced the removal of one of the most valuable sites on the internet. go away CRC, we don't need your kind on the internet.
wow, this is completely fascinating. it makes me think of all the other kinds of development that could take place in this fashion. could this technique be applied abstractly to problems in mediums other than programmable gate arrays?
cool, xmlterm is finally included. xmlterm seems like a really neat project, check it out at http://www.xmlterm.org/. i wish there was a way to build it though without having to build the whole mozilla source tree. rpms are available at the website, but they didn't work too well with m14. this build seems to have a good bit of functionality though. keep up the good work.
i originally posted the story and said that $8,000 would go to the apache software foundation - this is still correct... i'm not sure why it was changed on the front page. just read homepage for the project.
--
The plan:
Solve part of Certicom's ECC challenge. Win $10000 and give most of it to the Apache Software Foundation. Um, that's it. ...
Certicom is offering a prize of $10000 for the first correct solution. If we win it, $1000 will go to each of the two people who find the match and we will donate the remaining $8000 to the Apache Software Foundation. Note that following our previous successes, we have already donated $12000 to the Free Software Foundation.
--
older versions of this effort donated to the FSF, this one is definitely going to apache.
other posters have pointed out that DES is a secure algorithm, but also of note is the ridiculousness of comparing ECC to DES. elliptic curve cryptosystems are for public-key use, while DES is a symmetric cipher. so no, ECC is not "better" than DES, or vice versa. DES is a very strong symmetric cipher that has withstood many many years of attacks. This project helps to show how strong elliptic curve cryptosystems really are, as they have been around a relatively short time (early 80's i believe). While elliptic curves have been studied for a great deal longer than that (as certicom points out), not until recently have they been looked at in regards to cryptography. If ECC is as strong as certicom claims, it proves to be one of the most interesting cryptographic techniques since public-key and RSA itself.
i believe that is what we refer to as "security through obscurity." the algorithm itself must withstand, one must always assume attackers will be able to determine how a document was enciphered. in this particular case, the "crackers" most certainly new about the method of encryption before hand.
> This is about as cool as a guy who claims he can > open every safe and when asked to demonstrate > sits down in front of it and starts > turning the wheel until he gets the combination > by accident.
no, read up on it first. this was not a brute force attack, it used an intelligent algorithm. read more (and brush up on your abstract algebra) here: http://cristal.inria.fr/~harley/ecdl7/FAQ.html
> I like to think I have a concept of what I'm talking about.
urgh, sorry. sometimes i type faster than i think. my apologies for that comment...
i see what you're saying about RSA. there are a lot of reasons a free RSA is a good thing. i do agree that it will help spread the use of strong encryption, and i really can't argue with that. however, DH is just as good a solution -- arguably better. i think RSA is strong today, but is rapidly becoming weaker. if the only use of RSA is legacy systems, then it's great. i just don't think it is a wise idea to continue using it for mission critical needs.
this whole discussion is probably academic, though. personally, i think that ECC is going to be come a defacto standard in the next few years, after it has had more analysis. it eliminates the need for the mammoth keys required for RSA and DH. unfortunately, ECC seems to have just as many patent problems as RSA, so we're back to square one. woops.
wow, do you even know what you're talking about here? diffie hellmen is conjectured to be at least as difficult as rsa, just as the discrete logarithm problem is thought to be at least as difficult as the integer factorization problem. most likely, if one is broken, so is the other. in fact, i would probably bet on the DLP simply because of the *incredible* discoveries as of late which have let to quicker and quicker factoring.
openssh would seem to be the way to go. the plaintext of most encryption schemes today is compressed, btw. this is not so much to reduce the size of the encrypted traffic (it's usually pretty similar in size), but to help hide patterns in the plaintext. various modes of encryption also help hide these patterns. as other people have said, this compression probably won't increase your throughput that much, though, on a text based ssh session. there is a small delay at the beginning of the session, where the session key is generated and encrypted. if you can live with that second delay, openssh is the way to go.
Slashdot Mirror
one big thing to consider is the interface to the db you'll be using. i chose postgres for a large server-side java web-application, and while i have zero complaints about postgres the database, the jdbc postgres interface is a complete mess. if you're doing anything beyond the most basic operations, you'll find a _lot_ of the jdbc-2 spec completely or partially unimplimented (and these shortcomings are, of course, undocumented). i've put far too many hours pouring through jdbc driver code in the last year with postgres. though, i give the developers credit for making steady progress in the last year, it just isn't there yet.
like you, i've been pondering the switch to SAP-DB - from looking through the source, their jdbc implementation seems to be very complete. the only problem i've run into with SAP is the lack of readable documentation... the manual seems to have lots of information, but it isn't exactly developer-friendly.
if this is an "enterprise" level application, i see little choice but to dive into SAP and figure it all out - otherwise i think you'll run into bigger problems down the road.
it looks like those docs are for 2.4.5 only.
goto considered harmful.
uh... yeah, i should hope so.
pickup a few intel ee-pro/100 adaptors, and then use intel's advanced networking services module - the cards will support fault tolerance, load balancing, and link aggregation. you'll need to use intel's own e100 kernel module (not the eepro100 module included in the main kernel tree), though i haven't had any problems with it.
r /a ns/linux/linansoverview.htm
http://support.intel.com/support/network/adapte
if a site operator wants the username field shielded, all they have to do is make both inputs of the password type. it doesn't make any sense to break away from the w3 specs and make all input boxes obfuscated, does it? the wallet feature will already prefill any forms you save data for, and i believe there is progress on form autocomplete just like in the URL bar (anyone else have the bug id handy?)
if you don't think the mozilla project has innovated, you need to look a little closer. how about a rendering engine that works so well that it not only renders the markup, but the entire UI. which also makes the entire application not only easily themeable, but also extensible (see all of the open projects at mozdev.org). how many other browers out there support a UI for html link elements? have you tried the new javascript debugger, or maybe mathML or SVG support? and as of almost _3 months_ ago, crash data showed mozilla as being more stable than netscape-4.x.
i think the mozilla.org team is doing a fine job. think before you speak.
this is binet's formula. it's wonderfully interesting, and worthy of the aforementioned cause.
m l
http://cut-the-knot.com/arithmetic/Fibonacci.ht
it seems what you are trying to express is that ecstasy was not good for you. that is unfortunate, but it's great that you were able to see that, and make a change in your life for the better. some people, however, don't have the same horrible experiences you have had. perhaps it is unwise to think that because you have had a poor experience, that everyone else will, and therefore the substance should be outlawed, and those experimenting with it should be put in jail.
as you well know, i'm sure, it is not a chemically addictive substance. i find it strange that opponents of it continually refer to it as addictive when there is no evidence to back this up. if you're talking about it possibly being psychologically addictive, then i don't understand why you wouldn't also advocate laws barring video games and chocolates.
this story is almost offensive. maybe instead of making fun of america's "war on drugs" as a journalist you should take the time to educate your readers. if the kids who are here are told the truth and given facts about drug use, then they will grow up and elect officials who will pass fair legislation. by the way, here's a really interesting letter by john gilmore (of the EFF) on the "emergency re-sentencing of ecstasy" called for in february: http://www.toad.com/gnu/ecstacy-sentencing.html
john gilmore summarizes why many of us feel that eliminating scarcity is a good thing:
http://www.toad.com/gnu/whatswrong.html
you get thirty free browser windows in reserve, of course.
most classes at gt don't even allow students to use pocket calculators, much less pda's.
...and how exactly would that benefit apple?
i hope CRC is happy, now that they have forced the removal of one of the most valuable sites on the internet. go away CRC, we don't need your kind on the internet.
wow, this is completely fascinating. it makes me think of all the other kinds of development that could take place in this fashion. could this technique be applied abstractly to problems in mediums other than programmable gate arrays?
...sawfish :)
cool, xmlterm is finally included. xmlterm seems like a really neat project, check it out at http://www.xmlterm.org/. i wish there was a way to build it though without having to build the whole mozilla source tree. rpms are available at the website, but they didn't work too well with m14. this build seems to have a good bit of functionality though. keep up the good work.
i originally posted the story and said that $8,000 would go to the apache software foundation - this is still correct... i'm not sure why it was changed on the front page. just read homepage for the project.
--
The plan:
Solve part of Certicom's ECC challenge.
Win $10000 and give most of it to the Apache Software Foundation.
Um, that's it.
...
Certicom is offering a prize of $10000 for the first correct solution. If we win it, $1000 will go to each of the two people who find the match and we will donate the remaining $8000 to the Apache Software Foundation. Note that following our previous successes, we have already donated $12000 to the Free Software Foundation.
--
older versions of this effort donated to the FSF, this one is definitely going to apache.
later,
ian
other posters have pointed out that DES is a secure algorithm, but also of note is the ridiculousness of comparing ECC to DES. elliptic curve cryptosystems are for public-key use, while DES is a symmetric cipher. so no, ECC is not "better" than DES, or vice versa. DES is a very strong symmetric cipher that has withstood many many years of attacks. This project helps to show how strong elliptic curve cryptosystems really are, as they have been around a relatively short time (early 80's i believe). While elliptic curves have been studied for a great deal longer than that (as certicom points out), not until recently have they been looked at in regards to cryptography. If ECC is as strong as certicom claims, it proves to be one of the most interesting cryptographic techniques since public-key and RSA itself.
later,
ian
i believe that is what we refer to as "security through obscurity." the algorithm itself must withstand, one must always assume attackers will be able to determine how a document was enciphered. in this particular case, the "crackers" most certainly new about the method of encryption before hand.
later,
ian
> This is about as cool as a guy who claims he can
> open every safe and when asked to demonstrate
> sits down in front of it and starts
> turning the wheel until he gets the combination
> by accident.
no, read up on it first. this was not a brute force attack, it used an intelligent algorithm. read more (and brush up on your abstract algebra) here: http://cristal.inria.fr/~harley/ecdl7/FAQ.html
later,
ian
> I like to think I have a concept of what I'm talking about.
urgh, sorry. sometimes i type faster than i think. my apologies for that comment...
i see what you're saying about RSA. there are a lot of reasons a free RSA is a good thing. i do agree that it will help spread the use of strong encryption, and i really can't argue with that. however, DH is just as good a solution -- arguably better. i think RSA is strong today, but is rapidly becoming weaker. if the only use of RSA is legacy systems, then it's great. i just don't think it is a wise idea to continue using it for mission critical needs.
this whole discussion is probably academic, though. personally, i think that ECC is going to be come a defacto standard in the next few years, after it has had more analysis. it eliminates the need for the mammoth keys required for RSA and DH. unfortunately, ECC seems to have just as many patent problems as RSA, so we're back to square one. woops.
later,
ian
wow, do you even know what you're talking about here? diffie hellmen is conjectured to be at least as difficult as rsa, just as the discrete logarithm problem is thought to be at least as difficult as the integer factorization problem. most likely, if one is broken, so is the other. in fact, i would probably bet on the DLP simply because of the *incredible* discoveries as of late which have let to quicker and quicker factoring.
openssh would seem to be the way to go. the plaintext of most encryption schemes today is compressed, btw. this is not so much to reduce the size of the encrypted traffic (it's usually pretty similar in size), but to help hide patterns in the plaintext. various modes of encryption also help hide these patterns. as other people have said, this compression probably won't increase your throughput that much, though, on a text based ssh session. there is a small delay at the beginning of the session, where the session key is generated and encrypted. if you can live with that second delay, openssh is the way to go.
this appears to be the first kernel to support ieee1394/firewire... someone try it out and let us know how it works.
later,
ian