9 ms·

A guy preserving the new history of PC games, one Linux port at a time

244 points by rcarmo 3y ago

chillbill 3y ago
Would anyone ever sign up for a fucking newsletter from the first god damn second they open a website? Why do they do this? What kind of a stupid purpose does it have other than annoying users?
- d-lisp 3y ago
  Note that if you close the modal and read the article and then reload the page, it doesn't appear anymore. Which is weird; weird to ask for a newsletter subscription when you never saw any content yet, weird that this modal doesn't exist anymore after this.
- satvikpendem 3y ago
  Yes, many non-technical people do. If it didn't work, the people who add that popup wouldn't keep doing so.
  - rendaw 3y ago
    You're assuming that everything is run by purely logical data-driven statistics-oriented leaders with accurate models and methodologies.
    - satvikpendem 3y ago
      That is what many marketers do, yes. I've worked in ads, I know how it works. If the numbers aren't there, they usually don't continue.
      - chillbill 3y ago
        https://en.m.wikipedia.org/wiki/Faulty_generalization https://en.m.wikipedia.org/wiki/Faulty_generalization
        satvikpendem 3y ago
        At what point is the faulty generalization simply...a true generalization? Just because you don't want to believe it's true doesn't mean it's not true.
        chillbill 3y ago
        [flagged]
        dang 3y ago
        Yikes, you've been breaking the site guidelines so badly that we have to ban the account—especially because we already asked you to stop. It's not ok to be abusive like this on HN, no matter how wrong someone is or you feel they are. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
      - prerok 3y ago
        That is true, but IME only if it incurs costs. In this case, however, a pop-up on your own site costs nothing. In fact, removing it incurs costs in development time, even if it's a simple line delete. So, I am 100% sure no marketer would ever push for removing it, unless end-users specifically tell them that they are not going to use the site because of the pop-up. The likelihood that they realize that on their own is next to zero because of the difficulties in retention analysis to catch this.
        satvikpendem 3y ago
        I'd say if their click through rate to the actual article (aka bouncing off the page instead of clicking the close button and continuing to read the article) is low, they'd likely remove it. At least that's how I've been able to convince certain marketers about the inefficacy of their tactics. But other things, like modals to subscribe to the newsletter that pop up after reading the content half-way, simply work too well to ever give up.
        prerok 3y ago
        Now, that is a different take. You have been able to convince them. It's not like they realized this themselves, or that they deduced something from the numbers. Again, only my experience at past employers, but in a lot of cases the developers don't get heard when making these suggestions.
  - Dylan16807 3y ago
    What does "technical" have to do with it?
    - satvikpendem 3y ago
      Technical people often complain about popups and other marketing practices, not realizing that the vast majority of people aren't technical and do not complain, much less care, about such practices. They'll click the close button on the popup and move on.
      - skywal_l 3y ago
        But technical people ofter block JS by defaut which prevent the button from closing the popup. Fortunately, reader mode on firefox solves the problem.
        satvikpendem 3y ago
        The "they" in my second sentence is about non-technical people, not technical people, I should have clarified. Regardless, the number of people who use the internet and who actively block JS by default is a fraction of 1%.
      - cgriswald 3y ago
        They definitely care. They’re just not empowered to do anything about it It’s ubiquitous and technical solutions are not available to the non-technical.
        satvikpendem 3y ago
        I can tell you from experience, they really do not care. It's not even something that crosses their minds. You can see for yourself, ask 100 non-technical people you know about stuff like ads and popups. I bet over 50% of them simply do not care. It is a technical person's bias to think they do.
        3y ago
- andalemono 3y ago
  Didn't paper mags come with subscription cards?
  - Dylan16807 3y ago
    Those don't hover over the first article you try to read.
- cookiengineer 3y ago
  Hint: Use abuse@ emails and they will stop doing this on their own :)
  - nottheengineer 3y ago
    Some context for those wondering: Those are reserved aliases for google. If you send a mail go abuse@company.com and they use google, that mail will be receiced by google (and the company if they have that set up). It's intended for reporting spam sent out by company.com email addresses. Not entirely sure how it works, but I assume sending newsletters to that causes some automatic sanctions for the company that are a massive headache to resolve.
    - rgoulter 3y ago
      https://support.google.com/a/answer/178266?hl=en https://support.google.com/a/answer/178266?hl=en This is if the domain (company.com) is managed by Google.
    - ninjin 3y ago
      No, abuse@ is not some sort of Google invention but to the best of my knowledge was an informal convention that then got formalised in RFC 2142 [1] in 1997 along with many other common mailbox names. If Google sets this up automagically for their users it is great, but they are merely continuing this long tradition. [1]: https://www.rfc-editor.org/rfc/rfc2142.txt https://www.rfc-editor.org/rfc/rfc2142.txt
  - sixstringtheory 3y ago
    TIL. There’s gotta be a browser extension for this!
- deleted 3y ago
  [deleted]
- defanor 3y ago
  Worse yet while browsing with JS off by default: the popup shows up, but cannot be closed (and does not work for subscription, either), only obscuring the page.
  - perihelions 3y ago
    Disable CSS too and it's fixed. :) "Perfection is achieved... when there is nothing left to take away"
