>>106516742
It doesn't integrate so you don't have context menu support, file associations, etc. If you reinstall a lot, portable programs are a must.

>>106516820
There are tools that force file association even to portable applications.

>>106516865
You can still do it manually through the OS, but then it's no longer portable since it saves to the registry. To me that's not an issue since I just only care about the settings & program data.

completely destroys the narrative of the freetard eunuchs cult

>>106516742
>what is the downside?
embarrasses linux

>>106517154
But existence embarrasses them.

>>106516742
99% of applications on macos are self-contained and portable, even the ones that have an installer have an uninstall procedure that's just "delete Program.app from /Applications"

>>106516742
None.

>>106517416
So... they're NOT portable then?

>>106517436
how could you possibly arrive at that conclusion?
the .app is a folder with a manifest and all the necessary files to run the program, which can be ran from anywhere on the filesystem. copying it to /Applications is only a good practice to keep them all in the same place.
installers on macos are, 99% of the time, just a way to show the end user license, ask if the user wants to install it system-wide or only for the current user (which only changes whether it is installed to /Applications or $HOME/Applications), and to look fancy. the 1% are drivers, like wacom tablet drivers.

>>106517486
it's more like 90% and the remainder 10%
and 5% of those do random shit that leaves files and configs everywhere and causes breaks
it's awful when things do not conform but most of the system does. that's the real downside
of course this is not better with a package manager... windows 98 did this best

>>106517498
At the point where you're using package managers you might as well go back to Windows 11.

>>106517498
drag the .app to AppCleaner and it will delete any files created by the application along with it.
if you already deleted it, there are apps that show files created by applications that do not exist on the filesystem anymore.
I agree it's annoying and I wish there was a better way to deal with it but it's hardly an issue.
>it's more like 90% and the remainder 10%
idk what those 10% are for you, but even photoshop with the bullshit creative cloud thing does not require an uninstaller and is very much portable. the only thing that "breaks" is the auto-start and background services manifests adobe registers for its daemons which expect the binaries to be at the installed location, so it won't auto start at login (if you haven't disabled that for some reason), but that's ironically a good thing.
the actual program keeps working just fine

>>106516742
Phones are all infected with proprietary spyware. Why would I want anything important running on them directly?

I fucking despise dynamic linking

File: 1749522356445511.jpg (75 KB, 640x480)

75 KB JPG

>>106517572
>Phones

>>106516742
The downside, at least on Linux, is needing to bring a fuckton of outdated libraries with you, either statically linked, or inside your AppImage/Flatpak/Snap/whatever. Then your apps ends up using like 2x the space, simply because they can't share dependencies between each other. (Nix solves this btw)
On macOS this isn't a problem because Apple pushed really hard for dynamic linking. Pretty much nothing in macOS is statically linked, and there isn't even a stable syscall ABI. The syscall interface can arbitrarily change between versions, as Golang painfully found out when it had to port its macOS syscall interface to use libSystem.dylib instead. But by forcing all developers to use dynamic linking, apps get to run with the latest version of all libraries, Apple gets to update OS libraries without needing every program ever to relink, and everything uses much less disk space. It's a win-win-win.
I don't know the situation on Windows because I don't develop for that OS.
>https://developer.apple.com/library/archive/qa/qa1118/_index.html

