The concept of applying some kind of Apple-ish texture finish to metal is an idea. A research-heavy, highly specific, finely tuned, multiple step, trade secret, brand signature metal finishing technique is a painting.
Mac market share is closer to 20% when you exclude machines installed in offices and enterprises. Some estimates put the number as high as 30% in North America.
The fact that the Steam number is as high as it is, despite the extreme lack of compatible content, is noteworthy.
Any problems are inherent in the left-right metaphor.
To speed-run your second paragraph: (1) Absolutely the median person for any given question. (2) Suggesting that there's anything "neutral" about a median position is to catastrophically mix metaphors. They aren't remotely synonymous. (3) The failure of a highly partisan person to acknowledge gradations doesn't mean they don't exist.
Reality doesn't have a left-wing bias, it has a liberal bias.
(FWIW my experience is that while Grok is more likely to express the right wing perspective on a topic, it's almost invariably as a counterpoint alongside the left wing perspective. I never got it to give an exclusively right wing take. But I do have to regularly prompt ChatGPT et al to elucidate on the right wing view. IMHO I don't want AI to have a left OR right wing bias. Wherever there is a genuine political — not factual — dispute, teaching the controversy is the appropriate response.)
Not strictly a recommendation, but Terramaster is a good brand to look at if you want Synology-shaped hardware which can run TrueNAS or Proxmox or any flavour of Linux you want.
Along with various other devices (including a large Synology which I wouldn’t buy today), I run Proxmox on a small two bay+two nvme Terramaster. I have a bare bones Ubuntu LXC running Samba configured for Apple Time Machine, an VM running Scrypyed, and PBS for Proxmox backups. Nothing on it is critical so I don’t bother with any storage redundancy.
It makes perfect sense to ditch LLVM in development contexts, as its slowness is antithetical to developer productivity — most obviously in tight edit-compile-test loops. And this becomes orders of magnitude more salient when the edit-compile-test loop is being driven by AI.
But even when languages are described as "moving away" that usually means building their own very fast-compiling/min-optimising x64/ARM backend for development builds, while still acknowledging the need for LLVM for highly optimised release builds.
“Doing no domain modelling” is not really an option. It just means the domain model emerges accidentally from ad-hoc interfaces, conditionals, database fields, validation rules, and UI assumptions. Asking an LLM to help with domain modelling isn't ideal, but it's strictly superior to having your model designed by accident, informed primarily by the initial rough draft of your application code.
Generally speaking if an ORM is a good fit, the thing you're doing probably isn't database development, it's application state management disguised as database development.
For a video game, simulation, CAD program or other stateful program, loading an object graph can be natural. In that context, an object store, document database, serialized state, or ORM-backed persistence layer may be a reasonable fit. This isn't database design, it's application design.
But in data management applications, the job is to derive specific information from stored facts. For that, SQL is not an implementation detail behind objects; it is the main abstraction. The whole point is to ask for the shape of data your application actually needs, not to arbitrarily hydrate objects and reinvent a bespoke querying engine on the client side. I can barely even remember the number of times that I've ripped an ORM out of a system because the code to interact with hydrated objects had devolved into a single-purpose database engine, a sprawling mess of code, seemingly well organised into objects, but ultimately wasteful.
Often, de-duplicating in code is a perfectly fine solution, and significantly more performant than multiple round-trips. A join that repeats parent columns is not a flaw in SQL. It is only a problem if the application insists on rebuilding a nested object graph instead of asking for the shape of data it actually needs.
If the data returned by the query does not match what you are presenting, the answer should not be to fetch a pile of related objects and interrogate them in memory. It is to use more SQL to further digest the data so that the result set more closely matches what you intend to present to the user.
ORMs and schema design are not fully orthogonal. A database schema and an ORM model can be conceptually separated, but in practice they influence each other. And even if you are vigilant, knowing that you'll use an ORM will cause you to obsess about things which satisfy the ORM at the expense of good modelling.
It cannot be anything but coincidence. While 365.25 days in a year is physics, a day consisting of 86,400 seconds is an entirely arbitrary human construct.
If you just want to store and retrieve objects, and then store and retrieve "related" objects, what you want is an object store, not a relational database. You can use an ORM to shoehorn it into a relational database engine, but don't fool yourself into thinking that's the same thing as using a relational database engine properly.
Obsessively cramming tabular data into objects is often unnecessary, and it bloats the code downstream of the database query. It then encourages the bad habit of performing data manipulation in code rather than directly in the database.
"Fetch related objects" is a code smell. If any related data was needed, your original query should have already fetched it.
As long as you restrict yourself to an ORM-compatible schema, you are restricting the power of SQL available to you. Learning SQL properly means learning to model your data correctly, and this usually makes ORMs a non-starter.
Without an ORM you have to write a bit more boilerplate code to interact with the database. But by taking advantage of the power of your database engine, you could potentially avoid writing huge amounts of data manipulation logic. In my experience, an ORM is more of a code amplifier than a code simplifier.
My point is only that testing on any non-free platform involves jumping through non-free or non-legal hoops. Testing on a variety of platforms/clients shouldn't be considered a chore. It's a necessary part of having a truly open, truly free web. Don't complain that you have to buy an Apple device. Say thank you. Seriously.
Diversity — not choice — is what keeps the web truly open and truly free. Enforced diversity sometimes sucks for the individual but necessary for the healt of the ecosystem. The "choice" of Chromium everywhere isn't a choice, it's forcing everyone into a monoculture. When everyone is expected to use one browser engine, the open web is dead.
Because it cannot run Chromium, Safari on iPhone is the last refuge of the truly open and truly free web. Steve Jobs might be known for many things, but I think he's under-appreciated as a two-time saviour of the web; first by destroying Adobe Flash[0], and second by ensuring that one web browser couldn't dominate on all platforms.
[0] To this day I am utterly stunned that anyone in a community like Hacker News would think it acceptable that a significant chunk of the web was under the thumb of a proprietary, closed source binary blob. The death of Flash was necessary, righteous, and overdue.
I think that journey only feels inevitable if you start from the assumption that the application object model is the centre of the system. An alternative journey:
Hmm – I should model the data according to the domain, not according to the shape my application objects happen to want.
Hmm – maybe “related objects” are not things to auto-fetch, but relationships the database engine is already built to handle.
Hmm – now that my schema matches my domain, complex problems can be solved with a few lines of SQL, saving me hundreds of lines of application code.
Hmm – in fact, now I realise that many important operations can be performed without round-tripping the data through application code at all, saving me thousands of lines of application code.
https://en.wikipedia.org/wiki/Whirlpool_(website)