gdbstub
moonfire-nvr
Our great sponsors
gdbstub | moonfire-nvr | |
---|---|---|
8 | 31 | |
269 | 1,084 | |
- | - | |
6.1 | 8.4 | |
3 months ago | 13 days ago | |
Rust | Rust | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
gdbstub
-
A fast STM32 embedded system emulator implemented in Rust
now integrate gdbstub to support debugging code inside the emulator :)
-
Noctane: a highly WIP original PlayStation emulator
Shameless plug, but have you considered integrating gdbstub rather than rolling your own debugger? I know a couple folks out there have successfully integrated it into their PS1 emulators with great success.
-
Things I hate about Rust, redux
I've worked really hard to keep gdbstub panic free in its minimal configuration, going so far as to write some informal scripts that parse rustc's asm output to scan for the presence of panicking code paths.
-
gdbstub 0.6: An ergonomic, #![no_std] implementation of the GDB Remote Serial Protocol in Rust - now with async support!
crates.io | docs | repo
-
Announcing Loadstone, a secure bare-metal Rust bootloader
As a totally shameless plug, I'm the maintainer of gdbstub, a bare-metal, no_std, no_alloc, and size-optimized implementation of the GDB Remote Serial Protocol. One of the major changes slated for the upcoming release 0.6 is support for a new state-machine based API, which makes it possible to drive gdbstub directly via bare metal interrupt handlers (i.e: send/recv data over UART, handling breakpoints via the undefined instruction trap interrupt, etc...).
-
What's everyone working on this week (23/2021)?
Continue working on a new API in gdbstub that'll make it easier to use directly from an interrupt handler when debugging code in a no_std, bare-metal OS environment.
-
Designing a new architecture for Rspotify based on trait inheritance, need opinions
I ran into almost this exact same problem while working on gdbstub, whereby I an API that allowed users to mix/match protocol features however they wanted, while also preventing users from accidentally implementing mutually-exclusive features. Moreover, I wanted to have a "zero cost" way to enable/disable API features without relying on cargo features. The solution I came up with is something I've been calling "Inlineable Dyn Extension Traits", or IDETs.
moonfire-nvr
-
Mock Service Worker(msw) releases 2.0
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...
-
Alternative open firmware for your IP camera
> 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.
-
Installing Rust in a Raspberry Pi 3A+
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.
- Self Hosted CCTV/Home Security
-
NVR Suggestions & Experience...Any decent alternatives for MotionEye?
Moonfire may be what you're looking for otherwise.
-
What's everyone working on this week (50/2022)?
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!
-
surveillance station
Moonfire
-
Managing and using ONVIF IP cameras with Linux
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!
-
camera recording software recommendations
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.
What are some alternatives?
Shinobi - :peace_symbol: :palestinian_territories: Shinobi CE - The Free Open Source CCTV platform written in Node.JS (Camera Recorder - Security Surveillance Software - Restreamer
frigate - NVR with realtime local object detection for IP cameras
viseron - Self-hosted, local only NVR and AI Computer Vision software. With features such as object detection, motion detection, face recognition and more, it gives you the power to keep an eye on your home, office or any other place you want to monitor.
motioneyeos - A Video Surveillance OS For Single-board Computers
jupyter-rust - a docker container for jupyter notebooks for rust
neolink - An RTSP bridge to Reolink IP cameras
webdriver-install - Fast and simple webdriver installation
Zoneminder - ZoneMinder is a free, open source Closed-circuit television software application developed for Linux which supports IP, USB and Analog cameras.
dolt - Dolt – Git for Data
Magnetico - Autonomous (self-hosted) BitTorrent DHT search engine suite.
emuiibo - Virtual amiibo (amiibo emulation) system for Nintendo Switch
os-nvr