But if I understand it right, auto_ptr assignment didn't actually copy the pointer, but instead moved it to a new variable and quietly made the original variable null? And unique_ptr made this operation require an explicit move() call, because the assignment-only style caused too many null pointer bugs.
I'm just curious about this for historical interest.
Wasn't unique_ptr added as a migration path away from auto_ptr to provide similar functionality more safely? I've never used them but was just reading the history.
Yes, and like I mentioned in another comment, I consider this a major painpoint and problem with Node.js based applications. I have high hopes that eventually there will be an "evergreen" WebAssembly based Lambda function runtime.
The things that you just described are not automation, but human activities needed to tackle the new situation by following news and creating new automation. Which kind of proves my point that you cannot prepare for every unexpected situation before it actually happens. Except maybe with AI in the future.
I'm curious about this trivial automation. Let's say the new OS LTS version no longer includes nginx, because it was replaced by a new product with different config. How does the automation figure out what the new server package is and migrate your old Nginx config to the new format?
I agree with Node.js version deprecations being a huge problem and personally advocate for an evergreen WebAssembly platform for running apps. Apps should run forever even if the underlying platform completely changes, and only require updating if the app itself contains something that needs updating.
This is not about how easy or difficult it is to issue TLS certificates, to configure SSH keys or to update the OS. It's about having to actively maintain them yourself in every possible situation until eternity, like when TLS versions are deprecated, SSH key algorithms are quantum-hacked, backward-incompatible new OS LTS versions are released, and so on. You will always have new stuff come up that you need to take care of.
When buying the infrastructure as a managed cloud service, yes, I trust that they've got people handling it better than I could myself. The value proposition is that I don't even see the underlying infrastructure below a certain level, and they take care of it.
You might be right. I've been mostly using serverless / managed cloud services such as AWS Lambda, API Gateway, S3, DynamoDB for the past 10+ years. When I've needed to respond, it's been because I myself deployed a bad update and needed to roll it back, or a third party integration broke. The cloud platform itself has been very stable, and during the couple of bigger incidents that have happened, I've just waited for AWS to fix it and for things to start working again.
Maybe you're right - I've never tried dokploy, but from documentation it sounds like mostly a deployment, monitoring and alerting tool. For me the problem has always been that once you get the alert (or something just stops working), a human needs to react to it and make things work again. In cloud services you mostly pay for them providing the human, and in self-hosting you're the human.
I can see though that today's AI models could eventually replace the human in the loop and truly automatically fix every possible situation.
It means you take responsibility of maintaining the server forever, i.e. dealing with TLS certificates, SSH keys, security updates, OS/package updates, monitoring, reboots when stuck, redeploy when VPS retired, etc. Usually things work fine for a year or two and then stuff starts to get old and need attention and eat your time.
Sad to see it go. The philosophy of CDK has been to offer a shared ecosystem between IaC, backend code and frontend code, allowing to share configuration, data structures and libraries between all of them. It has made development more unified and have less redundancy and manual work. Personally I don't want to repeat some stuff in a special Terraform language, if I can find a way to manage the whole application in TypeScript.
I feel the opposite about SQL: It is often being shoehorned into use cases that don't fit the relative/transactional database model at all. My own default database is AWS DynamoDB, because it fits 90% of my own use cases quite well and offers a fast approach for iterative development. Recently I've been evaluating how to find the same level of abstraction in open source databases, and MongoDB feels like the closest match. Postgres with JSONB comes second, but manipulating JSON with SQL is not very comfortable and tends to result in subtle problems e.g. when something is NULL.
I think the author is implicitly describing the paradigm shift from software and hardware abstractions to service abstractions. We used to make computers by soldering electronics together, then by assembling cases and components, then buying premade servers, then renting cloud capacity, and now we're starting to rent everything as services.
The cloud is about going from capex to opex and the "capex" now is the initial work needed to define your own architectures and stacks for every project (before you get to work on the actual project, i.e. the differentiating part). Amazon is eliminating most of this by offering building block services that fit together with little hassle.
So the challenge for open source is how to move on to this era of service abstraction. It's no longer enough to just provide an NPM package or a configure script.
I think Docker is in a good position to bring us there, but it's currently stuck at the stateless container level. Something needs to evolve so that launching a scalable and auto-maintainable database cluster along with a connected web application cluster is as easy with Docker as it is by renting a few Amazon service.
I'm just curious about this for historical interest.