I think that the fact that AI has a very recognizable singular style is a problem. And this problem will be solved, sooner or later. It probably isn't a very important problem, because I feel that it should be relatively easy to solve (but maybe I'm wrong?).
But certainly with smarter AI I do believe it'll become more fluent with choosing more diverse idioms and phrasing, rather than repeating one thing over and over, to a point of being a comically similar. So people who learn on AI-generated text, will not learn from just one recurring style.
You can actually do that today. In fact I did that for some time, because I didn't want to configure e-mail client. The only hard thing is HTML. Average HTML e-mail is almost impossible to read and friction to extract it to a file to open in a browser is too much.
You can't do that with HTTP/2 (but thankfully every server still talks HTTP/1).
You also can't do that with TLS (and a lot of servers won't talk HTTP other than redirects). openssl s_client instead of telnet might allow you to tunnel text inside TLS, but that feels like a cheating.
And many other modern protocols, sadly, prefer binary encoding, which makes it impossible to tinker with it on wire level, not without specialized tools anyway.
I think people in the future will bother. I tried to make a fire with sticks once, I tried to burn a clay brick, these old things can be a lot of fun and sometimes of real use. If anything, AI actually makes tinkering a lot more easier. You don't need to dig into RFC to check your mail, you can just talk to LLM about it and it'll help you with most typical IMAP commands, for example.
You can actually treat kubernetes as a glorified docker compose engine. Deploy pods, deploy nginx instead of ingress controller, deploy certbot cronjob instead of cert-manager, and believe it or not, it'll work! On a single server!
People often compare Kubernetes with thousands of additional services to a simple VPS, but that's not apples to apples comparison.
1. You can't force third-party software to do that. There are programs with hardcored ports. There are programs which require XML modifications and container rebuilds to change port number. If your platform does not support launching of unmodified containers, it is severely restricted and not suitable for general use. All my programs always use port 8080 for HTTP, I don't make it configurable because I have no reason to.
2. Does not work for all protocols. Again your solution restricts the number of protocols to HTTP protocols. Might work for many uses, but still this restriction doesn't sound very good. Universal load balancer is much simpler conceptually.
3. YAML is not terrible. YAML is awesome. Kubernetes manifests are terrible, that's I agree with. Docker compose is nice, for example. Kubernetes manifests felt like they were designed to be generated from something, but everyone ended up writing them directly or with templates. Though I think that XML generally is superior format so I'd vote for XML in the end.
Overall your suggestions look like you want to shift complexity from cluster operator to software developer. I'm not sure industry supports that, recently it seems to move in the opposite direction, but that's interesting perspective. I guess with some wrappers for some containers it could be made usable.
But honestly you just want to throw away years of progress in containers and network namespaces. I understand that kubernetes mechanisms are somewhat complicated, but the core idea is to make pods look like virtual machines and I think this is very worthy idea.
Docker swarm is that simple solution you're looking for. But people don't need simple solutions. They want scalable solutions and Kubernetes fits this niche perfectly. You can deploy it on single server today and scale to 100 servers managed cluster tomorrow.
Just to provide a similar example. Linux system is insanely complicated. Kernel alone has thousands of options. Distos have tens of thousands of packages. Wherever you look at, everything is hard and complicated. Firewall, containers, init system, filesystem hierarchy, storage layers. One would think that some people desire simpler operating system. But everybody uses Linux despite all these complexities. Try to find OpenBSD in production, for example. It's not easy.
As I'm currently exploring kernel build things, the alternative to `make tinyconfig` is `make allnoconfig` which is supposedly will not disable expert options and might be a little bit safer starting point.
But he already got it, no? Claude Fable can only be made available to US citizens, which implies that every user who wants to use Claude Fable must provide proof of citizenship in some way, basically KYC.
> does the users who use Anthropic switch over to those even if they're available even as hosted models?
I'm currently spending $200 for Claude. That's around my maximum that I can afford. I could stretch that to $500 I guess. But I saw reports of people spending tens of thousands of dollars with Claude API. That's certainly outside of my budget.
So if/when Anthropic decides to stop subsidizing subscription (if they ever do that thing, I still not sure about that), I'll certainly look at the other options. And available "open weights" LLMs hosted by someone will be my first pick. Right now Claude 4.8 feels very advanced, but things move very fast...
> If it were that easy, everyone would be doing it.
E2E encryption is one click away in Telegram. I've yet to find anyone turn it on. Most people just do not care about encryption. The whole encryption story is pulled into mainstream by crypto-enthusiasts IMO.
Of course it is possible to have E2E encryption on emails. You can have E2E encryption on everything. Just use `age` and encrypt your message with sender public key. Easy.
> I've been saved so many times by a git bisect that landed pointing at a tiny commit to a single line that looks completely innocuous, yet broke something in a subtle way that only got discovered way later.
Their detection is too aggressive. Just today I'm trying to build a kernel for some SBC and I hit that downgrade. I just asked some things about `make menuconfig` items. I suppose it just flags everything related to linux kernel as cyber attacks.
You can build application outside of container, but run it in container. I think that it is simpler workflow, than everything in container (when you actually need to develop it with IDE).
I didn't try devcontainers stuff, TBH. But that's how I often develop my apps.
That said, there are other attack surfaces for that approach. For example I'm not sure if I can trust LSP server not to execute application code. So keeping everything in a container or in a VM seems to be the only sane approach to work with code you don't trust.
I'm on $200 plan which is supposedly 20x usage of $20 plan. With few Fable prompts (I'm working on u-boot port) I got 10% of my 5h usage, so that's already 2x of $20 plan usage and that would be 40% of $100 plan.
So Fable is just not usable for $20 plan and barely usable for $100 plan.
I don't live in USA. I'm getting paid around $2500/month and that's good salary for developers here, plenty of folks are getting below that number.
So this pricing is just completely outside of our economics and nobody I know would pay that, no company will justify spending $20k/month when they can hire 10 more developers instead.
It is very interesting unfolding of events. Can't wrap my head around it completely.
Sometimes I want to design a simpler C-like language and build toolchain for it from the scratch, with no historical baggage. Obviously optimization story will be very poor, gcc carries hundreds of super-qualified man-years of optimization work. But I wonder if it'll be that bad. Modern computers are fast.
But certainly with smarter AI I do believe it'll become more fluent with choosing more diverse idioms and phrasing, rather than repeating one thing over and over, to a point of being a comically similar. So people who learn on AI-generated text, will not learn from just one recurring style.