Setting up Kubernetes (eg with Talos) really is a one-time investment in the sense that you have to figure out what you're doing (what operators to add, how to connect them to they work together, etc.) and is a valuable skill also for work.
Of course then there's the maintenance - updating operators, Kubernetes, whatever else you have, but you don't have to do it and if you want to do keep up with recent versions then it's just as much work as on Ubuntu or any other distro. The upside with k8s is that you can definitely roll back (I'm just assuming you're using GitOps).
Besides, you'll probably want to add all of that Kubernetes functionality at some point anyway - eg you may just at first deploy your server/app via ClickOps, have some issue, decide GitOps is the way to go, then decide that you really need to have automatic certs, then decide that DB backups would be good to have. With Kubernetes you just keep extending it and never really have to "rethink" the approach cos it's really difficult to shoot yourself in the foot unless you really want to and have a shred of understanding (and to clarify I'm speaking about small deployments), and of course because you're using it yourself your knowledge grows meaning that your expertise grows.
I was in US three times for work events. Every single time I would try to walk somewhere and would be forced to navigate around pickup trucks stopped in the middle of a freaking crosswalk. Sometimes those cars were so large that I could stand right in front of it and I’m convinced the driver would not be able to see me. It was by far the worst thing about my time in the US. Like you have so much space, why do you need to block the damn crossing?
Perhaps I wasn't clear enough - that was my point as well. You can do that, but when people switch to Kubernetes a lot of them do a proper (or better) job of avoiding that, but compare to previous experience where they'd just ssh to update the env, etc.
So I’m personally a huge fan of k8s and while I agree it may be „complicated”, it’s because deploying applications is complicated. (I want to point out that there is no requirement no set up cert manager, ArgoCD, external secrets, etc. - and many people who’d consider a VPS would happily slap a .env with an unencrypted secret then ssh to update, but when they choose Kubernetes they take the long route of doing proper GitOps and complain that there are so many things to configure :)
But I found funny that the OP summarized to use Kubernetes when CTO is no longer the only dev.
Website with solitaire/card games. There are so many sites, but all of them are either full of bugs, full of ads or both. So long time ago I've decided to write a site for myself that works really well, and then I shifted my attention to other projects.
This time - I'm so close! I probably need few more weeks to somewhat polish the game and fix the rendering quirks and I'll be ready to put it online for easy access when I'm bored lol.
Hmm, but weren't you already rating websites by clicking on the search results before? I don't see how that changes the game - and I must admit I don't know much about SEO - but in my view we were always rating results and that was influencing the position. Now they make the linking obsolete or at least less important signal... that's good? It means that relevant content is going to be surfaced to the top. Win-win honestly (and yes, Google will continue to use users-generated signals to drive their revenue like they always have).
This is great! I've been trying to get into local models for a while as I share the sentiment that local models will eventually be so good that there won't be a need to use frontier models for most coding tasks (perhaps that's already true today?).
I have zero experience building computers - where would I even start? I mean, aside from the things already well documented and mentioned in the blog post.
I agree, but for small tasks - <20 lines that I can understand in a minute or two - perfect. Thinking about it - I have hundreds, if not thousands of tasks that I would like to do, improving pipelines, migrating from one tool to another, but never have time. The only question is - if I don't have time to do it, do I have time to prompt it?
I was thinking for years about doing something like this. Thank you for linking this. Would be nice if it allowed to "reject" or mark a change to fix later, but honestly when it would need to be linked to some tracking tool and it would be overkill.
This is a great idea for some vibe coding tbh and you can customize it to match exactly the resources that you need as everyone has slightly different requirements for their k8s stack.
The simplest way to start probably would just be to create a custom Helm chart and define what you want in `values.yaml`.
Musk is the ultimate conman. I admire the work that SpaceX is doing, but Elon just plays the market, every single time. I don’t know why he’s allowed to do that and why people still fall for his promises.
This SpaceX thing will make him 2 trillion guy, not the 1 trillion he’s promised to be.
Sucks for the people to lose their jobs, but probably the most honest message you’ll ever see.
What I don’t understand is why. There’s a natural churn at each company. Of course it’s not 40%, but probably 4-5% per year, but I doubt the company freezes hiring and they are not pressured to do this.
Of course then there's the maintenance - updating operators, Kubernetes, whatever else you have, but you don't have to do it and if you want to do keep up with recent versions then it's just as much work as on Ubuntu or any other distro. The upside with k8s is that you can definitely roll back (I'm just assuming you're using GitOps).
Besides, you'll probably want to add all of that Kubernetes functionality at some point anyway - eg you may just at first deploy your server/app via ClickOps, have some issue, decide GitOps is the way to go, then decide that you really need to have automatic certs, then decide that DB backups would be good to have. With Kubernetes you just keep extending it and never really have to "rethink" the approach cos it's really difficult to shoot yourself in the foot unless you really want to and have a shred of understanding (and to clarify I'm speaking about small deployments), and of course because you're using it yourself your knowledge grows meaning that your expertise grows.