3 ms·

I have a still barely usable HP MS200 all-in-one machine. I got it cheap at a garage sale in 2017. It wasn't fast, but with Linux on it, once Google Chrome wa

I have a still barely usable HP MS200 all-in-one machine. I got it cheap at a garage sale in 2017. It wasn't fast, but with Linux on it, once Google Chrome was finally loaded, it was OK, even to the point of running the web version of Skype for fullscreen video chats, certainly for watching fullscreen Youtube. It went off to the in-laws as a Youtube watching and Gmail station. Recently it came back to me. And with the old, 2017 vintage software on it, still worked as it did then. But before making it a kiddie computer, I installed FC38 and the current version of Chrome. But Youtube videos were now "slide shows". No amount of fiddling with the settings made them play right. Finally gave up and changed the RAM from 2GB to 3GB - I just happened to have the right (laptop) memory card to do that. And that brought it back to the old, barely adequate (720p fullscreen without noticeable skips) performance. 1.5x as much memory, an extra gigabyte, to do the same thing as six years ago. "So get with the program and buy an adequate machine! Don't you know that 16GB is the absolute minimum to get anything done these days?" Sure - I have machines with 16GB+ in them. Even on the crappy machine though, Google Chrome is showing a memory footprint on the order of 30GB. I'm sure most of that is mmap'ed files; it sure isn't RAM. But 30GB. For a mostly idle web browser.

