Live data from Hacker News

macOS Internals

gist.github.com

121–130 of 146 posts

Re: macOS Internals

#121

Earlier quoted context omitted.

This updates the OS and related content.

> and related content That is a very interesting if not a prodigiously strained hand-wave of a solution to GGP's complaint, "that the OS has no way to keep apps up to date," as Safari, Mail, Contacts, Calendar, Maps, Music, Photos, Messages, FaceTime, Notes, Preview, TextEdit, KeyNote, Pages, Numbers, GarageBand, Quicktime Player, Activity Monitor, Terminal, Console, Disk Utility, and hundreds of other bundled applic…

You're calling my comment strained, but somehow missed the fact that all of the things you mentioned are shipped by Apple and updated basically together? The comment mentions Sparkle as "patching up this gap" so it's very clear what they meant: third party applications. Nobody is asking for updates for "every application there is", but providing an API to update third-party apps. MacPorts, despite getting significant investment in the past from Apple, is now definitely a third-party solution and not an system API.

Re: macOS Internals

#122
post #61

Earlier quoted context omitted.

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.

Seriously I wish /proc was available as a tree of JSON documents as opposed to all these different ad hoc plain text formats. It would make using /proc a lot easier and more reliable

Could be unnecessarily costly unless the files are written ahead-of-time. I propose some kind of GraphQL-like interface to only read what you need.

Re: macOS Internals

#123

Earlier quoted context omitted.

Seriously I wish /proc was available as a tree of JSON documents as opposed to all these different ad hoc plain text formats. It would make using /proc a lot easier and more reliable

Could be unnecessarily costly unless the files are written ahead-of-time. I propose some kind of GraphQL-like interface to only read what you need.

/proc files are generated on-demand as you read them.

Generating JSON couldn’t be significantly more costly than the current ad hoc plain text formats are

Re: macOS Internals

#124
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.

How does reversing WindowServer allow you to make rcmd control Stage Manager? Figuring out which CG calls WindowServer is making? Wouldn't these calls fail unless you have special entitlements?

This is about a work in progress for a version of rcmd that I intend to distribute outside of App Store. As you guessed, calling private functions is not allowed by the App Store review guidelines.

I want to add hotkeys for creating Stages with the needed windows, because as it is right now, mousing around to move windows is too slow for me.

I'm looking inside SkyLight.framework and WindowManagement.framework to find the right sequence of SLS* or CGS* functions that does what I need.

Re: macOS Internals

#125
post #74
post #70

Earlier quoted context omitted.

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

That's a very refreshing attitude. I had heard of Lunar but was reluctant to try it. Lately my policy has been "the less software the better" precisely because of how predatory most software is.

But not your software, it seems!

Your privacy policy has made me think it would be a good idea to try and probably buy your app if it works for me.

Thanks for being one of the good ones!

Re: macOS Internals

#126
post #116

Earlier quoted context omitted.

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

Personally, my biggest gripe with the Swift DX, or anything DX related on macOS, actually is with Xcode.

AppCode or bust.

Re: macOS Internals

#127
post #116

Earlier quoted context omitted.

Personally, my biggest gripe with the Swift DX, or anything DX related on macOS, actually is with Xcode.

AppCode or bust.

Sadly it doesn’t enable you to totally bypass Xcode. And JetBrains is sunsetting it: https://blog.jetbrains.com/appcode/2022/12/appcode-2022-3-re...

Re: macOS Internals

#128

Earlier quoted context omitted.

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

I think modern "kids" (who now are in their early 40s perhaps!) don't quite get how useful the spacial finder was to non-technically aligned people. "I left it right here" is a huge piece of memory that our brains have developed over millennia, and the spacial finder played right into that. The "it's in the directory listing in terminal" or "spotlight will find it" or "what is a file" don't really compare, even if th…

Funnily enough, learning how to computer from Chromebooks and tablets have made modern kids incapable of understanding the spacial metaphor at all. Their navigation is entirely search-centric.

