3 ms·
It’s a horse worth beating, or at least kicking, because it’s a tough set of incentives. Even if you have functionally unlimited money like Apple, it’s tough t
by perardi 5y ago
It’s a horse worth beating, or at least kicking, because it’s a tough set of incentives.
Even if you have functionally unlimited money like Apple, it’s tough to prioritize rewriting a somewhat obscure piece of the OS solely to prevent security issues. Because if you have a team that’s capable of fully reimplementing this component, and getting it through a QA process to make sure it doesn’t break another component of the OS…well damn, that’s a team you probably want on a higher-profile project, and not doing cleanup, right?
- brundolf 5y agoYeah, rewriting is hard and involves lots of complex cost tradeoffs. But at least when writing new software, with today's options, I think it's much harder to justify starting out with an unsafe language.
- perardi 5y agoWell, web apps. But that’s me being argumentative. 100% agree for “system software” like this.
- pjmlp 5y agoToday's options? The options were always there since around 1958, then about 15 years later, a group of folks doing their tiny OS decided to ignore them when creating their fun little language, because it was more fun to do their own thing. The problem is that this tiny OS and accompaning language grew to be everywhere thanks to its license, so now we are in this mess. But options? They have always been there for those that actually care.
- newaccount74 5y agoThe hard part is interoperability. Apple is writing lots of things in Swift today, but low level libraries that are used in many places are hard to do in Swift. Interoperability with C often requires very difficult casts, and if you do them incorrectly you'll have the same kinds of bugs as in C.
- glhaynes 5y agoAnd, on top of that, how much confidence do you have that your brand new code doesn’t introduce more security issues than the ancient “battle-tested” code?