Google themselves have backed off from the VP8 claims, so it's not so easy to find the original claims anymore. Any places where I recall them making the change are either gone, or have had their focus shifted to WebM in general or VP9. One remnant of the claims can be found here
Evidence? It's fairly common knowledge, and anybody can go and look at comparisons themselves.
My claim is that VP8/h.264 parity is an absurd assertion, not VP9, and this is a widely accepted assertion. Have you actually looked at any comparisons between the codecs?
It's not the disaster that VP8 was (which looked like a codec from 10+ years ago), but it seems to be at best in the same ballpark as x264. VP9 isn't really a viable replacement for h.265, but it might do better than their last attempt merely by not being a laughable joke like VP8.
Mind you, I'm not saying VP8 is bad in and of itself. I certainly couldn't do better. But Google promoted it as being superior to h.264, which was an absurd assertion, hence the derision.
But when you compare the A380 to the 787, the A380 has 262 firm orders at US$403.9 million for a total of ~US$106 billion, while the 787 has 890 orders at a unit cost of US$206.8 or US$243.6 million (depends on which model) for a total of ~US$197 billion (based on specific model orders). It's hard to call the A380 a failure with that sort of revenue, but clearly the demand for something like the 787 was much higher, both in terms of units and revenue.
There are synthetic materials that can probably do the trick. How about synthetic diamond? Firing pins are tiny, and well within the capabilities of synthetic industrial diamond production.
Then those go for maybe two hundred bucks these days, which is pretty reasonable, although not cheap enough to make it into low-end machines. 128GB seems to be the default normally included, with 256 as an upgrade on top of that.
Define "large capacities"? Most notebooks sold at a thousand bucks or more use SSDs for primary storage now (certainly all the ultrabooks and tablets do), and even the $700 Dell notebook that got recently has a 32 gig SSD for caching (Intel SRT).
You're looking at things backwards. If you've got a 500 MB/s SSD, then you shouldn't look at 10GigE and say "that's twice as fast as I need, it's useless". You should look at the existing GigE and say "my SSD is four times faster, one gigabit is too slow"...
Even a cheap commodity magnetic hard disk can saturate a gigabit network today. The fact that lots of computers use solid state drives only made that problem worse. Transferring files between computers on a typical home network these days, I think the one gigabit per second network limitation is going to be the bottleneck for many people.
The fact that you can use existing commodity Cat 6 cables for up to 55m with 10GigE will help a lot too. Yes, Cat 6a cables are required for the full 100m distance, and yes, Cat 6a cables are themselves cheap ($4 for that 6 feet you mention costing $80 with Twinax), but for lengths under 55m, the cabling that you've already got will continue working at the higher speeds. I think that will be a big factor, especially for consumers, where cables longer than 10 or 15 metres are incredibly rare anyhow.
Right now, I think the NIC/port price is the major roadblock. Netgear made a big deal about dropping below $125 per 10gig port on their switches a while ago, and that's a step forward, but it's still a thousand bucks for an 8-port switch (probably on the larger end of what you'd find in a home network), and the cheapest 10 gig NIC on NewEgg is $345. That's in the "affordable for enthusiasts" range, though. If you're willing to spend seven hundred bucks, you could connect your desktop to your home file server over 10 gigabit, for example, and two or three thousand bucks could get a bunch of devices on a network. Expensive, but not "mortgage your house, this is only for multi-billion dollar enterprise use" levels like it was a few years ago.
More seriously, as a ZFS user (first on Solaris, now on Linux), I'm happy that ZFS outgrew Oracle and lives on as a community opensource project. I greatly prefer it to btrfs, if only on a management level. And ironically, ZFS is now completely free of Oracle influence, while btrfs isn't.
Even in the same language, cursing doesn't always translate. In Quebec French, all the curse words are church terms. Somebody from France probably wouldn't even recognize it as cursing, they'd just wonder why someone was angrily reciting a church-related vocabulary list.
I think your hypothesis only goes back 6 years or so, not ten:)
Seriously though, modern games don't look much better than the original Crysis, and what improvement there has been doesn't seem much better than throwing more polygons and texture resolution at the problem. It seems we've reached a point of diminishing returns.
There is, however, utility in more hardware power... that next-gen Oculus Rift isn't going to render for itself!
Perhaps it's because I live in the downtown core of a very large city, but Bell's underground conduits are fairly well maintained here, and probably have work done on them regularly. It certainly didn't seem to be a major barrier to them wiring up the city with fiber (they run fiber to the MDU and serve individual customers with VDSL2 from there). On top of that, access to Bell's conduits is regulated; anybody can pay Bell regulated rates to pull stuff through the conduits.
This situation may not be the case outside of large cities.
The thing is the telephone companies have a strong incentive to step up to fiber. VDSL2 is not keeping up with cable developments (bonded DOCSIS 3 is already pushing multi-hundred megabit speeds to customers here, which VDSL2 can't match), and while you might top out VDSL2 at 100-200 megabits per second with vectoring and bonding, cable is on the cusp of moving to DOCSIS 3.1 which competes with GPON in shared throughput (10 gigabit).
VDSL2 is seen by Bell Canada (who own Bell Aliant doing the fiber deployments in eastern Canada) as a stepping stone. It keeps them competitive long enough to roll out more fiber. It definitely won't be 20 years before they've replaced most or all of their copper...
There's another scenario other than "buried" or "strung", which is "in a conduit". In fact, for people served by VDSL2, that is often already done. My VDSL2 is served, as are many other people in Montreal, by a DSLAM in my basement. Dedicated fiber enters my apartment building, and all the units are served VDSL2 over the copper phone lines in the building. At that point, you've done the hardest part of getting the fiber to the building already, and all you need to do is run the fiber through the building. That's not very hard. Bell Aliant has a neat PDF where they discuss all the different ways they wire up a building with fiber, based on the building itself and the requirements of the owners. It can be anything from pulling the copper wiring from the building's internal conduits and using compressed air to blow fiber up them, or they can drill a hole between each floor and run it along the hallway outside each apartment near the ceiling where it's invisible, or even leverage a building's existing ethernet infrastructure if one exists (infrequent as that case might be).
In terms of battery backup, well, personally I'd have battery capacity to go beyond a few hours, but the vast majority of people won't. For them, there may be other options (cellular, for example), but the reality is that the copper infrastructure will eventually be completely replaced, so these problems are going to occur sooner or later. Rather than citing it as a reason copper should stick around, since that won't happen, finding a solution to the problem is more productive. I can think of a few mechanisms that might extend the lifespan of the batteries. Obviously, if you're using lead acid, you're going to want a lithium ion battery in there, but beyond that, a low power mode specifically designed to keep nothing but telephony working during a power outage could greatly extend the battery life. Perhaps, in such a mode, you could shut down the optical transceiver entirely until somebody actually picks up the phone, for example. Battery usage apart from when somebody is actually using a telephone would be minimal, to the extent that a relatively modest battery could easily provide days (or more) of telephone connectivity.
My understanding is that current battery backups for ONTs just provide power to keep the thing going as usual doing a power failure, but specific support for power saving could extend this greatly...
If the outage is widescale enough, as it was in 1998 during the ice storm, it doesn't matter who maintains them. There are only so many generators to go around to recharge those batteries, and acquiring additional generators is impossible when millions of other people are trying to do the same thing.
1. is not true in some places. Bell Aliant's territory (most of eastern Canada) is now primarily fiber, with very little copper left. They decided to replace their entire network, and then went and did it. 2. is partially true, but battery backups (frequently included in the install) keep things running for hours, making this much less of a problem than people think. Also, during extended power outages, the battery backups at your telco's CO only lasts so long, and they only have so many generators to recharge them with, so this problem affects copper too. 3. is misleading because fiber is cheaper to deploy on the whole, the cost of individual pieces of equipment is irrelevant when the overall process is cheaper. 4. is untrue, you can find GPON ONTs for $65 or less.
It's not what we use in Canada on every level of election, because the Federal government has no say in how provincial and municipal elections are done (that's up to the provincial government's elections body). Electronic voting has been used at other levels in the past. Maybe it still is, all I can say is that we tried it with the Quebec municipal elections years ago, and it was such a disaster that the Quebec elections commission banned electronic voting for umpteen years to come.
In terms of the actual process, after the polls close, the Deputy Returning Officer (the person responsible for the individual poll) counts the votes by hand, assisted by the poll clerk, with either the candidates or (far more likely) their representatives serving as witness. When the count in a particular ballot box is complete, the Deputy Returning Officer telephones the riding's Returning Officer (responsible for all polls in that riding) to verbally deliver the preliminary results for that box (in reality the call is answered by a phone pool, written on a scrap of paper, and delivered by hand to the next person in the pipeline). Only here are any electronics (other than telephone) involved: in order to be reported quickly to the public and media, Elections Canada employees enter each poll's results into a computer, and the results are sent to Elections Canada via an encrypted dialup connection (admittedly it was a few years ago that I did that job, but the riding's Elections Canada office is a temporary office rental for the duration of the election period, and probably still uses dialup today). These are not the official results, but serve to get the preliminary results out quickly to the press and public. Once all ballot boxes at the poll are counted, the Deputy Returning Officer re-seals the ballot boxes with the official results documents and delivers them to the Returning Officer. The preliminary results are validated against the official documents and published as the official figures. Normally the validation happens very quickly (within a few days), but officially they have up to three weeks to accommodate delays in delivery.
By this method, you get both immediate preliminary results that are pretty darned accurate, and also official certified results shortly after (in case the person at the riding office made a typo or something).
Switchboard can only accelerate internet access (the whole combining multiple pipes thing) if the user has a server in a datacenter. That's pretty cheap when you can get a Linode for $20 a month. The problem is this: switchboard's personal version only runs on Windows and Mac, but almost all consumer-level servers out there run Linux.
tl;dr: Why do I have to buy the enterprise version if I want to run switchboard on my Linode instead of on Azure or Amazon EC2?
Not to mention the capacity issues... These cameras are eating up something like 500-600 megabits per second at full resolution, and the ones people are most excited about doing this on (like the 5DIII) cost as much or more than video cameras that are designed to record to high bit-depth compressed format like ProRes 4444 (which is 12-bit).
I guess there's some value in getting more out of your existing gear...
The venue doesn't provide free wifi, so either I've got to pay for the RTC or the wifi. For the proof of concept model that won't be internet-connected, I'll probably just grab an RTC. For a potential future full-blown implementation with a bunch of units, I'd need wifi for live schedule updates anyhow, so could use that.
The problem with the rpi lacking an RTC is that many potential uses for it have it in places where internet access it not readily (or at least affordably) available.
Are there many apps that have hardware accelerated in-window rendering on the Pi? Web browsers or photo slideshow apps or whatnot? I'm considering using a Pi for a project (display live room schedules for a convention on televisions), and while that sort of hardware acceleration isn't required, fading between screens/images/whatnot would certainly look nicer.
I want to put a real-time room schedule display on televisions for a convention I work for. I could spend a few hundred dollars on a laptop for each television, or I could duct tape a $25 raspberry pi to the back of it and accomplish the same thing at a significant cost savings...
I can see a value in this sort of ultra-low-cost hardware, is it really so hard for you to? Not every use case requires high performance. In my case, cycling through a bunch of pre-made images (or perhaps I'll throw up a fullscreen web browser and do it live with scripting) on a television doesn't require much more than that. Well, except an RTC, which the Pi lacks and will require a $20 add-on, but the overall cost with accessories still ends up at a third of a crappy refurbished netbook.
So, let me get this straight... You're telling one of the founders of Raspberry Pi, who is a technical director at the company (Broadcom) writing those hardware video drivers you mention, and who was likely one of the people pushing the development work mentioned in TFA, that he needs to "spend more than ten seconds learning about wayland"?
Yes, I'm sure he's completely ignorant of such things.
Slashdot Mirror
Google themselves have backed off from the VP8 claims, so it's not so easy to find the original claims anymore. Any places where I recall them making the change are either gone, or have had their focus shifted to WebM in general or VP9. One remnant of the claims can be found here
http://www.webmproject.org/about/
The claim here is that VP8 is the highest quality format for real-time video delivery.
VP8 was just poorly designed. One of the x264 developers did some decent coverage on why this is the case on a technical level:
http://x264dev.multimedia.cx/archives/category/vp8
Evidence? It's fairly common knowledge, and anybody can go and look at comparisons themselves.
My claim is that VP8/h.264 parity is an absurd assertion, not VP9, and this is a widely accepted assertion. Have you actually looked at any comparisons between the codecs?
It's not the disaster that VP8 was (which looked like a codec from 10+ years ago), but it seems to be at best in the same ballpark as x264. VP9 isn't really a viable replacement for h.265, but it might do better than their last attempt merely by not being a laughable joke like VP8.
Mind you, I'm not saying VP8 is bad in and of itself. I certainly couldn't do better. But Google promoted it as being superior to h.264, which was an absurd assertion, hence the derision.
But when you compare the A380 to the 787, the A380 has 262 firm orders at US$403.9 million for a total of ~US$106 billion, while the 787 has 890 orders at a unit cost of US$206.8 or US$243.6 million (depends on which model) for a total of ~US$197 billion (based on specific model orders). It's hard to call the A380 a failure with that sort of revenue, but clearly the demand for something like the 787 was much higher, both in terms of units and revenue.
There are synthetic materials that can probably do the trick. How about synthetic diamond? Firing pins are tiny, and well within the capabilities of synthetic industrial diamond production.
Then those go for maybe two hundred bucks these days, which is pretty reasonable, although not cheap enough to make it into low-end machines. 128GB seems to be the default normally included, with 256 as an upgrade on top of that.
Define "large capacities"? Most notebooks sold at a thousand bucks or more use SSDs for primary storage now (certainly all the ultrabooks and tablets do), and even the $700 Dell notebook that got recently has a 32 gig SSD for caching (Intel SRT).
You're looking at things backwards. If you've got a 500 MB/s SSD, then you shouldn't look at 10GigE and say "that's twice as fast as I need, it's useless". You should look at the existing GigE and say "my SSD is four times faster, one gigabit is too slow"...
Even a cheap commodity magnetic hard disk can saturate a gigabit network today. The fact that lots of computers use solid state drives only made that problem worse. Transferring files between computers on a typical home network these days, I think the one gigabit per second network limitation is going to be the bottleneck for many people.
The fact that you can use existing commodity Cat 6 cables for up to 55m with 10GigE will help a lot too. Yes, Cat 6a cables are required for the full 100m distance, and yes, Cat 6a cables are themselves cheap ($4 for that 6 feet you mention costing $80 with Twinax), but for lengths under 55m, the cabling that you've already got will continue working at the higher speeds. I think that will be a big factor, especially for consumers, where cables longer than 10 or 15 metres are incredibly rare anyhow.
Right now, I think the NIC/port price is the major roadblock. Netgear made a big deal about dropping below $125 per 10gig port on their switches a while ago, and that's a step forward, but it's still a thousand bucks for an 8-port switch (probably on the larger end of what you'd find in a home network), and the cheapest 10 gig NIC on NewEgg is $345. That's in the "affordable for enthusiasts" range, though. If you're willing to spend seven hundred bucks, you could connect your desktop to your home file server over 10 gigabit, for example, and two or three thousand bucks could get a bunch of devices on a network. Expensive, but not "mortgage your house, this is only for multi-billion dollar enterprise use" levels like it was a few years ago.
No, me!
More seriously, as a ZFS user (first on Solaris, now on Linux), I'm happy that ZFS outgrew Oracle and lives on as a community opensource project. I greatly prefer it to btrfs, if only on a management level. And ironically, ZFS is now completely free of Oracle influence, while btrfs isn't.
Even in the same language, cursing doesn't always translate. In Quebec French, all the curse words are church terms. Somebody from France probably wouldn't even recognize it as cursing, they'd just wonder why someone was angrily reciting a church-related vocabulary list.
I think your hypothesis only goes back 6 years or so, not ten :)
Seriously though, modern games don't look much better than the original Crysis, and what improvement there has been doesn't seem much better than throwing more polygons and texture resolution at the problem. It seems we've reached a point of diminishing returns.
There is, however, utility in more hardware power... that next-gen Oculus Rift isn't going to render for itself!
Perhaps it's because I live in the downtown core of a very large city, but Bell's underground conduits are fairly well maintained here, and probably have work done on them regularly. It certainly didn't seem to be a major barrier to them wiring up the city with fiber (they run fiber to the MDU and serve individual customers with VDSL2 from there). On top of that, access to Bell's conduits is regulated; anybody can pay Bell regulated rates to pull stuff through the conduits.
This situation may not be the case outside of large cities.
The thing is the telephone companies have a strong incentive to step up to fiber. VDSL2 is not keeping up with cable developments (bonded DOCSIS 3 is already pushing multi-hundred megabit speeds to customers here, which VDSL2 can't match), and while you might top out VDSL2 at 100-200 megabits per second with vectoring and bonding, cable is on the cusp of moving to DOCSIS 3.1 which competes with GPON in shared throughput (10 gigabit).
VDSL2 is seen by Bell Canada (who own Bell Aliant doing the fiber deployments in eastern Canada) as a stepping stone. It keeps them competitive long enough to roll out more fiber. It definitely won't be 20 years before they've replaced most or all of their copper...
There's another scenario other than "buried" or "strung", which is "in a conduit". In fact, for people served by VDSL2, that is often already done. My VDSL2 is served, as are many other people in Montreal, by a DSLAM in my basement. Dedicated fiber enters my apartment building, and all the units are served VDSL2 over the copper phone lines in the building. At that point, you've done the hardest part of getting the fiber to the building already, and all you need to do is run the fiber through the building. That's not very hard. Bell Aliant has a neat PDF where they discuss all the different ways they wire up a building with fiber, based on the building itself and the requirements of the owners. It can be anything from pulling the copper wiring from the building's internal conduits and using compressed air to blow fiber up them, or they can drill a hole between each floor and run it along the hallway outside each apartment near the ceiling where it's invisible, or even leverage a building's existing ethernet infrastructure if one exists (infrequent as that case might be).
In terms of battery backup, well, personally I'd have battery capacity to go beyond a few hours, but the vast majority of people won't. For them, there may be other options (cellular, for example), but the reality is that the copper infrastructure will eventually be completely replaced, so these problems are going to occur sooner or later. Rather than citing it as a reason copper should stick around, since that won't happen, finding a solution to the problem is more productive. I can think of a few mechanisms that might extend the lifespan of the batteries. Obviously, if you're using lead acid, you're going to want a lithium ion battery in there, but beyond that, a low power mode specifically designed to keep nothing but telephony working during a power outage could greatly extend the battery life. Perhaps, in such a mode, you could shut down the optical transceiver entirely until somebody actually picks up the phone, for example. Battery usage apart from when somebody is actually using a telephone would be minimal, to the extent that a relatively modest battery could easily provide days (or more) of telephone connectivity.
My understanding is that current battery backups for ONTs just provide power to keep the thing going as usual doing a power failure, but specific support for power saving could extend this greatly...
If the outage is widescale enough, as it was in 1998 during the ice storm, it doesn't matter who maintains them. There are only so many generators to go around to recharge those batteries, and acquiring additional generators is impossible when millions of other people are trying to do the same thing.
1. is not true in some places. Bell Aliant's territory (most of eastern Canada) is now primarily fiber, with very little copper left. They decided to replace their entire network, and then went and did it.
2. is partially true, but battery backups (frequently included in the install) keep things running for hours, making this much less of a problem than people think. Also, during extended power outages, the battery backups at your telco's CO only lasts so long, and they only have so many generators to recharge them with, so this problem affects copper too.
3. is misleading because fiber is cheaper to deploy on the whole, the cost of individual pieces of equipment is irrelevant when the overall process is cheaper.
4. is untrue, you can find GPON ONTs for $65 or less.
I have 50 megabit DSL via old copper phone cables, and if my ISP swapped out my DSLAM, I'd qualify for 75 megabit when they introduce that.
It's not what we use in Canada on every level of election, because the Federal government has no say in how provincial and municipal elections are done (that's up to the provincial government's elections body). Electronic voting has been used at other levels in the past. Maybe it still is, all I can say is that we tried it with the Quebec municipal elections years ago, and it was such a disaster that the Quebec elections commission banned electronic voting for umpteen years to come.
In terms of the actual process, after the polls close, the Deputy Returning Officer (the person responsible for the individual poll) counts the votes by hand, assisted by the poll clerk, with either the candidates or (far more likely) their representatives serving as witness. When the count in a particular ballot box is complete, the Deputy Returning Officer telephones the riding's Returning Officer (responsible for all polls in that riding) to verbally deliver the preliminary results for that box (in reality the call is answered by a phone pool, written on a scrap of paper, and delivered by hand to the next person in the pipeline). Only here are any electronics (other than telephone) involved: in order to be reported quickly to the public and media, Elections Canada employees enter each poll's results into a computer, and the results are sent to Elections Canada via an encrypted dialup connection (admittedly it was a few years ago that I did that job, but the riding's Elections Canada office is a temporary office rental for the duration of the election period, and probably still uses dialup today). These are not the official results, but serve to get the preliminary results out quickly to the press and public. Once all ballot boxes at the poll are counted, the Deputy Returning Officer re-seals the ballot boxes with the official results documents and delivers them to the Returning Officer. The preliminary results are validated against the official documents and published as the official figures. Normally the validation happens very quickly (within a few days), but officially they have up to three weeks to accommodate delays in delivery.
By this method, you get both immediate preliminary results that are pretty darned accurate, and also official certified results shortly after (in case the person at the riding office made a typo or something).
Switchboard can only accelerate internet access (the whole combining multiple pipes thing) if the user has a server in a datacenter. That's pretty cheap when you can get a Linode for $20 a month. The problem is this: switchboard's personal version only runs on Windows and Mac, but almost all consumer-level servers out there run Linux.
tl;dr: Why do I have to buy the enterprise version if I want to run switchboard on my Linode instead of on Azure or Amazon EC2?
Not to mention the capacity issues... These cameras are eating up something like 500-600 megabits per second at full resolution, and the ones people are most excited about doing this on (like the 5DIII) cost as much or more than video cameras that are designed to record to high bit-depth compressed format like ProRes 4444 (which is 12-bit).
I guess there's some value in getting more out of your existing gear...
The venue doesn't provide free wifi, so either I've got to pay for the RTC or the wifi. For the proof of concept model that won't be internet-connected, I'll probably just grab an RTC. For a potential future full-blown implementation with a bunch of units, I'd need wifi for live schedule updates anyhow, so could use that.
The problem with the rpi lacking an RTC is that many potential uses for it have it in places where internet access it not readily (or at least affordably) available.
Are there many apps that have hardware accelerated in-window rendering on the Pi? Web browsers or photo slideshow apps or whatnot? I'm considering using a Pi for a project (display live room schedules for a convention on televisions), and while that sort of hardware acceleration isn't required, fading between screens/images/whatnot would certainly look nicer.
I want to put a real-time room schedule display on televisions for a convention I work for. I could spend a few hundred dollars on a laptop for each television, or I could duct tape a $25 raspberry pi to the back of it and accomplish the same thing at a significant cost savings...
I can see a value in this sort of ultra-low-cost hardware, is it really so hard for you to? Not every use case requires high performance. In my case, cycling through a bunch of pre-made images (or perhaps I'll throw up a fullscreen web browser and do it live with scripting) on a television doesn't require much more than that. Well, except an RTC, which the Pi lacks and will require a $20 add-on, but the overall cost with accessories still ends up at a third of a crappy refurbished netbook.
So, let me get this straight... You're telling one of the founders of Raspberry Pi, who is a technical director at the company (Broadcom) writing those hardware video drivers you mention, and who was likely one of the people pushing the development work mentioned in TFA, that he needs to "spend more than ten seconds learning about wayland"?
Yes, I'm sure he's completely ignorant of such things.