Out of nowhere, I logged in like a month ago. Everything was still there (at least, my friends list was). Hadn't logged in since the early 2000s. A few weeks later, I heard it was being shuttered. Weird.
Hey, I've been a Linux gamer for many, many years, and before Steam Deck it was exclusively on nVidia hardware (mostly because I also wanted CUDA cores for Blender).
We need to prepare for the future where there is no jobs and AI replaced all of them.
You seem to think that the natural extension of this is that everyone who used to have a job continues to flourish, and doesn't die in the gutter because they have no money/shelter/food.
The naivity would be adorable, if it weren't also extremely dangerous and playing directly into rich assholes' plans to bleed everything dry for themselves.
There's a whole lot of advice here, and practically none is it is aimed at a beginner. You don't need a reverse proxy or SSL to get started.
Install the OS - You've done this already.
Install some kind of http server - Apache is fine, people recommending anything else are overcomplicating. The package is called either apache2 or httpd, depending your flavor of Linux.
Put your files in the web root - Usually /var/www/html/. If the file is something like index.html, it'll load as the default page without having to type http://youraddress/index.html
Restart Apache - different across OSes, Google will get you there. Something like systemctl restart httpd, but "systemctl" might be "service", and "httpd" might be "apache2".
Once you've done that, you have a computer that will serve your html files when someone hits http://[yourIP]/ . At this point, make sure your router/etc is allowing connections on port 80 (the http port), specifically to that one computer. Also, don't allow that computer to connect to the rest of your home network (not getting into a step-by-step here; every home network uses different hardware), because now that the Internet can touch it, it's a target for hackers. If all they can touch is this one computer (start calling it a server), the risk is minimal.
If you want to point a domain at it, that gets into DNS (the Domain Name System; literally how domains are mapped to IPs so humans don't have to remember them). Cloudflare has guides for this.
Since it's your home IP, it might change. Either be fine changing your DNS if your IP changes (which usually isn't often if you have a decent connection), or look into something called "dynamic DNS" (just a thing that grabs your current IP and updates your domain to point at it).
NOW you can start getting into things like SSL. Remember that SSL doesn't protect you from some guy trying to hack your site/server, it just makes it harder for them to view or change content while it's being sent from the server to a site visitor (or back again, if you have a form).
Google "add SSL to Apache", you'll find references to "VirtualHost" and a bunch of config lines starting with "SSLCertificate...". You'll also find plenty of references to "LetsEncrypt" (a free SSL provider) and "Certbot" (a program that lets you generate the certificates with LetsEncrypt). Follow those.
As above with port 80, you'll need to make sure that port 443 (the https port) is allowed for your server through your router. Again, block your server from connecting to the rest of your network. The Internet can touch it, someone will try to hack it. The SSL doesn't save you from this.
As for reverse proxies, you don't need one unless you're getting into load balancing or header manipulation (which means you'll probably never need one for this project).
Adding to the increased attention: it was Microsoft night at the ballpark, with thousands of fans in attendance with ties to the Redmond-based software giant.
Honestly, my gut tells me this was a stunt.
Edit: Yeah, this is BS; You can hear typing in the video. What, they have a hot mic in the booth? And the article straight up calls it a gimmick. Definitely a stunt.
Hell, the fact that XP is handling an ultra wide display is enough to call bullshit xD
I just started my mbin instance a week or two ago. When I did, I wrote a guided install script (it's a long story, but I ended up having to blow away the server like 7 times and re-install).
This might be overkill for your purposes, but it's the kind of thing I have in mind.
Note1: Sorry, it's kinda sloppy. I need to clean it up before I submit a PR to the mbin devs for possible inclusion in their documentation.
Note2: It assumes that you're running a single-user instance, and on a single, small server, with no external requirements.
My profesional experience is in systems administration, cloud architecture, and automation, with considerations for corporate disaster recovery and regular 3rd party audits.
The short answer to all of your questions boil down to two things;
1: If you're going to maintain a system, write a script to build it, then use the script (I'll expand this below).
2: Expect a catastrophic failure. Total loss, server gone. As such; backup all unique or user-generated data regularly, and practice restoring it.
Okay back to #1; I prefer shell scripts (pick your favorite shell, doesn't matter which), because there are basically zero requirements. Your system will have your preferred shell installed within minutes of existing, there is no possibility that it won't. But why shell? Because then you don't need docker, or python, or a specific version of a specifc module/plugin/library/etc.
So okay, we're gonna write a script. "I should install by hand as I'm taking down notes" right? Hell, "I can write the script as I'm manually installing", "why can't that be my notes?". All totally valid, I do that too. But don't use the manually installed one and call it done. Set the server on fire, make a new one, run the script. If everything works, you didn't forget that "oh right, this thing real quick" requirement. You know your script will bring you from blank OS to working server.
Once you have those, the worst case scenario is "shit, it's gone... build new server, run script, restore backup". The penalty for critical loss of infrastructure is some downtime. If you want to avoid that, see if you can install the app on two servers, the DB on another two (with replication), and set up a cluster. Worst case (say the whole region is deleted) is the same; make new server, run script, restore backups.
If you really want to get into docker or etc after that, there's no blocker. You know how the build the system "bare metal", all that's left is describing it to docker. Or cloudformation, terraform, etc, etc, etc. I highly recommend doing it with shell first, because A: You learn a lot about the system and B: you're ready to troubleshoot it (if you want to figure out why it failed and try to mitigate it before it happens again, rather than just hitting "reset" every time).
I was hired at a small company a number of years ago. Contract-to-hire. One of those "we want to see you prove yourself before we actually hire you" deals. My role was to take over all of technical operations (cloud architecture, sysadmin, desktop support, the whole deal), so that the CTO didn't have to do it all himself.
One time - about a week in - I spent the entire day playing with kinetic sand in the main lobby (which was in full view of every developer and the CTO). Mostly, I was building little bricks (something like 0.5x1x2cm), and stacking them in a 2 sided 90 degree wall.
When asked what I was doing by several people throughout the day, I said "I'm rebuilding your network". I'm certain I looked like a crazy person. Honestly, it's not a totally invalid assessment in general, even now.
What I was actually doing was planning out the subnets, ACLs, and general routing for a series of servers (web front-ends, api servers, DB servers, etc), and weighing the pros and cons of AWS LBs vs HAProxy for various applications.
Over the next few days, I built out the new network and started migrating legacy servers into it. I demo'd the process and accompanied documentation (which I mostly kept in case I had to build another network, or rebuild this one after some catastrophic total loss), and they seemed impressed.
My 3 month contract was converted to direct-hire within 3 weeks, after a number of other enhancements (like centralized ssh auth via OpenLDAP - rather than everyone sharing the same default user RSA key - and total systems monitoring via Nagios). Each one came with about a day's worth of playing with some fidget or fixing some non-technical thing (like hanging a bunch of framed items in the lobby, which they'd been meaning to do, but wasn't a high priority, especially for the technical staff).
They'd have had all the reason in the world to assume the new guy was full of shit and was about to wash out, but after that they assumed that when I looked like I was majorly slacking off (usually well away from my desk, tinkering with something mindless) that I was about to build some new thing into the network, or up-end a process, or some other crazy (but ultimately useful) thing.
They definitely didn't mind when I would pace and talk to myself like a nut-bar (which I did/do frequently).
