DefederateLemmyMl @ SpaceCadet @feddit.nl

* Gen𝕏

---

Read more

Posts

1

Comments

584

Joined

2 yr. ago

Full kernel corruption

What does that even mean?

Was the file system on which your kernel resided corrupt, or did something go wrong with a kernel upgrade/installation?

It is the most popular lemmy instance though, so them banning a community like this is quite impactful.

IIRC they banned piracy@lemmy.dbzer0.com months ago. Not sure why it pops up again in the modlog. It was the reason I left lemmy.world.

Oh I wanted to say, “Do not use #!/bin/sh if you’re not writing bash-only scripts”

Hah, I was wondering if that was wat you actually meant. The double negation made my head spin a bit.

I have run into scripts that don’t work on Debian, because the author used bashisms but still specified /bin/sh as the interpreter.

The weird thing is that man bash still says:

 `

    
When invoked as sh, bash enters posix mode after the startup files are read.
...
--posix
    Change  the  behavior  of bash where the default operation differs from the POSIX standard to 
    match the standard (posix mode). See SEE ALSO below for a reference to a document that details 
    how posix mode affects bash's behavior.
`
  

But if you create a file with a few well known bashisms, and a #!/bin/sh shebang, it runs the bashisms just fine.

Do not use #!/bin/sh if you’re not writing bash-only scripts

Actually #!/bin/sh is for bourne shell compatible scripts. Bash is a superset of the bourne shell, so anything that works in bourne should work in bash as well as in other bourne compatible shells, but not vice versa. Bash specific syntax is often referred to as a "bashism", because it's not compatible with other shells. So you should not use bashisms in scripts that start with #!/bin/sh.

The trouble is that it is very common for distros to links /bin/sh to /bin/bash, and it used to be that bash being called as /bin/sh would change its behavior so that bashisms would not work, but this doesn't appear to be the case anymore. The result is that people often write what they think are bourne shell scripts but they unintentionally sneak in bashisms... and then when those supposed "bourne shell" scripts get run on a non-bash bourne compatible shell, they fail.

Goodbye warranty then. Many manufacturers have already been doing that with chip tuning, which is also just a software modification. When you take your car in for service they read out the ECU to detect chip tuning, and your VIN gets flagged in their system if it has been modified. So if at some point in the future you make a warranty claim, you are SOL.

Then there's also the technical barriers they're putting up, locking them down so unauthorized software can't be flashed to them (much like Apple's iphone and ipad crap).

It still sucks that features are physically present in the car, but you have to pay to unlock them.

Yeah I'd say that sounds recent enough, but it's still possible that there's some obscure bios bug you're hitting.

You may also want to check if your bios is up-to-date.

My 5900x had some spontaneous crashes and reboots when I just got it, a bios update eventually resolved it. This was around the time zen3 was just out, and there were still quite a few bugs in AMD's AGESA library, which is included in the motherboard's bios.

Many motherboards still ship with an ancient bios, or just have been sitting on a shelf somewher for a very long time with an old bios. So if you have never touched your bios, check that first.

in the office ... you can still hear what’s going on whilst listening

That sounds like an anti-feature. In the office I use my headphones because I don't want to hear the noise around me.

You're welcome!

Lots of bugs around screen blanking in plasma 6 it seems...

I also ran into this one: https://bugs.kde.org/show_bug.cgi?id=481308

and this one: https://bugs.kde.org/show_bug.cgi?id=483163

There’s still another odd behavior with ./ ! When extracted it will overwrite the permission/owner to the current directory source

Only if ./ itself is included in the tar file as a directory.

If my tar contains the following folder ./home/user/ and I extract it in my current home folder (which would be kinda stupid but It happens) this will overwrite the home folder

No it will not. It will extract your files to /home/user/home/user, so a nested home directory inside your home directory (yo dawg).

The man page section you quote is about absolute paths. That is, paths that start with a / without a leading dot. They indeed can be dangerous, but by default (GNU) tar strips absolute paths and will throw a warning like:

 `

    
# tar -cf test.tar /etc/hosts
                   ^leading slash
tar: Removing leading `/' from member names

# tar -tvf test.tar
-rw-r--r-- root/root       184 2022-12-08 20:27 etc/hosts
                                               ^no leading slash

`
  

this kind of structure could actually be dangerous

citation needed

I mean, tarbombs exist, but not because of the leading ./ as far as I know and they're usually specifically crafted tar files to create harm, not something you accidentally create yourself while tarring stuff.

Has anyone a good explanation why the second way is bad practice? Or not recommended?

They're functionally the same. It's like the difference between mkdir somedir and mkdir ./somedir. The leading ./ is not necessary, so I guess you could consider it less clean, but I wouldn't lose any sleep over it.

and if I make some server-like setup with multiple drives, I’d go with some kind of raid with redundancy instead of just stitching the drives together (or mb yolo and raid 0).

Server setups are usually virtual machines nowadays, with virtual disks (i.e. vmdk or qcow2 files in a storage pool). Stitching virtual disks together is valid in this case because redundancy is handled on another level, invisible to the vm.

Yes, the terse Unix version, which needs to be supported for compatibility, and the more readable GNU long option

Depends. Is it GNU tar, BSD tar or some old school Unix tar?

Double hyphen "long options" are a typical GNU thing.