5,948 karma · joined June 23, 2017
OTOH if you're a religious fundamentalist who thinks the End Times are near and just need a little shove, you can certainly use AI to design your weapon and recruit people to go release it. The difference being that religious fundamentalists aren't rational actors and aren't interested in self preservation.
That system is "the economy". Which, clearly, doesn't have humanity's best interests in mind.
I"m not saying it's obviously going to be great. I'm saying that "extinction event" has a very specific definition, and this isn't it.
It is not. Certainly AI is a big part of why robotics is hard, but it is by no means the biggest.
You can fall into one of two camps: you either think that robots will need to work in human-engineered spaces, doing jobs by replacing humans; or you think that we need to change our infrastructure in order to be robotically compatible. Of course, there are intermediate states, but those are the two cleanest ones.
In the first case, robots are hard because robotic manipulation is hard. Building robotic hands that are economically viable in human jobs is, currently, FAR from a solved problem. The human hand has 24 degrees of freedom and very capable touch sensing. Current touch sensors have a MTBF of tens of hours. And not only can we not build such hands, but we also do not have and are not likely to get the massive datasets a transformer model would need. Also, robots are not self-repairing, which makes them far less economically viable right now. We do not have the right datasets to even understand most step-by-step manual work, and no, VLAs are not the answer, because VLAs stop with vision, not with touch. They don't have the granularity required to make a robot actually reach out, pick up a tool, and use that tool to replace an oil filter.
So it's not just an AI problem. It's a data problem, a simulation problem, and a bunch of hardware problems.
In the second case, a tremendous amount of work needs to be done before we have anything resembling a fully automated supply chain. We would need self-driving cars and self-driving mining equipment. We would need self-driving trains and aircraft and ships. And not only that, but we would also need robotically repairable cars and trains and ships and factories, which would mean we need robotically repairable machine shops and robotically repairable buildings in which to house them. And so on and so on. Once you recurse down that tree a couple of steps you get to things like robotically compatible oil wells (for asphalt), robotically layable undersea cables, robotically wireable solar farms, robotically manufacturable and repairable pipelines and undersea wells, automated road and rail repair, etc.
I'm not saying these things will never happen. I'm saying that they're a huge lift, not primarily driven by AI, and way less than 10% likely over the next decade.
"AI" by itself won't kill us in the next ten years. I think. The reason I think that is that ten years from now, the tech economy won't be completely automated. I say this as a roboticist: as was adequately stated on a post earlier this week, robots are hard. So even a malign rational actor would still need human labor.
On the other hand, even the HuggingFace hack wasn't actually propagated by AI. it was initially started when humans directed the AI to achieve impossible results on a series of tests, and the AIs figured out that cheating was the only way to do that. That was then not caught by humans due to what seems to be a shockingly slack safety culture even for a company not known for its safety standards.
The point being: humans seem to me to be the weak link here. An AI isn't going to (for instance) engineer a bioweapon by itself. It's going to do so at someone's direction, and then significant parts of that thing are going to be assembled with human labor inputs.
I'm not sure what to do about the humans. Of course, we've had the ability to extinct ourselves for decades, and we're either muddled through, been lucky, or both. The problem with AI is that it pushes power down to the individual, not the nation-state or large corporation.
But it's nearly impossible to put odds on how likely that is to result in an extinction-level terrorist attack (which is what this would be). So I sympathize with the various researchers, but I have no idea how they came up with their figures, and I don't think they know either.
The evolution of the rumen was one of nature’s best tricks.
Current generation tactile sensors cost a couple thousand $ PER FINGER, and have a real world MTBF of hours. The cost can be solved with economy of scale. The fragility is harder.
The being said, I'm reading "Proto" By Laura Spinney, and the thing that strikes me is how recently the world's major languages developed. Everyone assumes we had language fifty thousand years ago, but the actual language families we know about all seem to trace to no more than about 10,000 BCE, and maybe a lot younger than that. The odds of Proto-Indo-European being traceable to a single tribe in the Black Sea region circa 4500 BCE seem really low to me, but that's what seems to have happened.
Note that the algorithm stack for almost any spacecraft cannot rely on modern compute. Single-core sub-1 GHz processors are the standard. Very few GPUs have ever been in space, in any capacity, and none that I know of in a mission-critical role.
"Does the satellite servicer need its targets to be constructed to some common standards, or is the new capability now leading to common standards?"
We can do life extension missions on client spacecraft that were not designed to be robotically compatible. That's actually SpaceLogistic's primary business case.
The question of standards in the spacecraft industry is a huge question. It's being worked... by a lot of people, cue the obligatory XKCD reference.
"Was it built with a method for itself accepting refueling?"
We are, in fact, refuelable.
"It seems to me this device would lead to a revision in satellite reliability design and life calculations."
We hope so! Spacecraft are expensive in large part because they have to be designed to be incredibly reliable. The example I use is cars. If you had to design a car that could go for half a million miles without ever having a part replaced, you could. It would just cost a billion dollars. But that's how we design spacecraft today. IF we can create a "mechanic safety net", we might be able to bring the cost down significantly.
To get back into earth's gravity well from a circular orbit requires similar amounts of fuel. Getting things back to earth from low earth orbit is doable, if you have a heat shield, because you only have to dump enough velocity to start hitting the atmosphere, and atmospheric drag does the rest of the work.
But that doesn't work at GEO, because you're so high (22,000 miles as opposed to ~1,000 miles for LEO). It's very hard to get enough delta-V (read as "change in velocity", which is basically the amount of fuel you need per unit mass) -- you'd need something with as much fuel as the upper stage of the rocket you were launched on, plus you'd need a heat shield. Alternatively you could use electric propulsion, which takes a lot less fuel, but would also take, literally, a couple of years, during which time you're a hazard to navigation to anything in a lower orbit. Plus, electric thrusters of the size you'd need to do this aren't cheap either.
So we basically never do that. If you need to dispose of a derelict satellite at that altitude, it turns out to be much easier to raise its orbit by a few thousand kilometers.
So, nobody will be recycling space debris that lives at GEO any time soon, unless someone figures out how to do it in situ.
I'm very hopeful that I'll get a strong technical paper through public release by the end of the year, ant at that point I could provide more detailed technical answers to things a HN audience would be interested in.
I grew up in the middle of nowhere Virginia. Like many of you I was a nerd, and I had no outlet for that nerd-dom until I spent all summer working for money to buy a C64. I taught myself assembly, and was a high school intern at NASA Langley where I learned about parallel processing, was introduced to the idea that people would actually pay you money to program computers, and had a tour of their space robotics lab.
When I went to college the guy two doors down from me in the dorm decided he wanted to build a robot, and he recruited me because I knew how to code. We spent freshman year working on a six-legged frame walker which we dreamed would explore Mars someday (this was in the late 1980s, long before the first Mars rover). It didn't work for crap -- the late 1980s were a disaster for makers, we had to source everything from the hardware store or Radio Shack. It was also the most amazing thing I'd ever done, and from then on I was an aspiring space roboticist.
I managed to not fail out, but it was close.
I went to grad school at the University of Maryland's Space Systems Lab under Dave Akin ("Akin's Laws of Spacecraft Design"), where I learned control theory and a ton of hands-on skills and got to scuba dive supporting the development of Ranger, which could have been the first US satellite servicer except we could never find a launch for it. I graduated with a PhD in aerospace engineering in 2003, and got hired by NRL, where I worked on RSGS.
The Apollo (and Artemis II) astronauts went through GEO inside a metal capsule going as fast as they could.
"Since the mission is designed to attach one and then leave to go to another satellite that needs servicing?"
Yes.
“This is why Linux now provides rseq() which is a much more enlightened solution. With restartable sequences, you actually can get rid of both the mutex and atomics, while the OS continues to fully abstract scheduling. The way it works is you advise the kernel whenever your program enters a critical section of code that you don't want interrupted. It's probably going to be maybe 10 assembly instructions tops. The first assembly opcode should be a move instruction that sets the rseq_cs field. The last instruction needs to be the thing that makes the modification to your global data structure. Think of it sort of like a really tiny database transaction. What makes it go fast, is that the bidirectional communication with the kernel happens via shared memory.”
"The system" almost always consists of mid-level bureaucrats. Maybe not this particular one, but her bosses -- a job which, if she sticks around long enough, she will eventually get promoted into. A large amount of what the government does isn't formally law, it's policy, which is often decided by those mid-level managers.
And like individual bureaucrats, "the system" in this case finds it easy to make demands of people if those demands do not result in increased workload for the agency. But if they do result in increased workload for the agency, then the policies that result in that increased workload often get rethought, or the agencies suddenly discover that they can make allowances, and so on.
In this case, I'm confident that "agency X cannot accept pdf documentation" isn't actually law. It might be guidance issued by an agency lawyer, but that isn't the same thing. It is likely to be a policy decided fundamentally by the IT department, which is estimating a high cost for securing the agency IT system to securely handle pdfs. That cost is compared to the cost of accepting faxes, which is significantly lower, and so a policy is issued that the agency cannot accept pdfs, and the legal guidance is offered as justification.
What is not factored in to the decision is the cost to the taxpayer. That's an externality.
So, if the taxpayers can magically make it much more expensive for the agency to accept faxes, so that it is suddenly not an externality any more -- which is what happened in this case -- then the above calculus changes, and the agency discovers that, you know what, actually we can accept pdfs. The IT department is ordered to make the necessary improvements, and it all works.
In my particular case, we were told for literally decades that we could not telework. It wasn't secure enough. Then COVID happened, and suddenly we had a telework system in place, with all the necessary Microsoft licenses purchased and servers stood up and laptops issued and VPN accounts activated, in less than three weeks, and nobody said anything about telework not being secure enough ever again. Because the original justification wasn't true. Setting up telework was more expensive, so we didn't want to do it, and we came up with reasons why we "couldn't". As soon as it was cheaper, we found out that we could do it after all.
As a government employee: it often is the employee personally. Not always, but surprisingly often. There is a type of mid-level bureaucrat who just can’t be bothered to make anyone else’s life easier, even if they can. It’s just easier not to, and over time that becomes its own form of malice. The tales I could tell you about security officers basically abusing their power in order to make their own lives as easy as possible, while making everyone else’s live almost impossible…
This is the way.
The problem is that it took Karen zero effort to say “we only accept fax”. She doesn’t care about how much effort it takes you you — in fact, as implied, it taking you a tremendous amount of effort actually reduces her effort. In order to make a dent, you have to figure out a way for the idiotic policy to impact the person making and/or enforcing it. That’s the only way it ever changes.