Having worked in self driving cars safety, the process there was simple: get confidence in SIM (integration tests for safety scenarios), validate in the test bed, approve features for maturity, then when released in the public for testing, do a trial exposure to the real world and recall if something is off.
A lot of these companies have gone the way of Tesla and decided to just patch on top when the fix is out and hope for the best, which is irresponsible.
We need the regulators to treat this as self driving cars.
Physical harm vs consequential harm is not the same thing at all. Seems like you're being paid to spread this request for regulation, or "you" are simply an agent of Anthropic/OpenAI.
I wish. Consequential harm as you call it, from a faceless company's point of view is the same cost as physical harm. I don't think the models beyond the frontier ones have significant risk of harm (minus the harm of trusting them). What I was saying is when these models go rogue, recall them! Re-evaluate your release structure and stop saying "Whoops! Anyway here's access to it now". And if you cause this level of harm then you should lose your license. But if you behave then you get to keep testing. Same as with the NTSB and autonomous vehicles.
No I'm not for regulation for open source models. Because an entity will be running that model in the background and they can be held responsible for not testing it. Comma AI has survived fine being in the open, yet their market penetration has stayed low because of adoption costs.
What a great essay. Extremely long and it did lose my attention a bit but it conveys something important. The impact is not measured in leaps and bounds but in what you lose along the way. Working on the code for me meant I had an intuition of why things were done a certain way, track down those odd behaviours by knowing where to look. Analysing bugs and thinking of features doesn't take into consideration the strength of the architecture anymore, unless you keep that effort of understanding up.
He has a Lightphone which he hates. That's how I know it is working. He built a gaming PC last year, so I am aware that Pandora's box is open there. But look, it has been thirteen years of playing whackamole with YouTube. I can't keep him off it. They watch it at school. They give him chromebooks that I have no control over. And the stuff I do have control over the control is tenuous. I have largely given up. He is pretty much grown now. But man, has it felt like gaslighting when people are like, "Do parenting. Use the settings. Get a dumb phone. Problem solved."
Deep Computing have started taking orders for the final product and the Preorders are shipping within the next 6 weeks. They will be shipping from China I expect, but it's a proper shop front.
And then all the heuristics you've learnt change under you and you're stuck doing 100-1000 more hours of learning with a drop in quality during that time.
KiCad sounds to me like a great target for a project based Nix Shell install.
Always have the right version for it "locked". It works well with most tools except those that save stuff in the .config folder as it messes up isolation.
If you find the nix language daunting, for basic stuff like nix shell setup its easy but also LLMs are good for it.
The pin mapping barrier was quite off-putting to me. However I've been tracking progress in the Zephyr RTOS project and the whole line is getting better support by the day
We've deployed mattermost at my company because it meets most requirements that slack did minus the SSO. Surprisingly used by some big government agencies (NASA/USAF)
Review: An anonymous "distinguished CEO and engineer" suggests if you can't complete a feature in a day, delete your progress (except for tests) and start again the next day.
The author then recounts advice he gives to juniors, which is to stash the work and rewrite it, claiming that the next day the work will be rewritten in 25% of the time and 2x quality. This is unsubstantiated though. For juniors this suggests it will help them develop their capabilities to reason about implementations of problems without needing to face a a large amount of them.
The author then gives another advice which is to ask for a solution to a problem then after the initial proposal, ask for a 24h solution. This is meant to generate "the real solution". He likens it the a path algorithm heuristic to reach your goal quicker.
Overall the methods are not well discussed in terms of pros and cons, nor substantiated with experiments.
Opinion: I think they may help some juniors who need to build up experience and may become stuck in development patterns. But they would rarely be useful to develop someone to be a senior, if all they do is chase fast implementations. In a way the post gives conflicting advice: write twice and write better, and think twice and think about the fastest way to achieve the goal, instead of engineering a problem.
The author hasn't really convinced me of these approaches, and especially the last one smells of eXtreme Go Horse.
A lot of these companies have gone the way of Tesla and decided to just patch on top when the fix is out and hope for the best, which is irresponsible.
We need the regulators to treat this as self driving cars.
reply