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

macOS Internals

gist.github.com

Post reply on HN
Print view View original

71–80 of 146 posts

Re: macOS Internals

#71

Post by pasc1878 »

ilkkal wrote: post #16
saagarjha wrote: post #15

Earlier quoted context omitted.

They’re just shared libraries.

Thanks for the blinding insight.

What they solve is that they are not just shared libraries, they include any other resources the library needs like translations, images, other data etc and for developers any header files.

But it works if you just treat them as shared libraied - just use -F on the compiler anlink rather than -l and the headers are not needed in /usr/include etc.

The are also versioned so easy for two apps to have different versions of the Framework.

Re: macOS Internals

#72

Post by ZephyrBlu »

ElFitz wrote: post #14

It’s funny how I used to think that operating systems, databases, and cloud systems, as these kind of arcane things that were somehow apart from the rest of software. I could not begin to grasp how they could deal with running programs, access control, or any of these things that once seemed so foreign and mysterious to me. And realising that it’s actually just software, that there’s no black magic to it, just lower-…

The thing that made me realize this was compilers!

"Wait, code is just text?"

"Always has been"

I still have to remind myself of this sometimes when I think "woah, how does this work?" and then I try to step through how it might be built.

Re: macOS Internals

#73

Post by jwandborg »

sgt wrote: post #61
amelius wrote: post #31

Earlier quoted context omitted.

Yes, a modern OS is a tangled mess of microservices.

They just don't communicate using JSON. I can see it now; Kernel JSON (aka kjson) support in the Linux kernel to attract Node developers.

Just take the Unix philosophy and replace the word "file" with "JSON file".

Re: macOS Internals

#74

Post by alin23 »

catoc wrote: post #70
alin23 wrote: post #24

The window server is "lightweight" in that it does no screen drawing itself. It is, to use Apple's term, "drawing model agnostic." WindowServer is such a behemoth nowadays, it took me ages to reverse engineer how to make rcmd ( https://lowtechguys.com/rcmd ) control Stage Manager. It’s interesting to see it described as lightweight . I guess every lightweight solution becomes heavy and complex with enough usage.

I love your website's privacy page. Also lightweight. ["rcmd does not collect any personal information."] That's the complete page. Great policy!

Thank you! Yes, I believe privacy policies should be written for end users, not for lawyers.

I tried to do the same with my other more complex app as well: https://lunar.fyi/privacy

Re: macOS Internals

#75

Post by mike_hearn »

maccard wrote: post #60
mike_hearn wrote: post #58

macOS probably doesn't get enough love from an OS design perspective. Over the years I've had reasons to work pretty closely with the guts of all of Linux, macOS and Windows and macOS is probably my favourite, design wise, although for some tasks you can't beat the flexibility and feature set of Linux. A few highlights that are lesser known: - XPC/Mach is a pretty reasonable IPC system that avoids the huge complexity…

I agree with most of what you've said here, except: - Code signing. It's incredibly frustrating as a developer to try and codesign an application to pass gatekeeper, requiring multiple steps with very little information as to what's _actually_ going on or going wrong in the middle of it, including uploading your entire bundle to Apple and waiting an arbitrary amount of time for them to notarize it. > It's very weak t…

A core OS service in my books is an API that can be used by any app, can be adopted in a backwards compatible way and which is used by the in-house apps too. The App Store isn't an API or service, it can't be used by every app and the built-in macOS apps aren't necessarily store apps. Yes, it's Apple's strategy but I maintain that from a tech perspective it's a very weak one.

Cryptography DX is always terrible on every platform, I don't know why, it seems to be an unwritten rule that crypto tools must have as many sharp edges as possible. But as far as these things go, Apple's infrastructure actually is effective and flexible. Notarization got a lot faster lately and is certainly way better for both devs and end users than client side virus scanners.

