catdog

> Proxmox is merely Debian with some fancy curtains.

It's part of the appeal that it is mostly just Debian under the hood. If I want to run containers I would also not see it as the best choice but it really shines in managing qemu VMs.

Also your script often might not be that battle tested, more likely it will have bugs and miss a few important edge cases.

> there's a special place in hell for helm in particular for using text/template to generate yaml

Indeed. Using text templating for structured documents is already quite bad, doing it with a significant whitespace language it's absolute hell.

It's the industry standard for running and shipping containerized applications, at least for the ones which are more complex and/or dynamic than an application container and maybe 1-2 databases. It provides a well defined and stable orchestration API which is also quite capable. It's even sometimes worthwhile to spin up a single node cluster for that reason. Does not mean it is perfect, is it sometimes a bit complex? yes, is it verbose? yes, could the established ecosystem be better (thinking about e.g. helm)? yes. But at some point it's still easier with k8s than without it.

It is of course not the best choice for everything, there are enough things where you better just spin up a VM and deploy directly or with only a simple container runtime if you use containers.

On low power, mostly idle systems that's definitely a downside. K8s is always busy, probably largely because it's whole architecture is centered around reconciliation loops which contentiously compare the actual state to the desired state. It's not much but enough to prevent the CPU from entering its lowest power states.

That's really a huge issue right now (to some extent even before the AI hype) that almost everywhere google is effectively the only entity explicitly allowed to scrape.

Maybe they have just too much money at hand, would not surprise me, people are still investing into gen AI like there is no tomorrow. Also, for the completely criminal operations, you only have to find a way to infect and distribute your bot to, e.g. some common internet of shit device. Scaling is basically free afterwards as you don't need to ask anyone. The article also hints that those are actually the biggest problem.

Then there is probably also a lot of time pressure on the people implementing and operating those scrapers so they have even less incentive to optimize their code.

Same here, the usefulness of the slop machines is quite limited compared to the downsides.

Yep quite useless. It's well known that postgres defaults are tuned for low resource usage, not for max performance. There are calculators like https://pgtune.leopard.in.ua/ to get a better than default config with next to no effort.

Switched to that one some time ago, more features and adapts faster to changes in newer proxmox versions https://github.com/bpg/terraform-provider-proxmox

I think it will in general go more into the direction of using the technology a bit smarter. This will include smaller models but certainly also just less usage overall. Currently a lot of people seem to just burn through tokens without thinking much about what they actually get in return or if an LLM really is actually overall the best tool for the job.

> This is just how the VC game works. Cross-town Uber rides don't stay $5 forever.

Basically yes but there is a small difference I think. Things like Uber took an existing and proven business model. slapped an App on top and priced the competition out of the market. The winner takes it all.

With "AI" it's not yet clear if there will be any winner at all because it's not yet proven if the business model is viable at the "real" price. Think air taxis across town, 5$ a ride, will work at scale for sure, probably won't work for 500$.

Really need to try PyInfra, the concept sounds nice.

You don't have to do crazy things with Ansible for that yaml DSL becoming the opposite of helpful. Things which would be quite straightforward to express in code become quite cumbersome, hard to understand and hard to debug. Also Jinja is often a horrible choice (you don't have in Ansible). Also Ansible excessively requires it in places where you want proper types and not just a string.

I think in general not being able to replace the battery toolless is quite an acceptable compromise nowadays. The needed mechanism and the protective shell the replaceable battery needs definitely takes up space which can be used for more capacity instead. You have (sometimes quite insane) fast charging and also powerbanks which support it. Also quality batteries can be quite durable.

The real problem I think is the hostility towards repair, glue everywhere, no spare parts, etc.

Also availability of original spare parts is important. Aftermarket batteries often tend to be shitty.

Nonsense. It just mandates easier repairability and spare parts availability, not ad-hoc replacement. Also this does not apply if the battery is able to retain 80% of its original capacity after 1,000 charge cycles so "innovative" manufacturers just need to use high quality batteries.

You can even use the chip on the card together with some cheap HW device to authorize the transactions made with the app. This actually exists [1] for quite some time but seems to be mostly limited to Germany. But this and the use of other HW tokens systems is on decline. Banks increasingly use apps now, increasingly without any meaningful second factor, not even offering better options. They want this and are fully to blame.

[1] https://en.wikipedia.org/wiki/Transaction_authentication_num... (This is a bit outdated, nowadays it works via QR codes instead of those flickering barcodes but the concept stays the same)

