My in-laws Kia did this for me. It got really shitty when it got darker and presumably had to use an IR camera. And I am tall so the angle might have been bad. It flagged me every minute. Even when I intentionally focused right ahead.
Tracking gaze is not immune to assorted failure modes.
I believe the OSS part of this oban library covers a lot of the celery feature set and is free as well. You can run multiple nodes and knock yourself out without needing more infra than the existing postgres.
Oban has been a free and OSS project in Elixir for ages. There are some more advanced bits that are paid and that sustains the people that make it.
If you like Celery. Great. This is a different take. I didn't enjoy celery last I needed it but never got super familiar.
I wonder if the limitation of the application processor and Linux starting is mostly a default for the standard OS or an actual limitation. Typically with a hybrid SoC like this part of the point is that you can use the micro-controller as the power efficient thing that decides when the bigger application processor should boot or not. I'd be curious to see if that's possible with this one.
Shipping only Debian to start is fine by me. It has to start somewhere. And they seem quite responsive to making it work with other things. James Harton is plugging away at getting it working with Nerves (https://nerves-project.org) and he has it running with Buildroot already. Current repo: https://github.com/jimsynz/buildroot
I share the sentiment that I don't trust that there won't be issues with Qualcomm over time. That company does have some pretty relevant chips though so I'm hopeful this means that we see them become more accessible on SBCs and embedded boards. I feel like they've been popping up more and more.
If they value this investment in Arduino they should now have a small wing of the company that pushes for things to be more open and even if they only consider that a marketing vector, if things are opened up for that purpose, quite possibly a win. But Arduino might also be absorbed into the amorphous megablob and this is the last we see. I hope not.
I don't think this board is that weird. It is just coming from the Arduino side and moving into Raspberry Pi territory. Personally I want to run Nerves on the application processor and get some practice with Zephyr on the MCU. Seems to already be supported: https://docs.zephyrproject.org/latest/boards/arduino/uno_q/d...
Also why no mention of the LED matrix. This is something RPi devices fail at. Providing som default way of neat output. First time plugging this in it starts doing fun stuff.
It seems to be RJ11 and they might be spec:ed slightly differently (thicker leads?) to power motors. I get the impression it is mainly to control what can be used in competitions.
I doubt it is Ethernet at all, so it wouldn't be Power-over-Ethernet. Just some useful connectors and wires making for an appropriate cable. Also seems like you can make your own perfectly fine. Or they might melt. I suppose try it.
I think Intel wants to stay alive so they are looking for a lifeline and the current administration wants to bring chip production into the US.
Intel's death would be very embarassing to that whole effort. So Intel has incentives (survival) and the administration has incentives (jobs in the US). The method is "whatever can be claimed as a win".
No US party seems particularly capable or keen to hold an ideological line but especially not the GOP from what I've seen. Not saying other countries have particularly impressive parties either. I'm less than thrilled with ours over here.
I've done this. The NIF worked as in that it ran and was a correct enough NIF. It did not work in terms of solving what I needed it to do. Iteration was a bit painful because it was tangled with a nasty library that needed to be cross-compiled. So when I made a change it seg faulted and I bailed.
I essentially ran out of patience and tried another approach. It involved an LLM running C code so I could check the library output compared to my implementation to make sure it was byte-for-byte.
The C will never ship. I don't have practice writing C so I am very inefficient at it. I read it okay. LLMs are pretty decent help for this type of scrap code.
I found out that Ampere is into edge and telco usage way after we got connected to do this work actually. I've been an Elixir dev and through that connected to Erlang for 7-ish years.
But I will certainly try to leverage my telco-connection to get to play with more of their kit if I can.
I was aware an Erlang being a unit though I'd forgotten what it measured. I Need to have my fun when giving titles to these things. Hope it fell within bearable tolerances.
According to Robert Virding at an unnamed bar in Berlin ~3 years ago they just wanted to be like Pascal in terms of picking a mathematician. But Ericsson Language certainly helped sell it internally, I'm sure.
This probably got second-chanced or something because I posted it over a week ago. Funny that this went up here since the follow-up is probably more in-depth.
Hope people enjoy it, both the technically interesting bits and the general goofiness of it all. I personally have enjoyed making the number go up.
I hope my co-fouunder on NervesCloud does some write-up on the allocator variations he has been trying. Every day he pops in and asks me to throw 5000 devices at the servers and see what they do. mimalloc, jemalloc and some others. Those two seem to do a better job with fragmentation for the BEAM than whatever we had by default, presumably from glibc.
No. It is not necessary. I don't think I said it was.
You can absolutely simulate more IoT-devices. But in this case I don't have to simulate receiving OTA updates, rebooting, keeping state. It has some upside but it isn't the reason I've done it.
I think I mentioned that in both this and the previous piece that I started out doing the VMs for fun and that's still kind of the central point. "What can I do with 192 cores?" We'll have a good use of the artifacts of this work for testing the framework itself in ways where devices are useful.
As you say, if I wanted to stress-test the OTA service for real I could definitely just set up some libraries to make multiple connections instead of starting the whole machinery. You can make a lot more connections, throw a lot more work at the system. And depending on how fancy you want to get you can simulate a lot of device behavior.
Given that I happened to have a couple of thousand full-fidelity devices in my pocket we got some incidental testing of the service.
Well I applaud their ability to get that bag. But in terms of raising the floor for a lot of people, this is not that.
I don't feel strongly about these salaries beyond them being an indication of deep dysfunction in the system. This is not healthy, for a market or for a society. No-one should be paid these amounts but I don't care about these developers because they don't run the system.
I've benefited from devs being paid well. Not that well. But same thing in concept.
Podcasting on beamrad.io and regprog.com