This article originally appeared in Facebook Notes. And you won't find it through an external search engine, so copying it here.

For reasons beyond my understanding, I decided to switch to Microsoft Windows 10 for a brief time to see how greener the grass on the other side actually is. I left behind the Fedora install I had for the past year (and before that I had had Ubuntu since 2005), so I was mostly exposed to Gnome 3 environment, all the goodies the default Fedora repositories could provide, as well as some packages providing extra multimedia codecs.

So I got a copy of Windows 10 Pro and...

Not really.

At first I had to fight a bit. It turns out that you can't reliably create a bootable USB drive of Windows 10 from a Linux machine. A direct write of a DVD image to the flashdrive got the Setup up and running, but it was unable to copy the files needed for an install. Unetbootin also failed.

So I had to go to a store and get a stack of blank DVDs for the first time in 5 years.

The installation went through, booted into a 1024x768 resolution on a widescreen display, but as I was creating an account in the Setup the driver got installed and the panel switched to a native resolution. This was as unexpected as a message from CUPS back in 2008 saying that my printer was plugged in on my Ubuntu installation. It just worked.

Unfortunately, the vendors need to sell new stuff to fuel their R&D and show profit, so I found that my late-2012 Lenovo E420 does not have a seal of approval from Lenovo to run Windows 10. And I was in for a surprise to find that the system downloaded and installed the drivers for power management (-50% fan noise), sound card (+100% signal), video adapter (+50% visual clarity), and the touchpad (which as it turns out actually supports pinch-to-zoom, whoa).

Now, remembering that the quirks tables exist in Linux drivers for a reason, I was pretty sure that something just pretends to be working.

The UI the system booted to was familiar. The Windows Start menu I used back in Windows XP days was gone, the replacement live tile thingie was not shocking (I still remember the feeling of OMG OMG THAT FLYING FULL SCREEN INTERNET EXPLORER SIGN IN YOUR FACE METRO when I booted a preview version of Windows 8).

It turned out that for some reason the constant moving nature of these live tiles makes me uncomfortable. Whenever I saw some constant animation happening on my Ubuntu machine, I was almost always hearing elevated interest of the fan to keep the CPU/GPU temperatures down, so that was really a BAD THING. And that was not happening here. Probably that Power Management thing did what it was supposed to do.

Now, being still fresh after a reinstall I decided to see how well the muxless hybrid graphics is supported under the only system is was kind-of designed for. I have a hybrid Intel/AMD setup which I kept in integrated-only mode for the whole lifetime of my laptop, because that thing just does not work under Linux. The moment I tried switching either the kernel ABI changed, rendering AMD kernel driver useless, or Xorg changed an internal structure which the proprietary driver depended on, or something else equally frustrating happened.

So I went to the "BIOS Setup" and re-enabled Switchable Graphics.

The system booted into a native resolution and the fan started to make some noise. According to the process list, a Catalyst driver was in process of being installed (yay! Future! Drivers beamed to your device instead of hunting them on the world wide web). Then this window appeared, prompting me to recall the backward compatibility stories from Raymond Chen (the old new thing).

This time it was a friendly message from an unknown application. So I rebooted.

The OS booted into a 1024x768 resolution and stayed this way for a day.

Now, if I were running a Linux distro, I would go look at the Xorg log, see what kernel modules are loaded… But the Event Viewer was of no use. No graphics-related errors during the boot, Intel Graphics and Media control panel item just did not start and there was no debug output I could use to find out what went wrong. The device manager was displaying both video cards as being up and happily running, and the system info also showed two devices. According to the system, it was all perfectly fine. According to my eyes, they wanted to pop.

Binging for the answer (nope, "Binging" is totally not a word I should have used to describe a process of searching at bing.com) I found that nobody really knows how to get the reason of the failure (no usable logs), so the driver reinstall was the only thing that should have helped. Thinking that the best way to get to a known good state would be to switch back to the integrated GPU, I ended up with exactly the same 1024x768 setup, but the screen took a minute (yes, around 60 seconds) to start displaying something after a cold boot, restart, or resume. I made it worse. That's when I started reading about the compatibility of the drivers, and found out that my system is not supported.

Reinstall.

Yup, with no logs to diagnose, no way back to a good state (system restore brought me to the same configuration), no actionable items in C:\Intel, which for some freaking reason contained log files for some media-related service as well as driver installation details, and no support from the vendor, I decided to give up and reinstall.

Back to a single Intel integrated GPU. Yay, my eyes are thanking me. A couple of days later I attempted the same trick, but explicitly installing the Windows 8 drivers for the GPU stack. I got the Switchable Graphics menu on every folder in Explorer, got the control panel displaying stuff, but the screen startup delay returned, now measuring about 30 seconds. Since a laptop would suspend/resume quite often, I decided to go back to Intel integrated GPU.

So now I could do some other things in the system, like launching Cortana...

Unfortunately, no matter how I screamed at the microphone, the device picked up only some noise.

Remember the quirks I talked about before? Yup, it turns out that the driver Microsoft installed matches the device perfectly - the PCI vendor and device IDs are covered by the driver, but since manufacturers are honey badgers and they don't care about playing nice with others, the driver I had to download from Lenovo had some magic bits tweaked to get the mic working.

Oh, and then I had fun with the built-in Ricoh MMC/SD card reader too. You see, I had mixed success with it under Linux, with some cards being unreadable. It turned out that the driver is not included with Windows 10, but again, Windows 8 one is good enough. I was able to read all the cards. However, after a suspend/resume cycle I noticed that "System and compressed memory" process started chewing up CPU cycles like mad. Of course, no logs or direct documentation about the bug was discovered with Bing, so I went deeper.

Mark Russinovich wrote a wonderful "Process Explorer" - a fancy task manager for those who want to know as much as possible about the processes on their systems. It also showed an elevated usage in System. Having opened Properties / Threads I was told the offending thread is being busy spinning in risdxc64.sys, which was a Ricoh-provided driver. Disabling the card reader via the device manager immediately stopped the abnormal CPU usage.

I would have avoided all these issues if I used a supported system, but problems happen with any software. It looks like there is a lot of guesswork and magic involved when something goes wrong.

At last I felt I accomplished something. I closed the lid of the laptop and went to sleep, looking forward to more challenges from the OS I hadn't touched in a long time.