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.
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.
We're looking at 40 days based on 30 minutes of daily reading at 30% brightness, and with Wi-Fi and Bluetooth turned off. Dropping the brightness down to 10% nets an increase to 53 total days of runtime.
So as long as you don't use it, the battery will last a long time!
For now, because Lemmy is relatively new. There's a reason many bot farms run accounts that are unassuming, "normal" people. Accounts that are established have value. They can then sell those accounts to another group who needs to sew discord. The older Lemmy is, the less useful the new account icon will be.
I'm not familiar with the Gemini protocol, but how does it differ from just starting up a webserver pointed at a single folder with an index.html
? Isn't it still just as possible to make a simple site using http?
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.
I think their point was, all things being equal, a server on discord vs a community on a Lemmy instance doesn't make a difference. In both cases, the people who ultimately own the platform have to decide whether to just delete them or go toe-to-toe with Nintendo in court.
Hosting everything themselves is a different story. Though...is it possible for a federated instance to exist inside the tor network? Maybe that's already a huge thing and it never occurred to me.