Generally the claude jargon is valid jargon I’ve seen real people use, it just uses jargon so much more often than a human would. And because it has particular jargon it likes, and claude is widely used, you see so much of that particular jargon that you get sick of it.
It’s like having one coworker with a very particular writing style which is mildly annoying, but then it suddenly feels like half the internet was written by that one person and it becomes a lot more annoying.
I think by "dangerous" they include things like "makes an edit to a config file outside the current project", not just "wipes the production database". So "dangerous" commands just means things we should ask the user for confirmation, not commands which definitely cause irreversible damage.
Even if that's what they mean it would still be disturbing if commands that should have explicit user confirmation were being waved through - whether by users or the auto mode - and being run when they shouldn't. The statistics appear to suggest that this is not only possible but actually quite likely given the number of commands an agent running all day might propose to run. But if that failure mode is a possibility at all then IMHO the whole system is playing with fire.
I changed from cursor to claude code a couple of weeks ago and this is the biggest difference I've noticed. cursor very rarely had to ask for permission for a command because it almost always used builtin find/read/edit tools. Whereas claude code makes extensive use of unix tools with mysterious flags which are basically impossible to whitelist and pretty impractical to manually review.
Overall claude code seems better at "just get things done" if you blindly trust it, but cursor was much better at keeping the human in the loop.
sed can be used to edit files (with the -i option). Not sure how this interacts with piping to its STDIN, but I wouldn't automatically assume `grep | sed` is safe.
I was thinking about this the other day, standard UNIX utilities seem poorly suited for this because they have so many weird options/flags with "unsafe" side effects. I have no idea if grep, for example, has some niche option to make it write/edit/delete files, so I wouldn't be comfortable blanket whitelisting it.
Even for extended workloads, a Pi 5 without a heatsink is still a hell of a lot faster than a Pi 4. And as sibling says, most users appreciate bursty speed while not doing prelonged compute (see also fanless laptops).
(Disclaimer, I work for raspberry pi ltd, not views of employer etc.)
Not unlike Buckethead, they seemed to prefer avoiding the direct spotlight of fame, but they still wanted to create these things and put their thoughts, feeling, and original aesthetic out there in the world.
...all of which is to say "except for the AI part" is a pretty big exception.
I had that style of integrated panels installed on my (Victorian) house in the UK. The slates were old and crumbling so needed replacing and doing integrated panels meant only needing a fraction as much slate which saved a chunk of money. I think the result also looks a lot better than non-integrated panels, at least with slate roofs (which are common in my area)
Apparently integrated panels can be a little less efficient in hot weather as they don't get cooled by airflow under the panels and are less efficient when hotter. But it's a pretty minor effect, maybe a few percent of output. Seems like the best option on a new-build or if you're re-roofing anyway.
To look at it another way, just because some code I work on at my job is derived from open source MIT-licensed code doesn't mean I personally have the right to distribute it if my company doesn't want me to. I'd guess this comes under some generic "confidential information" clause in the employment contract.
Hmm your example is different: if you manually write code, there is a copyright for it whether it is derived from an MIT-licence or not. If you don't own that copyright (because your employer does), then you don't have the right to distribute it because it is not your code.
If you generate the same code with AI, now it does not have a copyright. If it depends on an MIT library, then the MIT library has a copyright and you have to honour the licence. But the code you produced does not have a copyright (because it was generated by an AI). And therefore nobody "owns" it. My question is: can your employer prevent you from distributing something they don't own?
This is a very long-standing and AFAIK never explicitly decided copyright and human rights question: If something is Public Domain, are contracts restricting distribution valid? Is our right to information or knowledge a fundamental human right that is not permissible to take from others, such that restrictions greater than those imposed directly by the State are invalid? In a healthy society, "I have created an extraction machine and your actions are hindering my extraction" is not a valid argument. So at the very least contracts restricting rights to public dmoain works should be allowed only with heavy restrictions as to when, how, and for how long they are binding - much like the legality of non-competes have has steadily reduced in many places in recent years.
CC0 came about in part because of this ambiguity. To deal with it, part of CC0 basically says - even if there would still be restrictions to this if it were only in the public domain, I renounce those theoretical rights.
Outside the underdeveloped legal framework, I believe knowledge and truth is like life, and human society has some continued philosophical growth required here.
It'll be the same as larger inverters for roof-top solar - they are constantly monitoring the mains cycle and will shut off if the voltage (or probably frequency too?) goes out of range, let alone drops out entirely. The relevant standards in the UK are G98/G99.
It’s like having one coworker with a very particular writing style which is mildly annoying, but then it suddenly feels like half the internet was written by that one person and it becomes a lot more annoying.