MarkusWandel 3y ago
I forgot to mention this: Every time I install a new Linux system, I give the "factory" UI a chance before, inevitably, giving up and switching to MATE. Well, Gnome Shell was actually pretty crisply responsive on this clunker. And it has an "app store". And that has Chrome in it. Well well! But that installed a FlatPak. Bloat, bloat, bloat. Luckily Chrome is still directly "natively" installable as an RPM that actually uses the OS's shared libraries.
- WesolyKubeczek 3y ago
  Sure it’s using system ones and not the vendored ones? I mean chrome as packaged by Google, not, say, Fedora’s Chromium (which is bent and coerced to use system libraries as much as possible).
  - MarkusWandel 3y ago
    Good point, so I checked. It has a few private libraries but for the most part uses the system ones. I think I can paste this output without leaking anything personal... linux-vdso.so.1 (0x00007ffd353a6000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f852c4ea000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f852c4e5000) libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007f851eba4000) libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f851ea69000) libnss3.so => /lib64/libnss3.so (0x00007f851e92b000) libnssutil3.so => /lib64/libnssutil3.so (0x00007f852c4b2000) libsmime3.so => /lib64/libsmime3.so (0x00007f851e8ff000) libnspr4.so => /lib64/libnspr4.so (0x00007f851e8bc000) libatk-1.0.so.0 => /lib64/libatk-1.0.so.0 (0x00007f851e892000) libatk-bridge-2.0.so.0 => /lib64/libatk-bridge-2.0.so.0 (0x00007f851e859000) libcups.so.2 => /lib64/libcups.so.2 (0x00007f851e7ba000) libgio-2.0.so.0 => /lib64/libgio-2.0.so.0 (0x00007f851e5e0000) libdrm.so.2 => /lib64/libdrm.so.2 (0x00007f852c498000) libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007f851e58d000) libatspi.so.0 => /lib64/libatspi.so.0 (0x00007f851e550000) libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f851e51f000) libm.so.6 => /lib64/libm.so.6 (0x00007f851e443000) libX11.so.6 => /lib64/libX11.so.6 (0x00007f851e2fb000) libXcomposite.so.1 => /lib64/libXcomposite.so.1 (0x00007f852c491000) libXdamage.so.1 => /lib64/libXdamage.so.1 (0x00007f852c48c000) libXext.so.6 => /lib64/libXext.so.6 (0x00007f851e2e6000) libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00007f851e2dd000) libXrandr.so.2 => /lib64/libXrandr.so.2 (0x00007f851e2d0000) libgbm.so.1 => /lib64/libgbm.so.1 (0x00007f851e2bf000) libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f851e292000) libxkbcommon.so.0 => /lib64/libxkbcommon.so.0 (0x00007f851e249000) libpango-1.0.so.0 => /lib64/libpango-1.0.so.0 (0x00007f851e1e2000) libcairo.so.2 => /lib64/libcairo.so.2 (0x00007f851e0c6000) libasound.so.2 => /lib64/libasound.so.2 (0x00007f851dfb7000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f851df9c000) libc.so.6 => /lib64/libc.so.6 (0x00007f851dc00000) /lib64/ld-linux-x86-64.so.2 (0x00007f852c512000) libffi.so.6 => /lib64/libffi.so.6 (0x00007f851df8f000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f851df17000) libplc4.so => /lib64/libplc4.so (0x00007f851df10000) libplds4.so => /lib64/libplds4.so (0x00007f851df0b000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f851deb2000) libavahi-common.so.3 => /lib64/libavahi-common.so.3 (0x00007f851dea4000) libavahi-client.so.3 => /lib64/libavahi-client.so.3 (0x00007f851de8f000) libgnutls.so.30 => /lib64/libgnutls.so.30 (0x00007f851d800000) libz.so.1 => /lib64/libz.so.1 (0x00007f851de75000) libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00007f851de6e000) libmount.so.1 => /lib64/libmount.so.1 (0x00007f851de27000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f851dbd5000) libsystemd.so.0 => /lib64/libsystemd.so.0 (0x00007f851db03000) libXi.so.6 => /lib64/libXi.so.6 (0x00007f851de15000) libXrender.so.1 => /lib64/libXrender.so.1 (0x00007f851daf6000) libwayland-server.so.0 => /lib64/libwayland-server.so.0 (0x00007f851dae0000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f851d400000) libXau.so.6 => /lib64/libXau.so.6 (0x00007f851de0d000) libfribidi.so.0 => /lib64/libfribidi.so.0 (0x00007f851dac0000) libthai.so.0 => /lib64/libthai.so.0 (0x00007f851dab5000) libharfbuzz.so.0 => /lib64/libharfbuzz.so.0 (0x00007f851d729000) libpixman-1.so.0 => /lib64/libpixman-1.so.0 (0x00007f851d67d000) libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00007f851da66000) libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007f851d335000) libpng16.so.16 => /lib64/libpng16.so.16 (0x00007f851da2d000) libxcb-shm.so.0 => /lib64/libxcb-shm.so.0 (0x00007f851da28000) libxcb-render.so.0 => /lib64/libxcb-render.so.0 (0x00007f851d66d000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f851d257000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f851d655000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f851d64e000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f851d63d000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f851d636000) libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f851ce00000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f851d622000) libp11-kit.so.0 => /lib64/libp11-kit.so.0 (0x00007f851d125000) libidn2.so.0 => /lib64/libidn2.so.0 (0x00007f851cdaf000) libunistring.so.2 => /lib64/libunistring.so.2 (0x00007f851cc2a000) libtasn1.so.6 => /lib64/libtasn1.so.6 (0x00007f851d10d000) libnettle.so.8 => /lib64/libnettle.so.8 (0x00007f851cbd7000) libhogweed.so.6 => /lib64/libhogweed.so.6 (0x00007f851cb94000) libgmp.so.10 => /lib64/libgmp.so.10 (0x00007f851caf1000) libblkid.so.1 => /lib64/libblkid.so.1 (0x00007f851cab9000) libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f851ca1d000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f851c9f1000) libzstd.so.1 => /lib64/libzstd.so.1 (0x00007f851c942000) liblz4.so.1 => /lib64/liblz4.so.1 (0x00007f851c91e000) libcap.so.2 => /lib64/libcap.so.2 (0x00007f851d103000) libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007f851c7e2000) libdatrie.so.1 => /lib64/libdatrie.so.1 (0x00007f851d0fa000) libgraphite2.so.3 => /lib64/libgraphite2.so.3 (0x00007f851c7c1000) libxml2.so.2 => /lib64/libxml2.so.2 (0x00007f851c637000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f851c624000) libbrotlidec.so.1 => /lib64/libbrotlidec.so.1 (0x00007f851c616000) libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f851c5f0000) libbrotlicommon.so.1 => /lib64/libbrotlicommon.so.1 (0x00007f851c5cd000)
