Hacker News Reader

I've installed a clean windows 11 on some okay hardware a few days ago (i7 10750H, 32G ram, two 5GB/s NVMe SSD, GTX 2060) and everything is so astonishingly slow, at first I was mad but now I'm just utterly amazed.

I'll sometime wait three seconds for the explorer to open. Launching any non-trivial app takes on average 10 seconds. Sometimes copying stuff from a disk to another will show the incredible speed of 2 MB/s on stuff that should be literally instant. I have to wait for git which literally never happens to me on Linux ; just opening an MSYS shell lags (it's just a console and bash ffs!). MsMpEng.exe uses 15 - 20% CPU constantly even when turning every A/V shit off. And let's not even talk about usability - I got stuck for some reason with keyboard layouts that I didn't install, and apparently in Win 11, by default, not less than THREE SHORTCUTS will switch between layouts - ctrl+shift, alt+shift and win+space, which made coding absolutely insane until I could find a way to the "advanced keyboard settings" where the "alt+shift" shortcut could be turned off (which apparently also automagically turned off the "ctrl+shift" one).

And I could find hundred of messages on boards complaining about this, with "Microsoft MVPs" answering with the most generic and useless advice like "chkdsk", "do a check from your bios", "update your drivers".

Linux on the same hardware absolutely flies even when ran from a USB 2 stick, with as much eye candy with e.g. KDE Plasma.

And let's not talk about C++ compile times which are insane in Windows with the exact same compiler & toolchain (clang 16, libc++, lld...) compared to Linux, even when taking care of installing it on a separate drive, excluding the whole drive from virus scan...

My work laptop runs windows. 16 core 3.4GHz I7, pretty respectable. It should be, it's brand new.

C++ compilation takes more than twice as long as my Linux server from 2010. It's got two 16 core Xeon 2600-something processors at 2.6GHz. GCC doesn't even fully load the processors, it's something like 70% average and still runs twice as fast.

Fortunately, the exact details of my job have changed and I can switch to Linux soon. If my work machine still can't compete with my server, I can just slap distcc on it and use my server as a remote compile node. Might do it anyway, the compile is 'only' five minutes on my server, if I can combine these machines it'll likely halve again.

I don't run windows seriously anymore, but on small tablet level devices i've used recently, disabling everything in the "security" menus will significantly speed up windows.

In particular disabling MS defender (or whatever its called this week), will provide a massive increase in disk speed as its not longer scanning every single thing your reading off the disk.

This isn't so much NFTS but all the filters/etc that windows now comes with. In the past you would only get this behavior if you installed norton/mcafee and let it turn IO problems into CPU bound ones, but now its mostly unavoidable on windows. While your linux machine probably doesn't even have an always on virus scanner available.

Last time I ran windows on my personal machine, I saw the same thing. Unfortunately my work machine has workgroup policies that prevent even temporarily disabling Microsoft McAfee

That'll probably be NTFS shafting you. It's terrible at handling small files.

Trick I found was to fire up a Linux VM and do your compilation in there.

Also Windows file handling in general. It's incredibly flexible, allowing an arbitrary number of drivers to log or modify every disk access. That's great if you want real-time antivirus software, transparent file encryption (without encrypting the full partition), data-loss prevention software, advanced file syncing etc. But it also makes workflows that access lots of small files very slow.

Instead of a VM you can also use WSL2, assuming you put the files in the linux file system instead of accessing the host file system. (Yes, technically that's also just a fancy VM running in Hyper-V; but it's a more integrated experience than e.g. VMWare)

Yeah, granted the server is running a zfs pool on 7 mechanical SAS drives. But the windows machine has an nvme drive so I thought it'd even out.

Looking into compiler optimization, I can tell it's a very deep rabbithole that I'd rather stay away from if at all possible

I actually hadn't even thought of that. I'll have to see what performance on a VM is like these days, maybe it'll be enough to do my normal daily work?

