I think it is very rude to just install to any "default" directory and not asks the user where he wants it to be installed.
I think it is very rude to just install to any "default" directory and not asks the user where he wants it to be installed.
Probably better to not let programs spray all over your filesystem anyway.
The proposed "random third-party program" is effectively an extension to the OS.
I used a Win10 debloater last year about 2 weeks after install. It deleted Minecraft, which is apparently a UWP too, and it deleted my world, because UWPs apparently store userdata in program directory.
This is very annoying on company machines where you may not have admin, since now there's red tape with your IT because the installer was poorly written.
Half the reason I use the WSL is because you at least get "root" on it, so permissions are never an issue
Edit: there may be something lost in translation. This post is in reference to software your IT already approves, which happens to only install to program files.
It becomes less about controlling the users and more about stopping any bad guy dead in their tracks. If nothing but what has been implicitly authorized can execute, then 99% of ransomware attacks will be stopped immediately even after the user clicks the link.
Your company software procurement process shouldn’t be so onerous that people turn to Shadow IT. You have to work with people where they are.
> The company does NOT want you installing random crap on their machines.
Why do you immediately jump to the conclusion that the post is about installing "random crap?"
The post is about requiring admin to install to Program Files. Even if it is an approved piece of software, you're still going to need admin to install it.
The installer should ask the user if they are installing for just themselves or for everybody on the machine.
If it's the former, the installation is typically somewhere under %HOMEPATH% (probably in %LOCALAPPDATA%), the latter will put it in %ProgramFiles%.
It's a feature. You shouldn't be installing software on your work computer. Your IT department should be vetting it, deploying it, and keeping it up-to date for you.
Maybe you can tell the difference between report.pdf and report.exe, but too many people can't, so unfortunately we can't let everyone install anything.
There are not enough IT staff at my organization to do this. They have an approved list of software that may be installed. Some common installations are automated, others are niche-enough that it's DIY.
We don't live in a perfect world where the IT staffing ratio is 1:20 (or whatever arbitrary number you would consider "good"), so this is how my organization does it.
> unfortunately we can't let everyone install anything.
Who is this "we?"
"Your" IT department should consider giving you your own admin account. But it's their call.
Seems like a bit of an extreme solution for one-off installations that are rare enough to not be worth bothering to automate.
Good example of this is scientific software like Gaussian (a "common" quantum mechanics package): needs admin, expensive and strict license that gets audited. It's approved, but we have a single digit number of people using it. It's just not worth the time to automate a script around an install that only happens once every year or so on average, when they can just temporarily elevate the user.
If I actually had to depend on IT to do all that, it would take forever to get anything done.
/$PROJOPT/vendor-product-version
On a Mac, I've never wanted an application to go anywhere but the default /Applications. I don't ever recall being asked if I want another location, nor would I want to be.
Is it different on Windows or Linux? And why would you want a different install location?
Of course, 90% of macOS apps (outside of the App Store) don’t have installers. You just drag the app where you want it, so it’s a moot point.
On Linux, I want to be able to choose my install location because I may want it installed on removable media, or on a different drive for space reasons, or because I want to keep executables used for a single project with the rest of the files that comprise that project.
The same things apply to Windows, but also on Windows (which I only use at work) I specifically want to avoid the use of the standard locations for things so that I don't have to fight with OneDrive about them. Putting them somewhere else means OneDrive will leave them alone.
Person_1: I found this great blogger whose writing I think you'd love.
Person_2: Oh, really?! What do they write about?
There shouldn't even be a question where to put things much less a "wherever you want". Instead you want a sane, sensible standard.
mkdir derp
gmake install DESTDIR=$PWD/derp
But I also want to be able to decide to not adhere to that standard when it gets in the way. It's my machine, there's no reason why I can't make these decisions myself.
But application files have a huge size range depending on the assets the program needs (typical sizes range from the tens of MB to the tens of GB, with large outliers in either direction). I have multiple tiers of storage (a terabyte of SSD, multiple TB of HDD, tens of TB of network storage) and allocate my software to the desired storage tier depending on my needs
And this isn't just a thing on Windows, Android does the same by allowing you to moving apps to the SD card, provided you have one. Management is just greatly simplified in that case because you have at most two meaningful storage locations on an Android location, while desktop or laptop might have any number of them
What a surprise, an anti-Windows snob comment. "I dislike 75% of the world's OS choice, so let's pretend it doesn't exist."
The operating system or application manager within the operating system (what does flatpak consider itself?) should decide where all application state goes. The application shouldn't ever prompt the user for this, it should just assume a path inside a sandbox. That path inside the sandbox will get mapped to where-ever outside the sandbox, and that's where the user exercises control.
We already see this pattern emerging with docker images. Everything assumes `/data` is a good place to store things, and `/config` is a good place to read configuration from. I want every application to do this. If I want it to store state, then I'll decide to map those to directories that are persisted.
Fine grained access to single files should be given out using a file picker. The application manager passes in a socket to the application sandbox. The application connects to that socket using a known hard-coded path. It sends a message (client->server) over the socket, the listening file picking process opens a new GUI window to prompt the user to select a file. The user picks a file and a file descriptor is sent over the socket to the application (server -> client).
If a program prompts the user for a directory instead of querying the appropriate environment variable, that is a violation of the stated user preference.
And this "we" you speak of... 1% of users? 0.1%?
ttoinou•6h ago
powerhouse007•6h ago
I feel your pain as a developer but as a user, sometimes I need the choice. Try to hide it so non-techies people can click Next Next Next but put it in advanced options somewhere.
ttoinou•3h ago
politelemon•6h ago
bigbuppo•6h ago
ttoinou•3h ago
For me for my software there's specific folders to use, it's not Program Files windows classic subfolder
breezk0•6h ago
>> don't remember about it
If you take your time to manually set any kind of new installation location, I assume you know what you are doing and will obviously remember.
>> complain to the software publisher
Changing the installation location should not break the program and if it does, its obviously a bug, or what are you trying to tell me?
ttoinou•3h ago