>>106517436
.app is a macOS bundle that can be shared like a file (but really it's a folder). It has everything needed to run the app, like the actual executable (Contents/MacOS/$NAME), graphic resources (Contents/Resources), any libraries it needs, and anything else. Generally app preferences are saved to a file in $HOME/Library/Preferences/$NAME.plist.

>>106517486
>copying it to /Applications is only a good practice to keep them all in the same place
Not entirely true. While they can *run* from anywhere, only apps in /Applications (or $HOME/Applications) will be indexed by spotlight, show in Launchpad, and be eligible to load things like system extensions. But then again maybe that's a positive that they get no system integration.

>>106517523
>drag the .app to AppCleaner and it will delete any files created by the application along with it.
this does not work for installers that do more than drop an app dir though, and many do, think about anything you might use for development

>>106517628
Oh also since macOS 14 apps can now define "launch constraints" that can enforce certain things, like the fact they're in /Applications or launched by launchd. If this is not true the app will just crash.
It was added in macOS 13 to every system binary, to prevent exploits where trusted system binaries with entitlements can be exploited when run in an untrusted environment (e.g. that big TCC bypass that happened a few years back).
In macOS 14 it was expanded to third-party apps as well. But with third party apps you can just like... `codesign -s - --force --deep /path/to/application.app` and run them anywhere you want.
>https://developer.apple.com/documentation/security/defining-launch-environment-and-library-constraints

File: docker.png (165 KB, 900x632)

165 KB PNG

>>106517628
>show in Launchpad
aren't they removing that in macos 26?
>eligible to load things like system extensions.
true
>maybe that's a positive that they get no system integration.
true also, but it's a bummer for things that expose a context menu entry or a share target. still, keeping them in /Applications doesn't make them "not portable", in the sense that the application is still self-contained
>>106517652
care to give any examples? because in my experience that's not true. it's not perfect and it CAN leave a few files behind, but it works just fine. see docker for example.
unless you mean things like drivers and stuff that needs to install files to system locations, which I already mentioned as exceptions in another post

>>106517580
Retard spotted

>>106517523
>>106517652
>AppCleaner
What's the use case? If you know where to look you can manually clear out every app.
Probably the most important places are /Library/Launch{Agents,Daemons} and ~/Library/LaunchAgents so you can remove any leftover background shit.
System preferences in /Library/Preferences, user ones in ~/Library/Preferences.
Random app data in /Library/Application Support or ~/Library/Application Support.
That will cover basically all data 100% of Apple apps, and 70% of 3rd-party apps create. The remaining 30% are bad ports from foreign OS'es that write in nonstandard locations.

>>106516742
You'd have to bundle tons of libs with them. Many of the apps you think are portable aren't really portable, you just have the dependencies already installed.

>>106517714
>What's the use case?
>you (...) manually clear out every app.
>That will cover (...) 70% of 3rd-party apps create. The remaining 30% are bad ports from foreign OS'es that write in nonstandard locations.
you answered your own question.
appcleaner does all that in under a second and doesn't leave behind those 30%

>>106517686
that's interesting, I didn't know that. I can see its usefulness for making sure the binary hasn't been tampered with, the signature matches and no malicious libraries are being injected for things like, say, a bank decides to make a native macos application.
I can see that being a problem but I also can't see, for the time being, any developers going out of their way to use that unless for one of the reasons above

>>106517733
Why can't linux do the same? Freetards love bragging about having hardware drivers being built-in, but libraries are far more of a clusterfuck, and more work to manage than going to a manufacturer's website and running an .exe.

>>106517714
Shit don't forget if the app is sandboxed the folders will be under ~/Library/Containers, with the developer team ID and bundle ID. In Finder each container will show with the app name and icon.

>>106517689
>aren't they removing that in macos 26?
Yeah but I'm holding out on upgrading that. However much I despise launchpad and never use it (I use raycast), I hate the new design even more so I'm sticking with 15.x until at least 27/28 when the design is matured more. Running the dev beta on my iPhone is a complete shitshow, I only pray it's in a much better state internally if it's publicly releasing this month.
>keeping them in /Applications doesn't make them "not portable", in the sense that the application is still self-contained
Fully agree. There is very few apps that aren't portable. The biggest one (in terms of importance/frequency of use) on my system is Little Snitch.

Also fun fact every .pkg from Microsoft is a meme. If you extract the .pkg payload, you can extract the actual .app and run it anywhere you want. They force you to use the .pkg and don't distribute the .app by itself (unless on the App Store but that is hard locked to a subscription and can't be pirated) so you can get their spyware autoupdater (MSAU) service.

