diesel VS moonfire-nvr

7. Diesel

First of all thanks for making this great tool. As it happens I currently toy around with using it for diesel-cli releases. See the WIP PR here. I think diesel-cli is a good example of a tool that depends on system libraries as it needs to link native database drivers, so this new release is welcome. Defining the dependencies seems to allow easily building things on x86_64-unknown-linux-gnu and x86_64-apple-darwin. It seems to pick up everything in the right way there.

I did look at mysql initially. Then I started checking other crates. Diesel is an Object Relation Model (ORM), I'm not yet keen on taking on the complication of learning ORM, I give this crate a pass in the meantime.

I would recommend people look at diesel from Rust for how nice it could be. https://diesel.rs/ Look at the complex queries example. So much more readable and easier to understand.

Lemmy is written in Rust using Actix Web and Diesel.rs.

https://actix.rs/

https://diesel.rs/

for psql i feel like there's a wealth of things to choose from, like diesel perhaps https://crates.io/crates/diesel

Essentially you would need to implement Backend + Connection (+ the whole bunch of helper traits) for this type. That's ~1kloc for all of that. The PR that introduced this feature has more details on the exact implementation that's generated.

diesel

some things are barely expressible in the type system. For example, window functions are unavailable (the issue is six years old). You can use raw SQL, but then it has the same problems sqlx has

Have you considered using a library such as sqlx or Diesel? They’ll handle this for you and supports multiple backends

How do folks test timing-related stuff with MSW? AFAIK, MSW doesn't get along with jest.useFakeTimers. It drives me nuts; I have a bunch of disabled tests in an open-source project and at least one that is flaky because it uses real timers where I'd like to be using fake timers. [1, 2]

I've been thinking about ripping out MSW from my tests in favor of my own API-level mock for this reason. But it seems like many other folks are happy with MSW. I have to assume there's something I'm not getting. I'm a fish out of water with frontend stuff in general...

[1] https://github.com/scottlamb/moonfire-nvr/blob/5ea5d27908f1a...

[2] https://github.com/scottlamb/moonfire-nvr/blob/5ea5d27908f1a...

> I wonder how hard it would be to run your own streamer pipeline or whatnot on these things?

Agree with the_biot: The actual streaming component is not too hard. If this were the biggest problem, I'd be thrilled to contribute to an open source streaming server to complement my open source NVR. [1] The driver situation is indeed a bit harder—these things don't just have mainline Linux support with v4l2 for the video input and encoder. Or open source drivers of any kind to crib from AFAIK.

The biggest problem IMHO is that there just aren't any good cameras to buy, even completely ignoring the software aspect. I want a camera that:

1. doesn't support genocide. Nothing that involves Dahua, Hikvision, or Huawei. See IPVM articles on the subject. And a lot of available cameras are relabeled Dahua/Hikvision stuff and/or use Huawei components.

2. is legal for sale / authorized for use in the US. (See the Secure Equipment Act of 2021.)

3. has good night mode performance: IR/day switch, a sensor that is at least 1/1.8", reasonable resolution (somewhere from HD to 4k).

4. has an "eyeball" or "turret" form factor rather than "bullet". The latter seems to really attract spiders, so you end up with a really nice video of a web...

5. supports PoE.

6. is weatherized (IP66 or so).

7. is reasonably priced.

If you ignore #1 and #2, there's some nice hardware out there, but I'm not willing to do that. If you ignore #3, there are a few options (GeoVision, maybe Reolink, maybe Hanwha.) If you ignore #4 and #7, there might be a couple (Axis, maybe Hanwha.) Nothing that ticks all the boxes.

Hard to get excited about investing a lot in the software when the hardware isn't there.

[1] https://github.com/scottlamb/moonfire-nvr

But I would definitely avoid compiling Rust on the Raspberry Pi 3 if you can avoid it. I set up a Docker cross-compile environment for this reason.

Moonfire may be what you're looking for otherwise.

That last bit's not quite true: another option is to just use the cameras as a dumb stream source and do all the fanciness in an open source NVR. I've been slowly working on moonfire-nvr. Help welcome!

Moonfire

ONVIF isn't really that important IMHO.

Configuring your camera is something you do rarely, and if you have to put up with some crappy web interface, proprietary plugin, or desktop software for it, oh well. So the ONVIF SOAP APIs aren't really the most important part.

The most important part is RTSP. Many of these have astonishingly poor RTSP implementations. See https://github.com/scottlamb/moonfire-nvr/wiki/Cameras:-Reol... for some of what I'm talking about. That ONVIF page says everything is fine for several Reolink models, but I don't believe it!

If you don't need restreaming or mjpeg support, check out moonfire. It's the only alternative I'm aware of that doesn't use FFmpeg.