451–460 of 556 posts
Well I like the "workaround" that Microsoft proposes for a limitation of Windows that shouldn't really be to this day. UNIX resolved this decades ago: the filename is just a link to a structure on disk. You can delete a file even if it's used, since the file is there but you only delete the reference (filename pointing to the inode) that it has. Programs that have the file open can continue using it. When the file is…
Well I like the "workaround" that Microsoft proposes for a limitation of Windows that shouldn't really be to this day. UNIX resolved this decades ago: the filename is just a link to a structure on disk. You can delete a file even if it's used, since the file is there but you only delete the reference (filename pointing to the inode) that it has. Programs that have the file open can continue using it. When the file is…
I still long for the approach many software used on the AmigaOS - the app is a folder, the folder has the main exec and any assets it needs (libraries, images, etc.) and documentation and... That's it. Install? Copy the directory to where you like. Uninstall? Delete the directory. And if you wish you could keep any files used/generated with such an app in the same folder, making it 100% self-contained. I remember bei…
And for legacy/backward compatibility reasons, once MS allowed this behavior to go unchecked, there was no way to put the genie back in the bottle and stop it, without giving up backward compatibility. It didn't help that Microsoft software tended to be the "tentacle" kind as well.
Earlier quoted context omitted.
I mean all Linux package managers allow running arbitrary code on install/uninstall and it seems to work well enough.
It has also failed enough times for me, but luckily it often works like "on error resume next" do the package manager doesn't get stuck in a bad state. Regardless, installation on Linux is often just dropping some files somewhere and perhaps a modprobe. In Windows you have so many things you can do: filesystem, registry, COM registration, GAC, file associations, etc.
registry -> dconf
com registration -> dbus objects
gac -> shared libs
file associations -> dconf settings
windows scheduler entries -> systemd user sessionWell I like the "workaround" that Microsoft proposes for a limitation of Windows that shouldn't really be to this day. UNIX resolved this decades ago: the filename is just a link to a structure on disk. You can delete a file even if it's used, since the file is there but you only delete the reference (filename pointing to the inode) that it has. Programs that have the file open can continue using it. When the file is…
Under Linux, I have occasionally had the challenge of figuring out what process is holding open a large file that has been 'deleted'. This starts with recognizing that you're getting disparate values from different tools you might use to look at disk utilization. It's confusing as hell the first time you run into it without some established context as to why that might happen.
On deletion of a file that is open by another process, Linux does not warn me about that. Windows will give me a clear error message that the file is open by another process. Linux chooses to let the problem sit because it might just take care of itself once the process ends, but that decision kinda sucks when your disk is full and you're scrambling to get some space back. Windows forces me to deal with the conflict right now. That adds work in some cases while avoiding the confusion and risk factors of multiple perspectives about a volume's utilization.
It's not "Widnows (sic) doesn't get it". Windows made different choices. As another comment expressed, Windows has all it needs to do this at the FS layer, but chooses to use OS locks on top of that.
Earlier quoted context omitted.
> Any open file Any file that was opened without specifying FILE_SHARE_DELETE in the call to CreateFile[1] (the Win32 equivalent of open(2)). Unfortunately, most language runtimes that wrap CreateFile tend not to pass that flag. [1] https://learn.microsoft.com/en-us/windows/win32/api/fileapi/...
indeed - also reminds me that languages like go[0] and java[1] did disagree to even attempt using it [0]: https://github.com/golang/go/issues/32088#issuecomment-53759... [1]: https://bugs.openjdk.org/browse/JDK-6607535 So to me it's just not there...
While full Unix-like behaviour is only available on Windows 10 for the past five or so years, you can still have the old win32 behaviour on older systems (delete once the last file handle is closed).
Earlier quoted context omitted.
Everyone is pointing at Windows but there are still installer software on MacOS. Normally crusty old corpoware like Citrix that needs to extend its tentacles to the whole system. 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.
> On Unix/Linux land the prevalence of pipe curl to bash type installers is not much different. This is a problem but only if you install software on Linux by manually going to the project page and copy-pasting whatever curl they have there, I think the difference is that mostly you're encouraged to go the package manager route, whereas on windows downloading .exes directly (ala the curl example) is the norm.
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…
Of course, a decade later almost nobody uses those because they botched the rollout by limiting AppX to the Microsoft Store and an entirely new poorly documented and very restrictive set of windows APIs and app frameworks. They've made huge progress on all of those problems with MSIX to the point that it's a reasonably good and easy to use choice for most apps with some neat benefits like updates only downloading the changes between versions. Of course if your app pushes the boundaries of the sandbox or capabilities or runs into a bug it becomes a huge pain.
Earlier quoted context omitted.
Once you move past comparing hashes against known malware (by definition useless against novel malware), and the slightly more complex matching of specific binary strings, detecting malware with "shitty heuristics" is basically all we've got. Companies that buy AV/EDR products expect them to detect unwanted behaviour while allowing any sort of weird, hacky, abuses of the system that they rely upon for their business.…
The first point is true i admit. There are very complex and good ways to identify stuff but those perform so bad they cannot be used in practice. AV/EDR products do try to prevent a lot of stuff. They can 'generically' block things like injection etc. by 'hooking all the things' and injecting into everything (yes, yuck :D and still kind of heuristic based i admit!) to make certain sections read only or remove executa…