Re: macOS Internals

#129

Earlier quoted context omitted.

> and related content That is a very interesting if not a prodigiously strained hand-wave of a solution to GGP's complaint, "that the OS has no way to keep apps up to date," as Safari, Mail, Contacts, Calendar, Maps, Music, Photos, Messages, FaceTime, Notes, Preview, TextEdit, KeyNote, Pages, Numbers, GarageBand, Quicktime Player, Activity Monitor, Terminal, Console, Disk Utility, and hundreds of other bundled applic…

You're calling my comment strained, but somehow missed the fact that all of the things you mentioned are shipped by Apple and updated basically together? The comment mentions Sparkle as "patching up this gap" so it's very clear what they meant: third party applications. Nobody is asking for updates for "every application there is", but providing an API to update third-party apps. MacPorts, despite getting significant…

> You're calling my comment strained, but somehow missed the fact that all of the things you mentioned are shipped by Apple and updated basically together?

Again, you're handwaving and intentionally failing to acknowledge that Safari and GarageBand and all the other applications are applications, like any other a team may develop and/or a user may use source to build, or download and run an installer, or drag and drop a bundle, far more complex than, technically speaking, most available applications, and very big programs to the non-technical. Yet in regards to the operating system, not in the remotest way, "and related content."

Safari is not and Music and Photos are not related to the OS. They have nothing to do with the kernel, nothing to do with core services, nothing to do with directory services or App Kit, they're just applications. Apple bundles applications, and this is entirely irrelevant to the operating system "and related content." The bundled applications have nothing to do with the OS, which will keep chugging along whether they're there or not.

The salient detail here that has been lost on you since my initial comment is that softwareupdate manages a metric sh!tton of packages and keeps them updated with very little effort from the operator, like any good package management system should, and not merely "updates the OS and related content," an astounding simplification that misses the fact that it is a package manager, just like FreeBSD ports, just like pkgsrc, just like yum, just like RPM, aptitude, Ubuntu Software Center, Windows Package Manager, and just like MacPorts, AppStore, and Cydia, and hundreds if not thousands of other available package management systems.[1]

softwareupdate isn't just some cute Apple product, and Apple certainly didn't invent or pioneer package management; softwareupdate manages thousands if not tens of thousands of packages that have absolutely nothing to do with a computer operating system. It isn't called "macOS Update," it is called softwateupdate for patently obvious reasons.

> MacPorts, ... is now definitely a third-party solution

I could have sworn I stipulated it was third party. Didn't I?

> and not an system API.

What are you driving at with this straw man?

[1] https://en.wikipedia.org/wiki/Package_manager

Re: macOS Internals

#130

Earlier quoted context omitted.

Yeah NetWare used to boot DOS then load their kernel over it. I feel like computers used to be cooler.

Well, that is it worked on Windows as well ( up until Windows ME ), load DOS first and then Windows. You could still do it that way if you want. Windows 11 needs a boot loader. No reason you cannot write a DOS based one. The comment about game.exe above probably refers to the days of “DOS Extenders” that games were based on. You would launch a game from DOS and, instead of just running a 16 bit DOS executable, it wou…

dos.exe was kind of referring to how a lot of games would just completely ignore DOS even before the days of protected mode and 32 bits, im going back to the 8088 days.

but yeah same idea.

actually now that i remember it, my first linux was a copy of ... i think Dragon Linux? It used Dos as a bootloader, it ran off the existing DOS FAT filesystem so you didnt have to mess with partitions, and it dealt with the filename-too-short issue by keeping a dot file in each directory with a list of the 'real' linux long names and how they matched the DOS fake shortnames.

but like even windows and linux, they are having layers and layers of abstractions. trying to do anything in X11 or win32 API calls, compared to the before-times where you just write directly into RAM at A0000 to draw pixels.. there is something about that that is very interesting.

Post reply on HN