You can even go a step further and run the container in a VM, such as with Docker Sandbox or the krun runtime in Podman.
There's also smolvm which is a nice minimal microvm manager based on libkrun: https://github.com/smol-machines/smolvm. I vibe coded a little shell utility for building and running OCI images for the Pi harness using it (easy enough to do manually, but the automation just makes it a couple quick commands rather than digging through documentation): https://github.com/neuroblaze/smol-pi
I have a similar setup using containerd/nerdctl and Kata Containers. Each OpenCode instance runs in its own little VM with mounted folders for context.
Yup, good call, I'll have to check those out. Not that urgent to me as I also happen to use colima for it's docker daemon interface. And, colima uses a full VM to host the containers, and you can further lock down the config to what is even allowed to vol mount so there's even another fs access restriction layer in play.
Not my field, but since they use SQUIDs I suspect most of the volume is taken up by cryo equipment. So, maybe if someone eventually discovers a room temperature superconductor.
Nobody is arguing that space isn't big. The argument is space is big but dynamic, and launching enough stuff up there means that over a sufficiently long time horizon, you will have a collision between uncontrolled objects. This is not a theoretical concern, it has already happened [1].
Collision risk is significantly reduced by having maneuverable spacecraft with good conjunction prediction systems in place. But fundamentally, nothing is perfect and accidents can and do happen - you set a maneuver threshold based on an expected collision probability, but it's an engineering tradeoff: "spend the fuel to maneuver out of the way of everything, no matter how remote, or accept a small collision risk?"
And of course, when you are launching thousands of satellites, you will have a few failures that will become unmaneuverable hazards. Just the way it goes, you can't realistically engineer your way to perfect reliability.
So sorry, I have to reject your claims that it's "utter bullshit." Space debris risk is a well studied field, so much so that satellite insurance companies are starting to fold those calculations into insurance premiums. So yeah, it's real, and it deserves more than a pithy dismissal.
Whatever happens to Starlink, the debris in their new lower orbit would decay within months at the worst. It’s not one of those “thousand years imprisoned on the planet by a cloud of deadly debris” that we’ve heard about.
Not saying it couldn’t be bad if there were such a collision as obvi a really bad collision could in the short term damage Starlink and anyone else who decides to use that orbit, but this isn’t existential risk territory anymore.
VLEO addresses the risk, sure, but the new Starcloud space datacenter hype machine isn't going VLEO, it's going 600-850 km. Those altitudes are in the years to decades range for deorbit, and SpaceX has filed for 88,000 of them.
Risk is theoretical, that is; a) never demostrated, b) most probably overblown c) any methods of mitigation were never even given a chance to develop.
All in all you people take the precautionary principle so far as to cripple your own progress in fundamental stuff like spaceflight but at the same time see no reason to apply it in social stuff like that survelliance camera affair or the net-id. And also fervently believe in modern version of snake oil that is "AI".
This is hypocrisy at the base level and a sign that we have a civilization crisis akin to one that of ~7th century AD.
Okay buddy, that was a Gish gallop if I've ever seen one.
The risk is real. The math isn't complicated, you could stand up a basic debris simulation in a few hours with numpy from first principles. And we also know it's real because it's actually happened multiple times now: https://en.wikipedia.org/wiki/Satellite_collision
This is a real thing that satellite operators worry about all the time. Conjunction analysis and risk modeling leading to a go/no-go decision is something that real satellite operations centres do daily.
I don't know if an LVT is the answer, but we do need to figure out some way to make operators consider space sustainability efforts, especially if they are launching systems with such density that they make subsequent operation in those shells significantly riskier.
That attitude is how you start building up more and more tech debt until you trap yourself into extinction. If I thought that Musk's effort could benefit from an infusion of cash I would have organized it. As it happens he's limited by other things, so I sit back and enjoy the view of our civilization slowly climbing the Kardashev scale. You can fly by.
>If I thought that Musk's effort could benefit from an infusion of cash I would have organized it
Uh huh.
>As it happens he's limited by other things
Being some kind of weird multicellular invasive species that looks human enough to get VC funding but isn't quite human enough to have a relationship with his kids. Also, rolling forward his failed/stalled business ventures into whatever is hot enough to be currently valuable. Busy man(thing)
>That attitude is how you start building up more and more tech debt until you trap yourself into extinction
I literally watched a video of Space X engineers demonstrating their space junk tracking tech, and talking about how seriously they take it. This seems like a you problem, the science and the people doing the work are already concerned. I don't see what you get out of being flippant about it.
>so I sit back and enjoy the view of our civilization slowly climbing the Kardashev scale.
Is that what plato's projecting on his cave wall these days?
And then he betrayed all of that when he decided to IPO SpaceX and pivoted to space datacenters. Putting aside all the other things he's done over the past few years to betray his own stated ideals or plans.
That satellite's orbit very clearly did decay, though. The problem in that instance is the descent wasn't controlled, but that's a different kind of failure than the one this thread is worried about (i.e. satellites lingering for many years without active collision avoidance).
Not at all, it can be handled via international treaty. Frequency allocations for civilian satellites are already handled this way, a UN body (the ITU Radiocommunication bureau in Geneva) acts as a neutral party that handles satellite spectrum coordination between UN member states.
The ITU has no enforcement power, but fundamentally that doesn't really matter much, since enforcement is handled by the member states. Are there attempts by various member states to skirt around the rules or favour their own national interests? Of course, and sometimes these are successful - but nobody just outright ignores the rules, because they know it very quickly leads to a tragedy of the commons.
Administering an orbital LVT is exactly the kind of thing that could slot cleanly into an expanded ITU mandate. Where the money goes would be up for debate, but I think the cleanest solution would be ITU rebates most of it back to the government of the country that applied for the orbital slot provided that they demonstrate it's going into a space sustainability fund.
Is it perfect? No, but it's based on a rickety-but-mostly-works international model and it doesn't require global government conspiracy theories to come to fruition.
Also, the number of countries with practical space launch capability is very small. US / China agreement isn't trivial, but if you can get them agreeing to ITU-administered slots, getting ESA, Japan, India, NZ etc is pretty straightforward (and Russia's capacity isn't huge even if they don't want to play ball)
Eh... no, not really. At low altitudes (<500 km), sure, but much above 600 km you are starting to look at decades for a passive deorbit depending on solar cycle and ballistic coefficient.
I mean, presumably, the tax would apply per-spacecraft with a price adjustment for orbit lifetime and how busy a particular orbit is, so a small constellation of 5-10 short lived microsatellites wouldn't have a huge entry barrier.
Anyone done any benchmarks on the NV4FP quant? Seriously considering pitching an 8 x RTX 6000 Pro box at work to run GLM-5.2 in an air gapped environment.
Ooh, I hadn't seen these yet! That looks quite compelling, my only hesitancy would be what the software support looks like. But 1 TB of memory for $110k is really intriguing - I might go bother a sales rep. Thanks!
Thanks so much for building smolvm! I liked it so much that I vibe coded a little bash wrapper around it to handle creating ephemeral VMs for Pi: https://github.com/neuroblaze/smol-pi
Consists of two scripts, one to build an OCI image (customizable by editing the Dockerfile that comes with it) and another to handle smolvm invocation. The invocation script mounts the current working directory under /workspace in the VM and the user's ~/.pi directory under /root/pi, and handles any other setup (eg: I have some convenience flags set up to specify a block all/block local/block internet/allow all for network access).
One issue I ran into, it doesn't seem like smolvm cleans up disk images from ephemeral VMs, so my script has to do that itself. Is this a known bug or intended behaviour?
Setting aside how shortsighted it is to fire your employees to replace them with AI, Ford also screwed up by firing the wrong employees. LLMs work best in the hands of experienced senior engineers who can work at a high level of abstraction because they already understand all the pieces underneath.
In a sense, using an LLM agent is like providing instructions to a very smart, very quick junior who despite being brilliant has some blind spots and lacks institutional knowledge. That's something that seniors excel at, so by firing your seniors you've fired the people best positioned to make full use of LLMs.
That's just the basics. To craft a prompt for a complex architectural task, you need to know the solution at least on an abstraction level. If you don't have the right system design in your head, no llm is gonna conjure it out of thin air
> In a sense, using an LLM agent is like providing instructions to a very smart, very quick junior who despite being brilliant has some blind spots and lacks institutional knowledge. That's something that seniors excel at, so by firing your seniors you've fired the people best positioned to make full use of LLMs.
aye.
I've posted this here at HN several times but I had my intern try to track down how many CVEs from a list of vulns we found were being exploited in the wild -- couple years ago, pre mythos that is. I also took the list to Copilot and Claude.
All 3 got different answers, albeit off by one or two. The intern told me at least he didn't know about X, which was far more useful. I later had him whip up a plan and some basic code to patch some of them, and the experience comparing his answer to Copilot was similar to before as well -- both mostly worked, but didn't, and in different ways, and mostly due to not knowing institutional best practices.
Even if they only fire the juniors and retain the seniors, they have effectively broken the pipeline that creates more seniors for the next few decades.
That is either betting on AI being better than humans then, or closure of the company.
"Ford rehires 350 engineers after AI fails to preserve expertise or train juniors" In order to rehire someone they must laid off or fired? You don't rehire new employees?
I think most of them were losses by attrition. Where they don't replace lost employees. That's usually the preferred method of downsizing if you can get away with it.
I wonder if Nico will be feeling so cocky when Papermark gets their general counsel involved. The public Twitter shaming was clearly an attempt to resolve this without litigation, but hey, if that's how Nico truly feels, guess he gets to see what's behind door #2 (a massive bill for a legal retainer).
> it's pretty clear that YC does not care about a negative reputation.
Perhaps not what the general public thinks, but I assume YC cares a lot about its reputation among VC firms that fund its companies, because VCs don't like being scammed (directly, or indirectly through unknowingly funding scams)
Many YC companies do bad things, and I guess they do so independently. There may well be repercussions for the most egregious cases, but I suspect a lot of ill-behaviour simply flies under the radar.
For example only yesterday I got spam from an YC company, Polymath, and I replied back asking where they got my details from - no response yet. Once I get something I'll make a GDPR subject access request, then a deletion request. I hope the overhead of that causes them to rethink their spamming campaign.
I have also gotten spammed by a YC startup, but they spammed an email that I use in git commits, and lead with "I saw your fork of $POPULAR_PROJECT, pretty cool!" or something like that and then continued to pester me with their drip program even as I replied asking them to never email me again.
My comment was not about doing a generic bad thing - it was about scammy behavior in particular (which ties to the Delve incident). YC depends on the VC ecosystem to fund its companies, and no VC wants to be scammed. If a reputation of cultivating/condoning/obliviousness scammers takes root, that would be bad for business.
> But I'm not going to complain to YC about it.
I am not complaining, or even expecting a moral decision. I'm legitimately curious how this will shake out, for purely capitalistic, reputation-management reasons.
Good luck with referring to GDPR. Try clicking through YC startup list and see how many load GA and other trackers onto their landing pages without a consent banner or even a privacy policy sometimes. It’s baffling.
I didn't realise that one could forcibly require a competitor to disclose trade secrets.
Now, INAL of course, but I would think this sort of mechanism would be quite gameable from both sides ( i) a wealthy competitor legally forcing a promising upstart to reveal source ii) a copycat working out some kind of arrangement where the code itself is licensed to them via shell company based overseas.)
As with most legal hacks, the courts figured this one out long ago :).
If someone is trying to dig into their competitor's trade secrets via discovery, the court offers multiple ways to safeguard against that. The defendant can identify information as a trade secret and ask that it be protected in some way - for example, the documents may be restricted to "Attorneys' Eyes Only", so while the plaintiff's attorneys can review the material, the plaintiffs themselves are barred from reviewing it. Or the judge themselves may get involved in an in-camera session.
There are software engineers that specialise in source code analysis that lawyers will often use in these cases. The engineers will be given access to source code in secure environments where they're not allowed to bring any device in or out. They review, analyse, and write up a report using pen and paper, that can then be reviewed by the lawyers.
Absolutely. It was very similar to one of my first jobs: "Legal Technical Analyst". Not as much time doing deep source analysis, but basically translating things for lawyers: "So as far as this claim of copyright/plagiarism... this block here, that's CS 101 stuff, that block there, that's novel, and does x, y and z".
There's also smolvm which is a nice minimal microvm manager based on libkrun: https://github.com/smol-machines/smolvm. I vibe coded a little shell utility for building and running OCI images for the Pi harness using it (easy enough to do manually, but the automation just makes it a couple quick commands rather than digging through documentation): https://github.com/neuroblaze/smol-pi