>>106517739
Fair enough, I guess it makes sense if you install and uninstall apps frequently.
My use case is more clearing out / fixing buggy or misbehaving apps.
Like for example for some reason Apple Music now decided it will crash whenever loading the "recently added" view, so I had to hand-patch the preferences file to remove it from my selected views. I guess it's a iToddler BTFO moment.

>>106517765
>Why can't linux do the same?
Flatpak exists, but whoever made it is retarded so you have to download another copy of your fucking graphics driver and graphical environment platform for maximum bloat and redundancy.
Meanwhile all real dependencies an application usually bundles with itself (SDL, sqlite, icu, etc) are a couple hundred KB or a few MB.

File: nix.png (58 KB, 886x769)

58 KB PNG

>>106517765
It can. Much better than macOS, mind you. It's called Nix.

>>106516742
PATH variables.

>>106516742
anything with lots of dependencies or requires hardware drivers or unique forms of hardware access

>>106517785
I don't have any particular opinion on 26 but I guess I see where you're coming from. I also don't use launchpad, all my most used applications are on the dock, and those that aren't I run through spotlight.
> I guess it makes sense if you install and uninstall apps frequently.
it's not that I do it frequently, it's more that I prefer the convenience and not having to make sure I didn't miss any locations. but I can imagine why you wouldn't mind doing it yourself, it's very simple.
>>106517794
can you copy all files associated with a certain program (from a single place), copy them to a usb stick, plug it in another computer and run it there, with zero additional setup or even an internet connection?

>>106517765
because there's no benefit to it? we go out of our way to minimize having excess dependencies installed because that has an actual material benefit on our systems. Installing a bunch of bloatware, and then forcing every app dev to bundle whatever libs we missed is a strict downgrade from a functioning package manager.

>>106516742
i don't want your gay apps.

>>106516951
This. It shows there's no need for the online app stores, package managers, and the retarded ass shared dependency system freetards worship.

>>106517862
Yes, using nix-bundle it can take all recursive dependencies of any derivation (package), and compress them into a tarball that you can then run on any Linux with a kernel from the last two decades. It can optionally make that tarball into an AppImage if you want. No internet required in either case.
>https://github.com/nix-community/nix-bundle
If the other machine is running Nix and you're connected to it, you can do one even better: there's a built-in command "nix-copy-closure" that lets you directly copy the program and all of its dependencies. Then you just run the program from the exact same path on the other machine and it just works.
Note that, unlike AppImages which the devs have to make and distribute themselves, all the packaging is done by Nix. Nixpkgs is the largest software repository ever with 100k+ packages btw.

>>106517883
lol. let me guess, you use arch linux, because
>we go out of our way to minimize having excess dependencies installed
and you don't know they include the most bloated versions of every dependency, not even doing a split like ubuntu into "<lib>" and "<lib>-devel" for headers and such
>>106517893
cool
>Then you just run the program from the exact same path on the other machine
uhhh but okay

>>106517921
>doing a split like ubuntu into "<lib>" and "<lib>-devel" for headers and such
Nix does this btw, they have separate splits for "lib" (shared objects), "include" (headers), "man" (manpages), "doc" (other documentation), "bin" (executables), "dev" (general development stuff). If you're pulling from a cache it only pulls what you need, but when building from source it builds everything then splits into separate outputs.

>>106517921
>uhhh but okay
It's only if the machine is running Nix and you use nix-copy-closure. In Nix every program is in the Nix store, which is a content-addressed store, so like /nix/store/abcdefghijklmnop-my-program-1.0/bin/my-program, where it's identified by its hash.

If you use nix-bundle (in either tarball or AppImage mode) you just run the thing from any path. It has its own mini-Nix store with just the required dependencies inside it.

>>106517892
You can just install shit in /opt/, retard.

>>106517921
>and you don't know they include the most bloated versions of every dependency, not even doing a split like ubuntu into "<lib>" and "<lib>-devel" for headers and such
those are useful retard

>>106517999
I don't know what /opt/ is, though. I just type in sudo apt install name and that's that.

>>106518008
you use linux and don't know the LHS? why are you here?

>>106517883
Why are linux users so content with handing control of their PC over to other people (maintainers)?