Last time I tried that was back in the windows 7 days and VMs were almost unusable.

If you provision the whole disk up front i.e. reserve space then it'll be near native. That applies to Hyper-V, VMWare Workstation and VirtualBox VMs.

WSL this is not necessarily the case. I don't use WSL for a number of reasons including that.

It’s just economics, really. 1GB of RAM was unfathomably expensive back then so if you wrote software requiring it you’d be dead in the water.

These days RAM is cheaper than development time so instead of writing tightly memory controlled programs in C we write in e.g. garbage collected JavaScript. It's easier to learn and quicker to develop with. Part of me is broken hearted that the “art” of efficient programming is lost but it was an inevitable consequence of software becoming so central to our lives.

(and hey, that same discipline does still exist today if you want to dabble in it, in embedded spaces etc)

I also feel "back then" it was quite easy for a enthusiast machine to be quite well past "top of the line" whereas now we've been in the 2-4GB "standard" for so long that most people have it - it's decently hard to have something surprisingly faster than "top of the line".

E.g, I remember "recommended specs" for computer games that would ask for 64 MB of RAM; I had 128 MB.

Something like 16GB is or exceeds recommended specs for most desktop things... But some people are running 64 or 128GB in their desktops. So, I think overkill computers are still out there. It is pretty hard to get ahead of CPU specs now though: used to be you could get server chips (and a server/workstation board) and have something that was clearly better in every area other than price. Now, desktop sockets get new architectures before servers, and server chips have more cores, but usually lower clocks and not everything will scale to more cores in a way that makes that better.

That’s the main thing I feel - individual core speed is almost always the determining factor for “teh snappy” on modern desktop/single user systems.

> 1GB of RAM was unfathomably expensive back then

Well ... about $6k which wasn't astonishing for workstation budgets. These were machines that many people used to run software that cost $100k/year.

A credit to the incredible expandability of this era of Precision Workstation machines is you could have expanded the model 620 to 3GiB of main memory, which isn't bad at all. With 2x Pentium III Xeon CPUs and 3GiB you could credibly use that machine today. All that RAM only costs $75 today.

I'll sound like a miserable old bastard here, which I am, but I'm all for bringing back Gopher and banning any non native applications on a platform. Electron I'm looking at you.

All the native apps on my Mac desktop, an ass end M1 mac mini, are really really damn fast.

The moment I put windows, any managed apps or anything web based or wrapped web applications near any computer, a world of pain opens. It's mostly energy sucking buggy crap which serves the developers more than the customers. That's a cancer in the industry which is only going to get worse when we ship towers of excrement on top of WASM.

I have pipe dreams of using Serenity OS as my daily driver.

Also, I advise you to try Haiku OS Live CD. It’s refreshing.

I was a BeOS user for a few months back in the day. That would be perfect but no I need to use things which are on macOS.

My first PC was a Pentium 90 with 16MB RAM in 1994. I bought it specifically to run Linux. I've never really used DOS/Windows as my main OS on my personal machine.

Everything was fast back then. I had X11, Netscape, ethernet in the dorm. In a lot of ways I prefer the simple text heavy web pages of the time.

I've been designing integrated circuits including many chips in popular smartphones, network switches, and more. We make stuff faster but software manages to expand making my 8 core CPU with 64GB of RAM feel about the same when web browsing compared to back then.

I don't want to go back to those days but in many ways my computer with multiple X terminals, XFCE desktop, and Firefox, is extremely similar.

Even years after that Netscape would crash without any error messages and vanish multiple times a day. The past might have been good but we take so many things for granted today. Even if a browser crashes, it usually keeps all your tabs intact when you start it back up.

Something disappears into the ether every couple of years these days, but losing most of a day's work to a crash or some fat-fingered muscle memory back in the day didn't used to be an uncommon occurrence at all.

