

Modern transistors aren’t just silicon though. The silicon is doped with various materials, presumably gallium, boron, arsenic, phosphorus, and cobalt, among other elements.
Modern transistors aren’t just silicon though. The silicon is doped with various materials, presumably gallium, boron, arsenic, phosphorus, and cobalt, among other elements.
Can I guarantee? There are no guarantees in self hosting. By this logic you can never move away from Plex. There’s always unknowns. There’s always new issues to trip over. Plex is hardly without it’s own warts, but because they’re ‘known’ to you and your users nothing else will ever be able to measure up.
It’s a logical fallacy and a trap.
I set up Jellyfin basically overnight when the Plex pass changes occurred. Reverse proxies are trivial, as are docker containers, don’t let the anecdotes about things being hard or VPN being needed intimidate you.
There were absolutely bumps in the road. I had to make users for each person and email them customized sign-up links. Yes, that kinda sucked, but that’s the price for running and controlling the authentication yourself instead of though a 3rd party service that can and absolutely will eventually use that data to snoop.
Most of the time, once sent the link the users were fine, 9/10 of my users had no further issues and quickly adapted. For the last 1/10, I had to trouble shoot a few things and eventually ended up recommending a different device to connect with (it was an old TV with a really old version of Plex for TVs, they ended up buying a $40 Google TV device from Walmart and got set up that way).
The whole time I was running both Plex and Jellyfin so the migration process could happen at my speed.
My point is this: no, it wasn’t painless to switch. Yes, some tech support was required. Yes, the user who was getting hundreds of dollars (annually) of streaming services effectively for free had to shell out a paltry sum to upgrade and actually enjoys their experience much more now. No, that didn’t make it impossible or not worth doing.
I’m not saying what’s best for you and your users, and I’m absolutely not guaranteeing you’ll have no issues beyond these, but I hope you understand your hands aren’t actually tied, you’re just boxing yourself in.
Trump is notoriously a zero sum true believer, despite it being routinely mocked, disproven, and sociopathic. He fully believes that help given to people who are not him is wasteful and harmful to him, at least indirectly.
Or just use Linkwarden or Karakeep (previously Hoarder)
Badass female grunt soldier treated by her fellow soldiers as a soldier first and foremost.
Hey, if he becomes Pope he changes his name!
I’m personally looking forward to Pope GarlicBreadus I
Yeah… I mean, I did hedge by saying “depends on your CPU and your risk profile”, but I understand your point and will edit my comment to caution readers before playing with foot finding firearms.
From my understanding it’s a mixed bag. Some of those vulnerabilities were little more than theoretical exploits from within high levels of trust, like this one. Important if you’re doing a PaaS/IaaS workload like AWS, GCP etc and you need to keep unknown workloads safe, and your hypervisor safe from unknown workloads.
Others were super scary direct access to in-memory processes type vulnerabilities. On Linux you can disable certain mitigations while not disabling others, so in theory you could find your way to better performance at a near zero threat increase, but yes, better safe than sorry.
I apologize for being glib.
Agreed, shouldn’t affect performance. But also depends on how they see best to patch the vulnerability. The microcode patch mechanism is the currently understood vector, but might not be the only way to exploit the actual underlying vulnerability.
I remember the early days of Spectre when the mitigation was “disable branch prediction”, then later they patched a more targeted, performant solution in.
no performance change
You must be new here.
Joking. In reality it depends.
The first iteration of this comment had a cheeky observation about the performance impact of these CPU mitigations on Linux, some of which have nearly no real world threat to people not running cloud providers.
And while that’s true to a degree, tests disabling some or all of the most modern set of mitigations show that most have become highly optimized and the CPUs themselves have iterated over time to increase the performance of the mitigations as well.
And many of these CPU vulnerabilities actually had in the wild use and can still do horrible things with very little surface exposure from your system. Apologies to the people who read the first version of this comment and took the time to rightly push back.
Can you provide your docker-compose entry or your docker run command?
Okay, thanks for giving me that, I’ll investigate further tonight
So I just spot checked. Both shows work, you just have to not click an episode anymore.
E.g, https://pbskids.org/videos/design-squad -> design-squad
Thank you for telling me, I’ll update the readme
Hmmm. I just double checked and my episodes are still downloading. But maybe newer shows have a different format… What’s the exact error? I’ll try to reproduce and fix.
The streaming was easy, just declared I wasn’t paying for it anymore lol. We still have a crappy version of Spotify for free because of another service (ISP or phone plan something like that), but it’s purely used as a backup.
Jellyfin’s interface is a bit clunky as a music client in my experience. FinAmp looks cool but it’s still early on.
Navidrome does smart playlist, crossfading, gapless, flac streaming, and flac to opus transcoding. Those are sorta my core requirements, and Navidrome + the clients we use handles them all with aplomb.
And actually that’s another great feature I enjoy for Navidrome, there are dozens of excellent clients, so if one of them falls short for someone they can find one that they enjoy.
As for the user playlist thing… I haven’t seen anything like that but maybe I’m misunderstanding.
That’s fair!
This is correct for a given transaction, but there’s no consensus needed to open a Bitcoin wallet. That is usually just a private key in an encrypted envelope.