jeroenhd 3y ago
Youtube is a great example of the performance difference. Videos have risen in quality because of modern codecs, but old or cheap machines need to decode them in software (sometimes in Javascript, which is terribly wasteful but works on every machine) because they lack a modern GPU. On the other hand, for most devices, the increased battery life, lower temperatures, and smaller RAM/disk space requirements are obvious improvements. Youtube could leave duplicate files with the old encoding on their servers (if you use an alternative frontend for Youtube, you can often see the old file formats still being available for old content!) but that's just wasted space with most of the world visiting from more recent devices. Most RAM usage increases in Chrome have come from advancements in the sandboxing architecture. Shared memory and process space could be used to attackaand bust out of sandboxes, so more isolation was added. I'm sure there are some more useless features leading to a jump in RAM usage as well, but the really big ones always seem to be the fact Chrome spawns a new, independent process for every tab/extension. I've also noticed how much impact ad blockers have these days. With the web becoming ever shittier, effective adblockers have become harder to make and need more resources to do their job. Software doesn't get slower just to make your day harder. In many cases, slow software is a result of replacing dangerous hacks by good implementations and changing requirements. FLV videos just don't cut it anymore, and I doubt h264 will be around in five years with h265 and AV1 making it's way to more and more devices.
- smikhanov 3y ago
  Excellent remark. For each "I needed an extra gigabyte of RAM in my computer to do the same thing as six years ago" complaint there is normally a valid reason like this. It's always not exactly the same thing as six years ago, really. Oh, and the same applies to the original blog post, too.
- Culonavirus 3y ago
  AV1 is a massive flop in my opinion. What was supposed to be the be all end all open source video format of the future just recently barely starts to pop up here and there. There are tech demos and talks of Youtube etc. using AV1, but in the same breath they say it's mostly for really low bitrate where the AV1 gains the most. Also I'm sure no one is looking forward to burn CPU time (or very lately, GPU time) on encoding 4k+ streams. Is that even financially viable? You save 30% on bandwith and spend 10000% more on server HW time. (I'll admit that these numbers are pulled from my ass, but they're based on a few years old knowledge of AV1 encoders being like 350-3500 times slower than h264 encoders, depending on optimization.) The entire "there was no usable encoder and no hw decoder for years" thing didn't help and even now it's still all slow and complex, who has time and money for that? AV1 is just too complex for what it produces in comparison with the good old h264 or vp9.
aaaronic 3y ago
Web browsers in particular have become operating systems unto themselves. The "modern web" has so many features, often implemented in half a dozen competing ways... Just text rendering on modern hardware can be a HUGE lift. Modern toolchains are all about "not reinventing the wheel" -- but when each dependency has picked a different version of said wheel, just pulling in a few dependencies leads to 6 different implementations of the same low-level features.
- chankstein38 3y ago
  This is one of the reasons the announcements about WebGPU made me cringe. Yeah, just what I need, more unnecessary complexity added to webpages. Especially when there's seemingly a chance people will use them to mine crypto on my GPU while I'm on their page.
dunham 3y ago
I remember needing 8MB to run a graphical web browser with Linux/X11 (I believe it was Netscape Navigator). 8MB was sufficient, 16MB a bit more comfortable.

MarkusWandel 3y ago

I forgot to mention this: Every time I install a new Linux system, I give the "factory" UI a chance before, inevitably, giving up and switching to MATE. Well, Gnome Shell was actually pretty crisply responsive on this clunker. And it has an "app store". And that has Chrome in it. Well well! But that installed a FlatPak. Bloat, bloat, bloat. Luckily Chrome is still directly "natively" installable as an RPM that actually uses the OS's shared libraries.

