Yeah, I've been playing BG3 on Linux[0] for about 2 years at this point (using a Lutris "recipe" or whatever they call it). Ironically, the biggest issues have been with some of the modding tools needing specific versions of DotNet and whatnot. The game itself runs flawlessly.
[0] Arch Linux, btw, because that must be mentioned.
Actually, I have been having a specific issue with pickpocketing in BG3. On native Windows and native Linux, the client crashes if I pickpocket too quick. One time, on Linux, it even made my whole OS crash (and then some weird error BIOS error). But specifically with Wine on Linux, it does not occur. The only reason I even tried with Wine on Linux is because I wanted to try some mods unavailable otherwise. It does seem the native port has better latency, but latency in a game like this is pretty irrelevant.
I have been using Linux for nearly 30 years now, including running CS (HL1) via Wine with better performance and stability than Windows 9x on a LAN party. Good times.
Sometimes native ports don't get updates, while Windows port does. If you can then run it via Wine, you may have a more stable/less buggy experience.
Note I use both Wine and Proton. BG3 I run with Proton. But Proton is 'just' a fork with (neat) improvements which also partly got backported.
Oh, and I have to mention, I don't use Arch Linux.
Huh, I was unaware that BG3 had a native Linux release, as it's not listed on the Steam store page. Turns out that they released it only for the Steam Deck. Strange
The overhead isn't zero, but with SSDs (and filesystem caches in the gigabytes these days) it's damn near insignificant in pure terms of opening files and such.
I can generate a lot of tests amounting to assert(true). Yeah, LLM generated tests aren't quite that simplistic, but are you checking that all the tests actually make sense and test anything useful? If no, those tests are useless. If yes, I don't actually believe you.
It's the typical 10 line diff getting scrutinized to death, 1000 line diff: Instant LGTM.
> However, the best engineers I know are usually among the quickest to open an editor or debugger and use it fluently to try something out.
That's not my experience... mostly it's about first interrogating the actual problem with the customer and conditions under which it occurs. Maybe we even have appropriate logging in our production application? We usually do, because you know, we usually need to debug things that have already happened.
(If it's new/unreleased code, sure fine, let's find a debugger.)
Intel 8080 was launched in April 1974 and the development system for it, "Intellec 8 Mod 80", was available soon after that.
CP/M could be developed only after the launch of the 8080 and the delivery of the development system.
In UNIX, the environment variables were added in the Seventh Edition (1979-01), together with the Bourne shell.
I do not remember whether any other command interpreters used something equivalent with environment variables before the UNIX shell (excluding the interpreters for general-purpose programming languages, like LISP and APL, where you can run a function in REPL and that function can access global variables).
Therefore the quoted year may be a typo for 1979, when environment variables appeared in the UNIX shell, but were not available in the CP/M Console Command Processor (CCP, the predecessor of COMMAND.COM).
CP/M 1.0 was demoed to Intel in 1974, but they didn't buy it.
iCOM FDOS was the first operating system that was available to people, and it sure didn't have environment variables.
Anyway, these operating systems didn't have multiple directories. But you could use CP/M 2.x's ASSIGN command to bind a logical name to a physical name. Minicomputer operating systems had this, also IBM mainframe had JCL DD commands.
Been saying this for a while now. I work in aerospace, and I can tell you from first hand experience software engineers don't know what designing a spec is.
Aero, mechanical, and electrical engineers spend years designing a system. Design, requirements, reviews, redesign, more reviews, more requirements. Every single corner of the system is well understood before anything gets made. It's a detailed, time consuming, arduous process.
Software engineers think they can duplicate that process with a few skills and a weekend planning session with Claude Code. Because implementation is cheaper we don't have to go as hard as the mechanical and electrical folks, but to properly spec a system is still a massive amount of up front effort.
I think wmf's comment in this thread was absolutely correct and succinct, so I won't repeat, but I think it's worth noting that many (all?) of the Wayland devs were actually Xorg devs. Make of that what you will.
[0] Arch Linux, btw, because that must be mentioned.
reply