BirdNET-Pi: Automated, locally run bird sound identification and tracking

Yeh this was my initial concern with optical silhouette classification. The altitude and targets are quite small (and rapidly moving). I've thought about using optical flow analysis to track wingbeat frequency etc as I feel this might be a little simpler to acquire.

On wingbeat frequency I'm very curious to play around with mmWave doppler radar (there's some RF on chip stuff around), emitting a relatively isotropic signal might allow for a pretty wide field of view and I imagine you'd get a pretty reasonable wingbeat signal.

Very cool! I wonder how unique the signatures are and whether this can scale to smaller flocks.

I can't find a single place, on that site, which mentions radar.

Instead, it talks about data from partners, sources, etc., and even mentions some of them as manual counts, overlapping, etc.

It just looks radar-ish, but is not.

Thanks ! I'm now in the process of updating to the new 2022 model.

No, I'm sorry, I seriously don't understand how that applies in this case. How is "trusting the content you get from `apt-get`/`dpkg`/`pacman`" safer than curling-to-bash? In both cases, you are downloading and installing content from a trusted source (assuming you are curling via https to avoid MITMs). In the curl-to-bash case, you have the _ability_ to at least inspect the code first before you install it (though, realistically, how many folks would really have the dedication and the ability to do so?), whereas with package managers you're installing "blind". Doesn't that make curling-to-bash the _safer_ option?

I clearly must be missing something, here, because everyone decries "curling-to-bash" as a bad security practice, but I haven't seen an explanation of _why_. I tried doing some research for myself - this page[1] suggests that package managers have built-in checksumming and signature verification, but then goes on to propose an attack vector where the load balancer is compromised, so (presumably?) those same checksums/signatures could also be intercepted and faked. This gist[2] has a lot of people speaking against it, but from following those links, the only downside I could see was here[3], pointing out that the shell will keep executing if a connection closes mid-stream - which, yes, is certainly a bad thing and a good argument to use package managers, but not what I would call a security concern (unless you don't trust the entity on the other end of the stream - and, again, I'm taking that as a prerequisite both for `curl | bash` and for using package managers). This[4] demonstrates that a server can detect `curl | bash` and render differently - but, again, if you trust the entity at the other end, that's not an issue.

This is a genuine question, not a fight - you clearly know more about this than me, so I'm asking for your perspective, not challenging you. I recognize that there are non-security flaws to `curl | bash` (handling updates, handling unreliable connections), but I don't see how it's a security concern. How would a malicious attacker exploit someone doing a `curl | bash` from a trusted location over https?

[1] https://sysdig.com/blog/friends-dont-let-friends-curl-bash/ [2] https://gist.github.com/btm/6700524 [3] https://www.seancassidy.me/dont-pipe-to-your-shell.html [4] https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...