prennert
For example, where does the VPN connect to? The vendor? Do you trust the vendor more than the internet. Sure. Do you trust the vendor, that does not manage the firmware of their devices and uses inbound connections in the first place, enough to put them on a VPN?
How many devices and vendors do you have? How many VPNs can you establish with the existing networking hardware, and how many can you manage without IP clashes etc. IP clashes work both ways, btw. The vendor has to manage this themselves also if all their clients want VPNs.
Retailers are enterprises with 100s of vendors that run on a shoestring. On top, they use a lot of legacy architecture and hardware. They have teams that have a hard time making an architectural decision in the best of times, but even less so under stress. It is probably the same on the vendors side.
In my mind, the correct solution is indeed to deny any inbound connection to the network, now, to prevent further damage.
Incident response is, in order:
1. preparation (failed)
2. identification (done)
3. containment <--- we are here (take offline, put manual rota in place to manage fridge defrost cycles)
4. eradication (VPN, etc)
5. recovery (take it back online, relieve manual rota)
6. postmortem etcSo even with 0 access ACLs for node-to-node communication, nodes can advertise themselves to the control plane and change their config as the ACLs are updated.
Apparently agents will collude to break out of their individual sandboxes by delegating tasks to other agents that have the required permissions. This is a problem with agent fleets, because you need them to coordinate on their tasks. So you need to them to communicate.
A naive approach to prevent agents from doing something you dont want to do is a separation of powers, which individual permissions limited to each agents task. Say one agent to find and extract raw data, one to process it and write a report and one to publish it. If one of the agent decides that needs to publish the raw data, then chances are that they will collude to make that happen, even though no single agent has the permissions to achieve that goal.
OpenShell tries to fix this by monitoring the collective permissions set of the agent fleet, and by maintaining very granular permissions for each agent.
This was presented together with Sentry, which is something like a on-chip hardware firewall (BlueField) that sits between the chip agent run-time runs on, and the host. This improves safety by removing the ability of agents to modify their own OpenShell policies.
In this case the question is, if US Army freezers were hacked earlier, why did nobody brief other operators of cooling equipment. Its a failure at the top! Everyone is getting flustered and knives are out.
But maybe they could not fix the underlying software or whatever and were not ready to share details without opening themselves up to more attacks. Also there are a lot of attacks happening all the time, which ones do you share?
If the psychological pressure at the top increases, more mistakes will be made. Sometimes mistakes can be subtle over or under reactions, sometimes the mistake is not to do anything. It is real effort to evaluate an appropriate response. For example, the military could reach out to commercial operators quicker, but then they have to handle all the comms, questions, and they also potentially leak more attack vectors. The commercials also start having this overhead of having to read emails from the military and internally those orgs have to deal with that overhead in comms to evaluate the seriousness.
This is a problem, because very few orgs have spare capacity for this stuff and so they have a choice. They can react to the military comms and risk mistakes somewhere else due to comms / management bottlenecks, or vice versa. There are only bad choices. And every time this happens, another choice has to be made.
Lots of these will be low-level attacks with manageable impact, which lowers the alertness over time, until that moment when something serious happens. If at point everyone is exhausted a real costly mistake will happen. Its the long game.
In this case, I am sure a consideration was that the attack was already used against high-profile cases and it makes sense to just use the attack vector more broadly before it gets closed.
A short outage can snowball very easily in a lot of lost time. What I learned when working with enterprises is that above all they value reliability. This is for a reason.
A short outage might at best trigger loads of paperwork for multiple hierarchies, big meetings etc. The org has no choice. It needs to evaluate if whatever happens is a threat to their business.
In the worst case it is that, plus missing some crucial windows of delivery. This is because a system that is unavailable for a short time can cause backlogs that, like traffic jams, cascade as everyone has to slow down and then synchronously speed up again.
Orgs have the option to create more resilience, but that is overhead similar to compliance. You need to drill all your backup plans all the time, otherwise they are worthless. The drills cost time and money. At scale it is infeasible to be robust to all failures. Therefore, enterprises (at least) often prefer reliable systems over sophisticated systems. Because this delegates the risk management to the vendors rather than adding an overhead to every employee. Because at some point the employee would just do drills all the time instead of work.
It is unacceptable that enterprise plans get impacted by traffic on free and public repos. Our repos are neither on the free plan nor are they open. We have not had more AI stuff happening in the last weeks. Our traffic is stable. I would wager that most enterprises did not spike the traffic all of the sudden. Even if they were, we are paying for our quotas. Still our Github actions were breaking and our PRs not viewable at some times.
I am hoping this instability is going to cause a Cambrian explosion of forges and if that is happening, Github will be the first victim of the AI revolution.
I am working on a truly decentralized / local first code review right now, and a big part of my motivation for this is how bad Github has become. I dont know if I have enough time to build CI as well, but I am hoping others do. Otherwise I will just fall back onto Jenkins.
You will be surprised how many things you could not fix in Airtable or where awkward workarounds can be solved much more elegantly if you (or Claude) consider them straight in the design phase. Just make sure to start with your objectives and _maaaybe_ desired workflows to avoid biasing Claude too much and that you end up rebuilding Airtable.
There is a very narrow window in spring during which the ascent is possible, due to weather (enough ice to get over some sections, but weather not leathal). If you go too early you freeze or get blown off in 0 visibility, if you go too late, the ice has thawed too much and you get washed off in the rapids.
Sometimes the window is only something like 10 days during which you (and everyone else) have to ascent and descent from basecamp.
Your Scotland map shows towns without rail (although some had rail previously, like Callander, Aberfeldy), it prefers insignificant (population-wise) places while ignoring the larger cities next to it (Scone instead of Perth, Bannockburn instead of Stirling, Inverness is missing, Dundee is missing, Aberdeen is missing). All these places are drawn on the map, but not labelled.
All this clearly shows to me how bad it is. Yes it makes it look pretty, but given your task, I would have expected to give you meaningful map labelling.
Something basic like this would get you a long way:
0. cluster population centers into commonly known cities (i.e. show London instead of Islington or Walhamstrow)
1. display names of the top 10 population centers in the UK
2. display towns with stations (if crowded prioritize termination points and junctions, and prioritize larger places over smaller places)
Like this one: https://www.fuelinsight.co.uk/stations/7fd603ba12430695595b2...
I wonder if your API queries get capped / paginated or if those stations really do not report any changes for so long. It would be interesting to know if there is a pattern with those low frequency updates.
Draw your free-hand shape in Inkscape, export to SVG, import it in FreeCAD and go from there.
I used that trick to trace a part from an image and it worked surprisingly well. Not very efficient compared to commercial tooling, but despite the clumsiness its fairly intuitive and free.
I think this exactly how the US administration _feels_. Alexandr Dugin proposed spheres of influence. Russia starts acting on those. China is getting more powerful. Its now or never.
If you are interested in the geology of Scotland, there are excellent books available, including "Land of Mountain and Flood: The Geology and Landforms of Scotland". I am sure good books about the Appalachians and the Atlas are available, too.
At the time everyone seems to default to using C instead. But Fortran is so much easier! It even has slicing notations for arrays and the code looked so much like Numpy as you say.
Even in the 90s most people got book summaries to get through the curriculums. I would say, the highest performing language students and teachers pets at school did exactly that.
School unfortunately is largely about reciting of the teachers knowledge, so there is no need to read the source and think for yourself.
I am now much faster typing with the speech-to-text feature. Maybe that is what they are pushing. Maybe Apple wants to remove the keyboard and it is slowly increasing the friction so people use it less and less? Similarly how Chrome degrades browser performance until it gets restarted to force an update.
[0]: https://www.bmi.bund.de/SharedDocs/gesetzgebungsverfahren/DE...
Obviously a cool side-project. but I dont understand why anyone would want automate CV generation for "production use".
CVs are personal, and get updated once a year or so. Each life is different, each CV is different. So it does not easily scale across people.
As someone who is reviewing CVs, I review CVs from two aspects:
1. does the person have the skills I need, and 2. can the person communicate and do they have professional pride
Its much easier to get 1 & 2 across if you craft your CV. Think about what message you want to get across and work very hard to get that message across on one page. Expand with more detail in pages 2 and following.
As a hiring manager I am filtering roughly in this order:
1. has core skills I need, if yes, then 2. has used core skills I need in enough projects to likely meet our bar, if yes, then 3. are the relevant projects close enough to what we are building?
Later in the interview process, interviewers will look at the CV more closely to prepare for the interview.
Anyway, if anything I would only start with automating from page 2 and beyond.
Are those ~400-800 kg of aluminum oxide in cosmic dust each day uniformly distributed, and if not how big are those clouds of aluminum oxide that the earth is travelling through? Those 30kg from the satellites are going to be extremely concentrated and therefore take longer to "soak up".
Right now AI is good as a manager, it can identify issues and propose solutions, but it struggles to actually implement them reliably. This is even the case with code today, despite the vast datasets, documentation, compilers, etc.
This problem becomes harder the more the unconstrained physical world is involved, in particular in slow moving legacy environments that have not been designed for AI / robots. Prime examples are physical infrastructure, and housing stock and the associated trades that maintain and upgrade those.
There might be some inspiration in there to guide the story towards breaking some of the chicken and egg problems. Maybe the Romans find a way (and reason) to exploit the English coal deposits and start encountering the same problems the English did eventually: how to pump water out of shafts.