Obviously if you're developing primarily for Windows, you're going to need to run Windows. I don't think that's what the person you're replying to meant by that at all, but rather that the Windows UX doesn't buy you, as the user of the OS, anything that Linux doesn't.
I never get to see same smoothness in graphics and fonts as MacOS/Windows/ChromeOS in the same machine with Linux.
Every single time I decide that I'm moving to Linux, I give up after living with the browsers for a day or two. Rendering and fonts are just inferior to other systems in my experience.
> I never get to see same smoothness in graphics and fonts as MacOS/Windows/ChromeOS in the same machine with Linux.
Well, Chrome OS runs the same stuff as your average Linux distro, however maybe most distros don't turn on subpixel antialiasing in their FontConfig out of the box. (I don't know because I've been sharing configs between machines of the same distro for about five years).
Some distros do not enable subpixel rendering indeed, due to patents and them being based in the US. The users have to download a -freeworld package then, if they want it.
With HiDPI, that doesn't matter anyway.
Another issue are fonts themselves. If you have a document that uses Arial or Cambria or another proprietary font, and you don't have it installed, you are going to get something substituted, which may or may be not metrics-compatible. Do not expect pixel-identical results then.
If I'm not mistaken, those patents are dead now. Even Fedora has the freeworld stuff now.
> Another issue are fonts themselves. If you have a document that uses Arial or Cambria or another proprietary font, and you don't have it installed, you are going to get something substituted, which may or may be not metrics-compatible. Do not expect pixel-identical results then.
Yeah, though the Chrome OS core fonts are good metric-compatible substitutes for Arial and friends (though lacking the stylistic variety of the core Windows fonts).
Not the subpixel rendering ones ("cleartype"). In Fedora, FT_CONFIG_OPTION_SUBPIXEL_RENDERING is still disabled.
Google also released metric compatible substitutes for Cambria (Caladea) and Calibri (Carlito), but Linux distributions do not install them by default.
Edit: I'm wrong. In F27, the subpixel rendering is enabled.
Sure it does, proper GPU acceleration, hybrid graphics support and hibernation that actually works, and UI/UX tooling resembling Xerox PARC way of computing, only beaten by macOS.
Well, you said you wanted "proper GPU acceleration", macOS GPU drivers are terrible. They're unstable, they have limp shader compilers, they are CPU-intensive, and in the case of OpenGL, they are behind by nearly six years in terms of features. Today, your sleek MacBook Pro supports considerably fewer modern GPU features than your average entry-level smartphone. You're missing stuff like multi draw indirect, texture clears, 8-bit stencils, image copying, explicit uniform location...
> hibernation that actually works
Well, I have that set up (and in my case it really has to be optional, since I have a really disk-scarce device right now). It worked correctly. I believe systemd will even monitor my battery and hibernate before it gets too low, like you'd expect (though maybe it could be brought out of hibernation enough times in a row to eventually run out of power before systemd gets to it). Maybe there should be a smoother transition between suspend and suspend-to-disk like macs with macOS have, but that isn't strictly necessary.
> Any capable of DirectX 12, but only gets OpenGL 4.3 drivers or similar on GNU/Linux.
What GPU is this? I don't know of a DX12 device which lacks OpenGL 4.5 support in a stable release of Mesa (or the blob, in the case of NVIDIA, since they are uncooperative with regard to firmware).
> Regarding OpenGL on macOS, I don't care, that is what rendering engines are for, and all relevant ones already support Metal 2.
Sure, if you're running only games, and those that were made before 2012, and after 2017, then that works fine. For an example of something that does not currently use Metal (2 or no 2): any web browser (to my knowledge, including Apple's own, except as a backend for the WebGPU prototype), professional graphics application, or visualization utility. The shader compiler is still subpar, even in Metal.
> Or my AMD Brazos one on a Linux netbook, DirectX 11 class, which only gets OpenGL 3.3 drivers.
IIRC Brazos in that range would be... Radeon HD 6330M, and you're right, that should support GL 4.4. If you're running Mesa from 2016 or later, it should have 4.1 (and most extensions, except compute shaders, up to 4.4), if you run AMD's blob you can probably get 4.4 on it today. Work on drivers for pre-southern-islands devices is slow these days, but anything after SI has full certified OpenGL 4.5 on Mesa along with every extension in in 4.6 except for SPIR-V loading (coming soon), and the performance is better in basically all cases than it is on Windows, or with the proprietary drivers on Linux (though for now you'll need the proprietary drivers for some features like FreeSync, which is unfortunate but oh well).
So basically working vsync, alpha blending, render to texture and some basic shaders like blur, where even Intel GPUs are overkill?
Then you are in luck; even Intel GPUs under Linux do support OpenGL 4.5. 4.6 is in the works, the only missing part is the SPIR-V support and I don't suppose you need that for fluent or material design.
Honestly, tooling on windows is in the range [complicated-unusable]. Higher order abstractions and OS specific optimisations just seem to get in the way when I'm developping.
I for one do not feel windows has a good story if you're developping anything you don't use VS for.
I swapped back and forth a few times and Linux worked for all of that stuff 5 years ago. I do .Net development so I tend to stick with windows. But, from a pure user standpoint Linux is more user friendly on compatible hardware.
This works with open source drivers, it's only nvidia that is gumming up the works here. With recent drivers it should even be automatically setup, although you still need to set DRI_PRIME=1 when running something you want on the discrete GPU.
