A NOTE has been added to this issue. 
====================================================================== 
https://www.austingroupbugs.net/view.php?id=1827 
====================================================================== 
Reported By:                nrk
Assigned To:                
====================================================================== 
Project:                    Issue 8 drafts
Issue ID:                   1827
Category:                   Shell and Utilities
Type:                       Enhancement Request
Severity:                   Objection
Priority:                   normal
Status:                     New
Name:                       NRK 
Organization:                
User Reference:              
Section:                    compress(1) utility 
Page Number:                n/a 
Line Number:                n/a 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2024-04-15 03:23 UTC
Last Modified:              2024-04-17 00:10 UTC
====================================================================== 
Summary:                    Standardize gzip(1) cli interface instead of adding
it to compress(1)
====================================================================== 

---------------------------------------------------------------------- 
 (0006757) steffen (reporter) - 2024-04-17 00:10
 https://www.austingroupbugs.net/view.php?id=1827#c6757 
---------------------------------------------------------------------- 
Then the issue should be closed, because why standardizing yet another
compression format that will see less and lesser usage because of its
properties.
It is *much* worse for text files, and it is *much* worse for balls as of
pax(1) (and if via tar(1)).
In my opinion, of course.
Plain is only that compress(1) is not even installed anymore on a lot of
boxes.
*And* that i agree that placing new algorithms under a compress(1)
interface does seem to not make any sense.
And that a the xxhash64 of BTRFS or zstd (but even xxhash32) is still
better than CRC-32, if you go the mathematical approach, people go away
from CRC32, they do, standards do, too, and even though i know that SHA-1
and MD5 are still used for checksumming even if they are broken
cryptographically. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2024-04-15 03:23 nrk            New Issue                                    
2024-04-15 03:23 nrk            Name                      => NRK             
2024-04-15 03:23 nrk            Section                   => compress(1) utility
2024-04-15 03:23 nrk            Page Number               => n/a             
2024-04-15 03:23 nrk            Line Number               => n/a             
2024-04-15 03:24 nrk            Issue Monitored: nrk                         
2024-04-16 05:57 dannyniu       Note Added: 0006752                          
2024-04-16 05:58 dannyniu       Note Edited: 0006752                         
2024-04-16 18:39 steffen        Note Added: 0006753                          
2024-04-16 22:51 nrk            Note Added: 0006754                          
2024-04-16 23:03 nrk            Note Added: 0006755                          
2024-04-16 23:32 oguzismailuysalNote Added: 0006756                          
2024-04-17 00:10 steffen        Note Added: 0006757                          
======================================================================


  • [Issue 8 dra... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to