Back to Windows after twenty years

macOS doesn’t “require” scaling, it’s an optional feature if your display PPI is low enough that straight 2x rendering makes things look “too big”.

On my new XPS 13 4k, text is wonderful everywhere.

That's possibly my biggest grief with Edgmium. Chromium's (SDL-based?) text renderer is terrible on Windows compared to DirectWrite (the Window 8+ text rendering engine that replaced the crumbling GDI+ in the Windows OS interface and UWP apps but not ancient Win32 tech debt).

(I suppose it's also my biggest hope for Edgmium if they can somehow magic together a switch to DirectWrite on Windows, maybe that'd better the font rendering across Electron apps too.)

Subjective. I have a 4K screen and a 5K one, macOS text rendering blows Windows' out of the water. Linux is second (with some custom FreeType patch I forget the name about)

Not for me. Got a 4K thinkpad and text does look quite bad. On Windows UI, on Chrome, everywhere.

Same. This is utterly bizarre.

He somehow thought being a second class citizen in a second class OS would be better than just biting the bullet and buying one of the Dell developer edition XPS 13s that ship with Linux installed. I don't get it.

Font rendering in Linux is hilariously one of its strong points these days. Whether you prefer the OSX way of font rendering or the windows way, it's just a config setting. You change it to the way you like it and then it's the way you like it. There's no giant faceless organization trying to convince you that the "other" way of rendering fonts is objectively bad.

Also the Linux machines Dell ships all have 4k displays, and it's objectively difficult to render fonts poorly at those DPIs. That probably helps.

I use msys at work, despite WSL. It's just... easier. Haven't been able to get into powershell, but were I to go all in on the windows platform, I'd probably try to start there.

DHH (the original author) in the comments[1]: “I would like to try a good Linux laptop combo next.“

1: https://m.signalvnoise.com/back-to-windows-after-twenty-year...

As I recall, WSL1 uses NT's built-in personalities functionality to provide a Linux-compatible environment, but it still used NTFS which is much slower in the lots-of-small-files use case.

I know the rough high-level, and it's not necessarily WSL. POSIX programming does stuff differently than NT programming, the main or at least most noticeable design pattern being frequent process creation and lots of small IPC calls. On Windows this is slow. POSIX programmers also tend to set up directory structures with many small files. This is not necessarily slow on NTFS, but Windows' implementation seems to have many pathological edge cases.

