Linux

Just going to leave this xkcd comic here.

Yes, you already know what it is.

Open Document Standard (.odt) for all documents. In all public institutions (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.

Actually, IMHO, there should be some better alternative to .odt as well. Something more out of a declarative/scripted fashion like LaTeX but still WYSIWYG. LaTeX (and XeTeX, for my use cases) is too messy for me to work with, especially when a package is Byzantine. And it can be non-reproducible if I share/reuse the same document somewhere else.

Something has to be made with document files.

zip or 7z for compressed archives. I hate that for some reason rar has become the defacto standard for piracy. It's just so bad.

The other day I saw a tar.gz containing a multipart-rar which contained an iso which contained a compressed bin file with an exe to decompress it. Soooo unnecessary.

Edit: And the decompressed game of course has all of its compressed assets in renamed zip files.

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
  • @raubarno@lemmy.ml says it best here. .odt is simply a better standard than .docx.

  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.

I wish there was a more standardized open format for documents. And more people and software should use markdown/.md because you just don't need anything fancier for most types of documents.

Ogg Opus for all lossy audio compression (mp3 needs to die)

7z or tar.zst for general purpose compression (zip and rar need to die)

SQLite for all “I’m going to write my own binary format because I is haxor” jobs.

There are some specific cases where SQLite isn’t appropriate (streaming). But broadly it fits in 99% of cases.

I don't know what to pick, but something else than PDF for the task of transferring documents between multiple systems. And yes, I know, PDF has it's strengths and there's a reason why it's so widely used, but it doesn't mean I have to like it.

Additionally all proprietary formats, specially ones who have gained enough users so that they're treated like a standard or requirement if you want to work with X.

JPEG-XL for rasterized images.

https://jpegxl.info/why-jxl.html

Resume information. There have been several attempts, but none have become an accepted standard.

When I was a consultant, this was the one standard I longed for the most. A data file where I could put all of my information, and then filter and format it for each application. But ultimately, I wanted to be able to submit the information in a standardised format - without having to re-enter it endlessly into crappy web forms.

I think things have gotten better today, but at the cost of a reliance on a monopoly (LinkedIn). And I'm not still in that sort of job market. But I think that desire was so strong it'll last me until I'm in my grave.

JPEG XL for images because it compresses better than JPEG, PNG and WEBP most of the time.

XZ because it theoretically offers the highest compression ratio in most circumstances, and long decompression time isn't really an issue when the alternative is downloading a larger file over a slow connection.

Config files stored as serialized data structures instead of in plain text. This speeds up read times and removes the possibility of syntax or type errors. Also, fuck JSON.

I wish there were a good format for typesetting. Docx is closed and inflexible. LaTeX is unreadable, inefficient to type and hard to learn due to the inconsistencies that arise from its reliance on third-party packages and its lack of guidelines for their design.

Markdown for all rich text that doesn't need super fancy shit like latex

matroska for media, we already have MKA for audio and MKV for video. An image container would be good too.

mp4 is more prone to data loss and slower to parse, while also being less flexible, despite this it seems to be a sort of pseudo standard.

(MP4, M4A, HEIF formats like heic, avif)

UTF-8 for plain text, trying to figure out the encoding, especially with older files/equipment/software is super annoying.

i'd like there to be a way to standardise midi info in plugins for music