It's a beast in terms of complexity, in my opinion. But the vendor only supports running it on specific configurations.

There are a few brands out there but the Philips ones seemed better than the others and the prices were not as insane. I just disliked their marketing and buzzword filled content but otherwise they seem OK. Oh and you should know a lot of their stuff now are internet connected(disabling it will make you lose some functions but otherwise the device still works) and have touch buttons and screens etc. It's unfortunate but this seems to be where every device is heading.

I do agree with you that this seems overly complex. You can pretty much do it yourself if you'd like to take on a project. A fan and a constantly wet rag has the same function but is not as compact.

That part made me laugh and reflects my experience when I was working on "enterprise development" teams.

I'm curious about having this run on a VPS as opposed to a local VM. What does that provide you? I understand having the VM completely disconnected from your local network etc but is there anything besides that? I ask because mentioning the cost here seemed like one of the important points but that cost wasn't necessary for the experiment itself.

The businesses fired the staff and pocketed the difference. The result? Growth, at least on paper, as you're saying. Previously they were paying for 10 people and now they're paying for 2 so more profit yay! Of course this is a short term gain which might result in long term pain. That last part remains to be seen.

For a while, it felt like I'm in a minority when I was saying that it can be a useful tool for certain things but it's not the magic that the sales guys are saying it is. Instead, all the hype and the "get rid of your programmers" messaging made it into this provocative issue.

HN was not immune to this phenomenon with certain HN accounts playing an active part in this. LLMs are/were supposed to be an iteration of machine learning/AI tools in general, instead they became a religion.

Working to the point of making yourself sick should not be seen as a mark of pride, it is a sign that something is broken. Not necessarily the individual, maybe the system the individual is in.

[1] Medicine may be one example of an industry with poor work-life balance for some, specifically specialists. But job security there is unmatched and compensation is eye-watering.

The market rates were going up(and inflation going up more), people would ask their employers for an increase in compensation and get denied with broken promises. They'd wait to see if those promises go anywhere and then realize it's not going to happen so decide to change employers(and their employers act shocked).

Similarly, employment conditions were deteriorating and burn out spreading. People would ask their employers for a change in conditions such as hiring more staff and get denied with broken promises. They'd wait and well, see above.

On the other side of the spectrum, there were some with over 10 years of experience at the same place and lacked the knowledge of anything outside their employer's bubble. Their manager changed or redundancies started or something triggers and now they have to look elsewhere with their "loyalty" meaning nothing except being a detriment.

And if I may offer some more advice, it sounds like you need a technical co-founder as you're describing multiple roles and skills.

They all insisted that it was essential to have a CI/CD process but didn't even know what the "CD" part even did. Apparently you just "git push" and the code magically gets on the server. There are many ways to do deployments and a CI/CD process isn't always suitable and can have many forms, in my opinion, but I was happy to discuss any and all. But it's difficult to do that without the basics. As you said, before I was commissioned the platform had no documentation, was crumbling under tech debt and failing constantly so something like getting on the server to at least figure out what's going on was essential.

Finding a simple GUI is not going to be easy because everyone has a different definition of what "simple" means. It also depends on what you mean by "review" and "manage". There were a few web UIs for LXD containers and they were ported or used for Incus containers. Some are still maintained and active.

I personally prefer the command line and find it easier and simpler than using graphical interfaces so don't have a recommendation. When the number of containers and servers becomes large enough to warrant anything else, then that's when automation starts.

I would suggest you organize your thoughts and write down the list of what you think you need and then either pay for a consult with a senior developer or chat with a trusted technical person.

From your posts, it sounds like you need more than one role and/or the services of an agency. If money is the issue and you think you have a good idea, then I suggest you seek funding.

To me, there's a big difference between saying that migration projects can now be assisted with some AI tooling and saying that it is cheap and to just get Claude to do it.

Maybe I am out of touch but the former is realistic and the latter is just magical hand-waving.

I noticed that some of these roles come from businesses that recently had layoffs and were now asking their staff to "do more with less" so not exactly places people would be eager to work at, unless they have to.

I don't know if this is the new norm but this craziness is not helped by the increase in the number of "AI influencers" pushing the hype. Unfortunately, I've been seeing this on HN a lot recently.

In my experience, the problem had always been maintaining the business logic and any integrations with third-party software that also may be running legacy code-bases or have been abandoned. It can get quite complicated, from what I've seen. Now of course if you're talking about well maintained code-bases with 100%, or close to 100% test coverage, and that includes the integration part along with having the ability to maintain the user experience and/or user interface then yes it becomes a relatively easy process of "just write the code". But, in my experience, this has never been the case.

For the 2.x code-bases I maintain, the customers simply doesn't want to pay for any of it. They might choose to at a later time, but so far it has been more cost effective for them to pay me to maintain that legacy code than pay to have it migrated. Other customers have different needs and thus budget differently.

I'll refrain from judging if 2 to 3 was a missed opportunity or not. I believe the core team does actually know what they're doing and that any decision would've been criticized.

Although your general sentiment is something I agree with(if it's going to be painful do it and get it over with), I don't believe anybody knew or could've guessed what the reaction of the ecosystem would be.

Your last point about being able to change internals more freely is also great in theory but very difficult(if not impossible) to achieve in practice.

I don't know. Having maintained some small projects that were free and open source, I saw the hostility and entitlement that can come from that position. And those projects were a spec of dust next to something like Python. So I think the core team is doing the best they can. It was always going to be damned if you do, damned if you don't.