grimgrin 3y ago
Here's the service they're offering: https://www.gamingonlinux.com/2023/09/game-porter-ethan-lee-offers-services-to-maintain-old-games-for-developers/ https://www.gamingonlinux.com/2023/09/game-porter-ethan-lee-...
tanepiper 3y ago
That modal is a bad design, along with the site name - I almost closed the page thinking it was a 404 not found.
- wiseowise 3y ago
  I actually did, until I saw page link and comments on HN discussing content.
  - anonzzzies 3y ago
    Same here.
- vk7eu 3y ago
  That modal window cannot be closed without JavaScript, rendering entire page unreadable, if not the Reader View.
  - TapamN 3y ago
    On Firefox, go to View, Page Style, No Style to make it readable without JavaScript.
  - tanepiper 3y ago
    I actually wrote about how bad the <dialog> tag is for the web and I'm sort of glad to be proven right, if by absolute annoyance https://tane.dev/2021/02/revisiting-dark-patterns-with-the-html-dialog-tag/ https://tane.dev/2021/02/revisiting-dark-patterns-with-the-h...
- qsantos 3y ago
  You can also try the Kill Sticky add-on for Firefox: https://addons.mozilla.org/fr/firefox/addon/kill-sticky/ https://addons.mozilla.org/fr/firefox/addon/kill-sticky/. It will also get rid of the annoying banner in fixed position at the top.
  - scrame 3y ago
5- 3y ago
> People think of the PC as this completely invincible platform where once you get a PC version it lives forever that's true -- thanks to the free win32 api implementation wine, x86 userspace emulators like qemu or box86, and piracy for drm-laden titles. decades from now, windows games will be runnable on then-current platforms just like you can now run them on your android or arm macos device.
- shmerl 3y ago
  Someone has to maintain Wine and all the rest. So it requires effort and isn't something simply guaranteed.
  - 5- 3y ago
    of course. please donate (money or effort) to these important preservation projects!
  - 867-5309 3y ago
    in the future, finding a compatible emulator version will be a lot easier than acquiring the original intended hardware
    - shmerl 3y ago
      It's already easier. My point is that someone has to keep the compatibility layers working on modern systems.
  - pasc1878 3y ago
    TYo keep Wine going buy the commercial version of Wine - Crossover from codewavers.com
  - amelius 3y ago
    In theory, can't an LLM be used to translate code from the original platform to the emulation environment, in such a way that there is no copyright infringement ?
pjmlp 3y ago
> Fifteen years ago, Lee said, the idea that independent games could be so successful was so new, people were not thinking 10 years ahead. Now that he’s been doing it for so long, he has a new way of thinking about it. 8 and 16 bit home computer games were what people nowadays call indie games, followed by Flash games, naturally we knew how successful they could be.
sylware 3y ago
Had several times a chat with Ethan Lee, he is perfectly aware of the technical challenges to keep game binaries working in the very close source hostile environment which is elf/linux. BTW, I think Celeste is one of the most important games he does maintain on elf/linux. One of the major choke points is ELF with its GNU extensions severely abused by glibc devs (and indirectly libstdc++ gcc devs and libgcc gcc devs). It is hell to generate elf/linux binaries with works on "old" distros from "recent" distros.
- speed_spread 3y ago
  Wouldn't using containers help with that? Stabilizing the whole environment by pinning it to a known-working distribution + version.
  - sylware 3y ago
    This is what valve is doing with collabora "pressure-vessel" at the cost of a very expensive and intrusive kernel mechanism (mount namespace), and beyond sanity complexity ELF handling: they have to "scan" the host system and depending on the GNU versions (modules/symbols) used, have to cherry pick down to the host glibc libs to import into the container (usually it is limited to the driver libs). Currently, "pressure-vessel" is not finished as there are still bugs and missing features (basically speaking, if you don't have a massive and mainstream arch or ubuntu/debian...). Have to check on it in the near future, the devs have to fix the handling of host environment variables and some host libs which are not imported (for alsa dmix and dsnoop IPCs to work as intended in the container singe games need only to care about alsa-lib API). Then to work around the toxic behavior of glibc/gcc devs, valve is building a "mitigation" of extreme cost and complexity with the help of collabora. The guilty are the glibc and gcc devs, they deserve hate, and this is righteous hate. The other mitigation is to drop the ball, and go full wine+vkd3d as a layer to protect game binaries from glibc and gcc devs SABOTAGE. But this is a gigantic shabby kludge (troubleshooting is just horrible, and not breaking anything on the long run...) ON TOP of the already kludgy and bloated glibc/gcc... valve calls its wine+vkd3d version "proton" (probably running in a "pressure-vessel", I don't use proton but a custom lean build of wine+vkd3d). Valve seems not to do that fairly (hope I am wrong): proton is wine+vkd3d with nasty additional components. At least they should backport in plain and simple C everything from proton into wine+vkd3d... but some says there are too many real windows components (actual copies) and nothing really pertinent to backport. On the good side, dx12 is said to be a simpler vulkan, hence games, if coded with a conservative usage of the windows APIs, should really work better and better. Some troubles on the video/audio codecs, but game devs should really use a LGPL ffmpeg/libdav1d statically linked into their binaries for that. Keep in mind: all that should not exist in the first place. The alternative is to be extremely competent on elf/linux and to manage to generate game binaries which will work using only the core video game components, and that even on "older" distros... namely what Ethan Lee is doing, because do not expect game devs to know how to do that, it is a technical abomination ("pinning" can become quickly very hard, and it worsen if the game is using c++): game binaries naively generated on "recent" (for instance glibc 2.34) distros (what "normal" game devs do) won't run on "older" (for instance glibc 2.33) distros. Allready got at least a game and demo in this case on steam.
