There are too many of these comics, I'll make one to be the true comic response and unite all the different competing standards

There is also https://github.com/typst/typst/

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.

That's awful, we should design something that covers both use cases!

There are now 3 competing standards.

There are programs (LyX, TexMacs) that implement WYSIWYG for LaTeX, TexMacs is exceptionally good. I don't know about the standards, though.

Another problem with LaTeX and most of the other document formats is that they are so bloated and depend on many other tasks that it is hardly possible to embed the tool into a larger document. That's a bit of criticism for UNIX design philosophy, as well. And LaTeX code is especially hard to make portable.

There used to be a similar situation with PDFs, it was really hard to display a PDF embedded in application. Finally, Firefox pdf.js came in and solved that issue.

The only embedded and easy-to-implement standard that describes a 'document' is HTML, for now (with Javascript for scripting). Only that it's not aware of page layout. If only there's an extension standard that could make a HTML page into a document...

.tar is pretty bad as it lacks in index, making it impossible to quickly seek around in the file.

.tar.pixz/.tpxz has an index and uses LZMA and permits for parallel compression/decompression (increasingly-important on modern processors).

https://github.com/vasi/pixz

It's packaged in Debian, and I assume other Linux distros.

Only downside is that GNU tar doesn't have a single-letter shortcut to use pixz as a compressor, the way it does "z" for gzip, "j" for bzip2, or "J" for xz (LZMA); gotta use the more-verbose "-Ipixz".

Also, while I don't recommend it, IIRC gzip has a limited range that the effects of compression can propagate, and so even if you aren't intentionally trying to provide random access, there is software that leverages this to hack in random access as well. I don't recall whether someone has rigged it up with tar and indexing, but I suppose if someone were specifically determined to use gzip, one could go that route.

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.

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.

AV1 can do lossy video as well as lossless video.

Different ways of compressing the initial .tar archive.

Ziptarar?

Not just that. RAR also has recovery records.

why not gzip?

The only annoying thing is that the extension for zstd compression is zst (no d). Tar does not recognize a zstd extension, only zst is automatically recognized and decompressed. Come on!

This comment didn't age well.

Unless you have explicitly digitally-signed the PDF, it's not immutable. It's maybe more-annoying to modify, but one shouldn't rely on that.

And there are ways to digitally-sign everything, though not all viewing software has incorporated signature verification.

I’m not sure if they were ever designed to be immutable, but that’s what a lot of people use it for because it’s harder to edit them. But there are programs that can edit PDFs. The main issue is I’m not aware of any free ones, and a lot of the alternatives don’t work as well as Adobe Acrobat which I hate! It’s always annoying at work when someone gets sent a document that they’re expected to edit and they don’t have an Acrobat license!

No, it's too preserve formatting when distributed. Editing is absolutely possible, always were, it's just annoying to parse the structure when trying to preserve the format as you make changes

No, although there's probably a culture or convention around that.

Originally the idea was that it's a format which can contain fonts and other things so it will be rendered the same way on different devices even if those devices don't have those fonts installed. The only reason it's not commonly editable that I'm aware of is that it's a fairly arcane proprietary spec.

Now we have the openspec odt which can embed all the things, so pdf editing just doesn't really seem to have any support.

The established conventions around pdfs do kind of amaze me. Like contracts get emailed for printing & signing all the time. In many cases it would be trivial to edit the pdf and return your edited copy which the author is unlikely to ever read.

What do you use?

Acrobat Reader is actually great for filling out forms.

Even if the "pdf" is actually just a potato quality photo of what was at some time a form, you can still fill it out in Acrobat Reader.

Generally in windows I prefer sumatra pdf as a reader, but I keep acrobat around for this purpose.

@dinckelman @Supermariofan67 I think you mean unsecure. It doesn't feel unsure of itself. 😁

Zip has terrible compression ratio compared to modern formats, it's also a mess of different partially incompatible implementations by different software, and also doesn't enforce utf8 or any standard for that matter for filenames, leading to garbled names when extracting old files. Its encryption is vulnerable to a known-plaintext attack and its key-derivation function is very easy to brute force.

Rar is proprietary. That alone is reason enough not to use it. It's also very slow.

Both slower and worse at compression at all its levels.

Big file size for rather bad audio quality.

It's a 30 year old format, and large amounts of research and innovation in lossy audio compression have occurred since then. Opus can achieve better quality in like 40% the bitrate. Also, the format is, much like zip, a mess of partially broken implementations in the early days (although now everyone uses LAME so not as big of a deal). Its container/stream format is very messy too. Also no native tag format so it needs ID3 tags which don't enforce any standardized text encoding.

However, it is very patent encumbered and therefore wouldn't make for a good standard.

At both algorithms' highest levels, xz seems to be on average a few percent better at compression ratio, but zstd is a bit faster at compression and much much faster at decompression. So if your goal is to compress as much as possible without regard to speed at all, xz -9 is better, but if you want compression that is almost as good but faster, zstd --long -19 is the way to go

At the lower compression presets, zstd is both faster and compresses better

GNOME introduced its support in version 45, AFAIK there isn't a stable distro release yet that ships it.

Unfortunately, adoption has been slow and Alliance for Open Media are pushing back somewhat (especially Google¹, who leads the group) in favor of their inferior .avif format.

AVIF is slower, has a way smaller maximum resolution and doesn't support progressive decoding as well as lossless JPEG recompression.

