One machine can go pretty far if you build things properly
rachelbythebay.com
rachelbythebay.com
On the other hand planning for >1 node pushes you towards properties that are desirable for other reasons than scalability per se, such as a stateless app tier with a separate database, zero downtime deployment, incremental rollout, and change management by some less cowboyish means than interactive SSH. For those reasons I would probably prefer to start with something like N=3.
Also, when it comes time to increase complexity budget and spend innovation tokens, people would often be better served by making a simple deployment topology multi-region than by making a single region very complex. Separate failure domains are great!
Not saying that everyone who does this is wrong, just that this dynamic is real.
- [popular software] uses more memory than things did when I was a young'un
- "I don't ask about algorithms in interviews", followed by thread of people saying how much they don't use algorithms in interviews
- [old software] reimplemented in Rust
- "Here's why [badlang] is bad", followed by thread of 90% people telegraphing how tolerant they are by insisting that [badlang] is actually sorta good and it's all horses for courses, and 10% slightly weird-in-the-head people getting het up insisting that [badlang] is indeed bad
- [random humanities-related essay with oddly warm comments in thread]
- "Here's why everything is too complex and everyone should run their application on a single abacus connected to the internet by carrier pigeon", followed by thread of Group A insisting that complex things are good for complex problems and Group B insisting that most people's problems aren't complex, in a circle ad infinitum
etc etc
LOL yeah true. But with all the marketing pressure to buy all these expensive cloud services it's good to have some pushback to even things out.
And Bitcoin followed by a thread full of the word "Ponzi".
Oh and don't forget all the comments either entirely misunderstanding or mischaracterizing the study along with a bunch of anecdotes and suggestions that have nothing to do with the subject at hand
286s or 386s didn't need heatsinks, and since the rear side of shelves are up against the wall, there isn't much heat generated, or else they would have had problems.
> If we ignore the fact that the actual BBS software
Actual BBS software (https://en.wikipedia.org/wiki/RemoteAccess) had "ability to run multiple nodes under Microsoft Windows, Quarterdeck's DESQview and OS/2. RA could also operate over a network or even a combination of network and multitasking operating systems to provide multiple "nodes per station" capabilities."
It's possible they could have handled hundreds (maybe thousands?) of simultaneous users and actually needed this capacity.
It was a major shareware distribution site for the biggest shareware game publishers such as Apogee/3dRealms, id software, etc. So a disproportionately high amount of their usage was likely file downloads, which would lead to a different setup than a large BBS dedicated to multi-user text games.
Setups depicted as in this photo were extremely rare, and only made sense for highly specialized purposes (e.g. major file distribution hub as in this case). There were very few BBS's with over 100 nodes. I'd wager none with "thousands", that was absolutely unheard of with any traditional commercial BBS software that you could purchase.
By the 90s, large US metro areas tended to have hundreds of hobbyist boards with 1-2 nodes, and a small handful with 50-100 nodes. The large ones were typically either pay-for-access text game/chat/community hubs, or occasionally commercial systems run by companies (file hubs, customer support systems, etc).
Sure, you could run multiple nodes of RemoteAccess or PCBoard or whatever on a single PC, if using a multi-tasking OS. But "multiple" here means like 3 or 4 nodes max per PC, at least in the early to mid 90s. Beyond that you'd run out of RAM, because each node was a separate copy of the BBS software exe, relying on file sharing/locking for coordination. It was wasteful of system resources -- the OP's point is absolutely correct here!
In contrast, MajorBBS (popular for large text game BBS's) implemented its own multi-tasking / event polling loop, used efficient btree-based storage, etc to handle 50-100 simultaneous users on a single PC in a single process on DOS. In theory it could handle up to 256 nodes, although I don't know of any BBS's that actually got that large. Maybe Metropolis GamePort's BBS, but I vaguely remember they split it into multiple separate systems.
It's better to have a simpler, dumber system due to less things that can go wrong.
Do you have a particular thing for which you'd like "sysadmin in a box"?
https://github.com/stepchowfun/toast
Thanks so much in advance...