Except it's not, not really - it's hosted by Cloudflare which even requires you to enable JavaScript to pass.
I can't even pass with everything enabled (again). I've tried refreshing fifteen times now to try to hit it and I give up.
Website hosted on a 24 year old Linux server
101–110 of 131 posts
Re: Website hosted on a 24 year old Linux server
#102Earlier quoted context omitted.
> 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…
It can be much simpler if you're willing to write a couple lines of assembler: use an 8-byte file that contains one 64-bit counter, mmap() it, mlock() it, and use atomic CPU instructions to increment and read it.
I am going to ask gpt 4 to implement this for me so I can see what it looks like. Amazing.
Re: Website hosted on a 24 year old Linux server
#103Earlier quoted context omitted.
> b) just write blindly to file and pretend concurrecy doesn't exist This is likely what was done. Nobody really cares if a hit counter on a web page loses a few updates.
Given it's a single-threaded CPU, there's a fair chance the web server isn't concurrent anyway. Linux got proper POSIX thread support with NPTL only in 2002.
The RaQ line used Apache which definitely supported concurrent requests. We're talking about 1999 here. Maybe this isn't as obvious to people today looking back, but concurrent request handling was absolutely required from the beginning: consider how slow your clients are! One single client on a slow dial-up modem can't be allowed to drag the whole site down.
Re: Website hosted on a 24 year old Linux server
#104Earlier quoted context omitted.
> b) just write blindly to file and pretend concurrecy doesn't exist This is likely what was done. Nobody really cares if a hit counter on a web page loses a few updates.
Given it's a single-threaded CPU, there's a fair chance the web server isn't concurrent anyway. Linux got proper POSIX thread support with NPTL only in 2002.
It will be a forking web server. But the CPU scheduler will schedule process A while B is opening the file and reading and that. While B is then increasing the counter, leading to multiple processes with "wrong" data.l racing for the writes.
Re: Website hosted on a 24 year old Linux server
#105Except it's not, not really - it's hosted by Cloudflare which even requires you to enable JavaScript to pass.
I've got a pentium 90 I occasionally turn on and I'll reply again when I do here. Hosting stuff from it is wildly taxing. It's on my internal network and I proxy it through apache over a raspberry pi. But it does genuinely serve content to the proxy - which does not cache it. 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 interfa…
This was a cute blast from the past, thanks for sharing.
Re: Website hosted on a 24 year old Linux server
#106Earlier quoted context omitted.
It can be much simpler if you're willing to write a couple lines of assembler: use an 8-byte file that contains one 64-bit counter, mmap() it, mlock() it, and use atomic CPU instructions to increment and read it.
Genuine question: Does it have to be mlocked for this to work?
[deleted]
Re: Website hosted on a 24 year old Linux server
#107Earlier 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…
I think you can avoid the lock and all else, if all you need is a counter: Open a file in append mode (O_APPEND) and then write a byte for each visit. To get the count take the file size.
Of course you have to make sure to not run out of diskspace or max file size of the OS/filesystem (2GB on a 32bit system?)
Re: Website hosted on a 24 year old Linux server
#108Earlier 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…
d) write to a temp file and atomically move it onto the read path. you will miss counts, but nothing will break.
Re: Website hosted on a 24 year old Linux server
#109Earlier quoted context omitted.
I assumed myself there must be a lot of root privilege vulnerabilities in Apache, but it appears there isn't a single one: 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 v…
Don't get me wrong, I don't mean to recommend running ancient software and not caring about security! It was rather out of curiosity: for the past 20-something years, which is no guarantee for the future (especially with software getting more complex than ever), would there be a blanket issue if you follow best practices in general (like dropping ports in iptables if you don't need them), or is it only specific circu…
From my perspective, there seems to be a lot more vulnerabilities found today than 20 years ago, so I don't think it's wise to have an unpatched 24 year old kernel or web server.
Re: Website hosted on a 24 year old Linux server
#110Except it's not, not really - it's hosted by Cloudflare which even requires you to enable JavaScript to pass.
I immediately close the browser tab every time I see the cloudflare spinner. Very few websites are worth supporting the massive MITM that is cloudflare.
I just see "Enable JavaScript and cookies to continue" and leave.
You're not running arbitrary code on my machine without earning my trust first.