pthread_cancel is never the answer. Abrupt thread cancelation is always a risk for leaks and/or even worse, deadlocks. No matter of it was blocked in one libc function. The function is not one instruction you don't know what the poor thread was doing when it was killed.
Do you think that issues being discovered in 2018 with 2 planes and 346 people lost and systemic safety issues persisting since then qualifies as "relatively quickly"?
You are right, that is not remotely "relatively quickly", it should have been prevented.
My point was generally that the system (and specifically the current flavour of capitalism) is not fundamentally broken, it has the right shape of components and they are working roughly how they are supposed to, to balance each other. If it was broken, things would be way worse, as we have seen throughout history. But there's so much to improve.
I guess I am looking at it from a too wide lens. Sure things are working much better than they used to a century ago, such disasters were largely accepted as a normal cost of being productive, there was no system to correct them. But that's no excuse, I do agree with you, this Boeing mess was not acceptable, the system needs to do better.
Sure, I even have a similar taxonomy of foods. I think of pizza as high tech good. You need agriculture, all the knowledge of yeast and fermentation you need cow farming, cheese making, meat curing for the toppings etc. You need centuries of knowledge and an entire economy to make pizza. Compare all that to grilling a steak or making a fruit salad.
Apple is actually bigger by employee count, however about half (I think) are retail employees in the stores.
So yes - a very large organisation. However Apple's chip design teams are much, much smaller than that. And because Apple mostly doesn't do chip design those teams are likely able to work like a startup, without much internal politics or in-fighting. Where as all of Intel's 100,000+ employees are basically devoted to chip design and manufacture.
Apple as a whole, though, is starting to look rather sick from the same sort of problems that Intel has. Under Jobs there was an energy and clarity of purpose that's been lacking for some time. The drift in Apple's core businesses are obvious. The iPhone has been stuck in turgid incrementalism for a long time now, and has already been largely "disrupted" by Android which sold into cheaper markets and used that to fund R&D budgets that match Apple's. We don't think of it as disruption because Android arrive so soon after the iPhone and thus there was no obvious delayed "disruption event", Apple just had their market share capped by the refusal to compete on price, which is why Apple fans have for years been forced to make arguments about why Apple is successful because they take a larger profit margin than others.
Their core Mac business has also been adrift for many years now. I and many others actively avoid trying to upgrade because things frequently get worse rather than better. The first decade of the century saw constant innovation in the Mac business, after all their best people were reallocated to the iPhone and iPad, quality entered a long period of decline. macOS releases struggled with regressions and rarely introduced new innovations worth caring about. Their apps and hardware have also stalled with own goals and unforced errors like the keyboard fiasco <looks at butterfly keys with holes in the plastic from ordinary levels of use>.
Developer experience and docs are another area of problems, there was a good rant about it posted here the other day.
All these are due to organisational rot, and most obviously, a form of in-fighting between iOS / macOS in which the iWorld got the best people and resources, leaving macWorld to pathetically try and steal things from the other group occasionally, regardless of whether it made sense for a laptop context or not.
I get the idea that Apple's culture of secrecy applies just as much to internal projects. So while the total headcount is huge, the headcount involved in any given project is small, and unlikely to be affected by the rest of the organisation because they don't know about the project.
A pretty good summary of the state of C++. I actually enjoy the language and most of the new features. The 'modern' part is not at fault here. This has always been a problem. The cult of generic metaprogramming was always a pain to deal with. In part, the new language features can help reduce over reliance on templates. As a community we must push for features that can get is out of this situation, like a sane modules system.
I think Bjarne Stroustrup is partly to blame here. He has succeeded in creating a versatile and popular language but has given little priority to problems like build time, error messages and debug performance. These sound like petty, practical problems that the tooling guys should eventually figure out. Except they aren't. They are hugely dependent on the language design.
Another thing we are missing is a high profile figure that will show the way on correct patterns and that will literally publicly shame the authors of too "meta" template heavy libraries. You are not smart if you are writing these monstrosities. It should not feel good. Making it simple requires much more intelligence.
> The cult of generic metaprogramming was always a pain to deal with. In part, the new language features can help reduce over reliance on templates. As a community we must push for features that can get is out of this situation, like a sane modules system.
The "cult of generic metaprogramming" is the very community pushing for those features.
> literally publicly shame the authors of too "meta" template heavy libraries.
This is pretty harsh. I agree that metaprogramming abuse in application code is a problem, and it's not something that should be advocated. However, there is a big difference between promoting C++ literacy and saying "everyone should commit metaprogramming code at work". The blame for metaprogramming abuse lies _squarely_ on engineering teams with poor quality control, not on library developers who like to push the language to its limits in their free time.
Everyone knows that C++ is a language of footguns. Metaprogramming is one of them; Boost is a mixed bag. Every successful C++ engineering team enforces coding standards to address this.
She explains that: the converter outputs a size and a stream of rgb values, which are easy to parse and verify, and the worst thing that could happen is you get a bad output image.