> But the job had better take fewer people, or the automation is not justified.

Not necessarily. Automation may also just result in higher quality output because it eliminates mistakes (less the case with "AI" automation though) and frees up time for the humans to actually quality control. This might require the people on average to be more skilled though.

Even if it only results in higher output volume you often have the effect that demand grows also because the price goes down.

“Markets can remain irrational longer than you can remain solvent.” ― John Maynard Keynes

The thing is, there is next to no software that "doesn't need further changes" at all. There is always something, sure it might be infrequent and/or most of the time nothing really big or difficult (except sometimes) but the point is: someone needs to step up and do it.

If a see a project with recent activity, best from multiple people it is a strong signal that this will happen, if the last commit is a year ago I must assume it's completely abandoned because most of the time it just is. Sometimes it's clearly communicated that it is the way because the authors see it as essentially feature complete, there are some examples of this but not that many honestly.

It's an application issue but implementation wise it's probably way more straightforward to just open a separate network connection per thread.

An LLM is an impressive, yet still imperfect and unpredictable translation machine. The code it outputs can only be as good as your prompt is precise, minus the often blatant mistakes it makes.

Yep writing the code might have gotten a little bit easier but was never was the hard part to begin with.

Like with most technological change I think there is no need for FOMO. You run into problems if you completely ignore already established and proven tools and practices for years to come but you don't have to jump onto every "this changes everything, trust me bro" hype.

Independent of ones philosophical stance on the broader topic: I find it highly concerning that AI companies, at least right now, seem to be largely exempt from all those rules which apply to everyone else, often enforced rigorously.

Also it's not only the work of "the model" it's the work of human beings the model is trained on, often illegally.

> The key phrase here is “requirements analysis” and if you’re not good at it either your software sucks or you’re going to iterate needlessly and waste massive time including on bad architecture. You don’t iterate the foundation of a house.

This depends heavily on the kind of problem you are trying to solve. In a lot of cases requirements are not fixed but evolve over time, either reacting to changes in the real word environment or by just realizing things which are nice in theory are not working out in practice.

You don’t iterate the foundation of a house because we have done it enough times and also the environment the house exists in (geography, climate, ...) is usually not expected to change much. If that were the case we would certainly build houses differently than we usually do.

As it is so often in life, extreme approaches are often bad. If you do pure waterfall you risk finding out very late that your plan might not work out, either because of unforeseen technical difficulties implementing it, the given requirements actually being wrong/incomplete or just simply missing the point in time where you planned enough. If you do extreme agile you often end up with a shit architecture which actually, among other things, hurt your future agility but you get a result which you can validate against reality. The "oh, I didn't think of that" is definitely present in both extremes.

> A better formulation is "every feature is a liability". Taking it to the line of code level is too prescriptive.

Amount of code is a huge factor but maybe not the best wording here. It's more a thing of complexity where amount of code is a contributing metric but not the only one. You can very easily have a feature implemented in a too complex way and with too much code (esp. if an LLM generated the code but also with human developers). Also not every feature is equal.

> Occasionally writing more verbose code is preferable if it makes it easier to understand.

Think this is more a classic case of "if the metric becomes a goal it ceases to be a metric" than it being a bad metric per se.

> People talk about an AI bubble. What we actually have is a GPU bubble. NVidia makes really expensive GPUs for AI. Others also make GPUs.

Yes it is. I think even for multiple reasons. Competition in that space not sleeping is one but it's also a huge overestimation of demand combined with the questionable believe those GPUs and the Datacenters housing them can actually be built and put into operation as fast as envisioned.

> The reason that this 100B deal is apparently being reconsidered is that it is a bad deal for OpenAI. It was going to overpay for a solution that they can get cheaper elsewhere. It's bad news for NVidia, good news for OpenAI. This deal started out with just NVidia. But at this point there are also deals with AMD, MS, and others. OpenAI like the other hyperscalers is not betting the company on NVidia/CUDA. Good for them.

I think in case of OpenAI both may be true. While what you are saying makes sense, NVs first mover advantage obviously can't last forever, OpenAI currently does have little to no competitive advantage over other players. Combine this with the fact that some (esp. Google) sit on a huge pile of cash. In contrast for OpenAI the party is pretty much over as soon as investors stop throwing money into the oven so they might need to cut back a bit.