They’re keeping the 256gb LCD for now, although that could change in the future of course.
They’re keeping the 256gb LCD for now, although that could change in the future of course.
I think there are more people that are #1 and #2 the same time
Probably where some of the attitude comes from. People are assuming that it’s paid IT people bringing their work home with them, which is a different case then a casual user trying out self-hosting without the broader background.
Although I haven’t seen this attitude myself so I suspect it’s not that common, and probably just a handful of users jumping to conclusions.
I haven’t tried it, but Tube Archivist may fit the bill.
The downside with ULA is that ipv4 is given preference, which is annoying on dual stack networks. I believe there is a draft RFC to change this but it will take a while for it to be approved and longer still for OSes to change their behaviour. I workaround it by using one of the unused (but not ULA) prefixes.
Pretty cool especially since it’s RISC-V. I’d have some concerns about the software and driver side of things, though (and the performance).
Ah Nvidia. Bazzite uses Wayland I believe since it uses the same gamescope session as SteamOS (unless something has changed recently). While it may be possible to get it working, I’d expect a much better time with an AMD card.
A traditional distribution may be a better bet with Nvidia for now.
There’s a bunch of other variants like PiKVM and BIiKVM as well. Even some cheap knockoffs on Aliexpress that may do the job.
Mainly because running multiple desktop machines adds up to a lot of power, even at idle. If you power them off and on as needed it’s better, but then it’s not as convenient. Of course, if you leave a single machine with multiple GPUs on 24/7 that will also eat a lot of power, but it will be less than multiple machines turned on 24/7 at least.
And the physical space taken up by multiple desktop machines starts to add up significantly, particularly if you live in an apartment or smaller house.
Vanguard is especially bad because it will not allow to run the game with Intel-VT/AMD-V enabled even if you are running bare metal as of its last update.
The Vanguard anti-cheat is incredibly invasive and something akin to malware, so that’s not surprising.
I’ve recently tried to do that using sunsine and different linux gaming distros and it was awful, the VM was working great for a few minutes and then suddenly crashes and I have to hard stop it.
Are you running this with something like libvirtd/qemu? If so, VFIO configurations can get pretty complex. Random crashes seem like MSI interrupt issues (or you’ve allocated too much RAM to the guest). Or it could be GPU reset issues that would also occur on the (Linux) host, a newer kernel and Mesa version in the guest may help.
Setting on the kernel commandline for the host to workaround MSR interrupt crashes:
kvm.ignore_msrs=1
If you’re running on a Windows host or with something like Virtualbox (assuming GPU passthrough is supported by these), YMMV but I wouldn’t expect good results.
I would expect so. It might already be on the Deck, as sometimes Valve is ahead on kernel and firmware related issues.
Systems themselves are all around 5-20W, although the ones with mechanical HDDs obviously add their own idle usage.
I target a certain level of quality and a reasonable compression speed, and whatever file size it takes is what it takes. If a particular video needs twice the file size to reach the same quality than usual, then so be it.
Guaranteed good driver support too, since Valve fund devs to work on the AMD GPU drivers on Linux.
I don’t think they have yet, which is a bit of a sore point. Third party alternatives like Bazzite may do the job, though.
I wouldn’t expect HDMI 3 given the HDMI group are openly hostile to open source implementations of HDMI 2.1.
In fact, if you are capable of the admittedly high bar of self hosting, use bit warden instead.
Vaultwarden, typically, because it’s fully free and more resource efficient. But bitwarden as the client of course.
It looks like you’re actually using Pipewire, so you’ll want to look at the documentation / bug tracker for that instead.
Ledger/hledger may be an option if you’re command line inclined although more local only then self-hosted per-se.
Some audio issues were introduced in the SteamOS 3.5 update (partly due to having to handle the OLED model around the same time) which causes the HDMI problem. Hopefully it will be fixed in SteamOS 3.6 or 3.7. I’ve found that Bazzite doesn’t have the issue, although obviously that’s an invasive change, and I understand it’s still a bit buggy with the OLED model.
I think doing what you want could be a bit technically involved. One way might be to have one device control the music, and then cast it to the deck with snapcast or similar. Then, if you can get a snapcast client on the deck to be persistently running in the background, any music that is played on the other device, will be heard on the Deck.
Or more simply, you could try pairing your Deck in bluetooth from another device, and then select that Deck as an output. This is assuming that the Deck allows this, and that your source device supports it (Android did last time I tried).