DigitalJacobin

u/DigitalJacobin@lemmy.ml
7 posts · 37 comments

Recent posts

Recent comments

Feel how you want, but Spotify has a very clear policy on hateful content. And sure, maybe you won't listen to it, but do you know who will? Bigoted psychos that will go out and commit a hate crime. Allowing content like this on a popular platform will lead to hate crimes. There is nothing wrong with private platforms choosing to not platform certain kinds of content and it is entirely within their right.

Spotify has the right to deplatfom hateful content and doing so is the ethical thing to do.

on Please, do not use Brave. · c/privacy · -5 pts · 2y

There are many, many good reasons to not use Brave. Being spyware is not one of those.

Boycott Brave for real reasons like their CEO and owner being a raging anti-gay reactionary or because of their cryptocurrency bs.

However, getting people used to double extensions is one quick way of increasing the success rate of attacks such as the infamous “.pdf.exe” invoice from an email attachment.

Very good point. Though, i would argue that this would be much less of a problem if Windows stopped sometimes hiding file extensions.

I can’t see how Windows’ convention is worse

I don't believe what you're referring to is really a Windows versus Linux/Unix thing.

If I zip a file, it doesn’t matter what it was in a previous life, it’s now a zip - this is also how Unix deals with many filetypes, I’ve never seen a .h264.mp4 file, even though the .mp4 container can actually represent different types of encoding.

I disagree, but i do get what you're saying here. I don't think that example really works though, because a .mp4 file isn't derived from a .h264 file. A .mp4 is a container that may include h264-encoded video, but it may also have a channel with Opus-encoded audio or something. It's apples and oranges.

Also, even though there shouldn't be any technical issues with this on Windows, you can still use a typical short filename suffix if you wish, though i would argue that using the long filename suffix is more expressive. From "tar (computing)" on Wikipedia:

Compressor Long Short
bzip2 .tar.bz2 .tb2, .tbz, .tbz2, .tz2
gzip .tar.gz .taz, .tgz
lzip .tar.lz
lzma .tar.lzma .tlz
lzop .tar.lzo
xz .tar.xz .tx
compress .tar.Z .tZ, .taZ
zstd .tar.zst .tzst

I get the frustration, but Windows is the one that strayed from convention/standard.

Also, i should've asked this earlier, but doesn't Windows also only look at the characters following the last dot in the filename when determining the file type? If so, then this should be fine for Windows, since there's only one canonical file extension at a time, right?

The problem here being that GnuPG does nothing really well.

Could you elaborate? I've never had any issues with gpg before and curious what people are having issues with.

Unfortunately currently there aren’t many options to use AV1 in a very meaningful way; you can encode your own media with it, but that’s about it; you can stream to YouTube, but YouTube will recode to another codec.

AV1 has almost full browser support (iirc) and companies like YouTube, Netflix, and Meta have started moving over to AV1 from VP9 (since AV1 is the successor to VP9). But you're right, it's still working on adoption, but this is moreso just my dreamworld than it is a prediction for future standardization.

So there's a tool called tar that creates an archive (a .tar file. Then theres a tool called zstd that can be used to compress files, including .tar files, which then becomes a .tar.zst file. And then you can encrypt your .tar.zst file using a tool called gpg, which would leave you with an encrypted, compressed .tar.zst.gpg archive.

Now, most people aren't doing everything in the terminal, so the process for most people would be pretty much the same as creating a ZIP archive.

This is the kind of thing i think about all the time so i have a few.

  • Archive files: .tar.zst
    • Produces better compression ratios than the DEFLATE compression algorithm (used by .zip and gzip/.gz) and does so faster.
    • By separating the jobs of archiving (.tar), compressing (.zst), and (if you so choose) encrypting (.gpg), .tar.zst follows the Unix philosophy of "Make each program do one thing well.".
    • .tar.xz is also very good and seems more popular (probably since it was released 6 years earlier in 2009), but, when tuned to it's maximum compression level, .tar.zst can achieve a compression ratio pretty close to LZMA (used by .tar.xz and .7z) and do it faster^1.

      zstd and xz trade blows in their compression ratio. Recompressing all packages to zstd with our options yields a total ~0.8% increase in package size on all of our packages combined, but the decompression time for all packages saw a ~1300% speedup.

  • Image files: JPEG XL/.jxl
    • "Why JPEG XL"
    • Free and open format.
    • Can handle lossy images, lossless images, images with transparency, images with layers, and animated images, giving it the potential of being a universal image format.
    • Much better quality and compression efficiency than current lossy and lossless image formats (.jpeg, .png, .gif).
    • Produces much smaller files for lossless images than AVIF^2
    • Supports much larger resolutions than AVIF's 9-megapixel limit (important for lossless images).
    • Supports up to 24-bit color depth, much more than AVIF's 12-bit color depth limit (which, to be fair, is probably good enough).
  • Videos (Codec): AV1
    • Free and open format.
    • Much more efficient than x264 (used by .mp4) and VP9^3.
  • Documents: OpenDocument / ODF / .odt

    it’s already a NATO standard for documents Because the Microsoft Word ones (.doc, .docx) are unusable outside the Microsoft Office ecosystem. I feel outraged every time I need to edit .docx file because it breaks the layout easily. And some older .doc files cannot even work with Microsoft Word.