They refuse to make the Prime Video app available on the Play Store, they refuse to add Chromecast support, and now they refuse to even sell Chromecast because of their own decision to not support it? I've just canceled my Prime subscription and I hope a few others do as well.
You need 2 apps to run Prime Video, which I believe it's just called Amazon Video now.
You need the amazon appstore app, to install it, and you need amazon shopping app installed to run it (have no idea why). It works fine on android once you have installed all the amazon bs, but last time i checked the app wasn't very good on iOS.
I think you're confusing Google with Apple. The Play Store's policies are much more reasonable, and allow third party payment processors for purchasing digital items that can be consumed outside of the app itself. In fact, here's a third party video store on the Play Store , and here's Amazon's own Prime Music app .
Tierion Founder here. Very cool to see us on Hacker News!
Here's a real world example: We recently won the Coindesk hackathon by building an insurance claims processing application that creates an audit trail for the claims process by recording each step in the bitcoin blockchain. Our solution offered two main benefits. First, Tierion generated a blockchain receipt for the initial claim. This gives both the insurance company and the claimant a verifiable proof of the claim's timestamp and contents. Second, most insurance companies use an outside network of providers (call centers, data processors, etc.) to handle claims. By using Tierion, we created an immutable audit trail for the claims process. This gives the insurance company a record of how the claim was handled without having to integrate all of their external vendors.
An enterprise customer built a prototype that collects data from MRI machines to track its usage and maintenance schedule.
I don't see the benefit for the insurance company. The data isn't stored in the blockchain, so they will still have to maintain their own claims database. Why would they pay for the privilege of putting proofs in the blockchain when they already have their own database that they trust perfectly well?
The insurance companies are relying on an outside network of vendors. They are currently exchanging data using FTP/email and .CSV files. The usual controls for compliance, data-integrity, and fraud prevention are not in place. Our solution gave them an easy way to build an immutable audit trail and maintain data-integrity without having to incur the expense of integrating their external vendors.
In a perfect world, the insurance company would maintain a central database of claims data and everyone would work off that data. In the real world, data is being shared in an inefficient manner.
Insurance companies spend $2billion annual on fraud and compliance. Our solution helped them reduce their costs.
Instead, Tierion generates a blockchain receipt for each record, which provides irrefutable proof that your data was recorded in the Bitcoin blockchain. Anyone with this receipt can verify the timestamp and contents of the record.
It's not practical to store large amounts of data in the blockchain for the following reasons:
1) Bitcoin can currently handle seven transactions per second
2) You can only store 80 bytes of data in each transaction
3) The average transaction fee is currently $.03
Tierion is able to overcome these design constraints and generate blockchain receipts for millions of records. The specifics of how we do this is described in the following white paper: http://Tierion.com/chainpoint
Disclaimer: I designed the Factom Explorer and played a significant role in the launch of Factom.
That's a big question. Here are a few points:
1) Tierion does not require an altcoin. Factom does.
2) Tierion is a working product with paying customers. Factom is still in the very early stages of development. There is no user interface and only rudimentary developer tools.
3) You can sign up for Tierion in 30 seconds. We have an easy to use API and developer documentation. With Factom, you have to install three command line interface programs, exchange Bitcoin for Factoids, convert Factoids to Entry Credits, and then you can use the command line interface to write data to Factom. It's a very complicated experience. They are working on a docker image to make things simpler.
Factom has chosen to create a blockchain that is anchored to the bitcoin blockchain. If you choose to use Factom, your application will have a dependency on the Factom blockchain. If it fails, your application will probably fail. They have also chosen to create an altcoin. If you choose to use Factom, you will always need to acquire Factoids to write additional data to a Factom chain.
With Tierion, we've created a scalable protocol for recording data in the bitcoin blockchain and generating blockchain receipts. These receipts are portable. You can store them wherever you like. You can also share them with other applications that can independently verify the receipt.
Factom is still in the very early stages of development. They just reached their first milestone required to receive their first payment from the Factoid crowdsale. The second milestone requires Factom to build a storefront and a consensus mechanism for eight federated servers. This will likely take several months. The third milestone requires moving away from the current centralized model to a decentralized model. This will likely take several additional months.
I hope anyone who has been looking at Factom gives Tierion a try. I think you'll prefer our developer experience and you won't miss the reliance on an altcoin.
I'd love to see a Web renderer based on Vulkan. The reduced CPU overhead and much improved threading should be a huge win. You'd be able to cache on the command buffer level instead of just the vertex buffer level. Seems like a bleeding edge graphics API would be a good match for an experimental project like Servo as well.
To really use Vulkan as efficiently as possible, though, you'd probably want to write a renderer mostly from scratch rather than maintaining some sort of abstraction layer to support both GL and Vulkan.
I agree! The current graphics and driver landscape is too fragmented to bet on Vulkan in the near-term, however.
We do anticipate being able to keep most of the code around when Vulkan hits the scene. Our approach isn't to write an abstraction layer per se but rather by keeping our direct GL usage as isolated as possible, so that we can easily rewrite that stuff from scratch to really make good use of Vulkan, as you say. (This also allows us to support D3D if we want to.) Most of the logic here—batching, culling, texture atlas management, display list optimization—is very general logic that will apply no matter what hardware API we end up using.
"Near term" is relative. Multicore has been here for many years and we can safely assume its presence (though even then we're making sure we have good sequential performance). But it's not even clear that Vulkan will be available at all on all devices we might care about in the foreseeable future.
> as long as they [...] get users to agree not to act illegally
Is forcing everyone to set up captive portal pages just so people can check a stupid box on a form going to make anyone's life better? Is it going to benefit anyone in any way? I can't understand how anyone could possibly think that this requirement is a good idea.
There's a clear and massive movement of data forward for prediction in a CNN, and all that plus saving intermediate state and then moving the same amount of data backwards when performing backpropagation.
But don't believe me, don't believe a word I type. Go prove the above wrong by building a killer AlexNet implementation out of this chip. See slide 9 of this presentation for why I don't think you can do this (too much data transfer):