Just going to leave this xkcd comic here.
Yes, you already know what it is.
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
Just going to leave this xkcd comic here.
Yes, you already know what it is.
One could say it is the standard comic for these kinds of discussions.
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.
Markdown, asciidoc, restructuredtext are kinda like simple alternatives to LaTeX
It is unbelievable we do not have standard document format.
What's messed up is that, technically, we do. Originally, OpenDocument was the ISO standard document format. But then, baffling everyone, Microsoft got the ISO to also have .docx
as an ISO standard. So now we have 2 competing document standards, the second of which is simply worse.
I was too young to use it in any serious context, but I kinda dig how WordPerfect does formatting. It is hidden by default, but you can show them and manipulate them as needed.
It might already be a thing, but I am imagining a LaTeX-based standard for document formatting would do well with a WYSIWYG editor that would hide the complexity by default, but is available for those who need to manipulate it.
This is the kind of thing i think about all the time so i have a few.
.tar.zst
.zip
and gzip
/.gz
) and does so faster..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.
JPEG XL
/.jxl
.jpeg
, .png
, .gif
).AV1
.mp4
) and VP9^3.OpenDocument / ODF / .odt
.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.
.tar
is pretty bad as it lacks in index, making it impossible to quickly seek around in the file. The compression on top adds another layer of complication. It might still work great as tape archiver, but for sending files around the Internet it is quite horrible. It's really just getting dragged around for cargo cult reasons, not because it's good at the job it is doing.
In general I find the archive situation a little annoying, as archives are largely completely unnecessary, that's what we have directories for. But directories don't exist as far as HTML is concerned and only single files can be downloaded easily. So everything has to get packed and unpacked again, for absolutely no reason. It's a job computers should handle transparently in the background, not an explicit user action.
Many file managers try to add support for .zip
and allow you to go into them like it is a folder, but that abstraction is always quite leaky and never as smooth as it should be.
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.
It was originally rar because it’s so easy to separate into multiple files. Now you can do that in other formats, but the legacy has stuck.
.tar.zstd
all the way IMO. I've almost entirely switched to archiving with zstd, it's a fantastic format.
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)
The existence of zip, and especially rar files, actually hurts me. It's slow, it's insecure, and the compression is from the jurassic era. We can do better
Literally any file format except PDF for documents that need to be edited. Fuck Adobe and fuck Acrobat
Isn't the point of PDF that it can't (or, perhaps more accurately, shouldn't) be edited after the fact? It's supposed to be immutable.
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.
oh it's x, not x... i hate our timeline
JPEG-XL for rasterized images.
I agree.
I especially love that it addresses the biggest pitfall of the typical "fancy new format does things better than the one we're already using" transition, in that it's specifically engineered to make migration easier, by allowing a lossless conversion from the dominant format.
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.
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.
To chase this - converting to json or another standardized format in every single case where someone is tempted to write their own custom parser. Never write custom parsers kids, they're an absolutely horrible time-suck and you'll be fixing them quite literally forever as you discover new and interesting ways for your input data to break them.
Edit: it doesn't have to be json, I really don't care what format you use, just pick an existing data format that uses a robust, thoroughly tested, parser.
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.
Data output from manufacturing equipment. Just pick a standard. JSON works. TOML / YAML if you need to write as you go. Stop creating your own format that’s 80% JSON anyways.
I don't give a shit which debugging format any platform picks, but if they could each pick one that every emulator reads and every compiler emits, that'd be fucking great.
Even more simpler, I'd really like if we could just unify whether or not $
is needed for variables, and pick #
or //
for comments. I'm sick of breaking my brain when I flip between languages because of these stupid nuance inconsistencies.
I'd setup a working group to invent something new. Many of our current formats are stuck in the past, e.g. PDF or ODF are still emulating paper, even so everybody keeps reading them on a screen. What I want to see is a standard document format that is build for the modern day Internet, with editing and publishing in mind. HTML ain't it, as that can't handle editing well or long form documents, EPUB isn't supported by browsers, Markdown lacks a lot of features, etc. And than you have things like Google Docs, which are Internet aware, editable, shareable, but also completely proprietary and lock you into the Google ecosystem.
~~XML for machine-readable data because I live to cause chaos~~
Either markdown or Org for human-readable text-only documents. MS Office formats and the way they are handled have been a mess since the 2007 -x versions were introduced, and those and Open Document formats are way too bloated for when you only want to share a presentable text file.
While we're at it, standardize the fucking markdown syntax! I still have nightmares about Reddit's degenerate four-space-indent code blocks.
Man, I'd love if markdown was more widely used, it's pretty much the perfect format for everything I do
I'd like an update to the epub ebook format that leverages zstd compression and jpeg-xl. You'd see much better decompression performance (especially for very large books,) smaller file sizes and/or better image quality. I've been toying with the idea of implementing this as a .zpub book format and plugin for KOReader but haven't written any code for it yet.
.opus for lossy music, .flac for lossless music, .png for image files, .mkv for video
All of them are OK, except mkv is less a file type and more a container. What should be specified is the code for video, which for most things I'd say AV1, but high res movies might not be the most suitable. Throw in opus for the audio track, and you can use mkv, but might as well use webm anyways since it's more clear what's behind it. (though can still be other things)
I'd also add that jxl should be the standard for lossy images. Better than jpg. And you want something other than png for massive images because that quickly gets costly in terms of size due to png being lossless.
.gltf/.glb for models. It's way less of a headache than .obj and .dae, while also being way more feature rich than either.
Either that or .blend, because some things other than blender already support it and it'd make my life so much easier.
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.
Markdown for all rich text that doesn't need super fancy shit like latex
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.