There are a few things 1) the tradition of tight code writing has been abandoned in favor of fast deployment, to the point of people expecting day 0 bugs in software. 2) webpages themselves are bigger. 3) latency from webloading trained people to expect it locally, and a lot of apps are just wrappers around what are effectively webapps.

A couple things: your fonts render better, your text is in Unicode (may not be a big deal for Americans, just trust me that I care that I can write reliably in my own language), your kernel has to support many more abstractions.

But the real issue is that the browser does a lot more than it used to and languages with JIT compilers and automatic memory management are just going to have a much higher overhead than C++. This is doubly true when the languages are non-typed and ultra-dynamic like JS.

For a while I browsed the internet without JS enabled and sites that didn't break loaded without any visible delay.

> What has happened that our web browsers use 2G of memory and are slow!

They are much more complex - ridiculously so - both because of the constant evolution of web standards and because of everything they need to do to keep what they execute in its own sandbox.

It doesn't help that the actual content being served just keeps on bloating. Think back to the average web page in the early 2000s: it was probably still browsed over a 56k modem, CSS was starting to get support, and if it might have had a few inline images it was still mostly text embedded in plain HTML. Web apps were CGI, JS was used sparingly, and people were still using frames.

Those pages were positively anemic when compared to what we sling around nowadays. 1 MB used to be a lot of data, and it just isn't the case anymore. You have layers of abstractions piled up on each other, isolated from the rest of the system as much as possible, slurping in, parsing and rendering multi-megabyte compressed, encrypted blobs.

But yes - it is a shame. We are doing so much more to achieve pretty much the same thing, and I keep on asking myself if we really need to.

I can also add mandatory TLS to this list. Back in the day you could receive an entire webpage response in the first TCP packet with data. TLS requires more turn-arounds, especially if webpage uses multiple different domains, and network latency is not going anywhere, it's physics. I had 200 ms latency in 2000, I have 200 ms latency in 2020, I'll have 200 ms latency in 2050, that's just thousands of kilometers to travel.

Latencies have gotten better, although not tremendously so.

Depending on your last mile tech in 2000 and what you have now, you might have gone fron dialup with first hop round trips of 50-100ms, to something in the neighborhood of 5-25ms with fiber, dsl or cable. Or maybe you were already on dsl or cable and things are about the same.

Most of a 200ms round trip is on a long distance route, and fiber routes have improved, as had routing equipment in the data path. If you're outside the US and Europe, there's been a lot more local interconnections too, so routes that used to bounce through US/EU in 2000 don't in 2023.

Saving a few ms here and there adds up, but 160 ms instead of 200 ms doesn't feel that much different.

Well, part of the answer with respect to web browsers specifically is that we keep 100 tabs open and websites are often very bloated with respect to advertising-related components in particular. Security-related features probably also add some degree of overhead.

If I just want to run something simple locally on a stripped down version of Linux it would probably be pretty fast and resource-efficient.

Less resource pressure. No need to fit in 64 MB when you have 2,000 MB.

