[ghaff]

There are a few long-time MacOS design decisions that puzzle me. The lack of proper package management is one. Of course, the same might be said of Windows--although it's different enough from *nix that it's at least somewhat understandable.

The other one is the limitations of the Finder. There are better third-party apps but they don't integrate as first-class citizens.

[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.

[pjmlp]

Not all UNIXes have package management.

[patrickg_zill]

Which one doesn't? Solaris, Irix, SCO and everyone else I can think of does.

[pjmlp]

Embedded UNIX like OSes, mainframes with POSIX system?

Last time I used Solaris, around 2004, it had single application packages, like rpm before yum, meaning I had to manually track down the dependencies from Sun repositories.

[majewsky]

From the top of my head, CoreOS. (It's built with Gentoo tooling, but intentionally ships without emerge etc. because you're supposed to use it as a base for Docker.)

[kbob]

I'm curious, what are the limitations of the Finder?

[sir_brickalot]

I have a few limitations/annoyances to contribute:

1. Try to dragndrop content from a child folder to the parent folder. There is a very VERY small area at the top of the window where you can drop your files. (got worse on 10.13)

2. Transfer of multiple files (multiple actions) is not managed successivly but simultaniously.

3. Constant loss of sidebar content, i.e. mounted drives.

4. Info about folder/s inconsistency: Open info for one folder 'Cmd+i', for multiple folders 'Cmd+Alt+i' if you want the overall size (and it doesnt' get highlighted) | Close info window for one folder 'Cmd+w', for multiple folders 'Cmd+Alt+i'.

5. No option to edit file/folder names in Save As... dialog

6. Save As... dialog again: click on a file by accident and your initial file name is gone.

7. I don't understand how people can use the columns sorting but that's personal taste I guess.

8. Missing native window snapping (half size, full size etc.).

MBP 2009 OS X 10.11 & Hackintosh macOS 10.13.4 and my background is years and years of M$.

There are things I love about the Finder, too. :)

[ghaff]

Look at something like Pathfinder instead. The ordering of folders makes more logical sense to me. There's more flexibility in navigating to frequently used locations. There are more options in the menu. Etc.

There's nothing really bad about Finder. It's just sort of meh for a tool that one uses all the time.

[blacksmith_tb]

Having a 'shelf' (with stack-like behavior) like Pathfinder does is very useful, it allows you to go into a dir in one tab, grab arbitrary files, park that selection temporarily, then switch to the destination and drop them. Yes, you can copy-n-paste (finally) in Finder.app, but without any way to to see what files are on the clipboard (short of pasting), and you can do two bunches at once. Of course, for lots of other file-moving, it's easier to use the command line anyhow (like matching on patterns). Pathfinder also filters and searches in the current dir, which Finder never seems to do...

[myrandomcomment]

The shelf here was a key part of the NeXTstep manager. Drives me nuts that Apple removed it.

[gowld]

What's wrong with Pathfinder that makes it not a "1st class citizen"?

[ghaff]

When you do something like Save As... within an application and the dialog box is the native Finder.

[mmt]

I'm pretty sure that's a misconception. That's just the application using a system library for that dialog box, and the system library's look and feel (unsurprisingly) match the Finder's. In some cases, the code may actually be the same (i.e. the Finder itself uses that system library, too), but far from always.

This tends to show up if you're trying to tweak/customize preferences (e.g. from the command line or editing plists directly), since you usually have to duplicate the effort for both places.

[ghaff]

At that point you're into semantics though. I'm fine with saying that Apple has BOTH a meh file manager and a meh system dialog box related to file stuff that may or may not share code. (And if they don't both work in pretty much the same way, that's mostly an annoyance as well.)