@blakeyrat said:
@ais523 said:I thought only Administrators could write there? Or did I pick the wrong folder? I was talking about the known folder in which programs store their read-only data files.
What huh?
Programs store their read-only data files in Program Files, generally. You want them in a place where every user can access them, and since they're read-only it's harmless to have them in Program Files.
Roaming AppData is for read-write configuration files. (Roaming means these files can "roam" over an active directory to another physical PC if needed.) Each user has their own Roaming AppData
Normal AppData is for read-write caching, basically files which if deleted won't impact your program. (The perfect example of this is a web browser's cache. You don't want it to roam over the network, and deleting the files is harmless.) Each user has their own AppData
Ah right, sorry, in that case I just got the folders muddled. The reason for the confusion is that on Linux, there are separate known-location-equivalents for executables (which depend on the architecture), and read-only data files (which don't), both of which are read-only and centralized. The reason is that if you, say, have a 64-bit and 32-bit version of the same program, they can then share their data. Or you can share the read-only data files over NFS even if you have a bunch of programs running different architectures.
I agree with your clarification, and am sorry about the disconnect. I assumed that AppData was the equivalent of /usr/share, when it seems it's actually the equivalent of /home/username/.cache (non-roaming) or /home/username/.share (roaming). And /usr/share and /usr/bin are both lumped together as Program Files, it seems.
@blakeyrat said:
@ais523 said:
Most commonly, over a remote-desktop-like functionality, except that the target user is highly locked down and doesn't have permissions to anything other than the files used by one application.
What does this MEAN!
So it's Remote Desktop-like, but it's not Remote Desktop. So what is it? Knowing that is kind of critical to being able to answer the question. For example, if you're using VNC instead of Remote Desktop, then the remote user does not get their own individual user account, and all remote users would be sharing the same settings.
In my case, this is a command-line program, and the program in question is a service that accepts commands from arbitrary people over the Internet, provides them to the program's command line, and then sends the results back across the Internet. This is effectively a command-line Remote Desktop. (You could even use telnet for the purpose, in fact. Just imagine it's telnet except vaguely secure.) The service has the same permissions as the program; it runs under an account that basically doesn't have permissions to access anything, all it can do is run one program. (I know that Windows' permissions system is entirely capable of implementing this.) Being a service, it's running from boot time, so has no separate "log in" stage, and thus the login process doesn't need to be able to complete normally.
@blakeyrat said:
@ais523 said:(Sometimes it'll be a web interface instead, that's in a separate executable written for the purpose.)
Now I'm even more confused. If it's running in a web server, it's a completely different app you need to handle like any other web application.
A service with a web interface is just a webserver. So it's much the same as a service with a network interface.
@blakeyrat said:
Right, and Windows has System/System32 which is used by the OS and Program Files which is for stuff installed by the user/admin. The difference is that you can't install into System/System32 because why the fuck would you be able to? Why would this be something you need to tell the OS at install time? If the OS manages the programs in /usr doesn't it already fucking know that? It can just set the permissions when the OS is installed to disallow it! (And also: why the fuck would the "programs managed by the admin/user" be in a subfolder of "programs managed by the OS"... how does that make any sense?
I think there's been a communication problem here again. On Linux distributions, you normally install via package managers (which, basically, download and run the installer for you), which is part of the distribution (which corresponds to the OS; Linux the kernel has no concept of package managers, but it's only one component of the distribution). These install into the main /usr hierarchy. You can also install programs by either running the installer by hand, or (if you feel like it) copying files into the /usr/local hierarchy manually; in both cases, the files end up in /usr/local (which is important, because otherwise the package manager might overwrite them).
As for why /usr/local is a subdirectory of /usr, this is indeed a WTF (although not as much of a WTF as the reason the directory is called /usr in the first place). It's worked around in practice (the package manager knows that /usr/local is special and doesn't touch it), but it would definitely be possible to do better. (There was something of a campaign to use /opt for the purpose instead, but that lead to some sort of bureaucratic process with the result that nobody really knows what /opt is for, and in my experience, it normally seems to be used for programs that were ported directly from Windows and nothing else.) The way in which the home file directories start with dots is also a WTF, and again for stupid historical reasons (Windows' approach, in putting things like AppData in the directory below Documents, is a lot more sensible).
@blakeyrat said:
So if you know it's broken, fix it.
I'm talking about other people's installers here, which are broken on Windows. (What this thread is notionally about, in fact.)
@blakeyrat said:
Hey answer a riddle for me. If you go into your stupid-ass Linux build process and set the dash-dash-prefix to something like "my app" does it fail there too? I bet it does. I bet it's fucking broken on its native OS. But I'm too lazy to get a VM and try it.
I did just try. The installer in autoconf/automake is the most commonly used one on Linux; it handles spaces in directory names just fine (I just installed a program to a directory with spaces in). However, the programs that are actually installed often themselves have problems in such a configuration (for instance, failing to escape them correctly in command-line arguments when invoking other programs via the equivalent of Windows' CreateProcess). That said, it did fail when I tried a double quote in the directory name instead (although double quotes are illegal in filenames on Windows, so all Windows programs are either perfect or terrible at handling them depending on your point of view), and it's easy for programs using the installer to misconfigure it in a way that it fails to handle spaces (by not telling it how it wants them escaped).
My own system that I'm working on did indeed fail (it handles the spaces itself just fine, so it works in simple cases, but cannot correctly communciate them to custom build steps defined by the application; this is close, but not perfect, and not good enough). I view this as a bug that needs fixing; thank you for drawing it to my attention. It makes sense to fix this at the same time as implementing Windows support.
@blakeyrat said:
Linux doesn't even have installers. You're the first Linux user I've ever seen to even talk about installers, in a way other than telling me how much better package managers are and how I'm so stupid for not appreciating package managers and package managers solve all problems ever.
The package managers work via either a) downloading and running the installer; or b) running the installer on the distributor's system, recording the results, then downloading the results and copying them into the appropriate places. (The latter method is why you'd want to install in directory X, telling the program you're actually installing in directory Y; directory X is used to record the results of the installation.) So Linux users rarely deal with installers directly. People doing packaging for Linux, however, have to write the installers (if the installer is well-behaved, the package managers don't need much information from there, you can just tell it "this installer works like every other installer, do what you normally do" and it will work).
WRT package managers solving every problem ever, they don't; however, what they do do, is cause those problems to become someone else's (the team who administers the package database). In a way, this is solving problems from the user's point of view. Having seen what happens when they go wrong (so far, twice in seven years), they're no magical tool for making the problems not exist in the first place, and recovering from such a problem is almost as hard as it would be on Windows (slightly easier, in that all the source information is on someone else's server and so there's a limit to how badly you can screw things up).
@blakeyrat said:
@ais523 said:Or, if you installed it into a directory of its own, you can (if the installer was correctly written) just delete that directory instead, because it didn't touch anything outside that directory.
Really? How is that possible, if Linux is a multi-user system? And doesn't have any kind of non-filesystem based way of saving configuration?
The configuration would be installed into the same "directory of its own", in that situation.
@blakeyrat said:
@ais523 said:
OK, I think this almost works. The main way in which I see it failing is that it requires the executable to be on a writable disk, but systems on which people want executables on non-writable disks are rare on Windows(?) and so it probably won't be a problem in practice?
If someone goes out of their way to make a portable install, you pretty much just have to assume they kind of know what they're doing. I mean, you are 100% correct.
I don't use it myself, but apparently several people use a W^X system for disks on Linux (W^X normally refers to the practice of making sure that memory is never simultaneously writable and executable, which I believe is called DEP on Windows?); each disk either contains executable files, or writable files, but never both (and this is enforced at the filesystem level). You temporarily overwrite the "writable" flag on the executables disk to do an install, but otherwise leave it the same. Obviously, in such a case, the configuration would be on a different disk to the executable, in which case it would be awkward to put them in parallel directories (you could do it with Linux bind mounts or Windows junctions, but probably wouldn't want to). It's that sort of configuration I had in mind when I made my comment. (As well as just --prefix, most installers allow you to specify specific directories for executables, configuration, etc., so as to be able to support that practice, although that's not as ubiquitous as --prefix.)