https://opensource.apple.com/
We need to document macOS
211–220 of 266 posts
Re: We need to document macOS
#212I find most answers I need on Stackexchange. However there are books like "Mac OS The Missing Manual", I always wondered if anyone bought them and what they actually contained.
My thoughts exactly. First thought was what problems did this person run into that can't be found in a single google hit today? I was thinking the piece would go into some obscure internals but that doesn't seem to be the case. MacOS is simple enough to grasp for most people at first use. More advanced usage is documented, not in one location but scattered over the internet. Google made that not matter anymore. In ad…
I believe that's only true if the questioner is versed in "How to ask questions the smart way," and/or the answerer is _also_ versed in that, so they know how to answer what the questioner was _really_ asking
Not to mention the tons of "dear lazyweb, do my homework|task for me, kthxbai" level of effort expended by the questioner
Re: We need to document macOS
#213When I did some work on porting out product to macOS (so developers could run their server environment locally, though a few loons wanted to actually run macOS on servers), I was immediately struck by how awful and incomplete the documentation was. And, I've been working in the Linux world for a couple decades...where docs are copious but wrong about 50% of the time. In particular, the service launcher (launchd, ment…
> 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…
Interestingly, systemd (which, AFAIK, is influenced in large parts by launchd) goes the exact opposite way and has amazingly complete and well-structured documentation.
Re: We need to document macOS
#214Earlier quoted context omitted.
# man pdftohtml This manual page documents briefly the pdftohtml command. This manual page was written for the Debian GNU/Linux distribution because the original program does not have a manual page.
That is outdated though, at least my current release version of poppler (0.57.0) has a manpage for pdftohtml which says at the end "This manual page was written by Søren Boll Overgaard , for the Debian GNU/Linux system (but may be used by others).". According to the current poppler PKGBUILD in Extra[0], there are no patches applied. Edit: Actually, poppler has had the pdftohtml manpage upstream since version 0.5.0, w…
Re: We need to document macOS
#215Earlier quoted context omitted.
That's not pragmatic, that's just... wrong, on so many levels. Either 1) shame them, 2) move to OSS, or 3) suffer, but please don't donate your precious time to solve the problems of a rich company who doesn't care about its users. Doing so would only diminish the effect of first option (shaming) and is just not fair to anyone. Or, write a complete reference book and sell it for profit.
You could say the same thing about many free software projects created for the ecosystem. Many of them could have been created by Apple and shipped as a part of the system. I have donated my precious time to solve problems that should have been solved by Apple before. I’m not extatic about it, but my itch got scratched and hopefully I may have helped other people, too, so I consider it a pragmatic improvement. I can…
Re: We need to document macOS
#216Earlier quoted context omitted.
> But yeah, online documentation, classical tutorials are usually useless. How long ago was this? Checkout the arch linux wiki. It's a pretty great resource for all things GNU/linux.
The Arch wiki is great for dealing with common problems in popular software. Other stuff tends to be about as outdated and incomplete as the average "how to" blog post. It's a good resource to have, but it's not the same thing as having well-documented software.
I used Arch wiki to finally get it figured out, iirc.
Re: We need to document macOS
#217When I did some work on porting out product to macOS (so developers could run their server environment locally, though a few loons wanted to actually run macOS on servers), I was immediately struck by how awful and incomplete the documentation was. And, I've been working in the Linux world for a couple decades...where docs are copious but wrong about 50% of the time. In particular, the service launcher (launchd, ment…
> 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…
Unfortunately, cron and crontab only function as expected in every other (every third ?) release of OSX.
Re: We need to document macOS
#218Earlier quoted context omitted.
Also if you're not quite ready to kill yourself while using the windows command prompt. Enjoy a powershell.
You'd probably enjoy Cmder[1]. Everything works really nicely, it supports multiple tabs, and you can download a version that includes most of the Unix commands you know and love. [1] http://cmder.net/
Is it the actual Unix commands that I actually know and love, or just 25-year-old parodies like on macOS? (I've stopped keeping track of how often my bash scripts broke on macOS because I was giving some switch to a coreutil that was introduced less than 25 years ago.)
Re: We need to document macOS
#219Earlier quoted context omitted.
> But, I'm kinda baffled why anyone would volunteer to provide free labor to one of the largest and most profitable companies in the world. YES! MacOS users don't need to document macOS as a volunteer project, they need to demand Apple to give them their money's worth.
And yet Apple does not contribute to homebrew at all. The one project that makes osx usable for developers.
Re: We need to document macOS
#220Earlier quoted context omitted.
Unfortunately, your points aren't numbered, but I'm confused by a couple of them. - Finder has had tabs for a few releases, and I can't recall the last time I had multiple Finder windows open at the same time. I use tabs for everything. - By "sliding cell" do you mean the columns view? I use the list view roughly 100% of the time, so I'm no help there. - On my system, quicklook opens a preview to the left of the find…
For showing "system hidden files", most popular is the ~/Library, run this command in terminal defaults write com.apple.Finder AppleShowAllFiles YES For toggle display of hidden & dot files, type "Shift + Cmd + ."
> An internet complains about how macOS documentation is only transmitted by tribal knowledge. Hackernews acknowledges the problem, and proceeds to trade said knowledge in exchange for internet points.