WesolyKubeczek 3y ago
Sure it’s using system ones and not the vendored ones? I mean chrome as packaged by Google, not, say, Fedora’s Chromium (which is bent and coerced to use system libraries as much as possible).
- MarkusWandel 3y ago
  Good point, so I checked. It has a few private libraries but for the most part uses the system ones. I think I can paste this output without leaking anything personal... linux-vdso.so.1 (0x00007ffd353a6000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f852c4ea000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f852c4e5000) libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007f851eba4000) libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f851ea69000) libnss3.so => /lib64/libnss3.so (0x00007f851e92b000) libnssutil3.so => /lib64/libnssutil3.so (0x00007f852c4b2000) libsmime3.so => /lib64/libsmime3.so (0x00007f851e8ff000) libnspr4.so => /lib64/libnspr4.so (0x00007f851e8bc000) libatk-1.0.so.0 => /lib64/libatk-1.0.so.0 (0x00007f851e892000) libatk-bridge-2.0.so.0 => /lib64/libatk-bridge-2.0.so.0 (0x00007f851e859000) libcups.so.2 => /lib64/libcups.so.2 (0x00007f851e7ba000) libgio-2.0.so.0 => /lib64/libgio-2.0.so.0 (0x00007f851e5e0000) libdrm.so.2 => /lib64/libdrm.so.2 (0x00007f852c498000) libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007f851e58d000) libatspi.so.0 => /lib64/libatspi.so.0 (0x00007f851e550000) libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f851e51f000) libm.so.6 => /lib64/libm.so.6 (0x00007f851e443000) libX11.so.6 => /lib64/libX11.so.6 (0x00007f851e2fb000) libXcomposite.so.1 => /lib64/libXcomposite.so.1 (0x00007f852c491000) libXdamage.so.1 => /lib64/libXdamage.so.1 (0x00007f852c48c000) libXext.so.6 => /lib64/libXext.so.6 (0x00007f851e2e6000) libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00007f851e2dd000) libXrandr.so.2 => /lib64/libXrandr.so.2 (0x00007f851e2d0000) libgbm.so.1 => /lib64/libgbm.so.1 (0x00007f851e2bf000) libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f851e292000) libxkbcommon.so.0 => /lib64/libxkbcommon.so.0 (0x00007f851e249000) libpango-1.0.so.0 => /lib64/libpango-1.0.so.0 (0x00007f851e1e2000) libcairo.so.2 => /lib64/libcairo.so.2 (0x00007f851e0c6000) libasound.so.2 => /lib64/libasound.so.2 (0x00007f851dfb7000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f851df9c000) libc.so.6 => /lib64/libc.so.6 (0x00007f851dc00000) /lib64/ld-linux-x86-64.so.2 (0x00007f852c512000) libffi.so.6 => /lib64/libffi.so.6 (0x00007f851df8f000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f851df17000) libplc4.so => /lib64/libplc4.so (0x00007f851df10000) libplds4.so => /lib64/libplds4.so (0x00007f851df0b000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f851deb2000) libavahi-common.so.3 => /lib64/libavahi-common.so.3 (0x00007f851dea4000) libavahi-client.so.3 => /lib64/libavahi-client.so.3 (0x00007f851de8f000) libgnutls.so.30 => /lib64/libgnutls.so.30 (0x00007f851d800000) libz.so.1 => /lib64/libz.so.1 (0x00007f851de75000) libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00007f851de6e000) libmount.so.1 => /lib64/libmount.so.1 (0x00007f851de27000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f851dbd5000) libsystemd.so.0 => /lib64/libsystemd.so.0 (0x00007f851db03000) libXi.so.6 => /lib64/libXi.so.6 (0x00007f851de15000) libXrender.so.1 => /lib64/libXrender.so.1 (0x00007f851daf6000) libwayland-server.so.0 => /lib64/libwayland-server.so.0 (0x00007f851dae0000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f851d400000) libXau.so.6 => /lib64/libXau.so.6 (0x00007f851de0d000) libfribidi.so.0 => /lib64/libfribidi.so.0 (0x00007f851dac0000) libthai.so.0 => /lib64/libthai.so.0 (0x00007f851dab5000) libharfbuzz.so.0 => /lib64/libharfbuzz.so.0 (0x00007f851d729000) libpixman-1.so.0 => /lib64/libpixman-1.so.0 (0x00007f851d67d000) libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00007f851da66000) libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007f851d335000) libpng16.so.16 => /lib64/libpng16.so.16 (0x00007f851da2d000) libxcb-shm.so.0 => /lib64/libxcb-shm.so.0 (0x00007f851da28000) libxcb-render.so.0 => /lib64/libxcb-render.so.0 (0x00007f851d66d000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f851d257000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f851d655000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f851d64e000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f851d63d000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f851d636000) libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f851ce00000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f851d622000) libp11-kit.so.0 => /lib64/libp11-kit.so.0 (0x00007f851d125000) libidn2.so.0 => /lib64/libidn2.so.0 (0x00007f851cdaf000) libunistring.so.2 => /lib64/libunistring.so.2 (0x00007f851cc2a000) libtasn1.so.6 => /lib64/libtasn1.so.6 (0x00007f851d10d000) libnettle.so.8 => /lib64/libnettle.so.8 (0x00007f851cbd7000) libhogweed.so.6 => /lib64/libhogweed.so.6 (0x00007f851cb94000) libgmp.so.10 => /lib64/libgmp.so.10 (0x00007f851caf1000) libblkid.so.1 => /lib64/libblkid.so.1 (0x00007f851cab9000) libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f851ca1d000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f851c9f1000) libzstd.so.1 => /lib64/libzstd.so.1 (0x00007f851c942000) liblz4.so.1 => /lib64/liblz4.so.1 (0x00007f851c91e000) libcap.so.2 => /lib64/libcap.so.2 (0x00007f851d103000) libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007f851c7e2000) libdatrie.so.1 => /lib64/libdatrie.so.1 (0x00007f851d0fa000) libgraphite2.so.3 => /lib64/libgraphite2.so.3 (0x00007f851c7c1000) libxml2.so.2 => /lib64/libxml2.so.2 (0x00007f851c637000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f851c624000) libbrotlidec.so.1 => /lib64/libbrotlidec.so.1 (0x00007f851c616000) libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f851c5f0000) libbrotlicommon.so.1 => /lib64/libbrotlicommon.so.1 (0x00007f851c5cd000)

