The Apple Platform Security[1] white paper describes the secure boot process for Apple silicon. The Mac boot process is significantly more configurable than the iOS boot process, and it allows operating in reduced security modes. (Including running locally signed operating systems.)
Apple knows how to build an iPhone: if they wanted to lock down a Mac they would have simply done that. There's something like nine pages detailing the differences. What word describes that other than "intentional" design? The fact that you can sign and boot a third party OS isn't an "accident" if it's documented, and there's no "exploit" because this is functionality the platform supports; anyone can do it with tools already present on the (Apple-signed) recovery OS.
They certainly don't provide great support for people wanting to develop [drivers for] these operating systems, but the platform was very clearly engineered to support booting them.
>They think the process is “senior make ticket, anyone implement ticket, unga bunga”.
The fact that you just summarized about an hour worth of argumentation from my last annual planning meeting with that one sentence has just destroyed me. I kneel.
At this precise moment in time, if anybody seriously thought the above was the way the process works or should work, they should be advocating for firing all the juniors and replacing them with LLMs.
Somewhat agree and disagree. I bucket people's style into two camps, stressing over the former is largely unproductive, but stressing over the latter is crucial to writing high-quality, maintainable software.
Someone's style can be "different" without being "bad", and you have two basic options to deal with it. One is to authoritatively remove the soul via process (auto-formatters, code review, and to a lesser degree linters, etc. are all designed to create uniformity at the cost of individuality.) The other is to suck it up and deal with it, as this is just an inevitability of creating a team size larger than one: people have different tastes and those have to be reconciled. I somewhat prefer allowing for individuality, and individuals should endeavor to match the style of whatever module they're working in, out of courtesy to its owners/stakeholders if nothing else. However I have only worked independently or on small teams. Most large teams (/ open source projects) have gone the former route of automating all the fun/craftsmanship out of their systems, and even I think that makes sense at a certain scale.
Someone's style can just be objectively "bad", however, and I usually find it's evidence they just don't care about the source artifact that much, and they're focused on the results. (It can also be a sign of an under-performer that spends so much mental capacity just getting the code to work that they have no spare cycles to spend thinking about matters of taste.) If it compiles / works / passes the test-suite that's "good enough" and "their job is done" and they move on to the next task. These people tend to be hyper-literal thinkers that are very micro-task oriented: they see implementing a new feature as a checklist to be conquered, rather than being systems-level thinkers on a journey of discovery & understanding.
If the author is talking about the latter, I have to agree with you that the latter are quite difficult for me to work with; particularly since I know that the source has to be maintained & supported over a much larger time-scale. The source-code is like your house, you live in it, being comfortable to work with/in/on it is the key to success. The deployed artifact may live for only a few weeks, days, or even hours before it gets replaced. The source has evolved over decades. You (the organization) are practically married to it. To further the analogy: I don't mind if somebody wants to hang posters in their room for a band I don't like. (Hell I can even handle if a group of those posters are tastefully hung out-of-level to make some kind of statement.) I do mind if their furniture is blocking a vent, the outlet covers are hanging off, there's a hole in one of the walls, a light has been burnt out for months, and the window-blinds over there are clearly broken but they insist it's fine because daylight still gets through.
>Moderation will be extremely important to prevent low-effort memes and content regurgitation and the like from saturating your main channels
This idea more or less surfaces in the book "Fall; or, Dodge in Hell", where in the not-too-distant future the internet is so polluted that you are pretty much expected to hire a full-time "editor" to curate your social media feed. This doesn't scale particularly well, of course, so in reality particularly wealthy families hire an editor to present a cohesive stream of social media to their whole family-tree. Meanwhile the masses typically subscribe to an "off the shelf" stream (or several?) that most closely matches their tastes.
Apple knows how to build an iPhone: if they wanted to lock down a Mac they would have simply done that. There's something like nine pages detailing the differences. What word describes that other than "intentional" design? The fact that you can sign and boot a third party OS isn't an "accident" if it's documented, and there's no "exploit" because this is functionality the platform supports; anyone can do it with tools already present on the (Apple-signed) recovery OS.
They certainly don't provide great support for people wanting to develop [drivers for] these operating systems, but the platform was very clearly engineered to support booting them.
[1]: https://help.apple.com/pdf/security/en_US/apple-platform-sec...