@silhouette The last version of Windows I used before going to Microsoft was 2000. I gave up when XP came out and was worse than 2000 or NT4 and switched to a mix of OS X and FreeBSD. A few years later, when everyone was saying how much worse the new versions of Windows were than XP, I knew I’d made the right choice.

I decided to give it a fair go at MS, but they haven’t really fixed any of the things that made me leave in the first place and they’ve made a load of things worse,

@silhouette @david_chisnall

I have to admit I have these thoughts completely seriously whenever I fix my mum something on her machine (no, I won't switch her to Linus; she is over eighty, she managed to learn using Windows once and I don't want to torture her by learning anything new). Why do people do it to themselves to use system like that? It is just a horrible user experience!

@wolf480pl @david_chisnall

This happens by itself if you try to use it as daily driver.

Most of the time, doing simple tasks like e.g. finding a string in a file requires you to search the internet for a program that supports this special purpose, then install it.

When that more or less works, you can get into the advanced stuff: Finding and trying out drivers until you find a combination that works for you.

I think one major problem is that those Microsoft operating system people try to solve everything with a GUI, making even simple tasks needlessly complicated.

@amy I learned that accidentally. I was discussing how to adopt a security feature in NT and someone on that team casually mentioned third-party drivers (including antivirus) running things in interrupt handlers. The more I learned, the more horrified I was. On FreeBSD and XNU, interrupt handlers do one thing: wake a thread (or some work-queue equivalent). The thread is then preemptive. A small number of things run with interrupts disabled but it’s very rare in drivers or subsystems outside the very core parts of the OS. In Windows, the driver model seems to encourage people to just do the real work in interrupt handlers. So your USB camera is stalling a core (and whatever thread is currently trying to run there) for ms at a time, and so are a load of other kernel things.

Even FreeRTOS discourages this kind of thing, and it’s designed for a use case where it isn’t a terrible idea.

In CHERIoT RTOS we formalise it and bind interrupts to futexes, so the only thing that happens in an interrupt handler is that one or more futexes get woken and then we may make a scheduling decision if any of the woken threads are higher priority than the one that woke (on our chips, we have designed the interrupt controller so that it can avoid raising an interrupt if it wouldn’t result in a scheduling decision).