251–260 of 556 posts
And today I learned that Windows supports running Javascript as shell script. huh
This feature has existed for more than 25 years. My concern is more than Raymond Chen suggest that using it is still the recommended way. So much malware came through WScript.
Earlier quoted context omitted.
File permissions?
Isn't that very anti-linux though, to have a directory owned by root but populated with subfolders owned by other users? /home is the only exception I can think of that does this.
And there is no written or unwritten rule about that. In fact, /home is a subdirectory of / which is owned by root.
Why do Windows programs need special installers/uninstallers? Why isn't this handled by Windows itself?
I don't think any major desktop OS handles this well. I suspect the final form for software installation is probably where iOS and Android are going in the EU, where there's a single means of installing software to the device so that everything can be sandboxed properly, but the acquisition/update process can be pointed to a URL/Store that the user has pre-approved. macOS comes pretty close to what I'd ideally want i…
On Unix/Linux land the prevalence of pipe curl to bash type installers is not much different.
I normally keep both types away from my computers.
I keep forgetting Windows-isms that won't allow you to delete the executable file of a running process. I guess that's also why the arcane .dll upgrade process / WoW is so necessary.
Why do Windows programs need special installers/uninstallers? Why isn't this handled by Windows itself?
How could Windows handle it by itself? If it provides a framework for installers/uninstallers, it'll be fighting the inertia of decades of legacy software, programmer habits, and old tutorials. If it tracks file ownership by program, it might accidentally delete user files. How would it differentiate between a VSCode extension that should be uninstalled, and a binary compiled with VSCode for a user project? A false p…
Define a separate directory for program installations, that user processes cannot write to. Only program that can do so is the package manager, which other programs can call to install packages. Uninstall removes everything related to a program from this directory.
> In the age of shared runtimes, auto-updaters, extension marketplaces, and JIT compilers, managing installed applications is harder than ever.
The only reason these make things hard is that windows lacks any facility to deal with them. Solutions going forward: Outright ban having your own auto-updater, to auto-update you register your program and where to update it from with the package manager. Shared runtimes are trivial for package managers to handle, it's just a package that many other ones depend on. Extensions can be handled as packages.
Earlier quoted context omitted.
Why does the XDG spec have authority over software?
It usually doesn't, and it's mostly a good standards recommendation that even the most GPL of GPL codebases doesn't always follow (looking at you, emacs).
Earlier quoted context omitted.
How could Windows handle it by itself? If it provides a framework for installers/uninstallers, it'll be fighting the inertia of decades of legacy software, programmer habits, and old tutorials. If it tracks file ownership by program, it might accidentally delete user files. How would it differentiate between a VSCode extension that should be uninstalled, and a binary compiled with VSCode for a user project? A false p…
The same way any linux distro does? Define a separate directory for program installations, that user processes cannot write to. Only program that can do so is the package manager, which other programs can call to install packages. Uninstall removes everything related to a program from this directory. > In the age of shared runtimes, auto-updaters, extension marketplaces, and JIT compilers, managing installed applicat…
But what would you do with the millions of existing programs, most unmaintained? And what about programs with strong opinions on update schedules, or built-in extension marketplaces?
It's easy to solve this problem if your first step is "replace every program".
Why do Windows programs need special installers/uninstallers? Why isn't this handled by Windows itself?
One thing I like about Linux package managers is that you can query any file to see which package owns it. How does Windows not track this?
Presumably you mean something like using dpkg/apt for a Debian-style system?
I think that only works if a file is actually installed from within the framework. As soon as you've installed a file via npm, flatpak, pip, snap, specialist plug-in, standalone binary, that ancient program you had to install by hand, or one of the other squillions of ways of getting an executable program, you're out of luck and have to figure it out manually.
Earlier quoted context omitted.
How could Windows handle it by itself? If it provides a framework for installers/uninstallers, it'll be fighting the inertia of decades of legacy software, programmer habits, and old tutorials. If it tracks file ownership by program, it might accidentally delete user files. How would it differentiate between a VSCode extension that should be uninstalled, and a binary compiled with VSCode for a user project? A false p…
The same way any linux distro does? Define a separate directory for program installations, that user processes cannot write to. Only program that can do so is the package manager, which other programs can call to install packages. Uninstall removes everything related to a program from this directory. > In the age of shared runtimes, auto-updaters, extension marketplaces, and JIT compilers, managing installed applicat…
(which means that if you don't trust a provider, not only it's not safe to run the program, but it's also unsafe to install it)