ShamelessC 3y ago
Strange article ignores the elephant in the room - the general success of Proton. Native Linux gaming is obviously ideal, but I suspect that if Valve couldn’t figure it out then it’s unlikely to become the status quo.
- mariusor 3y ago
  I think Lee is one of the biggest critics of Proton, and Valve embracing it as the default way to deploy games on Linux. From Valve's point of view makes complete sense, dedicate resources to a single point of development that improves how their whole catalogue runs on Linux, as opposed to paying porting companies/individuals - like Lee - for each game to be ported to a native Linux version. It also makes complete sense that Lee (and Ryan C. Gordon - icculus) to be against a platform that makes their skills irrelevant[1] and actively cuts their contracting opportunities. Therefore a promotional piece for these skills might be silent on an otherwise relevant topic. [1] and also theoretically provides worse performance and compatibility.
- pjmlp 3y ago
  Just like with OS/2, it makes Linux irrelevant for game studios. Not even studios targeting Android care, and it would be quite easy, given that ISO C11, ISO C++17, OpenGL ES, Vulkan, OpenSL and OpenMAX, all exist on GNU/Linux, and most middleware engines as well.
DonHopkins 3y ago
I wrote this up about relicensing the Unix port of SimCity that I did for DUX Software as free open source software under GPL3 for the OLPC (which runs Linux): "It's a good idea not to just keep a copy of the source code stashed away somewhere, but also any contracts relating to the rights to the code." https://donhopkins.com/home/micropolis/dux-maxis-contract.txt https://donhopkins.com/home/micropolis/dux-maxis-contract.tx... https://donhopkins.com/home/micropolis/dux-don-hopkins-contract.txt https://donhopkins.com/home/micropolis/dux-don-hopkins-contr... https://donhopkins.com/home/micropolis/olpc-ea-contract.pdf https://donhopkins.com/home/micropolis/olpc-ea-contract.pdf https://news.ycombinator.com/item?id=13693675 https://news.ycombinator.com/item?id=13693675 DonHopkins on Feb 21, 2017 | parent | context | favorite | on: Development content accidentally shipped on a DOS ... It's a good idea not to just keep a copy of the source code stashed away somewhere, but also any contracts relating to the rights to the code. In the early 90's, DUX Software licensed the rights to port SimCity to Unix from Maxis. Then DUX made a contract with me to do the work. I kept a copy of my contract with DUX, the original floppies they gave me with the original PC and Mac source code, as well as versions of the source code I ported to Unix. Years later I got a job working for Maxis on The Sims. Before we shipped it, EA bought Maxis, so a lot of people were let go, projects were canceled, physical and digital files were shuffled around, and institutional knowledge was lost. After we shipped The Sims but just before I left EA, on a fluke, I asked a Maxis old-timer if he had any idea if the contract between Maxis and DUX for SimCity still existed, and where it might be. As you would expect, it was in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of the Leopard." ;( So I waited late into the night for the leopard to fall asleep, made a photocopy of it, then returned the original to its hiding place. ;) Several years later, John Gilmore suggested we persuade EA to relicense the SimCity source code under GPLv3, so it could be shipped with the OLPC. Of course nobody in EA Management knew where the source code was or if it even still existed, but fortunately I still had my copy. And of course nobody at EA Legal even knew if EA owned the rights to the changes I'd made (Maxis had gotten into some pretty terrible SimCity licensing contracts in the past). But fortunately I'd kept a copy of the contract between myself and DUX, and the contract between DUX and Maxis, proving its provenance, which clearly stated that DUX's rights expired after 10 years, after which the rights to all the modifications I made went back to Maxis (and thus were inherited by EA). Once all that was cleared up, the most important factor was that EA deputized someone on the inside to shepherd the project through the various stages of approval, relicensing, development and QA. Otherwise it would have died on the vine, since everybody in a big company, no matter how well intentioned, is always 500% busy doing their own stuff and can't be distracted by something that doesn't affect the bottom line. It finally made it through both EA Legal and QA, and we released the SimCity source code and binary for the OLPC under GPLv3! https://github.com/SimHacker/micropolis/tree/master/micropolis-activity https://github.com/SimHacker/micropolis/tree/master/micropol...
5- 3y ago
to echo some other points in this thread -- i used to be very much in favour of linux ports / recreations, actively supporting them with my wallet. but even without switching away from x86, the linux userland churn (64bit, and lately and even largely, wayland) is too much. windows games still work. (wayland driver for wine is actively being merged into the upstream at the moment)
- Topgamer7 3y ago
  There is a Wayland branch on the collabora gitlab where devs first started developing Wayland support for those who don't want to wait and can build from source. It's going to be fairly different from the wine mainland after all the reviewing. But for those who don't want to wait a few months for that review process it works pretty flawlessly from what I saw.
