As an employer though, what do you want to happen when your employee runs into an exception? Do you want them to flounder and have no idea how to solve it or do you want them to figure it out by doing some mildly novel design work?
> From a business point-of-view (when sideloading becomes more common) the "right" move for Google would be to fork AOSP, make new Android versions as closed as iOS (while still distributed for free) and prevent any sideloading. No sane CEO who is measured by increasing shareholder value could justify stayig open if this jeopardizes the revenues without providing major benefits.
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.
"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.
It's a really nice blog post but coming from Backblaze, it would have been nice if they wrote it _after_ bringing the Phoenix DC fully online. When Amazon or Google say 11 9s, I can believe it but Backblaze still only has a single datacenter for most data. All it takes is an earthquake.
> Do different video encoders, for the same codec, and input produce different outputs, or is the algorithm specified in a way where it produces the same results for two given inputs, no matter what?
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.
They can produce the same result but they do it in different ways and require you to express it in different ways.
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).