530
submitted 9 months ago* (last edited 9 months ago) by renzev@lemmy.world to c/linuxmemes@lemmy.world

I recently wanted to run tegaki, and my experience is pretty much summed up by the meme. I consider myself fairly tech-savvy, but I just couldn't figure out how to compile it. So I just gave up, downloaded the .exe and put it into a fresh wine prefix. After installing CJK fonts, everything ran fine. Now I'm trying to get gpaint to work. ~~My distro recently dropped support for gtk+2 (which I am fairly pissed about, since it's the last good version of GTK+), so I have to set that up manually as well.~~ [[[ EDIT: gtk2 is alive and well. I was just being and idiot and searching for gtk2, when the package is actually called gtk+2. ]]] I installed all of the dependencies that ./configure told me to, but I still kept getting obscure errors when running make.

So, here's my question: what tools make the process of running abandonware easier? Docker containers? Also, what can I use to package abandonware in order to make it easy for other people to run? Flatpak? Appimages? Any advice is appreciated!

Also, inb4 "just find a modern alternative". That would be a reasonable solution. I don't want reasonable solutions!

top 50 comments
sorted by: hot top controversial new old
[-] observantTrapezium@lemmy.ca 91 points 9 months ago

Pull a docker image of an old distro into an apptainer sandbox, install what you need within, then make a .sif image, should work pretty much in perpetuity. You can also try to make an Appimage.

[-] sturlabragason@lemmy.world 42 points 9 months ago
[-] huskypenguin@sh.itjust.works 3 points 9 months ago

I was coming here to post this.

[-] renzev@lemmy.world 16 points 9 months ago

TIL about sif. Thanks, will give it a try!

[-] Alborlin@lemmy.world 2 points 9 months ago

I am a beginner Linux user, if above scenario happens to me , I will not know what the hell you are talking about and just get windows, the linux community , here does not support the average user even in memes.

[-] observantTrapezium@lemmy.ca 4 points 9 months ago

This was just an outline of what you could do in the scenario, not a full solution. Looking up the keywords, "Apptainer" (+sandbox), ".sif", and "AppImage" should give you a starting point, and any specific questions can be answered separately. You are right that people could be jerks to beginners but this is rarely the intent. Not all discourse about Linux has to be at a beginner level, and packaging legacy software is not really a beginner topic.

[-] monobot@lemmy.ml 2 points 9 months ago

I am using linux for 20+ years and don't understand what they said. And I don't even want to, I was using wine to run open source software before flatpak, when I need it once a year.

[-] TootSweet@lemmy.world 33 points 9 months ago

Running the Windows version in Wine probably would never have occurred to me.

Arch (i UsE aRcH bY tHe WaY)'s AUR has a package for it. I just installed gpaint on a Raspberry Pi 4 just to see if it worked. It worked perfectly. (Disclaimer: I did have to update the architecture in the PKGBUILD to allow armv7h, but on an x86_64 machine, that wouldn't be an issue.)

You could probably run Arch in Docker and install the AUR package in the Docker container if you wanted to go that route.

[-] T0RB1T@lemmy.ca 10 points 9 months ago

I do this using an Arch distrobox on my openSUSE Kalpa machine whenever I need anything that isn't flatpak'd or available through my tumbleweed distrobox.

[-] Petter1@lemm.ee 10 points 9 months ago

Mi just love the AUR 👌🏻

[-] eya@lemmy.dbzer0.com 27 points 9 months ago
[-] kogasa@programming.dev 6 points 9 months ago

AUR can't save you from a library needing old versions of dynamically linked libraries

load more comments (2 replies)
[-] callyral@pawb.social 24 points 9 months ago

find an even older, less mantained alternative.

[-] sharkfucker420@lemmy.ml 21 points 9 months ago

Or you find an AUR someone built years ago

[-] Chewy7324@discuss.tchncs.de 12 points 9 months ago

That'd be one of those many broken AUR packages that won't compile.

[-] sharkfucker420@lemmy.ml 13 points 9 months ago
[-] tostiman@sh.itjust.works 12 points 9 months ago
[-] aBundleOfFerrets@sh.itjust.works 2 points 9 months ago
[-] renzev@lemmy.world 4 points 9 months ago

I read that as "they cygwin" and tbh it's a pretty accurate depiction of doing anything with cygwin, in my experience at least

[-] Thcdenton@lemmy.world 17 points 9 months ago

I got Mechwarrior 3 working with wine. That shit was fuckin impossible on modern windows.

load more comments (1 replies)
[-] OpenStars@startrek.website 16 points 9 months ago

I like how you pointed out: backwards compatibility is a choice.

[-] LesserAbe@lemmy.world 11 points 9 months ago

Maybe I'm missing something or don't know how to use wine, but more than 50% of the time if I try to run an old windows program it doesn't work.

[-] renzev@lemmy.world 4 points 9 months ago* (last edited 9 months ago)

Wine tends to work better for W*ndows programs that already have a Linux port, because they depend on fewer m*crosoft-specific libraries... which is not very helpful most of the time, but it is the subject matter of the meme.

[-] LesserAbe@lemmy.world 3 points 9 months ago

Also guess I should say my solution is to run a virtual Windows machine on my Ubuntu laptop

load more comments (2 replies)
[-] IndustryStandard@lemmy.world 11 points 9 months ago

One day someone's posts how all Linux programs run forever and Windows creates abandonware