TheMode 3y ago
Software maintenance shouldn't exist. Instead of fighting the source code to map the current trendy environment, we should compile our programs to easily interpretable formats that does not contain any environment specific code and therefore only contain logic specific to the given software. So instead of having a binary that contain some syscall to access a key state, provide it the function on startup (or the key state value directly if programs become stateless functions) As for the simple format, this is IMO the only way to guarantee accessibility as the alternative is having people constantly working on porting software over preferably with source access.
- AshamedCaptain 3y ago
  This is precisely the wrong solution. If anything, the CPU bytecode is one of the most stable things, so switching to some "interpretable format" is not going to help much. It is the total carelesness of literally everyone else in the entire stack which is the problem. If developers considered the inability to run a 30 year old game/software in the most recent release of "libwhatever" as a critical release blocker bug, then this problem would not exist. But obviously, this is not a popular solution. And currently we rather have the opposite situation, where open source projects dump compatibility as the default (e.g. Linux sunsetting a.out support), and only preserve compatibility in the comparatively rare case that there is enough developer mass.
  - TheMode 3y ago
    ISAs aren't stable. Can you guarantee me that programs will be compiled for x86 in 20y? What instructions will they output to access the environment? Linux, Windows, MacOS? Will any of these even remain in 20y? No standard last forever, your bytecode will ultimately deprecate and this is not a "developers should stop being lazy" situation. Why do projects dump compatibility? Because this is extra work. And no project can receive indefinite support. Simple formats do not depend on maintenance.
