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.
> 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.
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.
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.
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.
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.