The neat thing is that like
You COULD study and learn how to read the stuff Linux vomits on the terminal
Windows programmes just die and tell you nothing. Good fucking luck.
Yeah, being able to google stuff that’s not working has been a lifesaver for me. Or (and I know it’s not popular here) taking a snippet of some confusing output and giving it to an AI to have it explain what things mean.
I mean… Following what the Linux terminal was doing definitely helped me catch problems as they occurred back when I was using Ubuntu.
Honestly, shout out to the folks who maintain packages, Linux error logs are very searchable and readable.
I usually just scan the terminal logs looking for error flags and then search for them to see if they’re something that can, and should be, fixed.
You’re following it to understand it, I’m following it to skim for warning signs.
We are not the same.
It’s less of an understanding, and more of a “Hmm that’s a lot of good colour text” or “Fuck, that’s a lot of bad coloured text!”
Excellent, remember that after 64 times booting the system there will be a mandatory test on 16 random boot up messages.
Fail, and the system refuses to start.
Few Linux users have ever successfully beaten it…
…mostly because they have never had to reboot their system 64 times before getting a new machine.
People reboot their systems?
How else am I supposed to exit Vim?
You can reboot your system?
You guys know where the physical machine is?
…mostly because they have never had to reboot their system 64 times before getting a new machine.
You really didn’t have to call me out like that.
I’ve had my system for ~4 years now, and I think I’ve rebooted it a grand total of maybe 10 times. Pretty much never voluntarily. Usually due to a power outage or needing to shut down for a hardware upgrade.

Source? What’s going on here?
I just picked a random image of packages being updated.
Or if you mean the Star Trek image, it’s from an episode where Uhura and Spock are trying to fix one of the consoles on the bridge. ‘Who Mourns for Adonais’ season 2, episode 2.
Yes, the second. With some children toy thing, so it was Star Trek after all.


I think that the point being made here is that it’s not a great idea to hold an actually running soldering iron by the hot bit?
If so, I think that OP’s image is supposed to have some sort of thermal insulation stuff around the hot bit, that clear stuff.
Anti-fingerprinting or something, idk I don’t use secure browsers
Yeah, just reminded me of this.
is it even a soldering iron? i was assuming it was a probe for a logic analyzer or something
You can see metal changing colours due to temperature, those are definetly soldering irons except the top right one which is a hot air soldering station and (IIRC, I have the same model) it goes up to 550C. You don’t want to hold any of those on the business end when they’re running.
Yeah, the later images being posted are definitely soldering irons. I think that TurboWafflz is asking whether maybe the thing in the original Star Trek image that OP put up is intended to be a soldering iron, which is a fair question.
I’ve used probes with little hooks on the ends myself, but I imagine that there are pointy probes out there.
Ah, right. I’m not in star trek scene, but what I’ve seen that might be a probe, soldering iron, welder and a plasma cutter all in one in that universe.
I basically read logs for a living, read the boot sequence at least once in your life. It’s very cool to be able toi see the bootstrapping order and understanding all the basic things that have to be initialized just for the most basic of OS things to happen.
The boot sequence is what I was picturing originally, but I didn’t know how to word that cleanly for the meme, lol.
I thought the same when I first booted Linux, but after reading it day by day, you’ll understand more and if it is too fast you can always
Edit: woups!Sudo dmesgNote that on current, systemd-based systems, one probably wants
sudo journalctl -kbto show kernel messages for the current boot.dmesgreads from the in-memory kernel ring buffer. That can be desirable in some cases, but as the name suggests, the “ring buffer” is a “ring” — it has a finite amount of space and eventually, the old stuff gets overwritten by the new stuff. The idea is that a userspace logging daemon, like journald (or syslogd on most older systems) has time to pull the data from the ring buffer out to (potentially much larger) log files on disk.journalctl will also post-process the output to do things like convert the time-from-boot to a wall clock time, which is generally more useful for correlating with other things.
dmesg
😮🙏🏻woups
The way these tools are designed, typically unless something goes wrong you need to understand basically none of it. And if something goes wrong, the resulting error messages normally at least give you something to search for in order to understand more
Yesterday I installed a program to run windows games. The installation through the terminal spat out ten different types of “Error reading the jupitos bus” type messages that I simply could not parse, but they sounded grim and serious.
But it ran just fine afterwards so those messages couldn’t have been that important?
Error severity depends on whether you’ve mounted the bus. You wouldn’t want to go to Jupiter by accident
in wine there are many partially implemented/stubs, which generate warning messages but usually work fine
the resulting error messages normally at least give you something to search for
And:
#include <errno.h> #include <stdio.h> int main (void) { errno=ENOANO; perror(""); return 0; }Yields:
$ ./a.out No anode $
If you don’t want it, you can hide it — most distros have some way to just show a splash screen that hides it. I always unhide it, as I can see hints of things going wrong.
The messages are from a wide variety of kernel subsystems (and, later in the boot process, daemons) and most people aren’t going to be familiar with everything. I could tell you what a lot of lines mean, but there are always new ones showing up as new software is written.
They’re more-likely to be useful if something breaks and then you go examine a specific, suspicious-looking message and learn what it means. You probably won’t be constantly trying to stay up on all kernel subsystems.
as I can see hints of things going wrong.
Yes!
Even if you don’t understand every line, if the system hangs or just takes an unusually long time to boot, you’ll be able to see what it’s getting stuck on. And even if you don’t understand that, you can
googleDDG the message and find out what it’s doing, maybe figure out what’s taking so long, what’s wrong, and how to fix it.And even if you don’t care, if you have an old machine booting from a HDD, the process at least isn’t so boring.
^This comment is talking about the deluge of log messages you may or may not see (depending on the distro) while booting the system.
Just thought I’d add that, since the meme doesn’t actually mention booting. Not sure, where you got that from. 😅
In fact, the image in the meme shows an Ubuntu system installing updates using
apt.
Why are people so resistant to reading? fortunately, most things output an explanation of what went wrong, and often you can google that message…
Just skim to the part that tells you to type “yes, do as I say!”
Imagine syslog getting presented as a streaming video… “hi this is your friendly kernel again and today we’ll have another look at …” * looks at list… “initialising network, loading modules and much more. But first, a message from our sponsor!”
LEARN
I’m trying! There’s a lot.
You don’t have to learn though, you can just click on icons, like an animal.

















