It doesn't make sense to wrap modern data in a 1979 format, introducing .ptar(plakar.io)
plakar.io
It doesn't make sense to wrap modern data in a 1979 format, introducing .ptar
https://plakar.io/posts/2025-06-27/it-doesnt-make-sense-to-wrap-modern-data-in-a-1979-format-introducing-.ptar/
11 comments
Great work! What I feel skeptical about, is the fact that plakar is not self-contained, but has a dependency. That gives me a pause. What I’d love to see is one single binary that I can just install and use.
Author here, plakar is a single binary, unsure I understand what it is you’d prefer, a ptar specific executable?
Thanks for replying. Maybe I misunderstood something. The way I saw it, I can not use plakar without having to install Go first (the dependency). And that bothers me a bit.
Let me explain my reasoning. Suppose I made an .ptar archive today, put it on a USB stick, threw that in a vault and forgot about it. Ten years down the road I want to restore that archive. But the .ptar file alone is useless without the plakar tool. So I have to install plakar first. Ideally plakar should sit on that USB stick, right next to the archive, ready to be installed. But plakar is dependent on Go, so I have to hunt Go first. And who knows what the state of Go will be ten years down the road. The .ptar file that I made today may end up unusable ten years later, because Go evolved in some unpredictable way.
Let me explain my reasoning. Suppose I made an .ptar archive today, put it on a USB stick, threw that in a vault and forgot about it. Ten years down the road I want to restore that archive. But the .ptar file alone is useless without the plakar tool. So I have to install plakar first. Ideally plakar should sit on that USB stick, right next to the archive, ready to be installed. But plakar is dependent on Go, so I have to hunt Go first. And who knows what the state of Go will be ten years down the road. The .ptar file that I made today may end up unusable ten years later, because Go evolved in some unpredictable way.
oh, that's not meant to stay that way.
first, we're going to release pre-built binaries for various platforms with our next stable release which will remove the need to install a go runtime as you'll have a standalone native executable for plakar / ptar.
then, the format is open and we'll publish a friendlier documentation should someone want to implement their own builder/reader.
finally, it's likely we'll publish a library + standalone executable in C, so that people can easily implement a binding to their favourite language and/or have a small executable in a language that traverses the decades :-)
first, we're going to release pre-built binaries for various platforms with our next stable release which will remove the need to install a go runtime as you'll have a standalone native executable for plakar / ptar.
then, the format is open and we'll publish a friendlier documentation should someone want to implement their own builder/reader.
finally, it's likely we'll publish a library + standalone executable in C, so that people can easily implement a binding to their favourite language and/or have a small executable in a language that traverses the decades :-)
> a standalone native executable for plakar / ptar.
Great, that is exactly what I was missing! Thank you for your great work.
Great, that is exactly what I was missing! Thank you for your great work.
This is really neat... plakar itself looks like an awesome backup tool. We use Borg now but I'll be testing this out.
A truly fascinating article. Welcome to the 21st century. :-)
So another WIM like format?
Not exactly, if WIM is a complete snapshot of a Windows disk ready to be restored on an identical machine,
.ptar is a self-contained capsule holding successive, encrypted, deduplicated, and verifiable versions of any dataset, portable and usable across different environments.