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 balkanized across IRC and whatever we used before Google.
I also started writing a FF7 walkthrough all on a single page, because I didn’t know how to link from one page to another. I made the different chapters different font colors, reasoning that it was good enough to change the color when you’re trying to figure out which section to get to. Good times…
EDIT: Whoa. The view count is real time. You can see how quickly HN is hammering the page by refreshing it. The guestbook works too. I wonder what the tech stack looks like.
Doing this in modern times would be so complicated. You’ll need a database, then software to talk to the database, and maybe webpack.
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...
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 options are:
a) flat out die when concurrent things happens (file locks; default sqlite3 behaviour);
b) just write blindly to file and pretend concurrecy doesn't exist, but randomly lose data - (write to files directly like a crazy person; sqlite3 PRAGMA schema.synchronous = OFF)
c) allow reading at anytime, but serialize writing somehow (file locks + write + move atomic file operations; append writing and a journal; sqlite3 PRAGMA journal_mode=WAL)
Probably a CGI script updates a counter in a file.
That's what laptops are for!
I'm sure that some do, and most don't. Most kids 30 years ago didn't have similar thoughts either. Few people are meant to be programmers, engineers, etc. Were you not shunned as a nerd for having an interest in how computers worked?
I remember those days. There was one table in the lunch room where the 10 or so kids who were into computers sat. I found out later talking to some other classmates that nobody else wanted to talk to us because they thought they weren't smart enough.
I certainly wasn’t in the 10s. Usually people would come to me and my nerd buddies for PC building advice, smartphone advice, and of course the occasional “can you pirate this for me” request ;)
The realtime hit counter and fascination therewith brought up a memory.
Back in '95 the regional dial-up ISP I used offered personal website hosting on one of their boxes (the standard http://www.isp.com/~username gig). I was very excited to put up a personal website. That was fun for awhile but soon I wanted to do more with it. I liked the look of hit counters, guest books, etc.
I became annoyed because this "CGI" thing I'd read about didn't work. I could FTP up Perl scripts named with ".cgi" filenames, however accessing them only resulted in seeing the Perl code.
I setup a webserver (NCSA httpd) on my Slackware box and started experimenting. I learned about .htaccess files and, more importantly, learned I could override the server's main httpd.conf with directives in my directory's .htaccess file.
A little experimenting with my ISP's web server turned up that, sure enough, they had not configured "AllowOverride None". Lo and behold I could enable server-side includes[0] in my directory-- including executing CGIs via SSIs!
Once I figured out how to chmod +x my scripts thru the FTP server I was in business. I had a hit counter! I had a script to check the referer (sic) and add a link in the footer back to the "main page" if you didn't "come from" there. I wrote out my own log files (because I didn't have access to the server's main log file) so I could see the IPs, user agent strings, and referers of visitors. (I also learned about file locking and parallel execution of the script by multiple requests occurring simultaneously. Fun!)
(The ISP didn't offer shell access but I figured out, pretty quickly, that I could write a rudimentary web shell with my SSI-based CGIs. I didn't do too much with that because I didn't want to get caught and I'd mostly gotten the desire to do "unauthorized pro-bono remote system administration" out of my system by that time...)
This little "site" my friend and I ran got listed on Yahoo (we submitted it... >smile<). I remember seeing a bunch of clients with reverse-lookups of the form "xxx.yahoo.com" that day.
Wired had recently done an article on Yahoo[1]. I saw a client named "srinija.yahoo.com" and remembered the article talked about a "Srinija Srinivasan" being an employee there (working on ontology). It was really exciting to see somebody named in a Wired article accessing my silly little site. (The most memorable client name from Yahoo was "ratbastard.yahoo.com", BTW. I'd love to know the backstory. Guess I already wrote about this once...[2])
[0] https://www.oreilly.com/openbook/cgi/ch05_01.html
Reverse engineering the e-scooters so you don't have to pay is popular.
Old cars everywhere being rebuilt and modified.
One guy has added a small engine to his pushbike using some kind of gear wheel coupling.
They are making their own short films and fashion shoots now the Sun is out. Lets face it a smartphone is all you basically need to create (some kind of) media now.
https://www.reddit.com/r/history/comments/7btv14/the_more_th...
- Main count file.
- 2 "Append" files.
======
- Append 'a' to append file 1.
- After some time, swap append file 1 with 2.
- Count up 'a' in non-active append file 1, add it to main count.
Then just repeat, swapping append files.
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/
It's wild to see what's actually slow that's imperceptible now and what claims to be intel 586 32-bit compatible which actually no longer is.
Still happy to see this project online
Very few websites are worth supporting the massive MITM that is cloudflare.
You're not running arbitrary code on my machine without earning my trust first.
Any time I see a customer using an ssh or apache version from ten years ago (different from the kernel, but the kernel doesn't give you version disclosure), the list of bugs is all like "if they use RewriteRule and the second URI parameter is echoed unfiltered into a Location header by the application code and it's on Windows then you can do something actually interesting. The standard services' standard feature set is annoyingly boring when outdated ... most of the time.
Predictable sequence numbers would be my first worry, but with TLS and SSH being the main protocols of relevance, it doesn't really matter if you can send off-path traffic into a TCP connection.
https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
All the above seem to be in other Apache products. I think the fact that Apache doesn't run as root helps to mitigate these risks. Having said that, I have had a server compromised (about 20 years ago), through apache, suexec and a vulnerable cgi script, so I think it's best to be paranoid about security. I don't even see suexec on my current ubuntu 20.04 server (I used to just delete it).
Originally it was 2.2
The cpu (AMD K6-2 300 MHz) is a lot faster than a raspberry pi 1 for many things, it has 512mb of ram, so for running a simple webpage, it should still work good enough.
edit: especially with cloudflare infront of it...
https://web.archive.org/web/19991128033948/http://wearables....
>The Matchbox Webserver, which is serving this and the other web pages to you, is a single-board AMD 486-SX computer with a 66 MHz CPU, 16 MB RAM, and 16 MB flash ROM, big enough to hold a useful amount of RedHat 5.2 Linux including the HTTP daemon that runs the web server.
the og pi is still fairly capable, and you can achieve a lot with it if you offload a lot of things or write more efficient systems.
* Animated gif: check
* View counter: check
* Repeating background image: check
* Mobile? What's that? : check
Those were the days.
("We recommend that you bookmark this site so that it is easy to access in the future.")
check
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.
bash# w
sh: fork: Resource temporarily unavailable Icon for raq.serialport.orgraq.serialport.org
Checking if the site connection is secure
raq.serialport.org needs to review the security of your connection before proceeding.
Why am I seeing this page?
Here's a real server, hosting without a caching proxy, that's 30 years old:
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.
Ah, I was hoping this was a MIPS model