If you have flatpak, and the application don't need full user home access, then you can move the folder to application sandbox by setting a persistent path.
Linux is confusing for non IT people looking for program settings. It might be in share, local or config or hidden somewhere. On W 10 I just look under ProgramData. Maybe W11 is different. But Linux application devs need to agree on a single place. As users sometimes need to access it for plugins and resources.
You mean the 2 ProgramData folders? Altho who the hell puts config stuff there? Anyways, the 2 official settings apps, the 3 AppData folders and then the registry for every little thing Microsoft doesn't want you to edit for whatever reason? And then the countless 3rd party config apps for every device aiming to make this process easier? Yea I totally don't Google where to toggle stuff on windows as step #1, noo... And W11 just has a slightly better 2nd official settings app, so sadly not too different.
Also who the hell puts config stuff on Linux into /local or /share? It was always in ~/.config (personal) or /etc (system wide) from my experience.
I feel mildly aroused when I see a program or a game that collects everything in it's folder and can be used from a USB drive. Some paid, industrial grade software leaves so much traces and depends on so much different hidden files and keys it's making me sick.
Or if you just symlink /usr, /opt, and /home to that usb drive. You may be asking why you wouldn't just mount partitions on the usb drive to those locations. This is not a question I will be answering
That is good... unless you plan on sharing the app between users, then it sucks, because every user has to be an admin in order to change the config... and then, you have one user that sets it like so and so, and another that sets it completely different. And this is why separate settings for users is a good thing. Sure, have an option for a global config, and let that copy be copied to the local config as sane defaults, but not having the option to actually have separate configs in user directories is, from an IT perspective, insane.
Always remember, C:\ProgramData is the eqivalent of /etc in Linux. If they don't know where to put/hide shit, but needs admin priviliges to edit and users can only read, you put it in C:\ProgramData.
Config files that are meant to be used as sane defaults for new user accounts, yes. Config files that are meant to be manually edited, no.
Besides, there are a lot of examples of configs that are saved in ProgramData, like, let's say, registration info for proprietery programs (of course, this info needs to be shared amongst users, so your safest bet is ProgramData). Hidden by default, makes it perfect for storing everything the program is trying to hide from the user.
Don't forget that there's a hidden system junction at C:\ProgramData\Application Data that points to C:\ProgramData. Because everyone loves loops in their filesystem. Of course C:\Users\All Users is also a junction to C:\ProgramData. This kills updatedb in WSL.
Game save data? No, my documents.
Application config files? Again, my documents.
Temporary documents I don't care about keeping? Downloads, duh.
My actual documents? Desktop.
My desktop? Turned icons off because it was too messy.
Or if you still want a start menu, Start11 is worth paying for to get away from Microsoft's ad-ridden crapware they call the start menu. It even supports using Everything for showing file results.
Agreed, but the number of places where to search for the config is not as big as in Windows. And there is the fact that most software is open source, so you could always check where the application saves it's data.
Don't forget %USERPROFILE%/AppData/Local/Programs, where some programs get installed to because the developer doesn't want to make it a system wide installation.
This should be considered a war crime, and doubly so when they don't even have the decency to prefix it with a dot (looking at you Golang). It's my home folder, not a dumping grounds for random trash.
Or in /etc/<application>, or in /var/<application> I've seen all of that, sometimes differing between distributions for maximum annoyance. So I don't think we get to act smug in I'm this particular case.
For Linux applications that respect XDG? Sure. There are plenty that don't because they either predate that specification, or they just don't care. Linux filesystems are generally much faster at executing reads on many small files, meaning fast search tools like ripgrep and fd make it so I don't really have to care. They'll run through my whole $HOME in 5 seconds flat. There's also stuff like locate, although I don't like maintaining an index. SSDs are so damn fast that I can just rg --hidden --glob '*.toml' 'the_setting_i_want_to_change' ~/ whenever I want.
Let's not pretend regedit is a good thing, it is littered with unreadable keys and has terrible UI and UX. And it requires root privileges to edit anything.
I believe one of the worst disservice Windows has done to secure computing is to make users desensitized about root privileges. Every single action you do need root privileges, install app, changing config, people would just click allow whenever UAC pops up...
This means any program can easily inject rootkit into Windows during install, without the users noticing a thing, like LoL.
You don't need to use sudo command that much on linux. I personally only need to use it to edit two config files when setting up my system, that is it.
One for pre-connection mac randomization, one to enable a kernel module I need, because my distro disable many of them by default. I am very conscious of the changes I am making. However on Windows, I have no idea what the app installers are doing.
Not to mention, most users don't even need to make these changes. Per-network randomization is likely good enough for most user, and they probably not on a security-hardened distro which disables tons of kernel modules.
For a office work and entertainments, flatpak apps are more than enough. And developers can choose to get their sdk via flatpak or podman dev containers. None of them requires sudo.
Is there a good reason for a everyday user (not a tinker nor a system admin) to use sudo in linux?
I believe offline upgrade is also the default on every OS out there, for example gnome software only installs updates offline.
Even if you have to use sudo to upgrade (or journalctl, dmesg, both are sysadmin tasks and not typically done by a normal user), you are still only giving root privileges to these trusted programs distributed by your distro, not some random installers on the internet, unless you are using AUR.
I am genuinely curious what other commands with sudo that you need to run on a daily bases, for tasks that is unrelated to system administration?
Except when you install something on linux package manager of your distro is executed as opposed to installer that was made by developer of package you are installing. And you probably install install packages from your distro's repos, unless you are on Debian of course.
Or you can run package manager as user that usually installs in ~/.local. Or unpack yourself.
Package managers have post install scripts and hooks that would allow you to install a rootkit. Then again they can also just add services on many Linux systems, which can run as root. Just put a systemd unit file in the right place and enable it.
The security advantage of Linux is having trusted repos and using things like FlatPak. System packages being malicious would very much be able to infect a system. Just look at the XZ backdoor for an example.
HKEY means "handle to registry key"... Not that that helps anything.
When code opens a file, device, etc, it's given a "handle" to it, which is an internal reference so that Windows knows which file you're reading or writing, and it keeps track of where you are in the document. Similarly, HKEY_CURRENT_USER is the handle that gives you the current user part of the registry.
I know that, the HOTKEY_* part of it was a mystery, why is the key hot... I mean, why does HK have to stand in front of it, it could be simple like just LM, CU, U (Users... still does nothing and nothing in it gets transfered as a setting in new user accounts), CR, etc.
Huh... I don't know where I've read this a long time ago, but I could swear it was HOTKEY, not HKEY... your explanation does make sense though, while what I thought never did make sense.
What the fuck is local low? I don't understand. Local is Billy G's jizz... I get that... And Roaming is for poor plebs. But why LocalLow? Is it like cache? But I have seens games saving their save files there. I don't understand
Roaming: this data can be moved between machines in a domain if you have a roaming profile. E.g. go to another workstation and your browser configuration is the same? Means it's in Roaming.
Local: this data will not be synchronized between machines when you roam. This could be your browser's cache.
Has anyone tried this, any software who has the path hardcoded?
I know for certain that some Adobe products did have these paths hardocded (past tense, haven't tried this now), because I moved my home/user directory on D:, yet they persisted to save the settings in C:\Users.
And half the time you'll find it in the registry too. Linux has proven quite well that an OS doesn't need a registry.
Oh, and what's with ProgramData and AppData being two completely different things. I understand the difference between the two directories, but there is no difference between a program and an app. Everywhere else it's Machine/User.
Linux has proven quite well that an OS doesn't need a registry.
Gnomes dconf would like to have a word with you.
It's really interesting how the Gnome people seem to get rid of every useful feature as it might confuse the user or be complex, but on the other hand add this registry-like anti-feature to make the system just as unmanageable as Windows.
Nowadays, yes. Go back 15+ years, the registry was used extesively.
My reasoning as to why, Linux was never a targeted platform for software back then, now it is. There was only GTK back then and it didn't look "nice" (appealing) at all. Plus GTK apps were huge for Windows, since you'd have to also install the GTK runtimes and all that... that just took a lot of disk space, which was expensive back then. Compared to an app that does the same, but spends only 10% of the disk space needed for GTK (you could even go a lot lower with compressors), it's obvious why GTK was never a viable option when making a GUI app.
And since Linux doesn't have a registry (or even if it did, it'll probably be completely optional to have it or not, so you can't rely on users having it installed), you'd have to just save the settings in a file, just like the rest of the FOSS applications. So, it makes no sense to have completely different codebases for the same app for Windows and everything else. In fact, most apps nowadays that aim to be cross platform just use Qt. You can compile it for watever you like, there is no need to keep separate codebases.
ProgramData is for admin stuff and things that need to be shared between users. AppData is for personalized settings per user. For example, AnyDesk stores the unattended access password in ProgramData, as well as the ID. Sure they do get copied to AppData when AnyDesk runs on boot/login on any user, but you could also have some user specific options (like language) and they get stored in a separate file in AppData.
there is no difference between a program and an app
Yeah the naming is confusing. The reason is what you said - machine vs app.
Back on Windows 9x, some apps would store files directly in the C:\Program Files directory. This was 'fine' at the time since every app ran with full permissions. Users were at C:\Windows\Users, but users were optional so not every install used it.
Windows XP had a better NT-based permission model (not nearly as improved as Vista, but better than 9x) and allowing regular users to write to the Program Files and Windows folders wasn't really a good idea. It added two directories for settings:
C:\Documents and Settings\username\Application Data for user-specific data
C:\Documents and Settings\All Users\Application Data for non-user-specific data
Vista kept the former but moved the latter to C:\ProgramData. I can't remember why.
Most configs should be in the roaming directory, since you'd usually expect them to roam between computers on a domain. The local directory is only for stuff that doesn't make sense to sync to other computers - things like caches, configs specific to that individual PC, etc.
Not that it matters for home users, as home users generally aren't using Active Directory with roaming profiles.
Have you found appdata/local/Application Data? It's a "conjunction point" that you can only find via the command line, and only exists for backwards compatibility. It points to appdata/... Do not EVER try to gain access over all your files in appdata/. It'll break due to that conjunction point.
There are symlinks in Windows all over the place for backwards compatibility. Just look at "Documents and Settings", it's a symlink to ”Users".
Yet, you still have to install the same libraries with every app over and over, even though they can be shared. Why? Because Windows has no sense of default library locations, except for the things it absolutely needs to work.
Oh that setting is super easy to change, just go to run, type in regedit, expand HKEY_LOCAL_MACHINE then just scroll until you find CLSID-73838-abf83-c758d57-87a90ba, set the value to zero and reboot!
Probably just log in an out, but still, I fail to see how this is easier than changing some_bool_setting from =true to =false is harder... maybe because you actually know what you're changing, so that makes it scarier 🤔.