To add to that. Configuration file formats...just pick a standard one, do not write your own.

And while we are at it, if there is even a remote chance that you have a "we will do everything declaratively" idea, just use an existing programming language for your file format instead of painfully growing some home-grown add-ons to your declarative format over the next decade or two because you were wrong about only needing a declarative format.

I’ll take “what’s that file format for $300 please”

Markdown, CommonMark, .rst formats are good for printing basic rich text for technical documentation and so on, when text styling is made by an external application and you don't care about reproducible layout.

But you also want to make custom styles (font size, text alignment, colours), page layout (paper format, margin size, etc.) and make sure your document is reproducible across multiple processing applications, that the layout doesn't break, authoring tools, maybe even some version control, etc. This is when it strikes you bad.

Markdown misses checkboxes anywhere, especially in tables.

But markdown is just good. It's just writing text as normal basically

You can convert Markdown to a number of formats with pandoc, if you want to author in Markdown and just distribute in some other format.

Not going to work if you need to collaborate with other people, though.

They're basically zip files with a standardized metadata file to determine chapter order, index page, … and every chapter is a html file.

I am surprised no one mentioned HCL yet. It's just as sane as toml but it is also properly nestable, like yaml, while being easily parsable and formattable. I wish it was used more as a config language.

USD is more for scenes than models. It's meant primarily for stuff like 3dsmax and blender, and is far more complex than gltf.

It's also not really supported everywhere. Pretty much every game engine lacks support for USD, while most (except unity for some reason) have at least some gltf support.

USD is also, at least as far as I'm concerned, dead in the water. I have never encountered a single USD file in the wild, though that might just be because I mainly only work in blender and godot.

I'm not against USD, and I'd love to see it get some more love, but it serves a different purpose than gltf.

those are media formats, not containers.

A mp4 file contains media in, for example, h264 and AAC codec, which is the combined for playback. It is not a codec itself.

GitLab/Hub obviously. Also it doesn't matter since I don't need to compile it to read it.

You compile your markdown and don't read it raw? /s

Oh I'm not brave enough for politics.

asciidoc lost me because it's not a markdown superset. Why invent yet another way of marking headlines?

Also GitLab/Hub markdown is the standard and I don't think we need another.

If you were to format the drive with extra and then copy something to it from Linux - if you try open it on another Linux machine (eg you distro hop after this event) it won't open the file because your aren't the owner.

Then you have to jump though hoops trying to make yourself the owner just so you can open your own file.

I learnt this the hard way so I just use exFAT and it all works.

Well, okay, let me rephrase that. It would be nice if the B2C communication used something like that too.

Woah neat

whats the file extension and whats the category name, compiling list in body

org mode? whats rhe file extension

God damnit. I wrote an answer and it disappeared a while after pressing reply. I am lazy to rewrite it and my eyes are sore.

Anyway, I am too dumb to actually understand I/Q samples. It stands for In-Phase and Quadrature, they are 90° out of phase from each other. That's somehow used to reconstruct a signal. It's used in different areas. For me it's useful to record raw RF signals from software defined radio (SDR).
For example, with older, less secure systems, you could record signal from someone's car keyfob, then use a Tx-capable SDR to replay it later. Ta-da! Replay attack. You unlocked someone's car.
In a better way, you could record raw signal from a satellite to later demodulate and decode it, if your computer isn't powerful enough to do it in real-time.

If you want an example, you can download DAB+ radio signal recording here: https://www.sigidwiki.com/wiki/DAB%2B and then replay it in Welle.io (available as Appimage) if it's in compatible format. I haven't tested it.

Nice, hadn't seen this before. From the looks of the Ardour forum there is nobody currently looking at implementing the forum but they seem open to it. I would contribute but I only know python so probably not much use. I could write a ardour-dawproject translator in python but seems a bit pointless if someone goes and creates a proper implementation at some point anyway

except XML xD

OTDR: Optical Time Domain Reflectometry
SOR: Standard OTDR Record
XML: Extensible Markup Language

.sor files are a mess, poorly standardized, too restrictive as a format, and every manufacturer makes their own proprietary extensions.

Category: OTDR measurement results
File extension: .xml or something entirely new

On top of that, 20 kHz is quite the theoretical upper limit.

Most people, be it due to aging (affects all of us) or due to behaviour (some way more than others), can't hear that far up anyway. Most people would be suprised how high up even e.g. 17 kHz is. Sounds a lot closer to very high pitched "hissing" or "shimmer", not something that's considered "tonal".

So yeah, saying "oh no, let me have my precious 30 kHz" really is questionable.

At least when it comes to listening to finished music files. The validity of higher sampling frequencies during various stages in the audio production process is a different, way less questionable topic,

That is not what 96khz means. It doesn't just mean it can store frequencies up to that frequency, it means that there are 96,000 samples every second, so you capture more detail in the waveform.

Having said that I'll give anyone £1m if they can tell the difference between 48khz and 96khz. 96khz and 192khz should absolutely be used for capture but are absolutely not needed for playback.

because if you use a 40 kHz signal to "draw" a 10 kHz wave, the wave will have only four "pixels", so all the high frequencies have very low fidelity

I, for one, label my apple crates as oranges.

winebin="wine"
if file "$1" | grep 64-bit; then
    winebin="wine64"
fi

printf '%s %q $@ || exit $?' "$winebin" "$1" > "$1.sh"
chmod +x "$1.sh"