Is it? I hadn't used Ironwail before, but I just installed it somewhere (as per the instructions) and it found the Quake dir from Steam (where I extracted qbj3 as well) all by itself. I used VkQuake before this.
I stick with tech news and the creator space on social media, and while I could very well be doing something fantastically wrong, it is hard for me to find on Bluesky when compared to Mastodon and X.
All these years later, and nothing has replicated what Google Plus accidentally pulled off.
I really enjoy Bluesky a lot, but I agree that there's not enough tech news for my taste.
I do follow a bunch of tech news outlets (including many HN bots), and that works. But there is very little engagement, few likes and few comments. I'd like to see more of what others think. My experience on Twitter was that often these comments suck and aren't thoughtful, but there are some gems, some really enriching, and also that it was still useful for networking & finding those other interesting people out there.
Mastodon seems to have gotten most of the devs. But they don't have a ton of tech news either. And honestly there's just so little interesting development of Mastodon / ActivityPub. Where-as there are really neat amazing not hard to do cute apps and experiences happening with atproto / Bluesky. It's a weird bifurcation of not that technical sometimes but also technical about itself & very active about itself.
I’m more excited about the upcoming support for VST3, but this is still welcome news. It is far easier than getting hardware encoding working with Rockchip SoCs on Linux.
Two years ago I started a niche blog and tech site focused on hardware and software guides for Linux creatives. Even set up a forum because I was fed up with digging through scattered mailing lists and Discord servers for information. I like to think it has helped some people and it gives me a chance to practice writing human-readable documentation.
FEX is a CPU JIT, so your GPU settings are irrelevant to it, it is translated but not by FEX, and there is no real perf hit for the GPU
The old games don't really matter with regards to FEX perf, so the only relevant bit is the semi newer games at 30/40 fps, which seems very slow to me, given that you are only running at 1080p/Medium, so you likely have a CPU bottleneck there.
I would keep in mind that the results reported there are likely quite a bit lower (in terms of CPU-side performance) than what you could achieve in practice, because it's running all of x86 Steam+Proton in the emulator. In a pre-configured environment (like SteamOS for ARM), the Steam client and Proton itself would be native ARM code, and emulation would stop at the win32 API boundary (or at certain critical libraries' APIs if you're using Linux apps).
This week we closed the doors on our Linux gaming podcast, which has run continuously for the past 13 years. No fuss, no drama. With the announcement of Steam Machine II (we also covered the original launch), it just seemed like the right time. Proton has evolved to the point where most things work out of the box. Few people are bothering with native support, and it’s become difficult to find new things to cover.
It really feels like everything is lined up for the year of Linux in the living room, and it’s great to see.
I never listened to the podcast, but I see where you're coming from and thanks for doing it anyway.
Twenty years ago I was in university and had a Debian install on a cheap-ass Acer laptop and I managed to get exactly two and a half games working under Wine: the first two Fallouts and about three hours of Civ IV before crash. Getting games to run at all was A THING so a podcast for that makes a lot of sense.
Today I have a full-time job and deleted the Windows partition from my expensive PC about three years ago... pretty much every game I've ever wanted to play since then has just WORKED. Better than on modern Windows, even. Not a lot to talk about there, I guess.
One thing I wish is that Valve could publish a 'Proton spec' that people could build against to ensure compatibility, but I imagine that that this would be an IP nightmare.
Anticheat is a big issue that nobody seems to mention. I had to go back to windows for online games and it’s my understanding that there are deep technical reasons why anticheat on linux can’t be done the same way as on windows.
Not sure what you mean, in every thread there's someone that mentions anticheat as if to stress why Proton is never gonna be good enough.
You can be a true gamer™ even if you don't play the latest $90 AAA multiplayer FPS. To me not having a proprietary rootkit is a feature, and Windows is always there for those that are OK with being spied upon.
> The moment developers find a way to get their anti-cheat working in Linux I have absolutely no reason to ever boot a Windows machine again...
The trouble is that kernel-level anti-cheat sounds like something useful but it doesn't actually get you anything because the cheat developers are going to analyze and modify the anti-cheat code the same as they do the game code. And then having it running in kernel mode on the non-cheater's PC doesn't buy you anything when the anti-cheat code you wrote isn't actually running unmodified on the cheater's PC.
The cheat developers do have to put in the effort to analyze what it's doing in order for that to work, but the same is true of user-mode anti-cheat. Being in kernel mode doesn't solve or improve anything, it just creates a hazard because then bugs or malware in the anti-cheat code can compromise the entire system and are effectively granting themselves access to things you didn't approve, e.g. a game running as the kid's user account can't normally access the parent's tax returns, but in kernel mode it can. So what you want is for them to stop doing that.
Meanwhile the Windows kernel and the Linux kernel are completely different, so you're not going to be able to take Windows kernel anti-cheat code and run it in the Linux kernel even if you're not attempting to cheat. You'd have to have them to make a Linux-specific one, but you don't want them to, because they shouldn't be doing it at all.
This is entirely possible using TDX/SEV-SNP, running in a vm alongside a host OS. It's just a big engineering lift. They're almost certainly already working on it.
Anticheat is a big non-issue that multiple people mention whenever Linux gaming is brought up. 5 popular anti-cheat games do not outweigh the whole ecosystem.
It is when those anticheats gatekeep the most popular PC games. For most gamers, they can't compromise on what they play and there is still a very large amount of potential games that would forbid a switch to another OS. See : https://areweanticheatyet.com/
Because it's intractable on Linux and advocates don't want to admit that. The entire security model on Linux is resistant to deeper levels of access and control for applications, which is required for kernel level anti-cheat. While these forms of anti-cheats can't stop cheating, they are clearly more effective than user-space anti-cheats. For 99% of users, we gladly accept these more "invasive" anti-cheats because it means less cheating in the games we enjoy. Linux developers will never allow this kind of access because it is antithetical to their ideological beliefs around security. They gladly exclude any kernel level cheats to maintain the security model. It is a permanent impasse. One which I believe will never be solved with user-space or server-side detection. This is why the most common retort is: "just play different games."
To be frank, the argument that kernel level anti-cheats are invasive has never been all that accurate or compelling. Any user-space application already has numerous privileges which could ruin your day. You trust a developer and application every time you run it, irrespective of its access level. Valve has an opportunity now with SteamOS to impose technologies like SecureBoot and "safe" deeper layer anti-cheats which actually work. Yes, Linux enthusiasts would be up in arms, but it would mean that the most popular online FPS games would be supported on Linux, and I think that's far more important.
Well, it's not intractable if it's pushed to the underlying hardware and signed drivers.
Valve could build something into their chipset and start signing the Steam Deck drivers, create secure boot etc and essentially create an Apple SIP equivalent. Wouldn't work for the rest of the Linux ecosystem or other devices, and people would absolutely howl about it, but they could do it.
The other side is linux totally permits you to do whatever you like to your system, and then it's similar discussion to DRM (digital rights management, not direct rendering manager). When you're trying to the user from doing things they're not allowed to and the same user can fiddle with the system, there's no starting point for trust.
This week we shut the doors on our Linux gaming podcast that has been running continuously for the past 13 years. No fuss, no drama, but with the announcement of Steam Machine II (we also covered the origianl launch) it just seemed time. Proton has evolved to the point most things work out of the box. Nobody is bothering with native and it's gotten difficuls to find things to cover.
It really feels like evertying is ligned up for the year of Linux in the Living room and yeah, it's really good to see.
I was looking for a tool to replace GreenWithEnvy since it seems long abandoned. It has an option to override the automatic fan mode threshold on Nvidia GPUs as of version v0.7.4.
./ironwail -game qbj3
Edit: Changing /Id1 to /id1 and making the *.pak files lowercase will allowed the MOD to launch correctly on my Debian system using ironwail-0.8.1.
reply