HN user
It's doable but has limited benefits when they're limited to 2-4 GB of RAM anyway.
Back in the day there was no real benefit. Today it's different as most Linux distros don't really care much about supporting 32 bit anymore.
I owned a Samsung NC10 which had a non-shitty keyboard as its outstanding feature. Was a nice little Linux machine I used a lot. Only bad thing, those Intel Atom N2xx CPUs are just awfully slow, even back then.
Today realistically I don't think it really makes that much sense to bother with those devices even for small home servers. You can e.g. get used thin clients for cheap which run circles around those old CPUs and support way more RAM while likely being as power efficient if not more. At the bare minimum I would avoid using any 32 bit x86 CPU for running anything modern, even Debian dropped official support for that architecture now.
Sadly even back in the day mostly some very early models shipped with Linux as Microsoft promptly made sure they don't.
Except for the price. Apart from portability and battery life a huge factor was them being (very) low cost.
Netbooks didn’t need Microsoft’s help in dying. Nobody bought more than one of them, the experience was that bad.
If I remember correctly Microsoft put a limit on the HW specs for getting those cheap Windows copies while simultaneously making sure they all shipped with Windows which did not run that well on that low spec hardware. I think this is a huge part why this category died that quickly.
On the other hand there was also just general technological progress happening, "full size" notebooks were generally getting a lot more compact and lightweight so there was less need for that separate category.
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.