HunterWare

I would never suggest altruism as a defining motivation of a multinational corporation. grin What I’m suggesting as an owner of both since they were created is that iOS apps and devices have just been better curated

I chose iOS because the experience has been near uniformly better on iOS (in my opinion, for me) since inception. The motivations aside, their profit margins aside, and other externalities aside... The apps work better and are better on average and overall. This can only be consistently explained by the curation (directly, or indirectly with follow-on effects) because the other things are effectively equal. You can get a great piece of Samsung hardware, Android is a perfectly fine system sitting on a very robust OS (Linux), and the tooling is fine on both platforms... This leaves the curation: of both the apps in the app stores, and of the systems that are built in it’s name. I guess you could also make the case that Apple just made a better framework, but that’s easily addressable (if so, git gud google) and probably not really true.

The apps are just better curated, not perfect but better. And better is, well... better. Can you find a great Android app? sure. When you average across the store, however, the it will be lower. I don’t want or need even more worse choices. I want access to a couple good ones, to easily choose one, and then to move on.

The devices are (on average and almost across the board) also filled with less cruft. I remember picking up a top tier Android phone from Sprint several years back that had the newest processor, faster than any iPhone at that exact time. But the stuff that Sprint and HTC put on it slowed it to a crawl. The experience was just “less than”. Again, I want the most certainty that the device will just work and work well.

Competition is great, vital even. I sincerely hope all the different options keep the market on it’s toes for a long time. But legislating handcuffs seem counterproductive here. We don’t have a monopoly by any reasonable definition of the word. And without that this kind of idea is just overreach. I would be like me forcing your company to let me use their building just because it’s a lovely building. If your building is the ONLY building, then it’s in the public’s interest to enforce open access. But it’s not, so this is just me taking your nice private building (that people chose to pay to be in because it’s nice) and making it a public place so I can do whatever the heck I like because I want to.

There are already several different alternatives to iOS that a customer can get if they want a different app store. What he is really saying is that as a vendor he wants to force me as a customer to deal with a looser security model so that he can more easily sell to me. If I wanted that I would have chosen a different phone. But on the flip side, it’s helpful that now I know I never want a product of theirs... choice. =)

He's not saying it's impossible. He's saying the number of people doing it is so small as to be irrelevant to general arguments. While a much larger percentage (relatively) of people may have used this path ("reading into the law") a hundred years ago, it has largely faded from relevance in modern times.

See: https://en.wikipedia.org/wiki/Reading_law

Actually, I think the reply was basically on target... The complaint in the section of the linked article that APPEARS to be relevant to throwaway613834 is "CMake’s treatment of paths", which is all about the fact that build artifacts of cmake have absolute paths. Build artifacts of cmake, however, are build _output_ and thus shouldn't be relocated, distributed, or checked in (I would argue relocation is a form of redistribution, it's just the simplest possible case). These build artifacts are the output of a specific build, thus they are (as pointed out) a lot like .d files which I also would expect regenerate in the new build environment post moving/modifying. Just like with .o/.d, I would expect to move/distribute/checkin after cleaning these build artifacts, and then regenerate them afterwards. Since this is pretty simple to do, I'm not sure it's worth such a long section in this blog. This is even pointed out (a couple times) in the blog comments. The author also even references why it works this way as a default: "It is really hard to make everything work with relative paths, and you don’t get that much out of it, except lots of maintenance issues and corner cases that do not work." Unless you have spent a while deep-diving into the issues, wouldn't it be prudent to accept the word of the maintainers as pretty close to canonical?

Not really, since it's developed by them and for them (a mac house). He seems pretty welcoming of your additions to make this Linux/Windows if you desire... but why on earth one would expect that THEY would have taken the time to make this multi-platform when they don't use it that way is honestly beyond me (i.e. silly).

Come on.

Facebook isn't a human right or requirement. "Need" is too strong a word, you need food, water, oxygen, sleep... you "want" Facebook.

Facebook offers a service, use it or don't. It has settings, set them and if it still doesn't work for you then don't use it. Noone is "forced" to use Facebook, "forced to..." is not equivalent to "it would be really nice to...".