OCI is an antiquated format, not fit for modern security requirements

I'm tired of writing comments on LWN.net because simply I don't get where those biased points come from.
EROFS core on-disk format (e.g. used for ComposeFS) is much simple, flexible and efficient:

- It doesn't have an old-styled centralized on-disk inode table as SquashFS like extX and minix; In fact, EROFS on-disk inodes can be placed on disk anywhere if needed as modern fses like XFS, BtrFS, etc., therefore it's quite easy to do incremental builds (e.g. add new inodes and data) without expending and rewriting a new inode table entirely;

- It doesn't have extra on-disk directory indices to speed up inode lookup "https://dr-emann.github.io/squashfs/squashfs.html#_directory_index" for large directories since without those directory indices, SquashFS directory can only search dirents in a simple linear way due to its on-disk dirent design; Unlike SquashFS, EROFS dirents are still simple and strictly sorted in alphabetical order and can do binary search natively. I've tested some AI datasets where each directory contains millions of files, and EROFS random access performance is even better than SOTA EXT4.

- The core on-disk format just have three parts: super-block, 32 or 64-byte inodes (instead of one layout for each type of inodes to save seamless space) and dirents: https://erofs.docs.kernel.org/en/latest/core_ondisk.html. I have no idea where is "more space for potential issues" because it just behaves as a fsblock-aligned archive format;

- EROFS uncompressed data is strictly fsblock-based which means data can be directly fetched via DMA to page cache without extra post-processing, instead of SquashFS unaligned data even if it supports uncompressed mode but still need a memcpy to handle unalignment; thus, EROFS also supports advanced runtime features natively like FSDAX (XIP), direct I/Os, etc.