Live data from Hacker News

Suicide Linux (2009)

qntm.org

161–170 of 183 posts

Re: Suicide Linux (2009)

#162
post #45

Earlier quoted context omitted.

I can one up you: Coworker was trying to remove node so we could install a new version, so he ran: rm -rf /usr/bin node -rf was due to muscle memory, and unfortunately he forgot the space. That was a fun one to clean up. We were able to use nc because that was in /bin and not /usr/bin, so we used that to pipe curl over through a socket and then used curl to install dpkg + apt, then ran apt update to fix everything an…

It always scares me when people automatically add -rf after typing rm no matter what they're doing. How do you even get into that habit in the first place?

Starting out with that behavior because it comes up a lot in tutorials, probably. And then not making a typo mistake earlier on to learn the lesson to not do that with every rm command.

I'd probably have that habit if I didn't once delete everything in a /bin directory early on in my learning, and luckily it was in a VM.

Re: Suicide Linux (2009)

#163
post #30
post #27

> Perhaps rm -rf / should be replaced with something with more verbose flags set. That way, when you run a bad command, you are told immediately that things are being deleted This gives me an idea: Hell Linux. In Hell Linux, the operating system does its best to pretend that nothing is wrong, so it takes you as long as possible to realize that you've made a mistake. Commands ignore all unrecognized flags. In shell sc…

This sounds like if the designers of the web made a Linux distro.

Had to chuckle, but the I realized that everything is going in this direction on desktop as well

Re: Suicide Linux (2009)

#164
post #13

This is like that time, last week, when I was having issues with do-release-upgrade and someone helpfully suggested to run sudo apt-get purge python* && sudo apt-get autoclean && sudo apt-get install python* Which I did without paying attention to what I was doing and it turns out that this is one of the worst things you could do ever on a Debian-based distro. Damn you, abu-ahmed al-khatiri.

What's wrong with that command?

If you install a minimal Debian server avoiding recommends, and remove a few non critical packages, you can remove python, and start building from there. No problem.

Nothing is wrong.

If you go with a default installation, and start building over there, for example a desktop system. This will remove everything else that depends on python (not only python).

And that, is probably wrong, as you do not expect to remove half of the system (and don't reinstall it back), when you try to reinstall python, like megiddo said.

Some packages that do not need python at all, depend on python because of the packaging choices, like post/pre install scripts written in python instead of shell.

Other packages that do not use python in their core functionality (for example a program written in C) depend on python because of add-on scripts or contributed extensions, shipped in the same package.

Unlike Debian, in the Ubuntu case this command is worse, because Canonical push hard for python.

Historically, many Debian packages depending on python, have been introduced or modified by maintainers/developers working for Canonical.

To install a minimal Ubuntu server without python, first you need to remove many packages (a lot), related to launchpad, or landscape, or a few other Ubuntu specific services, or stuff really intended for desktop users (not for a minimal server).

Nothing against Python or Canonical... but as I have needed to deploy servers at work with the requirement of really really minimal base, I know well about removing Python in both Linux distributions.

Re: Suicide Linux (2009)

#165
post #117

Earlier quoted context omitted.

That is a better name in all ways. It might upset people who live in former war zones though. I can't speculate there.

To be equitable, Suicide Linux might upset victims of sui-- oh. Never mind.

To be fair, the victims are left with the aftermath.

Re: Suicide Linux (2009)

#166
post #148
post #27

> Perhaps rm -rf / should be replaced with something with more verbose flags set. That way, when you run a bad command, you are told immediately that things are being deleted This gives me an idea: Hell Linux. In Hell Linux, the operating system does its best to pretend that nothing is wrong, so it takes you as long as possible to realize that you've made a mistake. Commands ignore all unrecognized flags. In shell sc…

Is there a name for this design philosophy? A lesser version of it is already what both shell scripts and PHP pages do by default. No crashing—only limping forward (likely in ridiculous invalid states.) > if one branch exits with a nonzero exit code, the other branch is taken That's called the Amb operator. It's actually fairly useful! Presuming you tended to write side-effect-free shell scripts, I could see enjoying…

Some variants of BASIC had the infamous 'on error resume next' statement.

Re: Suicide Linux (2009)

#167

Earlier quoted context omitted.

That's a bit extreme. You should at least allow some error messages. Though those ones should just say "Oops, something went wrong :)"

Seriously speaking, it took me many years to realize that nearly all Windows BSoD messages are non-specific and useless - looking them up is a total waste of time. The only correct way to identify the actual error is analyzing the crashdump in WinDbg. I recently fixed a family computer that crashes randomly after a RAM upgrade. Removing the RAM didn't help, and it was totally a wild goose chase. The BSoD stop codes i…

In this particular example, I think the error is as specific as it gets, though.

Re: Suicide Linux (2009)

#168
post #55

A problem with most commands is that they usually don't need extremely-unfortunate typos or russian-roulette-enabled shells to turn into something wrong: they are usually wrong in passing , while you're typing them. I always wondered if something could be done against the effects of an accidental premature return. Some of us have cats... `sudo rm -rf /tmp/workdir` starts with `sudo rm -rf /` `git reset libs` starts w…

Thats why you always do (does not work on BSDs)

  rm  WHATEVER -rf

Re: Suicide Linux (2009)

#169
post #52
post #27

> Perhaps rm -rf / should be replaced with something with more verbose flags set. That way, when you run a bad command, you are told immediately that things are being deleted This gives me an idea: Hell Linux. In Hell Linux, the operating system does its best to pretend that nothing is wrong, so it takes you as long as possible to realize that you've made a mistake. Commands ignore all unrecognized flags. In shell sc…

> the operating system does its best to pretend that nothing is wrong Call it "Trump Linux"! :)

If we're poking fun at political leaders, maybe the antithesis to this OS - one that pretends everything is going wrong all the time - should be Brussels OS

Re: Suicide Linux (2009)

#170
post #167

Earlier quoted context omitted.

Seriously speaking, it took me many years to realize that nearly all Windows BSoD messages are non-specific and useless - looking them up is a total waste of time. The only correct way to identify the actual error is analyzing the crashdump in WinDbg. I recently fixed a family computer that crashes randomly after a RAM upgrade. Removing the RAM didn't help, and it was totally a wild goose chase. The BSoD stop codes i…

In this particular example, I think the error is as specific as it gets, though.

Please reread the comment. The quoted error is from the debugger, not from the stop code in a BSoD screen. The BSoD screen would be something like...

    0x0000000A: IRQL_NOT_LESS_OR_EQUAL
or...

    0x0000007E: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED
It corresponds to whatever the last operation kernel was executing before it fails, but without information on how it fails, and only indicates that something is wrong in the kernel or in a driver in general. You can chase these stop codes and check for bad RAM or bad drivers forever without real progress. Don't spend too much time on these codes, it's a waste of time. Enable memdump and get WinDbg. In comparison, analyzing the crash dump in WinDbg gives real information.

    KERNEL_DATA_INPAGE_ERROR - This bug check indicates that the requested page of kernel data from the paging file could not be read into memory.
Post reply on HN