Oh man, I ported this to the TI-89 back in 7th grade and made it slightly more school appropriate calling it “pop wars”, trading soda from different machines at different schools instead of drugs.
It will sometimes do this for gitignored files to avoid reading secret tokens in env files for example. But for certain languages that rely on code generation this can be a pain.
Just to clarify, it's more about the ability to run a terminal on my Linux box and connect and disconnect to it from my Mac that I'm looking for. Wezterm does a good job of this. Previously I was using tmux and mosh and Nebula, and that worked really great for reconnecting (I almost never had to reconnect, it just stayed live, wezterm I need to reconnect all the time, but that works reliably). But copy-paste with tmux is meh.
They DoW doesn't care about laws, that's the whole point. Anthropic did not believe the most law breaking administration in history when their drunkard incompetent leader said "lol trust us bro"
I see it as trying to apply the bitter lesson to robotics. Specialized robots will always have their place, but humanoid ones can take advantage of all the design interfaces that already exist in the world for humans.
Similar to how claude code gained so much traction in terminal by just leveraging the command line interface that already exists for humans, no need to invent a domain specific MCP to just run shell commands.
I agree with you that it's far from the most efficient approach for specific tasks. But the analogy would be that you also generally don't want to use LLMs to do something you can "just" write a script for... that doesn't make LLMs useless though.
Both can be true. I have personally experienced both.
Some problems AI surprised me immensely with fast, elegant efficient solutions and problem solving. I've also experienced AI doing totally absurd things that ended up taking multiple times longer than if I did it manually. Sometimes in the same project.
> The fact that I can unlock and relock the bootloader is not a security issue or a risk. People who don't know what that means cannot possibly do it by mistake.
The second sentence is false. Lots of people blindly follow things and don't understand consequences until they brick their devices. Those who don’t break something won’t notice if they’ve silently backdoored themselves.
People asking for support after getting themselves into some weird hole they never should have been in because some friend or online article said so is super common.
> The second sentence is false. Lots of people blindly follow things and don't understand consequences until they brick their devices. Those who don’t break something won’t notice if they’ve silently backdoored themselves.
"Lots of people", how many though? Can that number be reduced? What number would be acceptable?
I feel like it _has_ to be possible to devise an unlocking procedure that dissuades most people from self-harm.
The problem is often treated as intractable, but intuitively this seems really unlikely to me. I don't think more than a tiny percentage of Xiaomi owners, for example, would go through the bootloader unlock process which often has a mandatory wait period attached to it without a reason more compelling than an impulse to randomly and blindly follow instructions on the internet.
I would like to see user studies with good methodology before other people decide to barter long-term freedoms away for insufficient benefit.
Why do I so rarely see people who are concerned about the security issues of bootloader unlocking calling for designing hassle and warning into the process. Instead, it's more common to hear that in the name of the average user, all escape hatches must be removed.
After a certain point, someone else's insistence on self-harm ceases to be a good excuse to infringe on my freedom. We don't ban hammers because some people accidentally damage their property/body, and it's a lot easier to do that with a hammer than an unlocked bootloader.
reply