Another day someone complains about the Linux version of his program not tuning anyone so he has to use the Windows version

I'm not sure what's going on anymore

load more comments (6 replies)
[-] WaterWaiver@aussie.zone 10 points 9 months ago* (last edited 9 months ago)

A method I have not seen mentioned yet (for when you have an old precompiled version of an app):

  1. Identify the missing libs. You can run the program, but sometimes it's easier to use ldd
  2. Use your web browser to download the missing libs from Debian's repos (stable or older if need be). Unfortunately you often also have to grab their deps too.
  3. Extract the .debs
  4. Move all of the .so files into the same folder as the old program you are trying to run
  5. export LD_LIBRARY_PATH="$(pwd)"
  6. Now try running the app

It often takes a bit of fiddling, but it's worked for me a few times and you only need to fetch the few libraries you are missing. For bigger things however it can be a dependency hell, you might as well use the distro's actual package manager inside a chroot.

Note: You don't need to be using Debian as your host distro, I don't. As long as it's a glibc based distro you should be mostly fine (glibc is mostly backwards compatible)

[-] palordrolap@kbin.social 10 points 9 months ago* (last edited 9 months ago)

Sometimes you can have a similar experience trying to get abandoned Windows software to work too. Found myself in DLL/OCX hell trying to get an obscure old Windows game to work in Bottles.

And if that wasn't bad enough, after installing Bottles' Flatpak (the first and only Flatpak I've ever used), the system decided to activate hourly Timeshift backups despite that being disabled in Timeshift's config. I invoked the power of irony and told Timeshift to take the system back to a pre-Bottles state, and lo, everything behaved again.

[-] renzev@lemmy.world 2 points 9 months ago

I love bottles. Especially the flatpak version, since I don't have to worry about w*ndows programs shitting up my filesystem. And the recent per-bottle sandbox feature is also great for running semi-untrusted applications without needing to toggle things in Flatseal every time. I do wish Bottles kept support for winetricks tho. Recently wanted to run M$ Paint (the XP version), and it just wouldn't work with Bottles. Ended up installing the official Wine flatpak and using winetricks from there (it comes pre-installed).

[-] devfuuu@lemmy.world 9 points 9 months ago

Nix or guix are the proper solution.

[-] marcos@lemmy.world 9 points 9 months ago

Yep, if you manage to make it run on them, you are set forever.

[-] 2xsaiko@discuss.tchncs.de 7 points 9 months ago

First thing I'd try is to use a "period-correct" nixpkgs commit for the libraries. It might even have the package already.

[-] renzev@lemmy.world 2 points 9 months ago

Hmmm I'm a bit hesitant about nixpkgs, since when I last tried using it (outside of nixos), many (modern) GUI apps were broken, at least on my distro, But I'll give this a try if u/observanTrapezium's suggestion doesn't work. Thanks!

[-] 2xsaiko@discuss.tchncs.de 6 points 9 months ago

If the app uses OpenGL in any way, you need to use nixGL: https://github.com/nix-community/nixGL

load more comments (2 replies)
[-] Falcon@lemmy.world 6 points 9 months ago

Well to clarify the two big differences here are that the exe is pre compiled and maybe dynamic libraries.

Heavy tech stacks do suck though

[-] space@lemmy.dbzer0.com 5 points 9 months ago

Or just download an older live CD that is compatible, and use it in a VM.

[-] WaterWaiver@aussie.zone 4 points 9 months ago* (last edited 9 months ago)

My distro recently dropped support for gtk+2 (which I am fairly pissed about, since it’s the last good version of GTK+)

Stuff like this completely throws the shared libraries idea in the bin. There are lots of benefits, sure, but none of them matter when your program won't even start.

Please name and shame your distro. GTK2 is a core component of userspace for many users, just as important as glibc and bash. Maintaining it might be annoying, but it's the lesser of two evils.

My distro (Void Linux) dropped support for qt4 a few years back. Now I'm running QUCS in wine. "win32 is the only stable ABI in Linux"

(And yes you're right 2 is the last good version of GTK+. Gtk3 and 4 look and feel so much worse, they make me feel like I'm being punished.)

[-] shalva97@lemmy.world 3 points 9 months ago

just another Monday

[-] dai@lemmy.world 2 points 9 months ago* (last edited 9 months ago)

~~ive got limited experience however i think ive got tegaki-python to build under nixos:~~

https://pastebin.com/yCKUBrgG

~~name to default.nix then run (from the same dir)~~

~~nix-build -E 'let pkgs = import { }; in pkgs.callPackage ./default.nix {}' --show-trace~~

~~lots more to build but i looks possible to have up and running in nix with some small tweaks from the initial nix-init .nix~~

~~a sparceCheckout would trim some fat however minimal on a per-package basis too~~

looks like its running into perm issues, bit over my head :D

load more comments
view more: next ›
this post was submitted on 23 Jan 2024
530 points (98.5% liked)

linuxmemes

21281 readers
25 users here now

Hint: :q!


Sister communities:


Community rules (click to expand)

1. Follow the site-wide rules

2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack members of the community for any reason.
  • Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
  • Bigotry will not be tolerated.
  • These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
  • 3. Post Linux-related content
  • Including Unix and BSD.
  • Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of sudo in Windows.
  • No porn. Even if you watch it on a Linux machine.
  • 4. No recent reposts
  • Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.

  • Please report posts and comments that break these rules!

    founded 1 year ago
    MODERATORS