5 ms·

Hey, The choice of parameters was solely done to be clear, and not what people used to. -f meaning force is not clear; -w meaning overwrite, seemed like a bett

Hey, The choice of parameters was solely done to be clear, and not what people used to. -f meaning force is not clear; -w meaning overwrite, seemed like a better logical choice, to me. Nice point on -h. Yes, I did not want to go crazy. After all, almost all (CLI) people use pack as `pack ./test/`. Options are for advanced people like you. Most people will use the OS integration that will be published later on. --press=hard is the only option there is. There may be more, but with Pack you do not need to choose a level (like 1..9 with ZIP). Just let Pack do its thing, and you will be happy. Hard Press is there for people who want to pack once and unpack many times (like publishing), and it is worth spending extra time on it. Even then, Pack goes the sane way and does not eat your computer just for a kilobyte or two.

out_of_protocol 3y ago
> Just let Pack do its thing, and you will be happy Well, no. Sometimes i want maximum compression while having a lot of CPU and wall clock time. And sometimes being fast is more important than compression level. Also managing server utilization is needed. Level thing is there for a reason
- OttoCoddo 3y ago
  Then `--press=hard` would be the choice for you.
  - out_of_protocol 3y ago
    This is not a binary choice, actual level of effort is required. I've seen many times people fine tuning compression levels in all kinds of automation scenarios
    - out_of_protocol 3y ago
      Also, zstd covers a lot of ground between super fast compression and good compression ratio https://raw.githubusercontent.com/facebook/zstd/master/doc/images/DCspeed5.png https://raw.githubusercontent.com/facebook/zstd/master/doc/i...
      - OttoCoddo 3y ago
        Thank you for the notes. I am well aware of the levels and Pack uses custom configuration to match its inner design. Maybe more level come, or maybe not. But to be clear, Pack supports any valid Zstandard content, and this levels we are discussing are about Pack CLI chosen for better user experience. Any other client can produce and store any valid content for chose level or configuration, and other clients can read it.
        out_of_protocol 2y ago
        There are many different usecases, and each one have different set of requirements. E.g. - for end-user facing cli: support as much conventions as possible (-v --version, -h --help, other options similar to other compressors), sane defaults - for automatic tasks like making backups via cron: piping, correct exit codes, level of effort configuration, silent modes for reduced logging. Second one is likely to fly first, can be used isolated on company level if file format is stable

out_of_protocol 3y ago

> Just let Pack do its thing, and you will be happy Well, no. Sometimes i want maximum compression while having a lot of CPU and wall clock time. And sometimes being fast is more important than compression level. Also managing server utilization is needed. Level thing is there for a reason

OttoCoddo 3y ago
Then `--press=hard` would be the choice for you.
- out_of_protocol 3y ago
  This is not a binary choice, actual level of effort is required. I've seen many times people fine tuning compression levels in all kinds of automation scenarios
  - out_of_protocol 3y ago
    Also, zstd covers a lot of ground between super fast compression and good compression ratio https://raw.githubusercontent.com/facebook/zstd/master/doc/images/DCspeed5.png https://raw.githubusercontent.com/facebook/zstd/master/doc/i...
    - OttoCoddo 3y ago
      Thank you for the notes. I am well aware of the levels and Pack uses custom configuration to match its inner design. Maybe more level come, or maybe not. But to be clear, Pack supports any valid Zstandard content, and this levels we are discussing are about Pack CLI chosen for better user experience. Any other client can produce and store any valid content for chose level or configuration, and other clients can read it.
      - out_of_protocol 2y ago
        There are many different usecases, and each one have different set of requirements. E.g. - for end-user facing cli: support as much conventions as possible (-v --version, -h --help, other options similar to other compressors), sane defaults - for automatic tasks like making backups via cron: piping, correct exit codes, level of effort configuration, silent modes for reduced logging. Second one is likely to fly first, can be used isolated on company level if file format is stable