teawrecks

The difference between the idiot and the expert, is the expert knows why the fences are there, and can do the rewrite without having to relearn lessons. But if you're supporting a package you didn't originally write, a rewrite is much harder.

"0.001% of the time, I wanna know every time 👉😎👉"

Yeah, I get that. But are we talking about during development (which is why we're choosing between C and something else)? In that case, you should be running instrumented builds, or with debug functionality enabled. I agree that most programs just fail and don't tell you how to go about enabling debug info or anything, and that could be improved.

For the "Permission Denied" example, I also assume we're making system calls and having them fail? In that case it seems straight forward: the user you're running as can't access the resource you were actively trying to access. But if we're talking about some random log file just saying "Error: permission denied" and leaving you nothing to go on, that's on the program dumping the error to produce more useful information.

In general, you often don't want to leak more info than just Worked or Didn't Work for security reasons. Or a mix of security/performance reasons (possible DOS attacks).

It's more of an ABI thing though, C just doesn't have error handling.

And if you do exception handling wrong in most other languages, you hamstring your performance.

Yeah, this was something I recognized about myself in the first few years out of school. My brain always wanted to say "all of this is a mess, let's just delete it all and start from scratch" as though that was some kind of bold/smart move.

But I now understand that it's the mark of a talented engineer to see where we are as point A, where we want to be as point B, and be able to navigate from A to B before some deadline (and maybe you have points/deadlines C, D, E, etc.). The person who has that vision is who you want in charge.

Chesterton's Fence is the relevant analogy: "you should never destroy a fence until you understand why it's there in the first place."

You mean 0 indicating success and any other value indicating some arbitrary meaning? I don't see any problem with that.

Passing around extra error handling info for the worst case isn't free, and the worst case doesn't happen 99.999% of the time. No reason to spend extra cycles and memory hurting performance just to make debugging easier. That's what debug/instrumented builds are for.

The actual executables shouldn't ever go in that folder though.

Typically packages installed through a package manager stick everything in their own folder in /usr/lib (for libs) and /usr/share (for any other data). Then they either put their executables directly in /usr/bin or symlink over to them.

That last part is usually what results in things not living in a consistent place. A package might have something that qualifies as both an executable and a lib, so they store it in their lib folder, but symlink to it from bin. Or they might not have a lib folder, and just put everything in their share folder and symlink to it from bin.

Great, there we go, sounds like all distros should learn from OpenSUSE.

For wake from screensaver/sleep, this should be configurable. Your window manager is locking your session, so you probably just need to turn that option off.

For installations and updates, I suspect you're used to Windows-style UAC where it just asks you Yes or No for admin access in a modal overlay. As I understand it, this is easier said than done on linux due to an insistence on never running GUI applications as admin, which makes sense given how responsibilities are divided and the security and technical challenges involved. I will say, I agree 100% that this is a serious area that's lacking for linux, but I also (think I) understand why no one has implemented something similar to UAC. I'll try to give the shortest version I can:

All programs (on both Windows and Linux) are run as a user. It's always possible for any program to have a bug in it that gives another program to opportunity to exploit the bug to hijack that program, and start executing arbitrary, malicious code as that user. For this reason, the philosophical stance on all OSes is, if it's gonna happen, let's not give them admin access to the whole machine if we can avoid it, so let's try to run as much as possible as an unprivileged user.

On linux, the kernel-level processes and admin (root-level) account are fundamentally detached from running anything graphical. This means that it's very hard to securely, and generically, pop up a window with just a Yes or No box to grant admin-level permissions. You can't trust the window manager, it's also unprivileged, but even if you could, it might be designed in a supremely insecure way, and allow just any app with a window to see and interact with any other app's windows (Xorg), so it's not safe to just pop up a simple Yes/No box, because then any other unprivileged application could just request root permissions, and then click Yes itself before you even see it. Polkit is possible because even if another app can press OK, you still need to enter the password (it's not clear to me how you avoid other unprivileged apps from seeing the keystrokes typed into the polkit prompt).

On windows, since the admin/kernel level stuff is so tightly tied to the specific GUI that a user will be using, it can overlay its own GUI on top of all the other windows, and securely pop in to just say, "hey, this app wants to run as admin, is that cool?" and no other app running in user mode even knows it's happening, not even their own window manager which is also running unprivileged. The default setting of UAC is to just prompt Yes/No, but if you crank it to max security you get something like linux (prompt for the password every time), and if you crank it to lowest security you get something closer to what others are commenting (disable the prompt, run things as root, and cross your fingers that nothing sneaks in).

I do think that this is a big deal when it comes to the adoption of linux over windows, so I would like to see someone come up with a kernel module or whatever is needed to make it happen. If someone who knows linux better than me can correct me where I'm wrong, I'd love to learn more, but that is how I understand it currently.

In /etc? Are you sure? /usr/share/applications has your system-wide .desktop files, (while .local/share/applications has user-level ones, kinda analogous to installing a program to AppData on Windows). And .desktop files could be interpreted at a high level as an "app", even though they're really just a simple description of how to advertise and launch an application from a GUI of some kind.

An application can know that a file represents a soft link, but they don't need to do anything differently to follow it. If the program just opens it, reads it, writes to it, etc, as though it were the original file, it will just work^tm^ without them needing to do anything differently.

It is possible for the software to not follow a soft symlink intentionally, yes (if they don't follow it unintentionally, that might be a bug).

As for hard links, I'm not as certain, but I think these need to be supported at the filesystem level (which is why they often have specific restrictions), and the application can't tell the difference.

And know how to use an existing btrfs partition. And always [at least have an option to] show exactly what the automatic installer is going to do before I run anything. There's gotta be a middle ground between "we'll just surprise you" and "here, do everything yourself".