You are not logged in.
Airport security found a suspicious-looking unattended suitcase.
After efforts to find the owner failed, they decided to force it open. And lo and behold, it contained nothing but a single German sausage.
"Oh no," said the chief inspector. "This is the wurst case scenario!"
Europun Trip
Had a Danish for breakfast,
But I'm still Hungary.
Went with France to a Turkey lunch,
Paid the Czech and climbed the tower in Paris:
Eiffel and now I'm in Seine.
Saw repairman on a Poland said:
Lift me outta here, Ukraine!
The student was dozing off in English class. The teacher noticed, and snapped:
"Name two pronouns!"
The student replied groggily, "Who, me?"
Math teacher: Why are you handing in a blank sheet of paper for your assignment?
Student: Because all my answers are imaginary numbers.
My daughter decided to name her iPad after the Titanic. I have a syncing feeling about this...
Doctor: You have acute appendicitis.
Patient: Is that better than an ugly one?
"My sister plays the piano by ear!"
"That's nothing; my brother fiddles with his whiskers!"
"How much do you think the chimney cost?"
"Let me guess -- nothing, because it's on the house."
"On the contrary, it was through the roof!"
Dependencies are inherently evil. Did you know that versioned dependencies are an NP-complete problem? As in, if you have a graph of projects that have versioned dependencies on each other, resolving these dependencies potentially require an exponential-time (or exponential-space) algorithm. Dependency hell indeed!
In my own code projects, I prefer having no dependencies at all. Of course, this isn't always possible; so the next best thing is shallow dependencies: those that only require 1 level of dependencies. Actually, before I even get to dependencies, my preference is single-file modules that I can just copy into my source directory and use as-is, without declaring any dependencies. Not many things can be used this way, but when such exist, I prefer it. Only if I have no choice, I'll go with a shallow dependency. And of course, the fewer dependencies the better. Recursive dependencies I try to avoid like the plague unless there's absolutely no way around it. And I absolutely would not touch an automatic dependency system that will automatically download 500 packages in response to a single dependency on some package that's promiscuous in its recursive dependencies. Those things are pure evil.
See also this link that describes a lot of the issues that come with dependencies, that people have been ignoring for far too long: https://research.swtch.com/deps
If OSes were cars...
Windows user: I'll install this new filter and it should run for another 2 years.
Mac user: Oh no, something in there is broken, time to buy a new car all over again!
Linux user: (stares at floor full off isolated car parts and wonders how long it will take to recompile the entire car.)
The couch potato finally found a job at the stadium that suited him. He became a common-tator.
That sounds dangerous. If the executable is linked against version 4 of the .so, substituting version 5 may introduce subtle errors or crashes due to ABI incompatibilities. If at all possible I'd recommend getting a new version of the executable that's linked against version 5 of the library, or compile it yourself against the right -dev package.
Sorry was too lazy to do it. Will do that next time. My bad!
I almost always run apt-get with --no-install-recommends, because a lot of "recommended" packages are really needless bloat that I have no need of.
After this fiasco I'm almost ready to switch to a source-only distro, which I'd configure by hand to contain the absolute minimum options I need to do what I need to do, and nothing else. Even after getting rid of systemd too many Debian packages still come with too many things enabled by default. Mostly useless things that I never actually use.
If it were up to me, I'd just compile the sources for libhcrypto4 myself (or download the binary from somewhere) and use LD_LIBRARY_PATH to get it to load at runtime.
P.S. apt-file didn't find anything on my system. That probably means the required package isn't in Daedalus. However, it does show up in google in various rpm repos. Maybe what you want is to install `alien` and use it to install the needed rpm? I'm not 100% sure this is the best approach, though, because this could mess with your system in a way that's hard to undo should you change your mind afterwards.
Use apt-file to find out which package libhcrypto4 is in, and install it.
ld doesn't do what you think it does; it's for linking object files into an executable as part of the process of compiling source code into executable form. You can't use it to specify libraries at runtime; that's part of the OS dynamic library system and it won't help you if you don't actually have the required library installed.
How did the farmer stop the aliens from invading earth?
He caught their spaceship in his tractor beam.
A pun walks into a bar and 5 people died from laughter, another 5 died groaning.
Pun in, ten dead.
Relax, it's not as though I spend all day thinking up lame jokes. It's just a way to decompress after doing real work at my day job. After work some people tend to their garden and grow herbs, some people relax and get a beer belly. But IMHO that's just a waist of thyme.
Did you hear about the man who lost his left side? He's all right now.
What happened to the rest of him? That's all that's left.
@steve_v: you're probably unaware of this, but this is what ldd's manpage says about using it on untrusted or potentially malicious executables:
Be aware that in some circumstances (e.g., where the program specifies an ELF interpreter other than ld-linux.so), some versions of ldd may attempt to obtain the dependency information by attempting to directly execute the program, which may lead to the execution of whatever code is defined in the program's ELF interpreter, and perhaps to execution of the program itself. (Before glibc 2.27, the upstream ldd implementation did this for example, although most distributions provided a modified version that did not.)
Thus, you should never employ ldd on an untrusted executable, since this may result in the execution of arbitrary code. A safer alternative when dealing with untrusted executables is:
$ objdump -p /path/to/program | grep NEEDED
Note, however, that this alternative shows only the direct dependencies of the executable, while ldd shows the entire dependency tree of the executable.
In the case of the xz exploit, it's probably very unwise to use ldd to examine potentially affected executables.
Tried calling the tinnitus help line...
No answer, just kept ringing...
🤣
Did you know that there's a species of antelope that can jump higher than an average house?
This is due to its powerful hind legs, and the fact that the average house cannot jump.
"I am Ohm of Borg. Resistance is voltage over current."