Since the article assumes familiarity with the DDX3216 (or the lack of need thereof), I had to look it up: the DDX3216 was released in 2002, assuming this Sound on Sound review is contemporary: https://www.soundonsound.com/reviews/behringer-ddx3216
More background information: the Behringer brand has always very intentionally targeted the budget-conscious customer. One way they have achieved their low price targets has been to straight-up clone competitors’ products, building them with cheaper components and cheaper labor.
But they also do their own R&D, both within, erm, “familiar” physical form factors and in totally novel designs. I have no idea if this product is specifically inspired by any other studio-in-a-box, but my gut reaction is that no other competitor in this space would have sourced a damn 386-compatible CPU for such a product line in 2002.
My guess is Behringer got a great deal on some second-source manufacturer’s last stock of 386s (maybe in bankruptcy?), and only that kind of deal would have enabled Behringer to enter this market.
If anyone has a more informed take, I would love to waste time reading about the history of this thing!
but my gut reaction is that no other competitor in this space would have sourced a damn 386-compatible CPU for such a product line in 2002.
These days ARM and Linux seems to be the go-to, but DOS and embedded x86 has a long history stemming from the glory days of the IBM PC architecture and the openness of its software ecosystem. You could easily write and test your application on a PC (perhaps with additional peripheral card(s) that would be integrated into the target) and then directly run the binary on the target device.
There is a precedence for embedding x86 in music hardware. Roger Linn's original LM-1, LinnDrum and Linn 9000 (http://studiorepair.com/gallery/Linn/9000/index.htmlhttps://www.elektronauts.com/t/the-seminal-groovebox-linn-90...) were full 8088 PCs with custom cards. Successor MPC60 designed by Roger Linn for Akai was powered by Intel 80186. Final Linn's sampler, the legendary Akai MPC3000 is based on SOC form (NEC V53) of NEC V33, a 80186 compatible with microcode replaced by hardwired logic giving it clock for clock performance of 286 and immunity from Intel Microcode lawsuits.
I’m not your child, and that’s false, it’s literally one key to change in the settings. That allows you to select the exact scaling factor, not macos’s “more text”/“less text”.
Have you ever tried to write HiDPI-aware Win32 code? I suggest enabling HiDPI in Control Panel sometimes and marveling at how many Win32 apps just don’t notice and draw as postage stamps.
Mac OS X 10.4 tried the same thing (Quartz2D scaling) and it was so damn difficult that they threw it out and went for simple 1x/2x/3x auto-scaling. Even 3x was a challenge because of pixel alignment.
You’re thinking of the Bonjour sleep proxy. Normally if you tried to ssh to `mymac.local`, but your Mac was asleep, nothing would respond to the mDNS broadcast for `mymac.local`. If it had been long enough that your local mDNSResponder cache had expired, you’re out of luck.
The AirPort would take over for your Mac and respond to mDNS queries on behalf of its hostname. (I believe it would also repeat the service records.) So your lookup of `mymac.local` would resolve to your Mac’s last IP address, and the AirPort would send the WoL packet to your Mac’s MAC, hopefully in time for your TCP connection to succeed.
How is it not lights-out? You could remotely power on/off the servers (XServe only). Other Macs could not do this, as they did not have the separate LOM network interfaces, etc.
I managed a bunch of XServes for a while, they were incredibly good hardware. The Mac Server software kinda sucked (not the LOM stuff, it was as good as any of the LOM from Dell, which is to say, not amazing, but workable).
Any implication that OS X Server could only run on Xserve was inadvertent. I mentioned the special OS to preempt discussion of whether Xserve was, strictly speaking, part of the Mac product line.
No. The intention is most likely to get automated LLM based code review mechanisms to stall out.
Normally you’d want that to result in a fail and a subsequent rejection.
But because the team who made the review agent and pipeline in my example had many false positives at first they resorted to a fail-open and report setup (not uncommon).
So when the LLM hit this bit and then stalled out the pipeline pushed the code to their Artifactory repo anyway resulting in it being used internally -> exfil of secrets and repos etc.
It’s more about bad design but bad design is pretty common unfortunately.
Title buries the lede: the owner of the account under which the agent operates claimed to have likely had his account compromised, and the maintainer investigating actually seems to agree this is likely.
reply