I've written about this elsewhere but I predict there will be a significant secondary market for repurposing parts of datacenter GPUs (for example, RAM chips) by desoldering them and soldering them onto new PCBs that fit PC/consumer use cases.
> Git repositories were never extended to version everything developers build with in the AI era. [... more fatalistic verbiage ...] A system that cannot be retrofitted for what's ahead.
Two paragraph later:
> Entire will be based on three key components: a git-compatible database [...]
I predict there's going to be a niche opening up for companies to recycle the expensive parts of all these compute hardware that AI companies are currently buying and will probably be obsolete/depreciated/replaced in the next 2-5 years. The easiest example is RAM chips. There will be people desoldering those ICs and putting them on DDR5 sticks to resell to the general consumer market.
Being open source is technically not required to verify this. It’s possible to prove or disprove security claims by reverse engineering, and iOS specifically is already a popular target for professional/academic RE.
Of course, a hardware switch is always more secure.
> Back when decent civilization was a thing, there were rules of engagement, conduct, the pursuit of security, and strategic goals which didn't include active genocide of civilians.
What period of human history are you referring to exactly?
Feel free to read the chapter „Linksextremismus“. It talks about various violent Antifa groups and other cases. Keep in mind that the definition of „extreme left“ refers to organizations that want to replace the basic democratic system with communism or anarchy (according to the German constitutional court).
It does not necessarily include „political craziness“ that we may disagree with. The point of these legal descriptions of organizations is not to be used as a political weapon for parties you don’t like. You have to do some significantly malicious stuff to be considered as such.
All of the code is imported in 1 commit. The rest of the commits are deleting the specs that I guess were used to generate the code. There’s one commit adding code which explicitly says generated by Claude code. There’s basically no chance the whole codebase is not AI slop.
Seems like we have similar thoughts as we wrote more or less the same comment 10 minutes apart :) Would love to chat about this, maybe we figure out a way to get there? Email is on my profile.
There are some reasons. As a satellite operator, the worst thing that can happen is getting locked out of the satellite for any reason. So the risk of implementing a “new” technology that has a high risk of locking you out if you lose the keys for some reason sometimes outweighs the benefit of increased security. So I think there’s some work to do in building generally applicable key management practices and backup ways of reestablishing a command link.
> ...so how do you keep it secure?
> Is hosting a RPi in space different from hosting one on the ground, reachable over the public internet? I assume it is, but tell me more!
It is somewhat different from a security point of view, but the gap between them is getting smaller. The main "obstacle" to hackers taking over your satellite is that it is somewhat difficult to set up a UHF/VHF/S-band ground station with enough transmit power to reach the satellite. And you need knowledge of the command protocol that the satellite uses. But ground stations are getting cheaper every day, IMO you can build a fairly capable transmitting setup for ~1000€. So the remaining protection is a form of security by obscurity: "we invented this command protocol, so nobody knows how it works". But that can obviously be defeated by recording ground station signals and some dedicated reverse engineers.
When those protections fall away, you'll find that a lot of satellite/CubeSat software out there is quite vulnerable (see https://jwillbold.com/paper/willbold2023spaceodyssey.pdf). You often find things like commands that are literally "arbitrary memory read/write". While they are a nightmare from a security point of view, they are extremely useful for operators of experimental satellites, e.g. to patch software in memory to fix bugs or read variables that are not exposed as telemetry. I have written a few of these patches myself, and my friend PistonMiner used them brilliantly to hack in a software update capability and revived a 15 year old CubeSat that was assumed to be dead - see their 38C3 talk: https://www.youtube.com/watch?v=KdTcd94pVlY
If you ask me, the way to keep satellites secure is to basically apply the lessons that we have learned in terrestrial computing to space applications. Things like using encryption/authentication, process isolation backed by a MMU, memory safe languages, etc. That's what we're trying to do with RACCOON OS btw. You can take at the flight software of CyBEEsat, a 1U CubeSat that is launching soon(tm): https://gitlab.com/rccn/missions/cybeesat
My dream is to build an open source CubeSat kit (hardware, software, mission control software) with an experience similar to Arduino. Download GUI, load up some examples, and you're directly writing space applications. Ideally should be capable of high end functions like attitude control and propulsion. The problem is that designing and testing such a thing is a rather expensive endeavour. So far I haven't found a way to get funds to dedicate time on this kind of "abstract"/generic project, most funding organizations want a specific mission proposal that ends generating useful data from space.