jeroenhd 3y ago

Youtube is a great example of the performance difference. Videos have risen in quality because of modern codecs, but old or cheap machines need to decode them in software (sometimes in Javascript, which is terribly wasteful but works on every machine) because they lack a modern GPU. On the other hand, for most devices, the increased battery life, lower temperatures, and smaller RAM/disk space requirements are obvious improvements. Youtube could leave duplicate files with the old encoding on their servers (if you use an alternative frontend for Youtube, you can often see the old file formats still being available for old content!) but that's just wasted space with most of the world visiting from more recent devices. Most RAM usage increases in Chrome have come from advancements in the sandboxing architecture. Shared memory and process space could be used to attackaand bust out of sandboxes, so more isolation was added. I'm sure there are some more useless features leading to a jump in RAM usage as well, but the really big ones always seem to be the fact Chrome spawns a new, independent process for every tab/extension. I've also noticed how much impact ad blockers have these days. With the web becoming ever shittier, effective adblockers have become harder to make and need more resources to do their job. Software doesn't get slower just to make your day harder. In many cases, slow software is a result of replacing dangerous hacks by good implementations and changing requirements. FLV videos just don't cut it anymore, and I doubt h264 will be around in five years with h265 and AV1 making it's way to more and more devices.

smikhanov 3y ago
Excellent remark. For each "I needed an extra gigabyte of RAM in my computer to do the same thing as six years ago" complaint there is normally a valid reason like this. It's always not exactly the same thing as six years ago, really. Oh, and the same applies to the original blog post, too.
Culonavirus 3y ago
AV1 is a massive flop in my opinion. What was supposed to be the be all end all open source video format of the future just recently barely starts to pop up here and there. There are tech demos and talks of Youtube etc. using AV1, but in the same breath they say it's mostly for really low bitrate where the AV1 gains the most. Also I'm sure no one is looking forward to burn CPU time (or very lately, GPU time) on encoding 4k+ streams. Is that even financially viable? You save 30% on bandwith and spend 10000% more on server HW time. (I'll admit that these numbers are pulled from my ass, but they're based on a few years old knowledge of AV1 encoders being like 350-3500 times slower than h264 encoders, depending on optimization.) The entire "there was no usable encoder and no hw decoder for years" thing didn't help and even now it's still all slow and complex, who has time and money for that? AV1 is just too complex for what it produces in comparison with the good old h264 or vp9.

aaaronic 3y ago

Web browsers in particular have become operating systems unto themselves. The "modern web" has so many features, often implemented in half a dozen competing ways... Just text rendering on modern hardware can be a HUGE lift. Modern toolchains are all about "not reinventing the wheel" -- but when each dependency has picked a different version of said wheel, just pulling in a few dependencies leads to 6 different implementations of the same low-level features.

chankstein38 3y ago
This is one of the reasons the announcements about WebGPU made me cringe. Yeah, just what I need, more unnecessary complexity added to webpages. Especially when there's seemingly a chance people will use them to mine crypto on my GPU while I'm on their page.

dunham 3y ago

I remember needing 8MB to run a graphical web browser with Linux/X11 (I believe it was Netscape Navigator). 8MB was sufficient, 16MB a bit more comfortable.