Looking around my office most people sit about 20" from their monitor but hold a smartphone 12" away from their face. With 20:20 vision are humans able to see 326ppi at 20"? I would guess not.
No. The limit of human visual resolution is approximately 1 arc-minute. At a distance of 20", this equates to about 0.006", or approximately 172dpi. Which is still nearlt 50% higher than the 120dpi of the highest resolution monitor I see in a quick web search.
(Note you also cannot resolve 326dpi at 12" - 286dpi is about the highest you can resolve at that distance. You'd have to hold your iPhone 4 at just 10.5" in order to be able to see all of its pixels.)
You do know that having a TV does not mean you have to pay for a licence, don't you? A licence is required for *the act of receiving live broadcast TV*.
You can turn off transaction isolation and cram serialized record data into a single BLOB field, and you will get the same thing right?
Not really. Schemaless databases provide indexing and search capabilities that are impossible to achieve using SQL blobs without either loading all your data back into memory whenever you want to search for something or providing your own index mechanism.
Or, use a freaking filesystem?
Which as well as lacking indexing and search as the SQL-based system would, also does not provide any useful mechanism for concurrent updates, or for ensuring consistency (whether eventual or guaranteed at all times). It would also probably be much slower.
Why do they keep patting themselves on the shoulder over performance of particular implementation that is due to lack of features and safety, and comparing it to relational databases in general as if it was somehow superior? Apples and oranges.
They don't. You're misreading the articles because you haven't spotted the context: people are using oranges and complaining that the cider they're ending up with just doesn't taste right. I.e., a lot of people are using SQL databases for tasks for which one of the various NoSQL systems would be better suited simply because they don't realise there's a better tool for them. These people need to see comparisons between SQL & the NoSQL systems that are available in order to realise this.
SQL as a performance bottleneck? Having to escape certain characters? mysql_real_escape_string()? They probably never heard of bound parameters and prepared statements.
My experience is that SQL isn't so much the bottleneck (although it is slow, even with prepared statements) as object-relational mapping. And yes, my application does need some form of ORM (whether handbuilt or using an off-the-shelf library) because I'm working with many types of polymorphic object in single collections. Schemaless databases make this much, much simpler, as they remove the need for large numbers of table joins to make a deep inheritance heirarchy work.
I don't think anybody is claiming NoSQL is new. Many NoSQL products are just incremental improvements over old-style object-oriented databases, after all.
All that is new is the concerted push to point out to people that RDBMSs and SQL shouldn't necessarily bethe automatic solution to every problem. They're extremely good at certain tasks, perhaps even for a large majority of tasks, but there are some instances where they are not the best tool for the job. The NoSQL people just want to make sure we all consider this when choosing the tech for out next projects, and perhaps evaluate whether one of their systems is better for us than the SQL system we'd otherwise automatically default to.
My suspicion: it's less about the type of music and more about the type of task. The tasks you describe are ones where "flow" is known to be particularly useful, and music is known to help get you into flow. Complex analytical tasks, however, are not generally helped by flow (to use the criteria for obtaining flow as described by Csíkszentmihályi such a task lacks clear goals and immediate feedback, two of the most important requirements, and is in most cases at a challenge level slightly beyond typical flow tasks).
Hell, Ubuntu will even suggest to install the proprietary AMD/nVidia drivers automagically for you.
Which is exactly where it screwed up my latest install -- it set up the proprietary drivers for my Broadcom wireless, and they didn't work (compatibility issues with another module in the kernel needed to support my wired network card, AFAICT). Uninstall the proprietary drivers and use the open source ones and everything was fine.
There are a couple of chinese companies that make wrist phones, e.g. this one. No idea how well they work, but I've always thought they looked like a cool idea.
Tubes naturally have electric "mass" that has to be "moved" by the changing signal strength, smoothing out the raw digitial samples into a proper analogue curve.
You can say exactly the same thing for a capacitor, and they're much cheaper, less fragile, and get to their operating point much more quickly when the circuit is switched on.
A lot of ISPs set the target signal-to-noise ratio too low, telling the hardware to try to run the line too fast, in an attempt to boost their "average line speed" stats. Line quality varies according to how many other lines in the same bundle are in use, so while you may have a signal-to-noise ratio that's fine at offpeak times, you may be getting too many errors at peak and losing packets. Ask your ISP to increase your target SNR. I had a similar problem to you, and went from a target SNR of 3dB up to 6dB. I lost about 200kb off my peak throughput, but I get it pretty much constantly now.
Of course, it is not a replacement for DB in general, but that's precisely the point - a lot of use cases don't need a DB - they don't need concurrency etc, and they're dealing with at most a thousand records, not millions.
With 64-bit systems with 16GB of memory now retailing for under £500, even millions of records can now be handled in memory with ease.
SQLite does use types -- it just doesn't use typed columns. Each entry has a type associated, so it can determine what algorithm to use for the comparison when it pulls the row in from disk.
hmm, to use a NoSQL to avoid JOIN? A RDBMS can be designed to avoid joins easily with flat tables or text columns. So far, the only values I see from noSQL solutions is to sacrifice ACID for horizontal scalability to fit the user scenarios where ACID is not that critical. Everything else can be covered by RDBMS easily.
Relationships from data item A to data item B where the type of item B is not known in advance. RDBMSs suck at handling this.
I just can't think of a specific case in which I have data structured enough to be in a database, but unstructured enough to never have joins, schemas, or the rest of the RDB trappings. But it may just be that I've not encountered any yet.
Consider graph structured data, where you access it by following labelled edges in a graph, and where nodes have attributes. Different node types have different attribute sets, but edges with a particular label may point to nodes with varying types in different circumstances. This is a rather loose structure, but structured enough that a database store for it is a good idea. It is also rather hard to model with relations and joins (it *can* be done, and there are software packages out there that attempt to do it automatically, but performance is generally considered suboptimal). If your data matches this description, a NoSQL db is possibly better for you than trying to force your data to conform to a more relational model.
The downside of using this kind of database structure, though, is that operations that work on your data in bulk become much harder. If an edge with a particular label can't be relied on to point to particular type of node, querying based on its values may fail. Because you can't load the data in bulk and perform a join, operations on large subsets of your database are slower. If you need to perform bulk operations, SQL is much better than this kind of database.
It's all tradeoffs.
(By the way, in case you're struggling to think of data that fits the model I described above, consider a typical object-oriented program. Fields in your objects become attributes at nodes, pointers between objects edges in the graph. Some pointers may be polymorphic, i.e. you may have multiple subclasses of the type of pointer.)
This is pretty easy to answer, I think: because databases offer ACID attributes. Reimplementing those on your own is a big project and likely to create bugs; it's a lot easier to just grab an existing database and use it.
ACID is actually pretty simple as long as you can serialize transactions and lock individual objects while accessing them. This is actually possible for most applications that aren't large enough to require a distributed system (which is to say, it'd probably work for 90% of all systems that get built).
The classic example is invoice, lineitem. Do you keep a total in invoice or total up lineitem every time. Do you keep the price in Line Item or do you join to Inventory with ItemId and date? How do you handle special pricing? It gets complicated real fast if your dealing with someone who normalizes religiously.
Whereas not normalizing tends to lead to bugs. I've worked on a system that keeps total in invoice (or rather in a basket which was converted to an invoice by the checkout procedure) which had a flaw where if you submitted a new item to the basket and hit the 'checkout' button at the same time you could get that last item without paying for it about 10% of the time. Just because the original developer thought keeping a total price in the basket would be simpler than adding it up every time it was needed.
Price in line item, however, makes a little more sense -- keeping a history of price changes is a little excessive for something that really doesn't need to be tied back to its source like that. Special pricing, however, should be handled with a normal line item with the price copied directly from the product followed by an extra line item showing discount. You get better reporting that way.
SQL is nothing like COBOL. Once again they show how they are clueless rookies.
They are alike in a sense: both of them are designed on the misguided notion that making code read like a natural language makes it easier to work with. Both of them became entrenched simply because they were the first 'good enough' implementation of their respective ideas. Both of them are extremely hard to completely replace.
I think you're missing the point. So here's an illustration of what I think GP is talking about. I want to write a query. I type: "SELECT ". Now I want a column name. The environment is unable to complete at this point because it doesn't know what table/join I'll be selecting from.
If SQL syntax were the more natural FROM [join description] SELECT [projection] WHERE [selection] this problem wouldn't arrise. You could also then leave the projection section as optional, allowing queries like 'FROM contacts WHERE id=5' rather than the frankly bizarre 'SELECT *' syntax SQL forces you to use. The data source is both the most important thing and the only thing that is always required, so putting it at the top of the query makes most sense.
There should be no NULLs Then how do I, say, indicate the date of death for someone who hasn't died? An IsDead field? Really? (Yes, a NULL in a field is a shortcut for proper relationship, but a lack of relationship when using a linking table will still be represented by NULL)
By storing the data in a separate relation and not having a row present if the data isn't present. This is how the relational model is supposed to work, the use of null to represent missing data is a variation from the formal and valid mathematical model that the GGP post was praising and suggesting that as SQL implemented it perfectly we didn't need any other database interface. He was wrong.
there should be no possibility of having duplicate rows Firstly, get to know your DISTINCT SQL keyword.
The fact that SQL provides a means to allow you to force your data to be relational is no justification for the fact that by default it produces non-relational output to some queries. Again this is a deviation from the proven-valid mathematical that the GGP post was praising, etc.
Secondly, data in real life sometimes IS duplicate. What the hell should people do? Have a DuplicatedThisManyTimes field? Ugh.
If you have duplicates, your data is not in a normalised relational model. Data in a relation says "the values in these columns are related to each other in this specific way". This person has this phone number. This patient has an appointment to see this doctor at this date+time. The structure of those sentences is part of the formal definition of what a relation is. It has semantic implications, and one of those implications is that *duplicated rows are meaningless*.
If you have duplicated data and you actually need it, you're missing some important piece of information because those two rows must actually be talking about two different things. There's a column missing from your relation.
There's absolutely no reason to change SQL, because if you build a new query language that is based on the same mathematically sound principles of relational algebra then it will er... look just like SQL.
Actually, no it wouldn't. First of all, there's an assumption you're making here which is unwarranted: why do we need a query _language_ at all? A query API would remove a rather large class of serious bug: data quoting errors, typically leading to either SQL injection vulnerabilities, data corruption (ever see a site with all the 's turned to \'?) or both. It would also be more intuitive to new developers, better integrated with tools (autocomplete in language IDEs, etc), and more efficient (removing the need for text parsing).
Secondly, SQL is actually based on some rather horrible abuses of relational calculus that make most theoreticians in the field cringe. Including Christopher Date and Hugh Darwen, two of the original designers of SQL. You should check out their manifesto for a relational database system not based on SQL. Among other things, they think SQL screwed up handling nulls, and that 'group by' and 'having' are a violation of relational principles that lead to inefficient queries.
The advantage of most SQL/RDBMS is that they do adhere to the ACID principles
Which is also their disadvantage. ACID is brilliant, and I agree that it should be the default starting position. But it has terrible performance implications, and when we're dealing with large quantities of data where it doesn't matter if (say) a small random selection of recent changes are lost in event of a system failure, or if different clients see an inconsistent view of what changes have happened, you can do an awful lot better performance-wise. Which is where CouchDB and their ilk come in. You just need to be sure, before starting down that route, that you really do have one of the minority of problems for which sacrificing that degree of reliability makes sense.
Which is why I'm laughing at this article. There shouldn't be any case where you migrate from couchdb to mysql. You should only ever be using couchdb in the first place if you're sure SQL can't handle what you're trying to do.
(That and the fact that putting non-relational data in an SQL field is a newbie error that I made about 15 years ago and have already learned the lessons of...)
Here in the USA we have the biggest and most offensive example of not everyone being equal before the law — Disenfranchisement of Felons.
We have that in the UK, too. Even though the European Court of Human Rights has instructed us that it is a breach of the criminals' right to regular free and fair elections, and that we must allow them to vote, they still are not allowed to.
The difference is that in the US the orders are, I'm led to believe, almost always very specific. They identify a particular person you can't approach, or a very small area you aren't allowed to enter. ASBOs in the UK quite frequently relate to very large areas, may prevent activities such as approaching anybody on the street, or wearing specific types of clothes in public (yes, this has happened). They are granted by magistrates (== justices of the peace in US terminology) rather than proper judges, for the purposes of preventing behaviour that the general public may find distasteful or annoying. US restraining orders are to protect a specific individual, and AFAIK require a proper judge to issue them.
And you're probably in the majority doing this. But there is a significant minority that becomes uninhibited, speeds up, and drives more aggressively. People driving on race tracks report better performance after drinking, because they take more risks. Some people treat the road exactly the same as they would a race track, which is why drunk driving laws are required. Yes, for the majority of people in any study, being intoxicated is only a little dangerous. There are a minority (and it's based on personality type, and quite hard for any study to correct for because it's a personality type that doesn't as a rule like being studied) who are dangerously different.
To be fair, this isn't exactly the first/. article discussing bufferbloat, so presumably both submitter and editor assumed we already knew what it was.
Slashdot Mirror
Looking around my office most people sit about 20" from their monitor but hold a smartphone 12" away from their face. With 20:20 vision are humans able to see 326ppi at 20"? I would guess not.
No. The limit of human visual resolution is approximately 1 arc-minute. At a distance of 20", this equates to about 0.006", or approximately 172dpi. Which is still nearlt 50% higher than the 120dpi of the highest resolution monitor I see in a quick web search.
(Note you also cannot resolve 326dpi at 12" - 286dpi is about the highest you can resolve at that distance. You'd have to hold your iPhone 4 at just 10.5" in order to be able to see all of its pixels.)
You do know that having a TV does not mean you have to pay for a licence, don't you? A licence is required for *the act of receiving live broadcast TV*.
You can turn off transaction isolation and cram serialized record data into a single BLOB field, and you will get the same thing right?
Not really. Schemaless databases provide indexing and search capabilities that are impossible to achieve using SQL blobs without either loading all your data back into memory whenever you want to search for something or providing your own index mechanism.
Or, use a freaking filesystem?
Which as well as lacking indexing and search as the SQL-based system would, also does not provide any useful mechanism for concurrent updates, or for ensuring consistency (whether eventual or guaranteed at all times). It would also probably be much slower.
Why do they keep patting themselves on the shoulder over performance of particular implementation that is due to lack of features and safety, and comparing it to relational databases in general as if it was somehow superior? Apples and oranges.
They don't. You're misreading the articles because you haven't spotted the context: people are using oranges and complaining that the cider they're ending up with just doesn't taste right. I.e., a lot of people are using SQL databases for tasks for which one of the various NoSQL systems would be better suited simply because they don't realise there's a better tool for them. These people need to see comparisons between SQL & the NoSQL systems that are available in order to realise this.
SQL as a performance bottleneck? Having to escape certain characters? mysql_real_escape_string()? They probably never heard of bound parameters and prepared statements.
My experience is that SQL isn't so much the bottleneck (although it is slow, even with prepared statements) as object-relational mapping. And yes, my application does need some form of ORM (whether handbuilt or using an off-the-shelf library) because I'm working with many types of polymorphic object in single collections. Schemaless databases make this much, much simpler, as they remove the need for large numbers of table joins to make a deep inheritance heirarchy work.
I don't think anybody is claiming NoSQL is new. Many NoSQL products are just incremental improvements over old-style object-oriented databases, after all.
All that is new is the concerted push to point out to people that RDBMSs and SQL shouldn't necessarily bethe automatic solution to every problem. They're extremely good at certain tasks, perhaps even for a large majority of tasks, but there are some instances where they are not the best tool for the job. The NoSQL people just want to make sure we all consider this when choosing the tech for out next projects, and perhaps evaluate whether one of their systems is better for us than the SQL system we'd otherwise automatically default to.
My suspicion: it's less about the type of music and more about the type of task. The tasks you describe are ones where "flow" is known to be particularly useful, and music is known to help get you into flow. Complex analytical tasks, however, are not generally helped by flow (to use the criteria for obtaining flow as described by Csíkszentmihályi such a task lacks clear goals and immediate feedback, two of the most important requirements, and is in most cases at a challenge level slightly beyond typical flow tasks).
Hell, Ubuntu will even suggest to install the proprietary AMD/nVidia drivers automagically for you.
Which is exactly where it screwed up my latest install -- it set up the proprietary drivers for my Broadcom wireless, and they didn't work (compatibility issues with another module in the kernel needed to support my wired network card, AFAICT). Uninstall the proprietary drivers and use the open source ones and everything was fine.
There are a couple of chinese companies that make wrist phones, e.g. this one. No idea how well they work, but I've always thought they looked like a cool idea.
Tubes naturally have electric "mass" that has to be "moved" by the changing signal strength, smoothing out the raw digitial samples into a proper analogue curve.
You can say exactly the same thing for a capacitor, and they're much cheaper, less fragile, and get to their operating point much more quickly when the circuit is switched on.
A lot of ISPs set the target signal-to-noise ratio too low, telling the hardware to try to run the line too fast, in an attempt to boost their "average line speed" stats. Line quality varies according to how many other lines in the same bundle are in use, so while you may have a signal-to-noise ratio that's fine at offpeak times, you may be getting too many errors at peak and losing packets. Ask your ISP to increase your target SNR. I had a similar problem to you, and went from a target SNR of 3dB up to 6dB. I lost about 200kb off my peak throughput, but I get it pretty much constantly now.
Of course, it is not a replacement for DB in general, but that's precisely the point - a lot of use cases don't need a DB - they don't need concurrency etc, and they're dealing with at most a thousand records, not millions.
With 64-bit systems with 16GB of memory now retailing for under £500, even millions of records can now be handled in memory with ease.
SQLite does use types -- it just doesn't use typed columns. Each entry has a type associated, so it can determine what algorithm to use for the comparison when it pulls the row in from disk.
hmm, to use a NoSQL to avoid JOIN? A RDBMS can be designed to avoid joins easily with flat tables or text columns. So far, the only values I see from noSQL solutions is to sacrifice ACID for horizontal scalability to fit the user scenarios where ACID is not that critical. Everything else can be covered by RDBMS easily.
Relationships from data item A to data item B where the type of item B is not known in advance. RDBMSs suck at handling this.
I just can't think of a specific case in which I have data structured enough to be in a database, but unstructured enough to never have joins, schemas, or the rest of the RDB trappings. But it may just be that I've not encountered any yet.
Consider graph structured data, where you access it by following labelled edges in a graph, and where nodes have attributes. Different node types have different attribute sets, but edges with a particular label may point to nodes with varying types in different circumstances. This is a rather loose structure, but structured enough that a database store for it is a good idea. It is also rather hard to model with relations and joins (it *can* be done, and there are software packages out there that attempt to do it automatically, but performance is generally considered suboptimal). If your data matches this description, a NoSQL db is possibly better for you than trying to force your data to conform to a more relational model.
The downside of using this kind of database structure, though, is that operations that work on your data in bulk become much harder. If an edge with a particular label can't be relied on to point to particular type of node, querying based on its values may fail. Because you can't load the data in bulk and perform a join, operations on large subsets of your database are slower. If you need to perform bulk operations, SQL is much better than this kind of database.
It's all tradeoffs.
(By the way, in case you're struggling to think of data that fits the model I described above, consider a typical object-oriented program. Fields in your objects become attributes at nodes, pointers between objects edges in the graph. Some pointers may be polymorphic, i.e. you may have multiple subclasses of the type of pointer.)
This is pretty easy to answer, I think: because databases offer ACID attributes. Reimplementing those on your own is a big project and likely to create bugs; it's a lot easier to just grab an existing database and use it.
ACID is actually pretty simple as long as you can serialize transactions and lock individual objects while accessing them. This is actually possible for most applications that aren't large enough to require a distributed system (which is to say, it'd probably work for 90% of all systems that get built).
I'm working with one that shill remain nameless but sounds oddly like a piece of fruit right now.
I think that description matches about half of them, doesn't it? What it is with these "next big thing" techs and strange names?
The classic example is invoice, lineitem. Do you keep a total in invoice or total up lineitem every time. Do you keep the price in Line Item or do you join to Inventory with ItemId and date? How do you handle special pricing? It gets complicated real fast if your dealing with someone who normalizes religiously.
Whereas not normalizing tends to lead to bugs. I've worked on a system that keeps total in invoice (or rather in a basket which was converted to an invoice by the checkout procedure) which had a flaw where if you submitted a new item to the basket and hit the 'checkout' button at the same time you could get that last item without paying for it about 10% of the time. Just because the original developer thought keeping a total price in the basket would be simpler than adding it up every time it was needed.
Price in line item, however, makes a little more sense -- keeping a history of price changes is a little excessive for something that really doesn't need to be tied back to its source like that. Special pricing, however, should be handled with a normal line item with the price copied directly from the product followed by an extra line item showing discount. You get better reporting that way.
SQL is nothing like COBOL. Once again they show how they are clueless rookies.
They are alike in a sense: both of them are designed on the misguided notion that making code read like a natural language makes it easier to work with. Both of them became entrenched simply because they were the first 'good enough' implementation of their respective ideas. Both of them are extremely hard to completely replace.
I think you're missing the point. So here's an illustration of what I think GP is talking about. I want to write a query. I type: "SELECT ". Now I want a column name. The environment is unable to complete at this point because it doesn't know what table/join I'll be selecting from.
If SQL syntax were the more natural FROM [join description] SELECT [projection] WHERE [selection] this problem wouldn't arrise. You could also then leave the projection section as optional, allowing queries like 'FROM contacts WHERE id=5' rather than the frankly bizarre 'SELECT *' syntax SQL forces you to use. The data source is both the most important thing and the only thing that is always required, so putting it at the top of the query makes most sense.
There should be no NULLs
Then how do I, say, indicate the date of death for someone who hasn't died? An IsDead field? Really? (Yes, a NULL in a field is a shortcut for proper relationship, but a lack of relationship when using a linking table will still be represented by NULL)
By storing the data in a separate relation and not having a row present if the data isn't present. This is how the relational model is supposed to work, the use of null to represent missing data is a variation from the formal and valid mathematical model that the GGP post was praising and suggesting that as SQL implemented it perfectly we didn't need any other database interface. He was wrong.
there should be no possibility of having duplicate rows
Firstly, get to know your DISTINCT SQL keyword.
The fact that SQL provides a means to allow you to force your data to be relational is no justification for the fact that by default it produces non-relational output to some queries. Again this is a deviation from the proven-valid mathematical that the GGP post was praising, etc.
Secondly, data in real life sometimes IS duplicate. What the hell should people do? Have a DuplicatedThisManyTimes field? Ugh.
If you have duplicates, your data is not in a normalised relational model. Data in a relation says "the values in these columns are related to each other in this specific way". This person has this phone number. This patient has an appointment to see this doctor at this date+time. The structure of those sentences is part of the formal definition of what a relation is. It has semantic implications, and one of those implications is that *duplicated rows are meaningless*.
If you have duplicated data and you actually need it, you're missing some important piece of information because those two rows must actually be talking about two different things. There's a column missing from your relation.
There's absolutely no reason to change SQL, because if you build a new query language that is based on the same mathematically sound principles of relational algebra then it will er... look just like SQL.
Actually, no it wouldn't. First of all, there's an assumption you're making here which is unwarranted: why do we need a query _language_ at all? A query API would remove a rather large class of serious bug: data quoting errors, typically leading to either SQL injection vulnerabilities, data corruption (ever see a site with all the 's turned to \'?) or both. It would also be more intuitive to new developers, better integrated with tools (autocomplete in language IDEs, etc), and more efficient (removing the need for text parsing).
Secondly, SQL is actually based on some rather horrible abuses of relational calculus that make most theoreticians in the field cringe. Including Christopher Date and Hugh Darwen, two of the original designers of SQL. You should check out their manifesto for a relational database system not based on SQL. Among other things, they think SQL screwed up handling nulls, and that 'group by' and 'having' are a violation of relational principles that lead to inefficient queries.
The advantage of most SQL/RDBMS is that they do adhere to the ACID principles
Which is also their disadvantage. ACID is brilliant, and I agree that it should be the default starting position. But it has terrible performance implications, and when we're dealing with large quantities of data where it doesn't matter if (say) a small random selection of recent changes are lost in event of a system failure, or if different clients see an inconsistent view of what changes have happened, you can do an awful lot better performance-wise. Which is where CouchDB and their ilk come in. You just need to be sure, before starting down that route, that you really do have one of the minority of problems for which sacrificing that degree of reliability makes sense.
Which is why I'm laughing at this article. There shouldn't be any case where you migrate from couchdb to mysql. You should only ever be using couchdb in the first place if you're sure SQL can't handle what you're trying to do.
(That and the fact that putting non-relational data in an SQL field is a newbie error that I made about 15 years ago and have already learned the lessons of...)
Suspected by idiots... important distinction.
When you only have idiots available to make the decisions, it's an irrelevant distinction.
Here in the USA we have the biggest and most offensive example of not everyone being equal before the law — Disenfranchisement of Felons.
We have that in the UK, too. Even though the European Court of Human Rights has instructed us that it is a breach of the criminals' right to regular free and fair elections, and that we must allow them to vote, they still are not allowed to.
The difference is that in the US the orders are, I'm led to believe, almost always very specific. They identify a particular person you can't approach, or a very small area you aren't allowed to enter. ASBOs in the UK quite frequently relate to very large areas, may prevent activities such as approaching anybody on the street, or wearing specific types of clothes in public (yes, this has happened). They are granted by magistrates (== justices of the peace in US terminology) rather than proper judges, for the purposes of preventing behaviour that the general public may find distasteful or annoying. US restraining orders are to protect a specific individual, and AFAIK require a proper judge to issue them.
And you're probably in the majority doing this. But there is a significant minority that becomes uninhibited, speeds up, and drives more aggressively. People driving on race tracks report better performance after drinking, because they take more risks. Some people treat the road exactly the same as they would a race track, which is why drunk driving laws are required. Yes, for the majority of people in any study, being intoxicated is only a little dangerous. There are a minority (and it's based on personality type, and quite hard for any study to correct for because it's a personality type that doesn't as a rule like being studied) who are dangerously different.
To be fair, this isn't exactly the first /. article discussing bufferbloat, so presumably both submitter and editor assumed we already knew what it was.