Slashdot Mirror
Are Standards Groups Stifling Innovation?
cpfeifer writes "Jim Waldo expresses a a controversial viewpoint in his blog: "Common wisdom, especially in distributed computing, says that the right approach to all problems is to use a standard. This common wisdom has no basis in fact or history, and is curtailing innovation and rewarding bad behavior in our industry. " He also goes on to clarify his position and explain his reasoning."
We have standards for a reason.
Would you like to buy a cd only to find out that it will only work on X cdplayer? or a device that's only able to run if you're with Z electricity company?
Be you Admins? nay, we are but lusers!
I only know of two standards that have ever been of lasting use to me:
0
and
1
Everything else is probably just hype.
Yes standards can be a pain and they can stifle innovation. But there are trade offs. And that is chaos. As much as innovation is a noble goal it has to be traded off with standards.
For example take WiFi. Gee imagine we had ten different WiFi protocols. What would we get? The North American Cellular phone standards where everybody has their own freaken way of doing things.
Yes standards should solve a problem, but standards are required. Imagine everybody deciding by themselves which side of the road to drive on. Or deciding that some people want 40 volts another wants 90 volts, etc.
Why not use defacto standards? Because defacto standards might become out of date standards. This is not to say that they should not be investigated, but if there is a standard that works use it....
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
He's not saying that standards are bad, as much as he's saying that it may be better to take existing useful technology and then standardize it (think SSH and SSL, protocols that were standardized after initial deployment).
In the cases designed by committees, they ended up with something so complicated that nobody has ever implemented it fully (X.509*). In the cases that were implemented and later standardized, deployments with full features are widespread.
(*At first glance, the statements about X.509 seem contradicted by the fact that X.509 is used in SSL. The fact is that SSL stacks use about 1% of the features described in RFC 2459 (X.509v3). This is what I'm talking about: ridiculously overcomplicated committee designs)
Oh this is such a pile of shit. Without standards, the person with the best marketing will become the standard... not the best and most useful system.
Sure standards do slow innovation... but so does the the FDA when they ask for proper testing and years of results before millions of people pop that blue pill. Proper testing and analysis of innovations in technology need to occur before we just plaster them across the network only to find out later how gimped it was to begin with.
This is my sig. There are many like it but this one is mine.
Point two: A standards body is often a lousy place in which to invent a technology
No it's not. Standards are there to get the basics out of the way and move forward. For example, you can focus on inventing a time machine without having to figure out if the screws on your machine will fit the holes in your DMC's dashboard, or calculating the power it'll need in gigowatts, instead of number of power-foos that no-one else uses but the power-supply manufacturer you need that precious device from.
Good standards are good. Period. Bad or hard-to-use standards tend to be replaced by better ones. And standards that once were great (like the imperial system) can also be replaced by even better ones (like the metric system). But at any rate, no standards means no communication and no progress. That's a historical fact. Even the language I use to post this reply is a standard.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Common wisdom [..] says that the right approach to all problems is to use a standard. This common wisdom has no basis in fact or history, and is curtailing innovation and rewarding bad behavior in our industry.
So true. The world would be a much better place without standards...
Man: Hello shopkeeper, I'd like to buy some cheese please.
Shopkeeper: Fine sir. How much do you want?
Man: 500 grams.
Shopkeeper: Sorry sir. We don't use grams here. We use flogborts.
Man: What's a flogbort?
Shopkeeper: It's our own system. Much better than grams. I'll explain..
Man: Don't bother. How many grams to a flogbort?
Shopkeeper: A6NG8
Man: What?
Shopkeeper: Sorry sir, we don't use decimal either. We have our own system. I have a diagram somewhere...
Man: Listen, just give me one dollars worth.
Shopkeeper: A dollars worth? I'm afraid we don't accept dollars...
etc. etc.
Or you can support multiple standards and talk to any client. Nobody ever said that supporting one standard means that you can't support others at the same time.
What the article talks about is a difference between two kinds of standards. Those that codify existing practice (SMTP, IP, ANSI C, HTTP 0.9, most of the early Internet standards I think) and those which attempt to create a new standard from scratch. He doesn't like the second kind.
I think it's similar to the argument that says you shouldn't set a program's design in stone before it is implemented, because until you have a working implementation you can't know what the best design would be (nor indeed what the requirements will become). And I have a lot of sympathy with that.
But while a few years of anarchy followed by a period of standardization can work well in some cases, you can't seriously suggest that in areas where there are big upfront costs to get into the market it is better to let people waste effort thrashing around with a dozen different formats or protocols until one of them wins 'in the marketplace'. (And we all know that 'the marketplace' is often lousy at picking the best technical solution, worse even than standards committees.) Mobile phones are a great example. You need to have an agreed standard before you start manufacturing, not afterwards.
If new standard creation is politically motivated by companies who have a potential new product to promote, so what? That's surely preferable to having no standard at all, launching several new products with incompatible formats or protocols, and then years later trying to document and standardize whichever random one of them seems to be the winner. Case in point: where is the standards document and process for MS Word file format?
-- Ed Avis ed@membled.com
Take a look at the select(2) system call. It seems to serve a useful purpose: it allows a single program thread to wait for activity on multiple network connections at once.
Back when select() was created, a process could only have 32 connections open at a time, maximum. So, the guy who invented the call decided that the caller could use 32-bit integers to represent lists of connections. You just set the bits corresponding to the connection numbers you want to watch and leave the other bits as zero. Then, the system alters the list in-place before it returns to indicate which connections are active.
Well, now adays, a program can have a few more than 32 connections open. However, for standards' sake, select() still uses bit fields. In Linux, these bit fields are something like 8k in size. Since they are altered in place when you call select(), you have to set them up fresh every time you call it. Then, the OS has to scan through them all and set up each connection for waiting. This is *slow*.
Much better methods of waiting on multiple connections have been developed. The best methods involve an event queue. You then tell each connection you want to watch to always place an event on the queue when it receives data. This way, the OS doesn't have to set up every connection all over again every single time you wait for activity. FreeBSD has an interface for this called "kernel queues" which is quite nice. Windows has all sorts of convoluted interfaces for it. Linux only just recently came up with a semi-decent interface called "epoll", but it is rather limited in some ways. In any case, all of these interfaces are different.
Unfortunately, select() has stuck because it is a standard. People use it because it works everywhere. It works everywhere because people use it. However, it is, IMO, one of the worst system calls I've ever soon.
This is why my basic opinion on standards is, "Standards are great as long as they don't suck!"