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

91–100 of 146 posts

Re: macOS Internals

#91

Post by dhosek »

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

I think that’s one of the advantages of coming into computing in the early 80s. Computers like the Apple ][ were completely understandable by a single person (and it’s still my mental model for how a computer works 40 years later).

Re: macOS Internals

#92

Post by vernal »

vaughan wrote: post #4

History is such a great way to learn anything. It’s interesting - like a mystery revealed, but also provides the why - why things are the way they are. I was looking into accounting the other day, and you can go back to the first document that mentioned credit and debit and introduced modern accounting. There are so many topics like this that seem confusing and arbitrary but it all began extremely simply and pragmati…

What was that first accounting document?

Re: macOS Internals

#93

Post by robotresearcher »

eric-hu wrote: post #89
ZephyrBlu wrote: post #72

Earlier quoted context omitted.

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.

I don’t know that code was always text, but I’m thankful to have been born in the days after programming assembly on punch cards was not the only way.

The early days of programming was also text in the form of pencil on paper, then the program was transferred to the machine in various manual ways, such as flipping toggle switches, followed by punch cards. But the actual process of writing programs was always text. Even before electronic computers people wrote down algorithms to be executed by themselves on paper, or by rooms full of people whose job title was ‘computer’.

Re: macOS Internals

#94

Post by KerrAvon »

Kwpolska wrote: post #21

There are also some amusing writings not included here about modern macOS changing things in a way Siracusa dislikes. For example, mandatory file extensions (written in 2001, when the Internet was a thing and file extensions were required for all file exchanges) [0] or the Spatial Finder saga [1] about missing an antiquated way to make a mess on your screen and pretend to be managing folders. [0] https://arstechnica.…

He’s right about the spatial Finder. The Mac OS 9 Finder is still a better user experience. The OS X Finder only become marginally usable when they added the sidebar so that you had some starting reference points; it was much improved with Spotlight because you could then find things without spatial reference points.

But I still maintain that adding the NeXT browser view to the OS 9 Finder would be the perfect experience. The OS X Finder went down this awful .DS_Store-strewn half-assed path and it’s still just the weirdest set of choices imaginable.

Re: macOS Internals

#95

Post by KerrAvon »

pasc1878 wrote: post #71
ilkkal wrote: post #16

Earlier quoted context omitted.

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…

Minor clarification: two apps can embed different, incompatible versions of the same framework without versioning — the versioning is a NeXTism that allows the system vendor to ship a newer, binary incompatible version of the framework.

NeXT used it with AppKit for a few releases, but when they came to Apple they realized it would be impossible to support something like Aqua with the desired UX without having to update all the versions of the framework every release, which would defeat some of the purpose, not to mention exploding the QA matrix.

Re: macOS Internals

#96

Post by Maursault »

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…

> It's very weak that the OS has no way to keep apps up to date except via the store, which then introduces tons of other problems.

/usr/bin/softwareupdate [1]

[1] https://ss64.com/osx/softwareupdate.html

Re: macOS Internals

#97

Post by robertlagrant »

layer8 wrote: post #84
robertlagrant wrote: post #25

Earlier quoted context omitted.

Agreed. This is why often reading a Wikipedia page is the worst way to learn something. The best way is to get a teacher to tell you the relevant history leading up to the thing, and it makes much more sense.

Though many Wikipedia pages have a History section doing exactly that. (More should have one.)

Well, they have a history section, but I don't often find it does exactly that.

Re: macOS Internals

#98

Post by pasc1878 »

KerrAvon wrote: post #95
pasc1878 wrote: post #71

Earlier quoted context omitted.

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…

Minor clarification: two apps can embed different, incompatible versions of the same framework without versioning — the versioning is a NeXTism that allows the system vendor to ship a newer, binary incompatible version of the framework. NeXT used it with AppKit for a few releases, but when they came to Apple they realized it would be impossible to support something like Aqua with the desired UX without having to upda…

True for Apple/NeXT Frameworks or others used by a lot.

I think versioning could work if your framework is not used by many apps - the link structure and version number is still there but I have not tried for 20 years.

The correct current practice is as you say to embed the framework in the app at build time so you don't link to outside non Apple Frameworks.

Re: macOS Internals

#100

Post by ideologysec »

ris58h wrote: post #20

Does anybody know how to force sandboxing for a 3rd party app?

You can write your own sandbox profile if you're so inclined... but not easily, and you can't force it into a container in the Library folder, for example.
Post reply on HN