• 10 Posts
  • 39 Comments
Joined 3 years ago
cake
Cake day: July 16th, 2023

help-circle
  • It can only do the impressive numbers after you give it a schema for the data, and the data has to be structured in a way that follows a rigid schema, so it’s not magic.

    OpenZL compresses data into a self-describing wire format, any configuration of which can be decompressed by a universal decoder. OpenZL’s design enables rapid development of tailored compressors with minimal code; its universal decoder eliminates deployment lag; and its investment in a well-vetted standard component library minimizes security risks.

    The freedom afforded by OpenZL’s graph model is a double-edged sword: the capability it offers comes at the cost of a combinatorial explosion of choices that must be made—namely which components to use and how to compose and configure them. There is no one-size-fits-all compressor

    Webassembly for compression or something, but it’s made by the zstd people so maybe it will turn out to be magic eventually.

    On one hand the x2.06 ratio for the SAO data is extremely good, zpaq and paq8px are 50x and 10000x slower at encoding and decoding and still can’t even reach that ratio (I didn’t try even more extreme compression, paq8px -8 already took 20 minutes).

    On the other hand,

    enwik: A Case Study Where OpenZL Performs Poorly

    We present this case study to show that OpenZL is not a magic bullet for all use cases. The shortcomings are twofold. First, the standard codec library can achieve good results for many datasets, but is not currently optimized for human text. Second, English text is a highly compressible format for which domain- specific transformations are especially useful. xwrt combines multiple such transformations to achieve its results. With this in mind, we are optimistic that porting text-specific codecs and text parsing will improve the performance of OpenZL compressors in this domain.















  • The incredible thing is this is actually the result of an explicit design decision.

    The compiler accepts most GCC flags. Unrecognized flags (e.g., architecture- specific -m flags, unknown -f flags) are silently ignored so ccc can serve as a drop-in GCC replacement in build systems.

    They’re so committed to vibing that they’d prefer if the compiler just does random shit to make it easier to shove it haphazardly into a build pipeline.




  • maybe they were looking for extra special characters like 🁄 or ⶸ. Who am I kidding, RFC 1738 tells us that literally everything is unsafe and you know, we need to prepare for the inevitable occasion when the password somehow ends up inside an URL.

    The characters “<” and “>” are unsafe because they are used as the delimiters around URLs in free text;
    the quote mark (“”") is used to delimit URLs in some systems.
    The character “#” is unsafe
    The character “%” is unsafe

    It ends up with

    Thus, only alphanumerics, the special characters
    $ - _ . + ! * ’ ( ) ,
    are safe