[AnIdiotOnTheNet]

It's because package management is a bad paradigm for application management.

MacOS descended from NeXT, which had Application Bundles, but even before that MacOS Classic did the sensible thing and just used folders. You want to install an application, you just put the folder somewhere on your disk. No library conflicts, no web of dependencies to break, and it integrates easily with the file management metaphor personal computers have had since forever. Want two copies of the same application, but different versions? No problem. Want to move the application to another disk? No problem. Uninstallation is one delete away. Want to put it on a floppy and take it to a friend's computer and run it? You get the idea.

Turns out you don't need a package manager unless you intend to over-engineer application management to the insane level that the open source community has.

[ksk]

For simple apps that makes sense. But then you have apps that require kernel drivers. Or the app itself is a shared library. Or multiple users on the same system use the app, etc.

>Turns out you don't need a package manager unless you intend to over-engineer application management to the insane level that the open source community has.

You don't necessarily need a package manager, but you can't solve the problem with simple folders either.

[AnIdiotOnTheNet]

> For simple apps that makes sense. But then you have apps that require kernel drivers.

A.k.a drivers. The app is just a control panel. MacOS classic used "extensions" for this, which were basically just app folders you put in a specially designated folder.

So the modern version of that could just be dropping a folder into a special location there kernel knows to search for drivers, and include a control panel app.

> Or the app itself is a shared library.

A.k.a not an app at all. Shared libraries only really make sense as part of a stable base system that developers can target and depend on, otherwise you get DLL hell and require something like a package manager and all its associated limitations for basically no benefit at all.

If your application uses a library and you don't want to compile it statically, just include a copy in the app folder, secure in the knowledge that it will never cause a conflict or break your application due to an update or some other application replacing it.

> Or multiple users on the same system use the app, etc.

Desktops, a.k.a "Personal Computers", don't really have much of a multi-user use case. They did briefly in the time after the internet became a big deal but before smart phones were invented, but that time is over. Know what we did on Windows 98? We just shared the system, it wasn't a big deal.

Even so, it's not like you need two copies of the application to have two different configurations.

None of this is anywhere near as complicated as the people who promote it like to pretend it is.

[ksk]

>So the modern version of that could just be dropping a folder into a special location there kernel knows to search for drivers, and include a control panel app.

Do you mean the kernel is going to load random files from a user writable location? That sounds like a security nightmare TBH. Also, then you can't safely lazy-load kernel drivers because you never know what the user has done to the folder. Or if the OS has to lock access to the folder then the user has no feedback as to why they can't "uninstall" stuff by simply deleting folders, etc, etc. There are dozens of problems. Turns out, people have already thought over those problems and proposed solutions :)

>otherwise you get DLL hell and require something like a package manager and all its associated limitations for basically no benefit at all.

You claiming there is no benefit to being able to install/remove/update third party shared libraries doesn't solve anything.

>just include a copy in the app folder, secure in the knowledge that it will never cause a conflict or break your application due to an update or some other application replacing it.

That assumes you have the rights to distribute the library and that the library is small enough.

>Desktops, a.k.a "Personal Computers", don't really have much of a multi-user use case.

Maybe not for you. For millions of other users, its a very important use case.

>None of this is anywhere near as complicated as the people who promote it like to pretend it is.

Well its certainly not complicated if you re-define the problems as non-problems.

[AnIdiotOnTheNet]

> Do you mean the kernel is going to load random files from a user writable location? That sounds like a security nightmare TBH.

On a server, sure, but on a PC? It's their computer, they should be able to do that. You're confused because permission systems on Desktop OSs are currently based around user accounts, which is silly. If they were based around applications instead it wouldn't be a problem.

> That assumes you have the rights to distribute the library and that the library is small enough.

If you don't, then why is your application using it? As for size, multi-GB applications are pretty common. It's not libraries that bring that size up, it's assets. Some applications have icons larger than most libraries. Otherwise, if your application isn't valuable enough to be worth the size of that library, then maybe you shouldn't use such a huge dependency in the first place.

> Maybe not for you. For millions of other users, its a very important use case.

Apparently not one you're willing to elaborate on. Besides, as mentioned, I believe there are better and simpler solutions to the problem than package management. In fact, how the hell does package management even help here?

[ksk]

>On a server, sure, but on a PC? It's their computer, they should be able to do that.

A user-writable location should never be used to load kernel modules. This is a privilege escalation vulnerability.

>You're confused because permission systems on Desktop OSs are currently based around user accounts, which is silly. If they were based around applications instead it wouldn't be a problem.

I prefer to deal with the real world design of operating systems rather than imagined ones.

>If you don't, then why is your application using it?

Using an API doesn't give you distribution rights. Copyright law assigns that to the creator of the application/shared library/. Depending on the license you will get different rights to either include a copy of the library, include a separate installer of the library, let the user install it separately, etc.

In other cases, patent law can disallow distribution. To give you an example off the top of my head - MP3 encoding is under US patent law and Audacity (an audio editing software that I use) does not allow you to save to the MP3 format till you install the shared library separately and point the software to its location.

>Apparently not one you're willing to elaborate on.

What is there to elaborate on? Are you not aware that millions of computers used in schools, colleges, corporate offices, server farms, homes, etc rely on multi-user features?

Solving a general problem involves solving it seamlessly for a large number of usecases. Otherwise you end up with a fragmented system that is confusing.

I would prefer they solve it in a perfect manner with perfect compatibility and perfect code with zero bugs, but they wouldn't listen to me. ;)

> I believe there are better and simpler solutions to the problem than package management.

Okay?

In any case, your folder based idea doesn't solve many of the real problems that users and creators face w.r.t. distributing, installing, and updating software. Before you reject them, its worth thinking about them. Bye!

[gowld]

Or if you like to have a secure machine that doesn't have 40 copies of a zero-day embedded in binaries across the system.

[ghaff]

Fair enough. And I suppose Apple's attitude is more or less along the line that if you want to use our pristine machine as a Unix desktop/laptop managing the random packages you install is on you.

I almost wrote and didn't, but it's also true, that app stores (whether iOS or MacOS) are also effectively a form of application virtualization/package management.