I honestly rather not install nouveau since iknow it can cause issues and i wouldnt mind installing nvidias proprietary drivers if it makes it work since its not even for me
do you know if i should install the 470xx or the one just called nvidia drivers in the app store?
Are you using the legacy Nvidia drivers? They dropped support for the 600 series gpu, so you’ll need to make sure you’re using a driver version "470.something?
I have a stack of old phones in my drawer of tech I need to go through and check which ones work on postmarketOS. I think I have an old Pixel or two as well as Nexus phones.
I do scientific computing and I’ve used Ubuntu, Debian, Fedora, Arch, and NixOS for work.
Any and all of these can do what you need. Hell, you could probably throw your whole development environment into a docker container and use it anywhere. Pick one and go with it.
That said, here are my preferences:
Right now, I really like NixOS and Nix for development environments, but it’s a lot to learn, so I wouldn’t recommend it unless you were really excited to try it.
Before NixOS, I used Arch on my laptop, and it was soooo nice to be able to build my own desktop environment just the way I wanted it from the ground up, which is possible on any distribution, but the Arch documentation makes this much more approachable. If you are happy with KDE Plasma or Gnome, and you’re using well-supported hardware, then I wouldn’t say Arch is really worth the time (unless you’re excited to play with it).
Fedora and Nobara (a Fedora-based distribution with a lot of gaming-focused presets) have been a breath of fresh air coming off the heels of painstakingly setting up Arch and then NixOS. Fedora is pretty nice out of the box and Nobara has been the best experience of going from zero to gaming even when compared to Windows.
Debian (especially Debian 12) has been fantastic for servers and for machines that don’t need to use the newest hardware. It’s still my go-to for lots of things.
Ubuntu is fine, but Canonical, the company that makes it, has made some unfortunate choices lately, and with Debian 12 being as good as it is, I don’t think I’ll ever have a reason to go back.
Side note: One thing to look out for in the near future is System76’s COSMIC desktop environment, which seems to be doing a lot of things right. There is already active development to get it working on NixOS, and I’m sure it will be available on Pop!OS from the start. I would also bet that it would be ready to go on Arch not long after. It will likely eventually be easy to install on all distributions, but if you want to try that out as soon as it’s ready, one of those three would be a good option.
Well put. The one thing I would add is using the Nix package manager on a distro other than NixOS! I’m daily driving Fedora 39 + Nix (home-manager) with zero problems. My pick would either be Fedora or Debian.
Tons of good documentation either way. Flatpak the packages you, no kidding, need to be easy / consistent to debug. Non-root podman for containers. Nix for more up to date packages than are available in the native repos (especially useful with Debian) + the other benefits like nix-shell.
Use anything you want. All distros should support those packages, use what you’re the most comfortable with.
I personally would recommend Fedora Silverblue/ it’s other atomic variants or uBlue especially.
It’s pretty much unbreakable, modern and supports ALL distros’ package managers through Distrobox. It’s also pretty simple in my opinion, since you pretty much don’t have to worry about traditional package management.
I think you’re searching something reliable and simple, so this would be a solid choice.
i was using the dGPU, but i will try to use the iGPU next if it doesnt work and simply not use the gpu then, i just installed elementary to see if it was a fedora issue but no, i reinstalled fedora now and im going to try that out
I think the container piece is probably the least of your concerns here honestly. The biggest thing you’ll want to focus on is the ingress networking layer, but that won’t really be any different than if you were running the app normally. Generally exposing ports from your home network to the internet is not a great idea, and you try to use something like cloudflare or get a cheap cloud VPS with a reverse proxy connected to the container host via VPN.
But for general container security practice, what you mentioned is good. You could also look at the Docker CIS Benchmark for more good security practices. And container scanning tools like trivy or anchore syft/grype to identify vulnerabilities in your containers. But again this is secondary to the networking layer in my opinion.
Disclaimer: I don’t know much about securing the container itself. The considerations I discuss here are mostly networking.
What I’ve personally been doing is using k3s with Cloudflare Tunnel (routed using DNS like in this documentation) as an ingress.
With Cloudflare Tunnel, if you create an application in front of it, you can require authentication and add a list of allowed emails.
I could replace k3s with a different Kubernetes distribution, and/or replace Cloudflare Tunnel with a different ingress (e.g., Tailscale Funnel or more common ingresses like nginx).
Completely tangential tip, but in the very-limited video editing I’ve done recently: I’ve used Davinci Resolve, rendered as .mov, and then used ffmpeg to render to my actual desired format. e.g. h264 w/ aac audio so I can upload to Youtube:
I do think that finding the right flags to pass to ffmpeg is a cursed art. Do I need to specify the video profile and the pix_fmt? I don’t know; I thought I did when I adventured to collect these flags. Though maybe it’s just a reflection of the video-codec horrors lurking within all video rendering pipelines.
edit: there may also be nvidia-accelerated encoders, like h264_nvenc, see ffmpeg -codecs 2>/dev/null | grep -i ‘h.264’. I’m not sure if the profile:v and pix_fmt options apply to other encoders or just libopenh264.
using openh264… well that’s a choice. I would recommend to everyone that they use x264 whenever possible, and make sure to specify output crf and likely preset when you fo
A couple other things, you generally want to do pixel format conversion before the codec, is specified. You should be able to get satisfactory results with ffmpeg -i input.mpv -pix_fmt yuv420p -c:v libx264 -preset medium -crf 24 -c:a aac output.mp4 Play with preset a bit since that is where your Quality/Compression : Speed ratio comes in, CRF is the quality it handles. So you set CRF for a ballpark quality you want, then change the preset, slower = higher compression, faster = lower compression.
haha, yeah figuring out those ffmpeg flags is an absolute nightmare. My problem there isn’t so much the output format from Resolve, but source format I’m using. My camera only has the option to record in H.264/H.265 (consumer grade, what can you expect?) which Resolve can’t properly import on Linux. I could take the time to transcode them with ffmpeg before editing, but I’m usually working with ~2 hours worth of video per project and I don’t really want to wait all day for a transcode job to finish before I can even begin editing. On top of that my camera (rather neatly) generates its own proxy files while recording, and I’ve found leveraging these is necessary for getting good timeline performance on my aging rig. Now I could let Resolve generate its own proxy clips like I have in the past, but that’s more time waiting around before editing. I was SUPER stoked to see Kdenlive can natively utilize the proxy clips my camera generates.
Secure your network. Worry less about escalations in your containers. You’re thinking too deeply about what is essentially a rabbit hole with a dead end for the most part, and if you don’t understand why in the first place, you should read more to understand exactly what you’re afraid of.
If you’re thinking that on your personal home network (which should be reasonably secured anyway) that someone will get physical access, then get on your network and start scanning everything, then find the ports you have open on every host, then identify the specific versions of the http servers hosting your software, then run exploits to get past any authentication which should be there, THEN have superhax ready to escalate privileges on the container runtimes so they can run remote executions…that’s all they’ll be able to do unless you have volume mounts allowing access to your stuff everywhere in said containers.
If you live in fear of everything, you’ll get nothing done.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.