[dspillett]

> I used a dual boot configuration back in the day and found the Windows experience a lot more efficient than the Linux desktop then.

That was often due to driver support, some hardware not performing as quickly (or sometimes not being as stable) under generic OSS drivers compared to their behaviour with the manufacturer's proprietary binaries (which were quite likely not available for Linux at all). It could be very hit-and-miss, with two otherwise very similar machines performing quite differently due to one controller on the motherboard. Sometimes it was due to the generic driver not knowing for sure that a given device supported faster modes well so erring on the side of caution, a not uncommon example being a drive/controller combination ending up running in PIO mode or an old DMA mode despite supporting something much faster, in which case you could get the performance back with a little “magic” configuration manually telling it to use that better mode.

Generic drives in Windows often had the same problems, but manufacturers tended to make device-specific drivers readily available (usually in the box) for those OSs.

Other times it came down to differing defaults for things like cache modes (write-through or write back, etc), power-saving options, and so forth, which again could be tweaked with config (though the discoverability of these config options was typically not very high).

[bzzzt]

It was also the awful amount of indirection of X(Free86/org) which made sure you had to jump through hoops to get anything on the screen. Even with accelerated hardware X doesn't feel as fast as Windows/macOS due to the insane amount of round-trips for perceived 'network transparency' which doesn't work that great and almost nobody uses.

I find it very disappointing some people are still fighting Wayland which, while not perfect, at least tries to get Linux desktops graphics stack 'on par' with macOS versions from 20 years ago...

[dspillett]

> 'network transparency' which doesn't work that great and almost nobody uses.

Works fine enough, and I use it occasionally to this day (though it is replaced by other things for many tasks these days).

[bzzzt]

Most clients using client side rendering which uses an awful amount of bandwidth and performs bad compared to VNC/RDP is not my idea of 'fine'. Especially not if it's used to justify opposing a better solution.

[dspillett]

For distant remote access with particularly animated or graphically detailed applications, perhaps. Though I'd not argue VNC as being lower bandwidth except where you've got it tuned to massively compress to the point where things that are bad through X are bad in different ways through VNC. RDP usually does better in this respect, as do some less common protocols.