Showing all 126 replies.
>>
>>108986832
fym? I unpack tar.gz in whatever directory I want and it runs. rarely do I ever come across hardcoded at compile time $PREFIX programs.
bonus: I don't have to click "agree", "next", "next", "next", "next", "install", uncheck "also install our toolbar", etc.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>108987190
That (obsolete) usecase comes from the Windows XP era when programs would bundle a fuckton of DLLs. This is because you couldn't overwrite the system DLLs as XP prevented you from doing so, to address the "DLL Hell" problem with the Debian-style approach.
I kinda get it though, since those times were comfy.
>>
>>108986832
I agree that installing has ever only been a thing in Windows, and Mac (I assume, not sure what that drag and drop install thing actually does).
But there's more to it. What's the point of having your exe and data where you want if all the logs, settings, etc are in some random %appdata%/User/user-but-for-real/ActualUser/My Documents/Documents My/Program...
The real answer is that we needed sandboxing per program from the beginning. No writes outside exe folder unless user explicitly approves.
>>
>>
>>108987500
>not sure what that drag and drop install thing actually does
Apps on macOS are just folders that end with .app in the filename and Finder (the default file manager of macOS) simply interprets these folders differently, as launchable programs as long as the structure inside that folder is correct. Drag and drop just copies that folder into the /Applications folder
>>
>>
>>
>>108987190
I like to keep all my programs on my storage drive, while my OS is on the boot drive. That way, whenever I want to change the OSes installed on my computer, I don't have to back up and restore all my files. Instead they're just there.
>>
>>
>>108986848
>>108987142
Installing a program on Windows also potentially creates registry entries and moves shared DLLs around
>>
>>
>>
>>
>>108988257
>run application anywhere
>the application puts random shit to an obscure directory in .local and thousands of weird files in /var and .cache (it won't ever clean up after itself BTW)
nice freedom bro
>>
>>
>>
>>108988257
>>108987500
Whether a program on windows installs files in those places is entirely up to the developer, so blame them. Vast majority of windows applications are completely self contained and don't write any files outside their install dirs.
>>
>>
>>108986931
Everything should be in C:\Program Files since that can't be altered without admin permissions.
I wish Windows also had a system where programs could protect their user data so that only they (identified by either their path or certificate) can read it. It's incredibly retarded that any program running as your local user can steal any data from other programs, including your web browser. The fact that infostealers are possible is such a colossal fuck up.
At least let programs opt into having their data protected.
>>
>>
>>
>>108987500
>>108989084
there's a windows program that fixes that: sandboxie.
and for linux, there's firejail.
>>
>>108989090
The program can't protect the data because the OS doesn't let it. That's exactly the kind of API that's missing.
The only thing it can do is ask the user for a password, then encrypt the data on disk manually (or using DPAPI). Why does nobody do this? Because no one will want to use your software if you make them put in a password every time.
At least macOS has this figured out with its keychain.
>>
>>
>>
>>108989114
This works well for trivial programs. But for more complex programs that need to register services or scheduled tasks, or an event viewer source ,write registry keys, register shell extensions, register a driver etc. that's a bad idea.
Using a proper installer also lists your program in the add or remove programs applet. Which, unlike a mere deletion, will also remove all the components the installer added.
>>
>>108989084
>Everything should be in C:\Program Files
Why do linux/macfags either hate or are completely ignorant about setups with more than one hard drive? Are you really running computers with only one storage device in 2026? Even my laptop has 2 nvmes
>>
>>108989145
Because users are retards and will not set the proper ACLs for a "Programs" directory on another drive.
Programs tend to be rather small (the exception being bloated business software and Electron trash) so IMO it's just wrong to install them outside the OS partition. That's where they belong.
>>
>>
>>108989138
there's nothing that prevents a very serious, complex program from registering whatever shit it needs on first run, but working without installing is seen as a non-serious, un-business-like feature.
>>
>>
>>
>>108989252
What, you still have the freedom to do it if you want.
You're most likely retarded and doing it wrong if you do it, but you can.
That's how a good OS works. You can make shitty decisions. That's what freedom is about.
>>
>>
>>108989273
I'm sure users would love that. Imagine installing a music player and every time you close it, it unregisters itself as a handler for .mp3 files etc.
Do you create Linux software or where do these ass-backwards opinions on software design come from?
>>
>>108989294
user choices like file associations are not owned by the program. the program can only suggest them.
I've been enjoying the concept of "portable software" for quite a while on windows before ditching the platform altogether and moving on to enjoy it on linux.
>>
>>108986913
Sometimes. It depends.
1. Install from distro package manager to system paths.
2. Install AppImage in path of my choice, usually symlink it to $HOME/bin.
3. Compile and install to any directory I want.
4. (Variant of 1) snap or flatpak
5. docker/podman/singularity container
>>108986891
>installing
Honestly I've hated this since the 90s. "Please watch this progress bar while I write a bunch of shit into your system directories and registry that you don't know anything about." Windows apps that shipped as a standalone binary that you could just run were always superior.
>>
>>108986902
This.
On linux there's some reasonable history around why (distro organization, security, etc), but linux package managers still include features like "show me all the files installed by this package" and "which package owns this file."
>>
>>108989294
Imagine installing a music player not realizing that it was going to make itself the default music player without asking permission. So when you uninstall you are just fucked and have to go fix it manually (which you don't know how to do because you're a wintard who thinks the point of a computer is know as little about it as possible and only use it for what a software vendor permits you to do)
>>
>>
>>
>>
>>
>>108989058
>Vast majority of windows applications are completely self contained and don't write any files outside their install dirs.
If that were true then portableapps.com wouldnt exist. Almost all Windows programs save shit to AppData
>>
>>108986832
It's fake freedom because almost no installers actually respect the meaning of changing the path. They still require admin elevation, they still write hklm hive or even worse hkcu for the admin account.
At that point, what is the point of choosing the install directory? You're just wasting time.
>>
>>
>>
>>108986931
>copy linux and start installing shit and having programs store data in the users directory.
that's not a linux thing, no package manager on linux does this.
the reason this started being a thing was to avoid needing to be an admin to install something. if anything this is something from windows that has started to affect linux (namely things like steam and gog install games to your home folder, which was copied from how they did it on windows)
>>
>>108986832
If I need it in a specific location I clone the repo and build it. Anything I'll need/want in a specific location will be something I can that with.
Plus Linux file system structure makes more sense than windows now that I've been using it for close to a year.
>>
>>108986832
>>108987256
I use Linux but I agree, I really want this. The core system, most of the root directories should be immutable. Except on linux you're always removing and adding packages just to do basic things and the more packages you have the more tinkering you have to do for it to work right.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
File: 1776109741324692.png (205.1 KB)
>>108986832
Works on my machine
>>
>>
>>
>>108986848
>bonus: I don't have to click "agree", "next", "next", "next", "next", "install", uncheck "also install our toolbar", etc.
it's funny since MSIs should be installable silently, but of course discovering the args are another humiliation ritual in Windows.
>>
>>
>>
>>
>>108992955
how?
Windows is objectively worse in every way in this category.
You need some shitty tooling just to build an MSI, (Orca, NSIS, WiX, some other faggy nonfree shitware). Debs are just tarballs with metadata, RPMs are weird, but aren't a massive leap to make: mostly cpio and meta. nix flakes heem all of them to oblivion.
let's also add insult to injury, you don't even have a decent %PATH% story outside of %windir%\System32. Hope you like finding out the env block length limits adding all those misc %ProgramFiles% paths to your %path%.
>>
>>
>>
>>
File: 1756060952216530.png (18.9 KB)
>>108986832
You're a retard making a false equivalency, here's how it is:
>installing a redistributable package like tar.gz or appimage
Sure you can unpack wherever you like it, exactly like a .exe on windows
>installing packages through a package manager
I'm sure some of them allow for a PATH variable of sort situationally but as a rule of thumb you have to set a installation path for ALL packages managed, exactly like on windows if you use winget or chocolatey
>>
>>
>>
>>108986931
100% true
>>108993017
literally all linux garbage
>>
>>
>>
>>
>>
>>
>>108993892
>literally all linux garbage
as a long time linux user i don't know what any of those are. except msi, which was a failed attempt by microsoft to unify the installation of programs on windows (like what linux distributions do)
you could argue "linux" (meaning all distributions that use linux) collectively don't have one method for installing things, but these have the excuse of being different systems entirely. windows doesn't have that excuse. you yourself agree with this list of all these different things and yet these are all just for one system; windows. and yet you blame linux for this?
this is a new angle for me; blaming linux for the faults of windows. i guess that's just a sign of the times of linux becoming more popular.
>>
>>
>install linux
>install steam
>plug in drive (separate drive only for vidya)
>games dont show up
>spend 30 minutes looking up the solution
>need to mount drive
>mount drive
>games show up in steam library
>everything works
>turn off pc for bed
>use it the bext day
>drive is unmounted again
>look for solution
>permanent mount on boot
>do that
>game wont launch
>try another game
>wont launch
>hours worth of research
>turns out i need to reinstall steam .deb version cause Linux installed flatpack version or some shit
>do it again
>set everything up
>play for 30 minutes before bed
>turn off pc
>wake up next day and turn on pc
>games not showing up
>steam is the .deb version
>drives are mounted
>reinstall windows 10
>everything works
useless piece of garbage "operating system"
>>
>>
>>
>>108986913
you should in case you want to see what is going on there and what goes where and to hook up all monitoring to everything in there
many programs come like that outside of the repo too e.g. blender
>>
>>
>>108986832
GNU/Linux is an admin system, Windows is for
home users. Everything has it uses depend how you use it.
Another inconvenience in Linux is how you cannot install packages offline so if there is no internet, You cannot run software installers.
>>
>>
>>
>>
>>108986832
Windows has a registry so it just knows where shit is installed regardless
Linux doesn't use a registry and leaves finding programs up to distros, which make it way less flexible, especially when dealing with the absolute hive that is the FHS
>>
>>
>>108997238
I think he meant Synaptic itself (Debian based distros). On top of that there are couple of dependencies to solve. If all packages would be put in one location like a CD and updated regularly it would fix issues. It has been too long since I checked. My bad.
>>
>>
>>
>>108986832
This is really the thing I hate about Linux, every single architecture and distro and package stores its crap scattered all over the filesystem with no rhyme or reason. Windows developers have some inconsistency but worst case is a tossup between My Documents and AppData looking for shit. Meanwhile linuxshit will just scatter all its own internal files into a hundred different system directories, /etc/ and /opt and /var and god knows what else, merging with every other program that does the same shit
>>
>>
>>108997457
>scattered all over the filesystem with no rhyme or reason
except there is a rhyme and reason to it. resources are placed in specific places based on what kind of data they are, which makes it easier to share resources between programs, like say if a program installs a font, it will go with the rest of the fonts rather than being buried in a Program Files folder so other programs can use the font as well. while windows does have a shared system font folder as well, programs may not put their fonts there. while it's possible a linux package may install in more of a windows way (the closets equivalent is for a program to install all its' components under a folder in /opt, which is typically only used by programs not in that distros repo such as proprietary software, as it's hard to coordinate those files with the rest otherwise), the standard in linux is to put things in specific, known, shared locations.
it's why for example if you have say, mpv installed, and you want to add yt-dlp support to it, you install yt-dlp and it'll just work, because it's executable goes into "the executables folder", which is always in PATH, same with libraries.
>>
>>108994182
>linux
>OS
You couldn't be bothered to do the slightest bit of research on the software you were installing, have 0 understanding of how a computer work and can't be bothered to learn anything, and this is somehow 'linux's fault. You're less sentient than cattle, of course you're better off using windows.
>>
>>
>>108997927
not him but assuming he's saying like "you couldmake installinstead"
and yea you COULD... but by doing so you're taking over the role of the package manager for that package, and unless you know what implications that has, maybe don't do that. except perhaps if you're installing into /opt (as is recommended for out-of-tree software)
>>
>>
File: pepe-pipe-dual.jpg (39.3 KB)
>>108986832
when using linux you need to accept that it an autistic multi-organismic entity, where each part is a reflection of the autism of the creator/s.
you need to assimilate and inject your own autism into it, bringing the install mechanics you want.
>>
>>
>>
>>108986832
I really don't care where stuff install to, but fuck, why can't they keep to their dir? Every program fucking shits their files everywhere and it's different every time.
>Can you install this program
>Yeah, let me make a dir in program files, then change your register, soil your appdata and shit a turd in MyDocuments
I get actual happiness when a program is a portable executable that keeps their stuff where I extracted them. Why can't every program do this?
>>
>>
>>
>>109002839
/etc is for compatibility with old software, even macos has a hidden /etc for compatibility reasons.
there actually is a linux distro which does a similar thing;
https://gobolinux.org/
>>
>>
>>
>>109002886
>Why not ~/apps
Because each special snowflake would decide on a different name like Apps for GUIniggers, APP for walking fossils, .apps for le minimalist posers
>>109002886
>Why can't we just define where we want to put our stuff in ourselves
You almost can, XDG_*_HOME, there's no app directory yet though afaik
>>
>>
>>109002871
they're trying to with things like ~/.config (local configuration) and ~/.local/share (local data)
but since these are relatively new, there's still a lot of programs which don't yet do this, perhaps even intentionally