MartijnBraam

I'm very much aware of Gentoo...but if you're going to compare basically any distribution is "poor man's Gentoo" because it's a collection of packages built from source files.

These are user-mode containers

Using wrappers doesn't really help that much because the difficulties are in the things that aren't covered anyway. Proot doesn't help for these issues, there's a long-standing open issue for that one.

Using docker would make the mixing and nesting of native and foreign architecture chroots only more difficult

I've also spend a bit of time thinking about recipe formats because I wanted to write down some recipes for my website. Ended up making a custom yaml-based format after looking at the available options and after a while scrapped that again to make a new toml-based format to make it a bit easier to write.

The format is pretty well demonstrated at https://git.sr.ht/~martijnbraam/fathub-data/tree/master/item... which renders to https://fathub.org/en/recipe/indonesian/main/mie-goreng.html

Some notable features is a mini DSL to refer to ingredients in the instruction text and also have parse-able times and temperatures so on the frontend it's easy to switch units with javascript. This is combined with a simple database of ingredient IDs which contains (translated) names and for some of them the density so you can swap the recipe between volume and weight measurements.

The issue is more the space needed by all the passives, the crystal, the massive flash chip. I can just about make it fit but now I have the issue that the phy needs some vias to the center pad for gnd but that's always right at the point where my ethernet jack is on the other side.

I just quickly tried to fit the whole rp2040+ethernet phy in the WIZ850io formfactor (mainly because I already used that module in some projects before) and have not yet been able to make it fit without using the more expensive jlcpcb features like burried vias. It would be very cool to have though since the W5500 really needs an update.

A lot of them are just networking SoCs with built in switching fabrics or the lower end ones have the low end router SoC from various manufacturers.

Mikrotik is one of the few brands that actually list this in the spec sheets.

I have a stack of them here, they are great to work with for their intended purpose but they are not that great if you want to run custom software.

I also grabbed a RB2011 diagram because it's a simple diagram that explains it well I think, the RB1100AHx4 is a better example technically since it's using the same switch chip but it's more confusing because they use the two CPU ports together and claim it's a 2.5Gbps link while it's two 1.25Gbps link and they ignore the encoding overhead.

The reason why I build this from scratch is that it that the expense is reasonable and this should end up in the FOSDEM video recording boxes and it has to fix a few issues specific to that design like it needing to expose 4 network ports to the front panel of the case but also be connected to the internal SBC. There's simply not that much space in the case to put passthroughs in the case to a switch to not have an external loop cable for the SBC and with a dumb switch the system can't be monitored anymore. Since quite a few of these boxes are built this becomes a reasonable solution (if you ignore design time, but this is volunteer work)

Ah yes the legendary sprite_tm, I've come across this while writing my own raspberry pi firmware to manage the switch over USB.

I don't think this support it, only regular STP and apparently MSTP

I meant the cost of just the switch obviously... It can hook up to whatever Linux machine you have running and I happened to have this one in the drawer.

The point of this was not to make the fastest or cheapest or most featureful switch available, it just had to fit in a case and none of the options have one port facing backwards so it doesn't require an ugly loop cable on the front of the final case.

It's also possible to make a managed switch with that card alone, there is a footprint for a NOR flash chip, if you load the netgear GS105E firmware on that (which is available on the netgear website) then it will be just a GS105E without leds and one port on the back.

$100? I paid roughly $80 for two of these and the price per boards will rapidly converge to ~$17 when increasing quantity.

This is more efficient if most of the traffic will get switched, seperate adapters is more efficient if most of it needs to be routed.

It all depends on how you select the parts. I've ordered a set of 5 boards for $12 total including shipping and assembly.

The DNG/TIFF spec is unreasonably flexible. It would be possible to add just a fixed precalculated header on the image data to make it valid DNG. The lack of filesystem is still a bigger issue.

Who hasn't accidentally thrown away a days worth of work with the wrong rm or git command? It is indeed significantly quicker to recreate a piece of work and usually the code quality improves for me.

I completely forgot to do that part, thanks for the reminder :)

The firmware is at https://git.sr.ht/~martijnbraam/mixolydian-4x4-fw and the hardware is at https://git.sr.ht/~martijnbraam/mixolydian-4x4

I've updated the blog post to include these links as well.

With my current code the latency should be lower than 10ms at least but I haven't measured it exactly yet.

I want to try adding AES67 support since the Teensy 4 has native Ethernet and the protocol isn't that complicated, but it isn't needed for this use case yet.

I think it's quite important to have a good relation with upstream developers. You don't want to get into the situation that Manjaro got in with Arch Linux.

Exactly, this is straight up pressure from GNOME to get systemd everywhere.

This looks like the DJI can bus protocol used for the accessory ports on at least the DJI RS2. There's some documentation for the headers in the protocol in the DJI RS2 SDK pdf.

This needs an option to also play coil whine based on CPU load to be perfect

To be fair the solution in Resolve to get "correct" colors is with decklink cards bypassing the entire OS graphics stack to deal with this. It's only somewhat recently that Resolve started getting support for getting a fullscreen view on a second monitor that's not a decklink.

I wish the sr.ht employees the best of luck with the AMS migration. Luckily git is decentralized enough that I've been able to practically do everything the last few days except that I can't push new releases of software to the canonical upstream repository.

The fpga probably only does routing, it certainly can't handle effects

Well that ends my app...

Sadly a paid standard though :(

The Behringer X-air mixer does everything realtime with a lot of processing for 18 channels on a bog standard 400Mhz arm core, no special hardware needed.

I actually use one of those setups semi-regularly made from Xilica hardware. It does what it needs to reasonably well but that's only enableing/disabling some microphones in a converence hall basically.

The interface is horrible, the feedback on the control surfaces is extremely slow, I don't want to see my meters and faders update at an ~1Hz rate...

Added to that is the licensing costs to actually be allowed to change the DSP routing in the thing which makes me want to replace it with opensource software :)

Teensies are very much overkill for a lot of projects. I have gathered a decent amount of random microcontroller boards now and it's just a lot of fun to make them do random things.

I have some arduino nano knockoffs to do the really simple pin toggle things, some ESP8266 modules for when I need to do wifi enabled things. A few wiznet modules if I need to add ethernet to any module and the new raspberry pi pico boards are amazing if you need more performance and a really nice SDK.

The Teensy is a bit more expensive than those but you get almost an order of magnitude more performance for that cost, the perfect product between the other MCUs and just putting a linux enabled SBC in your project