I have never seen a program segfault and crash more than apt. The status quo is extremely bad, and it desperately needs to be revamped in some way. Targeted rewrites in a memory safe & less mistake-prone language sounds like a great way to do that.
If you think this is a random decision caused by hype, cargo culting, or a maintainer's/canonical's mindless whims... please, have a tour through the apt codebase some day. It is a ticking time bomb, way more than you ever imagined such an important project would be.
I've been using apt regularly on Debian for a long time and never seen it crash or segfault. Very strange that you do. All software has bugs of course, but apt is so heavily used that I expect it gets attention. It just works for me.
I’m very very curious to know what it is you’re doing to experience this: I’ve used Debian and its derivatives for 25 years now. On desktops, laptops, and servers. x86, x86-64, and Arm 64. I have never had a segfault with APT. Not a single time. Problems with dependencies or such a few times, but I don’t recall APT ever crashing on me.
Almost 30 years for me, both on my personal machines and at work.
I went through a period about 25 years ago where apt crashed on my (rather janky) desktop almost every other run, and sometimes left my system in a state so inconsistent that I had to fall back on 'dpkg-reconfigure --force' and the like to fix it.
Turns out that it was due to a bad interaction between a failing stick of RAM and reiserfs' tail-packing feature, which was causing frequent silent corruption in /var/lib/dpkg/status and friends.
I don't think I've seen any similar issues since, across what must be many millions of apt runs I've been responsible for.
Perhaps gp is suffering from some similar underlying problem?
Try the "Windows Legacy" launcher, or a 3rd party launcher like PrismLauncher. The legacy launcher is made for Windows 7 and is directly equivalent to the macOS/Linux launcher, so it doesn't have a hard dependency on the Microsoft Store. It will probably be a while before they stop maintaining it because it's such a trivial port.
Everyone has to address their spiritual beliefs every time they mention something vaguely related to them? Else they lack epistemic humility? ...Did it occur to you that most people have actually thought of this question?
Wait, is "seems lacking in epistemic humility" just coded language for "I disagree, therefore you couldn't possibly be thoughtful"?
Imagine vibe coding something in production, it breaks half the internet, then you can't vibe code it back because it broke the LLM providers. A real catch-22 for the modern age!
> Some configs are inherently global and cannot be phased
This is also why "it is always DNS". It's not that DNS itself is particularly unreliable, but rather that it is the one area where you can really screw up a whole system by running a single command, even if everything else is insanely redundant.
Sure, but that doesn't really help for user-facing services where people expect to either type a domain name in their browser or click on a search result, and end up on your website every time.
And the access controls of DNS services are often (but not always) not fine-grained enough to actually prevent someone from ignoring the procedure and changing every single subdomain at once.
> Sure, but that doesn't really help for user-facing services where people expect to either type a domain name in their browser or click on a search result, and end up on your website every time.
It does help. For example, at my company we have two public endpoints:
company-staging.com
company.com
We roll out changes to company-staging.com first and have smoke tests which hit that endpoint. If the smoketests fail we stop the rollout to company.com.
That doesn’t help with rolling out updates to the DNS for company.com which is the point here. It’s always DNS because your pre-production smoke tests can’t test your production DNS configuration.
If I'm understanding it right, the idea is that the DNS configuration for company-staging.com is identical to that for company.com - same IPs and servers, DNS provider, domain registrar.
Literally the only differences are s/company/company-staging/, all accesses should hit the same server with the same request other than the Host header.
Then you can update the DNS configuration for company-staging.com, and if that doesn't break there's very little scope for the update to company.com to go differently.
The purpose of a staged rollout is to test things with some percentage of actual real-world production traffic, after having already thoroughly tested things in a private staging environment. Your staging URL doesn't have that. Unless the public happens to know about it.
The scope for it to go wrong is the differences in real-world and simulation.
It's a good thing to have, but not a replacement for the concept of staged rollout.
But users are going to example.com. Not my-service-33.example.com.
So if you've got some configuration that has a problem that only appears at the root-level domain, no amount of subdomain testing is going to catch it.
This will also reveal your backend internal IP addresses. Anyone can find permanent logs of public IP addresses used by even obscure domain names, so potential adversaries don't necessarily have to be paying attention at the exact right time to find it.
> Intermittence is mostly a consequence of using orbiters as communication relays to reach a planet’s surface. Orbiters go around the planet and are only able to communicate with peers they can “see”.
As I understand, this type of intermittence will mostly be a solved problem by the time there are only a few relay satellites around a planet. I think the moon may already have enough for full coverage. (It does not have to be a full-on starlink-like network, Musk is a bit delusional about this)
Still interesting and potentially useful to design around it regardless.
> by the time there are only a few relay satellites around a planet.
Based on the limited information I have, I think it will take decades (at least) to get there for most planets. Hopefully the results of this research will be useful for a long time.
You would still need relays between earth and mars (Maybe at L4 or L5) since when they are on opposite sides of the sun, that will likely block radio transmissions
Should be noted that wild cats (felis silvestris, felis lybica, felis catus) are not "apex" predators based on hunting success or being obligate carnivores. It's a common misconception that cats were apex predators when they were domesticated. They are both predator and prey, firmly in the middle of the food chain, and as such have the instincts of both. "Apex predator" would mean taking down large animals like elk, which would obviously be ridiculous for a small cat unless the prey is literally immobile.
> the same for claude, you're API is tied to a bankaccount, and vibe coding a command and control system on a very public system seems like a bad choice.
Aside from middlemen as others have suggested - You can also just procure hundreds of hacked accounts for any major service through spyware data dump marketplaces. Some percentage of them will have payment already set up. Steal their browser cookies, use it until they notice and cancel / change their password, then move on to the next stolen account. Happens all the time these days.
If you think this is a random decision caused by hype, cargo culting, or a maintainer's/canonical's mindless whims... please, have a tour through the apt codebase some day. It is a ticking time bomb, way more than you ever imagined such an important project would be.