taaz

To explain you @TCB13@lemmy.world why you are being ridiculed here, the WINE itself stands for "Wine Is Not an Emulator".

It's a compatibility layer, but for all things and purposes a non-technical person might as well think about it as an emulator - it makes stuff run where it normally wouldn't.

Yeah, laptops with dedi nvidia cards were always pain with Linux, at least my experience was always terrible (there is no feature parity to windows, especially energy saving stuff), though for me I am in the position where I would rather have Linux with my configs (which translates into: I've spent a lot of time on tweaking and fixing stuff over the time) then windows, so a nvidia gpu in a laptop is no-go in the first place.

Linux requires time investment, not everyone is comfortable to dig in. The fragmented nature of Linux (multiple Desktop Environments, graphical libraries, heck even low-level stuff: va-api/vdpau, ...) lends itself into it so there is no sugar-coating it.

If you can't or don't want to fix it then win is the way but I would hope one day you will give Linux another chance - the community is there, so there is a high chance it will be better the next year and the one after that, and so on.

I've also found about this recently when moving my root from drive to drive which was after I upgraded to 13th gen intel (from various older i5s) and the best cipher changed (cryptsetup benchmark).

Oh cool, have been using RawTherapee will check this out next time.

El Salvador needs to offload bags of BTC, loud and clear

Welcome to federation, where basically every instance is a proxy to all others.

Btw you are also free to block any instance yourself.

There is also FX which can do this too, additionally you can browse/download/upload files to/from the phone locally from PC through browser (the app opens up a web server).

I think your idea is not necessarily wrong but it would be hard to get right, especially without making the entry into fediverse too painful for new (non-tech) people, I think that is still the number one pain point.

I have been thinking about moderation and spammers on fediverse lately too, these are some rough ideas I had:

• Ability to set stricter/different rate-limits for new accounts - users older less then X can do only A actions per N seconds [1] (with better explained rate-limit message on the frontend side)
• Some ability to not "fully" federate with too fresh instances (as a solution to note [1])
• Abuse reputation from modlog/modlog sharing/modlog distribution (not really federation) - this one is tricky, the theory is that if you get many moderation actions taken against you your "goodwill reputation" lowers (nothing to do with upvotes) and some instances could preemptively ban you/take mod action, either through automated means or (better) the mods of other instances would have some kind of (easy) access to this information so that they can employ it in their decision.
  This has mostly nothing to do with bot spammers but instead with recurring problem makers/bad faith users etc.
  Though this whole thing would require some kinds of trust chains between instances, not easy development-wise (this whole idea could range from built-in algorithms taking in information like instance age, user count, user age and so on, to some kind of manual instance trust grading by admins).

~

All this together, I wouldn't be surprised if, in the future, there will eventually be some kinds of strata of instances, the free wild west with federate-to-any and the more closed in bubbles of instances (requiring some kind of entry process for other new instances).

[1] This does not solve the other problem with federation currently being block-list based instead of allow-list based (for good reasons).
One could write a few scripts/programs to simulate a federating instance and have tons of bots ready to go. While this exact scenario is probably not usual because most instances will defed. the domain the moment they detect bigger amount of spam, it could still be dangerous for the stability of servers - though I couldn't confirm if the lemmy federation api has any kind of limits, can't really imagine how that would be implemented if the federation traffic spikes a lot.

(Also in theory one could have a shit-ton of domains and subdomains prepared and just send tons spam from these ? Unless there are some limits already, afaik the only way to protect from this would be to switch to allow-list based federation.)

Lot of assumptions here so tell me if I am wrong!
Edit: Also sorry for kind of piggy-backing on your post OP, wanted to get this ideas out here finally

There is a simple trick, as a basic user, do not ever run your (gnome) file explorer as root and if a permission error (requiring "escalation") pops up you shoud double check what you are doing.

I think most graphical file mangers also keep most of the weird/important/system folders away from user and you have to directly navigate to them.

In this case, yes anything under /run should not be considered as normal files.

https://serverfault.com/questions/24523/meaning-of-directories-on-unix-and-unix-like-systems

• /bin - Binaries.
• /boot - Files required for booting.
• /dev - Device files.
• /etc - Et cetera. The name is inherited from the earliest Unixes, which is when it became the spot to put config-files.
• /home - Where home directories are kept.
• /lib - Where code libraries are kept.
• /media - A more modern directory, but where removable media gets mounted.
• /mnt - Where temporary file-systems are mounted.
• /opt - Where optional add-on software is installed. This is discrete from /usr/local/ for reasons I'll get to later.
• /run - Where runtime variable data is kept.
• /sbin - Where super-binaries are stored. These usually only work with root.
• /srv - Stands for "serve". This directory is intended for static files that are served out. /srv/http would be for static websites, /srv/ftp for an FTP server.
• /tmp - Where temporary files may be stored.
• /usr - Another directory inherited from the Unixes of old, it stands for "UNIX System Resources". It does not stand for "user" (see the Debian Wiki). This directory should be sharable between hosts, and can be NFS mounted to multiple hosts safely. It can be mounted read-only safely.
• /var - Another directory inherited from the Unixes of old, it stands for "variable". This is where system data that varies may be stored. Such things as spool and cache directories may be located here. If a program needs to write to the local file-system and isn't serving that data to someone directly, it'll go here.

We’ve consolidated all our code into a single repository – just clone ente-io/ente on GitHub, and you will have at your disposal a state of the art, end-to-end encrypted, full stack (mobile/web/desktop clients, the server, and a CLI to boot) alternative to Google Photos and Apple Photos.