81–90 of 131 posts
Earlier quoted context omitted.
Pretty sure Linux didn't have inotify then. Probably a CGI script updates a counter in a file.
> Pretty sure Linux didn't have inotify then. Did FUSE exist yet? You could hack it up in userspace... (Have the HTML on a FUSE filesystem, and every time it gets a read it updates the HTML)
Earlier quoted context omitted.
Christ, that there were other kids with an interest in computers is amazing. I sat on my own lmao.
I had a friend to sit with at lunch and talk to excitedly about computers, PC gaming, robots, military hardware, etc. This was in the 90s.
Ah man, I always wanted a Cobalt RaQ server - they looked so cool! I seem to remember people reselling access to them and they had web guis that looked like them as well, I think a friend had one
The Cobalt RaQ was one in a series of Cobalt 'server appliances'. These appliances were and remain unique largely because of their design, including (1) Industrial design incorporating round moulded transparent blue plastic elements and an LCD/button basic network config and status system. (2) Hardware design which initially (for RaQ v1 + RaQ v2 + Qube v1 + Qube v2) was based upon MIPS processors, a rarity in commercial Linux products. This server is unfortunately a RaQ v3, so AMD K6 (intel) based rather than MIPS. (3) Software design, which incorporated a complex (IIRC perl v5 based) software module upload function which allowed for commercial sale of new software packages easily installed on the devices with web configuration.
One of my first jobs circa 2000 was writing a VPN module for the Cobalt devices in perl v5 which was sold by an Australian company. I gave away my hardware years ago.
Earlier quoted context omitted.
> Doing this in modern times would be so complicated. No, it wouldn't. All you need to store this kind of data is a simple file. Most people would probably use PHP for something like that due to its ubiquity, but it could even be a few lines of bash, or Python, or Go, or whatever...
> All you need to store this kind of data is a simple file. You mostly likely need a WAL Mode SQLite database. Most of the time, it's way simpler that handling state handling in concurrent situations yourself. (also, bindings are often available - if not outright bundled by default - under most common languages) The "easy" way is all fun and games until your file is accessed in a concurrent fashion, and then your opt…
This is likely what was done. Nobody really cares if a hit counter on a web page loses a few updates.
> Website hosted on a 24 year old Linux server Isn't that kind of mundane? The web was well-established by 1999, and the hardware of that era was literally designed and built to serve websites like this.
I remember how magical and mysterious a view counter used to feel when I was a kid. How did the website know when someone visited it? Where was the count stored? And how on earth could a website update its own HTML to show the new count? Geocities days were magical. I wonder if kids today have similar thoughts about Twitter profiles and such. It’s probably much easier to pick up the knowledge — back then, it was balk…
I feel like you could do this without a database using the Linux kernel inotify API. Every time a file is accessed trigger an increment. It’s too beautiful of a day outside to try this right now but an interesting brain teaser!
Earlier quoted context omitted.
I feel like you could do this without a database using the Linux kernel inotify API. Every time a file is accessed trigger an increment. It’s too beautiful of a day outside to try this right now but an interesting brain teaser!
Pretty sure Linux didn't have inotify then. Probably a CGI script updates a counter in a file.
Except it's not, not really - it's hosted by Cloudflare which even requires you to enable JavaScript to pass.
The machine runs netbsd with apache and has 128MB of memory and, as a cheat I'll admit, uses a SD/IDE bridge device to go to an ATA/100 interface (my older compatible PATA drives were failing on it ... I think there's some shelf-life degradation on those things although I never actually looked it up).
But even on the 100MB/s nic, the thing is unacceptably slow in serving pages. Maybe modern apache not being designed for 1994 hardware has something to do with it. I have some bullshit toy webserver I wrote, geez, 18 years ago, I wonder if it will be faster (https://github.com/kristopolous/apac) ... exciting things to look forward to after I bike home from this coffee shop.
That weird readme was some kind of pre-markdown markdown I had made and have long lost the interpreter for.
update: just tried compiling it. still works and serves pages. I like how I had SunOS support, lol. It's probably comically insecure so have fun I guess?
Here's the pentium 90 running apache: http://bootstra386.com/~hn/
I remember how magical and mysterious a view counter used to feel when I was a kid. How did the website know when someone visited it? Where was the count stored? And how on earth could a website update its own HTML to show the new count? Geocities days were magical. I wonder if kids today have similar thoughts about Twitter profiles and such. It’s probably much easier to pick up the knowledge — back then, it was balk…
Earlier quoted context omitted.
How can you tell the difference between cloud flare caching and cloud flare ddos alone?
The "CF-Cache-Status: DYNAMIC" response header seems to indicate that the file was not cached. https://developers.cloudflare.com/cache/about/default-cache-... > Cloudflare does not consider the asset eligible to cache and your Cloudflare settings do not explicitly instruct Cloudflare to cache the asset. Instead, the asset was requested from the origin web server. Use Page Rules to implement custom caching options.
The html page and the hit counter (counter.pl) aren't cached.