4 ms·

How could it not? It is adding software to the system software set, accessible by all users of the system. And many programs require some kind of integration i

How could it not? It is adding software to the system software set, accessible by all users of the system. And many programs require some kind of integration into the OS, such as file type associations or context menu entries, which even a single user shouldn't have access to do.

doophus 3y ago
Most software installers on Windows offer the user a "Install for this user"/"Install for all users" option, or will just install to the current user's appdata, which doesn't require admin rights.
- pjmlp 3y ago
  Not the case for ImageMagick, there are some things that cannot be installed for current user, like Windows services or specific kinds of shell extensions.
- tsimionescu 3y ago
  It's definitely not "most". It does happen, but it's actually very rare. Most people nowadays who go to the trouble of making a native installer do so because they want some kind of OS integration, so it's a nonstarter anyway.
Too 3y ago
This way of working should have been left behind in the previous century. Sandboxing should be default. Associating file endings should be a suggestion to the OS, accepted by the user, not something only configurable by delegating full super admin to third party app. Slow loading context menus where every app tries to claim its presence. Thank you for reminding me why I don’t use Windows since years ago. A image editor should only need to load and save images I ask it to, no other system integration. iOS, Android and the browser has proven it is possible. Now the desktop needs a similar journey.
- withinboredom 3y ago
  > Sandboxing should be default. Please no. There are valid reasons to NOT sandbox, and in Windows there is sandboxing in default (windows store apps) and there are often issues with those versions of the software. For example, Slack downloaded from the windows store uses 30-40% of your CPU while idle, but not when installed from their website. Even in Linux and using the Snap sandbox (ubuntu), there are significant issues when trying to access globally available software, which can be extremely hard to support and diagnose.
  - nolist_policy 3y ago
    The problem is that sandboxing is an afterthought on these platforms.
    - withinboredom 3y ago
      That is obvious. Like saying the "sun is yellow because it is about 4.5 billion years old." Even if sandboxing was thought about back when Linus was porting Unix, it would have been extremely slow as processors and ram was very limited back then. If we could go back in time and give them ridiculously fast processors and effectively unlimited ram like we have today, I'm sure Linux and Windows (er, DOS) would look quite different, and be much slower. Just look at how slow mobile OS's are, despite being on ridiculously fast hardware. My Palm Pilot in 1998 felt faster and more responsive than most devices today. Android devices essentially require a human to manage the memory because starting just a few apps uses almost all of it. Even iOS devices can only run a few apps before it starts killing things. Sandboxing has an extremely high cost (with not much to gain), so high that even on modern hardware you start running into physical limits very quickly: memory, disk space, and processing power. Until we can properly share resources in sandboxed apps (or increase the physical limits of the hardware) to a certain point, it just doesn't make sense to only be able to run a few things on a desktop machine.
      - nolist_policy 3y ago
        Performance has absolutely nothing to do with sandboxing. Heck you could already apply many sandboxing techniques with Linux 0.x by chroot() to an empty directory followed by setuid() to "nobody". If that process needs file access, fork() a broker process before the chroot() that funnels file descriptors over an unix socket to the sandboxed process. The broker strictly checks file access permissions of course or could even present the file open dialog to the user. This is next to no overhead in many cases (keep in mind you'll stat/open/mmap a bunch of .so's anyways on startup), except for the fork() maybe. And that can be fixed by proper sandboxing API's by the OS. The problem is that these OS's give the processes to much permissions in the fist place (access to all the user's files, ...).
vbezhenar 3y ago
There's HKEY_CURRENT_USER for a reason.
throw0101a 3y ago
> How could it not? It is adding software to the system software set, accessible by all users of the system. User-only installs are possible: > C:\Users\YourUsername\AppData\Local is intended for MSI installations for a single user but typically doesn't require Administrative privileges. This folder is normally hidden. * https://superuser.com/questions/1327037/what-choices-do-i-have-about-where-to-install-software-on-windows-10 https://superuser.com/questions/1327037/what-choices-do-i-ha... This is the variable %LOCALAPPDATA%: * https://pureinfotech.com/list-environment-variables-windows-10/ https://pureinfotech.com/list-environment-variables-windows-... See also perhaps CSIDL_DEFAULT_APPDATA and CSIDL_DEFAULT_LOCAL_APPDATA: * https://learn.microsoft.com/en-us/windows/deployment/usmt/usmt-recognized-environment-variables https://learn.microsoft.com/en-us/windows/deployment/usmt/us...

doophus 3y ago

Most software installers on Windows offer the user a "Install for this user"/"Install for all users" option, or will just install to the current user's appdata, which doesn't require admin rights.

pjmlp 3y ago
Not the case for ImageMagick, there are some things that cannot be installed for current user, like Windows services or specific kinds of shell extensions.
tsimionescu 3y ago
It's definitely not "most". It does happen, but it's actually very rare. Most people nowadays who go to the trouble of making a native installer do so because they want some kind of OS integration, so it's a nonstarter anyway.

Too 3y ago

This way of working should have been left behind in the previous century. Sandboxing should be default. Associating file endings should be a suggestion to the OS, accepted by the user, not something only configurable by delegating full super admin to third party app. Slow loading context menus where every app tries to claim its presence. Thank you for reminding me why I don’t use Windows since years ago. A image editor should only need to load and save images I ask it to, no other system integration. iOS, Android and the browser has proven it is possible. Now the desktop needs a similar journey.

withinboredom 3y ago
> Sandboxing should be default. Please no. There are valid reasons to NOT sandbox, and in Windows there is sandboxing in default (windows store apps) and there are often issues with those versions of the software. For example, Slack downloaded from the windows store uses 30-40% of your CPU while idle, but not when installed from their website. Even in Linux and using the Snap sandbox (ubuntu), there are significant issues when trying to access globally available software, which can be extremely hard to support and diagnose.
- nolist_policy 3y ago
  The problem is that sandboxing is an afterthought on these platforms.
  - withinboredom 3y ago
    That is obvious. Like saying the "sun is yellow because it is about 4.5 billion years old." Even if sandboxing was thought about back when Linus was porting Unix, it would have been extremely slow as processors and ram was very limited back then. If we could go back in time and give them ridiculously fast processors and effectively unlimited ram like we have today, I'm sure Linux and Windows (er, DOS) would look quite different, and be much slower. Just look at how slow mobile OS's are, despite being on ridiculously fast hardware. My Palm Pilot in 1998 felt faster and more responsive than most devices today. Android devices essentially require a human to manage the memory because starting just a few apps uses almost all of it. Even iOS devices can only run a few apps before it starts killing things. Sandboxing has an extremely high cost (with not much to gain), so high that even on modern hardware you start running into physical limits very quickly: memory, disk space, and processing power. Until we can properly share resources in sandboxed apps (or increase the physical limits of the hardware) to a certain point, it just doesn't make sense to only be able to run a few things on a desktop machine.
    - nolist_policy 3y ago
      Performance has absolutely nothing to do with sandboxing. Heck you could already apply many sandboxing techniques with Linux 0.x by chroot() to an empty directory followed by setuid() to "nobody". If that process needs file access, fork() a broker process before the chroot() that funnels file descriptors over an unix socket to the sandboxed process. The broker strictly checks file access permissions of course or could even present the file open dialog to the user. This is next to no overhead in many cases (keep in mind you'll stat/open/mmap a bunch of .so's anyways on startup), except for the fork() maybe. And that can be fixed by proper sandboxing API's by the OS. The problem is that these OS's give the processes to much permissions in the fist place (access to all the user's files, ...).

vbezhenar 3y ago

There's HKEY_CURRENT_USER for a reason.

throw0101a 3y ago

> How could it not? It is adding software to the system software set, accessible by all users of the system. User-only installs are possible: > C:\Users\YourUsername\AppData\Local is intended for MSI installations for a single user but typically doesn't require Administrative privileges. This folder is normally hidden. * https://superuser.com/questions/1327037/what-choices-do-i-have-about-where-to-install-software-on-windows-10 https://superuser.com/questions/1327037/what-choices-do-i-ha... This is the variable %LOCALAPPDATA%: * https://pureinfotech.com/list-environment-variables-windows-10/ https://pureinfotech.com/list-environment-variables-windows-... See also perhaps CSIDL_DEFAULT_APPDATA and CSIDL_DEFAULT_LOCAL_APPDATA: * https://learn.microsoft.com/en-us/windows/deployment/usmt/usmt-recognized-environment-variables https://learn.microsoft.com/en-us/windows/deployment/usmt/us...