If you were standing on dry ground with insulated boots, then you were like a bird who stands on a 125,000 V wire on transmission lines that can provide the amperage and who still stays alive.
Are you sure you weren't touching any part of the car. For a car circuit, the body of the car constitute the ground;-)
V = RI always apply, in truth your body cause the voltage to drop hence it is no longer true that you are at 10,000 volts. You are merely at 5 volt, maybe...
When I said "the spark device chokes", in truth, it meant that the voltage drops and that the device cannot sustain 10,000 volt while grounded to your body.
Sorry about this, the parent post is hard to follow but it makes sense except for the topic in this correction.
In realty, it is watts X time = joules that goes through your body that kills you. In short, the amount of energy going through your body in a relative small amount of time.
Watts = Voltage X amperage
You need BOTH Voltage and amperage to kill you.
Spark plugs wires provide high voltage but they are unable to provide enough amperage thus energy to go along with it in order to kill you.
The V = RI formula doesn't apply in this case, spark plugs wire aren't able to provide sufficient I (amperage) in order to kill although your body would be able to take a lot more given its R (resistance) value. Spark plug devices choke, not being able to provide sufficient I (amperage) to kill you and to make the V = RI formula apply.
Keeping the connection alive (keep alive) enables you to do just that without running a server (e.g. listening socket) in your web browser. Yet, people do not use it much. Allowing the server to connect back to you is even more complex and I do not think it would fly that much, you would now need more complex server applications. Paying the almost costless price to establish a new connection every time is the privileged option nowadays and most applications are built with that architecture in mind.
Even only allowing the server that you already connected to to connect back to you (listening socket in the browser) is a security risk.
I understand your point, you are basically saying that we should incorporated fancy p2p capabilities into web browsers;-)
My point is that it is a bad idea security wise. I use p2p clients/servers to do p2p ( Note: p2p clients are also servers). I admire p2p algorithms just as much as you might do but let's use right tools for the right job.
A lot of people, especially big corporations, won't like the idea of having their employees running p2p clients/servers incorporated in their web browsers either;-)
People running p2p clients/servers should understand the issues and risks. Computers are not sold with p2p clients/servers already installed into them. Computers are sold with pre-installed web browsers. Think about the "Grandma" type of users.
How would this peer2peer like static content propagation be really useful in a modern web application ? It is not worth the security implications (basically the same as running any p2p client)
Most web applications have dynamic content nowadays you know.
Would you rather to get stale Slashdot articles from the browser running in your neighbor's computer or to get them fresh from Slashdot ?
Again, nothing here that caching proxies don't already do, and people do not like caching proxies as I explained above in the GP.
> But accepting incoming HTTP connections in the browser is just asking for trouble.
Exactly, transparent caching proxies would seem to solve issue in a simpler and easier to manage way. Then again, providers trying to implement caching proxies that I know of have all abandoned the idea after trying it. Their customers complained to much and it brings all sort of problems with the transactional behavior of an application.
So people do not like caching proxies, why would they like one in their browser ? Why would they like getting content from another user browser instead of from the original source ?
Also, we live in a economy where we try to boost demand. I observed this trend many years ago: The more we go into the future, the less we seem to be concerned about bandwidth. Bandwidth is getting cheaper and cheaper and providers want to sell more bandwidth;-)
Bandwidth usage is meant to go up anyway so I do not see their concept fly. I mean if we are really concerned about bandwidth that much, let's start by design application properly and use what is already in place (cache, expiry headers, etc.) properly, which is seldom the case in the applications that I have seen.
In the tightest companies I have worked for, they name workstations and servers with meaningless random generated alphanumeric sequences.
I guess they consider it more secure, making it harder to figure out the network topology. Also, since the names are meaningless, there is never a need to rename the machine really, unless they would want to confuse even more want to be hackers.
While reading, I kept hearing the song "For the love of money" from the '70s in my head. The one from the O'Jays that goes "money,money,money,money, mooo...neeey";-)
Well; "waive the bond requirement, according to court filings. The actual document was filed under seal, so the full contents of the request have not yet been made public."
It sure helps having money to settle court cases in your favor, doesn't it ?
I agree too. Most friends I have who do not like Java is because they are not able to write a Java application;-))
It is hard to like something that you have a hard time to grasp. Some week day java programmers might master Java just enough to fulfill their workday tasks but they may not master it enough to do whatever they want with it. These will also say that Java isn't fun.
I have used a lot of languages but nowadays, I use mostly sh for anything new and simple that I write while resorting to Java for anything a little more complex. I also maintain php and perl, ajax/javascript stuff and I like it less...;-(
Very correct, in Java where multiple inheritance isn't allowed, too much inheritance in an application code is usually still a sign of developers/architects with less experience that seem to think that OO design equals inheritance as much as possible. Sometimes, the code looks like kids trying a new toy have written it;-)
The average application usually doesn't make that much inheritance usage. You should see much more interface usage (implements) than child classes (extends). I often corrected designs to replace "X is a Y" by "X has a Y".
That said, it is very correct to use inheritance where it is needed;-))
We are deeply sorry about this, we have just launched a test run of our experimental software and we did not think it could affect Twitter's performance. We have now reduced the threshold of our requests so everything should be back to normal now.
I just wrote on twitter about my opinion about harnessing the stream of messages flowing through twitter to read public opinion and sentiment in real time.
There is also systems that duplicate data on empty blocks in the file system.
If you look at the file system, it looks like a normal one, encrypted or not (at your convenience).
The algorithm writes encrypted data in "officially" empty blocks on that file system. It duplicates the data in several spots to make sure the "real" file system doesn't trash the information when it writes files.
All encrypted information kept by those systems is stored in "officially" empty blocks.
So give them the key for your encrypted file system, but keep your sensitive information in empty blocks on that file system. The hidden data is encrypted with yet another key. Keep the software needed to read the hidden data on a flash drive so there is no trace that you are using such a thing on the machine;-))
And no, if you look at the empty blocks, you won't see: "This is a file from APP. It's version X.Y. It's N bytes long. Encryption algorithm is A. Hash method is H. Data follows..."
I had a Linux root kit in 1998 that did just that, I remember it modified netstat, ps. top and others. Not sure about tcpdump although. it is common in any "good" rootkit;-))
Slashdot Mirror
Are you praying god or the nature ?
If so, you should be more polite...
I like the GP suggestion, in scientific thinking, you *need* to make hypothesis and try to validate them.
What if the ribbons were just Galactic Northern Lights ? ;-))
There is nothing wrong with trying to guess in science as long as you categorize your thoughts as hypothesis...
Yep indeed! it was obvious for an old f* like me that you were talking about V'ger ! ;-)
Not sure what Star Trek Voyager is although I think I remember that it is some kind of a Star Trek fork like "Deep space nine".
Thinking of it, isn't this the one where Mrs. Columbo is the captain of the ship ? ;-)
I did not know that V'ger never left the galaxy although, Thanks !
> You must have gotten a pink slip a week ago,
Or maybe he/she just GOT a JOB ;-) Not being busy looking for one anymore and having easy access to a computer 8 hours a day ;-)
and *synthetic* lubrication has the reputation the make things go even faster...
If you were standing on dry ground with insulated boots, then you were like a bird who stands on a 125,000 V wire on transmission lines that can provide the amperage and who still stays alive.
Are you sure you weren't touching any part of the car. For a car circuit, the body of the car constitute the ground ;-)
Unfortunately your parent post was right, read the correction I posted, physics help to explain a lot of things you know:
http://slashdot.org/comments.pl?sid=1340253&cid=29116915&art_pos=2
I also posted another reply admitting my original post was hard to follow but *almost* entirely correct :
http://slashdot.org/comments.pl?sid=1340253&cid=29116975&art_pos=1
100% agreed, I couldn't cover all aspects of this but I swear I thought about what you are mentioning.
I do not think so, even for a fraction of a second 10,000 volt will kill you.
I agree my wording in the GP was hard to follow, I can rephrase with strict units if yo wish ;-)
Please read my correction just below, I think this is the only point I missed in the GP.
http://slashdot.org/comments.pl?sid=1340253&cid=29116915
Correction:
V = RI always apply, in truth your body cause the voltage to drop hence it is no longer true that you are at 10,000 volts. You are merely at 5 volt, maybe...
When I said "the spark device chokes", in truth, it meant that the voltage drops and that the device cannot sustain 10,000 volt while grounded to your body.
Sorry about this, the parent post is hard to follow but it makes sense except for the topic in this correction.
In realty, it is watts X time = joules that goes through your body that kills you. In short, the amount of energy going through your body in a relative small amount of time.
Watts = Voltage X amperage
You need BOTH Voltage and amperage to kill you.
Spark plugs wires provide high voltage but they are unable to provide enough amperage thus energy to go along with it in order to kill you.
The V = RI formula doesn't apply in this case, spark plugs wire aren't able to provide sufficient I (amperage) in order to kill although your body would be able to take a lot more given its R (resistance) value. Spark plug devices choke, not being able to provide sufficient I (amperage) to kill you and to make the V = RI formula apply.
> Please explain if you do.
Keeping the connection alive (keep alive) enables you to do just that without running a server (e.g. listening socket) in your web browser. Yet, people do not use it much. Allowing the server to connect back to you is even more complex and I do not think it would fly that much, you would now need more complex server applications. Paying the almost costless price to establish a new connection every time is the privileged option nowadays and most applications are built with that architecture in mind.
Even only allowing the server that you already connected to to connect back to you (listening socket in the browser) is a security risk.
More explanations:
http://slashdot.org/comments.pl?sid=1340213&cid=29111783&art_pos=2
http://slashdot.org/comments.pl?sid=1340213&cid=29112163&art_pos=1
http://slashdot.org/comments.pl?sid=1340213&cid=29112577
I understand your point, you are basically saying that we should incorporated fancy p2p capabilities into web browsers ;-)
My point is that it is a bad idea security wise. I use p2p clients/servers to do p2p ( Note: p2p clients are also servers). I admire p2p algorithms just as much as you might do but let's use right tools for the right job.
A lot of people, especially big corporations, won't like the idea of having their employees running p2p clients/servers incorporated in their web browsers either ;-)
People running p2p clients/servers should understand the issues and risks. Computers are not sold with p2p clients/servers already installed into them. Computers are sold with pre-installed web browsers. Think about the "Grandma" type of users.
Cheers ;-)
How would this peer2peer like static content propagation be really useful in a modern web application ? It is not worth the security implications (basically the same as running any p2p client)
Most web applications have dynamic content nowadays you know.
Would you rather to get stale Slashdot articles from the browser running in your neighbor's computer or to get them fresh from Slashdot ?
Again, nothing here that caching proxies don't already do, and people do not like caching proxies as I explained above in the GP.
> But accepting incoming HTTP connections in the browser is just asking for trouble.
Exactly, transparent caching proxies would seem to solve issue in a simpler and easier to manage way. Then again, providers trying to implement caching proxies that I know of have all abandoned the idea after trying it. Their customers complained to much and it brings all sort of problems with the transactional behavior of an application.
So people do not like caching proxies, why would they like one in their browser ? Why would they like getting content from another user browser instead of from the original source ?
Also, we live in a economy where we try to boost demand. I observed this trend many years ago: The more we go into the future, the less we seem to be concerned about bandwidth. Bandwidth is getting cheaper and cheaper and providers want to sell more bandwidth ;-)
Bandwidth usage is meant to go up anyway so I do not see their concept fly. I mean if we are really concerned about bandwidth that much, let's start by design application properly and use what is already in place (cache, expiry headers, etc.) properly, which is seldom the case in the applications that I have seen.
A problem that I can see is that web browsers already contain enough security holes, imagine if they contained a web server ;-)
In the tightest companies I have worked for, they name workstations and servers with meaningless random generated alphanumeric sequences.
I guess they consider it more secure, making it harder to figure out the network topology. Also, since the names are meaningless, there is never a need to rename the machine really, unless they would want to confuse even more want to be hackers.
While reading, I kept hearing the song "For the love of money" from the '70s in my head. The one from the O'Jays that goes "money,money,money,money, mooo...neeey" ;-)
Well; "waive the bond requirement, according to court filings. The actual document was filed under seal, so the full contents of the request have not yet been made public."
It sure helps having money to settle court cases in your favor, doesn't it ?
I agree too. Most friends I have who do not like Java is because they are not able to write a Java application ;-))
It is hard to like something that you have a hard time to grasp. Some week day java programmers might master Java just enough to fulfill their workday tasks but they may not master it enough to do whatever they want with it. These will also say that Java isn't fun.
I have used a lot of languages but nowadays, I use mostly sh for anything new and simple that I write while resorting to Java for anything a little more complex. I also maintain php and perl, ajax/javascript stuff and I like it less... ;-(
Very correct, in Java where multiple inheritance isn't allowed, too much inheritance in an application code is usually still a sign of developers/architects with less experience that seem to think that OO design equals inheritance as much as possible. Sometimes, the code looks like kids trying a new toy have written it ;-)
The average application usually doesn't make that much inheritance usage. You should see much more interface usage (implements) than child classes (extends). I often corrected designs to replace "X is a Y" by "X has a Y".
That said, it is very correct to use inheritance where it is needed ;-))
> I cannot post at this moment.
We are deeply sorry about this, we have just launched a test run of our experimental software and we did not think it could affect Twitter's performance. We have now reduced the threshold of our requests so everything should be back to normal now.
Thanks,
Department of Statistics
University of Vermont
I just wrote on twitter about my opinion about harnessing the stream of messages flowing through twitter to read public opinion and sentiment in real time.
There is also systems that duplicate data on empty blocks in the file system.
If you look at the file system, it looks like a normal one, encrypted or not (at your convenience).
The algorithm writes encrypted data in "officially" empty blocks on that file system. It duplicates the data in several spots to make sure the "real" file system doesn't trash the information when it writes files.
All encrypted information kept by those systems is stored in "officially" empty blocks.
So give them the key for your encrypted file system, but keep your sensitive information in empty blocks on that file system. The hidden data is encrypted with yet another key. Keep the software needed to read the hidden data on a flash drive so there is no trace that you are using such a thing on the machine ;-))
And no, if you look at the empty blocks, you won't see: "This is a file from APP. It's version X.Y. It's N bytes long. Encryption algorithm is A. Hash method is H. Data follows..."
Only random data ;-))
Please read my other posts on this thread, they are all inspired by elementary logic that drives economics in the world we live in:
http://slashdot.org/comments.pl?sid=1328181&cid=28976993&art_pos=13
http://slashdot.org/comments.pl?sid=1328181&cid=28977745&art_pos=11
http://slashdot.org/comments.pl?sid=1328181&cid=28978255&art_pos=10
http://slashdot.org/comments.pl?sid=1328181&cid=28976711&art_pos=14
http://slashdot.org/comments.pl?sid=1328181&cid=28978499&art_pos=9
I had a Linux root kit in 1998 that did just that, I remember it modified netstat, ps. top and others. Not sure about tcpdump although. it is common in any "good" rootkit ;-))