Linux enthusiast, family man and nerd

  • 0 Posts
  • 245 Comments
Joined 2 years ago
cake
Cake day: August 24th, 2023

help-circle








  • I watch Netflix, Amazon Prime, Disney on my Ubuntu laptop on Firefox all the time. I have a laptop setup in front of my treadmill just to watch shows while I walk.

    Are you watching in regular 1080p or above, or the gimped 720p most DRM services impose on the Linux platform?

    If it’s 1080p+, how? If it’s 720p, that’s not really acceptable to most people.

    I think the point of OP is that Streaming services don’t care about Linux and downright gimps them, so the apps will “look better”. Casual users won’t know or care about the technical reasons.







  • No, pacman -S package is safe. Because the package list is not updated this way, and therefore the system is not updated and nothing else is affected. New packages can be installed with this command, perfectly okay. That is in the spirit of Archlinux.

    If the package is not in your cache, it needs to download it from the remote server first. The version on the remote server is built against the dependencies on the remote server. So if your local dependency is older, it will be a partial update!


  • But -S package is not upgrading the package. Installing with that command is supported. That is NOT a partial upgrade of the system. -Sy package is considered a partial upgrade, because that command updates the package list.

    I disagree. The -S flag stands for “sync”, which means sync the local version with the remote version. So if there is no local version it just installs the remote version. This is still a partial update, because any dependencies it might have, that you already have installed, might be the wrong version compared to the one the newly installed package expects.

    pacman -S should be discouraged because of this. The correct one is pacman -Syu for installing new packages.





  • From one of the Jellyfin devs in the issue you linked, posted in April this year:

    Now, let’s address this clearly once and for all. What is possible is unauthenticated streaming. Each item in a Jellyfin library has a UUID generated which is based on a checksum of the file path. So, theoretically, if someone knows your exact media paths, they could calculate the item IDs, and then use that ItemID to initiate an unauthenticated stream of the media. As far as we know this has never actually been seen in the wild. This does not affect anything else - all other configuration/management endpoints are behind user authentication. Is this suboptimal? Yes. Is this a massive red-flag security risk that actively exposes your data to the Internet? No.

    At this point, this over-4-year-old issue has gotten posted to HackerNews more than enough times and gotten quite enough unhelpful peanut-gallery comments like those above… We are limiting this issue to Jellyfin collaborators only at this point. Most of the big items are already tracked elsewhere (specifically, unauth playback) or have already been fixed. And many other options are now open to us in a post-10.11 landscape now that we have a proper library database ready.