Hacker News Reader

Comment by severak_cz | Hacker News Reader

Pragmatic approach would be host it from floppy disk, but have some caching proxy before it. It could cache into RAM, most modern machines have enough memory to cache many many many floppies. Even Raspberry Pi.

View on HN

The website says that he uses:

"Xitami web server, because it's the only one that does no caching at all, so the website is always served fresh from the floppy."

Source: https://web.archive.org/web/20220120092324/https://old.bigca...

I was wondering how he prevented the kernel from caching the disk blocks in memory, but then I saw he is running it on a machine with 4MB of main memory, and presumably most of that is eaten up by the TCP stack, web server, and parallel ethernet drivers. Not to mention memory needed by the OS itself.

Even more surprising, his page isn't just pretty, it is functional! You can get a copy of the demo for Wolfenstein 3D off of the site (supposedly, I did not try).

The pragmatic approach would be to not host it from a floppy. If you are going to host it on a floppy then just having it all constantly in cache somewhat defeats the point.

You need somewhere to persist writes from those CGI scripts.

This is exactly what Linux will do by default, without any special setup or config. Everything goes through the buffer cache.

In fact, you would have to do active work to disable the caching.

Don’t all modern operating systems have a RAM-based disk cache?

I don't have deep knowledge of any other operating system. But I'm sure you are right.

It's hosted on a machine with 4M of ram on windows 3.11, and specifically uses a web server which doesn't use caching (And I don't think Dos 6 caches files at the OS level, at least by default)

DOS does: https://home.csulb.edu/~murdock/buffers.html

I can't remember how buffers in DOS work, but that page seems to indicate that for input purposes they're used as some kind of a read-ahead buffer. That doesn't sound quite the same as keeping recently or commonly accessed data in RAM to speed repeated access.

DOS did have SmartDrive [1], though, which IIRC provided a more typical disk cache. I wouldn't think it was loaded in the default configuration, though I'm not sure.

[1] https://en.wikipedia.org/wiki/SmartDrive

As said in that page and the documentation, the read-ahead is the [,X] part, which is actually disabled by default in every DOS past 6.x (incl FreeDOS). The first part is the number of primary buffers which is indeed "for keeping recently read data in RAM".

Smartdrv, like Fastopen, just allows disk buffers to survive a Close File call. Normally DOS only does close-to-open consistency i.e. buffers are flushed on close. Smartdrv specifically also allows write-back rather than write-through.

And, anyway: yes, Smartdrv is enabled by default in 6.x installs with enough memory.

Okay, thanks for the clarification.

Nice, although if it is set to 15, that's only 7,680 bytes of buffer, and even 99 is just 50,688 bytes. It's not loading now, but I suspect a single load of all those images will flush that data

Reply on news.ycombinator.com