Friday Facts #408 - Statistics improvements, Linux adventures

[Svip]

Just an unimportant off topic question.
Is (or will be) the multi-pointer functionality (2 or more active mouse cursors) supported in Factorio 2.0? Could be fun playing the game with two mice simultaneously.

I am curious... are there any computer games that support this? I've never actually played one (or heard of one) that did.

Any game that works on a platform with primarily a touch-based interface that allows multi-finger gestures supports this. Since each finger is effectively an individual cursor. SDL and X11 supports it, to allow for them to be used on such interfaces. If you can pinch to zoom in a game, then the game supports multiple cursors.

As for games not for these platforms, it's less likely. But SDL supports it, and if Factorio already keeps track of which for SDL's mouse event, it should also support this.

[CommunistCatgirl]

As for server-side decorations the situation is a bit more complicated than this post and a lot of people make it out to be and I'm a bit disappointed to see GNOME dragged through the mud for something that isn't really their's or anyone particular party's fault directly. Wayland was designed with modularity and extensibility in mind and not only desktop use. This kind of modularity means that only the core wayland spec is mandatory to implement by anyone while everything else is essentially optional and depends on what kind of usecase the compositor is targeting. Unfortunately this does lead to some feature fragmentation (one of the side effects of trying to make one thing that is generic that works for everything) but it does mean that if factorio or any application wants to run on any compositor they would have to work within the core spec + xdg_shell as much as possible. In other words, if it wasn't GNOME today it would be another compositor tomorrow that didn't support CSD for a variety of reasons that would then require the use of libdecor anyway. In fact the reference wayland compositor Weston (though not really meant for desktop use directly) and Valve's Gamescope do not support the protocol. The xdg-decoration spec even states "If compositor and client do not negotiate the use of a server-side decoration using this protocol, clients continue to self-decorate as they see fit."

Were SSD to be mandatory, it would indeed suck that the compositors that don't care about any consistency, whose count is and likely will stay in the single digits for quite a while, would have to take the couple hours to draw a flat-color rectangle with 3 buttons on it, but, as-is, the problem is significantly worse, requiring each of thousands of applications to do it instead. And if those very-few compositors think it's that much of a problem, they could share a library to do it for themselves server-side, relieving hundreds of client-side applications from having to add a dependency for what should be an utterly trivial feature.