Swift is a good upgrade, but not exactly a high level managed language. Most of those languages have very fast or non-existent compile times as well as GC, they tend to be simple-ish, perhaps they have optional types. The Swift DX is quite different to a C# or a Java for example.

Re: macOS Internals

#76

Post by gshubert17 »

JadeNB wrote: post #66
aebtebeten wrote: post #32

Earlier quoted context omitted.

> The present is the past rolled up for action and the past is the present unrolled for understanding. — A&WJD

> A&WJD Who's that?

Ariel and William James Durant, authors of "The Lessons of History", where the quote appears on page 12, itself a quote of their earlier volume 6 from "The Story of Civilization", specifically "The Reformation", page viii.

Re: macOS Internals

#77

Post by cowsandmilk »

magoghm wrote: post #19
DavidPiper wrote: post #6

Earlier quoted context omitted.

http://newosxbook.com/home.html for the lazy :) They are an updated and much expanded version of "Mac OS X and iOS Internals: To the Apple′s Core" by the same author. Which in turn was an updated version of "MAC OS X Internals: A Systems Approach" by Amit Singh.

Does anybody know why they are so hard to buy from outside the US?

International shipping of individual books has become very expensive. Within the US, media mail provides an inexpensive option for authors.

Re: macOS Internals

#78

Post by yyyk »

pjmlp wrote: post #68
maccard wrote: post #60

Earlier quoted context omitted.

I agree with most of what you've said here, except: - Code signing. It's incredibly frustrating as a developer to try and codesign an application to pass gatekeeper, requiring multiple steps with very little information as to what's _actually_ going on or going wrong in the middle of it, including uploading your entire bundle to Apple and waiting an arbitrary amount of time for them to notarize it. > It's very weak t…

Code signing is coming for Win32 as well, as announced at BlueHat IL 2023.

I searched and found the slide:

https://msrndcdn360.blob.core.windows.net/bluehat/bluehatil/... (Pages 20-22).

Oh dear.

Re: macOS Internals

#79

Post by galad87 »

kreddor wrote: post #57
neurostimulant wrote: post #29

Man, I miss those 20+ pages long Ars Technica reviews. They don't seem to publish these kind of stuff anymore.

The macOS Ventura review doesn't count?

Not really. It lacks the insight and the attention to small changes and under the hood improvements of the Siracusa's reviews, in my opinion.

Re: macOS Internals

#80

Post by easeout »

pjmlp wrote: post #64
TazeTSchnitzel wrote: post #40

If this kind of thing interests you: late-2000's/early-2010's Apple had some fantastic documentation, but it's all hidden in the “documentation archive” ( https://developer.apple.com/library/archive/navigation/ ).

Only available to us old timers really, as newer devs on the ecosystem don't even know what to search for. I don't get it how they messed this up.

My hunch is SEO combined with placing less responsibility on the programmer.

The new docs have a page per code symbol, and much more focused single-page topic articles, rather than 20-page programming guides. Docs seem to be structured to answer a question right when you have a problem, but then they don't offer a good way to study in depth before you begin.

The other day a younger teammate asked a group about some API documentation that said the results are undefined if you call this wrong, and had we ever heard of such a thing. And yes, of course, using framework code in unintended ways is always a garbage in, garbage out affair. This made me realize we have come a very long way in eradicating boilerplate and ceremony in code.

There used to be so many things you just had to use the way the docs explained, or else. Doing the boilerplate correctly was a primary focus of code review. Today we have ARC, we don't call alloc separately from init, we never handle KVO without the compiler's help, and we have no IBOutlets to forget to bind. To begin writing for iPhone 15 years ago, I had to study for a week or so with the programming guides, one for the language and another for the platform. Today you can do a one hour tutorial.

So, if you can stumble your way through building an app by typing the period key and seeing what methods are available, and the whole platform SDK exhibits Clarity at the Point of Use, would a newcomer even use the programming guides if they weren't down in the archive?

Post reply on HN