Programmers invent their own algorithms all the time. Sure it may be reinventing the wheel, but that's part of the fun -- most wheels don't take that much time to invent anyway and it gives a much deeper understanding of what you are doing than having the solution just handed to you.
Contrast it with looking through millions of patents, obtaining a (costly) license for your (free?) software and implementing something you only have a borderline understanding of... Reinventing the wheel suddenly doesn't look so bad anymore.
You think too difficult. You could detect it by devices not being reachable because they're disconnected or no longer on your local network (ie, ms ping times). Just wipe the encryption key then, reboot (or active screensaver) and wait for the key to re-entered.
Although I'm sure you can move a computer plus some components without powering it down, try moving an entire network at once without anything odd being detected.
We are not denying them anything. I'm fine with them TRYING to make money of something immaterial that has 0 reproduction costs, just don't expect the populous to bend over backwards to have the privilege of paying for it.
I simply refuse to subscribe to a view where something with 0 reproduction costs should for some reason give a return on investment that scales with the population on this planet. A fair compensation sure -- unfortunately, they want it all.
Only up to a point, because only increasing by parallelism means increasing it by adding higher power requirements. If you think 300 W is a lot of power now, then it will be a heck of lot worse after we compensated Moore's law for a couple of years by adding more parallelism.
Better compression for video is mainly restricted by CPU power (during decoding) at the moment. There's still plenty of room for improvement (mainly in accurately predicting movement in frames).
However, I feel that compression is only useful these days for video. Audio, text and images just don't consume enough space of bandwidth to matter much anymore.
As for bandwidth, this is increasing so fast that it won't be much longer before internet will be available that is faster than my hard drive can store it... in other words, the problem will solve itself over time and the need for compression will become more and more irrelevant.
If it's encrypted it's going to have 'look random' - so that's ballsed up the compression ratios of the jpg you uploaded
There's two ways to do the encryption. But the only one that makes sense is to FIRST compress the image (with JPEG), then encrypt it. I don't see how it would have the slightest impact on compression ratios.
Of course, schemes have been known to first encrypt data, then try to compress it, but I doubt they would ever become very popular.
How did you get that immense queue in the first place? Sounds to me the TCP Window size is set WAY too large, which would be a problem on the initiating side (ie, your own computer). A TCP download won't send more data than you ask it to give, and will wait for ACK's of the previous data before sending more.
If you are silly enough to tell it, YES, send me that 1 GB right now! And then it takes your line 3 minutes to handle it all, then who's exactly at fault?
Instead, you tell it: send me that 1 GB but do it in chunks of 32 kB, and don't send more until I acknowledge the previous chunk was received correctly -- which is a gross simplification of what TCP does.
I don't see how buffers come into play... not to mention that RAM sizes have scaled by several orders of magnitude since the beginning of the internet and now, and only now we start noticing it? Sure, it may not have been a problem before with tiny buffers, but it always could happen if you (or your software) is stupid enough to ask for more than it can handle. Rate limiting is the correct solution, even going as far as dropping your own outgoing packets if you are trying to oversaturate your link.
For uploads, only if you allow it by not paying attention to ACK's you get from the receiver side and simply keep sending data.
For downloads, only if you are so stupid to request more data than your link can handle.
TCP will handle both of these as part of the spec. The only way you can still fuck it up is by having many connections going at once. In that case, use some proper rate limiting software.
It does not matter how big your ISP's buffer is. Unless they actually make data WAIT in an EMPTY buffer. I don't think they would be that stupid though, in which case the solution always is....
Donot REQUEST more data than your link can download -- this can be done with throttling, and not acknowledging previously received data until you are ready for more.
Donot SEND more data than your link can upload -- simply limit the rate of outgoing data to be slightly below your Routers maximum send speed.
The result: the ISP's buffer will be running close to empty at all times. Your Router's buffer will also be running close to empty at all times (since it can always send/receive the data slightly faster than the rate limit that you set your software to).
Nice side benefit: Effectively the queue will be on your computer's side. Inserting something at the head of the queue would then skip whatever is already queued up (for sending). Prioritize your games/pings/interactive stuff and you won't even notice that big download in the background.
Actually, I think it is ONLY about you buffering. Other boxes buffering is completely irrelevant because YOUR tcp/ip stack should have adjusted the window size accordingly, no matter what is in between you and the destination.
I mean, if I have a super fast link, but some box in between has a super slow link with a 1 GB buffer, how does that affect me? It only affects me if I actually use a huge window size, but any properly written TCP/IP stack would never use such large window sizes as the receiver would have to acknowledge initial burst of data first...
The other way around? My link begin super slow? Same thing.
Now, if you simply make sure that the buffers on your router are always empty and therefore putting them out of play, then latency will be close to minimum. How to do that? Simple, don't request more data than your link can download, and donot send more data than your link can upload. There's software that can do that.
Except that never happens, since you donot request 1 GB. Instead you use a TCP link which uses packets, and which are only requested in chunks that your line can handle (using the window size which will scale according to available bandwidth on YOUR side).
In other words, your software will never request sizes that big in one go, and so you will not be saturating your line with it.
If however you do manage to saturate your line, then that is still a problem on your side, and can be solved on your side by simply limiting the rate just below maximum speed.
A: is bogus, there are many sites that can saturate my crappy line without blinking -- they do ALL rate limit though (well actually the receiving site is doing that by virtue of not requesting more data than the TCP window size allows).
B: is irrelevant -- the problem is on the side of the requester; see above, TCP links donot send data willy-nilly, they actually wait until your software acknowledges that earlier data was received before sending more, if they didn't then every site faster than your connection would be DDOS-ing you.
Think of it this way for example: shorten the sentence to just the first character of every word.
So it becomes "Ih3c,a2otab." (a 12 character password). Now, for valid sentences, there's not that many word options that would make a valid sentence using these beginning characters.
"I have 3 chickens, and 2 or three are broken." -- my poor attempt at finding another sentence:)
The idea now is that assuming that there aren't that many possible valid sentences that could match these beginning letters. If it is less than a few thousand, then it would be as good as a 14 character password (the added 2 characters cover the "few thousand" extra possibilities).
Although I have no citations to offer, my common sense tells me that there just isn't that much entropy in english sentences.
What's this notion that the "government", which consists of the same Joe's and Jane's as the normal populous, is somehow smarter and more resourceful, so much so that they can trivially crack our best crypto?
Why would that be harder to crack? Stringing words together in readable sentences is something a cracker can do too. I'm sure the algorithms developed for word prediction (for smart phone keyboards for example) can help immensely there.
Your sentence contains 10 words and two punctuations. It would be comparable to a 12 character password, given that the words and word order have a lot of dependencies.
I think the 14 char password would last longer once sentence password cracking software becomes as advanced as current password crackers.
(The only reason the 14 char password in the article was cracked so fast is due to a hashing blunder in one of the hashing implementation on Windows -- if it was stored as a MD5 or SHA hash it would not have been cracked so easily, if at all).
Slashdot Mirror
Exactly how I feel.
Programmers invent their own algorithms all the time. Sure it may be reinventing the wheel, but that's part of the fun -- most wheels don't take that much time to invent anyway and it gives a much deeper understanding of what you are doing than having the solution just handed to you.
Contrast it with looking through millions of patents, obtaining a (costly) license for your (free?) software and implementing something you only have a borderline understanding of... Reinventing the wheel suddenly doesn't look so bad anymore.
With evidence that slim you'd confiscate computers?
Well, unless it was a rear-end collision, followed by a T-bone one...
Dunno, it depends on the latency.
Just activate screensaver as soon as several local and remote servers show irregularities in their ping times or disappear altogether.
You think too difficult. You could detect it by devices not being reachable because they're disconnected or no longer on your local network (ie, ms ping times). Just wipe the encryption key then, reboot (or active screensaver) and wait for the key to re-entered.
Although I'm sure you can move a computer plus some components without powering it down, try moving an entire network at once without anything odd being detected.
When what is charged? You just pay with cash, and of course, you donot fill in the form to get "double credits".
We are not denying them anything. I'm fine with them TRYING to make money of something immaterial that has 0 reproduction costs, just don't expect the populous to bend over backwards to have the privilege of paying for it.
I simply refuse to subscribe to a view where something with 0 reproduction costs should for some reason give a return on investment that scales with the population on this planet. A fair compensation sure -- unfortunately, they want it all.
Even AI won't help. Give 10 programmers the above instructions and you'll get 10 different results, with subtle and not so subtle differences.
Only up to a point, because only increasing by parallelism means increasing it by adding higher power requirements. If you think 300 W is a lot of power now, then it will be a heck of lot worse after we compensated Moore's law for a couple of years by adding more parallelism.
That's true, nothing ever gets deleted on the internet /sarcasm
Better compression for video is mainly restricted by CPU power (during decoding) at the moment. There's still plenty of room for improvement (mainly in accurately predicting movement in frames).
However, I feel that compression is only useful these days for video. Audio, text and images just don't consume enough space of bandwidth to matter much anymore.
As for bandwidth, this is increasing so fast that it won't be much longer before internet will be available that is faster than my hard drive can store it... in other words, the problem will solve itself over time and the need for compression will become more and more irrelevant.
Of course, such people would not stoop to simply post such messages using someone else's computer / account / wifi, etc..
I prefer a computer to do what I want to do. However, given that the computer cannot read my mind, it will probably do what it THINKS I want to do...
To me, it just says: I'm so filthy rich, I don't even need a salary.
There's two ways to do the encryption. But the only one that makes sense is to FIRST compress the image (with JPEG), then encrypt it. I don't see how it would have the slightest impact on compression ratios.
Of course, schemes have been known to first encrypt data, then try to compress it, but I doubt they would ever become very popular.
How did you get that immense queue in the first place? Sounds to me the TCP Window size is set WAY too large, which would be a problem on the initiating side (ie, your own computer). A TCP download won't send more data than you ask it to give, and will wait for ACK's of the previous data before sending more.
If you are silly enough to tell it, YES, send me that 1 GB right now! And then it takes your line 3 minutes to handle it all, then who's exactly at fault?
Instead, you tell it: send me that 1 GB but do it in chunks of 32 kB, and don't send more until I acknowledge the previous chunk was received correctly -- which is a gross simplification of what TCP does.
I don't see how buffers come into play... not to mention that RAM sizes have scaled by several orders of magnitude since the beginning of the internet and now, and only now we start noticing it? Sure, it may not have been a problem before with tiny buffers, but it always could happen if you (or your software) is stupid enough to ask for more than it can handle. Rate limiting is the correct solution, even going as far as dropping your own outgoing packets if you are trying to oversaturate your link.
For uploads, only if you allow it by not paying attention to ACK's you get from the receiver side and simply keep sending data.
For downloads, only if you are so stupid to request more data than your link can handle.
TCP will handle both of these as part of the spec. The only way you can still fuck it up is by having many connections going at once. In that case, use some proper rate limiting software.
It does not matter how big your ISP's buffer is. Unless they actually make data WAIT in an EMPTY buffer. I don't think they would be that stupid though, in which case the solution always is....
Donot REQUEST more data than your link can download -- this can be done with throttling, and not acknowledging previously received data until you are ready for more.
Donot SEND more data than your link can upload -- simply limit the rate of outgoing data to be slightly below your Routers maximum send speed.
The result: the ISP's buffer will be running close to empty at all times. Your Router's buffer will also be running close to empty at all times (since it can always send/receive the data slightly faster than the rate limit that you set your software to).
Nice side benefit: Effectively the queue will be on your computer's side. Inserting something at the head of the queue would then skip whatever is already queued up (for sending). Prioritize your games/pings/interactive stuff and you won't even notice that big download in the background.
Actually, I think it is ONLY about you buffering. Other boxes buffering is completely irrelevant because YOUR tcp/ip stack should have adjusted the window size accordingly, no matter what is in between you and the destination.
I mean, if I have a super fast link, but some box in between has a super slow link with a 1 GB buffer, how does that affect me? It only affects me if I actually use a huge window size, but any properly written TCP/IP stack would never use such large window sizes as the receiver would have to acknowledge initial burst of data first...
The other way around? My link begin super slow? Same thing.
Now, if you simply make sure that the buffers on your router are always empty and therefore putting them out of play, then latency will be close to minimum. How to do that? Simple, don't request more data than your link can download, and donot send more data than your link can upload. There's software that can do that.
Except that never happens, since you donot request 1 GB. Instead you use a TCP link which uses packets, and which are only requested in chunks that your line can handle (using the window size which will scale according to available bandwidth on YOUR side).
In other words, your software will never request sizes that big in one go, and so you will not be saturating your line with it.
If however you do manage to saturate your line, then that is still a problem on your side, and can be solved on your side by simply limiting the rate just below maximum speed.
A: is bogus, there are many sites that can saturate my crappy line without blinking -- they do ALL rate limit though (well actually the receiving site is doing that by virtue of not requesting more data than the TCP window size allows).
B: is irrelevant -- the problem is on the side of the requester; see above, TCP links donot send data willy-nilly, they actually wait until your software acknowledges that earlier data was received before sending more, if they didn't then every site faster than your connection would be DDOS-ing you.
Python did not do itself any favors by using idents for blocks. It makes it hard to teach on a blackboard, or any other medium that has finite space.
Think of it this way for example: shorten the sentence to just the first character of every word.
So it becomes "Ih3c,a2otab." (a 12 character password). Now, for valid sentences, there's not that many word options that would make a valid sentence using these beginning characters.
"I have 3 chickens, and 2 or three are broken." -- my poor attempt at finding another sentence :)
The idea now is that assuming that there aren't that many possible valid sentences that could match these beginning letters. If it is less than a few thousand, then it would be as good as a 14 character password (the added 2 characters cover the "few thousand" extra possibilities).
Although I have no citations to offer, my common sense tells me that there just isn't that much entropy in english sentences.
What's this notion that the "government", which consists of the same Joe's and Jane's as the normal populous, is somehow smarter and more resourceful, so much so that they can trivially crack our best crypto?
Why would that be harder to crack? Stringing words together in readable sentences is something a cracker can do too. I'm sure the algorithms developed for word prediction (for smart phone keyboards for example) can help immensely there.
Your sentence contains 10 words and two punctuations. It would be comparable to a 12 character password, given that the words and word order have a lot of dependencies.
I think the 14 char password would last longer once sentence password cracking software becomes as advanced as current password crackers.
(The only reason the 14 char password in the article was cracked so fast is due to a hashing blunder in one of the hashing implementation on Windows -- if it was stored as a MD5 or SHA hash it would not have been cracked so easily, if at all).