People who actually use their computers for work instead of surfing really need it. I don't know how often I'd like to mount a drive on my desktop at home while at work or using my laptop. Or access the browser on the desktop to check the URL history to find a link I thought I'd never need again, but which suddenly became important. Or access the printer configuration page to see how I set it up so I can help someone with a similar device. Getting rid of NAT changes the problem from being technical to being about policy and access control - and that actually has acceptable solutions. It goes back to letting TCP/IP be the general-purpose networking protocol it was designed to be without half-functional hacks like ssh connection tunneling. My computers should be able to sync address books, keychains, and other data without having to bounce of a third-party pay service just to get around routing problems - there really is no good reason for them to exist whatsoever. All that's needed is authentication (and that could certainly be third-party).
I suppose I should have addressed the argument that only 20% of farms owned slaves. I bet less than 1% of the population owned slaves, in fact - yet the 99%+ wouldn't vote to abolish it as a gesture of conciliation to the north? Why? Could it be that the 20% of farms that owned slaves represented 80% of output - heck, maybe even 80% of the GDP of these states at the time, and abolishing slavery was heavily subject to economic FUD arguments?
Methinks someone pays way too much attention to talk radio. Remember, for entertainment purposes only.
To argue that the War Between the States was about slavery, or that the South had slavery in mind as a reason for supporting states rights, is patently false.
Zip and RAR and PAR are used to distribute illegal software, WAREZ, etc. as well as legitimate business items..
I've never seen them used for anything legal. They are tools of the thief stalking the night, with no legitimate uses whatsoever. We've all seen the token legal zip file, but come on, who actually downloads these - we all know file compression was invented to facilitate illegal downloading! Internet Explorer was invented to browse illegal archives, everybody knows this and that it has no other real uses. In fact, we all know Turning invented computing so he could download porn without paying... and somewhere Mr Cerf is cackling over the grand success of his scheme to connect booty sites with downloaders.
I certainly agree with the quote in theory, but I also feel that it has to be broken because of the nature of society. In my town, there were some pretty nasty red-light runners. I was almost hit several times. So when they came to take away part of my liberty by installing red light cameras, I wasn't so upset. It was a trade off that would make the world better.
Yes but red light runners don't just have their property seized. They can go to court and argue it wasn't them, demand to see evidence, and generally defend themselves. Your PD's traffic enforcement doesn't collect names and then go seize their cars because they were used in the commission of a crime. Even red light runners have a right to due process. I have no problem with red light cameras either - or law enforcement in general. I have a problem with just rampantly interfering in civil disputes. Illegal distribution and bootlegging denies the property owners income, but isn't theft since that denies use of tangible property. Unless you steal the sole manuscript it's a bit rich to call it theft; it's generally not something that requires active prevention since it doesn't deny the rightful owner use of it. Nor is it a matter of public safety - it's strictly a civil dispute over distribution rights and compensation.
Or is it just that you feel the need to defend a site as if it was innocent. I really don't care what they hosted on their site, its purpose was clear, to facilitate sharing of copyrighted material.
Maybe, but why is it a homeland security issue, since when does ICE investigate copyright and other private property disputes, and what happened to the right to due process? Since when can the government intervene in civil disputes by simply seizing property without even bothering with a search warrant? I don't remember us ever granting it these rights. In fact it makes me sick that to see our republic and its citizenry raped like this by our hired bureaucrats.
HeapCheck, Electric fence, Dmalloc and all memory debuggers in general, are basically replacing the allocation functions in the executable with their own version.
The "extra" stuff that the patent proposes, is a BOOLEAN flag, that HeapCheck functions would check upon entry (at runtime) - therefore allowing the developer to control (ON/OFF) the machinery at runtime. For example, the substitute allocation function can check a registry setting, to decide whether the functionality is on or off, and a separate utility GUI can toggle this registry setting on/off (I believe Microsoft's PageHeap has something exactly like that).
So tell me, do you REALLY consider this addendum - a boolean flag, for pitty's sake - enough "innovation", to warrant the term "invention"? Patentable "invention"?
It can also mean things like "all allocations made at this point in the program", or "all allocations of this type or size of object", interactively from a debugger. This requires a lot more work under the hood than just a global flag somewhere - for one thing both types of allocations have to be able to coexist. It also means debug settings have to be changeable and the program continue to run.
You are actually arguing... that adding a boolean flag, controlled at runtime - a BOOLEAN flag! - constitutes enough... innovation, to make this... a completely new invention, worthy of patenting?
A mixed-mode allocator isn't as straightforward as you might assume. It's not enough to have a flag; it has to work and be useful as well. However, there must be prior art for this as well, I'm pretty sure it's not the first one invented. But there may well be technical details of the underlying design that are original. Most likely those are described in a different patent though.
First off, the guy's website was cited by the examiner rather than by IBM. The examiner used the OP's website to reject the claims three times before IBM's attorney finally came around and amended the claims to include this:
In other words, IBM tried really hard to patent exactly the method used by HeapCheck and Electric Fence - down to the last detail.
It's not a given they were aware of either of those though. I've never used either for instance - I do almost all my debugging with valgrind. The examiner pointed out the prior art, and eventually they had to narrow their claims. The process worked exactly like it was designed to.
wherein setting the allocation mode for the process to enable determining in real-time an invalid access is performed in real-time, and wherein the setting sets the allocation mode for an application executed by the process without requiring recompiling, linking or loading of the application to set, in real-time, the allocation mode for the application
This was cited by the examiner in the reasons for allowance. Does the OP's code do this?
I noticed this as well, but it's not clear what this actually means. On the face of it, it appears they build on the OP's work and only claim to be able to turn the checking on and off dynamically rather than at compile or link time.
Furthermore, while I agree that hiring someone for a patently fabricated project and career track is unethical, I'm not convinced that Seagate did that here.
Have you ever been involved in a labor dispute? If you have, you know the very fact that Seagate lost means he has hard evidence that they planned and conspired to do this. Without hard evidence your chances of winning a case like this are nil.
Just get a USB or Firewire audio interface for recording audio. Many of them have better quality than internal cards anyway. There's absolutely no need to get a card.
Of course there are specific needs that can't be met with USB/FW. But recording and audio playback isn't among them; getting perfect lip sync with video however is virtually impossible with any buffered device. For that you need SPDIF or a card. A SPDIF device with quality clock recovery will cost a lot more than either USB/FW audio capture and playback, while sounding about the same (but with a completely different level of sync). A card will have the same level of sync control as SPDIF, but will never reach the same sound quality as an outboard, and is probably not acceptable for any professional video production or playback environment. A lot of low-end SPDIF DACs work, but are very sensitive to jitter.
What can you[1] do with an iPad that I can't do with linux on any other tablet from 5 years ago?
Do you really want an exhaustive list of hardware and platform differences? Let's see, anything 3G or GPS navigation related, run keynote presentations, in fact run any other commercial software to speak of, 15 hour battery life, 1 month sleep/standby, type on an onscreen keyboard, fit in an envelope, play angry birds or pvz, you you can't use it as a leveling tool due to lack of accelerometers, you can't buy and download music directly, etc etc. Clearly you're not dumb enough to ask for a list of differences, you just expect to retort that none of these are important, or only stupid people want them, or you can add external hardware to the tablet, or you shouldn't leave home without a charger or extra batteries, etc etc. But clearly enough people care about these things to pay for it, while merely having the ability to point at a screen by itself, in a fairly bulky package with poor performance and battery life, is not marketable in itself. The proof of the pudding is in the eating.
Whatever it is, it's definitely related to I/O, and it makes using Linux really un-fun.
Of course, it used to be that X was given scheduler priority by the distributions, 'improvements' to the kernel ended that practice. Maybe the two are related?
What I suspect they did was bump the temporary scheduling priority of a processes when it blocked for I/O. On a tick-based system with fast I/O this means a single process will monopolize the CPU when an I/O operation takes less than a tick and I/O completion forces rescheduling. Looks great on benchmarks, but sucks in real use. For non-tick schedulers this is less of a problem because a temporary boost in priority can be accompanied by a very short life span - a fraction of the length of a tick. Like Solaris. I suspect the autogroups patch works because the temporary boost only applies within a scheduling group. (But it's hard to tell because the autogroups patch is devoid of comments even on what functions do and their expected side effects, while the code looks rather unfinished.)
but would having MD5 and filesize make it harder to produce collision?
Not appreciably - size matters more for passwords since they're (typically) shorter than the hash. This makes it likely impossible to find a collision between two plaintext strings of equal length. Files are different, even BT chunks, in that they're orders of magnitude larger than the hash. Hence, collisions exist and the strength of the hash is dependent on how difficult they are to produce at will.
Of course, 10 years from now, we'll be using a hash function that takes 1000 times a long to compute, because it doesn't affect real password-checking speed (which is lightning fast compared to typing speed) on the 200GHz-equivalent processor.
If you want it to take 1000 times as long to check a password, then all you need to do is store H(P+R) where P is the password, R a random number between 0 and 2000, and + some sort of transform operator that's not necessarily addition. After storing the hash you discard the random number. This means each password will need on average 1000 runs through the hash function to validate. This is no different from using a computationally more expensive hash function. Fundamentally though, the problem is the small search space, and at some point - no matter what hash function is used - we will need more bits worth of password than we can remember or want to type. At that time we'll have to switch to some physical means, like a card that is unlocked with a short password and then used for authentication. (Think SDIO card or RFID, or even SIM, though presumably once actually a basic necessity we'll have to come up with a standard specifically for it.)
Instead of someone breaking your 20 character password, all they have to do is find a password that hashes to the same as your SHA1 hash. Because of weaknesses in the SHA1 algorithm, any password contains only approximately 8 bytes (8 characters) of data. Put another way, until we improve off SHA1 it is not particularly useful to have a password over 8 characters because it's cheaper to crack the hash than the password anyway.
This is probably not true for password input that rejects non-ASCII. If you find a collision for H(P*V[S]) with password P, where S is a salt identifying a vector from V[], and you have S but not V[], then I suspect that collision is not so useful. First of all even if you could use the collision straight as-is if V[] didn't exist, it would likely contain the 200/256 chars or so that aren't accepted in a password. So you'd have to search for up to 1/((1-200/256)^8)/2 or 95364 collisions on the mean before finding one acceptable. And I bet many of those would still be too long or too short. In practice this means it's not enough to find a collision, but you need to find all collisions - basically you're back to brute force. But V[] would be an obstacle since you need to factor out V[S] before you can feed it into a password field. (I used '*' above loosely as a transform operator to indicate a change of P beyond merely appending a string.)
Now, if you know in advance that you will be able to get a copy of the account data then what you'd do is create one of your own and assign it a password. Now when you get the file you have the hash, P, and S and can attack V[]. Once you have at least one vector you can attack the other passwords using your own V[S] and hope for a solution that's in an acceptable format.
By definition any hash function has collisions if the passwords you are storing have more bits than the hash does (more possible passwords exist than possible hash values). The problem is when it collides in fewer bits.
Collisions aren't a problem per se, the problem is if they're predictable. A cryptographic hash that never produces collisions is like a random number generator that never produces the same output twice in a cycle. I.e., not very random and if not random it's predictable. This is different from other types of hash functions, like those used for data structures, where you ideally want to random shuffle the input space into the output space.
Why do we even have root domains? Why not simply partition load by say the last few letters of the domain name. Reserve trademarks, proper names, and other forms of identity to their rightful owners - this way say a city can register a "root" domain and sell subdomains. Or a country. Or a DNS hotel like GoDaddy. Small organizations can register with whoever they wish as a subdomain, or run their own top level if they wish. Charge a flat fee per domain to recover load costs.
And get rid of the annoying certificate system. These days everyone has account management; when I register for an account my browser should supply a random secret; when I login the browser, in addition to credentials, supplies a random number; in the response to the login the site signs the random secret using a second random number and the secret I provided at registration and returns this random number and its signed version in the reply; the browser then validates that I signed into the site I actually registered with. This could ALL be done transparently under the hood and the user would only be notified on mismatch. Secrets could be stolen, but so can login credentials and certificates, and DNS can be hijacked. Such a simple but effective system would get rid of the need for certificate authorities and the entire expensive trust chain. No need to trust anyone other than yourself! And, finally, when a bank or other party wants to send me email they can SIGN IT using the secret I supplied when I registered to prove their authenticity.
And speaking of DNS, fix it so we look up services such as "give me a list of endpoints for the http service of slashdot". Identify the endpoint by address:port AND PROTOCOL/FAMILY. This way it could return phone numbers, snail mail, TCP listeners, or what have you and it's up to the connecting side to find the one best suited. By extension this would permit lookups like "give me a list of services for slashdot". This would greatly simplify many service deployments!
The thing is with cable with 10 people on it, if 9 of them are downloading, fat chance of you checking your email.
With ADSL, the backhaul is more than likely far faster than the individual connections added together, so no speed degration for anyone.
DOCSIS 3.0 is very different from ethernet - most importantly it's strictly time multiplexed. And slice allocation is such that you will be able to read your email just fine while your neighbors download and/or upload. There is no collision domain. So while it's "shared" it's not a free-for-all where the one with the most TCP connections wins. Fire up more connections and they just compete for your existing allocation. You're the only one who won't be able to check your email.
The same basic metric applies: the degree to which POP capacity is oversold. DSL is always oversold, and no the link from the CO/POP is not infinite, in fact an entire suburban neighborhood might be on a single 22M link. The main difference is that cable has a whole lot more bandwidth to go around and is less oversold. It also does traffic shaping closer to the customer.
"Kind of"? Clearly the helper app has to do any validation and authentication since it has domain specific knowledge. How would the browser know to confirm, say "do you wish to call 1-900-xxx, this will incur a charge?" or "Upgrade CrapWare from 1.x to 2.3 for $19.99?" All the browser can ask is "really run helper App A?" Which may not mean anything to a user and they have no idea whether they want to or not. The fact that anyone can create a link or content that causes Skype.app to make a call really is a problem with Skype, not the browser...
In the example described in the article, the author overlooks one huge fact -- the treadmill is a source of energy, so assuming that a treadmill in a room with no wind is equivalent to traveling over a road with a wind from behind is fundamentally flawed.
What he really overlooks is the fact that no matter how fast the vehicle moves on a treadmill, the wind will always be faster than the vehicle. This doesn't happen in reality, since eventually the vehicle will catch up with the wind.
it is possible, if what you do is to extract energy from the speed difference between the wind and the ground instead of that between the wind and the vehicle.
Yes, but sails and propellers require airflow and hence derive energy from the air that flows past them. When the propeller moves along at wind speed there is no airflow, and hence no energy to be derived. If the propeller is attached to the vehicle then the relevant base speed is that of the vehicle. The maximum speed will be where the diminished airflow is sufficient to overcome the rolling resistance. If the windmill is separate from the vehicle and energy is provided by some other means, such as a cable, power rail, or catenary, then the vehicle is not limited to wind speed. The latter derives energy from the difference between the wind and ground; the former from the difference between wind and vehicle. What you're suggesting requires a stationary windmill.
A co-worker who is a British expat was royally pissed off when his ageing mother was told to go home and die when she had heart ailments in England when she was nearing 70.
But don't despair, we're going to fix that in the U.S. We're going to tell our seniors to curl up and die as well.
This is a good case against public health services, like the NHS, but not really as meaningful when discussing public insurance. Even the brits are ambivalent about the NHS and its days are probably numbered - that doesn't mean they have any intention to do away with public insurance. Most countries with so-called socialized medicine already have privately run health services. Except for outliers, like research institutions - but these tend to be top notch anyway. Even if your insurance doesn't cover something it doesn't consider essential you can always pay out of pocket if you so wish - even in places with so-called socialized medicine.
By the way, I'm pretty sure even the NHS allows patients to go elsewhere for a second opinion.
Slashdot Mirror
what needs "public" IPs? What /really/ needs them?
People who actually use their computers for work instead of surfing really need it. I don't know how often I'd like to mount a drive on my desktop at home while at work or using my laptop. Or access the browser on the desktop to check the URL history to find a link I thought I'd never need again, but which suddenly became important. Or access the printer configuration page to see how I set it up so I can help someone with a similar device. Getting rid of NAT changes the problem from being technical to being about policy and access control - and that actually has acceptable solutions. It goes back to letting TCP/IP be the general-purpose networking protocol it was designed to be without half-functional hacks like ssh connection tunneling. My computers should be able to sync address books, keychains, and other data without having to bounce of a third-party pay service just to get around routing problems - there really is no good reason for them to exist whatsoever. All that's needed is authentication (and that could certainly be third-party).
I suppose I should have addressed the argument that only 20% of farms owned slaves. I bet less than 1% of the population owned slaves, in fact - yet the 99%+ wouldn't vote to abolish it as a gesture of conciliation to the north? Why? Could it be that the 20% of farms that owned slaves represented 80% of output - heck, maybe even 80% of the GDP of these states at the time, and abolishing slavery was heavily subject to economic FUD arguments?
Methinks someone pays way too much attention to talk radio. Remember, for entertainment purposes only.
To argue that the War Between the States was about slavery, or that the South had slavery in mind as a reason for supporting states rights, is patently false.
Right-wing history: now fresh daily!
Zip and RAR and PAR are used to distribute illegal software, WAREZ, etc. as well as legitimate business items..
I've never seen them used for anything legal. They are tools of the thief stalking the night, with no legitimate uses whatsoever. We've all seen the token legal zip file, but come on, who actually downloads these - we all know file compression was invented to facilitate illegal downloading! Internet Explorer was invented to browse illegal archives, everybody knows this and that it has no other real uses. In fact, we all know Turning invented computing so he could download porn without paying... and somewhere Mr Cerf is cackling over the grand success of his scheme to connect booty sites with downloaders.
I certainly agree with the quote in theory, but I also feel that it has to be broken because of the nature of society. In my town, there were some pretty nasty red-light runners. I was almost hit several times. So when they came to take away part of my liberty by installing red light cameras, I wasn't so upset. It was a trade off that would make the world better.
Yes but red light runners don't just have their property seized. They can go to court and argue it wasn't them, demand to see evidence, and generally defend themselves. Your PD's traffic enforcement doesn't collect names and then go seize their cars because they were used in the commission of a crime. Even red light runners have a right to due process. I have no problem with red light cameras either - or law enforcement in general. I have a problem with just rampantly interfering in civil disputes. Illegal distribution and bootlegging denies the property owners income, but isn't theft since that denies use of tangible property. Unless you steal the sole manuscript it's a bit rich to call it theft; it's generally not something that requires active prevention since it doesn't deny the rightful owner use of it. Nor is it a matter of public safety - it's strictly a civil dispute over distribution rights and compensation.
Or is it just that you feel the need to defend a site as if it was innocent. I really don't care what they hosted on their site, its purpose was clear, to facilitate sharing of copyrighted material.
Maybe, but why is it a homeland security issue, since when does ICE investigate copyright and other private property disputes, and what happened to the right to due process? Since when can the government intervene in civil disputes by simply seizing property without even bothering with a search warrant? I don't remember us ever granting it these rights. In fact it makes me sick that to see our republic and its citizenry raped like this by our hired bureaucrats.
HeapCheck, Electric fence, Dmalloc and all memory debuggers in general, are basically replacing the allocation functions in the executable with their own version.
The "extra" stuff that the patent proposes, is a BOOLEAN flag, that HeapCheck functions would check upon entry (at runtime) - therefore allowing the developer to control (ON/OFF) the machinery at runtime. For example, the substitute allocation function can check a registry setting, to decide whether the functionality is on or off, and a separate utility GUI can toggle this registry setting on/off (I believe Microsoft's PageHeap has something exactly like that).
So tell me, do you REALLY consider this addendum - a boolean flag, for pitty's sake - enough "innovation", to warrant the term "invention"? Patentable "invention"?
It can also mean things like "all allocations made at this point in the program", or "all allocations of this type or size of object", interactively from a debugger. This requires a lot more work under the hood than just a global flag somewhere - for one thing both types of allocations have to be able to coexist. It also means debug settings have to be changeable and the program continue to run.
Er... let me get this straight:
You are actually arguing... that adding a boolean flag, controlled at runtime - a BOOLEAN flag! - constitutes enough... innovation, to make this... a completely new invention, worthy of patenting?
A mixed-mode allocator isn't as straightforward as you might assume. It's not enough to have a flag; it has to work and be useful as well. However, there must be prior art for this as well, I'm pretty sure it's not the first one invented. But there may well be technical details of the underlying design that are original. Most likely those are described in a different patent though.
First off, the guy's website was cited by the examiner rather than by IBM. The examiner used the OP's website to reject the claims three times before IBM's attorney finally came around and amended the claims to include this:
In other words, IBM tried really hard to patent exactly the method used by HeapCheck and Electric Fence - down to the last detail.
It's not a given they were aware of either of those though. I've never used either for instance - I do almost all my debugging with valgrind. The examiner pointed out the prior art, and eventually they had to narrow their claims. The process worked exactly like it was designed to.
wherein setting the allocation mode for the process to enable determining in real-time an invalid access is performed in real-time, and wherein the setting sets the allocation mode for an application executed by the process without requiring recompiling, linking or loading of the application to set, in real-time, the allocation mode for the application
This was cited by the examiner in the reasons for allowance. Does the OP's code do this?
I noticed this as well, but it's not clear what this actually means. On the face of it, it appears they build on the OP's work and only claim to be able to turn the checking on and off dynamically rather than at compile or link time.
Furthermore, while I agree that hiring someone for a patently fabricated project and career track is unethical, I'm not convinced that Seagate did that here.
Have you ever been involved in a labor dispute? If you have, you know the very fact that Seagate lost means he has hard evidence that they planned and conspired to do this. Without hard evidence your chances of winning a case like this are nil.
I don't think Seagate was malicious or willfully misconductive.
There's one born every minute...
Just get a USB or Firewire audio interface for recording audio. Many of them have better quality than internal cards anyway. There's absolutely no need to get a card.
Of course there are specific needs that can't be met with USB/FW. But recording and audio playback isn't among them; getting perfect lip sync with video however is virtually impossible with any buffered device. For that you need SPDIF or a card. A SPDIF device with quality clock recovery will cost a lot more than either USB/FW audio capture and playback, while sounding about the same (but with a completely different level of sync). A card will have the same level of sync control as SPDIF, but will never reach the same sound quality as an outboard, and is probably not acceptable for any professional video production or playback environment. A lot of low-end SPDIF DACs work, but are very sensitive to jitter.
What can you[1] do with an iPad that I can't do with linux on any other tablet from 5 years ago?
Do you really want an exhaustive list of hardware and platform differences? Let's see, anything 3G or GPS navigation related, run keynote presentations, in fact run any other commercial software to speak of, 15 hour battery life, 1 month sleep/standby, type on an onscreen keyboard, fit in an envelope, play angry birds or pvz, you you can't use it as a leveling tool due to lack of accelerometers, you can't buy and download music directly, etc etc. Clearly you're not dumb enough to ask for a list of differences, you just expect to retort that none of these are important, or only stupid people want them, or you can add external hardware to the tablet, or you shouldn't leave home without a charger or extra batteries, etc etc. But clearly enough people care about these things to pay for it, while merely having the ability to point at a screen by itself, in a fairly bulky package with poor performance and battery life, is not marketable in itself. The proof of the pudding is in the eating.
Whatever it is, it's definitely related to I/O, and it makes using Linux really un-fun.
Of course, it used to be that X was given scheduler priority by the distributions, 'improvements' to the kernel ended that practice. Maybe the two are related?
What I suspect they did was bump the temporary scheduling priority of a processes when it blocked for I/O. On a tick-based system with fast I/O this means a single process will monopolize the CPU when an I/O operation takes less than a tick and I/O completion forces rescheduling. Looks great on benchmarks, but sucks in real use. For non-tick schedulers this is less of a problem because a temporary boost in priority can be accompanied by a very short life span - a fraction of the length of a tick. Like Solaris. I suspect the autogroups patch works because the temporary boost only applies within a scheduling group. (But it's hard to tell because the autogroups patch is devoid of comments even on what functions do and their expected side effects, while the code looks rather unfinished.)
but would having MD5 and filesize make it harder to produce collision?
Not appreciably - size matters more for passwords since they're (typically) shorter than the hash. This makes it likely impossible to find a collision between two plaintext strings of equal length. Files are different, even BT chunks, in that they're orders of magnitude larger than the hash. Hence, collisions exist and the strength of the hash is dependent on how difficult they are to produce at will.
Of course, 10 years from now, we'll be using a hash function that takes 1000 times a long to compute, because it doesn't affect real password-checking speed (which is lightning fast compared to typing speed) on the 200GHz-equivalent processor.
If you want it to take 1000 times as long to check a password, then all you need to do is store H(P+R) where P is the password, R a random number between 0 and 2000, and + some sort of transform operator that's not necessarily addition. After storing the hash you discard the random number. This means each password will need on average 1000 runs through the hash function to validate. This is no different from using a computationally more expensive hash function. Fundamentally though, the problem is the small search space, and at some point - no matter what hash function is used - we will need more bits worth of password than we can remember or want to type. At that time we'll have to switch to some physical means, like a card that is unlocked with a short password and then used for authentication. (Think SDIO card or RFID, or even SIM, though presumably once actually a basic necessity we'll have to come up with a standard specifically for it.)
Instead of someone breaking your 20 character password, all they have to do is find a password that hashes to the same as your SHA1 hash. Because of weaknesses in the SHA1 algorithm, any password contains only approximately 8 bytes (8 characters) of data. Put another way, until we improve off SHA1 it is not particularly useful to have a password over 8 characters because it's cheaper to crack the hash than the password anyway.
This is probably not true for password input that rejects non-ASCII. If you find a collision for H(P*V[S]) with password P, where S is a salt identifying a vector from V[], and you have S but not V[], then I suspect that collision is not so useful. First of all even if you could use the collision straight as-is if V[] didn't exist, it would likely contain the 200/256 chars or so that aren't accepted in a password. So you'd have to search for up to 1/((1-200/256)^8)/2 or 95364 collisions on the mean before finding one acceptable. And I bet many of those would still be too long or too short. In practice this means it's not enough to find a collision, but you need to find all collisions - basically you're back to brute force. But V[] would be an obstacle since you need to factor out V[S] before you can feed it into a password field. (I used '*' above loosely as a transform operator to indicate a change of P beyond merely appending a string.)
Now, if you know in advance that you will be able to get a copy of the account data then what you'd do is create one of your own and assign it a password. Now when you get the file you have the hash, P, and S and can attack V[]. Once you have at least one vector you can attack the other passwords using your own V[S] and hope for a solution that's in an acceptable format.
By definition any hash function has collisions if the passwords you are storing have more bits than the hash does (more possible passwords exist than possible hash values). The problem is when it collides in fewer bits.
Collisions aren't a problem per se, the problem is if they're predictable. A cryptographic hash that never produces collisions is like a random number generator that never produces the same output twice in a cycle. I.e., not very random and if not random it's predictable. This is different from other types of hash functions, like those used for data structures, where you ideally want to random shuffle the input space into the output space.
Why do we even have root domains? Why not simply partition load by say the last few letters of the domain name. Reserve trademarks, proper names, and other forms of identity to their rightful owners - this way say a city can register a "root" domain and sell subdomains. Or a country. Or a DNS hotel like GoDaddy. Small organizations can register with whoever they wish as a subdomain, or run their own top level if they wish. Charge a flat fee per domain to recover load costs.
And get rid of the annoying certificate system. These days everyone has account management; when I register for an account my browser should supply a random secret; when I login the browser, in addition to credentials, supplies a random number; in the response to the login the site signs the random secret using a second random number and the secret I provided at registration and returns this random number and its signed version in the reply; the browser then validates that I signed into the site I actually registered with. This could ALL be done transparently under the hood and the user would only be notified on mismatch. Secrets could be stolen, but so can login credentials and certificates, and DNS can be hijacked. Such a simple but effective system would get rid of the need for certificate authorities and the entire expensive trust chain. No need to trust anyone other than yourself! And, finally, when a bank or other party wants to send me email they can SIGN IT using the secret I supplied when I registered to prove their authenticity.
And speaking of DNS, fix it so we look up services such as "give me a list of endpoints for the http service of slashdot". Identify the endpoint by address:port AND PROTOCOL/FAMILY. This way it could return phone numbers, snail mail, TCP listeners, or what have you and it's up to the connecting side to find the one best suited. By extension this would permit lookups like "give me a list of services for slashdot". This would greatly simplify many service deployments!
The thing is with cable with 10 people on it, if 9 of them are downloading, fat chance of you checking your email. With ADSL, the backhaul is more than likely far faster than the individual connections added together, so no speed degration for anyone.
DOCSIS 3.0 is very different from ethernet - most importantly it's strictly time multiplexed. And slice allocation is such that you will be able to read your email just fine while your neighbors download and/or upload. There is no collision domain. So while it's "shared" it's not a free-for-all where the one with the most TCP connections wins. Fire up more connections and they just compete for your existing allocation. You're the only one who won't be able to check your email.
The same basic metric applies: the degree to which POP capacity is oversold. DSL is always oversold, and no the link from the CO/POP is not infinite, in fact an entire suburban neighborhood might be on a single 22M link. The main difference is that cable has a whole lot more bandwidth to go around and is less oversold. It also does traffic shaping closer to the customer.
"Kind of"? Clearly the helper app has to do any validation and authentication since it has domain specific knowledge. How would the browser know to confirm, say "do you wish to call 1-900-xxx, this will incur a charge?" or "Upgrade CrapWare from 1.x to 2.3 for $19.99?" All the browser can ask is "really run helper App A?" Which may not mean anything to a user and they have no idea whether they want to or not. The fact that anyone can create a link or content that causes Skype.app to make a call really is a problem with Skype, not the browser...
In the example described in the article, the author overlooks one huge fact -- the treadmill is a source of energy, so assuming that a treadmill in a room with no wind is equivalent to traveling over a road with a wind from behind is fundamentally flawed.
What he really overlooks is the fact that no matter how fast the vehicle moves on a treadmill, the wind will always be faster than the vehicle. This doesn't happen in reality, since eventually the vehicle will catch up with the wind.
it is possible, if what you do is to extract energy from the speed difference between the wind and the ground instead of that between the wind and the vehicle.
Yes, but sails and propellers require airflow and hence derive energy from the air that flows past them. When the propeller moves along at wind speed there is no airflow, and hence no energy to be derived. If the propeller is attached to the vehicle then the relevant base speed is that of the vehicle. The maximum speed will be where the diminished airflow is sufficient to overcome the rolling resistance. If the windmill is separate from the vehicle and energy is provided by some other means, such as a cable, power rail, or catenary, then the vehicle is not limited to wind speed. The latter derives energy from the difference between the wind and ground; the former from the difference between wind and vehicle. What you're suggesting requires a stationary windmill.
A co-worker who is a British expat was royally pissed off when his ageing mother was told to go home and die when she had heart ailments in England when she was nearing 70.
But don't despair, we're going to fix that in the U.S. We're going to tell our seniors to curl up and die as well.
This is a good case against public health services, like the NHS, but not really as meaningful when discussing public insurance. Even the brits are ambivalent about the NHS and its days are probably numbered - that doesn't mean they have any intention to do away with public insurance. Most countries with so-called socialized medicine already have privately run health services. Except for outliers, like research institutions - but these tend to be top notch anyway. Even if your insurance doesn't cover something it doesn't consider essential you can always pay out of pocket if you so wish - even in places with so-called socialized medicine.
By the way, I'm pretty sure even the NHS allows patients to go elsewhere for a second opinion.