We need to document macOS

I have not used smart searches, and now I'm reading about them and it does look pretty cool. But that search bar should give me something sort of close to what I'm looking for in a couple strokes and it really doesn't.

I can specifically call out what my issues are with Finder.

- Where is my fucking folder tree. There was no reason to take it away other than "thinking different" just like the backspace key. Super special guys.

- Search bar does not behave in a way that I think comes close to useful for quick search.

- Why does the window default to something so small and not have an obvious way to set the default spawn size to something reasonable. At this point it should be context aware.

- I don't want more windows, I want tabs too.

- The sliding cell browsing is cumbersome, it sometimes forces you into a folder when you are trying to be in it's parent, it limits your view of your total file list, and in this view there is no way (that I know of) to utilize ordering without the dropdown, so you are stuck with hitting the first letter of the file you think might be there to try to get there quick.

- let me make symlinks from the UI.

- The list view is great for the most part, but since you don't have a tree you have to either loose your browsing context to move to a new folder or you have to open a new window... and it will be too small. Then when you try to drag things into the new window, that probably defaulted to the sliding cell view floating around to get where you want to go will inevitably have you dropping the file somewhere bad. This was the most egregious before Lion when "cut and paste" did not exist. You could enable something that called itself that but it didn't do it and used the trash? Mostly it was just delete.

- I can't preview a file in the list view without hitting space and blocking my view of my context.

- It appears to be designed to keep you away from the system HD. More and more so with every release. I want to look at my filesystem, it it's entirety, easily and without using "go".

- Because you can ONLY use finder for getting files from an application you are stuck with usually a default view that is just a directory dropdown. Then you open it up and it's the slider cell. Then you get trapped and you can't go up a single directory so you have to go to a directory that you used recently, hopefully.... if not you have to go to you user root and navigate down a train.

- If you're gonna be designed to keep normal users "safe" then maybe let me have a button that does "open ssh in directory."

- Drag and drop file copying is laggy as fuck and produces constant problems with relocating files. It's always been the same level of unpredictable and now I'm just trained to sit there and wait for the green +. If the UI is going to be so restrictive and drag copy centric, then this should be like lightning.

- Let me use cli applications from the UI. A right click is fine, a button is ok, a hot key is better. This is a Unix based system. Give me that option, out of the box.

- Without any customization, the program should be focused on less clutter, not more. The defaulting to opening new tiny windows that get left in a stack is bad. I sort of get the DMG open window install process when we were back in the CD days like 12 years ago. Now it's ugly, and shitty, and gives leeway to software providers to just do dumb illegible stuff. It seems that the rendering of the DMG install windows changes over time and that breaks the desired UI for older packages. This thing needs to die.

----

I want to be able to move down a tree looking at files like the cell does, with filtering, with a tree on the left, with easy file previews, to any place I can write on my system. Maybe that includes downloading a file from Chrome into /opt. File browsing is a noise heavy data intensive problem sometimes. If you are going to arbitrarily make the most basic tool on the system default to an oddly specific size, well then in use you should do some context detection and expand when there's a huge god damned list of files in the folder. I. Should. Always. Be. Able. To. Sort. And. See. My. Sorting. Options.

If any of this is available, please give me protips.

Not efficiently. And others volunteering their time to reverse engineer documentation on an ever moving target sounds like an exercise in folly.

Especially when the first party could hire technical writers for a fraction of the cost of developers and make this problem disappear.

> In particular, the service launcher (launchd, mentioned in the article), and various other system level things (including logs, also mentioned in the article), have so little official documentation as to be laughable.

God launchd's documentation is so woefully incomplete it's soul-crushing, even more so as they deprecate "legacy" subcommand (which are "community documented" as various souls tried to understand how to make them work) and the documentation for the "replacements" is even worse. I'm not a sysadmin, I don't really care for launchd, but every time I want to set up a cron I waste an hour trying to coerce it into doing something useful before just falling back onto crontab.

Not to mention the… idiosyncratic command lines which makes even documented tools a chore to use fucking `lipo`:

    lipo  [-info]  [-detailed_info]  [-arch arch_type input_file] ...  [ input_file] ...  [-arch_blank arch_type] [-create] [-thin arch_type] [-replace arch_type filename] ...  [-remove arch_type] ...  [-extract arch_type] ...  [-extract_family arch_type] ...  [-verify_arch arch_type ...]  [-output output_file] [-segalign arch_type value] ...

the various options are mostly exclusive which is documented but weird as fuck, but then say you want to check if a given binary contains a specific arch

    -verify_arch arch_type …
         Take one input file and verify the specified arch_types are 
         present in the file.  If so then exit with a status of 0 
         else exit with a status of 1.

You'd expect `lipo -verify_arch x86_64 `, but no, since it can take multiple arch rather than repeat -verify_arch you must put it at the tail: `lipo -verify_arch x86_64`, if you don't you get a screenful of garbage telling you that you gave an incorrect architecture flag, which architecture flags are valid and re-printing the synopsys.

> Lets just say specifically the Finder issue. Is the solution to use Linux as my desktop environment?

Yes, especially with KDE's Dolphin file manager which is more or less the pinnacle of GUI file browser.

See https://www.youtube.com/watch?v=jkWuVCKpiXs

it becomes especially good when you start taping in its scripting capabilities and the wealth of scripts available: https://store.kde.org/browse/cat/102/.

If the experience of developing for the OS is terrible because the documentation is terrible, well...an operating system without a thriving application ecosystem is an operating system that is not long for this world. No matter how good the OS may be. Computing history is littered with the corpses of better operating systems (Amiga and BeOS and every UNIX other than Linux come to mind) that didn't have the app ecosystem to keep them alive.

Obviously, Apple isn't hurting, but it can take a long time for anyone to notice that a huge tree is rotten in the middle. I don't know if that's true of Apple; they've been pretty successful in the transition to mobile, and their iOS ecosystem seems very healthy, but, if the terrible docs are a company-wide issue, it might be a slow-moving disaster. Docs are unsexy enough to where I could believe Apple would completely fuck them up, just because nobody wants to work on the unsexy stuff and nobody thinks about it when things are going so well for the company.