If a compositor wants to only target a specific use-case, it could just decide to not implement things not needed for said use-case (or, say, support SSD where the decorations are empty and enabling them is a no-op; if they don't want decorations, they, well, should be fine with not having decorations).

The obvious end-game of no guaranteed SSD, for the 99% of applications which don't have reason or resources to write linux-specific decorations, is, clearly, unquestionably, just slapping on libdecor, a library whose only job is to fill the hole of GNOME, and which won't fit in with the application, and won't fit in with the compositor (maybe unless the compositor happens to be GNOME, or someone for whatever reason decides to extend libdecor to match their compositor instead of contributing SSD for said compositor directly).

And there are benefits to CSD as well. For example, visual consistency of different applications is basically impossible unless they are using the same toolkit and were made with the same design language. With SSD the only thing that is achieved is the window decoration looking out of place compared to the window itself. In fact I really like how the black decoration looks in the screenshot of the user from the CSD bug report, it matches the black vignette of the factorio main screen way better than a bright white decoration from a user using light theme on their desktop ever could.

Indeed, there's absolutely a place for CSD, but that's no reason to make it mandatory. I doubt the black color changes when getting in-game where it'll cease to fit in, and you absolutely cannot expect that most applications will do any such color matching (never mind for the tiny marketshare of linux, as I doubt much such effort goes/would go to even windows/macOS).

Maybe I wasn't fully clear in my previous message. Non-guaranteed SSD isn't a hypothetical, its how wayland works because all optional protocols are optional. This is the status quo, now! We can have a discussion about how that is an oversight of the original protocol, but that's how it is right now and the assumptions of software already written can't be changed retroactively, so we have to roll with it. As for the scale of the problem, it's exaggerated. Applications using certain toolkits already do CSD by default. Even most (all?) electron apps I use do CSD and they are glorified web browsers. As for games, SDL supports linking to libdecor and using it so this is also basically minor. The "thousands of new applications" sounds scary until you realise >99% of them already use CSD (blender, web browsers, whatever) or use toolkits like GTK and Qt and electron where these are the default anyway or SDL which can also deal with it.

As for consistency, SSD does jack. If you want all your apps to look consistent you need to use only appliactions using the same toolkit and design language, there is no shortcut for that. Factorio will never look "consistent" with your desktop and it doesn't have to, nor should it, its a game with its own style and that's awesome. What it can do with CSD is make the decorations match itself and it will look better for it since it will look like a consistent window. In fact this is only possible with CSD, since the client can render whatever it wants on the decorations and make them match. A compositor could never achieve this consistency.

Your recommendation for compositors supporting the protocol but making decorations a no-op is recommending someone makes a buggy compositor that doesn't respect the app's wishes, so I'm not sure how it solves anything other than make everything even more confusing for applications, since they'll think they are getting decorations when they aren't. It also... still has compositors that don't support SSD so I'm not sure how this even solves the suppoded issue in any way?

[dzaima]

Maybe I wasn't fully clear in my previous message. Non-guaranteed SSD isn't a hypothetical, its how wayland works because all optional protocols are optional. This is the status quo, now! We can have a discussion about how that is an oversight of the original protocol, but that's how it is right now and the assumptions of software already written can't be changed retroactively, so we have to roll with it. As for the scale of the problem, it's exaggerated. Applications using certain toolkits already do CSD by default. Even most (all?) electron apps I use do CSD and they are glorified web browsers. As for games, SDL supports linking to libdecor and using it so this is also basically minor. The "thousands of new applications" sounds scary until you realise >99% of them already use CSD (blender, web browsers, whatever) or use toolkits like GTK and Qt and electron where these are the default anyway or SDL which can also deal with it.

I am fully aware that SSD support is optional in wayland, but, hypothetically, the spec could be updated to make it mandatory in a new version, and, in time, applications could start assuming that it will exist and not bother providing any fallback, just as with any version update of anything ever.

Indeed if you're using a toolkit you'd hopefully get CSD automatically, but it still sucks for developers of said toolkits and anyone who wants to use wayland directly in general. I think it's extremely poor design to wave away the issue with "just use an existing toolkit or library", essentially making the wayland protocol less approachable than it could be. And toolkits should still significantly outnumber compositors.

As for consistency, SSD does jack. If you want all your apps to look consistent you need to use only appliactions using the same toolkit and design language, there is no shortcut for that. Factorio will never look "consistent" with your desktop and it doesn't have to, nor should it, its a game with its own style and that's awesome. What it can do with CSD is make the decorations match itself and it will look better for it since it will look like a consistent window. In fact this is only possible with CSD, since the client can render whatever it wants on the decorations and make them match. A compositor could never achieve this consistency.

Yes, SSD won't make decorations consistent with their respective applications, but CSD by no means will guarantee that either; namely, anything using libdecor (i.e. a bunch of things) will not be consistent with the application (i.e. gets zero benefit from having to do CSD) and won't be consistent with other apps either (i.e. a thing that SSD could improve; not only colors/icons, but things like guaranteeing the close button covering the top-left pixel and remaining usable while the application is lagging; and SSD doesn't necessarily need to not fit in with the application, i.e. a compositor could, if it so chooses to, infer the decoration colors from the app).

Again, indeed, if an app has the resources to make custom linux CSD which fit in with the app, CSD can have good benefits (and I think CSD should be an option regardless of whether SSD support is required!), but most are just not gonna bother and end up with the worst of both worlds *and* require a library to achieve said worst of both worlds.

Your recommendation for compositors supporting the protocol but making decorations a no-op is recommending someone makes a buggy compositor that doesn't respect the app's wishes, so I'm not sure how it solves anything other than make everything even more confusing for applications, since they'll think they are getting decorations when they aren't. It also... still has compositors that don't support SSD so I'm not sure how this even solves the suppoded issue in any way?

That recommendation is for, quote, "compositor [that] wants to only target a specific use-case", and if that use-case doesn't include any applications which want SSD, there's literally no need for any SSD functionality by definition. And if the compositor's indented use-cases do include SSD-wanting applications, well, it'll need to support SSD regardless of whether the protocol requires it. And if it's intended use-case is arbitrary applications, it's not much of a specific use-case compositor.

[_xer_]

Finally, it's needlessly hard to click on a specific item in the filter list if there are several at the same production rate. A common scenario: you're producing red, green, and blue science at the same average rate. You go to see how your blue science is doing. But in the moment that you try to click on it, a couple of red science assemblers happen to finish so it jumps up above the other two and you accidentally click it. Then you try to click it in its new spot, and it swaps with green science. And then you try to unclick green science and red science, and end up clicking on blue twice. And then you decide that you know what, it's probably fine, you don't need to know. The suggestion was made a few FFFs ago that logistics network contents should only get ordered by quantity when you open the panel, so that they don't jump around if things change while you're reading; I would apply that to production statistics too.

Why should you need to click on a specific item in the list at all, even if it's not moving?

There should just be a filter slot, where you can select an item the same way you do everywhere else in the game.

You already know where the items are in the filter menu, so it's easier to select that way rather than searching for it in a list sorted by production rate. You're also typically looking to compare items that have a similar function, not ones that have a similar production rate, so selecting from a menu sorted by type also makes more sense in that regard.

[xvitxr]

Really really thank you guys for supporting Linux as a platform, this really means a lot to the community. You guys have been doing some amazing job at this game, and I just want to thank you guys for everything you've been working on so far! <3

[Twisted_Code]

I can practically hear the artillery shell whizzing overhead when you talk about Client-Side Decoration. Admittedly I have very limited experience with Linux (so take everything I am about to say with a grain of salt please!), but it seems pretty strange to have to add your own decorations if every other app is also having decorations and everyone in the ecosystem pretty much agrees on having a title bar... and the server just doesn't implement a universal option to take the load off clients. Even though libdecor exists, that just kind of makes dependency hell worse, even if by inaction. At the absolute bare minimum, it means you need another dependency in your build scripts, and so does everyone else that wants this otherwiseseemingly-trivial feature.
I've been considering switching to Linux recently, or at least setting up my computer so that it can dual boot and I can at least begin to phase Microshit out of my life. Based on a KDE vs. GNOME article I read on itsfoss, I don't really understand why GNOME is so popular in the first place. It sounds like it's main advantage is a cleaner interface and a unique workflow, but KDE offers more room for customization, a bigger arsenal of apps, a very busy contributor community... all of this and your complaint coupled with the fact I'm coming from Windows and would prefer having a taskbar and stuff, I think the choice for me would be clear even if it's not so one-sided for someone else.

[CommunistCatgirl]

I am fully aware that SSD support is optional in wayland, but, hypothetically, the spec could be updated to make it mandatory in a new version, and, in time, applications could start assuming that it will exist and not bother providing any fallback, just as with any version update of anything ever.

I mean maybe, but there need to be a way to clearly communicate this to the community and some kind of new protocol rules for how to handle old compositors. What happens when you run a new app on an old compositor? Will there be a hard cuttoff date when clients should say "this compositor is too old, I refuse to run"? That's arguably even more awful than literally any other platform and than what's happening right now. Also how do we justify this becoming mandatory for some reason over other things that are arguably way more important. For example the explicit sync protocol was created because the way wayland works is essentially incompatible with parts of the mandatory vulkan spec, that should probably be higher on the list than a plainly colored rectangle. I've already stated I think this discussion is more hate and misunderstanding. Like sure "theoretically" it could be done but unless someone has some good bulletproof ideas for how to do it while keeping everything working together then it won't be done due to the aforementioned issues.

Indeed if you're using a toolkit you'd hopefully get CSD automatically, but it still sucks for developers of said toolkits and anyone who wants to use wayland directly in general. I think it's extremely poor design to wave away the issue with "just use an existing toolkit or library", essentially making the wayland protocol less approachable than it could be. And toolkits should still significantly outnumber compositors.

If you are either a toolkit dev or a rawing wayland the least of your issues is a window decoration. We are wholly exaggerating the amount of effort of drawing a rectangle with 3 buttons compared to the complexity of everything else involved with getting a complex piece of software working. GUI toolkits need to deal with problems whose complexity you and I cannot fathom. A toolkit will also do need to support CSD anyway for the apps that use it, so... what's the extra work they have to do actually? The answer is nothing. And for a cross platform software already using libraries to aid in their cross-platform support like factorio (and tbh a lot of other games) using SDL, the extra work is also basically nothing beyond getting the build system to link libdecor. IIRC factorio uses a weird build system I had never heard of before or since but with meson adding libdecor is extremely easy.

Yes, SSD won't make decorations consistent with their respective applications, but CSD by no means will guarantee that either; namely, anything using libdecor (i.e. a bunch of things) will not be consistent with the application (i.e. gets zero benefit from having to do CSD) and won't be consistent with other apps either (i.e. a thing that SSD could improve; not only colors/icons, but things like guaranteeing the close button covering the top-left pixel and remaining usable while the application is lagging; and SSD doesn't necessarily need to not fit in with the application, i.e. a compositor could, if it so chooses to, infer the decoration colors from the app).

I have no idea what your point here even is. SSD can't make decorations consistent with the app. CSD can look okay with minimal changes to the decorations since the developer knows the app. Yes CSD doesn't guarantee it but... neither does SSD? In fact no computer code can guarantee design that looks nice, that's always a messy, inconsistent human element. And no compositor could automatically guess how to make it look good. There unfortunately isn't some magic spell that we can use here, design is extremely fucking complicated and once again has nuances neither you or I can comprehend. I only know enough to know that I don't know anything. With CSD you have the opportunity to make it match, with SSD it never will. Libdecor could be extended to make it easy to control the decoration contents if it isn't possible already. SSD will just never be able to do that. The guarantee of windows being responsive is an interesting one maybe, but for clients that use CSD it's moot so I'm not sure how it's an argument for something like SSD being required. As for the other points I'm struggling to understand what you mean.

Again, indeed, if an app has the resources to make custom linux CSD which fit in with the app, CSD can have good benefits (and I think CSD should be an option regardless of whether SSD support is required!), but most are just not gonna bother and end up with the worst of both worlds *and* require a library to achieve said worst of both worlds.

I think the assumptions here are very skewed towards apps and developers that don't exist. Like if your app is mostly used windowed then as a developer you will care about how your decoration looks. You are also most likely using a toolkit already and you have considered using or are already using header bars which is more than just a window decoration which needs CSD anyway. If it's a mostly fullscreen app (a game, most likely using SDL or a game engine anyway, if you are doing raw calls to everything then adding a single dep or rolling it on your own should be trivial for you) then a simple decoration will do.

[CommunistCatgirl]

I can practically hear the artillery shell whizzing overhead when you talk about Client-Side Decoration. Admittedly I have very limited experience with Linux (so take everything I am about to say with a grain of salt please!), but it seems pretty strange to have to add your own decorations if every other app is also having decorations and everyone in the ecosystem pretty much agrees on having a title bar... and the server just doesn't implement a universal option to take the load off clients. Even though libdecor exists, that just kind of makes dependency hell worse, even if by inaction. At the absolute bare minimum, it means you need another dependency in your build scripts, and so does everyone else that wants this otherwiseseemingly-trivial feature.
I've been considering switching to Linux recently, or at least setting up my computer so that it can dual boot and I can at least begin to phase Microshit out of my life. Based on a KDE vs. GNOME article I read on itsfoss, I don't really understand why GNOME is so popular in the first place. It sounds like it's main advantage is a cleaner interface and a unique workflow, but KDE offers more room for customization, a bigger arsenal of apps, a very busy contributor community... all of this and your complaint coupled with the fact I'm coming from Windows and would prefer having a taskbar and stuff, I think the choice for me would be clear even if it's not so one-sided for someone else.

The problem is not whether or not everyone agrees on having a title bar, the issue is what is the title bar. In fact on all platforms "header bars" (however you wanna call them) that combine the application header with the close buttons and different app actions and graphics on the window decoration are being favoured over plain title bars that take up a whole row of your screen doing almost nothing. I will point you to the previous discussion for why doing it client-side is not such a big load and why server-side is not something that can/should be done.

As for the dependency hell, wayland is still miles ahead of X11. As I said above if you're using a toolkit then that toolkit is already doing way more complex things, pulling way more complex libraries and all that work a toolkit does anyway can be used to handle a CSD. For a trivial or minimal client then libdecor is needed, but that client is probably already pulling a lot of deps for doing all sorts of also trivial-on-their-own things. I'm not saying yet another dep is awesome, but wayland is still a really mininal protocol with 2 (to 4, depending on how you count them) core deps that everything needs regardless of how complex your app gets and for most application it's 0 extra deps beyond your toolkit while for some more extremes cases when it comes to windowing (games) it's like 1 extra with a few transitives.

Happy you are looking to linux as an alternative, I wish you smooth sailing. Unfortunately the article you quoted has several major issues (and it's not the exception by any means, most things you'll see online border on misinformation). I will try to be brief: The article is from 2023 but it showcases a 2-year-old release of GNOME for the time it was written. As for the app ecosystem, look at the flathub home page and notice how many are libadwaita (gnome's toolkit library) apps, it's hard to compare but it's not a clear win on either side imho. As for the customisation yes it's true, you can change a lot on KDE, whether or not you'd want to or can is another discussion. Fun history lesson: GNOME used to also go hard on customisation until they realised too many settings makes it impossible for them to maintain their software and keep it free of bugs. In the KDE community there the concept of settings you shouldn't change because they will cause instability. Personally I don't think that's a great experience but if you want to mess with it to find something you like I think you should do it. As for resource usage the test done is ridiculous. Not even using the same distro is already adding too many variables to measure anything correctly. Also more RAM usage doesn't mean it runs slower (in fact there are often tradeoffs where you pick one or the other). Ironically however on linux desktops the biggest ram user is packagekit and not the desktop for reasons I won't get into, fortunately that's on its way out. Now, the reasons distros pick GNOME over KDE are many and the article doesn't bother mentioning range from accessibilty to the fact that gnome syncs their release cycle with distros to make it easy for them.

If you want a windows-like interface both KDE and cinnamon will give that to you and distros like fedora offer variants for all of the major desktops including those, so I recommend giving them a try try it and seeinf what sticks. Wish you luck on your linux adventures.

[madpinger]

haha, Yeah. The whole X11 to Wayland thing is a nightmare for many. I greatly appreciate the effort and continued support. Factorio is one of the shining examples I oft push forward to promote linux gaming !

[NoCompilerHere]

I was having resizing issues with my game engine on wl-roots as well. The key to solving the problem for me was to keep recreating the swapchain until it was fixed (detected with VK_SUBOPTIMAL_KHR, tho VK_ERROR_OUT_OF_DATE_KHR may be useful too?).

[dzaima]

If you are either a toolkit dev or a rawing wayland the least of your issues is a window decoration. We are wholly exaggerating the amount of effort of drawing a rectangle with 3 buttons compared to the complexity of everything else involved with getting a complex piece of software working. GUI toolkits need to deal with problems whose complexity you and I cannot fathom.

I do have second-hand knowledge that decorations are, in fact, a real annoyance - at https://github.com/HumbleUI/JWM/pull/278 decorations were a pretty prolonged issue - that started out using libdecor but switched away from it for reasons I don't know (I do recall that libdecor was being problematic, but I thought we fixed that?). And this library is only for window management, so "drawing a rectangle and some icons" requires messing with rendering graphics in a library that otherwise does not need to. That PR is a total of 4427 inserted lines as per git diff --stat, and wayland/cc/Decoration.{cc,hh} total to 556 lines - 12% of the total diff.

I have no idea what your point here even is. SSD can't make decorations consistent with the app. CSD can look okay with minimal changes to the decorations since the developer knows the app. Yes CSD doesn't guarantee it but... neither does SSD?

You're completely ignoring the part of matching the desktop environment or other apps again. Yes, if the app bothers, CSD can have a chance to match with the app, but, again, most will not (if the app cares about linux there may be a chance, but most don't do even that, and I doubt many libraries/toolkits would even expose options to change linux-specific decoration styles). And, in that scenario, between CSD (matches neither this app nor other apps) and SSD (doesn't match this app but might match other apps) SSD is still unquestionably the better choice. (but, to repeat myself, this does not mean that all apps should be forced to use SSD - CSD should still be an option; it's just that SSD makes sense as an option too).

(another random benefit of consistent decorations across apps - I can, on my X11 system (linux mint cinnamon so I don't even have a (stable) wayland option) put two apps side-by-side, and can, from the title text color alone, consistently determine which is focused, as the colors for focused and unfocused are the same on both. Or, if not title color, then whether the close icon is saturated red. Whereas with prominent inconsistent CSD your options are either to learn each specific apps' colors or like look at the taskbar if you even have one visible)

Like if your app is mostly used windowed then as a developer you will care about how your decoration looks.

..not really? If the app is cross-platform, most devs would just instantly give up on any attempt of getting good looks of platform-specific things, they have better things to do. Many apps already have much more significant consistency issues already anyway.

[dr_vm]

First of all: Thank you very much for the excellent Linux support !

Not sure if it was already mentioned or considered, but running the async-save fork with an adjusted oom score (see proc(5) oom_score_adj) should prevent at least some memory related crashes. By sacrificing (=eg. adj +500) the fork, the main game is more likely to survive an out-of-memory situation.
All it needs to do is detecting whenever the async-save fork has successfully finished, is still saving or is "gone" - either being killed by the oom reaper or other bad things happened to it.
In the latter case, main game should/could run a classic, synchronous save of (the now current) game state instead and "automagically" disable the async-save for the rest of the session.

[SirSmuggler]

I play Factorio on PC via Steam because I'm lazy. It's a very good thing that you support Linux though, as Microsoft doesn't need any more of a monopoly than they allready have.

[Henry Loenwind]

8 Pages? Sorry, not reading all of them to see if it has been mentioned.

For the production statistics, I'd love to have the item lists for production and consumption combined into one list. I find it a pain to search through the list for the items I want to see anyway, and having to do it twice is just painful.

For the energy statistics, I like to have a "focus" mode where I can select one of the three graphs and get it in (almost) the full width of the window (a 4:1:1-split would be fine, too). Maybe even with a bigger height. It's always annoying when the information you want to see is shown in a postage-stamp-sized area of the UI dwarfed by all the stuff that doesn't interest you at that moment.

Just like here on the forum while writing a reply. The text box to type my text in is 95% of my focus, yet it uses less than 5% of my screen area. At least on this forum, it auto-increases in size when needed...

[Rammix]

I play Factorio on PC via Steam because I'm lazy. It's a very good thing that you support Linux though, as Microsoft doesn't need any more of a monopoly than they allready have.

Linux and MacOS are "PC" too. Just saying.
Even if we're talking specifically about "IBM PC", desktop Linux is still a PC platform. IDK why some services (like Steam, for instance) write Linux and PC as if they were separate entities. ¯\_(ツ)_/¯

[catpig]

Just an unimportant off topic question.
Is (or will be) the multi-pointer functionality (2 or more active mouse cursors) supported in Factorio 2.0? Could be fun playing the game with two mice simultaneously.

I am curious... are there any computer games that support this? I've never actually played one (or heard of one) that did.

Iirc the original settlers 2 supported this. Haven't tested whether that works on modern systems and/or in the remaster/remake.

[TheBuzzSaw]

Just an unimportant off topic question.
Is (or will be) the multi-pointer functionality (2 or more active mouse cursors) supported in Factorio 2.0? Could be fun playing the game with two mice simultaneously.

I am curious... are there any computer games that support this? I've never actually played one (or heard of one) that did.

World of Goo supports multiple mice in Linux. It's honestly amazing.

[the80srobot]

Hi! About the `fork`-related crashes on Linux and Mac. So, I'm an occasional Linux kernel dev and I have some unfortunate news: there is actually not a lot that's guaranteed to work after fork returns in the child process. It's been a while since I've had to do this, but IIRC it's the same set of things you would be allowed to do from a signal handler (so not a lot).

There are many edge cases, but the basic reason is that a lot of code in libc has internal state (e.g. printf, anything working with FILE*...) that could be left inconsistent when the executing thread gets interrupted. We sometimes say such code isn't reentrant.

For example, imagine you have a non-reentrant file operation:

1. Grab a lock
2. Do some I/O
3. Release the lock

You get a signal between 2 and 3. If the signal handler tries to call the code at 1. again, the thread will deadlock. And unlike multithreaded code, another core will not wake up and take over, because you are not suspended (and probably can't be, because threads in an interrupt handler don't get preempted).

This might seem like a trivial property, but actually most code is not reentrant, including malloc, a lot of IO and printf.

OK, what does this have to do with fork? Well, for one thing, the parent process had other threads that could have been in a non-reentrant function. As soon as you return from fork, those threads are gone. If, e.g. one of them was holding a mutex, that mutex will never get released.

There are some very careful ways you can use fork correctly, but I think the most common advice I've heard is that the only safe thing to do in the child process is calling execve() or exit().

I realize I'm raining on your parade - it's such a clever design!

I am typing this at 1:30 AM, so maybe there's something I'm not thinking of. Some things you could explore:

Option A: I think you only need the fork to get a CoW copy of the address space, right? Maybe you could do this:

1. mmap yourself, then fcntl to remove FD_CLOEXEC
2. fork again and execve into a "async saver" process
3. You now have a file descriptor for the part of the CoW address space and your C runtime is not going to deadlock.
4. Do crazy things to read and your game from the address space snapshot
5. ? Profit ?

Option B: Maybe, possibly, you might be able to do option A, keep the maps that contain your C++ heap, then execve back into Factorio and do terrible things to get the C++ heap to be your old, CoW C++ heap, while having a clean, non-deadlock-prone runtime.

Anyway, sorry for posting a long, rambling post. I got nerdsniped, but I have to wrap it up and go to bed. Please let me know if you're interested in exploring these options, I might be able to throw together a POC for Option A.

[Twisted_Code]

I can practically hear the artillery shell whizzing overhead when you talk about Client-Side Decoration. Admittedly I have very limited experience with Linux (so take everything I am about to say with a grain of salt please!), but it seems pretty strange to have to add your own decorations if every other app is also having decorations and everyone in the ecosystem pretty much agrees on having a title bar... and the server just doesn't implement a universal option to take the load off clients. Even though libdecor exists, that just kind of makes dependency hell worse, even if by inaction. At the absolute bare minimum, it means you need another dependency in your build scripts, and so does everyone else that wants this otherwiseseemingly-trivial feature.
I've been considering switching to Linux recently, or at least setting up my computer so that it can dual boot and I can at least begin to phase Microshit out of my life. Based on a KDE vs. GNOME article I read on itsfoss, I don't really understand why GNOME is so popular in the first place. It sounds like it's main advantage is a cleaner interface and a unique workflow, but KDE offers more room for customization, a bigger arsenal of apps, a very busy contributor community... all of this and your complaint coupled with the fact I'm coming from Windows and would prefer having a taskbar and stuff, I think the choice for me would be clear even if it's not so one-sided for someone else.

The problem is not whether or not everyone agrees on having a title bar, the issue is what is the title bar. In fact on all platforms "header bars" (however you wanna call them) that combine the application header with the close buttons and different app actions and graphics on the window decoration are being favoured over plain title bars that take up a whole row of your screen doing almost nothing. I will point you to the previous discussion for why doing it client-side is not such a big load and why server-side is not something that can/should be done.

As for the dependency hell, wayland is still miles ahead of X11. As I said above if you're using a toolkit then that toolkit is already doing way more complex things, pulling way more complex libraries and all that work a toolkit does anyway can be used to handle a CSD. For a trivial or minimal client then libdecor is needed, but that client is probably already pulling a lot of deps for doing all sorts of also trivial-on-their-own things. I'm not saying yet another dep is awesome, but wayland is still a really mininal protocol with 2 (to 4, depending on how you count them) core deps that everything needs regardless of how complex your app gets and for most application it's 0 extra deps beyond your toolkit while for some more extremes cases when it comes to windowing (games) it's like 1 extra with a few transitives.

Happy you are looking to linux as an alternative, I wish you smooth sailing. Unfortunately the article you quoted has several major issues (and it's not the exception by any means, most things you'll see online border on misinformation). I will try to be brief: The article is from 2023 but it showcases a 2-year-old release of GNOME for the time it was written. As for the app ecosystem, look at the flathub home page and notice how many are libadwaita (gnome's toolkit library) apps, it's hard to compare but it's not a clear win on either side imho. As for the customisation yes it's true, you can change a lot on KDE, whether or not you'd want to or can is another discussion. Fun history lesson: GNOME used to also go hard on customisation until they realised too many settings makes it impossible for them to maintain their software and keep it free of bugs. In the KDE community there the concept of settings you shouldn't change because they will cause instability. Personally I don't think that's a great experience but if you want to mess with it to find something you like I think you should do it. As for resource usage the test done is ridiculous. Not even using the same distro is already adding too many variables to measure anything correctly. Also more RAM usage doesn't mean it runs slower (in fact there are often tradeoffs where you pick one or the other). Ironically however on linux desktops the biggest ram user is packagekit and not the desktop for reasons I won't get into, fortunately that's on its way out. Now, the reasons distros pick GNOME over KDE are many and the article doesn't bother mentioning range from accessibilty to the fact that gnome syncs their release cycle with distros to make it easy for them.

If you want a windows-like interface both KDE and cinnamon will give that to you and distros like fedora offer variants for all of the major desktops including those, so I recommend giving them a try try it and seeinf what sticks. Wish you luck on your linux adventures.

Thank you for your perspective. I will try to keep this in mind as I explore my options

[Usul]

While you are improving the stats UI, *please* add a very basic QoL feature: Remember/persist last viewed time scale accross close/open stats UI. Opening the stats UI defaults to "5 s", which I honestly believe to be the *least* useful choice. Every single time I open stats, I need to switch again to more commonly viewed scales such as "10 min" or "1 h" for example. The user's chosen item-filters get persisted, why not persist the choice of time-scale too? This would facilitate and reduce tedium while monitoring a specific part of production repeatedly in the stats UI.

Finally was implemented in 2.0.15!
viewtopic.php?f=3&t=119952

Thank you!