161–170 of 266 posts
Does anyone remember "Inside Macintosh," the manuals Apple published back in the classic Mac OS days? I have many of those books, covering everything from how the hardware handles drawing to the screen, up through memory management, files, networking, etc. They're examples of some of the best technical documentation I've ever encountered. It's too bad they don't prioritize that anymore. :(
Stop consuming proprietary code from for-profit corporations.
Earlier quoted context omitted.
A lot of these just seem like you aren't familiar with the Finder, did you check the menus, preferences, or do a web search for Finder tips? - No folder tree you are correct. I don't miss it personally. Gotta just deal with this one I think. - What way specifically does the search not work for you? It's incredibly powerful and you can search by file name, content, file type, creation date, etc. - It should save the w…
I'm not GP, but I recently sank time into trying to change Finder searches to default to the current directory instead of my entire machine. It mildly infuriates me that I can't change this; I gave up after I saw com.apple.finder.plist is not plaintext.
plutil -convert xml1 com.apple.Finder.plist
Earlier quoted context omitted.
A lot of these just seem like you aren't familiar with the Finder, did you check the menus, preferences, or do a web search for Finder tips? - No folder tree you are correct. I don't miss it personally. Gotta just deal with this one I think. - What way specifically does the search not work for you? It's incredibly powerful and you can search by file name, content, file type, creation date, etc. - It should save the w…
I'm not GP, but I recently sank time into trying to change Finder searches to default to the current directory instead of my entire machine. It mildly infuriates me that I can't change this; I gave up after I saw com.apple.finder.plist is not plaintext.
Earlier quoted context omitted.
There is no undocumented open source software, the documentation is just in a technical language. This is why learning to program is important, as it also means learning how to read the documentation. I'm not being factious. We always say that documentation doesn't keep up and that the only real documentation is the code. Ultimately the only reliably documented software is free software.
Code is the end result of a thinking / problem solving process, not the process itself. If I implement a mathematical formula in code, the “documentation” is the academic paper where the formula is described and proved, and the whole context of textbooks and other papers where the relevant terms are defined and abstractions are constructed, not the handful of lines of abstract arithmetic on one-letter variable names…
Academic papers are both jargony and written in specialist notation and are not generally accessible to lay people without background in the field. I don't see how it is really much different.
Earlier quoted context omitted.
That's it though, it very often does just work. Without vendor support and with barely any investment from manufacturers, the Linux community is still pushing on to get things to a point where your dog could install it. Your experience is an anomaly they're trying hard to eradicate.
I understand that, and have tried again nearly every year for the past 15, using the most "user friendly" distro I can find each time.
It only takes a particularly new graphics card, or certain wireless chipset to give even battle-hardened users a novel and painful experience.
Earlier quoted context omitted.
Documentation effort towards OSX would help vastly more people than similar efforts for any flavor of Linux, which nobody plus epsilon uses (except amongst devs). Impact is a big factor in how useful an activity is, even if it's tied to a big company.
> "Documentation effort towards OSX would help vastly more people than similar efforts for any flavor of Linux" From a purely utilitarian perspective: - The same amount of effort spent trying to document will result in more documentation being produced on a free system, since free systems are easier to document. - The same amount of documentation produced will result in more benefit from end users for a free system,…
When 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…
I've filed documentation bugs against launchd. They acknowledged the issue, and then filed them for resolution in the n+2 major release in macOS, because it was too late for the next major release.
I suspect their technical documentation process to have gone pear-shaped.
Earlier 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…
Sometimes it is good because it helps people use more free software- but not always. Sometimes it just helps people use the non-free software.
When 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…
>And, I've been working in the Linux world for a couple >decades...where docs are copious but wrong about 50% of the >time. Nice summary of the status of Linux documentation. Not sure if it's really 50% wrong, especially the man pages make an impression of over-corrected but the usefulness depends on the tool and is completely random. But yeah, online documentation, classical tutorials are usually useless. When I see…
# man pdftohtml