Cool to see principles behind this, although I think it’s definitely geared towards the consumer space. Shameless self plug, but related: we’re doing this for industrial assets/industrial data currently (www.sentineldevices.com), where the entire training, analysis and decision-making process happens on customer equipment. We don’t even have any servers they can send data to, our model is explicitly geared on everything happening on-device (so the network principle the article discussed I found really interesting). This is to support use cases in SCADA/industrial automation where you just can’t bring data to the outside world. There’s imo a huge customer base and set of use cases that are just casually ignored by data/AI companies because actually providing a service where the customer/user is is too hard, and they’d prefer to have the data come to them while keeping vendor lock-in. The funny part is, in discussions with customers we actually have to lean in and be very clear on “no this is local, there’s no external connectivity” piece, because they really don’t hear that anywhere and sometimes we have to walk them through it step by step to help them understand that everything is happening locally. It also tends to break the brains of software vendors. I hope local-first software starts taking hold more in the consumer space so we can see people start getting used to it in the industrial space.
Gonna throw in my hat and say that if you’re working on industrial applications (like energy or manufacturing) give us a holler at www.sentineldevices.com! Plug-and-play time series monitoring for industrial applications is exactly what we do.
Gonna throw in my hat here, time series anomaly detection for industrial machinery is the problem my startup is working on! Specifically we’re making it work offline-by-default (we integrate the AI with the equipment, and don’t send data to any third party servers - even ours) because we feel there’s a ton of customer opportunities that get left in the dust because they can’t be online. If you or someone you know is looking for a monitoring solution for industrial machinery, or are passionate about security-conscious industrial software (we also are developing a data historian) let’s talk! www.sentineldevices.com
We’ve finally managed to give our AI models existential dread, imposter syndrome and stress-driven personality quirks. The Singularity truly is here. Look on our works, ye Mighty, and despair!
‘"An ML engineer at Slack says they don’t use messages to train LLM models," Orosz wrote. "My response is that the current terms allow them to do so. I’ll believe this is the policy when it’s in the policy. A blog post is not the privacy policy: every serious company knows this."’
I really wish this advice was followed to the letter. I’m sick and tired of trying to read into policies on AI training (or AI anything these days) that is pure blog posts on how the service works and what the data protections are. Even from Microsoft no less! Even their “documentation” has a bad habit of referring to half-decisions alluded to in a blog post, saying this is how it works, just trust us, interpret this policy vaguely because we interpret it vaguely. None of the cloud vendors will just sit down with you and sign a contract saying what they will or will not do, they all default to as minimal responsibility as possible. And then they have the guts to jump in on regulation - there’s zero components of the current way these giants do business in AI that is amenable to regulation, at least not in a way that helps you unless you’re an uber-enterprise.
Sentinel Devices develops "zero-cloud" anomaly detection devices for industrial machinery. Our platform, OTAware, reduces the time users have to spend identifying and tracking down issues in their machines by analyzing machine signals and providing engineers with useful pointers on what's going on, as well as identifying signs of issues that would otherwise go unnoticed. Our unique approach is we do EVERYTHING, including data storage, ML training and decision-making, entirely on embedded devices - we never send data outside of the customer facility. This means that we are an instant buy-in for security-sensitive customers or customers with remote operations, such as defense or oil & gas.
I sympathize a lot with the headline statement; it boggles my mind on a lot of the data residency/integrity/confidentiality measures taken around massive data silos (as well as the infra teams companies bring to bear to manage, scale and then inevitably publish gospel articles on the web about) when companies could just opt… NOT to collect that data? I really like the model of “It stays on your device, we never see it. At most we get bare-minimum location statistics.” Although I question the assertion that their metrics system won’t be turned against them; seems obvious that anything programmed can be reprogrammed or updated, especially in the modern update-focused age. I don’t think they addressed that beyond a general statement that they took pains to assure that their users won’t ever be spied on. Would be interested in a technical article on that.
Side note, we at Sentinel Devices are taking exactly this “we don’t hold your data” approach for industrial machinery. Think automated AI pipelines that are air-gapped. And we’re hiring! If you’re interested, reach out to [email protected]
Since this is a topic that’s near and dear to my heart, going to quickly plug my own startup that’s doing exclusively this: www.sentineldevices.com. We make industrial equipment smart enough to self-monitor and self-report issues using AI, but we are specialized in making AI that does EVERYTHING (including training) on embedded devices (think something only marginally more powerful than an RPi 4) so we never call out to a server. As the article notes, a big challenge has been making the AI and all support software resilient and able to “bounce back” from random occurrences in industrial environments (which can be extremely unpredictable and unique). Also as the article notes, this pretty handily opens up the Defense market since we don’t need to clear a cloud component.
Feel free to reach out at [email protected] if you’d like to chat. We’re building and trying to take people on part-time if anyone’s interested in this space! Also if anyone just wants to talk about challenges in the space I’m happy to, HN usually gives really great conversation partners.
Sorry, but this is untrue; action potentials in neurons have extremely complex interplay with each other, including residual “soft” periods and chemically-induced changes in how they fire. Neurons don’t just “fire” or “not fire”, they adaptively change the strength of their firing constantly, unpredictably and continuously.
We use machine learning to monitor industrial equipment for signs of faults or failures, and identify in real-time which signals are relevant to the failure/which ones a technician should look at first. The problem we're solving is that when a machine fails unexpectedly, 60% or more of a technician's time is spent just figuring out what was going on and what, specifically, went wrong. We want to cut that time by half or more by having our device be an engineer-in-a-box monitoring the equipment 24/7/365. We're also unique in that we're "zero-cloud" - we do all data collection, storage & processing (yes, even the AI training - not just inference) on-device, on a COTS hardware platform that fits in your hand. The idea is to be truly plug-and-play without having to figure out network infrastructure, and cybersecurity, and data storage costs, etc. etc. Demo video here: https://www.youtube.com/watch?v=FhtLS3UfnPU&feature=youtu.be
We're always interested in pilots; our website is admittedly fairly stealth mode, but if you know someone that works at a factory, they can reach out to [email protected]
Hey, I’m a big fan of what you’ve been doing since I stumbled upon it in 2021. Do you have an estimated timeline on when you guys will have that web-app API available, even as a beta? Incorporating a web app with the same ease textualize can be implemented with (or even getting a web app with cross-compatible TUI as a fallback) would be super attractive for the product I’m currently working on.
I guess I’ll take the opportunity to throw in my hat… I’m currently running a very early-stage startup trying to address some of the brain drain and complexity in industrial maintenance. If you’d like to talk/rant about your job and the pain points you have, I’d be all ears! Wouldn’t be a sales call, I’m just trying to talk to people at this point. Feel free to DM me if interested.
I'll take this opportunity to plug my own question to the folks on HN - does anybody know how much protection an LLC generally provides you w.r.t. lawsuits and such? I'm currently looking at doing software consulting for a startup, but indemnification clauses have been touchy for the people I've talked to (and I'm paranoid about losing more than I gain in an unfortunate situation). My lawyer has told me that "piercing the corporate veil" is difficult and an LLC should protect me relatively well, but a good friend told me that I should basically always limit my liability to the amount I've been paid as in his opinion the LLC would be of questionable utility. I know HN isn't the place for legal advice, just wondering if anyone has friendly opinions.
I tried googling this, but the SEO spam is so bad I always converge to the same damn sites. Maybe google search for legal layperson questions is the next big thing?
Just curious where you heard Kevin Fu speak about this? I heard about the PowerGuard a while ago but never heard what became of it. If he has talks about the failures they encountered I'd love to hear them, because it's a really cool concept.
I agree with your objective, however it's obvious why Microsoft didn't do this: they wouldn't have been able to make good on their billion-dollar investment in OpenAI/GPT-3, which they REALLY want to justify.
“Those darn Chinese! They’re also launching their projectiles at 45 degree angles! They’re obviously copying the techniques we invented when the laws of physics first came into being!”
On the one hand, I know this is a sentiment that I’ve seen echoed amongst some of my colleagues. Simulation codes just don’t FIT, sometimes, into the neat little box that these mature hardware coprocessors try to put them in. It’s easy enough for ad revenue peeps to adjust their data and models to a new architecture, since the only will they’re obeying is their own and the computational reality is more-or-less whatever they want it to be. With simulations a lot of these assumptions go out the door, because now you can’t just disobey fundamental laws when convenient. If you need to go through a calculation on a single core because you have to evaluate every state sequentially, sometimes that’s all that can be done.
On the other hand, this article seems to be subtly beating the hardware co-design drum, which in my opinion isn’t always a good idea either. One argument could be made that limiting ourselves to one computational approach actually encourages creativity because it encourages some bright young researcher to come up with a new way of looking at things to make the software better fit the hardware. An argument could also be made that co-design is sometimes a bad idea because it might result in things being shoehorned in when they have no place. I’m certainly guilty of experimenting with FPGA implementations which, at the end of the day took so long to compile they would never be useful.
As in all things, I think in this case both “sides” have a little something to offer.