lukeh

There’s also AES70, or OCA (https://news.ycombinator.com/item?id=46934318). More popular in audio than video, something of a competitor to NMOS (although there are parts of NMOS that were very much inspired by OCA). There are open source C++, Python, JavaScript and Swift implementations as well as some commercial ones.

IOKit was designed to support CoreAudio from the start, cc gvdl.

That is a beautiful piece of industrial design.

XMOS is still keeping the Inmos dream alive, more or less!

This is also my recollection.

Small nitpick: malloc is not a system call.

And Mach 3 vs 2.5. And a 4.4BSD (well, *BSD) user land, although in fairness the original, never released NEXTSTEP 4.0 also had this.

Another approach is swift-java, which uses Swift macros and also supports Panama.

https://github.com/swiftlang/swift-java

That’s sad. One of the first pieces of (serious) software I wrote was licensed by HP for bundling with it. Didn’t use HP-UX a lot but it’s a pity we’re asymptoting towards a Unix monoculture.

Sequential doesn’t mean reentrancy safe, something which has bitten me a few times in Swift concurrency.

Not really! AES67 is essentially RTP with a PTP derived media clock. Connection description uses SDP and unicast signaling uses SIP. Just like VoIP.

Also I imagine TDM was first used in telephony.

Yup, similar for audio stuff.

Hard to say. May be related to CarPlay.

Oddly Swift appears to support QNX but there’s not much information about it.

https://github.com/swiftlang/swift-testing/issues/868

In the kernel’s process structure. See NOTES - https://man7.org/linux/man-pages/man2/chdir.2.html

The first version of MacOS X Server was based on an unreleased version of NEXTSTEP which in turn used 4.4BSD and Mach 2.5. Around BBB 1997-1998 a lot of userland was synced with bits from not just FreeBSD but the other BSD distributions, if my memory serves me correctly. MacOS X moved to Mach 3. That’s a very very long time ago though, and Apple obviously did a _lot_ of their own CoreOS engineering, things like launchd and XPC don’t have FreeBSD equivalents.

But hey, Darwin is open source so if someone wants to do go on a provenance archeological dig, it could be done!

I'm using it for the "business logic" (control plane) in an embedded device. Yocto integration may be useful to others doing same. [1]

[1] https://github.com/jeremy-prater/meta-swift

Still rocking a 2019 Mac Pro with 192GB RAM for audio work, because I need the slots and I can’t justify the expense of a new one. But I’m sure a M4 Mini is faster.

Yes, this is correct.

Yeah, emulating syscalls is fine until it isn’t. See WSL1.

I did try to build a medium sized project with this today. Still a lot of dependencies that will need to be updated for the differences between glibc and libc.

My understanding was Foundation and bits of CoreGraphics but not AppKit. Yellow Box required DPS.

Source?

I’m using it on Linux for an embedded product. No reason other than it’s a nice language that I am familiar with and productive in. The async/await features are quite nice too when you need to implement a lot of protocols / state machines.

I wrote one for Swift a few years ago, not sure if anyone else is using it but I am!

https://github.com/PADL/IORingSwift

I think XMOS can do it (the ones without the GEMAC) but I'm not exactly sure how much hardware assistance they have.

AU plugins work, the AU framework itself spins up a separate process to host the translated Intel plugin.

And here I was thinking someone had resurrected NeXT's issue tracking system.

XMOS (spiritual successor to Inmos) is still kicking around, it’s not without its challenges though, for the reasons you mention.

I worked on a Swift ASN.1 compiler [1] a while back (not swift-asn1, mine used Codable). I saved myself some time by using the Heimdal JSON compiler, which can transform ASN.1 into a much more parseable JSON AST.

[1] https://github.com/PADL/ASN1Codable

[2] https://github.com/heimdal/heimdal/tree/master/lib/asn1