Less experienced programmers (only know the latest thing; promoted to mediocre project leads... while the Old Guard doesn't pass on their knowledge before retiring)

Poorly documented code resulting layered workarounds (MS code from the 80's and 90's was hot garbage in terms of comments; source: I worked on Win95 diplay drivers and didn't comment any of my 16-bit VXDs. See previous gripe about O.G. being bad at documentation)

Bloated libraries (ironically, reluctance to jettison old code that is not well understood, so patch around it and keep dragging the baggage to the next release.)

Insufficient test suites causing too much bloat (see previous comment).

More complex APIs (spywhere and integrations everywhere).

I haven't walked the Windows source tree in 30 years, it would be fascinating to see a breakdown of the kernal linker map summaries.

One thing that people overlook is just stuff like screen sizes. Back then your laptop was 640x480. Now it's 3840x2160, 26 times as many pixels to push. Just a single 4k framebuffer will take up 32 MiB, you are gonna need at least two (and your system might even want to use 3) so you are looking at 96 MiB of memory right there. And this leaks into everything - just keeping a single display fed at 60 Hz takes up 2 GByte/s of memory bandwidth, more than half of what your dual-channel RDRAM setup could even deliver.

While there is some truth to your point, you have to remember that resolutions where already pretty high in the 90s (CRTs, not LCDs); I remember using 1024x768 as the standard, and it only required something like a 2MB VGA card. Part of the reason we had these huge framebuffers and still work with a minuscule amount of RAM is cultural. Programs (GUIs, games) would just NOT store a bazillion copies of the framebuffer, but rather only one or two (and mostly in the video card itself), and would prefer to scroll or redraw rather then to save/restore contents of the framebuffer whenever possible.

One pretty obvious example happened in the 2000s where the major 3 operating systems switched to desktop compositing almost simultaneously. You suddenly jump from requiring memory for just one framebuffer to requiring memory for one framebuffer + a copy of all the windows you have created.

I've posted about this before, but people forget that we used to worry about bit depth for the framebuffer and available VRAM. And back then, such a low-RAM card was only doing 2D acceleration at most, with a little offscreen buffer for fonts and sprites that would be blitted into the active framebuffer or composed at the DAC by the card itself (like the cursor).

Just for your example, 1024x768 would require a minimum of 3 MB just for a single buffer of pixels if stored with today's typical 4-byte RGBA and updated in immediate mode. A double-buffering technique would take twice as much. Most often, we were using either 8-bit pseudo-color mode or maybe 2-byte 15-bit true color with only 5 bits per RGB component and no transparency. A 2MB card might support 1024x768 in 15-bit mode or 1280x1024 in 8-bit mode.

I distinctly remember on my first serious Linux machine when I downloaded a single large JPEG image from an academic site and displayed it with the "xv" command which was the go-to image viewer at the time. It required virtual memory swapping because the image buffer to store the decoded image would be larger than my entire 20MB of system RAM. This was an unusual image, interesting to me mostly for this fact. As I recall, it was a high resolution scan of an ancient manuscript.

I find this line of thinking very interesting. From above:

> And this leaks into everything - just keeping a single display fed at 60 Hz takes up 2 GByte/s of memory bandwidth, more than half of what your dual-channel RDRAM setup could even deliver.

Does anyone know how practical are any countermeasures, for instance is tinycorelinux tinyx working for anyone?

I’m particularly interested in all the used Chromebooks floating around and what are some ways to trick them out with customized Linux.

The sad part is the younger generation who think a glacially slow multi-core supercomputer is normal as they have no point of reference for the performance capabilities of older hardware that have been lost due to bad dev practices.

Do you also remember that Netscape Navigator was hot garbage? It was so bad that people would brag about how stable their OS was by how well it handled Netscape crashes.

The first computer I felt was fast and responsive is my current MacBook Air M2.

But in all honesty, I haven’t worked with my own personal computer in years. I mostly worked on corporate Windows computers and my last Mac was a latest generation MacBook Pro 16 inch with corporate installed malware.

[Author/submitter here]

> I only spent about 1 hour playing round. But it left me distraught.

I know what you mean.

One of the biggest shocks I've had recently was researching this:

https://www.theregister.com/2023/07/24/dangerous_pleasures_w...

> What really is the software progress in last 20 years?

It has become significantly cheaper and easier to build software.

That has come at the cost of an enormous complexity paid by hardware and reliability.

I question the reliability part. Certainly there is more complexity (in some respects), more dependencies, etc. But I'd probably argue that most of the software I use today is more reliable than equivalent software (if it existed) that I used a couple decades ago.

Browsers are doing insane work very efficient: rendering pages of true type fonts and ultra res images while executing hundreds of js per second in VM and transforming page layout according to dynamically changing CSS rules. For all 10-100 sites opened at once.

It is Linux that now slow and bloated, not speaking of layers of GTK lard that can not render a window with simple controls without consuming hundreds of megabytes.