Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

I mean, I'm not the target audience and I don't have the attachment to OSX as a platform, but if I was gonna expend the energy to document a thing, I'd hope it goes towards a good cause and isn't just free labor for like the richest corp I can think of from the top of my head.


Maybe, sometimes, some of us just want to make a thing we use better rather than attaching grandiose moral judgements to the political status of a piece of fucking code.


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, because more people will be able to use a free system.


Not sure that I agree with the second proposition. I'm pretty sure vastly more people choose to use iOS and macOS than free systems.


But more people will choose to use free systems if they get better documentation (that is tailored to average folk, not computer enthusiasts).


> 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 question is "how the heck am I supposed to connect to this WPA-Enterprise network," it's wpa_supplicant under the hood whether you're using Android's network dialog or GNOME's, and documenting wpa_supplicant's abilities and bugs helps Android users just as much as GNOME users.


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?)


I am speaking about developer documentation.

As for user documentation, any OEM is free to do whatever they feel like, so you don't have any guarantee how much of it is actually like AOSP.

Samsung is well known among Android devs for breaking AOSP compatibility.


OS X devs are also devs.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: