Latest T2 Linux on an 486 with Just 32MiB RAM | Hacker News Reader

Latest T2 Linux on an 486 with Just 32MiB RAM

youtube.com

25 pointspantalaimon25 comments

100 MHz 486? 32 megs of memory? It should fly!

I'm running NetBSD 9 on both a Mac LC II with 10 megabytes of memory and on an LC III+ with 36 megs of memory. The LC II has a 16 bit memory bus and runs at 15 MHz, and it's... interesting. It can actually go multiuser and run sshd, although ssh logins have to have their timeout extended to ten minutes so logins can happen before they time out.

The 33 MHz m68030 in the LC III+, with 36 megs of 32 bit memory, is fully usable. I can ssh without timeouts. I can run vi or vim. I can do things while it's running stuff in the background (making the man database, for instance, or compiling), and I can compile software natively just fine.

Why is Linux so painful with about the same amount of memory, but with a CPU that's six times the speed? Hmmm...

nvi should be as usable on basic stuff (plus unicode) as vim while using far less resources.

Can you use TLS websites under Lynx?

That’s a lot of RAM for a 486! My first Pentium came with only 24mb :(

My 486/33 came with 16mb. It sat at one end of a 64k frame relay line and allowed me to telnet (yes!) into remote sites and WFH in the early 90’s.

My 486DX2/50MHz came with 4MiB of RAM -- I used it all the way up until I gave it away in the early 2000s (though I did upgrade the RAM at some point, I couldn't run Netscape and compile my kernel with only 4MiB of RAM).

I had forgotten about those Intel Overdrive chips. I had updated a PC with the 486DX4/100.

I had a similar setup with an ISDN line. I got a discount because I worked for an ISP. I had a full /24 routed to my home, too.

I remember upgrading my 486/100 to 32 megs of RAM, back in 1995. I had 15 users logged in over telnet, using pine, elm, tin, etc. That thing flew!

I worked all summer between my first and second years of university, and saved up enough to buy a 'Morgan Generic' 486-BL2-66.

IBM used to make their own 'Blue Lightning' version of the 486. IIRC RAM cost at the time was around 100GBP for each 4MB, and I opted for more RAM instead of a better brand of PC.

It ran X fine, but the bundled monitor was limited to 800x600 non-interlaced, or 1024x768 interlaced.

Holy stream of consciousness Batman!

Why does this 30ish minute video have 10 ad slots? As cool as this is that he got this working, from my android phone I can't watch this without losing track of what he's saying. (I know there are ways to block ads, but that's not the point)

People blame Windows for bloat, but Linux today is the true bloated software in my opinion - Linux used to be the OS we turned to run on machines where Windows used to crawl. But look at the state of Linux today. As someone asked in the Youtube comment too, I wonder where the bloat is in Linux that makes it so slow today, compared to its breezier past?

Got any citations/benchmarks for what is slower about Linux today?

I'm guessing the kernel itself isn't taking more than 30mb of RAM these days.

What's next? udev/systemd?

X11 server / Wayland + display manager?

Anecdotally, this comment annoyed me so much that I decided to reboot my machine (that I typed this comment on) and see what the memory situation looked like. As I correctly remembered, it still starts up in under three seconds & using under 40MB, after init launches my web server, networking & other various tools for convenience.

I'm not sure if this is sarcasm?

I'm typing this on a Thinkpad x200 (Intel Core 2 Duo from 2008) running up to date Debian GNU/Linux with MATE, and it runs great!

Compared to a NetBSD/OpenBSD setup with Mate it's dog slow.

umm...ok? What was this post trying to get across?

Without any concrete benchmarks, it comes across to me like some sort of flexing for reasons that I have no idea why.

Is it slow? I mean, Linux itself. Yes, the kernel is bigger these days. But once it's up and running it should be handling system calls as fast as about 20 years ago. Often faster.

So, I'm not sure core things are slower. But libraries have gotten bigger. Much bigger. Open up a web browser and you load several hundred megabytes of libraries. You got Unicode, and data for your vector fonts, and code for special tweaks on rendering everything from Taiwanese vs. Mainland Chinese character forms to obsolete Russian diacritics, libraries for parsing image, audio and video codecs, libraries for 3D rendering, and Javascript and WASM dynamic translation, and parsers for 30 years of crufty non-standard web standards. Oh, and of course everything over the network is encrypted now.

So it's a mix of asking more from the machine - 4K displays involve a lot of pixel-pushing. And associated code size to do those things. Which makes it slower to load, and everything becomes very miserable when you run out of RAM.

Now if you configure a kernel with not much more than the features you would have had in the '90s, use lightweight libraries, stick to the command line, and give it enough RAM? Modern UNIXes actually are still quite snappy on even the most pitiful hardware. I have an old Mac with a 68030 running at 16 MHz. I put NetBSD on it a few years ago, just as a lark. For poking around the file system and using vi, it might as well have been my modern desktop for user response times. (It even runs X11 tolerably... as long as you stick to twm and xterm.)

Of course much of it really is just bloat. Editors should probably not be implemented in Electron.

> Of course much of it really is just bloat. Editors should probably not be implemented in Electron.

Maybe. On the other hand, vscode feels faster than Visual Studio or Eclipse or IntelliJ ever was.

Easy when it doesn't do half as much.

For some things (let‘s say frontend development) it does a lot. Even with a large number of plugins it still feels snappy.

It doesn't do much actually.

IDEs do two way editing with data models on SSR, debuging with all development stack, and then there are visual RAD tools like outsystems.

>as long as you stick to twm and xterm.

FVWM or ctwm will run much better, ditto with urxvt against xterm.

icewm might also be a good choice, but I'm not sure about it's dependancies.

I wonder if the spectre/meltdown mitigations have anything to do with it. Or stack smashing protection perhaps. A LOT of security mitigations over the years probably will make considerably slower code on older processors.

Reply on news.ycombinator.com