I was a 90’s hacker (teenager in the early 90’s deep into “hacking”). “Hackers” was clearly a movie for teenagers and released in the 90s, so it stands to reason that it captured some of that cultural moment. I did love it.
However, Sneakers was also released at around the same time, and that really captured my imagination and had a real lasting impact on my life. Hackers was fun, but Sneakers was aspirational.
> 8 minutes to kick off the next chunk of my one-person project development via my phone, review the results, then kick off the next chunk of development.
claude can deploy to github spaces and modify code for deployment to those by commits and pull requests to the repo exclusively
claude via browser and claude mobile apps function this way
but alongside that, people do make tunnels to their personal computer and setup ways to be notified on their phone, or to get the agent unstuck when it asks for a permission, from their phone
> And for a technology example, a database server disappearing might raise a single alarm, but the applications that rely on that database might raise countless alarms as attempts to connect fail over and over again.
Right. The lingo for this is “cascading alarms”, and there are various mechanisms to suppress consequential alarms if you design well. If an “upstream” alarm results in further alarms/events downstream; these should be suppressed (still recorded, just not alarms), until the root alarm cause is resolved.
I thought this was well understood in the industry, but perhaps not.
Having worked in this space for over a decade (but not in the last 7 years), your comments surprise me. Is this a smaller operation perhaps?
In general, operator UX (HMI, human machine interface), is a an area that’s well researched and more or less standardised in recent times (ISA101). Abnormal Situation Management (ASM), Situational Awareness, automatic alarm suppression for “consequential alarms”, High Performance Graphics (basically everything grey except the stuff that matters). If your Engineers do a good job; the operators can do a good job.
Removing all interlocks sounds like a bit of a cop-out to me. Interlocks are there to prevent the mis-click pouring molten steel on peoples heads. If you have a nice boring standardized ASM HMI, operators can’t “hide behind them”. Every operation is the same.
I’ve been diving down the BYOD rabbit hole recently. At enterprise scale it’s not “hook in with your vpn, job done”, it’s got to be managed. Remote wipe on exit, prove the security settings, disk encryption, EDR.
What this means for the user is your personal device is rather invasively managed. If you want Linux, your distro choice may be heavily restricted. What you can do with that personal device might be restricted (all the EDR monitoring), and you’ll probably take a performance and reliability hit. Not better than just a second laptop for most people.
> the "silo breaking" philosophy that looks at complex fields and says "well these should all just be lumped together as one thing, the important stuff is simple,
I don’t think this is the right take. “Silo’s” is an ill-defined term, but let’s look at a couple of the negative aspects. “Lack of communication”, and “Lack of shared understanding” (or different models of the world). I’m going to use a different industry example, as I think it helps think about the problem more abstractly.
In the world of biomedical engineering, the types of products you are making require the expertise of two very different groups of people. Engineers and Doctors. A member of either of these groups have an in-group language, and there is an inherent power differential between them. Doctors are more “important” than engineers. But to get anything made, you need the expertise of both.
One way to handle this is to keep the engineers and doctors separate and to communicate primarily via documents. The doctor will attempt to detail exactly how a certain component should work. The engineer will attempt to detail the constraints and request clarifications.
The problem with this approach is that the engineer cannot speak “doctorese” nor can the doctor speak “engineerese”; and the consequence is a model in each person’s head that differs significantly from the other. There is no shared model; and the real world product suffers as a result.
The alternative is to attempt to “break the silos”; force the engineers and doctors to sit with each other, learn each other’s language, and build a shared mental model of what is being created. This creates a far better product; one that is much closer to the “physical reality” it must inhabit.
The same is true across all kinds of business groups. If different groups of people are required to collaborate, in order to do something, those people are well served by learning each other’s languages and building a shared mental model. That’s what breaking silos is about. It is not “everyone is the same”, it’s “breaking down the communication barriers”.
I don't think that's like DevOps, though. A closer analogy would be a business that only hired EngDocs, doctors who had to be accredited engineers as well as vascular surgeons.
I don't think anyone thinks siloes are themselves a good thing, but they might be a necessary consequence of having specialists. Shift-left is mostly designed to reduce conversations between groups, by having individuals straddle across tasks. It's actually kind of anti-collaboration, or at least pessimistic that collaboration can happen
Oh, I completely agree! We created “EngDocs”, as you say, and simply made the situation worse. An EngDoc is an obviously ludicrous concept, on its face. But by breaking down the silo in the biomedical example, each engineer becomes a bit knowledgeable about an aspect of medicine and each doctor gains some knowledge about aspects of engineering.
I am arguing that all such people, whether developers or ops or ux designers or product managers; need to engage in this learning as they collaborate. This doesn’t mean that we want the DevPM as a resultant title, just that Siloing these different groups will lead to perverse outcomes.
Dev and ops have been traditionally siloed. DevOps was a silly attempt to address it.
What an interesting talk, and an interesting concept also. Open source hardware security; get the security researchers interested and fix the security defects.
The “read the data out with a super expensive microscope” remained. Is there any way to defeat that attack I wonder? I suppose the hsm model of “destructive tamper detection” is one way.
I patented something that had a countermeasure for this, which was a bit impractical but fun to think about. Basically you put the sensitive data in an eeprom layered with a chemical that emits UV when exposed to air or, optionally, visible light - chemically more entertaining, hard to manufacture. But it's a just an arms race at that point.
The current solution is obfuscation. They make the mapping from physical state to actual key complicated enough that you have to reverse engineer a lot of the logic.
You can also bury the fuse array inside the chip. So in addition to the microscope, you will also have to non-destructively etch or mill the chip to expose the fuses. This also renders the chip non-functional, so if the secret is unique per chip, then the leaked secret can't be used to bootstrap to other secrets on the die.
> The “read the data out with a super expensive microscope” remained. Is there any way to defeat that attack I wonder?
Get your chip made with the latest TSMC process and get features so small nobody else, even superpowers and trillion-dollar tech companies working together, can manipulate them :)
A good scanning electron microscope costs at most a few million? And is pretty common in a decently funded lab pretty much anywhere? Resolutions of 5nm is not uncommon. A scanning tunnelling microscope can go much lower (single atom types) and isn’t all that much more expensive either (comparatively I mean).
I think it’s common knowledge by now that the smallest feature in a 5nm chip isn’t really 5nm. So that’s not (yet?) a viable strategy.
Manipulating features smaller than what TSMC manufacture is possible in many places (just at great expense), TSMC's special sauce is being able to manufacture it in quantity and economically. Ultimately it's always going to be difficult to completely protect storage at rest, because it is possible to take something apart atom by atom, but it does raise the cost of the attack substantially.
What I mean is: on a normal laptop, when you scroll with two fingers on the scroll wheel, the distance you scroll is nearly a continuous function of how much you move your fingers; that is, if you only move your fingers a tiny bit, you will only scroll a few pixels or just one.
Most VM software (at least all of it that I've tried) doesn't properly emulate this. Instead, after you've moved your fingers some distance, it's translated to one discrete "tick" of a mouse scroll wheel, which causes the document to scroll a few lines.
The VM software I use is UTM, which is a frontend to QEMU or Apple Virtualization framework depending on which setting you pick when setting up the VM.
> another overlooked feature is that it now keeps track of its state and maintains all the unsaved files that are open in it, allowing me to use it as a momentary place to jot down things that I want to remember but that I don't want to save in a txt file.
There are plenty of apps that do exactly this. Sublime was the best of them that I know.
Notepad was great for the opposite reason. It is ephemeral. I can use it as a scratch pad for passwords and what not, with the comfortable knowledge that it’s all cleared away next reboot.
You can bring classic notepad back, it’s still there, so that’s what I do.
However, Sneakers was also released at around the same time, and that really captured my imagination and had a real lasting impact on my life. Hackers was fun, but Sneakers was aspirational.
reply