First Impressions: Lenovo T14s with Qualcomm Snapdragon ARM64 CPU

Yeah sorry. You're right, and when I read that I assumed the usual HN context of engineering == the kind of software engineering most often discussed on here. I see what you meant now. Here's where I was coming from anyway, reframed in the context of your comment:

Web dev is painful on Windows. NTFS really can't deal with 50k+ files in node_modules, I think it's something like 50-100x slower still. Not to mention that Windows by default _still_ tries to go and index your entire node_modules and silently poops the bed. This is one of the main reasons behind WSL's popularity, but that only works if you don't have your code on a mounted NTFS volume. Make the mistake of reopening the same repo you started working on in Windows in WSL2 thinking that you'll see an improvement & you'll bed disappointed - silently. You have to move your react project out of NTFS entirely and let the virtualised linux kernel manage those descriptors if you want to get work done.

macOS has a similar problem - not with NTFS but with Docker / virtiofs. Web development experience is generally awesome on macOS if you're working natively, but if you want to work inside a devcontainer (to maintain consistency with prod) and depend on Docker, it slows down considerably. I've heard that OrbStack and Colima have recently made this much better on macOS, but I've not tried it recently. But other more serious software development scenarios, where you want a might want a local k8s environment or you're writing lambda functions that you want to test locally? You have to use Docker and take the hit. In Linux it has always just worked (podman aside). Not to mention that Chrome's memory management is way better there than in Windows (thanks, ChromeOS).

For the rest of these please keep in mind that I explicitly said I was talking about quality of experience rather than quantity of people having to suffer through it, so the whole 'how many X people are on Linux when their manager makes them use Windows' argument is one I was specifically trying to avoid. With that said, I'll try to answer the rest of your qs:

> Anything graphics programming related. D3D and Metal are significantly more prevalent than OpenGL or Vulkan.

Agree almost completely - you wouldn't be building most graphics to run on Linux, so why not develop where your target platform is best supported. I disagree with your assertions around opengl or vulkan (see android), but UE5/Unity support in Windows vs elsewhere proves your point.

> Anything CAD related, because there’s next to no professionally used CAD software on Linux.

Agree, again obviously. In my case I love Onshape, and it works really well on Linux (apart from spacemouse driver support, which is a spacemouse issue not an Onshape one - there's no such thing as a class-compliant spacemouse interface and direct usb access for chrome would need them to implement a full driver; they invested heavily in getting a hack working on Windows but obviously not worth it for Linux, if for no reason other than that their target userbase will be extremely accustomed to Windows because of historical software availability and compatibility). But yeah, Onshape is an exception.

> Audio stuff. How many DAWs have a significant Linux user base?

Ardour supposedly has some recent converts, and the kernel is supposed to be acceptably good at realtime stuff now, pulseaudio/jack are supposedly better now. Regardless, you're right - it's too little too late. FWIW last time I did any real audio work absolutely nothing came close to CoreAudio (even on intel hackintoshes, or _especially_ on intel hackintoshes vs Windows on the same hardware). I don't think that has changed much since. RME drivers make a difference on Windows but WMI still sucks and ASIO on windows still isn't as stable as mac. Reaper officially supports Linux (<3 Justin F) but it's still dependent on Wine and yabridge, i.e. will probably never be on par. Reaper aside (which is a genius piece of software, on par with Samplitude 7 and Logic 5.5.1).

> And even beyond that, how many website devs are on Linux

Almost all of the ones I know, with a few of them still on Mac but curious. Literally none on Windows.

> Flip that around, why would someone use Linux to develop when they could use macOS? Can you give a non-subjective answer? Then try the opposite.

Hopefully I did that when I explained myself above.

> Even if you’re developing for Linux deployments, you can still do most of it local and then spin up docker in the VM on demand.

> The number of software developers who need to run a Linux VM on their Mac/Windows are a vast minority.

I think I already answered this, but for my (admittedly ignorant initial) definition of "actual engineering", unless you're targeting iOS or desktop development, _everyone_ is developing for linux as their primary target. Everyone.

I directly disagree with your final two statements, and that's kind of the point I was trying to make. For modern cloud/infra/saas/product/platform/web dev, i.e. the arguably subjective definition of "actual engineering", everything else is a compromise. Docker is, VMs are, WSL is.

Not to be flippant, but don’t your final two paragraphs boil down to : “if you ignore all the non-Linux stuff, everyone is on Linux?”

Also why is that the “arguable subjective definition”? Why are we trying to define “actual engineering” at all, even if subjective?

On what scale are you defining that? Users? Complexity?

Not to be rude, but it feels like “people in a Linux bubble are just reluctant to admit that there’s a wider non-Linux world out there”.

You said “most of the engineering discussed on here” but there’s tons of posts about graphics engineering. It just happens that web/saas is the most approachable end of software engineering. Again, and not trying to be rude, I think this is a case of being too close to the trees to see the forest. Are you perhaps only clicking on the links to subjects that are relevant to your domain knowledge?