sylware 3y ago
I am going to post here what seems to be the two least shabby recipes (Ethan Lee is aware of them) to generate elf/linux binaries which will run on "old" and "recent" distros. Then you will understand why normal game devs are not welcome on elf/linux, thx to the very nice and video game caring glibc and gcc devs (irony): First recipe: You must not link in the glibc "startup" runtime objects, aka you must not have main(): your executable must be a pure ELF64 binary, only the "_start" ELF entry point and the ELF ABI ("_start" is basically a main() anyway). Careful: all glibc runtime services which require those "startup" runtime objects are gone (you need to be able to find out which ones... good luck browsing glibc code...). Because those glibc "startup" runtime objects often require the same version or above glibc runtime being around (it is very vicious, look at glibc 2.33->2.34 with the new version of the libc_startup symbol... delicious). It means your build script on elf/linux must have fined grained compilation/linking (don't use the gcc compiler driver unless to discover static libgcc and static libstdc++ filesystem location... if you don't need to fork them). All host system dependencies must be libdl (dlopen/dlsym/dlclose), yes even the libc, memcpy, errno, etc. Of course you will have to use the static libgcc and static libstdc++ (if c++ is used). Namely if your game binaries are pulling code paths from libgcc and libstdc++ which requires glibc services, you have to fork the libgcc and libstdc++ from the gcc you use in order to properly "libdl-ized" those code paths (readelf command will tell you that while you have a look at the undefined dynamic symbols... and their required version). Then, you have the abomination of the ELF static flag: many glibc libraries have this flag, namely those libraries must be "statically loaded", namely have a ELF dynamic DT_NEED entry. You will find a ELF dynamic DT_NEED entry for libdl since you use (dlopen/dlsym/dlclose), and probably libpthread/libm(yes...!!!)/etc. Use the binutils readelf command to know if a library has the ELF static flag and must have such an entry (but you must still libdl it and its symbols to work around GNU symbol versioning issues!!). Some TLS code expect some TLS storage to be allocated and inited at executable startup, namely "static". Of course, all distributed binaries must follow those guidelines... even from third party. You want to expect normal game devs to be able to do that? ABSURD 2nd recipe: you get your hands on the most recent gcc, and the oldest glibc you want to support (~10years, more?). Compile such glibc, then this gcc to use only this very glibc (good luck configuring that cleanly). You can use main() and directly glibc services here, but still, you must libdl everything from the video game core libs (you need the headers only). Expecting that to go smoothly is just unreasonable, it will probably be a nightmare. All your distributed binaries must be built using this gcc and glibc. Expecting normal game devs to do that? GROTESQUE Both recipes must not generate binaries with the latest ELF relative relocations. The video game core libs on elf/linux are: wayland(static code in binaries)/libxkbcommon fallback-to-> x11/libxkbcommon-x11 (don't use libX11, only xcb libs). vulkan fallback-to-> GL fallback-to->CPU, be very conservative with shaders, VERY. libasound: alsa-lib, the software mixer is hidden behind the API, as it could be pulseaudio1/pulseaudio2(pipewire/wireplumber)/dmix/dsnoop/jack/whatever, have a ffmpeg resampling library ready if your audio formats are weird, or the user microphone audio format is weird. The trick: make user configurable the "speaker configuration" (5.1/7.1/headphones/stereo/etc), but with a automatic fallback to stereo if unable to open the device (all software mixers should support stereo mixing). joypad: linux /dev/input/eventXX files, check write access if you want to configure the rumbles. You can implement dynamic detection with linux inotify there (usually overkill though).

244 points by rcarmo 3y ago

Would anyone ever sign up for a fucking newsletter from the first god damn second they open a website? Why do they do this? What kind of a stupid purpose does it have other than annoying users?

d-lisp 3y ago
Note that if you close the modal and read the article and then reload the page, it doesn't appear anymore. Which is weird; weird to ask for a newsletter subscription when you never saw any content yet, weird that this modal doesn't exist anymore after this.
satvikpendem 3y ago
Yes, many non-technical people do. If it didn't work, the people who add that popup wouldn't keep doing so.
- rendaw 3y ago
  You're assuming that everything is run by purely logical data-driven statistics-oriented leaders with accurate models and methodologies.
  - satvikpendem 3y ago
    That is what many marketers do, yes. I've worked in ads, I know how it works. If the numbers aren't there, they usually don't continue.
    - chillbill 3y ago
      https://en.m.wikipedia.org/wiki/Faulty_generalization https://en.m.wikipedia.org/wiki/Faulty_generalization
      - satvikpendem 3y ago
        At what point is the faulty generalization simply...a true generalization? Just because you don't want to believe it's true doesn't mean it's not true.
        chillbill 3y ago
        [flagged]
        dang 3y ago
        Yikes, you've been breaking the site guidelines so badly that we have to ban the account—especially because we already asked you to stop. It's not ok to be abusive like this on HN, no matter how wrong someone is or you feel they are. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
    - prerok 3y ago
      That is true, but IME only if it incurs costs. In this case, however, a pop-up on your own site costs nothing. In fact, removing it incurs costs in development time, even if it's a simple line delete. So, I am 100% sure no marketer would ever push for removing it, unless end-users specifically tell them that they are not going to use the site because of the pop-up. The likelihood that they realize that on their own is next to zero because of the difficulties in retention analysis to catch this.
      - satvikpendem 3y ago
        I'd say if their click through rate to the actual article (aka bouncing off the page instead of clicking the close button and continuing to read the article) is low, they'd likely remove it. At least that's how I've been able to convince certain marketers about the inefficacy of their tactics. But other things, like modals to subscribe to the newsletter that pop up after reading the content half-way, simply work too well to ever give up.
        prerok 3y ago
        Now, that is a different take. You have been able to convince them. It's not like they realized this themselves, or that they deduced something from the numbers. Again, only my experience at past employers, but in a lot of cases the developers don't get heard when making these suggestions.
- Dylan16807 3y ago
  What does "technical" have to do with it?
  - satvikpendem 3y ago
    Technical people often complain about popups and other marketing practices, not realizing that the vast majority of people aren't technical and do not complain, much less care, about such practices. They'll click the close button on the popup and move on.
    - skywal_l 3y ago
      But technical people ofter block JS by defaut which prevent the button from closing the popup. Fortunately, reader mode on firefox solves the problem.
      - satvikpendem 3y ago
        The "they" in my second sentence is about non-technical people, not technical people, I should have clarified. Regardless, the number of people who use the internet and who actively block JS by default is a fraction of 1%.
    - cgriswald 3y ago
      They definitely care. They’re just not empowered to do anything about it It’s ubiquitous and technical solutions are not available to the non-technical.
      - satvikpendem 3y ago
        I can tell you from experience, they really do not care. It's not even something that crosses their minds. You can see for yourself, ask 100 non-technical people you know about stuff like ads and popups. I bet over 50% of them simply do not care. It is a technical person's bias to think they do.
        3y ago
andalemono 3y ago
Didn't paper mags come with subscription cards?
- Dylan16807 3y ago
  Those don't hover over the first article you try to read.
cookiengineer 3y ago
Hint: Use abuse@ emails and they will stop doing this on their own :)
- nottheengineer 3y ago
  Some context for those wondering: Those are reserved aliases for google. If you send a mail go abuse@company.com and they use google, that mail will be receiced by google (and the company if they have that set up). It's intended for reporting spam sent out by company.com email addresses. Not entirely sure how it works, but I assume sending newsletters to that causes some automatic sanctions for the company that are a massive headache to resolve.
  - rgoulter 3y ago
    https://support.google.com/a/answer/178266?hl=en https://support.google.com/a/answer/178266?hl=en This is if the domain (company.com) is managed by Google.
  - ninjin 3y ago
    No, abuse@ is not some sort of Google invention but to the best of my knowledge was an informal convention that then got formalised in RFC 2142 [1] in 1997 along with many other common mailbox names. If Google sets this up automagically for their users it is great, but they are merely continuing this long tradition. [1]: https://www.rfc-editor.org/rfc/rfc2142.txt https://www.rfc-editor.org/rfc/rfc2142.txt
- sixstringtheory 3y ago
  TIL. There’s gotta be a browser extension for this!
deleted 3y ago
[deleted]
defanor 3y ago
Worse yet while browsing with JS off by default: the popup shows up, but cannot be closed (and does not work for subscription, either), only obscuring the page.
- perihelions 3y ago
  Disable CSS too and it's fixed. :) "Perfection is achieved... when there is nothing left to take away"

