Alternate account: @woelkchen@lemmy.world
It's usable until it isn't. That's the problem with Wine/Proton. It's not a stable implementation of a well defined specification like Java. It's a reimplementation via reverse engineering of proprietary Win32, something that's buggy and sometimes changed between Windows updates by accident.
Update to a game compiled with a slightly newer version of Visual Studio, like it's happening all the time with live service games? Compatibility becomes a dice roll. Sure, the chance is high that compatibility is kept but it not 100%. Neither is Proton not breaking a game by accident. The big games are automatically checked by Valve but some weird indie game isn't.
And here comes the wonderful thing that's Steam Linux Runtime: containerized binary compatible runtimes of every other or so Debian release. All the issues about not being able to target Linux because of its ever changing nature have been fixed by Valve and yet for whatever reason Valve refuses to promote it towards developers.
They literally promote Win32+x86 emulation for Steam Frame development, a wearable platform where even the slightest stuttering can cause motion sickness and where battery optimization is paramount.
I hope Valve bring Lepton, their Android compatibility layer, to x86 Linux as well. Lepton is based directly on AOSP and not reverse engineering. I have higher hope for that.
Their not invented here git
Full article:
It wasn't.
The video is a 20 minutes long dive into the software architecture of Wolf3D, you commented within 3 minutes of my submission.
Unless you already knew the video, it's unlikely your comment is qualified.
Ich denke, dass so etwas nur auf dem Papier kommt. Wenn Leute seit inzw. ein paar Jahren labern, dass ja Verbrenner kommen könnten, die nur E-Fuels vertragen, dann ist das natürlich Unsinn, da ja gerade eben der Sinn von E-Fuels ist chemisch identisch zu klassischem Benzin zu sein.
Chromecast actually mostly sends a link to a google device and then launches it on the device to play; there isnt a direct replacement to that.
I'm aware of one project called ScreenInvader but it's unmaintained since about a decade. It offered a web UI where you could paste a URL from any device:
As you can see the UI was clunky and I guess it's part of the reasons why it died. Too bad, I like the concept of having a jukebox at a party where people can just contribute to without installing anything, let alone sign up for an account.
It might also be a single dev who pushed for it. With only a 1-3% market share, the company is unlikely to push resources at it.
And yet Microsoft and all PC OEMs panic at the existence of Steam Deck and throw resources at Windows-based competitors.
„Deshalb prüfen wir auch, wie wir die europäische Automobil-Wertschöpfungskette am besten stärken können – etwa durch gezielte EU-Präferenzkriterien.“
Sicher, dass der Artikel nicht weiter geht? So weit komme ich auch mit regulärem Werbeblocker und darunter kommt dann die Paywall-Zahlungsaufforderung.
There is no best. Period.
But there are bad ones. For example Ubuntu and derivatives broke Flatpak support in 25.10. This was known ahead of release but because only Snap matters, the fix will only roll out after release.
But Proton is not one API. There is a reason why Valve maintains multiple Proton versions and keeps them around. Cleanroom reverse engineering Windows is a moving target. They are at developing Proton 10. How long can they keep it up to maintain old Proton versions for old games while advancing Proton for new games? Will the workload break them at Proton 20?
Steam Linux Runtime is a less moving target. Valve bases a new SLR version on every second or so Debian release (IIRC SLR 3 uses Debian 11).
Signal have tons of money from selling proprietary licenses of the Signal code base to Meta (used by WhatsApp and Facebook Messenger), Google, and Microsoft.
All these partnerships were announced on Signal's own blog, in case you don't believe it.
I recently installed Slowroll in Steam Deck's Distrobox. First day and yt-dlp was already too outdated.😅
Adding OBS repos got weirdly broken since the last time I did it. Some packages cannot be forked into one's home repo because they are on openSUSE's git and zypper ar does not add the repo type to the offline file, so zypper ref complains about an unknown repo.
In the end I found some other repo containing a recent version of yt-dlp that I could fork into my home repo and edit the file in /etc/zypp/repos.d by hand. I assume this is transition pain during the move from OBS to git. I hope they'll get this done soon.
thanks for using Leebra!
go to feed...