Apple also made their own operating system, their own programming language, their own external connectors, etc. Have their competitors followed their lead in becoming more vertically integrated in any other way? I’m not really seeing it.
This wouldn’t be the first time Apple used a non-x86 chip in the Mac. Nobody followed them last time.
Doesn’t that invalidate your earlier claim that “it wasn't very bad and most developers complied, which is an argument in favour of an ARM transition being feasible”? It doesn’t matter how nice the experience is for those who upgrade if a significant number of people avoid upgrading because the experience would be terrible. That’s selection bias.
Sure, Coke sales are down 50%, but the customers who are buying New Coke say they like it just as much as the old recipe!
Tasks versus goals, same as always. It's exactly the same as the question of why it was once recommended to carry a rifle for safety when traveling from St. Louis to Portland, and now it's recommended you leave it at home.
The goal was always to make corporations money. The task necessary to accomplish this goal just happened to flip.
Solaris skipped from 2.6 to 7. UnixWare also jumped from 2.x to 7. HP/UX skippped from 3.x to 6.x. In perhaps the strangest version jump of all time, Darwin jumped from 1.4.1 to 5.1, as part of Mac OS X 10.1.1.
It seems Unix vendors really don't like low version numbers. Of course, Windows famously jumped from 3.x to 95, so it's not like they're any better.
Apple is very consistent with this: the visual display always indicates the current state.
Other operating systems and third-party applications are not always consistent, even some big popular ones. 1Password used a "locked padlock" icon to both mean "it's locked" and "it's not locked (click here to lock it)", for the first 12 years. (They never fixed it, though with 1Password 7 they strangely removed the lock button entirely.)
Maybe it's because I grew up using Apple computers, but I never understood why one would make a control show the state that it isn't in.
Isn't that mostly OSHA? We are still doing megaprojects, but we've traded schedules for safety, which means we can do fewer of them.
I think that's the correct tradeoff, but it would be nice if we didn't lie to ourselves (and our constituents) about the precision of our estimates. I can't recall a megaproject completed this century which was less than 3 years late.
Amazon's M.O. is "pay money, get physical item". On the scale of how much aesthetics matters on a website, that's way over on the "not at all" side. About the only thing I'd put further that direction is Craigslist (which is "maybe pay no money, maybe get physical item").
For nearly every other website, aesthetics is of significant or even primary concern. When I'm not receiving packages from it, I care about how it looks. Facebook, Google, and StackOverflow were all much cleaner designs than what they replaced, and Wikipedia is perhaps the biggest and most aesthetically consistent website there is. Aesthetics matter.
> I feel like I’m missing something, because I keep seeing blog posts that tell me a browser monoculture is bad (and the irony of Microsoft saying this is nearly too much), but none of them tell me why.
For me personally, multiple independent implementations is a stamp of approval. It means that Google can't just sit on the standards committee, build something behind closed doors, and ship it, even if the result is open-source.
It means someone outside of that one company has to understand it, and be able to implement it. It can't be ridiculously complex, or have DOCX-style "just do what proprietary implementation X does" requirements. There has to be sufficient documentation. The implementations probably won't all have the same bugs -- I've heard avionics systems have multiple independent implementations for this very reason.
> Maybe the rendering engine should be more akin to the Linux kernel and less akin to Windows?
I fear it'll be more like Darwin. It's nice that XNU is "open source", perhaps, but nobody is taking advantage of this. I've never heard of anyone running XNU except as part of Apple's proprietary operating systems, and I've never heard of anyone forking it to run a custom version on their Apple hardware. I'm not even sure to what extent it's technically possible.
I would be much less worried if the single surviving browser engine were Gecko -- not because I think it's technically superior (I don't think it is), but because I trust Mozilla a lot more than I trust Google, or even Google+Microsoft. Mozilla is not good at design but they operate out in the open.
> no bug in your program nor any external application can ever make ".." invalid
Sure it can, if you consider lack of permissions to be invalid. We already do, in other similar situations.
> Without ".." all of a sudden you're orphaned and your application is stuck in an inconsistent state.
No, it just means you need an out-of-band method to accomplish this.
> that's like saying that all applications should be prepared for any pointer access to segfault at at any moment
No, nobody's talking about crashing. It's more like saying you can't assume you can do raw pointer arithmetic to jump around in an array. Languages like Java and Python feel restrictive to C programmers at first, too.
> Without ".." all of a sudden you're orphaned and your application is stuck in an inconsistent state.
I don't understand these claims of races and segfaults. Doesn't Fuchsia avoid race conditions like this with VFS cookies?
> Further, if your process is treating '..' as a subdirectory, you're doing it wrong.
That's the point they make. And in Unix, it's really easy to do it the "wrong" way (like, "type 3 characters" easy), so lots of people do.
Back before protected memory was common on PCs, some people said "If you're chasing pointers without being sure that it points to a valid address, you're doing it wrong". Well, perhaps so, but in practice lots of programs were doing it wrong, and it was the users who suffered.
Capabilities sound to me a bit like protected memory for persistent storage. It'll be a little inconvenient for a little while, and eventually we'll wonder how we ever lived without it.
Studies have found that bug count is roughly proportional to program length, across languages. Saying you prefer verbosity essentially means you prefer more bugs. 500 lines is generally less understandable than 40 lines. There may be cases where terseness can be too extreme, but I don't see it here.
Is there some particular aspect of the Clojure code here that you think is overly clever, or hard to understand? This Clojure code uses only one lambda, and in a straightforward way.
I've written a lot of Java, and a moderate amount of Clojure, and if I had to place a wager on which version had fewer bugs, I'd definitely bet on the Clojure. Especially if there were the possibility that it was related to threads.
We could write this in assembly language, and it'd take 50,000 lines, and probably have lots of bugs. The salient point is not (just) the lower line count, but that when code is shorter, that's a good indicator that it's written at a level of abstraction that fits the problem.
The entire JSON spec is only about 3 pages long. (I don't know exactly how long because ECMA's webpage is down today!) I'm pretty confident that any popular JSON parser I use will abort correctly on bad JSON. There's no expansion or entities or escaping, so the parser is a pretty boring 1-to-1 translation. Give it a 1KB JSON file, and I'm going to get back a data structure that takes roughly 1KB.
XML is incredibly complicated. My operating system's XML parser has had XXE-related security bugs in the recent past -- that's OWASP bug#4, and there's a Wikipedia article about it. There's other possible attacks, like the "billion laughs attack". I'm very nervous about running an XML parser on untrusted content.