AlexanderESmith

To add to this; I've done some corporate work in this area as a systems admin. If something like this comes up (within the context of being a representative of a company that finds out that someone has a domain that we may hold rights to), one of the things I've been asked to do is submit a "Uniform Domain-Name Dispute-Resolution Policy" (UDRP) complaint to ICANN (icann.org - Internet Corporation for Assigned Names and Numbers). They basically regulate domain usage and ownership, among many other things.

To read about how these complaints work, see; https://www.icann.org/resources/pages/help/dndr/udrp-en

Read that over while deciding whether you want to use the domain and how you use it. Give particular attention to https://www.icann.org/resources/pages/udrp-rules-2024-02-21-en , section 3-b-ix (titled "Describe, in accordance with the Policy, the grounds on which the complaint is made..."), and it's sub-items.

I never minded the difficulty. I knew what I was signing up for.

What I minded (and why I stopped playing Elden Ring only a few months after release after like 120 mostly-fun hours) was that they couldn't stop fucking with the balance. Some jackass would min-max some specific PvP build, and they'd nerf the shit out of it (even in PvE), then my semi-okay build (which used one part or another of the min-max build) would go to shit and I'd have to start over. This happened like 4 times and I just said "fuck it" until the game was old enough that they'd stop fucking with it.

lol, joke's on me, here we go again.

LinkedIn is Facebook, if the people you follow could fire you for not being a total brown-nosing boot licker.

Well, the other option is an unemployable dipshit that needs somewhere to rant, thereby making themselves even less employable.

When journalists had integrity, they protected the identity of their sources. Not just for the sake of their own reputation and that of the source, but also because once you fuck up that trust, no-one will talk to you anymore (or only do it anonymously, and there's a lot of opportunity to get fucked with when you don't know who your source is, which means you need to spend a lot more time vetting).

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.

1. Install the OS - You've done this already.
2. 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.
3. 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
4. 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).

I'm happy to answer follow-up questions.

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.

https://alexanderesmith.com/mbin/install_mbin.bash

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).

heh, pulling out

threadiverse plays Pokemon

It was unclear if Lindell would retain new counsel in the case. As Foster pointed out, business entities cannot represent themselves in court.

lol not even if he wanted to (which would be very entertaining to watch, sadly)