grimgrin 3y ago

Here's the service they're offering: https://www.gamingonlinux.com/2023/09/game-porter-ethan-lee-offers-services-to-maintain-old-games-for-developers/ https://www.gamingonlinux.com/2023/09/game-porter-ethan-lee-...

tanepiper 3y ago

That modal is a bad design, along with the site name - I almost closed the page thinking it was a 404 not found.

wiseowise 3y ago
I actually did, until I saw page link and comments on HN discussing content.
- anonzzzies 3y ago
  Same here.
vk7eu 3y ago
That modal window cannot be closed without JavaScript, rendering entire page unreadable, if not the Reader View.
- TapamN 3y ago
  On Firefox, go to View, Page Style, No Style to make it readable without JavaScript.
- tanepiper 3y ago
  I actually wrote about how bad the <dialog> tag is for the web and I'm sort of glad to be proven right, if by absolute annoyance https://tane.dev/2021/02/revisiting-dark-patterns-with-the-html-dialog-tag/ https://tane.dev/2021/02/revisiting-dark-patterns-with-the-h...
qsantos 3y ago
You can also try the Kill Sticky add-on for Firefox: https://addons.mozilla.org/fr/firefox/addon/kill-sticky/ https://addons.mozilla.org/fr/firefox/addon/kill-sticky/. It will also get rid of the annoying banner in fixed position at the top.
- scrame 3y ago

5- 3y ago

> People think of the PC as this completely invincible platform where once you get a PC version it lives forever that's true -- thanks to the free win32 api implementation wine, x86 userspace emulators like qemu or box86, and piracy for drm-laden titles. decades from now, windows games will be runnable on then-current platforms just like you can now run them on your android or arm macos device.

shmerl 3y ago
Someone has to maintain Wine and all the rest. So it requires effort and isn't something simply guaranteed.
- 5- 3y ago
  of course. please donate (money or effort) to these important preservation projects!
- 867-5309 3y ago
  in the future, finding a compatible emulator version will be a lot easier than acquiring the original intended hardware
  - shmerl 3y ago
    It's already easier. My point is that someone has to keep the compatibility layers working on modern systems.
- pasc1878 3y ago
  TYo keep Wine going buy the commercial version of Wine - Crossover from codewavers.com
- amelius 3y ago
  In theory, can't an LLM be used to translate code from the original platform to the emulation environment, in such a way that there is no copyright infringement ?

pjmlp 3y ago

> Fifteen years ago, Lee said, the idea that independent games could be so successful was so new, people were not thinking 10 years ahead. Now that he’s been doing it for so long, he has a new way of thinking about it. 8 and 16 bit home computer games were what people nowadays call indie games, followed by Flash games, naturally we knew how successful they could be.

sylware 3y ago

Had several times a chat with Ethan Lee, he is perfectly aware of the technical challenges to keep game binaries working in the very close source hostile environment which is elf/linux. BTW, I think Celeste is one of the most important games he does maintain on elf/linux. One of the major choke points is ELF with its GNU extensions severely abused by glibc devs (and indirectly libstdc++ gcc devs and libgcc gcc devs). It is hell to generate elf/linux binaries with works on "old" distros from "recent" distros.

speed_spread 3y ago
Wouldn't using containers help with that? Stabilizing the whole environment by pinning it to a known-working distribution + version.
- sylware 3y ago
  This is what valve is doing with collabora "pressure-vessel" at the cost of a very expensive and intrusive kernel mechanism (mount namespace), and beyond sanity complexity ELF handling: they have to "scan" the host system and depending on the GNU versions (modules/symbols) used, have to cherry pick down to the host glibc libs to import into the container (usually it is limited to the driver libs). Currently, "pressure-vessel" is not finished as there are still bugs and missing features (basically speaking, if you don't have a massive and mainstream arch or ubuntu/debian...). Have to check on it in the near future, the devs have to fix the handling of host environment variables and some host libs which are not imported (for alsa dmix and dsnoop IPCs to work as intended in the container singe games need only to care about alsa-lib API). Then to work around the toxic behavior of glibc/gcc devs, valve is building a "mitigation" of extreme cost and complexity with the help of collabora. The guilty are the glibc and gcc devs, they deserve hate, and this is righteous hate. The other mitigation is to drop the ball, and go full wine+vkd3d as a layer to protect game binaries from glibc and gcc devs SABOTAGE. But this is a gigantic shabby kludge (troubleshooting is just horrible, and not breaking anything on the long run...) ON TOP of the already kludgy and bloated glibc/gcc... valve calls its wine+vkd3d version "proton" (probably running in a "pressure-vessel", I don't use proton but a custom lean build of wine+vkd3d). Valve seems not to do that fairly (hope I am wrong): proton is wine+vkd3d with nasty additional components. At least they should backport in plain and simple C everything from proton into wine+vkd3d... but some says there are too many real windows components (actual copies) and nothing really pertinent to backport. On the good side, dx12 is said to be a simpler vulkan, hence games, if coded with a conservative usage of the windows APIs, should really work better and better. Some troubles on the video/audio codecs, but game devs should really use a LGPL ffmpeg/libdav1d statically linked into their binaries for that. Keep in mind: all that should not exist in the first place. The alternative is to be extremely competent on elf/linux and to manage to generate game binaries which will work using only the core video game components, and that even on "older" distros... namely what Ethan Lee is doing, because do not expect game devs to know how to do that, it is a technical abomination ("pinning" can become quickly very hard, and it worsen if the game is using c++): game binaries naively generated on "recent" (for instance glibc 2.34) distros (what "normal" game devs do) won't run on "older" (for instance glibc 2.33) distros. Allready got at least a game and demo in this case on steam.

