I assume the original photo or film must have holes or marks on it, they would be interesting to see.
I also have an (unconfirmed) suspicion that this image may have been a black and white photo that has been digitally colourised. It can’t have been fully AI colourised as the flowers on the lady’s dress are too perfectly coloured (even where they are hidden in folds or shadow). Alas the chroma of the flowers is shaped in perfect circles of pink, even overlapping black areas of the dress (where it’s otherwise coloured slightly blue), making me suspect a round brush tool in an image editor:
I can’t be 100% certain, there might be some other explanation for this chroma patterning. It’s not JPEG (that quantises in square blocks, not circles). Might be some weird optical effects or multiple layers of JPEG on top of each other causing gaussian filtering (if you apply box filters repetitively at different offsets then you eventually approximate a gaussian). Not to mention that the version I downloaded is a .webp (and I have no experience with that format), I suspect Lemmy might have converted it upon upload.
A method I have not seen mentioned yet (for when you have an old precompiled version of an app):
Identify the missing libs. You can run the program, but sometimes it’s easier to use ldd
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.
Extract the .debs
Move all of the .so files into the same folder as the old program you are trying to run
export LD_LIBRARY_PATH="$(pwd)"
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)
They edited the left side with a clone tool to hide the fact some of the coloured slides/layers are a bit faded at the edges. This also explains why the left of the image is yellowish and the bottom reddish. Perhaps those slides were like that their entire life, uneven due to manufacture or developing issues?
Across the entire image are tiny coloured blips and scratches. Most of them were edited out.
The rounded shape of the chroma on the flowers isn’t as evident in this version, but it still looks blurry. It’s plausible that the super-round shape in OP’s version of the image is an artefact from multiple lossy image encodings POSSIBLY combined with the red channel (glass slide) having worse resolution than the other colours in these areas (?).
<span style="color:#323232;">Ctrl-z
</span><span style="color:#323232;">kill -9 %1 # Shell keeps track of job pids for you, job 1 is %1, job 2 is %2, etc
</span><span style="color:#323232;">fg # Not technically necessary, but it's fun to see the corpse
</span>
You could probably increase the 82K and 10K resistors to be much bigger (by a factor of 10x or maybe even 100x). Lookup the input impedance for the ADC of your model of ATmega, as long as it’s >10x the size of your resistors then your circuit will probably be accurate enough.
A couple more things to keep in mind:
a fresh alkaline 9V battery is actually 9.6V or more, not 9V.
9V battery voltages droop noticeably when under load because of their high internal resistance. Make sure to measure under the same conditions.
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.)
I’ve been using PipeWire this year on my Void Linux laptop & desktop. It’s been mostly OK but has a few problems. For years I have been using plain ALSA (with no custom configuration) because pulseaudio causes me regular issues across multiple machines (mostly silently failing).
Pros:
I don’t have to use Chromium for my mic to work on online video conf (WTF Firefox)
“EasyEffects” lets me quickly fix crappy youtube audio (bad gain normalisation, way too much sibilance) with a minimum of effort.
Cons:
Sometimes breaks all audio until I manually restart it (hey, just like pulseaudio. This problem never happens when using ALSA straight)
First time setup is complicated, involving environment variables, dbus user session buses and multiple daemons (running just pipewire isn’t enough). Why can’t it handle this all itself? Surely it should notice if these things are missing and just fix it itself? Compare this to straight ALSA where you (1) do nothing and then (2) everything works (except Firefox mic support)
I can’t have multiple audio outputs all unmuted at the same time. Eg my headphone output and my rear speaker output. If I override this (using alsamixer) then it gets forgotten next boot anyway, it seems to be out of scope of PipeWire’s understanding.
I’m very curious about the downvotes to this one. May I ask people’s thoughts? Perhaps I’m too vague? I can put a bigger story about my experiences with various init systems in production & research if people are interested.
The fact this issue is happening on both Pipewire and Pulseaudio also suggests it’s more likely a bug in the drivers… It might not be obvious on ALSA directly, but that doesn’t mean an issue doesn’t exist there…
I probably made the overlap unclear, sorry:
Pipewire issues: My 2023 desktop and 2016 laptop, very different hardware.
Pulseaudio issues: All of my pre-2023 desktops and several family laptops
I do a lot of middleware development and we’re regularly blamed by users for bugs/problems upstream too (which is why we’ve now added a huge amount of enduser diagnostics/metrics in our products which has made it more obvious the issues aren’t related to us).
Eep, that’s annoying. You also probably don’t have direct interaction with the users most of the time (they’re not your customer) which makes this worse, people in a vacuum follow each other’s stories.
In practice, very few people have issues with Pulseaudio (I haven’t seen issues since launch). Sometimes as well, keep in mind it can be the sound interface (especially if its USB)
There might be a bias here because these problems are not persistent, ie a reboot fixes them.
In regards to setup, most distributions will handle that anyway I’m guessing. So not sure why the configuration process should matter unless you’re in Arch or Slackware? As long as the distribution handles it, it shouldn’t matter. It’d really a non-issue honestly.
That’s potentially more things different distros can do differently and more issues your middleware will start getting blamed for.
Yes it’s not a problem for user-friendly distros, but why does the user friendliness problem exist anywhere anyway? It’s better to fix problems upstream, not downstream.