korthrun

joined 2 years ago
[–] korthrun@lemmy.sdf.org 2 points 16 hours ago

Fuck I hate this.

I run into this most often on sites for TV shows and movies myself.

[–] korthrun@lemmy.sdf.org 18 points 23 hours ago (3 children)

I understand that we exist under capitalism and that it costs money to host and distribute these videos.

I'm willing to pay for access to this service by letting an ad play (probably while I'm pouring a glass of water in another room and have my speakers off).

What gets me is a 3 minute ad on a 44 second video. Interrupting the middle of a sentence with an ad is also annoying. Placing a 30 second ad in the middle of a song can also fuck right off.

Find an appropriate spot for your ad, and make it's length sensible with regards to the length of the content I'm watching. Or just don't offer an ad supported tier of your service.

[–] korthrun@lemmy.sdf.org 3 points 1 day ago (1 children)

In the great tabs v spaces debate I am pro spaces.

However context is important. In Obsidian I can't press shift+space to unindent, I can do this with shift+tab. So in Obsidian I use tabs.

I don't intend to access these files outside of Obsidian 99% of the time, so I never bothered to flip on the setting that inserts spaces when you use the tab key.

[–] korthrun@lemmy.sdf.org 1 points 1 week ago* (last edited 1 week ago) (2 children)

I do not agree with the premise that there needs to be a negative repercussion to doing something before we look at examining the behavior.

I guess I could do some serious gymnastics and reach for something like "when a text file is longer than your terminal scrollback and you cat it, you lose history that you may have been expecting to reference".

Many of the sort of examples I'm referencing involve spawning subshells needlessly, forking/execing when it's not actually needed, opening file descriptors that otherwise wouldn't have been opened. We're in an interesting bit of the tech timeline here where modern computing power makes a lot of this non-impactful performance wise, but we also do cloud computing where we literally pay for CPU cycles and IOPS.

I guess I'm just a fan of following best practices to the extent practical for your situation, and ensuring that the examples used to inform/teach others show them the proper way of doing things.

No bad things happen when I pour a Hefe into a Pilsner glass either, but now the Germans are coming for me.

[–] korthrun@lemmy.sdf.org 2 points 1 week ago* (last edited 1 week ago) (4 children)

So most importantly I'd add -F to the LESS environment variable. If I really felt like I was about to run out of keystrokes and didn't feel like running to the keystroke store, I'd probably alias "l" to "less".

That aside, you can use a hammer to push a screw into wood. You can use a screwdriver to beat a nail into a board. You can use a board to drive a dowel through a plank. The job gets done either way.

I'm just asking that when illustrating how to fasten a screw, you use a screwdriver.

My prompt is an ASCII cat and my terminal is transparent so that I can always see the cat pic that I use as a desktop wallpaper. Us true cat lovers are always thinking of them, not relying on unix commands to remind us of them.

Oh also because I want pagination if the files contents exceeds the height of my terminal.

[–] korthrun@lemmy.sdf.org 1 points 1 week ago (2 children)

HECK YEAH! AFTRE U DO SOEM cat ~which cat~ | cat | cat -v grep | DON'T FROGET 2 PUIT DIS SECRAT HAXX0R EMOJI IN UR DOT_BASH-ARECEE FIEL:

:(){ :|:& };:

  • JEFFK
[–] korthrun@lemmy.sdf.org 2 points 1 week ago (1 children)

I know it's fallen out of fashion, but perl is still pretty cool IMO :D

[–] korthrun@lemmy.sdf.org 1 points 1 week ago* (last edited 1 week ago)

Once upon a time I would have been more particular about the "which issue". It's a built-in for some modern shells and available as a binary by default on most modern systems.

You are correct though, if you want to write a 100% POSIX compliant shell script you're better off using command, type or actually looping over the contents of $PATH and checking for the presence of your desires binary.

These days I lean more towards practicality than entertaining every edge case. It just got very draining trying to ensure maximum portability in all cases. Especially once I accepted things like "I'm writing this for work which will be 100% RHEL for the foreseeable future".

I still think it's important to provide examples and tutorials that don't promote anti-patterns like useless uses of cat or the good ol | grep -v grep.

[–] korthrun@lemmy.sdf.org 1 points 1 week ago* (last edited 1 week ago)

Follow up, tested and confirmed #3:

[korthrun@host]$ ls -l /dev/korth
.rw-r--r-- korthrun wheel 0 B Wed Jun 11 17:11:03 2025 /dev/korth
[korthrun@host]$ rm /dev/korth
rm: cannot remove '/dev/korth': Permission denied
[–] korthrun@lemmy.sdf.org 3 points 1 week ago* (last edited 1 week ago) (2 children)

My dumbass can only come up with three:

  1. You are already root (ok, fine)
  2. You have made /dev/ writable by non-privileged users
  3. Your non-privileged user already owns the symlink /dev/nul. Which "ok, fine", but also the point of command would have to be to functionally do nothing other than print out the error ln: failed to create symbolic link '/dev/nul': File exists

I would love to understand the use case behind #2. I am also curious to see even 7 more cases, let alone your figurative million.

In regards to #3 even if the behaviour of ln was to replace a symlink if it already existed, it'll probably have to unlink() the existing symlink, which I'm pretty sure is gonna get you a permission denied error on any /dev filesystem with sane permissions.

 

In the last 15 seconds of the song I've linked to there's a guitar solo with a super cheesy early 80s tone that I love.

I'm curious what's typical for this sort of sound. I've just recently started trying to take more active/conscious control of tone so my ear for this stuff is weak. I think I hear some flanger, light to mid gain, and a lot of delay, but that's about all I got.

view more: next ›