GaumBeist

My secondary laptop had an issue where the time would be wrong whenever I booted it up. I'd make sure the system was set to the right timezone, but it always required me manually setting the time, even restarting ntpd (and making sure I had internet) didn't work.

The problem was pretty clear, because the time would be off by years: the issue was that the hardeare clock was set incorrectly in the BIOS, because I use it so infrequently that it would lose all charge in the interim and the BIOS would be reset. Setting the hardware clock correctly fixed everything.

Not to be that gal, but... the GNU site's Bash Reference Manual documents everything you could ever want to know right up until you get into weird edge cases and abusing bugs/unintended behaviors for your own nefarious purposes.

For that, others have pointed to YSAP, whom I will also recommend. I can't find it right now, but I swear in some videos he mentions a website or forum where people discussi Bash extremely in-depth, and that is end-game stuff (the stuff you learn right before you start auditing the code yourself or editing the source to enable your own custom behaviors)

Here's the direct link

I avoid screens (with one exception mentioned in a bit)—especially social media (including fediverse)—for like an hour ahead of time, read a book, make sure I'm well fed and hydrated without eating too close to bedtime, wear a sleep mask, and put on some soothing music, podcast or (mostly audio-based) video—with the screen off as soon as I hit play. Sometimes I even resort to my noise-cancelling headphones—or earplugs, if the sounds of my own breathing, swallowing, and bloodflow don't bother me too much that night. It helps to meditate and/or make sure to exercise/work hard enough to wear myself out each day.

Comfort helps. Finding the right position, having the right sheets, mattress, pillow, getting the ac/fan/heater so the room feels perfect, maybe cracking a window for fresh air. Feeling secure and safe where I'm sleeping, confident that I'll make it through the night without rude awakenings. Each isn't very powerful on its own, bit all together make a big difference in how readily I drift off.

Finally, I just try not to worry too much whether I fall asleep or not; if it's not looking like it's happening, I'll try to write a story for myself or draw a masterpiece in my minds eye. If that doesn't work, I'll focus on invoking some Wake-Induced Lucid Dreaming instead: forcing myself to lie perfectly still with my eyes closed, not even shifting for comfort nor to scratch itches nor swat flies, letting my mind wander wherever it wants to and just going with the hypnagogic hallucinations (they can get a little uncomfortable at times). This rarely has the intended effect, but I usually do end up waking up later, realizing I fell asleep without knowing it.

Disclaimer: my routine won't solve insomnia, it won't fix neurological disorders that affect circadian rhythm, it probably won't work on the first night even if you don't have the aforementioned issues. But adding any part of it to your routine (if you can) will make it just that much easier to fall sleep, when you can get around to it, even if you do have underlying conditions.

Also, at the risk of sounding like a boomer, screens are really bad for sleep. I grew up with them: my family had a habit of watching tv until bedtime, I trained myself to fall asleep while staring at my laptop (which I often have on my bed), or I'll pick up my phone after I put the laptop down. Nowadays I can feel how awake my brain gets when I check lemmy or read news around bedtime. If I have my phone near me, I'll have this nagging feeling to do "just one more" check of all my socials.

And it always keeps me awake until I will myself to turn it off and close my eyes.

