Skipped through the first pages and I really like your approach. Avoiding to use „magic“ libraries which abstract away a lot of the intricacies the lower levels is helping with the understanding.
I started my journey to develop my own little OS (https://github.com/jbreu/jos ) based on phil opperman‘s tutorial but quickly diverged from his exactly due to his use of such libraries.
Anyone can recommend a good quality camera without spyware and ideally open sw stack.
I am willing to do it myself with little soldering etc.
that’s one rabbit hole didn’t enter yet
Depending on your definition of "good quality", you might find this project useful: https://thingino.com/
Most cameras on that list are low cost, typically with 4-5MP sensors. They don't compete on the high end in terms of image quality but you will have an open source firmware stack with root access over SSH.
Models from Eufy, Cinnado, Jooan, TP-Link, WUUK, Galayou are relatively easy to source on Amazon or Aliexpress.
The best option is just to assume any IPCam is unsafe and firewall them off in my experience; even with a fully open source camera stack connecting it directly to internet is not that great a practice. Put them on a no internet access VLAN and you can largely buy whatever cheap IPCams you want, etc etc. If you want remote access you should expose the server running the camera management software/NVR securely, not the cams.
This is basically how I run Frigate at home today, with only the NVR able to reach the camera IPs on my no web access “internet of nothing” VLAN.
It's not open source but used Axis cameras are pretty cheap and have rtsp and onvif support. Those mostly come from commercial installs and can be configured offline using a web interface.
Nothing good has an open software stack. There are some brands (eg: Axis, Bosch, Hanwha), that support 3rd party apps that can run on the camera and perform various tasks, including AI applications.
Any product that would fall under the good quality segment is primarily targeted at the commercial market, and nobody there is looking for open software.
There's https://openipc.org/ , if open source camera firmware is of interest to you. I actually ordered a few supported IP camera modules (basically complete IP cameras but without the case) from Aliexpress and tested that I'm able to compile a firmware, I shall see if I get it working once they arrive.
It's not quite clear to me what the firmware is actually able to do, though. Apparently its motion detection is very basic, though, so you'd need to use e.g. Frigate for that.
Thought about zero-copy IPC recently. In order to avoid memcopy for the complete chain, I guess it would be best if the sender allocates its payload directly on the shared memory when it’s created. Is this a standard thing in such optimized IPC and which libraries offer this?
IPC libraries often specifically avoid zero-copy for security reasons. If a malicious message sender can modify the message while the receiver is in the middle of parsing it, you have to be very careful not to enable time-of-check-time-of-use attacks. (To be fair, not all use cases need to be robust against a malicious sender.)
On Linux, that's exactly what `memfd` seals are for.
That said, even without seals, it's often possible to guarantee that you only read the memory once; in this case, even if the memory is technically mutating after you start, it doesn't matter since you never see any inconsistent state.
It is very easy for zero-copy IPC using sealed memfd to be massively slower than just copying, because of the cost associated with doing a TLB shootdown on munmap. In order to see a benefit over just writing into a pipe, you'd likely need to be sending gigantic blobs, mapping them in both the reader and write into an address space that isn't shared with any other threads that are doing anything, and deferring and batching munmapping (and Linux doesn't really provide you an actual way to do this, aside from mapping them all in consecutive pages with MAP_FIXED and munmapping multiple mappings with a single call).
Any realistic high-performance zero copy IPC mechanism needs to avoid changing the page tables like the plague, which means things like memfd seals aren't really useful.
Thanks for the reference! I had been wondering if there was a way to do this on Linux for years. https://lwn.net/Articles/591108/ seems to be the relevant note?
I think he meant what's the scenario where you're using IPC via shared memory and don't trust both processes. Basically it only applies if the processes are running as two different users. (I think Android does that a lot?)
I've been meaning to look at Iceoryx as a way to wrap this.
Pytorch multiprocessing queues work this way, but it is hard for the sender to ensure the data is already in shared memory, so it often has a copy. It is also common for buffers to not be reused, so that can end up a bottleneck, but it can, in principle, be limited by the rate of sending fds.
Btw, with the next release iceoryx2 will have Python bindings. They are already on main and we will make it available via PIP. This should make it easier to use with Pytorch.
I've looked into this a bit - the big blocker isn't on the transport/IPC library, but the serializer itself, assuming you _also_ want to support serializing messages to disk or over network. It's a bit of a pickle - at least in C++, tying an allocator to a structure and its children is an ugly mess. And what happens if you do something like resize a string? Does it mean a whole new allocation? I've (partially) solved it before for single process IPC by having a concept of a sharable structure and its serialization type, you could do the same for shared memory. One could also use a serializer that offers promises around allocations, FlatBuffer might fit the bill. There's also https://github.com/Verdant-Robotics/cbuf but I'm not sure how well maintained it is right now, publicly.
As for allocation - it looks like Zenoh might offer the allocation pattern necessary. https://zenoh-cpp.readthedocs.io/en/1.0.0.5/shm.html TBH most of the big wins come from not copying big blocks of memory around from sensor data and the like. A thin header and reference to a block of shared memory containing an image or point cloud coming in over UDS is likely more than performant enough for most use cases. Again, big wins from not having to serialize/deserialize the sensor data.
Another pattern which I haven't really seen anywhere is handling multiple transports - at one point I had the concept of setting up one transport as an allocator (to put into shared memory or the like) - serialize once to shared memory, hand that serialized buffer to your network transport(s) or your disk writer. It's not quite zero copy but in practice most zero copy is actually at least one copy on each end.
(Sorry, this post is a little scatterbrained, hopefully some of my points come across)
YouTube settings are notoriously volatile even on the same device and being logged in. Subtitles are enabled every other day all of a sudden without any need (even for my natural language content).
Since they rolled out the auto-trabslation thing the same happens, I have to switch to original English every few days.
I started my journey to develop my own little OS (https://github.com/jbreu/jos ) based on phil opperman‘s tutorial but quickly diverged from his exactly due to his use of such libraries.
reply