271–280 of 556 posts
There was a bug in an uninstaller, once, that deleted all of the files on the disk. Sounds like malware to me!
There was a bug in some Linux driver installer that accidentally /usr, the whole thing.
Earlier quoted context omitted.
There was a bug in some Linux driver installer that accidentally /usr, the whole thing.
Why does a third party app have rights all files without asking? The Android app rights system integration into linux and windows is way overdue
Earlier quoted context omitted.
Thunderbird never quite used XULRunner, I think; they always built their own binary (though at some point quite a lot of the shared stuff moved into the XRE stuff). Think of it as they had a fork of Firefox (much like Firefox had a stripped down fork of the SeaMonkey stuff). Also, I think one of the Start Menus (might have been XP‽) was kind of HTA-ish? Not sure about that part, though.
> they always built their own binary > Think of it as they had a fork of Firefox Yep indeed, you are right. Notable projects using actual XULRunner included Songbird (a music player) and BlueGriffon, an WYSIWYG HTML editor (a successor of Nvu and KompoZer, themselves succeeding Netscape Composer). Both released after 2006 indeed. I liked XUL, I strongly believe Mozilla could have dominated the market taken by Electro…
Earlier quoted context omitted.
Why would you want that? If you have separate partitions, would you really want user data to go to the system partition? Or a third partition? Do you find having more places that user programs can write a benefit?
I would favor a /var/user/something directory. The fact that nobody does that is pretty much a consequence of the difficulty of coordinating multiple projects that do not have a common authority, not because it is a bad idea.
Maybe the reason no one does that is simply that no one shares your preference.
Earlier quoted context omitted.
What can you rely on then?
Uhm, for uninstallers? How about Windows Installer? If you mean in other contexts... I think the point is you're not intended to be able to do this? Outside of uninstallers, running code that only exists in RAM is... the type of thing malware typically wants to do more than anything else. But in terms of what's physically possible, I suppose there's the command prompt, PowerShell, and scheduled tasks? I'm not sure if…
Earlier quoted context omitted.
What is "it"?
Special installers / uninstallers and also the ability to install and run things outside the official OS store.
All the points you list does not need _Special_ installers / uninstaller.
Earlier quoted context omitted.
I agree with you, now for completeness I should mention that Linux package formats usually allow packagers to provide arbitrary pre- and post- install shell scripts ran as root. (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)
>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 Isn't it same for windows right now? `.msi` and `.exe` can execute arbitrary code right?
Earlier quoted context omitted.
I agree with you, now for completeness I should mention that Linux package formats usually allow packagers to provide arbitrary pre- and post- install shell scripts ran as root. (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)
The packages are cryptographically signed, you have the option to abort the install of an untrusted package before it does something malicious.
packages are cryptographically signed by the packager, by the way on Debian you add the key when you install a new repository. The signature tells you "This package has been built by X and has not been tempered in the meantime", not "X and this package are not malicious, I promise".
> you have the option to abort the install of an untrusted package before it does something malicious
How do you do this in practice?
If I run apt install p or or dpkg -i p.deb, the thing is installed. APT asks you for confirmation if it has to install additional dependencies but that's it.
I don't have no guaranty such like for any package, I can install it without worrying something bad won't happen during its installation.
Of course you should not install untrusted packages, but still. The same could not be said if the package format didn't have anything to specify arbitrary install scripts.
Earlier quoted context omitted.
> macOS comes pretty close to what I'd ideally want in an OS with regards to installation - independent packages that are certified/notarised, but I'd like to see the OS allow for user-specified authorities beyond just Apple. It's easy to run unsigned binaries/app packages on macOS: right click on the .app, hold down Option, then click Open and confirm the warning.
That is not a user-specified authority.
The closest Apple comes to this capability is achieved via device Supervision and MDM, which might be comfortable for some of us here in this forum but obviously isn’t practical beyond more technical circles.
Baddies keep ruining all the fun for the rest of us.
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…
In the same way 'Linux' (in the widest sense of the term, i.e. Linux distributions like Debian) handles this. User data is not touched by the (un)installer, configuration files are checked for changes from the package default and left alone unless explicitly purged. Files which do not belong to any package are left alone as well so that binary compiled with VSCode for a user project will not be touched:
warning: while removing directory /splurge/blargle/buzz not empty so not removed
> In the age of shared runtimes, auto-updaters, extension marketplaces, and JIT compilers, managing installed applications is harder than ever.
Most auto-updaters should be disabled on systems with functioning package management - Thanks Firefox but I'll update my browser through either the package manager as I prefer my executables to be read-only for users.
Some packages - the whole Javascript rats' nest being a good example - move too fast to be usefully packaged by volunteer maintainers so those are relegated to a different area which is not touched by the package manager. Other packages - anything Python fits here - are such a tangled mess of mutually incompatible versioned spaghetti that they are hard to fit inside the idiom of package managers so they get their own treatment - python -m venv ... etc. These are the exceptions to the rule that package management can be made to work well. By keeping those exceptions in areas where the package manager does not go - e.g. your home directory - the two can and do coexist without problems.