To be honest, with Azure Devops platforms, web app instances, containers and deployment slots, its almost bulletproof once you spend the time to get it originally configured. Same with AWS I imagine.
Deciding to sell this on the darknet is a life changing decision, white to black overnight and imagine not really something most would contemplate. Payment in BTC probably from an already compromised address so loads of factors. Probably an easy + quick 2BTC though
The newer generation smart meters operate on their own network, so that its critical and separate infrastructure so this won't happen again in the future. Also you have to be pretty set on not getting a smart meter as it removes you from a lot of competitive energy deals, especially ones with a cheaper night rate.
Without knowing the problem or context, I will take this on the basis of a "coding problem" where I may be tasked to create a piece of software/code/webapp to solve the needs. I take things a bit differently to most, I find the best way (for me) is to start tackling the problem with the tools I have, and then when I get stuck, see what I can do to fix it. I don't believe any problems I face have no solution, its just how long it takes/much it costs.
The only certainty in tech, is that there will always be some tool/software package that looks to solve an already established solution with a new approach, only time will tell if it will be successful. Reflecting on the past can shed light on why somethings remain unchanged decades later, and why others have fallen behind. But I think the real answer to your question, is whilst having a coffee/tea/break whatever, it can be nice to read an older article, or a new article on old software, to remind yourself about the "old days" or see how you wold solve a past problem today. It's a bit like classic cars, some people like to buy the car they had or couldn't afford when they were a teenager, equally now as a tech worker (hopefully earning good money) you can indulge and purchase a snes/COM64/Apple 2gs or whatever.
That's a great read, many people get burned out. Have spoken to a few people who left the industry to do something else, most of them came back a few never did. The grass isn't always greener, some people can easily work through a burnout and come through the other side, others simply need a few months off to re-ignite the flame. It can just be working in the wrong environment, switch to a smaller team maybe? A few friends of mine ditched the startup wheel and now work for an agency producing "standard" websites/cms and enjoy their life so much more.
I have been using chroot since approx 04 when I found it during my first Gentoo install, what docker did for me was make it so much easier to deploy various environments, due to how much exposure they have. It took a good amount of effort to make chroot both "cool" and widely available to both sys admins and developers. Sadly what it has done, is make users less aware of the core Linux/Unix principles that allow us to have cool software that just does it all for us.
Yea, I have tried OpenBSD a few times, but sadly I just don't have enough time to invest in my OS to get the most out of it. I use my machines until they fail, then replace them with a new one/part. A fresh install of ubuntu and they are ready for work in 30mins. I used NixOS for a small period of time for this reason, but even this became more of a headache than it was worth.
As someone who has used FreeBSD exclusively on bare-metal corporate production servers for the last 10 years, I still wouldn't use it on desktops/workstations. It's built as a server OS and my opinion is that it does this very well, I have tried a few times over the years to use it as a destkop OS, I spent more time configuring my machine than I did actually using it. I can install Ubuntu and 30mins later be using it for work with no issues.
If you run your own servers, especially ones that you physically have to maintain the hardware on, FreeBSD is a very reliable choice and the upgrade paths on it are fantastic. I now run some services in Azure and use docker, but all my "on prem" stuff, is still freeBSD powered.
So for some reason I am just discovering borg (been an rsync.net customer since 2014), currently all my data is GPG encrypted on the client side, so database dumps, files and server logs. I have a custom script that encrypts all files, then rsyncs them to rsync.net, if I need them, rsync them back to a local machine and decrypt using GPG. A drawn out process that seems quite antiquated, especially seeing as my need to access these backups is maybe once per year. It would seem from initial (quick) reading, borg just basically makes this whole process easier and arguably even more secure?
I'm sorry, if you cannot see the benefits to running programs inside a container, then you have been reading the wrong article. I have been using FreeBSD jails for years, and now on Linux deployments, docker as well.
Lets say you have a server, it runs a mail server, database server, web server (proxy) and application server.
If they all run without containers, if one service gets compromised, and a root exploit is found, that's it game over.
If you have a service that starts eating up memory, with proper configuration, it can't overload the root server. Basically each jail/container can only see itself and any exploits cannot effect the host system, or other jails/containers (when configured correctly).
It also allows for easy expansion, when one jailed/containered service gets to large for the server, just move it to another server easily and quickly.
It also allows for speedy deployment, with docker you can bundle everything on your laptop, create an image, then ship this straight to an external host like EC2/Goole Cloud (for example), with the addition of pre built containers for Django/Rails/Postgres/MySQL etc, it creates a ready working environment for developers who might not be to hot on configuring systems. The "shipping" ability to docker is a by product of the container which is another added benefit. There are loads more features than what I have stated here, this is just a very brief summary.
In current times if a site was expecting high load or large amounts of traffic, it would be a bad idea NOT to have it behind a well configured load balancer and tested to a scale beyond what you expect. A simple python web API can handle 3k requests per second on a fairly average server, so either your software choice or production method would need analysing if you are worried about downtime at high usage.
Use a whiteboard/pen paper with a webcam, as if you two were in the same room. Just because we have every productivity application available to us, it doesn't mean we have to use them or approach things any differently, half of the time these products are solving problems that don't exist, keep it simple, communicate and get results.
The correct way todo this is setup a load balancer, then use route 53 to manage the dns, set the root domain to your load balancer I'D then map the www cname to the root domain, this solves all problems and takes under 5 minutes to configure.
When you stat answering more questions on irc and stackoverflow than you ask about complicated areas.
Building basic sites ans blogs is easy, but say someone asked you to read data from an old database or connect to a payment backend that doesn't have a django plugin, could you write your own? You also need to be able to support every plugin you use if/when that plugin gets dropped by the author.
If your going to freelance I would get very familiar with your own cms and blog system so you know it inside out, or best yet, write your own from scratch, then you aren't maintaining other people's code.