Atemu

You're basically looking for DRM and I'm not aware of any DRM system that you as a non-media-conglomerate can use.

I'm also not aware of DRM that is actually effective. It's mostly snake oil or, at best, "please don't steal"-signs.
The ultimate Achilles' heel of any DRM system is the analog hole: As soon as the user has an image on their screen, they can take a photo of said screen and share that in any way they want.

As with multi-media piracy, you cannot solve this issue using technology.

If this is a VM, video playback stutters do not surprise me one bit. There's many layers between the video and the image you see on screen here and they're not optimised for viewing fidelity. This is likely not due to Linux but because you're running this inside a with an emulated GPU. GUIs in VMs usually suck.

Optional codecs won't help for Youtube since they serve royalty-free codecs such as VP9 or AV1 most of the time rather than patent-encoumbered codecs such as H.264 and free codecs are always installed.
That would also not fix stutters, only videos not playing back at all (because there'd be no decoder that could).

If this is a VM, installing the Nvidia driver also won't do anything because the machine has no access to your host's GPU. Not that the nvidia driver would change anything about videos since no sane browser supports their proprietary crap driver, so it's software decoding either way.

You should try this on real hardware. You technically don't even need to install as most GUI distros have a graphical installer with Firefox etc. pre-installed that you can use to test this.

If you have an Nvidia GPU, I'd recommend you to try !pop_os@lemmy.world.

That's U.S. patent law actively getting in your way, not the distros.

You should be spending very little time, if any, in that folder.

Hahaha, tell that to https://lemmy.ml/c/unixporn

On my cheeseburger guinea pig device with a broken screen what I do is enable ADB in the system via some shell commands in TWRP recovery and then use scrcpy to use the phone "normally".

#!/usr/bin/env bash
adb shell "
twrp mount system
twrp remountrw system
echo '' >> /system_root/system/build.prop
echo '# Enable ADB' >> /system_root/system/build.prop
echo 'persist.service.adb.enable=1' >> /system_root/system/build.prop 
echo 'persist.service.debuggable=1' >> /system_root/system/build.prop
echo 'persist.sys.usb.config=mtp,adb' >> /system_root/system/build.prop 
"
adb push ~/.android/adbkey.pub /data/misc/adb/adb_keys

(You need to generate an ADB keypair first ofc.)

This does not require decrypting data but you do need a writeable system and data partition. In TWRP, data is mounted by default and the first two commands mount system writeable at /system_root/. I've never done it with Lineage recovery but in theory, it should be possible somehow. (Obviously not using the TWRP command.)

robust stop and resume of download

You can stop/resume downloads via HTTP too. That's up to the client to implement.

increased download speed with using several http and torrent sources at the same time

Again, this is a commercial CDN. Speed is practically infinite. Without the rather long ramp-up time too.

downloading from peers from within the same network

That sounds like a micro-optimisation for an edge-case.

automatic checksum calculation and redownlaod if needed

Not really necessary for an installer ISO downloaded via HTTPS.

Sorry that I asked. Seems that you feel very offensed by my question.

???

As mentioned, one of the reasons torrents don't make sense here is that the ISOs change quite frequently. I don't have exact numbers here but there's nothing preventing them from changing every single day. The current ISO is only two days old.

Every seeder would have to discard the old ISO and re-download an entirely new ISO every few days or so.

Given that we need the CDN anyways, torrents just simply don't make sense.

Were you using the Google espionage services on GOS? If so, you'd likely gain a little privacy because of µG.

Some devices can lock the bootloader but that's not a generally supported feature on /e/OS.

It doesn't really make sense to use torrents here. We've got a commercial CDN serving these files for us and they change basically every day or so.

These aren't all versions per se but mostly variants, versions and versions of variants. For example, we have packaged the xanmod kernel which is a modified kernel optimised for desktop use but it has two variants: Main and LTS. We have packaged both.

Here are the names of all of our kernels currently to give you an idea (as a JSON list):

[
  "linuxPackages",
  "linuxPackages-libre",
  "linuxPackages-rt",
  "linuxPackages-rt_latest",
  "linuxPackages_4_14",
  "linuxPackages_4_19",
  "linuxPackages_4_19_hardened",
  "linuxPackages_4_9",
  "linuxPackages_5_10",
  "linuxPackages_5_10_hardened",
  "linuxPackages_5_15",
  "linuxPackages_5_15_hardened",
  "linuxPackages_5_18",
  "linuxPackages_5_19",
  "linuxPackages_5_4",
  "linuxPackages_5_4_hardened",
  "linuxPackages_6_0",
  "linuxPackages_6_1",
  "linuxPackages_6_1_hardened",
  "linuxPackages_6_2",
  "linuxPackages_6_3",
  "linuxPackages_6_4",
  "linuxPackages_6_5",
  "linuxPackages_6_5_hardened",
  "linuxPackages_6_6",
  "linuxPackages_custom",
  "linuxPackages_custom_tinyconfig_kernel",
  "linuxPackages_hardened",
  "linuxPackages_latest",
  "linuxPackages_latest-libre",
  "linuxPackages_latest_hardened",
  "linuxPackages_latest_xen_dom0",
  "linuxPackages_latest_xen_dom0_hardened",
  "linuxPackages_lqx",
  "linuxPackages_rpi0",
  "linuxPackages_rpi02w",
  "linuxPackages_rpi1",
  "linuxPackages_rpi2",
  "linuxPackages_rpi3",
  "linuxPackages_rpi4",
  "linuxPackages_rt_5_10",
  "linuxPackages_rt_5_15",
  "linuxPackages_rt_5_4",
  "linuxPackages_rt_6_1",
  "linuxPackages_testing",
  "linuxPackages_testing_bcachefs",
  "linuxPackages_xanmod",
  "linuxPackages_xanmod_latest",
  "linuxPackages_xanmod_stable",
  "linuxPackages_xen_dom0",
  "linuxPackages_xen_dom0_hardened",
  "linuxPackages_zen"
]

(Note that some of these are aliases; linuxPackages_latest is currently linuxPackages_6_6 for example.)

Each of these has the following nvidiaPackages (modulo incompatibilities):

[
  "beta",
  "dc",
  "dc_520",
  "latest",
  "legacy_340",
  "legacy_390",
  "legacy_470",
  "production",
  "stable",
  "vulkan_beta"
]

(Again, some of these are aliases.)

This is useful to have because users might have hardware constraints. It's not hard to imagine a scenario where a user might have a WiFi chip that only works with kernel ABIs < 5.4 and require the 470 nvidia driver for their old GPU. Packaging just the latest kernel and just the latest Nvidia driver would make this user unable to use their system.

Stromkosten nahe 0 für den Elektrorasierer, der mir vor vielen Jahren mal geschenkt wurde.

furry anime girl

Welcome to the Nix community I guess :D

there’s a different nvidia driver for each kernel version. Already a stupid design

That's not a stupid design at all. A nvidia kernel module artifact is only compatible with exactly one kernel ABI. Thus you need one binary nvidia package for each kernel you ship.

Arch also has one package for every kernel ABI they ship: nvidia and nvidia-lts.
Though it should be noted that their design assumes that these two ABIs are the only possible ABIs which isn't strictly the case as the zen, hardened or RT variants may sometimes lag behind their regular counterpart. That's a stupid design if anything as it increases the friction of kernel ABI upgrades as a kernel package maintainer.

We at NixOS also ship the nvidia module for each of our ~50 kernel variants; all major versions of the Nvidia module compatible with that kernel in fact.
The only possible way to access these nvidia kernel modules is via a certain kernel's linuxPackages attribute set that contains all packages that rely on a kernel ABI such as kernel modules or packages like perf. That's good design if you ask me but I'm obviously biased ;)