Live data from Hacker News

We need to document macOS

eclecticlight.co

231–240 of 266 posts

Re: We need to document macOS

#231
post #197
post #67

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). Documentation effort towards Linux would help get that number up from nobody plus epsilon. Also, at this point that's just not true because of Android. Most of the userspace is different from normal GNU/Linux distros, but not all : for instance, if your q…

Android is only about Java. The NDK APIs are quite constrained and only meant to be used for Java native methods, real time audio and high performance graphics. Google can replace the kernel for anything else POSIX like, with the same set of NDK APIs. Since Android 7, they have been locking down access to anything else not part of the official NDK APIs.

That depends if you're talking about user docs or developer docs. I'm saying that we should document wpa_supplicant as user documentation: if there are caveats like, oh, "Android 5.1 and lower can't connect to TLSv1.2-only PEAP or EAP-TLS networks," that should be documented for end users but is irrelevant for devs since wpa_supplicant isn't accessible to the application at all. It's not a library/API, it's a system daemon.

(But maybe I missed the point and we're specifically talking about developer documentation here?)

Re: We need to document macOS

#232
post #195

Earlier quoted context omitted.

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

AmigaOS is more of a zombie - it's still being developed, and has spawned at least two "offspring" in MorphOS and AROS that are both still developed (and ported to new hardware in the case of AROS in particular). And AmigaOS was a shining beacon of efficiently surfacing apps online early on. Aminet [1] provided a robust mirror system and ability to browse a big catalog (still online and updated) of downloadable Amiga…

Sure, and I used my Amiga until well after CBM died; I didn't switch to a Windows PC until after Windows 95 came out (and then switched to Linux soon after). But, it's hard to argue that the smaller application ecosystem didn't hurt it. There were good applications for most tasks, but the big names were absent, and businesses rarely chose Amiga for that reason (and a few other reasons).

Re: We need to document macOS

#233
post #46

Earlier quoted context omitted.

ElementaryOS seems to be going in the right direction. But I suppose the main "thing that works" is to have a team of people that actually enjoy making software usable by the masses rather than solving X for their own needs.

That's a rare sort of intrinsic motivation, though, and tends not to last long in the face of frequent contact with users who, having their own situations to deal with, reasonably tend more often to complain about software that fails to make their lives easier than compliment that which does. That's where extrinsic motivation needs to come into play, but it's not much on offer in the context we're considering.

maybe can get doc writers who care more about people rather than things...

Re: We need to document macOS

#234
post #153

Earlier quoted context omitted.

Of course they want to kill macOS, it's only a small fraction of their profits. They've rewritten all the software they've acquired over the years, Final Cut Pro etc, I'd bet they're internally compatible with whatever their future iOS based desktop OS is.

It's a $25B+ a year business that earns more profits than all the other PC makers in the world combined. I'm pretty sure they don't want to kill macOS.

Not saying they want to kill Macs, just move them to a new OS so they can share developers with the 10x larger iOS market.

If you have 50% of your OS programmers working on an OS that only 10% of your users use, seems like a waste

Re: We need to document macOS

#235

Earlier quoted context omitted.

I wonder how much this has to do with the code, and coder, churns in the Linux ecosystem. Seems to me that there is a new weekend plumbing project popping up and being replaced almost monthly, if not even more often. And it if gets an toehold in the ecosystem, the initial developer will quickly move on as he runs out of features to graft on and thus lose interest. Then whoever takes over invariably decides the codeba…

Well, that might be true of some random special-interest packages; but for base system components like the kernel (linux) and the init system (systemd), you see the opposite of that description. The maintainers of core GNU/Linux infrastructure are, for the most part, permanent and devoted.

Watch systemd get passed off soon enough.

Never mind that calling it a init is a mislabeling at best...

Re: We need to document macOS

#236

Earlier quoted context omitted.

Listen man, I do plenty of customization. What I'm bitching about here is what I consider to be a lack of innovation and a dereliction on obvious existing, key tools. Finder is a beautiful example of Apple not taking care of it's shit. I don't need a fucking hand hold. My 3 year old Macbook Air is in my opinion the BEST laptop available. I'm angry that the innovation appears to have ceased from the availible provider…

Your delusion that paying "availible [sic] providers" the large price tag they put on their electronics and 'doing plenty of customization' make them "your" tools is the reason I don't take you seriously; "your vernacular" is more an indicator than an issue in that regard. > The second they shape up, someone else delivers me an answer, or I write something to get me out of this platform, there I go. The first two are…

Starting a comment with a personal attack isn't well-advised here.

Doing it twice in a row, far less so.

Re: We need to document macOS

#237
post #234

Earlier quoted context omitted.

It's a $25B+ a year business that earns more profits than all the other PC makers in the world combined. I'm pretty sure they don't want to kill macOS.

Not saying they want to kill Macs, just move them to a new OS so they can share developers with the 10x larger iOS market. If you have 50% of your OS programmers working on an OS that only 10% of your users use, seems like a waste

But macOS and iOS share enormous amounts of code, if not the majority. The kernel is pretty much the same. APIs usually get support on both systems, with the exception being the UI layer.

Indeed, if they have different APIs on the 2 platforms for the same functionality, you can probably bet that pretty soon one will be ported across to the other and the other obsoleted. Recent examples: PDFs, Bluetooth, Media SDKs (AV Foundation etc).

Re: We need to document macOS

#238

Earlier quoted context omitted.

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.

> "Audio has "just worked" for years now, thanks to PulseAudio." For your use cases perhaps, but it's not suitable for all use cases in the same way CoreAudio on OSX is. Music production is a key weak point, which is why JACK and PulseAudio are both required to have what CoreAudio offers out of the box.

There are a few options to allow for Jack and PulseAudio to coexist: http://jackaudio.org/faq/pulseaudio_and_jack.html

There is a reason why there is both Jack and Pulse...they meet different needs (pro-audio vs desktop), and it is not necessarily a bad thing to have separate tools to handle separate needs.

Re: We need to document macOS

#239

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…

> 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. Somewhat related, it has become Apple user/developer etiquette not to mention bugs without filing a bug report on Apple's closed issue tracker beforehand: https://blackpixel.com/writing/2012/02/radar-or-gtfo.html I can't believe how many hours I've wasted on detailed bug reports…

  1) be influential, 2) complain publicly
3) don't buy their products.

Re: We need to document macOS

#240
post #229
post #202

Earlier quoted context omitted.

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?

No, a fools errand is to buy a Mac and use GNU/Linux tooling instead of the official OS X SDK tooling.

GDB stop being part of the official modern SDKs quite long time ago.

Post reply on HN