ShamelessC 3y ago

Strange article ignores the elephant in the room - the general success of Proton. Native Linux gaming is obviously ideal, but I suspect that if Valve couldn’t figure it out then it’s unlikely to become the status quo.

mariusor 3y ago
I think Lee is one of the biggest critics of Proton, and Valve embracing it as the default way to deploy games on Linux. From Valve's point of view makes complete sense, dedicate resources to a single point of development that improves how their whole catalogue runs on Linux, as opposed to paying porting companies/individuals - like Lee - for each game to be ported to a native Linux version. It also makes complete sense that Lee (and Ryan C. Gordon - icculus) to be against a platform that makes their skills irrelevant[1] and actively cuts their contracting opportunities. Therefore a promotional piece for these skills might be silent on an otherwise relevant topic. [1] and also theoretically provides worse performance and compatibility.
pjmlp 3y ago
Just like with OS/2, it makes Linux irrelevant for game studios. Not even studios targeting Android care, and it would be quite easy, given that ISO C11, ISO C++17, OpenGL ES, Vulkan, OpenSL and OpenMAX, all exist on GNU/Linux, and most middleware engines as well.

DonHopkins 3y ago

I wrote this up about relicensing the Unix port of SimCity that I did for DUX Software as free open source software under GPL3 for the OLPC (which runs Linux): "It's a good idea not to just keep a copy of the source code stashed away somewhere, but also any contracts relating to the rights to the code." https://donhopkins.com/home/micropolis/dux-maxis-contract.txt https://donhopkins.com/home/micropolis/dux-maxis-contract.tx... https://donhopkins.com/home/micropolis/dux-don-hopkins-contract.txt https://donhopkins.com/home/micropolis/dux-don-hopkins-contr... https://donhopkins.com/home/micropolis/olpc-ea-contract.pdf https://donhopkins.com/home/micropolis/olpc-ea-contract.pdf https://news.ycombinator.com/item?id=13693675 https://news.ycombinator.com/item?id=13693675 DonHopkins on Feb 21, 2017 | parent | context | favorite | on: Development content accidentally shipped on a DOS ... It's a good idea not to just keep a copy of the source code stashed away somewhere, but also any contracts relating to the rights to the code. In the early 90's, DUX Software licensed the rights to port SimCity to Unix from Maxis. Then DUX made a contract with me to do the work. I kept a copy of my contract with DUX, the original floppies they gave me with the original PC and Mac source code, as well as versions of the source code I ported to Unix. Years later I got a job working for Maxis on The Sims. Before we shipped it, EA bought Maxis, so a lot of people were let go, projects were canceled, physical and digital files were shuffled around, and institutional knowledge was lost. After we shipped The Sims but just before I left EA, on a fluke, I asked a Maxis old-timer if he had any idea if the contract between Maxis and DUX for SimCity still existed, and where it might be. As you would expect, it was in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of the Leopard." ;( So I waited late into the night for the leopard to fall asleep, made a photocopy of it, then returned the original to its hiding place. ;) Several years later, John Gilmore suggested we persuade EA to relicense the SimCity source code under GPLv3, so it could be shipped with the OLPC. Of course nobody in EA Management knew where the source code was or if it even still existed, but fortunately I still had my copy. And of course nobody at EA Legal even knew if EA owned the rights to the changes I'd made (Maxis had gotten into some pretty terrible SimCity licensing contracts in the past). But fortunately I'd kept a copy of the contract between myself and DUX, and the contract between DUX and Maxis, proving its provenance, which clearly stated that DUX's rights expired after 10 years, after which the rights to all the modifications I made went back to Maxis (and thus were inherited by EA). Once all that was cleared up, the most important factor was that EA deputized someone on the inside to shepherd the project through the various stages of approval, relicensing, development and QA. Otherwise it would have died on the vine, since everybody in a big company, no matter how well intentioned, is always 500% busy doing their own stuff and can't be distracted by something that doesn't affect the bottom line. It finally made it through both EA Legal and QA, and we released the SimCity source code and binary for the OLPC under GPLv3! https://github.com/SimHacker/micropolis/tree/master/micropolis-activity https://github.com/SimHacker/micropolis/tree/master/micropol...

5- 3y ago

to echo some other points in this thread -- i used to be very much in favour of linux ports / recreations, actively supporting them with my wallet. but even without switching away from x86, the linux userland churn (64bit, and lately and even largely, wayland) is too much. windows games still work. (wayland driver for wine is actively being merged into the upstream at the moment)

Topgamer7 3y ago
There is a Wayland branch on the collabora gitlab where devs first started developing Wayland support for those who don't want to wait and can build from source. It's going to be fairly different from the wine mainland after all the reviewing. But for those who don't want to wait a few months for that review process it works pretty flawlessly from what I saw.

