Pissompons
> Google doesn't charge them a cent for using Android.
Why should Epic care about Android's development costs? They don't pay Microsoft a cent for Windows, why should they pay Google for Android?
Google chose this business model, software developers certainly have no obligation to support it.
> Along with payment processing, download bandwidth, and customer service?
Epic has all this infrastructure already, they need it for their PC customers. Why overpay for Google's?
The problem here is that while Google controls the software, it doesn't control the hardware. All the real power is in the hands of the OEMs.
If Google wanted to close Android, they'd need to either:
- Leverage/convince all the OEMs into adopting the closed fork
- Watch as they lose control completely when someone else makes a dominant fork
- Watch the Android ecosystem crumble as everyone throws out their own fork
I don't think this would work because the OEMs have no incentive to do it. They don't get any cut of the Play Store profits so they have no interest in its success. To the contrary, Samsung at least has its own store. Plus, Android's openness is one of the things differentiating it from Apple. If they closed it down, they have the compromised privacy of a Google device with the closed platform of an Apple device. Apple's closedness then ceases to be a problem and they can differentiate with their privacy-friendliness.
Right on their blog (https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-ove...), quoted by the article:
"We’d like to turn this on as the default for all of our users. We believe that every one of our users deserves this privacy and security, no matter if they understand DNS leaks or not."
I'd say that it's basically just the lowest common denominator of English. Imagine an English where any accent is acceptable as long as you're consistent and any regional vocabulary is okay so long as it's well known (e.g. either "torch" or "flashlight" is okay, "soda" is okay but "pop" is not). You then have "global" English.
The overall sentiment of your comment is good but I took issue with this particular statement. English is _a_ language of great literature. There's great literature written in basically all languages, you're just less likely to know unless you speak them.
Someone else answered this but I thought I'd elaborate: A good way to think about a codec is as a toolbox. The specification tells you which tools you can use to build a frame (encoder) and which you must support to turn one into pixels (decoder).
Which tools are used in what way makes a huge difference in the output of the encoder, particularly in terms of compression. Have a look at the results for a few H.264 encoders [0]. For the "video conferencing" use-case, the best encoder (x264) uses ~400kbps to produce the same quality of the worst at ~1000kbps.
And like different tools have different costs (a jackhammer needs a generator, a handheld hammer does not), so do the tools in the codec toolbox. Some tools might make the encode slower or might make the decode drain more battery from a mobile device. Others might take a lot of physical space on a piece of silicon, so they're rarely used in hardware.
So different encoders have very different characteristics, not just in terms of output but in terms of power usage, speed and complexity as well.
[0]: http://www.compression.ru/video/codec_comparison/h264_2012/
Make has you describe a graph of outputs and how to produce them. It then traverses the graph to produce the requested output.
Bash is just a regular sequence of commands, with functions and loops if you wish.
If the pipeline you need to run can easily be turned into a dependency graph, I think make is a great fit. It's easy to use, comes with most of what you need built in and has some fun extras, like -jXXX, which allows you to parallelise things and built in caching so you don't regenerate the same asset twice if you don't need to.
You can do all that in bash but you'll have to write it yourself, which takes time you could spend on other things.
- Quantopian: Was good, has tons of data and makes things very easy. Unfortunately you can't easily live trade your algorithms anymore.
- QuantConnect: Open source, works okay, at the time I wanted it for options trading though and their support for options chains isn't so good.
- Zorro: Closed source, paid, uses a weird custom variant of C but works surprisingly well. Mainly focused on forex though.
- Others: There are others, like this one, that are mostly unusable because they miss something essential, like broker support or data.
QuantConnect is the only real packaged option these days I think but it's also not hard to roll your own. There are brokerages with _really_ easy to use APIs (Tradier is the first that comes to mind).