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

241–250 of 266 posts

Re: We need to document macOS

#241

Post by pjmlp »

geofft wrote: post #231
pjmlp wrote: post #197

Earlier quoted context omitted.

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…

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.

Re: We need to document macOS

#242

Post by khedoros1 »

pjmlp wrote: post #219
fnord123 wrote: post #129

Earlier quoted context omitted.

And yet Apple does not contribute to homebrew at all. The one project that makes osx usable for developers.

I used OS X a few times for iOS development, never used homebrew. Am I not a developer?

Maybe you had different requirements than other developers. Or maybe you've got a lower bar for considering something "usable".

Re: We need to document macOS

#244

Post by pjmlp »

khedoros1 wrote: post #242
pjmlp wrote: post #219

Earlier quoted context omitted.

I used OS X a few times for iOS development, never used homebrew. Am I not a developer?

Maybe you had different requirements than other developers. Or maybe you've got a lower bar for considering something "usable".

My requirements were those that any OS X and iOS developer have, which don't require UNIX CLI rather XCode tooling, and are happy to use any UNIX certified POSIX system for the occasional CLI automation of OS X and iOS development.

Now those that bought OS X as a pretty alternative to GNU/Linux and *BSD, for development that should actually be done on those systems, might miss something like homebrew.

Apparently only those are developers on HN speak.

Re: We need to document macOS

#245

Post by jcelerier »

spost wrote: post #179
jcelerier wrote: post #155

Earlier quoted context omitted.

how do we know there aren't similar bugs with MS explorer / Finder ?

Well, we don't, but would you rather use software known to have bugs or software not known to have bugs?

uh... software whose bugs are known and whose source is accessible of course ? it's not like finder does not have CVEs: https://www.cvedetails.com/vulnerability-list/vendor_id-49/p....

Re: We need to document macOS

#246

Post by vidarh »

SwellJoe wrote: post #232
vidarh wrote: post #195

Earlier quoted context omitted.

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

I agree about that - didn't mean to imply otherwise. Though it also quickly got expensive (I'd argue that for a while in the mid 80's it was cheap as a PC alternative - my dads PC was slower than my Amiga 500, had no graphics abilities, had less memory - it's two benefits were a 20MB harddrive and compatibility with PC apps; for that he paid about a $3000 premium).

In fact, part of the point I didn't put across very clearly is that things like Aminet demonstrates how important that ecosystem is. Amiga would have become useless to most users far earlier if we didn't have incredibly well curated sets of applications, and amazing dedication to maintenance (e.g. even today people are releasing their own bug-fixed versions of system libraries and the like) - it took a lot of effort to try to compensate, and it still wasn't enough.

Re: We need to document macOS

#247

Post by ZenoArrow »

em3rgent0rdr wrote: post #238
ZenoArrow wrote: post #130

Earlier quoted context omitted.

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

> "and it is not necessarily a bad thing to have separate tools to handle separate needs."

It's not a bad thing to have different high-level tools for different needs, but in the case of lower level frameworks it's suboptimal unless interoperability is seamless. In the case of PulseAudio and JACK that interoperability is not seamless, and is fraught with problems, so in this regard Linux audio is worse than CoreAudio.

Re: We need to document macOS

#248

Post by dman »

pjmlp wrote: post #240
dman wrote: post #229

Earlier quoted context omitted.

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.

I understand that gdb is not part of the official SDK. I would expect an OS in widespread use to not break userspace and when it does, take substantial remedial action to fix / patch widely used applications.

Re: We need to document macOS

#249

Post by pjmlp »

dman wrote: post #248
pjmlp wrote: post #240

Earlier quoted context omitted.

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.

I understand that gdb is not part of the official SDK. I would expect an OS in widespread use to not break userspace and when it does, take substantial remedial action to fix / patch widely used applications.

The onus is on gdb developers to keep up with the OS API changes, not the other way around.

Re: We need to document macOS

#250

Post by [deleted] »

pjmlp wrote: post #244
khedoros1 wrote: post #242

Earlier quoted context omitted.

Maybe you had different requirements than other developers. Or maybe you've got a lower bar for considering something "usable".

My requirements were those that any OS X and iOS developer have, which don't require UNIX CLI rather XCode tooling, and are happy to use any UNIX certified POSIX system for the occasional CLI automation of OS X and iOS development. Now those that bought OS X as a pretty alternative to GNU/Linux and *BSD, for development that should actually be done on those systems, might miss something like homebrew. Apparently only…

[deleted]
Post reply on HN