There is also of course some translation overhead. That may be in the driver filter stack, though that is decently designed (it's close to having filter code pass over zero-copy state).

I think at the core it's a Ruby problem. Ruby is the programming language ecosystem I've never been successful in using Windows native builds of it. Ruby on Windows has long been a nightmare of kludges and it really seems to show how few Ruby developers must use Windows as a daily driver given how poor the support has always been for it.

(I say this as someone that used NodeJS when Windows native builds of it were an unsupported community project around the time of the IoJS fork and no one was sure Windows support would survive, much less be officially adopted. That was still a better situation than any time I've tryed to bootstrap a Ruby environment on Windows.)

Ruby is my primary and sometimes sole usage of WSL.

Yeah to me this just sounds like another case of trying to force Windows to be Unix. Its ok if you want Unix and are used to it, but to say Windows is no good because it isn't Unix is just wrong.

The author didn't even seem to try to learn the Windows ecosystem or tooling at all. He didn't check out Windows package managers (scoop or choco), he didn't try to learn powershell (which has a ton unix tools built in), and he didn't even try to use git on windows which can check out a repo just as fast as any other system!

Additionally, I dont think its fair to blame Windows for the Docker company's failure at making their product work on Windows.

I switched to Windows after uh, I don't know how many years, but a lot. The last version of Windows I used on my personal machine was 3.11 for Workgroups, I think, and since then I used various Linux distributions and OpenBSD, then ultimately MacOS because everyone else did and I lost my taste for swimming up that particular stream. I still use a company-issued Mac laptop at work.

Like DHH, I was "seduced" by the hardware; the Surface Pro just made sense to me as a personal machine and I was also "seduced" by the apparent ease of WSL+Ubuntu. I started down the path DHH did and was frustrated by some of the same issues.

At some point I realized that (just like with every other technology I've used) when you fight your tools, you're just giving yourself heartache. At this point I decided to start trying to do things the "Windows" way, or at least, the geeky Windows way. It's just not Unix.

I discovered Chocolatey and started to familiarize myself with the environment and--here's the major one--started making an actual effort to appreciate powershell. Once I started grokking that, I realized I needed to switch, so I switched from bash to powershell on all my machines (including the MacOS machine I use for work).

I'm going to geek out about different things than another user, but I haven't had a hard time starting with choco's ruby packages for ruby development. I'm an emacs and shell kind of person, and they both work great for me. I have had trouble building some native gems but these tend to be due to unnecessary problems in the gems, like finding libraries via shell commands.

As for fonts and the other things people are complaining about--well, it looks fine to me. I'll grant that this isn't something I'm deep into. Neither is VS Code, which I've played with a tiny bit and still don't really get.

There have been pleasant surprises like how nicely accessible the detailed system performance data is.

One thing I'll say is that a lot of why someone thinks things "just work" in MacOS (or there other platform of choice) is due to familiarity and luck. I've run into my share of things that don't, on every platform.

this is quite a subjective opinion, some people prefer crisp rendering, other prefer smoother edge (even if high dpi screen render this comparison moot).

Then with font hinting, I would agree, but I am mainly working on windows, doing non graphic work and looking at wall of text all day long.

They are solving Microsoft's problem, which is that they are frustrated they only get paid by this customer one time every five years. They would much rather this customer pay them every month ad infinitum or lose access to Windows altogether, which is what the whole push of Windows 10 towards "Windows as a service" is about.

But it'll take a long time to wear people down to the point where they'll accept renting their operating system, so in the meantime they're hungry for any other way to have Windows bring in extra revenue above that one-time $200 -- which is where things like Candy Crush ads in the Start menu, intrusive and inescapable data mining, etc. etc. etc. come from.

At Microsoft, they know that no matter how bad it gets, you won't leave. Just about everyone who might leave already did. Likewise, for Apple.

Having a customer base that will tolerate any abuse, no matter how bad, is worth way more to Apple and Microsoft than a base that is incrementally larger, but more demanding.

People who expect things to work well are what MBAs call a "cost center". Business school taught them that cost centers are to be shed, to the maximum degree possible. People who tolerate bad products and services are what the Business School professors call "cash cows", to be milked forever. (No, literally. It's there in the textbooks. There is no shame in Business School!)

Apple and Microsoft each have countless $billions in cash, a very small bit of which (1%? 3%?) would be plenty to make things work well, and keep them working well. But that would attract demanding customers, who would just expect better, all the time. Cost center!

Clearly, the status quo is what keeps the cash pouring in. Upsetting that flow would be a huge mistake: the most likely outcome, just from basic thermodynamics, would be less cash to divert into holdings. Nobody wants that. Anyway, nobody who matters.

So in answer to the question, "Whose problem is Microsoft solving?": Microsoft is solving Microsoft's problem, quite deftly, just as Apple is deftly solving Apple's problem. Apple is doing it better: they have people paying $1200 for a $300 phone, again and again.

Apple and Microsoft have only one remaining problem, Fafnir's: nothing on Earth is worth as much to them as their respective cash hoards.

Meanwhile, Google has picked up the strays. Their huge advantage is that you aren't even a customer; you're the product! Anyway your eyeballs are. The actual customers are more demanding, in principle, but much, much fewer. Google has to keep your eyeballs pointed at their screens, but they know everything about you, so they can automate a lot of that, and they don't even have to pretend to be trying to keep you happy; just attentive.

Moo.

If you notice a similarity to Spammers, give yourself a thumbs up. Spammers have to be extremely picky about their customers. Spammers need you to give them all your money in exchange for nothing at all. That is a very special customer, and they need to sift through millions to find each. If you are bothered by bad spelling or grammar, they know not to waste time on you -- you reject yourself! No, they want only the least discerning customers. Anyone capable of doubt has to be driven away in absolutely the most automated way possible. If a hundred people per million took up any time, they would need to find something else to do.

The difference between the spammer and anyone who sheds discerning customers is only degree, not kind.