Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We need to document macOS

eclecticlight.co

Post reply on HN
Print view View original

221–230 of 266 posts

Re: We need to document macOS

#221

Post by blacksmith_tb »

stuntkite wrote: post #35

OT a bit but I think still related. 8 years ago when I switch to OSX I was furious with finder. Tiny window, no hierarchical browsing and the search just doesn't do shit that is useful. I normally default to locate or find now so much that I was using it the other day I was reminded about how much it sucked. It's literally identical (aside from tags and labels) to what it was forever ago and is a terrible paradigm. I…

I much prefer mdfind[1] to locate or find on macOS, it uses the same metadata Spotlight leverages.

1: https://ss64.com/osx/mdfind.html

Re: We need to document macOS

#222

Post by sds2 »

lj3 wrote: post #150
sds2 wrote: post #80

Earlier quoted context omitted.

> Linux is a great server OS but a really terrible choice on the desktop. Why?

Because I spent 4 hours today trying to figure out how to prevent something from starting on boot (which boot system is Ubuntu using this version? Why do the systemctl and service commands disagree with each other?). I spent two weeks trying to make my ctrl/capslock swap stick and not reset every time the computer slept/resumed. When I plug my headphones into the computer, I have to manually switch the output source…

> Because I spent 4 hours today trying to figure out how to prevent something from starting on boot

Learn systemd then? Or use the "Startup" app?

> I spent two weeks trying to make my ctrl/capslock swap stick and not reset every time the computer slept/resumed.

xmodmap or gnome-tweak-tools?

> When I plug my headphones into the computer, I have to manually switch the output source every time.

I never needed to. See your settings.

> If I plug in my external monitor while the monitor is off and then turn it on, linux refuses to recognize it.

That's your window manager.

> Is that enough for now? I could go on.

Going on with what? With pure laziness from your side to look up tutorials? Or that you use one of the worst window manager/desktop on linux in its almost-beta version and complain about it?

> I'm using Ubuntu 17.04.

That's your problem. 16.04 or switch distros. Don't use unity either. Don't expect things to work when you use (practically) unstable stuff and you don't even know what you're doing.

> Linux on the desktop is still not as easy to use or predictable as Windows or OS X.

None of your claims are true. Just because you misconfigure something somewhere or because you use a crappy window manager it doesn't make the "linux desktop" worse. Windows is not predictable either - I'm forced to use it at work and it's a pretty bad experience overall.

Re: We need to document macOS

#223

Post by sds2 »

lj3 wrote: post #200
em3rgent0rdr wrote: post #188

Earlier quoted context omitted.

A lot of those issues result with non-uniform hardware. If you want predictability with that then buy from a manufacturer who has designed for and preinstalled Linux, like one of those Dells.

It's a Lenovo W530 Thinkpad. It uses standard hardware that Ubuntu officially supports. Been there. Done that. Also keep in mind I've been using Linux off and on since 1999. I'm not a stranger to hardware compatibility issues and none of these problems result from that.

You're using linux from 1999 and you've problems like this: "I spent two weeks trying to make my ctrl/capslock swap stick and not reset every time the computer slept/resumed."? It's unbelievable.

Re: We need to document macOS

#224

Post by CaptSpify »

em3rgent0rdr wrote: post #173
jacobolus wrote: post #34

Earlier quoted context omitted.

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…

Good code can be understood just by reading it. That is practically impossible with binaries.

I think that's kind of jacobolus' point though.

(at the risk of speaking for someone else)...

jacobolus is saying that in both binary and source format, code is readable. It's just a matter of scale as to how readable each is.

Source is an abstraction of the code that is actually running, and documentation should be an abstraction of the source and how the running code works.

Re: We need to document macOS

#225

Post by CaptSpify »

Nullabillity wrote: post #47
taurath wrote: post #39

Earlier quoted context omitted.

I shouldn't have to go to terminal to edit a conf file to make audio or video work. I have every single time I have tried Linux on the desktop. It does not work out of the box. You must know how to use terminal and edit Byzantine configurations, and read Linux forum posts from 2005 to make basic functionality work. It's my "subjective" opinion, but after 5+ hours troubleshooting and configuring as a power user who do…

Audio has "just worked" for years now, thanks to PulseAudio. Video was a mess for a while, but now it will generally work great out of the box if you've got Intel or AMD graphics. Nvidia is still a mess, but Nouveau will work fine for non-gaming stuff.

I'm going to strongly disagree with you. Audio still has a lot of problems experienced by a lot of people. These naive statements are why people get frustrated with Linux. I strongly support FOSS software and use it all day, everyday, but we need to stop saying that our shit doesn't stink.

Re: We need to document macOS

#226

Post by sd8dgf8ds8g8dsg »

majewsky wrote: post #220
sd8dgf8ds8g8dsg wrote: post #135

Earlier quoted context omitted.

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 + ."

I can already see how n-gate is going to summarize this thread: > 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.

You are not wrong, but my account is throw-away just for this thread. Not hoarding HN points, that is a ridiculous behavior.

Re: We need to document macOS

#227

Post by eikenberry »

jacobolus wrote: post #34
eikenberry wrote: post #16

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…

As a firm believer in the old adage that programs are written for people to read, and only incidentally for the machine to execute, I don't buy into this reductionist argument. Code doesn't become self-documenting automatically, writing self-documenting code is one of those things you learn that makes you a good developer. If you throw away your documentation and then can't read the code, you've written bad code.

Re: We need to document macOS

#228

Post by shenaor »

Gaelan wrote: post #208
herbst wrote: post #180

Earlier quoted context omitted.

Assuming this happened and lead to anything it is still far from actually supporting it.

IIRC Max now works at Apple and is responsible for Swift's package manager.

I think he left sometime last year https://changelog.com/podcast/232 they start talking about his departure from Apple at 55 min and 26s, unless he went back recently

Re: We need to document macOS

#229

Post by dman »

pjmlp wrote: post #202
dman wrote: post #181

I just wish apple would stop breaking gdb every release. They need to make up their mind on whether OS X is a general purpose OS intended for developer use or if its just a locked down version of iOS which runs on larger devices.

It intended for OS X and iOS developers, which use the official supported debugger, lldb.

In other words writing systems software for OS X if you are not employed by Apple is a fools errand?

Re: We need to document macOS

#230

Post by SwellJoe »

majewsky wrote: post #213
masklinn wrote: post #106

Earlier quoted context omitted.

> 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…

> launchd's documentation is so woefully incomplete it's soul-crushing Interestingly, systemd (which, AFAIK, is influenced in large parts by launchd) goes the exact opposite way and has amazingly complete and well-structured documentation.

I've found that to be true, as well. Say what you will about systemd, but they've really done a good job documenting it. There are also useful blog posts from some of the developers delving into various topics. Nearly every question I've had about systemd (and I've had a lot, as our products interact with the init system tons) has been answered either by the docs or by a blog post by one of the systemd developers.

e.g. I recently dug into how to build an inetd style (called "socket activation" in systemd) service. I found pretty good core docs, and a very good blog post with real and useful examples.

Learning my way around systemd has just been a good experience, all around. I have my complaints, but doc quality isn't among them.

It's a big project, but having it all come from the same folks does lead to a consistency across sub-systems that is rarely seen in the Linux world.

Post reply on HN