Both glowing portions are natural gas pipes. Perhaps it’s somehow ignited inside the pipes and is super heating them but also somehow NOT travelling outside the two glowing sections and burning the house down???
Both glowing portions are natural gas pipes. Perhaps it’s somehow ignited inside the pipes and is super heating them but also somehow NOT travelling outside the two glowing sections and burning the house down???
Why would I recommend Fileflows? It was a little more user friendly in my experience without requiring pulling in configurations from other sources. I know there are repos chalk full of Tdarr settings and configs, but for simple setups and DIY I preferred the Fileflows interface. The end result is basically the same, so pick your poison.
Isn’t AMD’s HEVC/265 still decent, specifically? I feel like I read that somewhere years back. 264 has always been a weak spot for them, however.
Isn’t this almost the inverse argument to the android vs iPhone thing? Like the iPhone being (traditionally) more expensive for the “same technology from 5 years ago”? I don’t really have a horse in this race, I’m a firm believer in use what you like and is easiest/best for you. But I do feel compelled to call this one out a bit.
I might recommend fileflows over tdarr- but either way some kind of similar solution is almost mandatory with the grab bag of arbitrary encodings you find out there.
Software-wise, it seems that the relatively fast adoption of flatpaks and other containerized formats somewhat solves the typical dependency hell that was so common in Linux just a few years back (and to some extent still is an issue today depending on your distro and use case). The hardware support side is a little harder. That’s going to be up to vendors to play nice with the Kernel team and/or introduce reasonable userland software that doesn’t break the golden rule. Until Linux gets more market share the latter isn’t likely to happen. A nice side benefit of the emergence of immutable and/or atomic distros is that users can play around and try things with much lower risk of bricking their systems, so I’d also consider that a step closer in the “it just works” department.
Very true. But brute force checking through tons of different settings for each camera you need to configure is not fun. I couldn’t seem to find any kind of “known working configs” database or anything either. Every camera seems to be different in what it expects, outputs, authenticates, etc. Once it’s set up, I agree, maintaining the config is easier. Having all your cameras match in model and firmware version probably makes the whole endeavor MUCH easier.
AmCrest and Frigate together are SO good. Integrating Frigate with Home Assistant was also insanely easy for quick viewing and notifications. That initial Frigate config is a bit of a bear- but once you’re past that I cannot speak more highly of it.
hunter2
Proton experimental and (at least as of yesterday) I had to opt into bleeding edge beta as well or I’d just get black screen at launch.
No stuttering for me on Linux… Runs as good as it ever has but the visuals are even that much better due to the engine upgrades. Not a fan of the new UI, but the old UI was clunky too, so I can’t really say it’s even a step backwards.
My friends and I all LOVED the pick-up nature of SG1. We’re all adults with busy lives, so hopping into a ~5 minute casual match was just so easy. And the casual nature made it feel like we could have success without “grinding” the game. I guess that is explicitly not the intent of SG2.
The shift from “we’re making a fun and relatively casual arena shooter with a neat gimmick and extremely rewarding fundamentals” to “we’re making a generic e sport shooter” was swift and, frankly, uncalled for.
Even with nvme drives which supposedly “don’t need” to use BFQ, I STILL always swap it since it maintains responsiveness across the system during heavy IO loads. I used to have similar full system freezes when downloading steam games which notoriously overload your IO in Linux. BFQ was the solution every single time.
Edit Try following the instructions detailed in this post to add a systemd rule to set the scheduler: https://stackoverflow.com/questions/1009577/selecting-a-linux-i-o-scheduler
The second answer that shows an actual rules.d file example has always worked for me. If using nvme or old school spinning rust you’ll need to change it up a bit. Instead of “noop” set it to “BFQ”.
Try swapping to BFQ io scheduler and see if that makes a difference.
He retains the “Cold Take” name and property- so here’s hoping he continues it, whether that’s under some new media company or even just as a solo content creator.
Anyone who ritualistically buys Dell. I believe Intel is on the record as having called Dell “the best friend money can buy.”
Are you on Gnome, KDE, or some other desktop environment? I know KDE Wayland and Nvidia do NOT play nice (presently).
Are you running it through Lutris? Steam with Proton? That error seems decidedly like a Wine specific problem, which Proton should have ironed out at this stage for this particular game.
*Unless you’re trying to play on hardware with incomplete Vulkan support. Then it’s a hardware support problem that is unlikely to be fixed in a reasonable timeframe.
For what it’s worth- I’ve used them plenty and it’s always appeared to be legitimate. They don’t “stock” every game out there, but they do have most things and they do usually end up being 3-5% cheaper than steam unless steam is having a sale.