kennu

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.

Thanks, will definitely look into it. I first used Pulumi when it was just a cloud platform but seems it is a more general devops tool now.

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.

Scrolling with mouse scroll wheel a few hundred thousand kilometers at a time is so much work that I gave up :-(

At minimum, the government gets a "ping" when identified citizens visit adult sites requiring the age check, so they can keep a record. In worse scenarios, maybe some identifier leaks through that can also identify which site they visited. And of course, the identification apps can be hacked through supply chain attacks etc.

I don't really know what to do with a dumbphone, since I don't get any phone calls or text messages any more. Everything goes through apps, email or web nowadays.

I guess there's many cases where you don't really know how complicated or simple the solution will end up to be, and start drawing it while thinking about it.. I must admit that those are usually the most interesting parts of the work.

I understand the sentiment, but I don't get how you could draw more complex software plans by hand. I usually use Draw.io/Diagrams.net, and the drawings get pretty large and need reorganizing dozens of boxes several times while planning the architecture.

OTOH if the plan is very simple and obvious, and can be drawn out in one go, it doesn't really need a diagram in the first place, so I skip spending time drawing the obvious stuff.

My main issue in the EU is that cloud platform services are not very mature compared to AWS, Azure, GCP. They have some of the basic stuff like VMs and storage, but almost nobody has FaaS and the smaller services like SQS, SNS, scalable pay-per-request database like DynamoDB, etc. I hope these things become available so that it becomes possible to build scalable serverless apps here. Ultimately these services should be standardized like S3 did for storage.

Cursor is not about vibe coding. Vibe coding means you don't care about the AI's code output as long as it works. Cursor is all about efficiently reviewing the AI-proposed changes and hitting Tab only when you approve them. Much of the editing process is hitting Esc because the proposed change is not good.

I got my first fixed IP address and always-on Internet connection in 1995 and I don't particularly miss the dial-up times before that. I prefer to have everything connected and online all the time, but also with proper security.

It's funny how back in the 1990s the concept of software was different. You might buy an actual shrink wrapped package with an install disc and be happy with it for years. Nowadays it would be unthinkable to use software without getting regular updates (at least security updates) and always being able to install the latest version.

I'm really happy with my Bosch washing machine's WiFi. Getting a notification to the phone when the wash cycle is complete is something I wouldn't give up now, since I don't hear the beeping to upstairs. I also wish I'd get notifications from the dish washer, but it's an old model that still works and it's hard to justify replacing it yet.

I also have no clue what all the physical buttons on the washing machine's control panel do, but it's easy to configure the wash program using the phone app whenever something special is needed. I wish I had the same kind of remote control for the dish washer, since its buttons are also pretty much undecipherable.

The actual Home Connect Android app is not great though. Could be simplified and cleaned up of unnecessary cruft.

I disagree with smaller docs being easier to write. Quite the opposite, it is easy to write longer text, which then requires more effort from the reader to understand it.

To write shorter text, you must put in the effort beforehand to compact, crystallize and organize the ideas. Each reader then doesn't have to do that themselves in their heads.

Maybe not save "us", but possibly the Rohingya during the Myanmar genocide, which was fueled by hate speech and disinformation spread through and promoted by Facebook.

My impression is that the current Sonos app becomes unusable when your home Internet connection is unstable. It usually works fine here, but when our 5G starts switching channels due to a snowstorm, the Sonos app becomes erratic.

I understand there's also issues with mDNS discovery and maybe other things, but the worst mistake seems to be the assumption that everybody has a stable Internet connection all the time.

There are other apps that have made a similar mistake. E.g. Ubiquiti's UniFi management app has problems connecting to the local LAN console if you originally signed in using a cloud account and Internet becomes unstable.

One app that handles this right is the Home Assistant Companion app. It detects when you're using a local WiFi SSID and connects directly to the internal LAN address which always works, and otherwise uses the cloud connection or public WAN address.

Whenever I have created API keys for a product, this is the #1 feature I want: easy copy-pasteability. Just letters and numbers, no special characters that break double-click-selecting the key.

AWS SDKs handle some important stuff though, such as retrying database operations with backoff delays. Without it your app will fail in unexpected situations because the cloud service is designed to be stateless and return specific error codes when the client needs to retry.

For me, 2024 was the year I finally got completely rid of Windows and switched fully to Ubuntu on all computers. I had kept Windows for playing Steam games, but I realized Proton will play them just fine on Linux when you enable it in the Steam compatibility settings.

It feels really good to get rid of WSL, Docker in VM and other hacks that kind of make Windows work for development, but always cause various issues. Developing natively on Linux just lets you forget all those hacks.

One thing I also did was switch from NVIDIA RTX to Radeon RX. I haven't had to worry about GPU drivers and settings and heat issues in Linux after that.

There are many interesting Web3 apps, like decentralized social media, decentralized web (IPFS), decentralized domain names, decentralized organization management, etc, but they have not seemed to mature enough to become mainstream. They all have various kinds of problems with usability especially for "ordinary people". But the core idea is there and it's good: Make the Internet truly decentralized and peer-to-peer again, and enable it by incentivization via crypto transactions. But it's going to take time.