Key here is, HTML5 was supposed to at least partially break Adobe's stranglehold on the web by moving some content away from Flash
And put it in the hands of a far more pernicious "evil empire" than Adobe has ever hoped or pretended to be? H.264 is evil. What patents does Adobe claim on Flash? Adobe allows other implementations on a royalty free basis. Do they have any basis to do otherwise? Last, but certainly not least, Adobe doesn't come close to the audacity of requiring royalties on all Flash distributed content. If they did, Flash would be dead in the water.
Do you think any web advertiser in the world would pay royalties for Flash ads, for example. Hardly - they would switch to a royalty free alternative (as simple as static images) overnight.
WebM/VP8 will force a non-accelerated CPU-only rendering path on ALL existing hardware
So what? Tomorrow this will change. The future of the open Internet is of somewhat more consequence than battery usage over the next thirty six months, especially considering we are talking about a HTML tag for which support isn't yet widely deployed in the first place.
If battery usage is such a consideration, just stick with "evil empire" codecs like H.264 and pseudo standards like Flash in the interim. As has been mentioned elsewhere, all the DRM people apparently need to stick with something like Flash indefinitely, so there is nothing stopping paid video distributors like NetFlix from sticking with H.264.
It is the H.264 uber alles movement that is the enemy of the Internet as we know it. On a limited basis in proprietary sandboxes, it is just fine.
the US government should claim eminent domain on all patents involving the h.264 technology, and then dare the large companies to make a move. After all, we're the ones with the guns.
There is the pesky little constitutional provision about "no taking of private property without just compensation". So if the U.S. wants to spend somewhere between a hundred million and a billion dollars repossessing the H.264 patents, fine.
It would be far better, however, to quit the enormously counterproductive practice of granting patents (in most cases) in the first place. Patents are evil, on occasion a necessary evil perhaps, but certainly an enemy to openness, competition, and economic progress everywhere.
No software patents, apparently. Is USB support in the Linux kernel patent encumbered? Is Intel or any other USB Implementers Forum member threatening to sue?
Hardware patents, while perhaps counterproductive, are a much less serious threat to open standards than software patents are. For one thing, they tend to be orders of magnitude less vague. For another, hardware cannot economically be distributed for free. Third, the entire structure of the open Internet does not depend on whether people can produce and use something like USB without royalties. If USB required computer users to pay royalties on anything they produced with a USB device, it would be dead in the water.
H.264 would be much more viable if the MPEG-LA made an unconditional, non-expiring license grant to open source software implementations, and dropped the ridiculous idea of requiring royalties of any kind on content distribution. As it is H.264 is more like an "evil empire" standard than anything I have ever seen.
that is not enough to convince anyone to support the video tag, when they can simply keep using h.264 in Flash players which will cover 99.9% of all browsers hitting them.
If they are stuck on H.264 for whatever reason, that is exactly what they should do - rely on a proprietary codec for a proprietary plugin. There is no reason why an "evil empire" codec like H.264 has some sort of natural right to rule the open Internet. To borrow an expression, the Internet views royalties as censorship and routes around them.
IE9 hasn't been released yet, and won't run on a majority of Windows boxes for years to come. So you could say, yes Internet Explorer supports H.264, it just requires a commercial plugin called Windows 7.
They are just not columns in the relational database sense.
They are not columns _even_ in the sense that column oriented databases use. They are repeating groups. What column oriented databases call "columns" have a perfect logical correspondence with what relational databases call columns. Nothing about the relational model dictates either row or column orientation, so far as storage is concerned.
The logical and physical structure of a Cassandra row has been used in some databases (Adabas, Pick, etc) for thirty or forty years. In fact others (such as Oracle and DB2) can implement the logical model of a relational database on the same physical model as that used by repeating group databases like Cassandra, getting the best of both worlds.
The end game for contemporary NoSQL databases is to evolve step by step in the direction of distributed, shared nothing relational databases with some special purpose relaxations. Secondary indexes? We have that. Transactions? We have that too! And so on...
The only problem with Cassandra is that the designer seem to have ignored everything written about database implementation in the past fifty years. Either that or have a severe case of the not-invented-here syndrome. Why use standard nomenclature when we can make up one maximally designed to confuse everyone and everybody?
Non-relational databases that do this have been around for decades. Adabas and Pick are the examples that come to mind. The pertinent difference here is that the developers of those databases were sane enough not to call repeating groups "columns".
Cassandra, HBase and BigTable aren't traditionally what is meant by the term href="http://en.wikipedia.org/wiki/Column-oriented_DBMS">column store database at all. Much closer to hybrid "repeating group" databases like Adabas and Pick.
True column store databases are almost unheard of for online transaction processing because they are optimized for streaming, unindexed data storage and subsequent column oriented analysis over large datasets with very low per row overhead. A bitmap index is the closest a traditional relational database comes to column storage, although at least two major relational databases have means of physically clustering related rows from different tables on the same page, which is more or less what Cassandra is described as doing here, except perhaps with more flexibility and more overhead to go along with it.
The video tag was starting to see adoption, because all video has unified behind h.264, so it made the use of the video tag actually work across all browsers
Except Internet Explorer, Firefox and Opera of course.
Here is a suggestion: What happens tomorrow, and what happens over the next five years are not the same thing. Without an effort like this, the video tag would be dead in the water. Forever.
Excuse me, IE9 hasn't even been released yet. Windows 7 has what, ten percent market share? And Windows Vista another ten percent? And the percentage of Windows 7 / Vista users who use IE instead of Firefox/Chrome/Opera/Safari is what, fifty percent maybe?
So if IE9 were released tomorrow, it would add native H.264 video tag support to a whole ten percent of the market at best.
All that aside, whatever its temporary technical merits, H.264 is epitome of an "evil empire" codec, and that is why it must die. "Patented standard" is an oxymoron.
I don't mean distributed repositories, but the one feature pack that the other systems seemingly have right: branching and merging with real rename tracking
It is entirely possible that this will never happen in any reasonable time frame without re-engineering the whole system. If it can happen with relatively minor changes, it should have happened by now. If it is going to require major changes, somebody is essentially going to have to fork it and redo the core SCM storage from the ground up. A number of minor patches won't do. A version of the Innovator's Dilemma, more or less.
No, for two reasons. (1) For most common applications PDF was high quality (2) PDF was based on a technology designed for typesetting from the very beginning. Adding the tweaks necessary for pre-press is a minor change.
Javascript support and interactivity was not, evidenced in part by the fact that dynamic PDF documents are incredibly rare. The whole tool chain used to produce most PDFs has no support whatsoever for automating them.
For the record, I think embedding audio and video clips is a worthwhile extension. General purpose scripting and Flash, not so much. Entirely different market, different tool chain, different security considerations, etc. "Interactive document" is an oxymoron.
I misspoke when I said "printed documents". I should have said something like "print-ready page oriented documents". Form support was bolted on three years later, and the sort of forms that PDF was good at were "print ready page oriented documents", like IRS tax forms, for example.
It is not a mistake that audio, video, and Flash support didn't come to PDF for twelve years after that. That is not what the creators had in mind, or at least not what they expended any actual effort implementing. What they spent all their effort implementing was support for page oriented documents that could be printed out verbatim at typographical quality if necessary.
The biggest difference, by far between PDF and something like HTML is that PDF is fixed size page oriented, and HTML is not. An HTML "page" really isn't a page at all. Not unless it is short enough to be printed out on one, and most aren't. Worse, the printing support of most web browsers is so bad that you might have guessed that Adobe bribed them to keep it that way.
You can always go read the PDF 1.0 specification, which is what I did, in 1993 or so. Of course no one was promoting the idea that you had to reduce the documents to hard copy. Acrobat Reader would be pretty useless if that was the case.
PDF/A is not an appropriate format for general use on the web, because it requires embedding all fonts. This makes the PDF much bigger, and that means the user's experience is slower.
Clearly we need a 'PDF/R' then, much like PDF/A except without mandatory font embedding.
It provides a set of stateful drawing commands which are identical to the same commands in PostScript. It is not a Turing-complete language, because it doesn't have loops, but it is interpreted and its syntax is identical to PostScript.
A syntax identical to a highly restricted subset of PostScript - not so much as a user defined macro - everything pre-defined for you. You can't even come anywhere close to converting the most average, run of the mill Postscript file (such as the output of a typical Postscript printer driver) to PDF without running through a full blown Postscript interpreter first.
That is entirely apart from the fact that most Postscript generators do not generate much in the way of control flow. What nearly every Postscript driver does is generate a bunch of macros that expand to lower level operations of the sort that PDF supports. Very roughly speaking Postscript is to PDF as XSLT is to XML.
Postscript is like M4 on steroids. PDF/X doesn't have macro expansion (let alone control flow), which makes it trivial to process by comparison. All the operators are pre-defined and do exactly the same thing. Postscript files are a user defined menagerie of any operator the programmer finds convenient.
A subset of PDF is almost identical to a subset of PostScript.
One should say rather that a subset of Postscript, when executed/interpreted produces output that is equivalent to a subset of PDF. PDF isn't based around an interpreter. Javascript/Flash appendages aside, a PDF document won't overflow the stack, does not have infinite loops, won't crash your photo-typesetter or take hours to run, because it is not a scripting language, but rather a vector oriented graphics format.
If Adobe did it over again, it is unlikely that Postscript would have been developed at all. Instead of Postscript printers, we would have had printers that accepted a subset of PDF. It would have solved a lot of problems. At this point Postscript is a historical artifact. PDF/X is its much superior replacement.
A good set of SGML like tools should accomplish all of what is buried in a PDF but with transparency
SGML is two full levels of abstraction higher than PDF. PDF isn't really intended to be a user editable document format at all. PDF is a page description language with a few extra features glued on. It was never intended to be editable, let alone provide any sort of document structure (aside from a table of contents), but rather to provide an accurate representation of printed pages.
SGML and HTML cannot do that without pixel perfect rules for layout, stylesheets, and font embedding. It is not likely to ever be a viable replacement for what PDF is good for, even with some sort of super container format. It is not like one can go anywhere on the web and download pixel perfect specification for the ultimate HTML / CSS layout engine. HTML layout is half specification and half folklore. Obviously extremely useful, just much more complex than PDF is.
Entirely different levels of abstraction make PDF rendering trivial compared to writing a good HTML/CSS layout engine. The layout has already been done by higher level tools, down to the level of exact page coordinates. Different kind of format good for different kind of things.
The fact that PDF is almost solely used to produce printed documents doesn't mean that's the intent of the format.
That was its sole intent when it was created, and for several years afterward. Rudimentary javascript support wasn't added until 1996. Audio / video embedding is a much more recent addition (2008 or so). See here.
PDF is in essence a PostScript-document (with restrictions of the use of external fonts and in a compressed form). PostScript is a complete programming-language which implies that one could write PostScript that would react to the environment in which it runs
PDF is not anything like PostScript. It shares the same rendering model, that is about it. Postscript _is_ a Forth-like, stack oriented programming language. PDF isn't a programming language at all, but rather a generally vector oriented graphics format with Javascript automation tacked on as an afterthought.
If you take the scripting aspect out of Postscript, you are left with nothing. If you take it out of PDF, 99.9% of the world's PDF documents still display and print without a problem.
Until the day when a major ISP implements LSN and then gets blocked.
No one is going to put mail servers or any other kind of server on an LSN IP address if they can help it. With the gradual re-allocation of 'consumer' IPv4 address blocks to LSN, there will be enough static IPv4 addresses for public facing servers for decades to come. Not pretty, but that's the way it is.
And if there were a shortage of static IPv4 addresses for servers and others willing to pay extra for them, there are no end of much more effective techniques to multiplex IPv4 addresses for server usage than NAT. Application layer proxies, in particular.
Most small businesses could run with a single static IPv4 address if they operate their own servers, or if they outsource proxy services hundreds of small businesses could share the same static IPv4 address for server usage using a central proxy and SNI.
The real question is for how long will 'residential' customers be able to get a static IPv4 address, and how much will it cost them. I imagine that most will be able to get static IPv4 addresses at a reasonable monthly fee for some time to come. Unless they are so unfortunate as to be Comcast customers, of course.
Slashdot Mirror
Key here is, HTML5 was supposed to at least partially break Adobe's stranglehold on the web by moving some content away from Flash
And put it in the hands of a far more pernicious "evil empire" than Adobe has ever hoped or pretended to be? H.264 is evil. What patents does Adobe claim on Flash? Adobe allows other implementations on a royalty free basis. Do they have any basis to do otherwise? Last, but certainly not least, Adobe doesn't come close to the audacity of requiring royalties on all Flash distributed content. If they did, Flash would be dead in the water.
Do you think any web advertiser in the world would pay royalties for Flash ads, for example. Hardly - they would switch to a royalty free alternative (as simple as static images) overnight.
WebM/VP8 will force a non-accelerated CPU-only rendering path on ALL existing hardware
So what? Tomorrow this will change. The future of the open Internet is of somewhat more consequence than battery usage over the next thirty six months, especially considering we are talking about a HTML tag for which support isn't yet widely deployed in the first place.
If battery usage is such a consideration, just stick with "evil empire" codecs like H.264 and pseudo standards like Flash in the interim. As has been mentioned elsewhere, all the DRM people apparently need to stick with something like Flash indefinitely, so there is nothing stopping paid video distributors like NetFlix from sticking with H.264.
It is the H.264 uber alles movement that is the enemy of the Internet as we know it. On a limited basis in proprietary sandboxes, it is just fine.
the US government should claim eminent domain on all patents involving the h.264 technology, and then dare the large companies to make a move. After all, we're the ones with the guns.
There is the pesky little constitutional provision about "no taking of private property without just compensation". So if the U.S. wants to spend somewhere between a hundred million and a billion dollars repossessing the H.264 patents, fine.
It would be far better, however, to quit the enormously counterproductive practice of granting patents (in most cases) in the first place. Patents are evil, on occasion a necessary evil perhaps, but certainly an enemy to openness, competition, and economic progress everywhere.
Patents also encumber USB and HDMI
No software patents, apparently. Is USB support in the Linux kernel patent encumbered? Is Intel or any other USB Implementers Forum member threatening to sue?
Hardware patents, while perhaps counterproductive, are a much less serious threat to open standards than software patents are. For one thing, they tend to be orders of magnitude less vague. For another, hardware cannot economically be distributed for free. Third, the entire structure of the open Internet does not depend on whether people can produce and use something like USB without royalties. If USB required computer users to pay royalties on anything they produced with a USB device, it would be dead in the water.
H.264 would be much more viable if the MPEG-LA made an unconditional, non-expiring license grant to open source software implementations, and dropped the ridiculous idea of requiring royalties of any kind on content distribution. As it is H.264 is more like an "evil empire" standard than anything I have ever seen.
that is not enough to convince anyone to support the video tag, when they can simply keep using h.264 in Flash players which will cover 99.9% of all browsers hitting them.
If they are stuck on H.264 for whatever reason, that is exactly what they should do - rely on a proprietary codec for a proprietary plugin. There is no reason why an "evil empire" codec like H.264 has some sort of natural right to rule the open Internet. To borrow an expression, the Internet views royalties as censorship and routes around them.
IE9 hasn't been released yet, and won't run on a majority of Windows boxes for years to come. So you could say, yes Internet Explorer supports H.264, it just requires a commercial plugin called Windows 7.
They are just not columns in the relational database sense.
They are not columns _even_ in the sense that column oriented databases use. They are repeating groups. What column oriented databases call "columns" have a perfect logical correspondence with what relational databases call columns. Nothing about the relational model dictates either row or column orientation, so far as storage is concerned.
The logical and physical structure of a Cassandra row has been used in some databases (Adabas, Pick, etc) for thirty or forty years. In fact others (such as Oracle and DB2) can implement the logical model of a relational database on the same physical model as that used by repeating group databases like Cassandra, getting the best of both worlds.
The end game for contemporary NoSQL databases is to evolve step by step in the direction of distributed, shared nothing relational databases with some special purpose relaxations. Secondary indexes? We have that. Transactions? We have that too! And so on...
The only problem with Cassandra is that the designer seem to have ignored everything written about database implementation in the past fifty years. Either that or have a severe case of the not-invented-here syndrome. Why use standard nomenclature when we can make up one maximally designed to confuse everyone and everybody?
Non-relational databases that do this have been around for decades. Adabas and Pick are the examples that come to mind. The pertinent difference here is that the developers of those databases were sane enough not to call repeating groups "columns".
Cassandra, HBase and BigTable aren't traditionally what is meant by the term href="http://en.wikipedia.org/wiki/Column-oriented_DBMS">column store database at all. Much closer to hybrid "repeating group" databases like Adabas and Pick.
True column store databases are almost unheard of for online transaction processing because they are optimized for streaming, unindexed data storage and subsequent column oriented analysis over large datasets with very low per row overhead. A bitmap index is the closest a traditional relational database comes to column storage, although at least two major relational databases have means of physically clustering related rows from different tables on the same page, which is more or less what Cassandra is described as doing here, except perhaps with more flexibility and more overhead to go along with it.
I would be shocked if Google goes to any great lengths to hunt down and exterminate H.264
Shocked now, are you? (smile)
The video tag was starting to see adoption, because all video has unified behind h.264, so it made the use of the video tag actually work across all browsers
Except Internet Explorer, Firefox and Opera of course.
Here is a suggestion: What happens tomorrow, and what happens over the next five years are not the same thing. Without an effort like this, the video tag would be dead in the water. Forever.
Excuse me, IE9 hasn't even been released yet. Windows 7 has what, ten percent market share? And Windows Vista another ten percent? And the percentage of Windows 7 / Vista users who use IE instead of Firefox/Chrome/Opera/Safari is what, fifty percent maybe?
So if IE9 were released tomorrow, it would add native H.264 video tag support to a whole ten percent of the market at best.
All that aside, whatever its temporary technical merits, H.264 is epitome of an "evil empire" codec, and that is why it must die. "Patented standard" is an oxymoron.
I don't mean distributed repositories, but the one feature pack that the other systems seemingly have right: branching and merging with real rename tracking
It is entirely possible that this will never happen in any reasonable time frame without re-engineering the whole system. If it can happen with relatively minor changes, it should have happened by now. If it is going to require major changes, somebody is essentially going to have to fork it and redo the core SCM storage from the ground up. A number of minor patches won't do. A version of the Innovator's Dilemma, more or less.
No, for two reasons. (1) For most common applications PDF was high quality (2) PDF was based on a technology designed for typesetting from the very beginning. Adding the tweaks necessary for pre-press is a minor change.
Javascript support and interactivity was not, evidenced in part by the fact that dynamic PDF documents are incredibly rare. The whole tool chain used to produce most PDFs has no support whatsoever for automating them.
For the record, I think embedding audio and video clips is a worthwhile extension. General purpose scripting and Flash, not so much. Entirely different market, different tool chain, different security considerations, etc. "Interactive document" is an oxymoron.
I misspoke when I said "printed documents". I should have said something like "print-ready page oriented documents". Form support was bolted on three years later, and the sort of forms that PDF was good at were "print ready page oriented documents", like IRS tax forms, for example.
It is not a mistake that audio, video, and Flash support didn't come to PDF for twelve years after that. That is not what the creators had in mind, or at least not what they expended any actual effort implementing. What they spent all their effort implementing was support for page oriented documents that could be printed out verbatim at typographical quality if necessary.
The biggest difference, by far between PDF and something like HTML is that PDF is fixed size page oriented, and HTML is not. An HTML "page" really isn't a page at all. Not unless it is short enough to be printed out on one, and most aren't. Worse, the printing support of most web browsers is so bad that you might have guessed that Adobe bribed them to keep it that way.
You can always go read the PDF 1.0 specification, which is what I did, in 1993 or so. Of course no one was promoting the idea that you had to reduce the documents to hard copy. Acrobat Reader would be pretty useless if that was the case.
PDF/A is not an appropriate format for general use on the web, because it requires embedding all fonts. This makes the PDF much bigger, and that means the user's experience is slower.
Clearly we need a 'PDF/R' then, much like PDF/A except without mandatory font embedding.
It provides a set of stateful drawing commands which are identical to the same commands in PostScript. It is not a Turing-complete language, because it doesn't have loops, but it is interpreted and its syntax is identical to PostScript.
A syntax identical to a highly restricted subset of PostScript - not so much as a user defined macro - everything pre-defined for you. You can't even come anywhere close to converting the most average, run of the mill Postscript file (such as the output of a typical Postscript printer driver) to PDF without running through a full blown Postscript interpreter first.
That is entirely apart from the fact that most Postscript generators do not generate much in the way of control flow. What nearly every Postscript driver does is generate a bunch of macros that expand to lower level operations of the sort that PDF supports. Very roughly speaking Postscript is to PDF as XSLT is to XML.
Postscript is like M4 on steroids. PDF/X doesn't have macro expansion (let alone control flow), which makes it trivial to process by comparison. All the operators are pre-defined and do exactly the same thing. Postscript files are a user defined menagerie of any operator the programmer finds convenient.
A subset of PDF is almost identical to a subset of PostScript.
One should say rather that a subset of Postscript, when executed/interpreted produces output that is equivalent to a subset of PDF. PDF isn't based around an interpreter. Javascript/Flash appendages aside, a PDF document won't overflow the stack, does not have infinite loops, won't crash your photo-typesetter or take hours to run, because it is not a scripting language, but rather a vector oriented graphics format.
If Adobe did it over again, it is unlikely that Postscript would have been developed at all. Instead of Postscript printers, we would have had printers that accepted a subset of PDF. It would have solved a lot of problems. At this point Postscript is a historical artifact. PDF/X is its much superior replacement.
A good set of SGML like tools should accomplish all of what is buried in a PDF but with transparency
SGML is two full levels of abstraction higher than PDF. PDF isn't really intended to be a user editable document format at all. PDF is a page description language with a few extra features glued on. It was never intended to be editable, let alone provide any sort of document structure (aside from a table of contents), but rather to provide an accurate representation of printed pages.
SGML and HTML cannot do that without pixel perfect rules for layout, stylesheets, and font embedding. It is not likely to ever be a viable replacement for what PDF is good for, even with some sort of super container format. It is not like one can go anywhere on the web and download pixel perfect specification for the ultimate HTML / CSS layout engine. HTML layout is half specification and half folklore. Obviously extremely useful, just much more complex than PDF is.
Entirely different levels of abstraction make PDF rendering trivial compared to writing a good HTML/CSS layout engine. The layout has already been done by higher level tools, down to the level of exact page coordinates. Different kind of format good for different kind of things.
The fact that PDF is almost solely used to produce printed documents doesn't mean that's the intent of the format.
That was its sole intent when it was created, and for several years afterward. Rudimentary javascript support wasn't added until 1996. Audio / video embedding is a much more recent addition (2008 or so). See here.
PDF is in essence a PostScript-document (with restrictions of the use of external fonts and in a compressed form). PostScript is a complete programming-language which implies that one could write PostScript that would react to the environment in which it runs
PDF is not anything like PostScript. It shares the same rendering model, that is about it. Postscript _is_ a Forth-like, stack oriented programming language. PDF isn't a programming language at all, but rather a generally vector oriented graphics format with Javascript automation tacked on as an afterthought.
If you take the scripting aspect out of Postscript, you are left with nothing. If you take it out of PDF, 99.9% of the world's PDF documents still display and print without a problem.
Until the day when a major ISP implements LSN and then gets blocked.
No one is going to put mail servers or any other kind of server on an LSN IP address if they can help it. With the gradual re-allocation of 'consumer' IPv4 address blocks to LSN, there will be enough static IPv4 addresses for public facing servers for decades to come. Not pretty, but that's the way it is.
And if there were a shortage of static IPv4 addresses for servers and others willing to pay extra for them, there are no end of much more effective techniques to multiplex IPv4 addresses for server usage than NAT. Application layer proxies, in particular.
Most small businesses could run with a single static IPv4 address if they operate their own servers, or if they outsource proxy services hundreds of small businesses could share the same static IPv4 address for server usage using a central proxy and SNI.
The real question is for how long will 'residential' customers be able to get a static IPv4 address, and how much will it cost them. I imagine that most will be able to get static IPv4 addresses at a reasonable monthly fee for some time to come. Unless they are so unfortunate as to be Comcast customers, of course.
err, right most 64 bits, not 2^64...