The problem is while full company names IIRC do have to be unique they often contain spaces, brackets and other mess and are often very different from the companies normal trading name. If you stipped the spaces, brackets etc you would end up with something reasonablly unique but I don't think it would be something most people would want to have as their domain name.
1: achievable data rate is pretty much directly tied to the signal to noise ratio and the ammount of bandwidth you have available. Since there is a limit to how low you can reasonably get the noise to get a higher SNR you either have to increase the effective radiated power of your transmitter or increase the directionality of your receive antenna. 2: RF signal level drops off considerablly with distance. The free space model gives inverse square, the plane earth model gives inverse fourth power. Afaict reality for satellite transmissions is pretty close to free space and reality for terrestrial transmissions is somewhere in between free space and plane earth. 3: RF signal gets much worse if you don't have line of sight to the transmitter.
Fact 1 applies to both terrestrial and sattelite communications and presumablly a power level was found that would not interfere with GPS will delivering acceptable data rates. Fact 2 is far worse for terrestrial communications than satellite communications because with sattelite communications every user and potential victim is at roughly equal distance from the transmitter while with terrestrial some potential victims may be much closer than some users. Fact 3 is also worse for terrestrial because you are far more likely to have line of sight to the sky than you are to have line of sight to a terrestrial transmitter.
The internet is already paid for. Every home user and business pays their ISP, every small ISP pays their upstream, every large ISP pays to run their lines and to peer, etc.
A network is of very limited utility without useful services to connect to.
Yes you pay for your connection to the internet but that money goes to the costs of getting your traffic to/from "the internet"* and the profits of those who provide you with your connection. It DOES not generally** go to those who provide you with useful services through the internet. Instead they ALSO have to pay for their connection to the internet.
So either they run the service out of altruism (can work for small sites but generally doesn't scale well) or they have to find some way of making money off their users. The combination of users liking to get stuff for free and the lack of good micropayment services has made adverts the dominant model for that.
*Specifically the cost of getting it to/from either an ISP that is upstream for both you and the person you are communicating with or to a place where an ISP that is upstream for you peers with an ISP that is upstream for the person you are communicating with. **The exception being if the person providing you with the service is also one of your upstreams.
Its being deployed as dual stack, and where folks have IPv6 only I understand that the providers have 6to4 translation devices.
There are a number of approaches to for an ISP to give people connectivity to servers onf the v4 internet without giving them a public v4 address.
There is conventional IPv4 NAT. This does not require IPv6 at all and frankly it's what I see most ISPs going for. The downside is a need to manage private v4 addresses in the ISP access network (this is especially problematic for massive ISPs like comcast) and runs the risk of address conflicts between the ISP access network and the consumer network. Still frankly this is what I see most ISPs who run out of v4 addresses doing. Some are already doing it (particually mobile ISPs here).
There is NAT64 which translates v6 requests to v4 but protocol translation is generally messy, messing with DNS is required and client devices and applications need to FULLY support IPv6 even if the servers they are talking to are on the v4 internet. Maybe some mobile providers will adopt this but IMO it's the worst of the options i've seen.
There is DS-Lite which combines tunnelling with a special NAT at the ISP that can handle overlapping private networks coming in from different IPv6 IPs. In this setup the customer premisis equiment has to be upgraded to support ds-lite but the ISPs access network can be v6 only and the client devices can use whichever private v4 IPs they like. IMO this is the most elegant soloution.
There are probablly some other options too that I missed.
This will not scale
I don't see why not. There will be costs involved sure but all of the options I mentioned above can be scaled horizontally by sending traffic from different clients to different translation boxes. As I said above some ISPs already run ISP level NAT.
however my point is as a consumer you don't have a need for IPv6 addresses unless there is a service that is only available on IPv6 that you need to reach.
The big issue will be when a user who doesn't have a public IPv4 IP but does have a public IPv6 block wants to accept incoming connections they will only be able to accept them from people who have IPv6 access.
The biggest issue right now is that if you want 100m, you have to increase the minimum packet size at the faster speeds - 64 bytes is barely able to meet it at GigE speeds, nevermind 10G or faster. The thing is, at the faster speeds, you can send out a minimum-sized packet and it'll be completely "on the wire" before the other end gets it
And what makes you think that is a problem? Once CSMA/CD is eliminated it really doesn't matter if packets are "completely on the wire" since they can't collide.
A block is not a "group of 50 BTC", a block is essentially a transaction in a ledger (the blockchain) which updates which accounts (addresses) hold what balances. By working through that ledger you can (and need to) determine the balance that each address has. Participants check blocks for validity so a miner can't generate blocks that don't follow the rules. As a carrot to encourage mining those who generate a block are allowed to award themselves a reward. Currently this reward is 50 BTC
It is possible for blocks to be removed from the blockchain by creating a paralell block chain and "outrunning" the existing branch but to do so you need more hashing power than the rest of the network put together.
Don't, however, mistake that for meaning the 1.47BTC you receive today doesn't come complete with a full transaction history tracing it back through every owner it ever had, all the way back to the single address of the miner who "won" that block.
AIUI you can trace the history of transactions but it's more of a tree than a line. You can't say "this bitcoin came from those found in block X".
Because its adding heat for a part you're not using
Personally I doubt a graphics core that is turned off draws any significant power, particually compared to the massive gulf in performance per watt between intel and AMD at the moment. You could buy a xeon chip where the graphics core is lasered off rather than merely disabling it in software but I doubt it's worth the extra cost to do so.
and sucking up die space?
Meh, what does that matter to me as the user. Yes a slightly smaller die is perhaps a little cheaper to make but we all know price is only loosely tied to cost anyway and it's not like a smaller die means a smaller total area taken up by the processor. The package and heatsink already many times bigger than the die.
If you're going to grab networks that aren't BGP Advertised
Which would be a really stupid idea. Do you think the likes of IBM would renumber their whole internal network. Or do you think it's more likely that people who got allocated addesses from 9/8 would simply be inaccessible to anyone at IBM.
and when are we going to do someting with 240/4? How many proposals have to be unfulfilled to use this resource when the resource is scarce? (I know, it'll take a while for some vendors to support this)
The compability issues prevent them being meaningfully used to expand global v4 space. Use on large private intranets has been proposed but frankly there are only a handful of such networks in the world and making sure everything supports class E addresses sounds only marginally less painful than making sure everything supports IPv6.
More generally I can't help but feel that trying to add a few percent to the public v4 address space is fiddling round the edges that won't really change anything other than perhaps adding a few more months before people have to accept that v4 space is no longer going to be nearly free and easy to get.
Due to the upfront costs and lack of any immediate benefit it has become clear that the orderly transition from v4 only with a public IP per customer to dual stack with a public v4 IP and public v6 block per customer to v6 only is not going to happen and marginally enlarging the address space is not going to change that. The only option left is for growing ISPs to deploy some mechanism* so that their least valuable customers can access resources on the v4 internet while using less than one v4 address per customer. Hopefully most of them will also offer users public v6 IPs but i'm not holding my breath.
* Be it conventional v4 NAT, DS-LITE, NAT64, port range based IP sharing, proxies or whatever.
Serious question: has a RIR ever tried to interfere with the sale of an OLD block (e.g. one they did not themselves allocate) and if so did they succeed?
Hardly any 10 base T systems bother with the CDMA/CD system that original ethernet had
I don't think i've ever seen a 10BASE-T system that didn't use CSMA/CD. Switches were too expensive back then to justify a fully switched network so people used hubs and let the end nodes continue to do collision detection and retry. Also afaict the autonegotiation system needed to automatically disable CSMA/CD didn't come in until 100BASE-T was introduced (it's certainly defined in the 100 megabit section of the spec).
OTOH at higher speeds CSMA/CD is basically gone. While I know 100BASE-T hubs exist i've never actually owned or knowlingly used one. I'm not sure gigabit hubs existed on the market at all (despite being defined in the spec). At 10G and beyond hubs aren't even defined.
WHy not just give it a new name?
Because the change came in gradually. Changing the name now would just serve to confuse people.
Also while modern ethernet networks don't use CSMA/CD much if at all the equipment does generally still support it. You can still take an old peice of equipment with an AUI port, plug a 10BASE-T transceiver into it and plug it into your brand new gigabit switch. The switch will detect the speed, turn on CSMA/CD on the port and things will just work.
AIUI the "ether" in ethernet was an analogy coming from the fact that a shared coax cable has some aspects in common with a radio system.
However while coax ethernet shares some things in common with a radio system there are also big differences that mean running ethernet over radio would NOT be a simple matter of adding amplifiers and antennas.
1: Radio systems have FAR more loss than coax cable systems. In particular this means it is MUCH harder to detect collisions since when you are transmitting your own signal is FAR stronger than anyone elses signal. That is why radio systems have tended to use CSMA/CA rather than CSMA/CD. 2: As well as having more loss radio systems also have highly variable loss so your receiver has to be able to cope with a wide range of signal levels. 3: DC can't be passed over radio. IIRC coax ethernet does use DC for some signalling functions (I belive it uses it for collision detection) 4: It is very difficult to make an antenna that works well with consistent performance over a very wide bandwidth (relative to the center frequency). So it is pretty much essential to modulate radio transmissions onto a carrier with a frequency many times the symbol rate. 5: Multipath can be very strong in indoor radio applications and requires special modulation techniques to deal with
Just because the engineers have pulled two rabbits out of hats and managed to run first 1 and then 10 gigabit over slightly improved versions of cheap twisted pair cable with the 8P8C connectors (though at present afaict the cost of transciever hardware is such that for short 10 gigabit runs you are better off with SFP+ direct attach) doesn't mean they will be able to do it again.
Personally I find the keyboards on my 13 macbook and my 10 inch HP mini to be about the same comfort wise. Mostly because the keyboard on the HP mini goes very very close to the edge of the machine meaning the keyboard size difference isn't actally that great even though the overall machine is quite a lot smaller.
Both of them are masively better than trying to type on the onscreen keyboard of a tablet.
If sourceforge is totally compromised you are right but still the chances of that happening are almost certainly lower than the chances of a random download mirror being compromised, so checking md5s is still a good idea.
Apple usually tries hard to find at least two manufacturers for every single component.
Honestly any hardware designer with a clue tries to minimise use of single source parts. Single source parts can be troublesome pretty much regardless of volume. For small volumes where you buy from stock there is the risk of all the stock of a part suddenly dissapearing with no new batch due for months. For large volumes where you are having parts made to fill your order single source parts gives the part manufacturers more bargining power.
Sadly for ICs there often isn't a lot of choice since there is often no generic part that does what you want.
It's possible if subpixel rendering is working correctly (only works on LCDs and you get the occasional LCD with a reversed subpixel order which screws it up). Subpixel rendering exploits the fact that the eye has far better resoloution for intensity than for color and each pixel on a LCD is made up of three sub-pixels each in a different position (as well as a different color) by treating each subpixel like a pixel therefore effectively tripling the horizontal resolution.
Of course there is no theoretical reason why a subpixel bitmap font couldn't be made.
With raw materials the price does tend towards a cost but the cost it tends towards is the cost of the marginal supply, not the cost of the average supply (and yes this does mean that those who control supplies that are much cheaper to deal with than the marginal supply can get very rich).
No - you use long, cryptographically random, salts to avoid dictionary attacks.
There are basically two types of salt, fixed salts stored in the server configuration and per-password salts stored in the password database. They defend against different things.
Fixed salts stored in the server configuration defend against someone who has got your password DB but not your server configuration. per-password salts stored in the password DB defend against precomputed attacks.
Neither provides a defense against someone who has both your password DB and server configuration and is going after an individual password. That is where deliberately slow hash functions come in.
Users will use weak passwords*, web servers will get compromised.
Ideally you would have a seperate "password checking server" that did nothing but store and check paswords and was locked down very tight but most sites can't really justify the cost of that. So on most sites the password database and any related secrets such as a fixed part of the salt are just one bug in a php webapp away from being revealed to an attacker.
Using a deliberately slow hashing technique will increase the time taken for the hacker to crack passwords in that scenario potentially buying you time to warn your users.
*and if you make rules to try and stop them they will do the minimum needed to comply with those rules.
But do note that at high ratios of committed bandwidth (that is the bandwidth you pay for whether your 95th percentile measure is up there or not) to maximum line bandwidth it's a very gameable system. Max out your line for short periods and keep it near idle the rest of the time and you can have a zero low 95th percentile bandwidth while moving a lot of data. I bet if 95th percentile billing with high ratios of committed bandwidth to line bandwdith was offered to end users you would see a lot of pirate-hoarders doing this sort of gaming.
IMO the real problem is not the measurement of bandwidth, average bandwdith or the equivilent total data transferred (possiblly with a peak/off-peak system) is a reasonable measurement when dealing with end users. The real problem is that there is little competition and little motivation to drop prices.
Slashdot Mirror
The problem is while full company names IIRC do have to be unique they often contain spaces, brackets and other mess and are often very different from the companies normal trading name. If you stipped the spaces, brackets etc you would end up with something reasonablly unique but I don't think it would be something most people would want to have as their domain name.
Lets consider a few facts about RF transmission.
1: achievable data rate is pretty much directly tied to the signal to noise ratio and the ammount of bandwidth you have available. Since there is a limit to how low you can reasonably get the noise to get a higher SNR you either have to increase the effective radiated power of your transmitter or increase the directionality of your receive antenna.
2: RF signal level drops off considerablly with distance. The free space model gives inverse square, the plane earth model gives inverse fourth power. Afaict reality for satellite transmissions is pretty close to free space and reality for terrestrial transmissions is somewhere in between free space and plane earth.
3: RF signal gets much worse if you don't have line of sight to the transmitter.
Fact 1 applies to both terrestrial and sattelite communications and presumablly a power level was found that would not interfere with GPS will delivering acceptable data rates. Fact 2 is far worse for terrestrial communications than satellite communications because with sattelite communications every user and potential victim is at roughly equal distance from the transmitter while with terrestrial some potential victims may be much closer than some users. Fact 3 is also worse for terrestrial because you are far more likely to have line of sight to the sky than you are to have line of sight to a terrestrial transmitter.
The internet is already paid for. Every home user and business pays their ISP, every small ISP pays their upstream, every large ISP pays to run their lines and to peer, etc.
A network is of very limited utility without useful services to connect to.
Yes you pay for your connection to the internet but that money goes to the costs of getting your traffic to/from "the internet"* and the profits of those who provide you with your connection. It DOES not generally** go to those who provide you with useful services through the internet. Instead they ALSO have to pay for their connection to the internet.
So either they run the service out of altruism (can work for small sites but generally doesn't scale well) or they have to find some way of making money off their users. The combination of users liking to get stuff for free and the lack of good micropayment services has made adverts the dominant model for that.
*Specifically the cost of getting it to/from either an ISP that is upstream for both you and the person you are communicating with or to a place where an ISP that is upstream for you peers with an ISP that is upstream for the person you are communicating with.
**The exception being if the person providing you with the service is also one of your upstreams.
Its being deployed as dual stack, and where folks have IPv6 only I understand that the providers have 6to4 translation devices.
There are a number of approaches to for an ISP to give people connectivity to servers onf the v4 internet without giving them a public v4 address.
There is conventional IPv4 NAT. This does not require IPv6 at all and frankly it's what I see most ISPs going for. The downside is a need to manage private v4 addresses in the ISP access network (this is especially problematic for massive ISPs like comcast) and runs the risk of address conflicts between the ISP access network and the consumer network. Still frankly this is what I see most ISPs who run out of v4 addresses doing. Some are already doing it (particually mobile ISPs here).
There is NAT64 which translates v6 requests to v4 but protocol translation is generally messy, messing with DNS is required and client devices and applications need to FULLY support IPv6 even if the servers they are talking to are on the v4 internet. Maybe some mobile providers will adopt this but IMO it's the worst of the options i've seen.
There is DS-Lite which combines tunnelling with a special NAT at the ISP that can handle overlapping private networks coming in from different IPv6 IPs. In this setup the customer premisis equiment has to be upgraded to support ds-lite but the ISPs access network can be v6 only and the client devices can use whichever private v4 IPs they like. IMO this is the most elegant soloution.
There are probablly some other options too that I missed.
This will not scale
I don't see why not. There will be costs involved sure but all of the options I mentioned above can be scaled horizontally by sending traffic from different clients to different translation boxes. As I said above some ISPs already run ISP level NAT.
however my point is as a consumer you don't have a need for IPv6 addresses unless there is a service that is only available on IPv6 that you need to reach.
The big issue will be when a user who doesn't have a public IPv4 IP but does have a public IPv6 block wants to accept incoming connections they will only be able to accept them from people who have IPv6 access.
Of course sadly some ISPs may LIKE it that way :(
The biggest issue right now is that if you want 100m, you have to increase the minimum packet size at the faster speeds - 64 bytes is barely able to meet it at GigE speeds, nevermind 10G or faster. The thing is, at the faster speeds, you can send out a minimum-sized packet and it'll be completely "on the wire" before the other end gets it
And what makes you think that is a problem? Once CSMA/CD is eliminated it really doesn't matter if packets are "completely on the wire" since they can't collide.
it has blocks (groups of 50BTC)
A block is not a "group of 50 BTC", a block is essentially a transaction in a ledger (the blockchain) which updates which accounts (addresses) hold what balances. By working through that ledger you can (and need to) determine the balance that each address has. Participants check blocks for validity so a miner can't generate blocks that don't follow the rules. As a carrot to encourage mining those who generate a block are allowed to award themselves a reward. Currently this reward is 50 BTC
It is possible for blocks to be removed from the blockchain by creating a paralell block chain and "outrunning" the existing branch but to do so you need more hashing power than the rest of the network put together.
Don't, however, mistake that for meaning the 1.47BTC you receive today doesn't come complete with a full transaction history tracing it back through every owner it ever had, all the way back to the single address of the miner who "won" that block.
AIUI you can trace the history of transactions but it's more of a tree than a line. You can't say "this bitcoin came from those found in block X".
As a brit who the education system utterly failed in it's attempts to teach french I resent that comment ;)
i3s dont come with intel 4000 graphics
If you don't want to look stupid it pays to check before making blanket statements. Especially ones as trivial to check up on as this.
http://ark.intel.com/products/65692/Intel-Core-i3-3225-Processor-3M-Cache-3_30-GHz -- desktop i3 with HD 4000 graphics
Because its adding heat for a part you're not using
Personally I doubt a graphics core that is turned off draws any significant power, particually compared to the massive gulf in performance per watt between intel and AMD at the moment. You could buy a xeon chip where the graphics core is lasered off rather than merely disabling it in software but I doubt it's worth the extra cost to do so.
and sucking up die space?
Meh, what does that matter to me as the user. Yes a slightly smaller die is perhaps a little cheaper to make but we all know price is only loosely tied to cost anyway and it's not like a smaller die means a smaller total area taken up by the processor. The package and heatsink already many times bigger than the die.
If you're going to grab networks that aren't BGP Advertised
Which would be a really stupid idea. Do you think the likes of IBM would renumber their whole internal network. Or do you think it's more likely that people who got allocated addesses from 9/8 would simply be inaccessible to anyone at IBM.
and when are we going to do someting with 240/4? How many proposals have to be unfulfilled to use this resource when the resource is scarce? (I know, it'll take a while for some vendors to support this)
The compability issues prevent them being meaningfully used to expand global v4 space. Use on large private intranets has been proposed but frankly there are only a handful of such networks in the world and making sure everything supports class E addresses sounds only marginally less painful than making sure everything supports IPv6.
More generally I can't help but feel that trying to add a few percent to the public v4 address space is fiddling round the edges that won't really change anything other than perhaps adding a few more months before people have to accept that v4 space is no longer going to be nearly free and easy to get.
Due to the upfront costs and lack of any immediate benefit it has become clear that the orderly transition from v4 only with a public IP per customer to dual stack with a public v4 IP and public v6 block per customer to v6 only is not going to happen and marginally enlarging the address space is not going to change that. The only option left is for growing ISPs to deploy some mechanism* so that their least valuable customers can access resources on the v4 internet while using less than one v4 address per customer. Hopefully most of them will also offer users public v6 IPs but i'm not holding my breath.
* Be it conventional v4 NAT, DS-LITE, NAT64, port range based IP sharing, proxies or whatever.
Serious question: has a RIR ever tried to interfere with the sale of an OLD block (e.g. one they did not themselves allocate) and if so did they succeed?
Hardly any 10 base T systems bother with the CDMA/CD system that original ethernet had
I don't think i've ever seen a 10BASE-T system that didn't use CSMA/CD. Switches were too expensive back then to justify a fully switched network so people used hubs and let the end nodes continue to do collision detection and retry. Also afaict the autonegotiation system needed to automatically disable CSMA/CD didn't come in until 100BASE-T was introduced (it's certainly defined in the 100 megabit section of the spec).
OTOH at higher speeds CSMA/CD is basically gone. While I know 100BASE-T hubs exist i've never actually owned or knowlingly used one. I'm not sure gigabit hubs existed on the market at all (despite being defined in the spec). At 10G and beyond hubs aren't even defined.
WHy not just give it a new name?
Because the change came in gradually. Changing the name now would just serve to confuse people.
Also while modern ethernet networks don't use CSMA/CD much if at all the equipment does generally still support it. You can still take an old peice of equipment with an AUI port, plug a 10BASE-T transceiver into it and plug it into your brand new gigabit switch. The switch will detect the speed, turn on CSMA/CD on the port and things will just work.
AIUI the "ether" in ethernet was an analogy coming from the fact that a shared coax cable has some aspects in common with a radio system.
However while coax ethernet shares some things in common with a radio system there are also big differences that mean running ethernet over radio would NOT be a simple matter of adding amplifiers and antennas.
1: Radio systems have FAR more loss than coax cable systems. In particular this means it is MUCH harder to detect collisions since when you are transmitting your own signal is FAR stronger than anyone elses signal. That is why radio systems have tended to use CSMA/CA rather than CSMA/CD.
2: As well as having more loss radio systems also have highly variable loss so your receiver has to be able to cope with a wide range of signal levels.
3: DC can't be passed over radio. IIRC coax ethernet does use DC for some signalling functions (I belive it uses it for collision detection)
4: It is very difficult to make an antenna that works well with consistent performance over a very wide bandwidth (relative to the center frequency). So it is pretty much essential to modulate radio transmissions onto a carrier with a frequency many times the symbol rate.
5: Multipath can be very strong in indoor radio applications and requires special modulation techniques to deal with
Just because the engineers have pulled two rabbits out of hats and managed to run first 1 and then 10 gigabit over slightly improved versions of cheap twisted pair cable with the 8P8C connectors (though at present afaict the cost of transciever hardware is such that for short 10 gigabit runs you are better off with SFP+ direct attach) doesn't mean they will be able to do it again.
Personally I find the keyboards on my 13 macbook and my 10 inch HP mini to be about the same comfort wise. Mostly because the keyboard on the HP mini goes very very close to the edge of the machine meaning the keyboard size difference isn't actally that great even though the overall machine is quite a lot smaller.
Both of them are masively better than trying to type on the onscreen keyboard of a tablet.
Forcing updates is bad enough
Dropping features is bad enough
Combining the two is horrible behaviour
If sourceforge is totally compromised you are right but still the chances of that happening are almost certainly lower than the chances of a random download mirror being compromised, so checking md5s is still a good idea.
Apple usually tries hard to find at least two manufacturers for every single component.
Honestly any hardware designer with a clue tries to minimise use of single source parts. Single source parts can be troublesome pretty much regardless of volume. For small volumes where you buy from stock there is the risk of all the stock of a part suddenly dissapearing with no new batch due for months. For large volumes where you are having parts made to fill your order single source parts gives the part manufacturers more bargining power.
Sadly for ICs there often isn't a lot of choice since there is often no generic part that does what you want.
It's possible if subpixel rendering is working correctly (only works on LCDs and you get the occasional LCD with a reversed subpixel order which screws it up). Subpixel rendering exploits the fact that the eye has far better resoloution for intensity than for color and each pixel on a LCD is made up of three sub-pixels each in a different position (as well as a different color) by treating each subpixel like a pixel therefore effectively tripling the horizontal resolution.
Of course there is no theoretical reason why a subpixel bitmap font couldn't be made.
With raw materials the price does tend towards a cost but the cost it tends towards is the cost of the marginal supply, not the cost of the average supply (and yes this does mean that those who control supplies that are much cheaper to deal with than the marginal supply can get very rich).
No - you use long, cryptographically random, salts to avoid dictionary attacks.
There are basically two types of salt, fixed salts stored in the server configuration and per-password salts stored in the password database. They defend against different things.
Fixed salts stored in the server configuration defend against someone who has got your password DB but not your server configuration.
per-password salts stored in the password DB defend against precomputed attacks.
Neither provides a defense against someone who has both your password DB and server configuration and is going after an individual password. That is where deliberately slow hash functions come in.
Users will use weak passwords*, web servers will get compromised.
Ideally you would have a seperate "password checking server" that did nothing but store and check paswords and was locked down very tight but most sites can't really justify the cost of that. So on most sites the password database and any related secrets such as a fixed part of the salt are just one bug in a php webapp away from being revealed to an attacker.
Using a deliberately slow hashing technique will increase the time taken for the hacker to crack passwords in that scenario potentially buying you time to warn your users.
*and if you make rules to try and stop them they will do the minimum needed to comply with those rules.
I doubt this will help against spike strips. It sounds more designed for gradual re-inflation.
IIRC they make run on flat tyres designed for use where the ability to escape quickly in the event of a deliberately punctured tyre is needed.
They have.
Afaict the standard is 95th percentile, not 90th.
But do note that at high ratios of committed bandwidth (that is the bandwidth you pay for whether your 95th percentile measure is up there or not) to maximum line bandwidth it's a very gameable system. Max out your line for short periods and keep it near idle the rest of the time and you can have a zero low 95th percentile bandwidth while moving a lot of data. I bet if 95th percentile billing with high ratios of committed bandwidth to line bandwdith was offered to end users you would see a lot of pirate-hoarders doing this sort of gaming.
IMO the real problem is not the measurement of bandwidth, average bandwdith or the equivilent total data transferred (possiblly with a peak/off-peak system) is a reasonable measurement when dealing with end users. The real problem is that there is little competition and little motivation to drop prices.