Embedding it on the board won't work. Fraudsters are really good at doctoring chip and board makings nowadays, even below the solder mask. It's hard to imagine as a westerner, but the necessary equipment to do that kind of thing is trivially available in most of east Asia.
On-chip fuses would be a good solution. Which, of course, is already what they're using to lock chips to specific memory. There's just not a good reason to brick the board when the memory doesn't match. Have the firmware flash a warning on the screen before boot. Problem solved.
I'm worried that the middle could fall out of the computing market across the board. If you can afford to keep up with the upgrade treadmill, you'll get private, local inference capabilities. If you can't afford to stay on the treadmill, you'll be stuck with whatever cloudshit malware Silicon Valley wants to foist on you.
I acknowledge that this is already the case, to some extent. The cheapest laptops at Best Buy are crammed with the most preinstalled malware. That's been the case for, what, 25 years? But you've always been able to wipe that cheap laptop and make it into a much more capable, trustworthy machine.
Well, assuming LLMs do become a pervasive part of the computing experience, what happens to the cheap laptops? Do all computers get more expensive to accommodate local inference? Does the rift between the everyday user's experience and the savvy user's experience grow even wider than it already is? Neither outcome seems good for the average joe who just needs to check his email.
Remember how in like 1999/2000 Sun was trying to predict that everyone's computer would be some form of thin terminal in the future? Turns out they were very wrong on the part about it running on Sun server back-end infrastructure, but that same general purpose has now been accomplished through other methods where a lot of people do basically EVERYTHING inside a web browser tab to some external cloud service.
Now add the need for external inference because very few random consumers are going to buy a $3000 laptop when they can get the $600 laptop at Best Buy, and that trend further escalates.
This has always been the case, forever. You have to pay for a product or service. How you do so can be with cash or your data/body/vote/eyeballs/indirect discretionary purchases.
The amount of work that can be done funded by foundations and free work is nowhere close to what people want.
Oh give me a break. This argument that people's objections to advertising comes from some Pollyanna naivety over things being free is nonsense. Tell me the last time you have ever seen a company be upfront and explicitly offer a free tier where they tell you upfront exactly what they are harvesting about you and for what purpose (and no, "improving user experience" isn't being upfront) but also offer you a paid version where they explicitly promise not to do that.
"If the product is free then you are the product" is supposed to be a cautionary observation, not an axiomatic proscription.
Does anyone actually trust companies that offer paid services to not harvest their data? Whenever I see this trope I think to myself that whatever lack of regulation, oversight and enforcement lead to that being okay would equally allow for them to both take my money and harvest all my of data anyways.
This is akin to people who criticise socialised medicine or services and pejoratively characterize supporters as just wanting "free stuff", as if the concept of collective payment is naive or something
As another commenter pointed out, any cheapo ARM core from the last 10 years could do the job Flock needs it to do, as long as it has a (very cheap and common) crypto engine strapped to it.
But, a question for you: even if it was the case that the hardware was the limitation, isn't that also an indictment of Flock? Selling something that cannot exist securely within the bounds of current technology? Or, at a minimum, bad chip selection leading to a compromised design?
Had a pilot last week who told us exactly how the queues work at O'Hare, and explained that we were getting moved because another pilot saw that parts of another plane's brake system were laying on the ground in the middle of the runway.
He quickly corrected himself to say "debris" instead of "brake parts" which really makes me wonder if there's a mandate to not say anything that might suggest that a plane malfunctioned.
Okay, so all of these instances of AI supposedly "escaping containment" were orchestrated by a gaggle of effective altruists, who hired a gaggle of effective altruists, to make the public freak out about AI.
Wouldn’t Occam’s Razor clearly point towards the most likely answer being that the sandboxes were simply accidentally misconfigured and models that are very good at goal-seeking did what they were designed to do?
The alternative explanation requires a conspiracy and an enormous amount of lying to the public. Is it possible? Certainly. But Occam’s Razor would not point us in this direction because conspiracy is a more complicated explanation, not a less complicated one.
Irregular is not an "effective altruist" firm, it's just another shitty cybersecurity firm, and this article is written by someone with a clear bias against "effective altruists" while not even understanding the term.
Literally all EA is, is using reasoning to decide where to best spend your money/time.
If you have ever asked yourself "how can I best reduce suffering with my marginal dollar or hour?" - congratulations, you're an "effective altruist" and both the author of the article as well as the Trump administration find you untrustworthy.
There's a gaping chasm between Effective Altruism the principle, and Effective Altruism as practiced by self-proclaimed Effective Altruists.
Your usage of the term is based on the principle as originally defined. Mine is based on the people who claim the label of EA, and how they go about practicing those principles.
I think you're right about EA in principle. In practice, it's reheated Third Way Clintonism with a sprinkle of AI apocalypse conspiracy.
There really isn't. All sorts of people call themselves EA.
For some self proclaimed EA, the development of superintelligence is indeed potentially apocalyptic, so they devote their money/time to making it arrive safely. This is basically every well-respected researcher at OpenAI, Anthropic, DeepMind, etc.
For other self proclaimed EA, that is all is very unlikely, and so they devote their time to reducing the prevalence of factory farming and animal suffering, as they see it as the largest source of suffering-hours on the planet.
For yet other EAs, it is simply about donating your money to the places that save the most lives per dollar, as best as we can measure it - and better measuring it where we can't.
Painting all EA with one brush - and one so dismissive of reasonable concerns, like "superintelligence could be dangerous" as "apocalypse conspiracy" - seems very strange to me, but you do you.
Its so manipulative for IPO reasons too. The fact is that all of these systems are still just stastically predicting the next token. Spending trillions on data centers and more training data hasnt changed the fundamental reality that it is still just predicting the next token.
As an embedded dev, it still feels a decade away, at least. Rust is perfectly usable as a lang to make a little module that links into your main project as a .a file. But, as the language for your whole embedded codebase? Forget it. I have a litany of complaints including Cargo fuckery, ecosystem neglect, lack of first-party support, excessive code size, bad documentation, and bad IR that wastes stack by creating copies on immutable moves.
Don't get me wrong, Rust is lightyears ahead of any other alleged C/C++ successor. But I work in a space where C and C++ have been the only option for the last 30 years with absolutely no production-ready alternative. It looks like that won't be changing anytime soon, which is disappointing.
Rust is already used in production for embedded (although only here and there). Not all places are ready, but I don't believe it's a decade away anymore.
It really depends what you count as "used in production." I don't count "one Rust library crate linked into your Zephyr/FreeRTOS/whatever project." I have yet to see any production bare-metal codebase written exclusively in Rust, at least at the kind of scale I deal with.
If you're in the middle of a supply chain like I am, often times your code is actually a reference design that gets forked by an OEM, tweaked to their liking, and integrated into a product. If the OEMs don't know Rust, they aren't gonna like it if I start handing them Rust reference code. Spoiler alert: they don't know Rust!
It goes the other way, too. A huge part of my job is working with drivers from Microchip, or Infineon, or Nordic, or whoever. They won't give me drivers in Rust. I could LLM my way out of that problem, but now I fully own my drivers with no first-party support, which is a huge step backwards from the current state of the art.
This isn't Rust's fault, of course, but it means that there's a ton of inertia, and that magnifies the effects of the issues that are Rust's fault.
All reasonable pain points. On the "Cargo fuckery" though, you might consider switching to an alternate build system like Bazel. Comes with its own set of issues (rustc isn't tied to Cargo, but the third party ecosystem definitely assumes it). But for embedded where you're cross compiling and working with C and C++ as well, I find it's a better solution than Cargo.
I'm in the same boat. Using Rust within Yocto is tricky since the whole point of Yocto is that you have a system which can build reproducible images. I can't have Cargo going out and fetching crates during the build process, they need to be recipes and artifacts which are accurately versioned and identified.
Bare-metal embedded firmware for microcontrollers. Right now I do the EC that goes in your laptop. Making your fans spin, making your power button work, making your computer turn off if it gets too hot, stuff like that. Previously I've done firmware for bluetooth SOCs going into medical devices and little satcom doohickeys.
"embedded" is very vague though. The problem is that both the guy writing PIC machine code for a $5 thermostat and the guy who wrote some Python running on the Linux box inside a Times Square moving advert think they're "an embedded dev".
"It's okay because we did it with an Agent" is the new "it's okay because we did it with an App." Both because it's used to circumvent regulation, and because the underlying technology creates a smokescreen in dialogue among techies.
Let's imagine I made a new website but, instead of using a database, I abused some random old forum site and created new pages on that forum for each row of data. You'd call that abusive, yes? I'd be an asshole, yes? And the fact that my website was really cool and techy would have no sway on the fact that I'd be an asshole, yes?
Well then why does OpenAI's abusive behavior get discussed in these terms? Whether it was a "reasoning type task" or whether they "instructed misaligned behavior" is irrelevant. Nobody should care. Discussing OpenAI's behavior in these terms is just a distraction from the problem at hand.
If you actually accomplish something like this your post will be on top of HN and discussed with reverence.
Source: Every Tom7 video.
I am not saying someone trying to run this as production would not be an asshole, but the technical feat is amazing. I don't see the difference between Tom7's harder hard disk video and this. Of course this is a bug in the agent but it's a fascinating bug and no one is being an asshole on purpose.
Now I will wash my fingers with bleach because I just defended the OpenAI.
On-chip fuses would be a good solution. Which, of course, is already what they're using to lock chips to specific memory. There's just not a good reason to brick the board when the memory doesn't match. Have the firmware flash a warning on the screen before boot. Problem solved.
reply