> How come Amazon video isn't available on Apple TV or Chromecast?
In the case of Chromecast, because Amazon hasn't built an app that uses the Chromecast API, because -- the same as the move here -- Amazon wants to use its position to promote and sell its own hardware that competes with Chromecast.
Its not like Google prevents Amazon from using the Chromecast SDK the same as anyone else.
Hell, until recently, you couldn't play Prime Video on Android at all without resorting to Flash trickery in the browser. (But, of course, you could play it on Fire OS devices, even though they're running a fork of Android.)
Amazon really does not like Google. This is not a failure on Google's part, this is all of Amazon's own making in an attempt at product lock-in.
It's been a couple of weeks since I did it, but I got it working on my nVidia Shield TV, and I remember the process being something like:
1) Sideload Amazon app APK
2) Sideload Amazon Video app APK
3) Open Amazon app and log in
4) Open Amazon Video app
However, it wasn't a pleasant experience. The version of the Amazon Video app I was able to get working didn't scale well to large screens, didn't work well with remote-based navigation, and didn't seem to do HD. I watched one episode of something, and haven't used it again since.
You can install the Amazon Video app on Android now via the Amazon app. No Chromecast, so I haven't really used it much, and it doesn't look like you can tell it to download shows onto your SD card instead of internal storage. I'm guessing I'll end up using it for limited times when I wouldn't have a TV anyway, like airplane trips.
They want to sell the Fire TV and Fire Stick because it will get you 1) used to talking to their remote, 2) hopefully get you searching and browsing around for all kinds of stuff - their selection is a fascinating mix of really new stuff and older stuff and b-movies, and it's often surprising what's covered by the prime subscription and what you have to pay extra for.
By getting you to spend more time in their interface, they can add things. E.g. Prime Music had me spending a lot of time checking out playlists, some of which may very well lead to purchases of albums where only a couple of songs are available for free.
It also gets them penetration for whenever they add shopping to these devices, and e.g. lets you talk to Echo and ask it to bring up the top five best new phones on your TV for you to choose fro.
Getting Prime on Chromecast would help their penetration of Prime, but it might hinder their overall service penetration by giving some people a reason not to get a Fire Stick. Especially when the Fire Stick/Fire TV and Chromecast are all cheap enough that there's little stopping people from getting both...
It may very well backfire for them, but there's all kinds of reasons for them to want to push the Fire TV devices hard.
Yes, but if you're used to picking an app and casting from it, rather than picking a device and chosing apps on it, Amazon faces a much larger hurdle. On the Fire TV/Stick they control the UI. On Chromecast, they have to not only convince you to use Chromecast, but convince you to stay in their app.
They can lose a lot of users and still find it to be worth it for the extra engagement of the ones they did get.
I got a fire stick when it was on sale for like $20. It is a useless piece of garbage with a terrible user experience. The UI is clunky, as it tries as unsuccessfully as every set top box manufacturer to do everything with a crappy remote. Chromecast did it right and going back to the bad UI of a set top box is just unacceptable anymore.
Blaze is the one thing I miss the most from Google. However Blaze is very heavy for most small open source projects as the article says so the startup cost is too high.
I think there is probably room for a blaze-lite that relaxes a few of the restrictions blaze requires and is written in an easier to deploy language. Go perhaps?
The build rule language and the correct dependency specification and tracking are the most important pieces to have in my opinion. You could drop the expectation that all the dependencies including the compiler toolchain are in the source repo without losing too much.
It's all Python. It's built so you can include one Python file in your source tree and install nothing but Python.
A relatively small core handles dependency tracking and shuffling flags from the user to tasks. I can't believe how fast it is, considering it is reading the files and computing hashes.
While user scripts have access to all of Python, you can limit yourself and write rules in a high level build rule style that's only slightly more Pythonic than Bazel, et al. Basically it's bld.program(source=['main.c'], use=['foo']) or bld(features='c cprogram', source=['main.c'], use=['foo']) instead of cc_binary(srcs=['main.c'], deps=[':foo']).
Adding rules can be done in various ways, including genrule-style shell commands, registering a task class by file extension, and a very flexible system of registering methods to hook into the "features" attribute.
With surprisingly little work, you can layer your own build language on top of the core modules. Demos are provided that parse makefiles or generate rules by searching the source directory with no user script .
Relative to the OP's concerns, a configure step is required and can search the system, call pkg-config, write config.h, etc. Arbitrary command line options can be added by shared tools and user scripts. Install, dist, and distclean are all there.
So probably no one is still reading this. But I'm the author.
I enjoy investigating new languages and technologies. These tutorials were built while I was doing that for urbit. They probably read like a foreign language to some folks. It does assume a little bit of familiarity with nock and urbit servers.
Totally off-topic, but about 10 years ago I played an MMO called Star Wars Galaxies. My character's name was Zaphar Waverunner (at this point I can't remember if it was a totally random name from their generator or if I modified one in homage to Zaphod Beeblebrox). I'd never seen that word in another context until I saw one of your posts here recently.
after the initial boost of productivity, the effect will
no longer be noticeable
But the purpose of the team isn't just to get the initial boost but also to prevent a continual loss of productivity as the tooling inevitably bitrots. When you hit a certain size that bitrot happens much faster than you might think. It makes sense to keep an EE team on just to do maintenance. And support future changes to workflow. New languages and frameworks. Large scale refactorings happen more and more frequently as you hit walls that weren't there a month ago.
A break the engineer chooses is chosen and is unlikely to interrupt flow. An interruption caused by the tooling is not chosen and is more likely to interrupt flow.
Tooling cruft also increases the startup cost of some tasks. Where the amount of pain you will experience trying to do it may inhibit your desire to dig in.
The author was generalizing he wasn't assuming perfect accuracy. But in an engineering organization the size of Twitter the productivity gains of a dedicated tooling team add up fast. Much faster than you might think.
I admit that I have a fondness for learning esoteric languages. That said I've actually gone far enough down the urbit rabbit hole to write a set of tutorials.
urbit has a high startup cost and is hampered by a lack of documentation as well as a desire to reinvent terminology as well as a fast changing API to write too. All of which means that it's more suitable for the curious and hobbyists right now.
I'm withholding judgement on whether it will manage to succeed despite these.