• 9 Posts
  • 820 Comments
Joined 1 year ago
cake
Cake day: June 13th, 2023

help-circle



  • I worked with a French guy in Amsterdam. His parents were Portuguese, but he was born and raised in France. As far as he was concerned, he was French.

    As I understand it, that’s a French thing specifically, not just a non-USian thing. Like, if you’re a citizen of France, you’re expected to be French and assimilate into that culture, no matter whether you’re a native Parisian, you moved there from Algeria in the '60s, or you’re from some random other place and got citizenship via the French Foreign Legion. It’s a specific sort of national ideology that’s different from the American “melting pot” one.









  • Ah, that’s different then!

    Hmm…

    From https://wiki.hyperbola.info/doku.php?id=en:manual:contrib:hyperbolabsd_faq:

    HyperbolaBSD is under a progressive migration by replacing all non GPL-compatible code. It will be replaced with new compatible code under Simplified BSD License. We do this in order to incorporate GPL code from other projects such as ReactOS, as well new code from scratch.

    It’s not clear to me that relicensing the existing code to GPL is what they’re planning on doing; it sounds more like they’re going to mix in GPL code but not change the existing files to GPL en masse after they finish harmonizing them to two-clause BSD.

    Frankly, IMO that’s too bad: I’d love to see them make the whole shebang GPLv3-or-later


    Related question: is all Linux kernel code required to be licensed GPLv2-only, or are individual contributions allowed to be GPLv2-or-later? I’d be nice to see if that project (and stuff like HURD and ReactOS) could benefit from at least some Linux contributions, even if they can’t copy it wholesale.







  • I mean, yeah, if you were trying to get a game to run using bare WINE in like <2010 or something, you were gonna be troubleshooting it for a while (and might still fail just because the functionality hadn’t actually caught up yet). By 2017, though, DirectX etc. support had improved drastically (Valve’s first attempt at SteamOS was already a few years old by then), so the main issue was figuring out the right configuration (which version of Windows to mimic, installing supporting libraries, etc.) and tools like PlayOnLinux and Lutris went a long way towards crowdsourcing and automating that.


  • In 2017? Well, that’s an interesting question. On one hand, it definitely wasn’t as easy as it is now. On the other hand, I was motivated to ditch Windows and willing to make the gaming sacrifices necessary to make that happen. The last version of Windows I used was 7, and I was determined that 10 would never touch this machine – or any computer of mine going forward, for that matter. I also was done putting up with 7, given that Microsoft was starting to backport 10’s spyware and forced-upgrade BS to it by then.

    It’s been a while, so I’m fuzzy on the details of what I was playing between 2017 and 2018 (when Proton came out). I think I just limited myself to the subset of my Steam games that had native Linux versions (e.g. TF2 and other Valve first-party games, Don’t Starve, Cities Skylines, etc.), supplemented with PlayOnLinux for Star Trek Online, which, being an MMO I was already committed to, was pretty much the only exception I made. Otherwise, my attitude became “if the developer can’t be bothered to support my OS, that’s their loss, not mine, and I don’t need their shitty Windows-only game anyway.”

    After Proton came out and I flipped that switch to “enable Steam Play for all other titles”, I think the majority of my Steam games “Just Worked” – yes, even back at that initial release – and the ones that didn’t became compatible pretty rapidly over the next couple of years. With one exception, I don’t think I’ve had trouble getting a game working since the start of the pandemic, if not earlier. At this point, I’ve softened my “I won’t buy a new game if it doesn’t natively support Linux stance” and instead simply expect every game I buy to work. And they have!

    (That one exception was Star Trek Online, which I had continued running via PlayOnLinux because (a) why mess with a working config, and (b) the Steam version of STO wants to permanently link your STO account to your Steam account, which I didn’t want to do. One day, though, they updated the launcher or something and it quit working. I eventually gave up trying to fix it in PlayOnLinux and decided to use Proton for it instead. But I still didn’t want to link my accounts, so I had to jump through these weird hoops where I installed the Steam version, but didn’t log in or play it, and instead re-imported it as a non-Steam game pointing at the executable for the Steam version and then fiddled with the compatibility settings to find a version of Proton that worked. That’s still the configuration I’m using for it to this day.)