ไม่สามารถเล่นวิดีโอนี้
ขออภัยในความไม่สะดวก
The Nightmare Of Porting Software To Linux
ฝัง
- เผยแพร่เมื่อ 6 พ.ค. 2024
- There's so much software that could be ported to Linux if the developers wanted to spend the time doing so but most aren't interested and even if they are it's not simply just a matter of compile for Linux and then it's done.
==========Support The Channel==========
► Patreon: brodierobertson.xyz/patreon
► Paypal: brodierobertson.xyz/paypal
► Liberapay: brodierobertson.xyz/liberapay
► Amazon USA: brodierobertson.xyz/amazonusa
==========Resources==========
Factorio Post: factorio.com/blog/post/fff-408
=========Video Platforms==========
🎥 Odysee: brodierobertson.xyz/odysee
🎥 Podcast: techovertea.xyz/youtube
🎮 Gaming: brodierobertson.xyz/gaming
==========Social Media==========
🎤 Discord: brodierobertson.xyz/discord
🐦 Twitter: brodierobertson.xyz/twitter
🌐 Mastodon: brodierobertson.xyz/mastodon
🖥️ GitHub: brodierobertson.xyz/github
==========Credits==========
🎨 Channel Art:
Profile Picture:
/ supercozman_draws
#Linux #OpenSource #FOSS #LinuxDesktop
🎵 Ending music
Track: Debris & Jonth - Game Time [NCS Release]
Music provided by NoCopyrightSounds.
Watch: • Debris & Jonth - Game ...
Free Download / Stream: ncs.io/GameTime
DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase I may receive a small commission or other compensation.
"Factorio is a flow chart that looks like a game" - Brodie 2024
truer words haven't been spoken
Lol if u Google factorio it says "software" not "video game" 🤣
EVE Online players: "Wanna compare Excel macros?"
Factorio is the Vizio to Eve's Excel 😆
I use windows and I drive Bugatti oh yeah, did you guys find a solution on the recent open source backdoor?
@@sigmawolf228 Didn't a microsoft employee find that back door because he prefered to play with his linux instead of doing work?
For people who say valve does nothing and wins, just haven't seen the amount of stuff they have done for linux
lol I’ve been following Proton so long that I didn’t even consider this idea!
Fr. They've put a lot into this because they wanted the Steam Deck to work very well and it does. This benefits Linux, but overall, the gamers. Valve doing God's work
Valve basically single handedly made Linux a viable gaming platform.
@@KanokYTHeck, I got Ableton Live 11 to work on Linux with Bottles/Wine. Wine & Proton have gotten so good!
@@greatestcait Yep. Thanks to Valve, they slowly made Linux gaming go from "ha ha, pretty funny" to "most games just work".
I like Valve's troubleshooting tips for fixing some apps on gnome: "use KDE"
Solved all my problems 😊
How do I fix the horrible buggy inconsistent UI mess aka KDE then?
@@user-ps5up3og2h report the bugs and wait for fix. A reason exists as to why even valve goes for it
@@user-ps5up3og2h Use GNOME
@@user-ps5up3og2hwhat de are you even using if you think kde is buggy and inconsistent, and what do you even mean by that anyway? What bugs and/or inconsistencies do you experience
Remember guys, there's Wayland... and then there's GNOME Wayland.
I think it would probably be best to call it 'GNOME for Wayland'.
GNOME is, after all, a separate desktop environment supporting Wayland.
And now there is KDE Wayland, which is completely different from any other Wayland. Why? Because Wayland is defective and everyone tries to fix it. In a different way.
@ is wayland being defective related to the stupid way its made, as in some random no name DEs that are only used by their developers have veto privileges on features.
because honestly i wouldn't be surprised
Gotta love how X11 has "broken solutions that doesn't cover all cases", and then Wayland has 3 different broken solutions that doesn't cover all cases
Wayland's approach is fundamentally capable of being better while X11 is fundamentally incapable of being better... So whine all you want, but Wayland needs to progress for linux to progress. And for linux development time scales it seems to be doing pretty amazing lately.
12:25 it's funny how when Brodie started talking about audio issues, OBS decided to have it's own audio issues lmao.
I figured he did that for comedic purposes
I thought that was my computer having a stork
@@KanokYT ditto, seemed intentional
On the one hand, this seems like a Brodie troll, and that popping is a pretty easy effect to add.
On the other, Kdenlive just did this to one of my videos for zero reason (the source audio was fine), and the popping was still there on a re-render, so 🤷♂️
@@GSBarlev Hmm, maybe you could give these files to some Kdenlive devs so they can see what's going on? Easily reproducible issues can often be figured out quickly.
As a GNOME user, I am 100% in the camp of developers just not implementing CSDs for their applications and marking each bug report as wontfix. You shouldn't have to write any specific code for a desktop environment for your app to work. In my mind, having a weird looking undecorated window is the GNOME intended functionality since they refuse to adopt the xdg-decoration spec. 🤷 That's the experience they want I guess, so might as well not try to code around it.
Technically speaking, Wayland requires clients to decorate their own window if the compositor doesn't support xdg-decoration, but I think most people would agree that's unreasonable.
It makes a lot more sense for the compositor to be required to decorate windows that explicitly request SSD.
Most of the issues I thought were related to Wayland were actually related to the way Gnome handled Wayland, if you look at the list of Wayland protocols and who initiated the creation of them, most come from wlroots and Kwin/KDE. Gnome demanding CSD's wouldn't have been so bad if they had actually were also pushing and experimenting with a decoration spec. On the other side Hyprland has implemented a protocol to replace X11 global keybinds.
I vote for implementing CSD but adding a giant label that says GNOME is unsupported and linking to a wiki on why CSD sucks
@@BrodieRobertson Client side decorations are a godsend for making tabbed and modern looking applications.
BUT, there should be a fallback where the server kindly adds decorations should you not want them. KDE for the win, yet again
@@dexterman6361 I'm fully in favour of supporting them like KDE does but it's never acceptable for a desktop like gnome to not have them by default. You can make an argument for a tiler but that's a very different kind of desktop
It makes me sad when the native Linux version of a game in Steam runs badly or not at all, but then switching to the Windows version with Proton works flawlessly.
I remember back in the day being thrilled that a game I wanted had a native Linux client only to discover that it doesn't work properly with multiple monitors, forcing me to use Windows to play it.
Most of the other problems I've had with Linux ports have been modding support being hit or miss. Dwarf Fortress mods/tools for instance - while a decent portion of them work great on Linux, some are Windows only. IIRC Among Us worked on Linux, but getting mods working was a huge pain in the ass. Though modding support is also hit/miss with Proton - Palworld, for instance, was frustrating to get working with mods on Linux (though most of them did work properly once I figured out how to set stuff up).
@@masaufuku1735 Yea, Cities Skylines is/was like that. The base game ran great on Linux, but a bunch of mods (which were essential to me) I just could not get to work without crashing the entire game (and sometimes the entire system), which was usually a mono issue IIRC. Although Proton also caused a bunch of issues, hence I barely played as it just wasn't worth having a Windows install for.
On the other hand I‘m also a little said when games like FFXIV don‘t run on Linux natively at all and need proton.
Then again: The official mac version of ffxiv literally just runs wine.
I know it wont happen, but it would be so funny if lots of app developers would just remove CSD support from their applications and mark every issue regarding missing window decorations as wontfix because its a gnome bug. Just imagine the impotent rage from the gnome devs once users start complaining.
Edit: The absolute madman developer of the 'Tracy Profiler' actually did it.
wontfix: requires the OS to provide its own window decorations.
That would be very funny.
that would be amazing!
I think the gnome Devs genuinely wouldn't care, look at tray icons
I'm going to be porting my open source C# app to a cross platform UI framework soon (not soon) and when that time comes, if the UI framework doesn't automatically make CSD for gnome then I won't be bothering with it and will tell users that its a gnome bug.
props to the dev for upstreaming the clipboard feature to SDL
Factorio has some of the best Linux support of any game. One of the defining features of Factorio in general is that it's incredibly stable. It rivals developer tools like compilers for its correctness of operation.
Now you know why, you have a dev who is actually passionate about the platform
@@BrodieRobertson It's not THIS particular dev, though. As you said in the video, he's a recent addition to the team. Factorio had Linux support when it was still in alpha over a decade ago, and when I moved to Linux in 2019, it was just as stable as on Windows, and still a year out from release. If you think that means bug-riddled, nope! For all the bugs that get fixed in the changelogs, the game never seems to crash, even when it was in Early Access. I think the only times I actually have had it crash were due to buggy mods, not the base game itself. The devs are just really damn good at what they do.
@@BrodieRobertson It may also be because a large portion of their fanbase fits into the category of tinkerers, which are far more likely to be interested in daily driving linux than your average gamer.
Honestly, Mindustry shocked me with it's Windows-Android-Linux versions, all work really well.
Every single time I've fired up Factorio on Linux (which admittedly has not been recently), it's been a damn near flawless and fantastic experience. Hats off to raiguard and many game developers like them that put so much attention and detail into Linux support. They could "just" say "hey, it probably works okayish on Proton, stop complaining and accept this as is".
Also THANK YOU raiguard for calling out the absolute insanity that is having to leverage libdecor for literally just GNOME because they have their heads stuck too far up their asses to implement server-side decorations. Absolute based take and glad that Wube Software hires people that have good heads on their shoulders!
It's probably more that XWindows (aka 'X') provided a default and they never needed to do that.
The changeover from X to Wayland was a very, very big change to how things worked on Linux.
@@jnhartonno, it’s absolutely not. Gnome refuses to implement the existing protocol for ssd for no good reason.
@@jnharton X11 doesn't have any window decorations either. The only user visible things it provides are a desktop you can render a window to and a cursor.
xinit still just displays that by default: Checkerboard desktop and the classic 🞮 (X) cursor. If you start an xterm there you can't even move it.
All decorations come from a window manager like i3, kwin, fvwm3, xmonad or other.
@@joe--cool Don't think I've ever seen a X window without "decorations", though. And frankly decoration is a terrible word for something now deemed essential.
@@jnharton some programs don't work without. I cannot post links on YT but archwiki has an article on xinit. Since X11 is also a network protocol you can run "windows" on multiple servers with different operating systems and display it on your local Xorg server. I did that when using Solaris programs from the server on my laptop studying at university. It looks funny when CDE and KDE windows live next to each other. (There is also an X server for Windows, so you can do that there too)
Any devs that turned a command line thing into a GUI thing deserve a small medal.
As always, Gnome is a pain in the ass. I hope Cosmic will take a good a good chunk of their market share where we'll have Cosmic and KDE as the two popular DEs.
i switched to i3 last year from kde, and then recently to hyprland. there's really no going back, the desktop metaphor is ancient and unnecessary
@@bobdouglass8010 Yeah, while it can feel clunky using a tiling WM for the first time, there is no going back once you get used to it. I have been using a tiler for ~4 years now, and recently was booted into Plasma, which used to be my preferred environment, and it feels just as clunky using it now as it did when I first switched to i3 years ago (though I am also using Hyprland now),
Yeah, I'm hoping COSMIC lives up to the hype. It'll be a few years before it's stable enough that I might use it, but I'll be watching it with great interest.
As always, GNOME is a literal pain in the ass. But hey, Gnome has no decoration by design, closed as not a bug, wont fix.
At this point, Gnome should be seen as a bug of the Linux ecosystem.
@@stephanhuebner4931 Pretty much. :(
Then they say it doesn't have bugs, if they don't put half of the basic functions obviously there won't be Bugs XD
@@stephanhuebner4931 There really is no Linux ecosystem, though. It's more like a bunch of separate ones that semi-regularly interact.
It isn't a bug, and doesn't need to be fixed.
I said this last time. I would either implement the most basic Windows95-esque decorations, or alternatively just do nothing and simply say "not a bug on my end, report to GNOME. The DE is responsible for window decorations."
Just another case of GuhNOME causing BLOAT on porpoise.
You might as well just state that you don't support GNOME because GNOME expects the application developer to use GTK.
That would be honest communication instead of finger-pointing or passing the buck.
@@jnharton nah. Window decoration should be handled by the OS/Desktop unless specifically disabled in the application.
Why? Because everyone putting in their own window styles will lead to mismatched styling, possibly something like the minimize and close button may be switched accidentally on some software, potentially destroying hours of work, then there is also the fact that it will cause bloat if everyone has to write their own solution, it's a standard on EVERY other OS/Desktop, etc.
This is like forcing everyone to write their own audio backend instead of just supporting pipewire or pulseaudio.
Also this would just make it harder for a user to get a consistent custom theme to work.
Just so many reasons not to do this, I could probably go on for HOURS.
I agree that a null value should have a default replacement
@@joeschmoe7324 I would love if having no decorations would just crash the software on GuhNOME. That way you could always just blame them so much better.
Factorio should be classified as a schedule I drug.
More seriously, for me, Factorio scratches the same itch that makes developing software one of my hobbies. It's about creativity, problem solving and optimizing (and sharing code/blueprints). It makes sense they try to have it working on platforms used by devs, like MacOS and Linux.
On the broader topic of proton vs native, I think it will depend of Valve's decisions and success. A future with strong steam deck sales could incentivize studio to allocate the resources for a native port that doesn't rely on proton and is then easier on QA.
Tbf, they're putting in seemingly a lot more effort than most other devs. I mean, devs usually don't test their apps on something as niche as a tiling WM.
Some Wube devs are probably using WM themselves.
Well, in this case, Sway is what this particular dev was using, so it makes sense that he would test on Sway
@@fotnite_ oh, I thought they were testing on bunch of DEs and WM to find bugs.
@@donkey7921 If they're smart they tested it on KDE, GNOME, at least one spinoff of either, and whichever DE they personally use.
Doing any more would mean they were putting in exceptional effort.
That audio glitch around 12:28 genuinely made me think my pulse audio was messing up and that equal amounts hilarious and bitter.
Pipewire has a weird long running issue where CPU spikes break audio capture
@@BrodieRobertson I thought it was just me. that sucks bro
@IAmzColbz lol I thought my speaker cable was broken or something
The audio breakup around 12:30 is hilarious with the topic.
Sound bugs just spontaneously manifest whenever someone mentions PulseAudio. It even works in person.
Nice catch lmao
@@Poldovico a similar thing happened in a video where as soon as Brodie said "JACK" the audio started breaking
As someone who maintains a cross-platform non-game project with a ton of dependencies, I can confirm that supporting multiple platforms adds significant development overhead. For us, one Linux distro would be the easiest, but targeting many different distros makes it comparable to Windows and Mac. Something always breaks somewhere.
AppImage is a godsend-even more so than flatpak. Works everywhere, requires *zero* coordination with dependencies.
I think it is easiest to support the base distros like debian and arch so you would catch most of the needed dependencies without distros doing it for you (or even bare bone gentoo)
@@QWERTIOX The hard part is not collecting the dependencies, but rather fixing random issues. For example, our python scripting (embedded interpreter) broke last week on Rocky Linux 9 and Ubuntu 22.04 when python is installed via Anaconda, but it was still working on Rocky Linux 8, and Ubuntu 22.04 with python from the repos. You need to test on lots of different configs to catch things like that. And they all need to be fixed, too.
@@szaszm_ just one breaking change in any of the required libraries, and you have a mess. Back before you could easily create a network bridge easily in a config file, or a few clicks in a GUI, I used to have to compile kernels from scratch for our transparent firewalls, and sometimes it was five or more tries to get everything at the right level for all the libraries to be compatible. Once you got there, then you had to wait for the 486 to do the actual compile. And if I missed a needed feature building the config, I had to start back at the beginning. So nice these days, that most of the options that I need, are already compiled in, you just change a config to enable it.
This is ultimately why a lot of projects are choosing just to target one distro and then let the community sort out the rest for themselves. Frankly, these days most projects would be best off supporting just Flatpak, and at a stretch Nix if possible. Both are designed around granular dependency support and are usable on many distributions.
Terraria is an example of a truly native Linux game... When I get out of full screen it doesn't force me to a specific resolution and let's me make it any window size I please and it feels far less janky in general... So safe to say I REALLY prefer Linux builds
holy crap! ive been using computers since the 90s and some how never learned that you can drag windows by holding the windows key and dragging. you have accidentally improved my life, thank you!
My dad played the Morrowind game for 20 years without realizing that you can run by pressing the tab button.
GNOME and elementary do support it, but Windows does not. Never tested on KDE, Cinnamon and others, so IDK
@@softwarelivre2389 im using KDE and it worked when i was watching the video and found out.
@@softwarelivre2389 Works on KDE Plasma.
@@softwarelivre2389 Not sure if KDE does it out of the box, but I do have shortcuts on Plasma that let me resize and move windows just by hitting a key with the mousepointer. The wonders of a desktop that is endlessly configurable.
I actually helped debug a port of OneShot to Linux. It's up on Steam.
If you don't know what achievement that even is, then you never ever played that game or even saw someone play it.
Sadly it requires updates again. But back when the port was being made, it worked just fine.
Thanks! I've played that one, it's quite cute :D
for those that don't want to look it up, it a game with some meta elements (light spoilers on what the game does I guess), like how DDLC (Doki Doki Literature Club) is has meta elements
some parts have the floating window squeezed, as well as changing your desktop background (for in-game hints) and use the file system to solve a puzzle (which is late game stuff).
which is why it's little tougher than the average game to port.
on a side note, what these games need to do for console releases is interesting, where the game needs to make a fake desktop environment with fake file systems as well (to allow for an desktop like experience on console)
Imagine adobe tries porting but they say it's too hard 😭
Lol
ha ha
I'm frankly shocked that Adobe hasn't gone browser/cloud only by now.
adobe for some reason is very against linux already had talk with an adobe dev. very pro apple and microsoft.
long ago Disney ask them to port as they were moving to full Linux Systems, Adobe refused so they funded Wine so their designers can use Photoshop 😅, DreamWorks was VMware for it, Pixar was Linux only. Lot of their recent ai demo were using Ubuntu , so port might possible if big companies asked for it, I am hopeful after Wayland, Vulkan, ML stack become first class, it might be easy for them
I had a lot of fun porting our unity mod loader to Linux :3
Gaming isn’t a hard requirement for me but I appreciate how much I’ve been able to remove Windows from my life.
There are so many good and stable options for Linux gaming.
Any CAD software is basically unobtainium and probably will need nativ ports. And no FreeCAD is not a option.
You mean like specialized industrial software? Blender is FOSS, Autodesk has a Linux port of Maya, and more and more tools are moving to the browser/cloud, so I'm surprised to hear this.
There is onshape that works as a website. And I saw some repos that are made to run other cad software via wine (there apparently are problems but apps are working).
But yes, I agree that probably there is basically no "industry standard" cad software with decent support.
And from foss cad software there is FreeCAD, OpenSCAD and SALOME.
There is also Plasticity (not foss) which is "CAD for artists" and I know also about COMSOL which is FEM software but have some limited CAD features.
@@GSBarlev I meant parametric cad not the making funny shapes that conform to nothing 3d object design software.
@@Daniel_VolumeDown OneShape is not running on your pc so they actually want alot of money for VM hosting etc. and it’s also expensive even compared to fusion..
I tried the Wine stuff but just too many things not working.
@@GSBarlev blender & Maya are built specifically for animation. That is nothing like what is required for CAD. There is no linux equivalent to the giant that is Solidworks
I do wish Tim Sweeney would not have a hateboner for Linux. Valve has already done all the work for them.
'Member how Unreal and UT99 had Linux builds on the CD day 1 and even a little Tux picture on the box? I 'member
@@wallyhackenslacker I remember too. Unreal and UT99 were my drugs back in the day
I’m going into engineering as a career. I’d stick with Linux on my laptop forever if I didn’t HAVE to use Windows for the engineering apps I need.
proton made me switch 100%. no windows gaming pc anymore. game doesnt run under proton, i wont play it. before proton i had to use a windows pc. gaben is my hero.
Sherlock: I have connected the dots Dr.Watson
Dr.Watson: Watt does it mean?
Sherlock: He's a linux user
Dr.Watson: I don't git it sir
git: 'it' is not a git command. See 'git --help'.
The most similar command is
init
Sherlock: it's the hub of the green Watson; he plays Neverputt every Tuesday.
Watson: as your friend and a medical man, I cannot see you destroy yourself with this addiction.
Sherlock: I would give up Pokemon. But Pikachu is a worthy adversary.
Audio stutters when you mention SDL Audio backend 😂
I think it was on purpose 😂
On the off chance that factorio dev reads this, for fixing sway I suggest just adding a timer before applying a resize to allow for intermediate changes. Something lke this:
static w = 1024;
static h = 720;
static update_at = 0;
static needs_update = false;
resize( width, height )
update_at = time() + (SECONDS * 3)
w = width;
h = height;
needs_update = true;
end
...
while ( gfxloop )
if ( needs_update && time() > update_at )
...;
...
That would be fixing their program with respect to Sway and it might negatively impact the player's impression of Factorio on Linux.
I suspect the dev would prefer that Sway's developers implement a fix on that end of things.
And in case, the problem is likely that the game's display needs updates more often than Sway process resizing of the output.
In some ways it might be easier if the game simply delayed responding to resizing. That would ensure a stable display even if it was smaller than the window for a few seconds.
The whole process is a bit more complex than it looks from the outside.
@@jnhartonWell my suggestion is only meant as a stop gap measure, not a long term fix. Might be fine to just delay by only 500ms, I dunno, but a temporary fix for sway builds is definitely better than no fix, even if it means a temporarily poorer experience it's still better than getting flash banged into a seizure .
@@zxuiji nothing is more permanent than a temporary solution
-sun tzu
Another success story of porting a game to Linux would be ADOFAI (A Dance of Fire and Ice).
It's made in Unity, and as such I was able to make an unofficial port that makes the Windows build run on the native Linux runtime, which I deemed ALPOFAI (A Linux Port of Fire and Ice). One other player was interested by the project and helped me fix some issues with it.
A year or so later, they were hired by the studio that makes the game, and helped deliver an official Linux port, which still runs great to this day.
0:30
Yes. Gaming IS the hard requirement for me. I promised myself that I'll jump Windows boat, once I'll be able to enjoy some games on it. Once it became a thing, I did the jump. Now I'm on Linux for half a year now.
When I purchased Worms WMD recently I noticed they had a native Linux version and I was like yay. When that did not work and proton did I was like that's weird but just continued to play on proton. This makes sense now
Does Steam provide an option to install the Win-version of a game rather than the Linux-version? 🤔
@@cyangalaxy yes, going into properties > compatibility and clicking "Force the use of a specific Steam Play compatibility tool" forces it to use the Windows version of the game (after a reinstall)
It might just be an issue of an out of date build or older dependencies that aren't installed.
Windows is a proprietary operating system. You get whatever Microsoft software gives you and whatever degree of backward compatibility they choose.
The Linux world is a very different place, where the user has a lot more choice and control along with the inherent difficulties that creates.
Going with a mainstream distro and sticking to it's default desktop environment and standard applications spares you from having to essentially build your own distro.
I think it's a good point he made about the amount of issues created by Linux users. Never did actually consider this but of course Linux users are somewhat tech sawy so I got really annoyed as I've heard this justification to drop Linux support or leave the proton layer broken. Great to hear the exact opposite here!
The funny thing is that for open source software, those nerds are also the ones submitting PRs. I maintain a handful of Minecraft mods which, being Java, function identically on all operating systems. But half of my bug reports, 3/4 or my issue discussion and 100% of my outside contributions come from Team Penguin.
i read the factorio post when it showed up in my steam news, but i didnt expect to see it being talked about here
My hope is that GNOME caves and implements SSD support a couple years down the line (probably would take quite a few years). They've caved on other stuff that they previously removed support for, for example they've recently started work on an alternative (and from what I've seen, superior) version of tray icons after years of removing them and ignoring the consequences.
I feel like there's gonna be more pressure on them to implement it once there's more than just them, KDE, and Sway being the only significant groups, and especially after COSMIC releases and people start making apps using iced, or trying to install COSMIC apps on GNOME. For a while, GNOME made up by far the majority of Wayland users, because using standalone compositors was pretty niche and Plasma didn't have very good Wayland support until very recently.
12:28 Odd that you started having audio glitch exactly as you started talking about audio subsystems
Just seeing the title I knew that GNOME would show up
Gaming isn't just a hard requirement for users. It's essential for mindshare. Kids need to grow up playing on linux if the idea of linux is going to survive into its 4th decade. The gamers are literally the future of hacking and computer science... always have been. Most of us did our first hacking or programming to mod games for our HW or OS's...aka budget videocards that windows or older games wouldn't support. My favorite is porting xwing alliance to directx11 with 4k resolution! It's such a great gaming experience... provided you can get XP to run on modern HW! ... too bad linux just isn't an option here.
This, all my kids would be on Linux if roblox worked.
12:28 funny that the only time your audio has issues is when you're talking about an audio backend
This was a cool topic. It makes more sense now just how much it takes to move a codebase over.
I apparently knew nothing about the RADV driver module for amdgpu and had to use that the other day to get something working after rendering errors.
After I loaded it though, specific program combinations will cause any program left with hardware acceleration to fight to survive. Things like discord, Steam, and my web browser will crash until only one left is open.
Is there something about configuring amdgpu that I missed?
If someone comes around saying GNOME devs are actually receiving funding to hinder Linux adoption, I'd believe at this point
To be honest, it's not just them.
Let's just say that there's a reason people don't like programming anything graphics related on for it. The stack is insane, truly insane.
Am i the only one nervous that valve may one day say: meh, we don't care about linux anymore.
That's a concern for sure
The probability increases the more we push broken protocols like systemd and wayland
Not just that, but I'm highly uncomfortable about so much depending on one for-profit company.
@@gogudelagaze1585 That's always been the open source way though. One person/one org starts providing a lot of stuff and you use it all because it's useful. Then they go away and either the stuff stops existing or someone else picks it up. Proton is open source, right?
While I think that's an issue, as long as they open Proton and let everyone make their own fork of it or possibly even maintain it, we should be fine without Valve.
This is awesome. I just bought a copy of Factorio based on this video.
It's a great game. It's even better after you win and load up krastorio and space exploration
It's been nice knowing you! I'm sure you will be missed.
My advice is, spread out. Don't try to cram everything into the smallest space possible. In the end, you will find yourself struggling more and more to actually keep your production rising. Learn about busses, and do modular type builds.
We used a similar fork trick but in the other direction, on new data package parent would fork and continue serving requests, child would load new data package. Once loaded listening FD would be past to child and parent exits. We did hit performance issues on paravirt on aws instances (they fully copy proc address space on clone switching to hvm solved for us). During the save operation the memory will be mapped in a Copy On Write mode so if 'volitile data structures' can be written and freeded from the saving process early then additional cpu/mem of the fork can be minimized
Every time I try Wayland I have to revert back. I still have issues with font rendering all over the place and the scale is kinda weird to on my 1440p monitor.
It is important to say that official Proton support is one way to "properly support Linux", I don't particularly like that false dichotomy at the end.
Just like Android using Java APIs in ancient times, Linux using Win32 APIs (aka Proton) is a completely valid and sensible approach. For a game targeting Linux, it is not any less "native" to target Proton than to target APIs exclusively available on Linux. For obvious reasons, Proton is often thought of as an emulator, but in a real technical sense it isn't that at all. This isn't only a gimmick with the name "Wine". Proton exists on the same level as other native APIs, and choosing any particular API is comparable to choosing Angular vs Vue vs React for web applications. Developer convenience is the most important consideration for that choice.
Now, I think Valve should make it much easier to use Proton as a development platform so that game developers can just use Linux as a daily driver for themselves. If that starts to become common, as it already is for many web developers, Linux support in games will just naturally be available, even if a studio allocates zero dollars to it. By then, the cost will be on maintaining Windows support (because the fringe differences between OSses - as discussed in the video - will continue to exist.) and Microsoft will then start chasing Proton comparability, instead of Valve chasing Win32 comparability.
Will this ever happen? I have no idea. But with Android as an example, this could just gradually become true one day.
WINE implements heaps of the Windows stack and the GUI framework still looks like it's from 1995, basic usability issues (explorer.exe sucks ass), more primitive stuff calls glibc and X11 functions adding overhead, so I wouldn't say it's on par with native support, the only thing that is basically "native" is OpenGL and D3D support, the D3D11 -> Vulkan conversion has zero penalty because it's so much lower level, and OpenGL is almost 1:1 except for the Windows to X11/Wayland window setup.
@@woobilicious. I'm not exactly sure what you are getting at. (And I think what you're saying is not correct, let me explain:)
If you're running a desktop/"windowed" application, that application may be using the GNOME platform, the KDE Frameworks, Windows USER or COMCTL, etc. These are all libraries that provide GUI functionality built directly on top of the OSses low-level drawing API. On Linux this can be Xlib or wayland, on windows it is GDI. The GNOME platform and KDE Frameworks support drawing with GDI on windows. And Wine provides an implementation of USER and COMCTL drawing with Xlib on Linux. There are no significant "layer loops" in the sense that an API is implemented using another API that is logically on the same abstraction layer. The absence of a layer loop seems to also be your point about D3D11 -> Vulkan through DXVK. And I do agree with you there, although IMHO that's actually already one of the more significant detours. So if you're accepting that argument for DXVK, I don't see why you wouldn't accept the same for all the other APIs.
Unfortunately I can't make sense of the part where you talk about explorer.exe etc. If you're a developer creating a game that targets Proton, what does a bit-rotten part of the Wine codebase that you will never touch, have to do with your choice of API? Those parts are available for legacy reasons, and probably can't easily be removed. When you said it is not "on par with native support", I'm confused whether your trying to compare wine's explorer.exe with microsoft's explorer.exe, or with Nautilus/Dolphin? Either way, I just don't see what you're trying to say with those comparisons in the context of Proton being a viable API target for new developments.
Anyway, I was specifically talking about Proton, since I think that the game related APIs from windows are worth supporting well on Linux. (USER and COMCTL are a giant legacy mess and nobody even on windows should be targeting those APIs, better options are available.) Much more relevant than GUI libraries are audio and input libraries, etc. But the same argument applies here; layer loops are just not a significant part of these implementations.
PS: Maybe I'm a bit direct in this post. It's not my intention to be randomly flaming you. But your response came across as weird to me, and hopefully this explains why.
It's still kind of nasty to rely on a 2nd or 3rd party implementation of a one platform's (x86-64, Windows) API to run your game on an entirely different platform (x86-64, Linux).
There's no guarantee that WINE or Proton will continue to be up to date with the latest Windows API.
@@jnharton An API cannot be owned. If Proton ever becomes a more important platform for running games than Windows is, then it will be Windows that must try to be up to date with the latest Proton API.
Android's take on the Java API's is a very good example of this. Initially, it was important for Android to have source code compatibility for Java libraries so that app developers could tap into the huge existing Java ecosystem. Over time, Android has become an important platform to target in its own right, and Java compatibility is not an issue at all anymore.
Another, slightly different, example are the Web APIs. Initially, Netscape was the target platform for most websites, and browser builders were forced to follow its lead. Then IE took over the position of platform that most websites were targeting, and the other browser builders were forced to follow its API choices. Then there was a time that browsers got so good at cooperating their API design that in practice most websites really didn't have a main target they were trying to hit. And today, things are still pretty compatible, but the Blink/Chrome dominance is pretty often becoming the only target that websites care about anymore, which leads to reduced usability of other browsers.
All of this has nothing to do with who created or owns the API, there will always be implementation differences (even if they are only performance related) and if developers choose to use an implementation to use during development, then their software will be best tested with that implementation. Proton is a very long way off, and there is no guarantee this will ever happen. But if the dominance of the Steam Deck for casual gaming persists, then there is a chance that the future moves in that direction. With Proton becoming the de-facto standard gaming platform.
Having ported a few applications between Windows, Android, Linux and MacOS, I am very much in the camp of Win32 (wine or proton) being the best Linux API. It is stable, well documented, and generally doesn't have breaking changes. Heck, it is also the best Windows API despite Microsoft's attempts at replacing it.
Porting an application or game to Linux isn't incredibly hard, though it can be if you make it. If you for example start of making it for windows, and heavily mix the logic for the application, and the stuff that handles OS stuff, it can require a rewrite to make it work on Linux, also writing it in some specific languages (like C#) can make it extra hard to port over.
If you start from the beginning by separating OS code and application code it can be way easier to port it. For example, if you treat your application logic more as a library that you call from your OS related code, then you can just implement different entry points for different OSes and call the same application code. You could also treat your OS code as the library, and call that from the application, then just swap out the implementations depending on the OS you are compiling for.
Though to be fair, even if you do this, there may be a few things in your application code you might have to fix/change to make it work properly, but compared to the potential rewrite you would need if you too heavily mix the application code and OS code, it is a lot less work.
it is not just about porting, you have to QA lot of stuffs in Linux, X11 vs Wayland , musl vs glibc, so many audio drivers, so many drivers for same gpu 😅, different distros with lot of differences , after all this NixOS users will threaten you not supporting them 🤣, also forgot about stable api
@@tui3264 It's not really a game developers job to worry about graphics drivers and sound drivers.
i tried to play the psychonauts linux port it has micro stutters running it via proton does not have those
Quick example: been enamored with an rts stealth em up by the name of Crookz: The Big Heist on Steam Deck. but when I dock and change resolution maaaan does it misbehave. Figured it was a Proton issue, noticed it was a native port... forced a Proton version, downloaded the Windows binary and... not only did it work, but it also got rid of a LOT of the stutters I was having during gameplay.
Even under Proton, I've been having problems with Helldivers 2. On an X11 desktop, the monitor's resolution does not show up, forcing me to play at a fraction of the max resolution, and upon successful extraction, I suddenly loose connection and get booted back to my ship. On Wayland, the graphics work, the connection is, somehow, more stable, but SHIFT and CTRL do not work. It cuts off access to sprint and crouch on my key binds.
These are things to report to an appropriate repo's issue tracker I'd say.
i like games that play natively on linux, like tuxcart, warzone2100, 0ad, blobwars,minetest etc. using SDL as the backend library really helps with porting. It also helps when the game sticks to c/c++ and doesn't use "trendy" build systems which change so often that compatibility of the build system is a problem.
Nothing wrong with a good old CMake project building your C++ game, I really am sad that most game developers are now using higher level langauges and avoid optimisation/native-solutions like they are a plague and this is true even in the Windows ecosystem, people would rather be wrapped up in a fuzzy blanket of high-level warmth than solve real problems.
Great content. Games aren’t the only thing g blocking me from full time Linux, but having to reboot to engage in games is a consideration when I boot to either windows or Linux for sure.
I vaguely referenced this on another one of your videos, but in addition to limited gaming options (which have admittedly improved greatly in recent years), the big thing holding back Linux from most consumers is the lack of music and design/graphic options, eg: Gimp doesn't hold a candle to Photoshop and there's nothing comparable to Clip Studio Paint on Linux. On the music side it's a damn shame though since Linux could hypothetically provide a better experience, eg: a Linux distro that has certain DSP functions -- like those in the 56K DSP chips -- baked in at the kernel level for audio software to take advantage of. At that point we're talking about purpose-built Linux distros for the masses, but honestly I think that's for the better.
Hi Brodie, i noticed some audio crackling at around 12:25 in this video. I have the exact same problem when recording with OBS. It seemingly happens occasionally and randomly. I searched a lot on the net to find anything about that problem but i only could find stuff that was not related to that exact problem. It drives me nuts. I wonder if you might have an idea what is happening here and why OBS does this sometimes when recording under Linux with OBS.
It seems to be some sort of issue with pipewire breaking with random cpu spikes
@@BrodieRobertson It's kind of fitting that as you're talking about audio issues in factorio your own recording breaks
@@lunchbox1341 That's why I didn't rerecord it
omg is that a squishmallow in next to the shelf???? Look at that little doggyyy =D
Im glad FFF# made it into a Brodie Robertson video. They are the best dev blogs
A part of me wonders if Linux would benefit from more under the hood standardiation? Closest comparison I can think of being something like POSIX but extended to be more relevant to a typical Linux distro.
I've had issues in the past where I literally had to switch distros because specific software wouldn't work for one reason or another.
Gnome devs care only about Gnome, what else is new?
Maybe there needs to be some consensus between game devs on what they require in order to support a Linux version. Like a low level container specifically for games that will provide a stable environment with needed packages etc. (and a window top bar 🙄) and distros can be the ones to choose if they want to support gaming or not. Like proton I guess, but move the responsibilities for native gaming support onto the distros.
thanks for the video!
I didn't know that fork and CoW (copy on write) was not a thing on windows. I hope windows will catch up someday in a few decades.
It's not necessarily a matter of catching up. That would imply that the Linux approach is the best way (and has no downsides) as opposed to just being different.
Windows has apparently had functionality equivalent to fork for a long time, the problem is (or used to be) that cloning a process poses some complex issues and it works best if the OS was created with those things in mind...
Needless to say that was not the case with Windows, which was original a single user, single tasking OS.
As an example, if you clone a process that's connected to a database you probably don't want both processes using the same connection. So you need to create a new database connection!
Depending on how that part of the application is handled, it could be kind of hairy to get stuff working.
A particularly annoying case would be if some core function came from a DLL (dynamic link library) and you would need to load a second copy in order to satisfy the requirements for your process.
Supposedly if you try that on Windows you just get a pointer to the already loaded dll, not a new dll (unless it's an explicitly different version).
Copy on Write as a technique aims for efficiency by having both processes work with exactly the same resources. It puts off the copy and concomittant growth in resource usage until the child process tries to write to something....
This just one of many places where you find out that two software systems that appear to be functionally identical most definitely are not.
I have read that btrfs wears down SSDs a lot faster than EXT4.
@@atomicskull6405 we are talking about COW of RAM pages and not COW of disk sectors.
Same concept different topic.
I think it really depends. If making the game specifically for Linux lends some specific benefits I'd like to see that. But with Proton being as good as it is, if playing a game via Proton doesn't come with any real down sides, and it makes it easier for developers to keep the games working on Linux, I'm all for that too.
Never thought of the gnome thing with CSDs. I mean I use Unity but I'm on an old build, and knowing Unity, their Wayland player support is still probably not fully there. Luckily adding a CSD to my game isn't hard since the in-game UI already has a status bar. Turning that into a CSD would be trivial. But....great....now I have to worry about that.
I would hope unity just deals with the problem
@@BrodieRobertson One would hope...
One would hope.............
but sometimes they don't.
As a relatively new user that mostly uses steam/proton for gaming, it seems odd to me that Wayland users look down on GNOME, when GNOME and X11 actually work for gaming, but I couldn't get Wayland to work in over a week of digging through forums and documentation. KDE was pretty, but the gaming under Wayland was a stuttering mess.
I run a complet X11-system and want to run Plasma-X11. I need to install Wayland as bloat! Why getting rid of the dependency for X11?
I wrote a game in Linux for my master thesis back in late 00s. I couldn't make the binary work across different versions of Kubuntu not to mention making it work across different distributions. It was easier to port it to Windows than to port it to newer version of Kubuntu 3 years later :) Eventually I gave up because I've choosen a library for in-game UI that soon ceased to be maintained (libparagui if anybody's interested) and I had to recompile it and fix problems with it to even make my game work with each new distribution version.
If you start with portability in mind, it isn't that difficult to build a game that compiles to about anything; even with an universal SDK, but you have to plan for that... BTW, Allegro back in the day of the end of the DOS era was really neat for that, because it provided abstractions for everything (sadly it lacked a plugin system).
Wouldn't something like flatpak be able to keep older Linux ports running even if they are out of date?
Depending on the situation, developers could just ship a statically built executable.
Flatpak is essentially just yet another alternative package management system plus some extra features.
You could keep older Linux ports running with almost any such system, it's just a question of relative overhead.
@@jnharton So it is possible to make a "end of life" built of the game that could run without to many problems.
i actually prefer having native linux support, since on older hardware the performance difference may be much bigger between a native version and running it on proton
I'm an amateur game developer who has his own game engine, and I dwelled into writing my own SDL-replacement (as SDL is garbage) but I'm actively looking into SDL alternatives instead. I might keep my Windows/Linux audio implementations though, since I have my own mixer, and as such "function that plays WAV/MP3" type of solutions aren't ideal for me. And there's also the issue of absolutely abyssmal I/O support (some are still using the ancient DirectInput 8 for handling input devices), missing critical features as long as they can be clunkily worked around, but having things that are in almost every standard library except for some obscure device/OS.
9:20 it sounded so much like you that i didnt even realized you were reading, i thought that part was you making a comment on what you were reading before 😂
Good dev, showing what it means to be a maintainer.
Honestly these are things I had not considered. My wine support experience with wow made me wish there was a native client but I can see why this wouldn't be feasible if these are the kinds of issues blizzard would need to deal with. Are these just solved problems in windows land ?
I wonder when 2.0 releases to make a comparison of performance between just running proton and playing the linux version.
Factorio is massive for optimization since really big bases (10k+ science x minute) are limited by your cpu.
But in other games i wonder if addind linux support is worse than just making it work with proton, if it doesn't work from the start.
Actually it's quite fun... But so daunting: you gotta implement support for multiple extensions, such as wl-shell, xdg-shell, because of constant updates. Besides that, it gets quite complex, as you add seats (seats are responsible for handling input and stuff), but it's kinda cool. I'm not sure if GLFW supports wayland, but what I can tell for sure, is that creating a wayland surface manually and integrating it into vulkan apps using vulkan WSI stuff is not hard, it's just extremely time consuming. It was a love, turned into hatred, turned into confusion and acknowledge, then into something even more hateful, just to turn into a love again
GLFW does support Wayland and it generates headers for extensions in the newer versions
@ ayo, that's actually nice! Thank you ^^
i defend gnome for so many of their stupid decisions but i cannot stand the csd ssd decision. it's just so unimaginably stupid
10:57 about that… I game exclusively in tiled mode because I need the extra info in my status bar
I have been dabbling with linux for decades now technically. In the whole time I have been aware of wayland, it has been a problem. I always hear how wayland support is coming along, but then a tip to switch to x11 for better performance or even certain things to work at all. It's almost makes me feel similar to the frustration of Star Citizen never being finished, or nuclear fusion. It's always coming along, but never seems to be near.
I've said it before and I'll say it again, if tou wanna treat your project as a personal hobby you design for your own standards I wish you the best and it's wonderful that you're having fun, don't expect for other to bend over backwards to support you bc you don't use the standard. If gnome doesn't want to prioritise devs and user over it's opinions, they shouldn't be surprised if someday when linux is much more meaningful in the desktop space they're the ones no one support
Technically yes, but the end users don't care. It either works for them or it doesn't, and if it doesn't the application's developer is at fault and they will go somewhere else. Unfortunately app devs must support and workaround many bugs of the OSes and hardware. Big company made a product, but they received CPU with faulty memory blocks and this hasn't been found until pretty much almost everything else was done, so the only option was to probe memory faults on boot and inject dummy memory reservations in these regions, otherwise everything worked flawlessly - even large corporations are not immune to this crap.
I bought Factorio recently, partly because among the games I was interested in, it actually had Linux support and I have to say thanks to the dev, because it runs flawlessly on my system. And it's a great game if you like city builders!
Very recent example: Last Epoch left early access recently and has a native Linux version. Sadly, it has gamebreaking bugs and I use the Windows version via Proton instead, which works perfectly fine for me and even has more features.
Just spitballing about what would make supporting games for Linux better. Perhaps either a sandboxing, such as flatpak, or containerization such as docker, podman or apptainer. Probably wouldn't want to do on docker since it needs privileged access.
As for porting itself it would be interesting in the future if AI could assist with this. I imagine it wouldn't do all the work but would be more like helping create an outline and sketch. At least until it gets good enough to do it all.
Although, it would also be kind of nice if copyright law was such that once software is public domain that the source code along with the assets is available. That way you at least have the raw stuff and any enthusiast for a legacy/retro game could port it to any system they could compile and get it to run on.
I like native Whatever OS *and* native Linux support because it means ultimately writing code consciously and merging different approaches into a new standard. You don't want to maintain 2 versions of your code for 2 OS..or even more. Game Devs want to get the dependencies they need ready, choose the target environment and spin up their build process and ship their compiled application without changing anything in their code to make it compile (and run) on another system besides their main target system. This is the only way we will achieve and maintain a great and varied library of games on other systems than Microsoft products.
I can vouch that the asynchronous saving is pretty cool, no interruption while I'm getting run over by my trains
Wayland isn’t ready yet. It made my monitors look weird.
3:08 I noticed recently, a lot of switch games outsource that maintainment to companies like Panic Button.
I actually like the fact that GNOME forces to implement Cliente-Side Window Decorations, so all apps need to somehow keep up with the GTK4 library. - That's how I see the Linux Experience, and I'm just a 2 weeks old GNOME user after being almost a 10 years old XFCE user... I have always thought that apps without that feature were just unmaintained, obsolete, old, or simply ugly, using a bar for something that can approach space in a pretty way. Hope XFCE get something similar for all their apps.
lol the url just says _No at the end
HDR is coming before the end of the year. And Wayland Wine should be done around there too.
Anyone else noticed how much smoother a lot of Windows games run on Linux? I'm not talking about framerates I mean lack of frame judder and micro stutter even at 60fps. This is especially apparent on 2D scrolling games like Pizza Tower
I am curious if more game devs should be using something like flatpak to fix these issues with dependencies but personally I am not a dev myself and not sure if that would fix anything. Plus steam store I assume right now does not support flatpaks but maybe they will someday.
The major problem with a FlatPak is that it bundles the libraries inside it, so if you download three games that use the same libraries, you've got three copies of those same libraries on your system, which completely defeats the purpose of the `lib` system on linux.
To explain it a bit better, installing a native application can be as simple as downloading 500kb of libraries and the main application itself, with a FlatPak you could suddenly be downloading 300mb of libraries you already have installed on your system and will be packing them inside a node on your filesystem just for that one app.
This is why Windows is incredibly bloated, by most apps bundling runtimes with them rather than having the user install the common run times once and matching versions in a sane manner.
@@Rexhunterj saving a few gigabytes on a desktop home PC is no longer relevant in a world with cheap 4gb SSDs and 10TB HDDs. It now causes more problems than it solves on and it's time for it to go. End users expect their PC to "just work" and this is one of the things that's actually holding back Linux on the desktop. The only way I can see the linux desktop ever replacing Windows is an immutable distro and flatpacks (and if you really want to tinker on such a system there's still distrobox)
Yeah, Vulkan is nearly abandoned on DotA2, and it is just a matter of time before DotA2 stops working on my linux machine, because they dropped OpenGL support. SDL has also been a painpoint with dota2 as well, with really weird bugs pooping up after seemingly every update.
Whenever people have brought up native linux games to me, I have always been aware that you need talented and dedicated individuals to keep the linux build maintained. If developers are focusing on NOT breaking proton that could be good enough for me. I just want to play the games and if I get the same performance as being on Windows I'm all for it. I'm happy with Proton but if a dev wants to do Native Linux Support I will not say no.
What is the state of wayland now a days? How is the nvidia support for it now?
2024, using plasma6 on wayland; still can consitently crash plasma with clicking fast enough out of a freerdp client on one screen to the plasma taskbar on my second screen.
Proton is the way. The windows runtime is the defacto standard, and we have an excellency compatibility layer in proton/wine