TheMode 3y ago

Software maintenance shouldn't exist. Instead of fighting the source code to map the current trendy environment, we should compile our programs to easily interpretable formats that does not contain any environment specific code and therefore only contain logic specific to the given software. So instead of having a binary that contain some syscall to access a key state, provide it the function on startup (or the key state value directly if programs become stateless functions) As for the simple format, this is IMO the only way to guarantee accessibility as the alternative is having people constantly working on porting software over preferably with source access.

AshamedCaptain 3y ago
This is precisely the wrong solution. If anything, the CPU bytecode is one of the most stable things, so switching to some "interpretable format" is not going to help much. It is the total carelesness of literally everyone else in the entire stack which is the problem. If developers considered the inability to run a 30 year old game/software in the most recent release of "libwhatever" as a critical release blocker bug, then this problem would not exist. But obviously, this is not a popular solution. And currently we rather have the opposite situation, where open source projects dump compatibility as the default (e.g. Linux sunsetting a.out support), and only preserve compatibility in the comparatively rare case that there is enough developer mass.
- TheMode 3y ago
  ISAs aren't stable. Can you guarantee me that programs will be compiled for x86 in 20y? What instructions will they output to access the environment? Linux, Windows, MacOS? Will any of these even remain in 20y? No standard last forever, your bytecode will ultimately deprecate and this is not a "developers should stop being lazy" situation. Why do projects dump compatibility? Because this is extra work. And no project can receive indefinite support. Simple formats do not depend on maintenance.

sylware 3y ago

I am going to post here what seems to be the two least shabby recipes (Ethan Lee is aware of them) to generate elf/linux binaries which will run on "old" and "recent" distros. Then you will understand why normal game devs are not welcome on elf/linux, thx to the very nice and video game caring glibc and gcc devs (irony): First recipe: You must not link in the glibc "startup" runtime objects, aka you must not have main(): your executable must be a pure ELF64 binary, only the "_start" ELF entry point and the ELF ABI ("_start" is basically a main() anyway). Careful: all glibc runtime services which require those "startup" runtime objects are gone (you need to be able to find out which ones... good luck browsing glibc code...). Because those glibc "startup" runtime objects often require the same version or above glibc runtime being around (it is very vicious, look at glibc 2.33->2.34 with the new version of the libc_startup symbol... delicious). It means your build script on elf/linux must have fined grained compilation/linking (don't use the gcc compiler driver unless to discover static libgcc and static libstdc++ filesystem location... if you don't need to fork them). All host system dependencies must be libdl (dlopen/dlsym/dlclose), yes even the libc, memcpy, errno, etc. Of course you will have to use the static libgcc and static libstdc++ (if c++ is used). Namely if your game binaries are pulling code paths from libgcc and libstdc++ which requires glibc services, you have to fork the libgcc and libstdc++ from the gcc you use in order to properly "libdl-ized" those code paths (readelf command will tell you that while you have a look at the undefined dynamic symbols... and their required version). Then, you have the abomination of the ELF static flag: many glibc libraries have this flag, namely those libraries must be "statically loaded", namely have a ELF dynamic DT_NEED entry. You will find a ELF dynamic DT_NEED entry for libdl since you use (dlopen/dlsym/dlclose), and probably libpthread/libm(yes...!!!)/etc. Use the binutils readelf command to know if a library has the ELF static flag and must have such an entry (but you must still libdl it and its symbols to work around GNU symbol versioning issues!!). Some TLS code expect some TLS storage to be allocated and inited at executable startup, namely "static". Of course, all distributed binaries must follow those guidelines... even from third party. You want to expect normal game devs to be able to do that? ABSURD 2nd recipe: you get your hands on the most recent gcc, and the oldest glibc you want to support (~10years, more?). Compile such glibc, then this gcc to use only this very glibc (good luck configuring that cleanly). You can use main() and directly glibc services here, but still, you must libdl everything from the video game core libs (you need the headers only). Expecting that to go smoothly is just unreasonable, it will probably be a nightmare. All your distributed binaries must be built using this gcc and glibc. Expecting normal game devs to do that? GROTESQUE Both recipes must not generate binaries with the latest ELF relative relocations. The video game core libs on elf/linux are: wayland(static code in binaries)/libxkbcommon fallback-to-> x11/libxkbcommon-x11 (don't use libX11, only xcb libs). vulkan fallback-to-> GL fallback-to->CPU, be very conservative with shaders, VERY. libasound: alsa-lib, the software mixer is hidden behind the API, as it could be pulseaudio1/pulseaudio2(pipewire/wireplumber)/dmix/dsnoop/jack/whatever, have a ffmpeg resampling library ready if your audio formats are weird, or the user microphone audio format is weird. The trick: make user configurable the "speaker configuration" (5.1/7.1/headphones/stereo/etc), but with a automatic fallback to stereo if unable to open the device (all software mixers should support stereo mixing). joypad: linux /dev/input/eventXX files, check write access if you want to configure the rumbles. You can implement dynamic detection with linux inotify there (usually overkill though).