hashbrown
moonfire-nvr
Our great sponsors
hashbrown | moonfire-nvr | |
---|---|---|
22 | 31 | |
2,261 | 1,114 | |
2.2% | - | |
8.2 | 8.6 | |
17 days ago | 11 days ago | |
Rust | Rust | |
Apache License 2.0 | 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.
hashbrown
-
OpenD, a D language fork that is open to your contributions
That's because you're looking at a wrapper around the actual implementation (which lives in an external package). Notice "use hashbrown::hash_map as base;" at the top.
There's far more unsafe there: https://github.com/rust-lang/hashbrown/blob/f2e62124cd947b5e...
-
I just published my first crate: `identified_vec` - I would love some input! PR's are most welcome.
You might want to check out how popular ecosystem crates do some of these things. Particularly relevant to you are probably crates providing collections, such as smallvec, hashbrown, or indexmap.
-
GDlog: A GPU-Accelerated Deductive Engine
https://github.com/topics/swisstable
rust-lang/hashbrown: https://github.com/rust-lang/hashbrown
CuPy has array but not yet hashmaps, or (GPU) SIMD FWICS?
NumPy does SIMD:
-
When Zig Outshines Rust – Memory Efficient Enum Arrays
Thanks, great point indeed. I am looking into this https://github.com/rust-lang/hashbrown
The way I think about it -- rather naively, I suppose -- is that I care more about the references cells make to each other than the actual grid of cells displayed on a table. The latter feels more like a "view" of the data than an actual data structure?
This also seems to align with the relative priority of (sorted from highest to lowest): figuring out the order of evaluation, calculating those evaluations, and finally displaying the results of the evaluation
-
This Week in Rust # 500!!
updated std's hashbrown dependency to 0.14 which contains some optimizations
-
Crust of Rust: std::collections [video]
The std hashmap is actually very fast and uses state of the art hashmap design, namely because it's implemented by hashbrown
-
Deduplicating a Slice in Go
I believe Rust uses hashbrown as the underlying implementation now. This just calculates the number of buckets based on the number of items requested:
https://github.com/rust-lang/hashbrown/blob/009969a860290849...
Is it really the case that rehashing can guarantee that the number of buckets allocated will be sufficient for any given set of keys? In principle you could fail to rehash in a way that reduces collisions after k attempted rehashings.
-
Blog Post: Rust Is a Scalable Language
For example, since the hashbrown crate is marked with #![no_std], it can be used as a dependency for the standard library.
-
Hey Rustaceans! Got a question? Ask here (6/2023)!
To implement something that cannot be expressed in safe Rust, or at least cannot be expressed succinctly in safe Rust, like fundamental datastructures. The hashbrown crate contains a lot of unsafe code, but it's such high quality that it's now the backing implementation for std::collections::HashMap.
- Data-driven performance optimization with Rust and Miri
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.
[1] https://github.com/scottlamb/moonfire-nvr
-
NVR in Rust
saw one nvr project in rust - https://github.com/scottlamb/moonfire-nvr - maybe you can find answer there
-
IP Camera stream - simple recording - no resize/detection/etc - is it possible?
Moonfire NVR does basically that. No decoding at all. The configuration process could be smoother, but there's a decent setup guide to follow.
-
Surveillance system, how low can you go?
This is exactly what you're looking for: https://github.com/scottlamb/moonfire-nvr
-
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
What are some alternatives?
dashmap - Blazing fast concurrent HashMap for Rust.
Shinobi - :peace_symbol: :palestinian_territories: Shinobi CE - The Free Open Source CCTV platform written in Node.JS (Camera Recorder - Security Surveillance Software - Restreamer
meow_hash - Official version of the Meow hash, an extremely fast level 1 hash
frigate - NVR with realtime local object detection for IP cameras
flamegraph - Easy flamegraphs for Rust projects and everything else, without Perl or pipes <3
motioneyeos - A Video Surveillance OS For Single-board Computers
bumpalo - A fast bump allocation arena for Rust
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.
aoc - 🎄 My solutions and walkthroughs for Advent of Code and more related stuff.
jupyter-rust - a docker container for jupyter notebooks for rust
aoc-2020 - Advent of Code 2020
neolink - An RTSP bridge to Reolink IP cameras