

This camera (Reolink E330) doesn’t have HTTP (80 or 443), just RTSP (554), ONVIF (8000) and the proprietary interface that their own app uses (9000).


This camera (Reolink E330) doesn’t have HTTP (80 or 443), just RTSP (554), ONVIF (8000) and the proprietary interface that their own app uses (9000).


Yeah Frigate devs claim it can’t be done, but it works in other projects like Shinobi.
They don’t need to be actual users. When they’re trying to start Tailscale on a new device have them pass the authorization link to you and open it on your account. This way their devices are registered as devices for your user. You can tag the devices and write ACLs for them to determine what they can access.


I’ve tried LazyNVR but I couldn’t figure out how to make it work with my cameras. There seem to be no real instructions. I don’t even get how it’s supposed to find the cameras, there’s no place to put an IP.


The Frigate docker image is generally nasty. It’s humongous (5.5 GB), bundles and runs a ton of different things whether you use them or not, uses s6 as init and supervisor which is a piece of crap, and it cannot be secured – it won’t run as a non-privileged user, it won’t drop caps, you can’t make it read-only because some genius configured nginx to put temporary files in with the app files, it conveniently includes apt so the attacker can install anything they might want inside the container, and in fact recommends running in privileged mode(!).
I think it’s the most security-hostile docker image I have ever seen.


Not for lack of trying, mind you. Previous attempts were eventually thwarted after decade-long efforts, which is also how this one looks like it’s shaping up.
It’s also worth pointing out that in previous cases there were champions of the industry that stood up for Linux and countered with equal amounts of money into things like lawsuits and marketing on the supporting side.
Furthermore this attack is of the FUD variety (fear, uncertainty and doubt) which is harder to counter.


What are they getting for their money?
It’s a marketing campaign to devalue Linux in the public eye.
If they can state that AI came up with a “good enough” distro you know what non-savvy people will think about it: that making a distro is “easy”, and “anybody can do it”, and that anybody involved with making distros “manually” is redundant and giving themselves airs etc.
It has already happened to many other fields.


It’s not you (an informed user) that they’re after, it’s about public perception of Linux.
I would go as far as to say Omarchy is an attack on all Linux distros.
It’s the notion that you can just “dial up some tech” that has been doing widespread harm to all branches of IT, shaking up the public trust in technology and confusing what “reliable” means for IT.
If Omarchy succeeds in having AI create a usable Linux distro it would fundamentally alter the optics of “manually” created distros and the public’s trust in them. And it probably can, given massive amounts of money and resources. Hence all the millions being poured into it.
It’s the old “embrace, extend, extinguish” strategy in a new form.


If those individuals want to distance themselves from a Nazi movement, they can do so. They can put out statements clarifying their association. RMS battling cancer is an extreme case.


companies that sell our data
You can just say “Google”.
Always keep in mind that Google pays for Firefox. But in order to avoid a monopoly investigation they only need Firefox to exist, they don’t need it to be good.


If you ask AI to do all the work, including the smallest little things, I imagine you can burn through a lot of tokens very quickly.


This reminds of that time during the crypto bubble when the Fashion Channel put out its own crypto currency.


I think Pangolin would be massively overkill for this. It’s designed to be a CDN layer orchestrator and it’s primarily a HTTP reverse proxy. You can do it with Pangolin but it complicates things and you’d need more resources too.
All you really need on the VPS is to run a tunnel (WG or OpenVPN) and forward whatever ports the games need from the VPS public IP into the tunnel. Maybe a DDNS tool/script if the public IP is dynamic.


According to its Github page seems to be a container-oriented Linux distro, like Flatcar / Fedore CoreOS / Talos Linux.
The linked website is AI-generated so ofc it doesn’t say anything useful up front.
I can give you an indefinite, unrestricted license to do whatever but I still own the copyright.
Isn’t this distinction academic?


It’s fairly safe as long as you add a strong enough form of access control. For example if you put it behind a VPN, or a SSH tunnel, or require mTLS. Even a key in a custom HTTP header or Basic HTTP auth can be good enough if the key is strong enough.
You can further decrease the probability of drive-by bots reaching a publicly exposed service by merely scanning IPs and ports if you use a reverse proxy and hide your service FQDNs and IP.
You can do this by using TLS certs on wildcard domains rather than explicit domains, using explicit CNAMEs for the service subdomains rather than a wildcard domain, and keeping the A/AAAA records on an obfuscated subdomain rather than the base domain. If the bots can’t figure out a FQDN they’re not getting past the reverse proxy even if they find the IP and port.
This is obfuscation not real security but it cuts down tremendously on bot hits.


I just can’t find any single sentence in the license text covering SaaS.
SaaS is covered by the following fragment (emphasized by me below) which was added since version 1.1 to the last paragraph of Article 1:
- ‘Distribution’ or ‘Communication’: any act of selling, giving, lending, renting, distributing, communicating, transmitting, or otherwise making available, online or offline, copies of the Work
or providing access to its essential functionalitiesat the disposal of any other natural or legal person.
regarding the compatible licenses, they say the other one wins.
If you combine the original work (licensed EUPL) with another work (licensed under weaker terms, but only applicable to one of the explicitly listed licenses), and there’s a conflict of obligations for the combined result, the terms of the lesser license prevail.
If there’s no conflict or the other license is silent, the stronger terms prevail (EUPL).
The original work always remains under the stronger terms (EUPL).
Hope this clears it up.
PS: I think maybe I understand the confusion. In the earlier comment I was talking about cross-licensing. That means making the software available under two licenses. That’s something that can only be done by the copyright holder.
What you’re describing is not cross-licensing. If someone takes EUPL software and combines it with code under one of the other listed licenses, the distribution alone of the mixed result can be done under the terms of the other license (if the obligations conflict etc. etc.)


Reticulum seems to be licensed EUPL 1.2, which includes the SaaS provision.
everyone is allowed to redistribute it under the terms of the LGPL
I think maybe you misunderstand how cross-licensing works under EUPL. When you cross-license into a weaker copyleft like the LGPL, the stronger provisions in the EUPL still apply and prevail.


Didn’t have a network card.
It’s popular because it works. You don’t get a lot of choice in the NVR area, most of the other projects are kind of ass too. I’ve been trying lots of them and so far Frigate and Shinobi are the only ones that you can get to show your camera streams, and detecting & recording actually works.
I also don’t think many people care about the security that much. Either that or they run the container like I do in a completely isolated VLAN with the cameras. Honestly, if it wasn’t for the obscene amounts of RAM, CPU and storage it wastes for no good reason I wouldn’t care that much about the security either.
Lots of developers are clueless about Docker. They are used to running their stuff on the metal and piling everything together and they don’t even consider they should clean things up before they ship a docker image.
Gramps Web for example is another humongous image, and it’s humongous because apparently the developer can’t be arsed to separate the building stage from the production stage in their Dockerfile, so they’re shipping all the build toolchains. People have pointed this out to them and they’re like “eh whatever”.