If you're worried about that, I can recommend a service like Tailscale which does not require permanently open ports to the outside world, offering quite a bit more security than an exposed traditional VPN server.
Compared to a traditional distro, the packaging difficulty distribution is quite skewed with Nix though as packages that follow common conventions are quite a lot easier to package due to the abstractions Nixpkgs has built for said conventions while some packages are near impossible to package due to the unique constraints Nix (rightfully) enforces.
good luck creating new options
Creating options is really simple actually. Had I known you could do that earlier, I would have done so when I was starting out.
Creating good options APIs is an art to be mastered but you don't need to do that to get something going.
good luck cross-compiling
Have you ever tried cross-compiling on a traditional distro? Cross-compiling using Nixpkgs is quite easy in comparison.
actually good luck understanding how to configure existing packages
Yeah, no way to do so other than to read the source.
It's usually quite understandable without knowing the exact details though; just look at the function arguments.
Also beats having no option to configure packages at all. Good luck slightly modifying an Arch package. It has no abstractions for this whatsoever; you have to copy and edit the source. Oh and you need to keep it up to date yourself too.
Gentoo-like standardised flags would be great and are being worked on.
good luck getting any kind of PR merged without the say-so of a chosen few
Hi, one of the "chosen few" here: That's a security feature.
Not a particularly good one, mind you, but a security feature nonetheless.
There's also now a merge bot now running in the wild allowing maintainers of packages to merge automatic updates on their maintained packages though which alleviates this a bit.
have fun understanding why some random package is being installed and/or compiled when you switch to a new configuration.
It can be mysterious sometimes but once you know the tools, you can directly introspect the dependency tree that is core to the concept of Nix and figure out exactly what's happening.
I'm not aware of the existence of any such tools in traditional distros though. What do you do on i.e. Arch if your hourly shot of -Syu goes off and fetches some package you've never seen before due to an update to some other package? Manually look at PKGBUILDs?
I'd define "bloat" as functionality (as in: program code) present on my system that I cannot imagine ever needing to use.
There will never be a system that is perfectly tailored to my needs because there will always be some piece of functional code that I have no intention of using. Therefore, any system is "bloated" and it's a question to which degree it is "bloated".
The degree depends on which kind of resources the "bloat" uses and how much of it. The more significant the resource usage, the more significant the effect of the "bloat". The kind of resource is used defines how critical some amount of usage is. 5% Power, CPU, IO, RAM or disk usage have varying degrees of criticality for instance.
Some examples:
This system has a calendar app installed by default. I don't use it, so it's certainly bloat but I also don't care because it's just a few megs on disk at worst and that doesn't hurt me in any way.
Firefox frequently uses most of my RAM and >1% CPU util at "idle" but it's a useful application that I use all the time, so it's not bloat.
The most critical resource usage of systemd (pid1) on my system is RAM which is <0.1%. It provides tonnes of essential features required on a modern system and therefore not even worth thinking about when it comes to bloat.
I just noticed that mbrola voices sneaked into my closure again which is like 700MiB of voice synthesis data for many languages that I don't have a need for. Quite a lot of storage for something I don't ever need. This is significant bloat. It appears Firefox is drawing it in but it looks like that can be disabled via an override, so I'll do that right now.
Nvidia has been slowly trying to open a little over the years; first GBM support in the proprietary driver then the open OOT module and finally GSP firmwares for the kernel; allowing an OSS kernel module to exist.
The OSS graphics community has obviously shown that it doesn't want Nvidia's open module (which is tied to the proprietary driver anyways) and would rather build out its own OSS drivers atop an adapted Nouveau/NOVA. Perhaps Nvidia finally realised this?
I'm sceptical too but for now this appears to be an actually good move from Nvidia?
I used to not but I wish I did. I want to know where pictures were taken. Photo album software like Immich can also make cool maps out of your photos this way and group photos by location.
As long as you're not sharing the pictures with anyone, there is no loss of privacy whatsoever in doing this. I don't see any reason to generally label it as "not great for privacy".
When sharing publicly, you need to be careful of course and run the images through an EXIF metadata stripper.
Atemu @ Atemu @lemmy.ml Posts 63Comments 1,439Joined 5 yr. ago
I'd look further into that bug because it's not happening on my end.