data1701d

I haven't researched this (I don't have kids), but out of curiosity, what type of mobile device is your daughter using? Also, I think PiHole is a solid recommendation like others recommend.

Otherwise, from a quick Google, I don't know of anything that can integrate both Linux PC and mobile phone screen time. Honestly, this sounds like a fun project I could implement someday if I ever had the will. However, for right now, in terms of screen time all I can think of is reading system logs (perhaps via SSH) to manually analyze your daughter's screen time.

ROCm is basically AMD’s GPU compute system, like CUDA but worse but better because the card is actually usable for desktop stuff.

However, they only support it on specific distros, and they’re really weird about what cards they support. This should be changing soon - Debian’s been working on packaging it natively, and I think so has Fedora.

Assuming you have a free PCIe slot, maybe just buy a PCIe USB card to use instead of what seems to be a faulty AMD USB controller.

I agree with you on the 580, although I got mine new and use it with 2 1080P monitors. I do wonder if ROCm works any better on newer cards, but I don't have my hopes up.

Honestly, just play with Linux in a VM for a while.

For your sanity, I have several recommendations:

• Linux has a central location to install apps called package repositories. Those packages are well-tested and tend to be extremely safe, so try to install from there first.
• Sometimes, apps aren’t available from the main package repository, so you have to source them from elsewhere. To avoid some of the fear, you can try using a thing called Flathub. I won’t go into all the intricacies of how it works or why it exists, but suffice it to say, some of the apps there have a verification checkmark.
• Also, when installing an app, research it online and find the Git(hub/lab/ea) repository. Start by checking if it’s under an open source license like GPL, BSD, or MIT. Although not a sure thing (like the XZ incident, which was an isolated incident), half the time if it’s under one of those FOSS licenses means the app is legit. In addition, check to make sure the source code is actually there- repos with just an executable file and a readme telling you to buy something are red flags.
• Finally, don’t go running random commands online without first researching what it does (with manpages or the like).

I would recommend Googling the following and reading about these:

• Linux directory structure
• Linux package managers

If it can get non-destructive editing by when 3.2 comes out say… 2030, I’ll be happy.

My first question is about your laptop; is the SSD removable, because if so, even a pretty large SSD is cheap these days.

Also, the GPU question is complicated. For most use cases, AMD is better on Linux. However, since you’re doing Resolve and Blender, that gets a bit murky. It depends on if ROCm support is less dismal on later AMD cards - I have an RX 580, which AMD quickly dropped support for and I am bitter about.

This is not to say I like NVidia, but for fast video encoding and rendering, as far as I know, it’s the easier option. Someone correct me if I am wrong, please.

As for actually building the thing, you’d start by look for what CPU you want, then find a compatible motherboard, then read the board’s compatibility list for RAM. They usually have compatibility lists for storage - those don’t matter, as it’s pretty universal. Then choose a graphics card, a case with the right form factor, a PSU, and a cooler. I tend to go with liquid cooling, as it’s not that expensive anymore.

Like others have said, check kernel support for your hardware, but also, it’s generally much easier on desktop. The main things to look out for are ethernet and WiFi controllers. By the way, what distro do you prefer, because that’s definitely a factor.

For a more professional tool, I’ve heard DaVinci Resolve also supports Linux.

I would be annoyed with how much Shotcut or OpenShot crashes, but I can’t say better of Premiere.

Like others have said, most of this is possible but might take a bit of work to set up. In other words, you’re doing somewhat complex things on Windows, so it’s going to get a bit complex on Linux.

I’ve done GPU passthrough using 2 graphics cards (RX 580 going to VM and RX 550 staying connected to host) for VMs on my desktop, and it mostly works. I’d recommend this tutorial for getting it set up. I had to adapt it a bit to get my AMD card working, but it got me started. I now pass through my RX 580 to 3 VMs (obviously not at the same time): Windows 10, Windows 7, and a Hackintosh VM. Although you can technically use just 1 card (leaving Linux without graphics as Windows is using the card), I recommend using dual cards. Just make sure you:

1. Have a free PCIe slot for a second graphics card that stays connected to a monitor while your better card goes to the VM. (The secondary card can be a cheap card - I’d say the 1030 might be good for you. There are ways to use the better GPU to get better performance in Linux native applications when a GPU passthrough VM isn’t running.)
2. Be sure that slot is in a different IOMMU group from the GPU you pass through to the VM as well as any important system peripherals like network cards or SSDs. (Just Google something like “Linux check IOMMU groups” and you’ll find a way.)

Note that GPU passthrough invites a few bugs. You can’t always return the GPU to Linux after turning off the VM, depending on the GPU. (For a while, I got this fixed and could use my card after VM shutdown, but I’ve experienced a regression and haven’t been able to figure out what happened yet). Also, after I’ve run a VM and try to turn off the host, Linux doesn’t shut down clean sometimes and I have to manually press the power button.

As for distros, I actually don’t recommend Ubuntu anymore. I’ve found a severe decline in its performance compared to other distros and its privacy standards. I personally use Debian, but would recommend Pop OS as an easier distro. OpenSUSE and Fedora are good ones as well.

I’m sorry if I dropped a bunch of new terms without explaining them well. Ask me any questions. In return, may I ask what kind of desktop this is? Is it an ATX or ITX form factor or some sort of proprietary small form factor computer by HP or Dell or something that’s going to be miserable to upgrade?

Now the big question is if the update fixes this nasty little bug where no matter what, the audio is muted on login until you mute and unmute. that I had to add a dirty little shell script on startup to fix:

#!/bin/bash
pactl set-sink-mute 0 toggle
pactl set-sink-mute 0 toggle

I was experiencing it with 1.2.3 on Debian Trixie, though I've heard of Arch users experiencing it. I'm updating to 1.2.4 right now.

I'd recommend flashing your distro on a USB drive (it could be the live installer or honestly just the whole darn thing if you want it to be persistent), boot up off the driver, and start playing around to see if you can reproduce the problem.

👏