lukeh

It’s to do with trademark usage as I understand it.

I tried to sell XAD, the Active Directory workalike I wrote 2002-2006, to Sun. Would’ve integrated nicely with SunDS (a big part consisted of SLAPI plugins). Was in touch with Jonathan Swartz, but no dice. Sold it to Novell instead. Ironically ended up porting SLAPI to eDirectory to integrate it.

It's possible to have a career in classical music (I have one, for some definition of classical). But I suspect that streaming income from passive listeners (i.e. not fans) will disappear once the streaming services can eliminate those pesky songwriters and artists.

CM4s are very tricky to find right now. Should have stocked up… :( (I’m building an embedded product and it’s probably still the right choice, just more expensive and harder to find than when I started the project in 2024.)

Ha, I quite enjoy doing this in comments or commit messages where practicable. But, that's just a few lines. :)

Ha yes, PC XT clone here! And then eventually, a 486SX around 1993, which was my first foray into Linux.

Correction: Apple never used X as a native window system, nor did NeXT. The did provide the hooks for an X11 server to run on macOS. From memory this was due to requests from the academic community at the time.

You might want to make the port index instead a bit mask, that will let you support multicast and also selective broadcast flooding (although if you have limited space you’ll likely make broadcast flooding the default).

Toyota is using Flutter I believe.

I haven't used it, but there's also Avocado OS [1]. Myself, I use Yocto for our embedded build. It's not perfect but for our application, which involves building a bunch of software that uses both Swift and Flutter for an embedded audio product running on a RPi CM4, it works just fine. Shout out to Mender for A/B updates.

[1] https://www.peridio.com/avocado-os

Also it’s nice for things like SPI which have no user space non-blocking API.

Microsoft Surface Dial is nice. You'll also need to write a driver...

Well, also to be clear, I did find a great hardware engineer to design the board based on my somewhat outrageously over-engineered specifications. And I have been working on it for three years and haven't shipped.

It's a great question, and indeed a centralised mixer is pretty much the common approach as it allows for economies of scale. I guess there's a philosophical bent, the same reason I run my own SMTP and IMAP servers instead of Gmail: I like distributed systems. The practical bent is that, in my studio (the target market!), I only really need one or two of these, so the economy of scale doesn't apply. And interestingly with things like Lawo .edge we are seeing distributed mixers come into fashion.

And as you point out, being protocol-agnostic means that it can fit into a lot of scenarios, which might be useful (say) if it were to be a hire product.

Feel free to drop me a line if you want to chat more, I'm lukeh at padl dot com.

Re: yours, that is a _long_ boot time. Boot time on mine isn't great, but I think I'm just going to have to accept that as an artefact of U-Boot, Linux, and an Ethernet switch chip that takes some time to initialise.

Anyway, re: my widget: it's a personal monitor mixer [1], something one might use in the studio or live, not dissimilar to existing products in the market, except: it supports up to 64 channels of Dante or AVB natively, it has a super nice (HiDPI) UI, and absolutely everything is remote controllable using OCA (AES70) or OSC. I even have a MCP bridge so you can let Claude manage it ;) [2]

The hardware is a custom board that hosts a CM4 SOM (for the control plane and UI), a Brooklyn 3 SOM (Dante), and an XMOS which runs the mixer firmware and AVB stack. There are also some nice AKM DACs, and a Marvell Ethernet switch chip that connects the SOMs and XMOS to two external Ethernet ports.

The CM4 runs Yocto which manages the switch in DSA mode (i.e. hardware offloaded bridge), runs the gPTP and SRP stacks for AVB, the OCA daemon, and the UI (which is just a regular OCA client). SSH is presently enabled but there's not a lot to do once you're in there. Working on secure boot at the moment with U-Boot and dm-verity.

[1] https://forums.swift.org/t/an-embedded-audio-product-built-w... (note, older prototype)

[2] https://www.linkedin.com/posts/lukehowardmusic_heres-a-long-...

Well, it started off simpler, but, yes.

I’m building an audio device. It runs Linux for the control plane (it’s just a CM4 running Yocto, maybe I’ll leave SSH running on production units, maybe not, haven’t decided yet). No audio passes through the CM4, there’s a dedicated FPGA and MCU for that. It’s been a fun project, first time hardware for me, feel free to ask my anything!

SIP is anti-feature for a certain class of users, but the right tradeoff for most consumers. At least you can disable it. And even as a developer I leave it enabled.

Right, and I suspect as things get more complicated (and you have to ship), abstractions get leaky.

There was also the Java-like syntax for ObjC but I don’t think that ever shipped.

Yup, even with a hard drive the m68k turbo slab was no speed demon. Wasn't too bad on HPPA though.

Still rocking a 2019 (Intel) Mac Pro here, all slots filled with various Pro Tools and UAD DSP cards, SSD, GPU, etc. I'm planning to get as much mileage out of it as I can. I'm sure a Studio would be more performant, but the Thunderbolt to PCIe chassis are not cheap.

I hear you. Actually I read this thread because we’re using jemalloc in an embedded product. The only way I found to work on interesting problems here was to work for myself. (Having said that I think Apple might have some security research in Canberra? Years ago there was LinuxCare there and a lot of smart people. But that was in 2003…)

To some degree. There are _many_ SwiftUI clones that support other frameworks such as Gtk and Windows, with varying states of maturity. Or you can share the business logic and write the UI natively in Swift.

It does like to weasel in if you let it write a commit message, and even after rewriting and force pushing, it seems to hang around on the GitHub contributor list.

Swift actually has excellent C++ interop [1] (compared to other languages, but, I guess, not good enough for Ladybird).

[1] https://www.swift.org/documentation/cxx-interop/

Also things like support for GSS-API pre-authentication mechanisms (so, you can use an arbitrary security mechanism such as EAP to authenticate yourself to the KDC), the new SAnon mechanism, pulling in some changes from Apple's fork, replacing builtin crypto with OpenSSL, etc. Lack of release has been typical OSS lack of resources: no one is paid to work on Heimdal full time.

You also need synchronization to mix sources (common in any production) without incurring the latency and resampling of asynchronous sample rate conversion.

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.