> Damn - all packaging tools to hell. Damn them I say!
That's the thing about packaging tools: they have to work 100% reliably, every time, without any error, or they're catastrophic. As Douglas Adams says: "the difference between something that might go wrong and something that cannot possibly go wrong is that when something that cannot possibly go wrong does go wrong, it also turns out to be impossible to get at or fix."
the tool did work reliably. the user overrode it its safety check. i.e. imagine I chattr +i libc to prevent it from being removed, and a user chattr -i and rm's the file. whose fault is it? the user who did the action.
Wow, the world was such a different place back then. When this was written, the dotcom bubble hadn't even fully collapsed. Just two weeks later, NASDAQ would hit a peak of about 5048.62 before tumbling all the way 1139. America still believed itself to be invincible, as 9/11 hadn't even happened yet and airport security was fairly relaxed, and Enron was still considered a decent company.
This part wasn't true. I lived then, as I do now, in Houston. In 2000, I was a partner in a custom software/internet technology professional services company. (Back then, you could charge lots of money to help people build intranets; it was GREAT!)
Enron had bids out all over to do custom work for them, but it was also super common knowledge -- at least locally -- that if you wanted to get paid, you needed to insist on a fat retainer, because Enron absolutely would not pay on time, or maybe ever if they thought they could get away with stiffing you.
Yes, but given everything that's about to happen to those people, the technical difficulties with some fledgling operating system seem so distant now. Many people who posted in that thread are no longer even alive probably.
What are you proposing as the alternative? Even after major catastrophe we would still want to be involved in the trivialities of OSes, as we are now amid the pandemic.
> The rest was obvious - start from relevant block in inode table and walk through the references... Once we got that, it was an easy ride
It reminds me about when I sometimes have do ext4 surgery with debugfs. I always keep a static busybox running, so I can either piggyback to it (or its proc entry in the worst case - but as much fun as it may be, I don't like too much fun!)
> Amazing how little you actually need to bring the system back to life...
Indeed. Interestingly, this art seems to be lost to people who will talk about "cattle not pet" and how layer upon layer of abstraction protects them from anything - until it doesn't.
For one, it's (2000). Second, the subject is misleading - the lined post is about Al Viro's hacky solution of another problem, unrelated to Debian (or, more precisely, OP's adventures with dselect).
Debian was one of the first Linux distributions I tried and I had forgotten how terribly confusing dselect was to me at the time. Funny how apt-get has outlived it, even though it does not offer a "friendly" interactive interface.
Difficult to overstate the importance of aptitude in light of comments like this. Aptitude is a package manager frontend with an ncurses TUI. The biggest benefit is the clarity it gives to managing dependenies.
Other than that, I completely share your sentiment about how monsterous dselect is with dep-hell situations :).
That's the thing about packaging tools: they have to work 100% reliably, every time, without any error, or they're catastrophic. As Douglas Adams says: "the difference between something that might go wrong and something that cannot possibly go wrong is that when something that cannot possibly go wrong does go wrong, it also turns out to be impossible to get at or fix."