And for some reason people think Kali is the distro they should use to check email, browse the web, play videos. Now we have an experiment running on human subjects a reality show: in practice, what really what happens if you run as root all the time on a desktop system used primarily by just one person?
The most common arguments for why one ought not run everything as root--like, if you don't have a backup, then you could accidentally have to reinstall the system, whereas if you run as a limited user then you could only accidentally lose everything made by you or anyone you love that is important to you--are not very compelling.
The argument, "Well, at least you can have fewer ways to mess things up!" is correct, but I don't think it usually manages to capture the degree to which it really is not a good idea to run stuff as root needlessly.
For a system that a single human user operates, I think the reason is really, "If you do everything as root, you will not be able to reason effectively about what could go (or has gone) wrong."
A trove of novice Kali Linux questions about use cases that Kali Linux is not actually intended for might provide the evidence needed to confirm or refute this idea.
What do you think?
I mean, about the idea that the reason to avoid running as root even on a "single user" system is to avoid doing bad things that don't make enough sense to anticipate and avoid through other means.
I agree with that. You will do things you don't know are a bad idea. The UI will not complain to you much if at all. Things will go wrong. You will not know why. You will ask an unclear question on Ask Ubuntu which will be closed. Sad face
So @EliahKagan, you might be interested to know the other day I had to modify a proprietary JAR file. It actaully went much smoother than I had expected.
@EliahKagan Well what I did was, I opened the JAR in my decompiler, decompiled only the class I needed to modify, and saved the output to a file. Then I opened the JAR in archive manager, and deleted the compiled class that I was going to modify. Then I created a new module in AS with the original JAR and some dependencies, and then only had the one class which had to be recompiled again in that module.
I changed the Java wrapper for a proprietary C++ lib to load the lib from the shared storage instead of Including it with each compile. (It was increasing the APK size too much)
So it was a 3-line change basically
But what I found quite shocking was the fact the the output from the decompiler compiled again without any modifications!
I didn't realize Java decompilers had gotten so good
@EliahKagan I'm not a git expert, and I have a bit of an issue and was wondering if you can help me. I forked a repo on Github, made a few commits in the master branch (because I forgot to make a new one) and PRed. When the maintainer merged, he squash-merged, and now my master is behind the upstream master. However, git thinks that it's up to date - and it is - but the issue is that the history is different even though the actual files are the same
@Neil I don't know. Did you find it? If not, what have you found about it so far? Also, maybe someone in the general room knows.
@AndroidDev I feel like I should know this... but I don't. If you find out how to fix it properly, I'd be interested to hear. I think that would definitely be on-topic on Stack Overflow, if you wanted to ask a question about it. (There are a lot of Git questions there.)