Idk how versed you are on Bash Parameter Expansion or the find command, so I'd like to expand (pun intended) a little more on Jo Miran's explanation (if you already know, I'll leave this for others who may not):

find's -exec (and -execdir) option takes everything after it until a semicolon — which usually needs to be escaped, so the shell doesn't accidentally treat it as the command separator special character — as a command to run and arguments to pass to that command. Furthermore, when using the -exec option, find treats all instances of {} as places where it should substitute the files it matched

So breaking down -exec bash -c 'mv "$0" "${0/crunk/chunk}"' {} \; really just tells find to take the name of a file it found (in this example it would only match dir1/crunk) and put it after the command bash -c 'mv "$0" "${0/crunk/chunk}"'

So now the command to run looks like bash -c 'mv "$0" "${0/crunk/chunk}"' dir1/crunk

this command spawns a (sub)shell, bash, tells it to run the next argument as a command, -c, gives it that command to run, mv "$0" "${0/crunk/chunk}", and passes filename as an argument, dir1/crunk

So now let's talk shell parameters

Usually $0 is a special parameter that references the shell (or script) that invoked the command. In the case of using the -c option, bash actually changes $0 to be the argument after the command to run: dir1/crunk

So now the command looks more like

mv "dir1/crunk" "${0/crunk/chunk}"

So let's finally get to the finish line: shell parameter expansion. Shell parameters (aka shell variables) can be written with curly braces around the name, so $SHELL and ${SHELL} refer to the same thing. But the curly braces can also let the shell know that if it sees certain special characters after the variable's name, it should do some transformations to the contents of the variable.

In this case ${0/crunk/chunk} takes the contents of $0, searches for the first instance of the string ”crunk", and replaces it with "chunk" before inserting it into the command.

So now the final command to run looks like

mv "dir1/crunk" "dir1/chunk”

Also worth mentioning that the -name option of find accepts wildcards in its argument.

I would also recommend using the -execdir option instead of -exec in this specific case, because it will run commands from inside the directories where it finds the files. In this case, that means {} would expand to ./crunk instead of dir1/crunk; this will be relevant in about 3 paragraphs.

So now you can tweak the command to your needs. If you wanted to find more than one file that, for example, all had a "u" somewhere in the name, you could do so thusly

find dir1 -name ”*u*"

And then if you wanted to change the "r" in the filenames to "l", you could do:

find dir1 -name "*u*" -type f -execdir bash -c 'mv "$0" "${0/r/l}"' {} \;

Note that you could not do this with the regular -exec option, as it would try to mv dir1/crunk dil1/crunk and throw an error because that directory (dil1) likely doesn't exist... and even if it did, you don't want your command moving files to different directories without your knowledge

Notice that it also only changed the "r" in dir1 to an ”l”, and left the "r" in "crunk" alone? That's not a typo on my part, that's the intended behavior of Shell Parameter Expansion. If you wanted to replace all "r"s in filename, you would have to change the expression to ${0//r/l} (note the double slash)

Seriously, it's worth reading that page from gnu.org. Parameter expansion can get incredibly powerful, and it's much easier to use the right format (${VAR/%r/h}) than trying to combine the most simple ones to achieve the same goal (e.g. DO NOT DO THIS: ${${VAR//r/h}/h/r}; it won't even work as intended and it's unnecessarily complex to read)

Presumably so the regex in the parameter expansion/replacement works, since you can't do that to the placeholder {} string that find uses

1. Yes........ in my opinion. The real answer is that it depends on the intended use of the system and the users' needs. It's as legitimate to treat wheel as a catchall permissions group as it is to go around specifying permissions for specific users in your sudoers and udev rules

2. From my understanding, the kernel tends to reuse the same names when attaching devices, but it's not required to do so by the specs (i.e. there may be cases where the /dev file name changes depending on what you have plugged in). Hence why the common advice is to not specify /dev files in your fstab, and why people use udev rules instead of chmod and chown-ing the /dev files

Sultans of Swing (metal cover by Leo Moracchioli feat. Mary Spender)

Cover - check
Popular song - check
From 80s or 90s - check
Redone into metal - check
Female vocalist - check!

Bonus song: Manhattan Skyline by Ihsahn feat. Einar Solberg
It's not harder than the original, but Ihsahn and Einar are some of the most influential metal musicians out there

I have a Lenovo Flex 2 15, which has an i3, 1080p display with intel graphics (although it's a 15" display) and upgraded to 16 GB of RAM

I use AntiX/MX Linux bc they're made with lower spec/older systems in mind. I started with AntiX-core to keep everything as lightweight (not a ton of background processes = low memory usage, low cpu usage) as possible

I use Sway bc 1. It's more lightweight than a full DE, and 2. Keyboard navigation is a must for laptops (trackpads only exist to inflict pain and misery on the world)

A couple great things about this setup is that it rarely overheats (as long as I keep it to a couple tasks at a time), and the battery can last for a 2 hours if I forget to plug it in

Even if you don't end up going with any of these suggestions, please take this to heart: never stop tweaking your system. You end up learning so much about it, and every little change makes it feel all that much more special to you

Ooh, ooh! I know this one!

NAT stands for "Network Address Translation." The important idea is that when your guest machine (windows) tries to access the internet, it sends the traffic to your hypervisor (VirtualBox or qemu/kvm). Your hypervisor then passes it to your host OS, which changes the source IP address to its own, and changes the source port to one that will help it recognize traffic meant for the windows virtual machine. It then passes that traffic on to your router, which does a similar thing so that the broader internet can't just access any device on your home network willy-nilly. When the server your windows machine contacted responds, it addresses the traffic to your host machine's IP with the special port that lets your host know it's meant for the virtual machine.

To simplify this into an analogy with the postal service: 5 year old Billy (your windows VM) wants to write a letter to Ted (a server or device somewhere outside of your host machine). Billy writes his letter and addresses it to Ted, but in the return address field, he writes "Billy's Room." He then hands the letter to his mom (the host machine) to mail it for him; knowing that Ted probably doesn't know where the flying fuck "Billy's room" is, she quickly crosses it out and writes her home address. She then mails it. When Ted gets the letter, he responds and addresses it to Billy @ Billy's mom's house. She gets the letter, sees that it's addressed to Billy, and takes it to his room.

A bridge is a virtual interface that allows the virtual machine to send traffic directly to the hardware (networking card) without bothering the host machine. This allows it to get its own IP address on the local network, and for everything on that network it appears to be a separate machine from your host.

This is like if Ted and Billy get to writing letters all the time, and Billy's dad (you) realizes he can just set up a second mailbox outside the house for Billy and negotiate with the postal service so that the address on the mailbox is "Billy's room." Now Billy's mom never has to handle his mail or rewrite the addresses anymore, which is good, because Ted just mailed Billy a bomb (because no one, not even Billy, can know where Ted Kaczynski is).

"Can you make me download 150 MBs of .js files before I can read a single text-based article please?" - Software connoisseurs before AIs bloated everything

Fantastic resources, especially that pistack article. Tysm!