>>106518006
>we go out of our way to minimize having excess dependencies installed because that has an actual material benefit on our systems
>n-no, having headers and development libs and files for every single dependency we pull is actually a g-good thing. huh, "do I use them"...? n-no, but it's a good thing they're there!!

>>106517977
I see. I guess that nix-copy-closure is more for when you're doing "clones" of a particular base image, like deploying work machines for your employees, where you expect them to be (at least at the start) the same.
seems less useful when you want to copy stuff between completely different computers, but based on what you said nix-bundle seems to fill that niche.

>>106518055
(((maintainers)))

>>106518087
>where you expect them to be (at least at the start) the same
Not at all. The only thing that must be in common between the two machines is that they run Nix and speak the Nix store protocol.
You give it a path, like /nix/store/...-program-1.0, and a destination address. It will connect to the remote store using SSH, find the recursive dependencies of the path you gave, see what's already on the remote computer, and copy anything that's not. It's kind of like rsync but for the Nix store.
By default it will copy directly from your store to the remote store. But if the remote machine has fast internet, you can tell it to try to pull from the cloud cache if it's available there, before falling back to pulling from your machine. By default it requires no internet other than the direct connection between the two machines, or you can even run your own cache if you want to speed things along, still no internet required other than the connection to that cache.
And remember that the Nix store is a content-addressed store. That means the path of myprogram on my computer and your computer will always be the same, if it's the same program, and always different if it's different.
It can be used for things like remote OS deployments, where you build a NixOS configuration and use nix-copy-closure to copy it to the remote machine, then run /nix/store/...-my-configuration/switch-to-configuration on the remote machine. Then the remote machine will run the new generation you built.

>>106518128
>It can be used for things like remote OS deployments
that's what I was referring to, but thanks for the clarification

>>106518057
>"do I use them"...? n-no, but it's a good thing they're there!!
yeah and fuck you. I hate having to scramble around for dev headers when I want to build something. They should be there by default and only a distro for autistic space saving and dumbfuck retards would do otherwise.

>>106518165
Oh right, sorry I'm retarded. I see it now that I read your post again.
>seems less useful when you want to copy stuff between completely different computers, but based on what you said nix-bundle seems to fill that niche.
Yeah the main value of Nix is that it basically completely eliminates unneeded dependencies and solves DLL hell. It's really good for running OS-wide, but having "portable" programs bundled in tarballs/AppImages kinda kills the point of it, across many tarballs/AppImages, there will be duplicate dependencies. Since they're fully self-contained.

>>106517765
I'm saying that portable apps don't really exist. If you're talking about Windows app then the developers of those apps targeted Windows knowing the libraries would be present. If they depend on something Windows doesn't ship like Qt or GTK then the app comes with tons of DLLs, which will eventually be out of date.

>>106516742
can't harvest your clicks to double-check for bugs

File: sdffsdfsdfds.png (11 KB, 440x468)

11 KB PNG

>>106516742
impossible install spyware if file permissions correct

>>106517794
you can run nix on macos though https://determinate.systems/nix-installer/

>>106518556
Determinate Systems is amazing. I wish they would just make their own NixOS.

>>106518259
>app comes with tons of DLLs, which will eventually be out of date.
>duuuuuuuuude you have to updoooooooooot because...you just do ok?
Lmao at freetards
If you ship your DLLs, you can expect Windows to not break your shit in the vast majority of cases. Windows programs from 20 years ago work just fine. There's nothing that gets "outdated".
The licensing of Windows libraries is a lot freer than on Linux too. You are allowed to statically link MSVC standard libraries if you want to make sure the user doesn't have to install the library.

File: tcc-logo.png (19 KB, 250x150)

19 KB PNG

>>106518653
windows, start from XP, keep all version of all DLLs she seen in shes live
instead better to keep personal copy for every program

>>106516742
just use ldd to list libraries the binary needs, gather the libraries in some randon folder and point LD_LIBRARY_PATH to that folder and run the binary

there is your portability