> people have hundreds and thousands on conversation on these apps that can't be easily moved elsewhere.
I just asked it to build me a searchable indexed downloaded version of all my conversations. One shot, one html page, everything exported (json files).
I’m sure I could ask Claude to import it. I don’t see the moat.
Ok so it worked correctly today, for you. How do we know it will continue to do so five years down the road when they are suffocating for cash? The more stuff we have there, the harder it becomes to verify their takeout will have everything.
I'm trying to motivate one or hopefully both of these ideas
- if it is worth backup up or exporting, it is worth doing it early and often
- but more importantly if we backing up and exporting, we should be continuously thinking are we even on the right platform? Does a better alternative exist?
How bad it is if put of 200+ conversations, a couple of those are not exported correctly? Not much honestly.
If I verify some of those and they are ok, I would see no reason to keep verifying all of them.
So far I've not seen anyone complain that their conversations have gone missing. There's a GDPR-style export option that I've used a few times for my own.
??? I’ve worked in this software game for over 20 years. I’m yet to experience this “no need to worry about the globe”. I think you have the fallacy of thinking local experience is general experience.
There is a very large amount of b2b software out there that is serving multi-nationals of all types. Perhaps it is surprising, but there’s a large number of software solutions that aren’t that big, but still have customers in all the 4 corners.
I think you would enjoy (and possibly have your mind blown) this series of videos by the “Rebel Mathematician” Prof Norman Wildburger. https://youtu.be/XoTeTHSQSMU
He constructs “true” complex numbers, generalises them over finite and unbounded fields, and demonstrates how they somewhat naturally arise from 2x2 matrices in linear algebra.
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.
Basically with Termius I "tunnel into" my host machine, and then I start a session with `claude` or `codex` or whatever and chat with one of those agents on my phone.
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.
“The strong do what they will. The weak suffer what they must.”
If you are in the US, pray that you are never weak.
reply