• Fmail Compression and Decompression

    From Zazz@1:124/5014 to All on Fri Aug 18 17:19:02 2023
    What are values to enter in fmail for zip compression an decompression
    It came only with the arc defined and nothing else

    Ruben Figueroa aka Zazz
    Mystic Prison Board Sysop
    telnet://pbmystic.rdfig.net:24
    Web: www.rdfig.net

    ... As a matter of fact, it IS a banana in my pocket!

    --- Mystic BBS v1.12 A49 2023/03/14 (Windows/32)
    * Origin: Mystic Prison*Mesquite Tx*pbmystic.rdfig.net:24 (1:124/5014)
  • From Wilfred van Velzen@2:280/464 to Zazz on Sat Aug 19 12:21:33 2023
    Hi Zazz,

    On 2023-08-18 17:19:02, you wrote to All:

    What are values to enter in fmail for zip compression an decompression
    It came only with the arc defined and nothing else

    I tested this, and you seem to be right and found a bug... :-( ;-)

    These are the default values that are in the source and which are supposed to be set when you run FConfig for the first time without a fmail.cfg file present:

    arc32 "PKArc.Com -a"
    zip32 "PKZip.Exe -ex"
    lzh32 "LHA.Exe a /m /o"
    pak32 "Pak.Exe a /ST /P /WN"
    zoo32 "Zoo.Exe aP:"
    arj32 "ARJ.Exe a -e -u -y"
    sqz32 "SQZ.Exe a /p3"
    uc232 "UC.Exe a"
    rar32 "RAR.Exe a -y -s -m5 -ep -std -cfg-"
    jar32 "JAR.Exe a -y"

    unArc32 "PKXArc.Com -r"
    unZip32 "PKUnzip.Exe -o"
    unLzh32 "LHA.Exe e /cm"
    unPak32 "PAK.Exe E /WA"
    unZoo32 "Zoo.Exe eO"
    unArj32 "ARJ.Exe e -c -y"
    unSqz32 "SQZ.Exe e /o1"
    unUc232 "UC.Exe e"
    unRar32 "RAR.Exe e -y -std -cfg-"
    unJar32 "JAR.Exe e -y"

    But these are the defaults from the DOS era. I currently use the infozip versions, with these command lines:

    zip -jq9
    unzip -ojq %a -d %f

    These work on both Windows and Linux.


    Bye, Wilfred.

    --- FMail-lnx64 2.2.0.0
    * Origin: FMail development HQ (2:280/464)
  • From Tommi Koivula@2:221/6 to Wilfred van Velzen on Sun Aug 20 12:58:50 2023
    Hello, Wilfred van Velzen.
    On 19/08/2023 12.21 you wrote:

    Hi Zazz,
    On 2023-08-18 17:19:02, you wrote to All:
    What are values to enter in fmail for zip compression an decompression
    It came only with the arc defined and nothing else
    I tested this, and you seem to be right and found a bug... :-( ;-)
    These are the default values that are in the source and which are supposed to be set when you run FConfig for the first time without a fmail.cfg file present:
    arc32 "PKArc.Com -a"
    zip32 "PKZip.Exe -ex"
    lzh32 "LHA.Exe a /m /o"
    pak32 "Pak.Exe a /ST /P /WN"
    zoo32 "Zoo.Exe aP:"
    arj32 "ARJ.Exe a -e -u -y"
    sqz32 "SQZ.Exe a /p3"
    uc232 "UC.Exe a"
    rar32 "RAR.Exe a -y -s -m5 -ep -std -cfg-"
    jar32 "JAR.Exe a -y"
    unArc32 "PKXArc.Com -r"
    unZip32 "PKUnzip.Exe -o"
    unLzh32 "LHA.Exe e /cm"
    unPak32 "PAK.Exe E /WA"
    unZoo32 "Zoo.Exe eO"
    unArj32 "ARJ.Exe e -c -y"
    unSqz32 "SQZ.Exe e /o1"
    unUc232 "UC.Exe e"
    unRar32 "RAR.Exe e -y -std -cfg-"
    unJar32 "JAR.Exe e -y"
    But these are the defaults from the DOS era. I currently use the infozip versions, with these command lines:

    Time to update the defaults for the next release. :)


    --
    Tommi

    ---
    * Origin: nntp://news.fidonet.fi (2:221/6.0)
  • From Wilfred van Velzen@2:280/464 to Tommi Koivula on Sun Aug 20 13:31:42 2023
    Hi Tommi,

    On 2023-08-20 12:58:50, you wrote to me:

    What are values to enter in fmail for zip compression an
    decompression It came only with the arc defined and nothing else
    I tested this, and you seem to be right and found a bug... :-( ;-)
    These are the default values that are in the source and which are
    supposed to be set when you run FConfig for the first time without a
    fmail.cfg file present: arc32 "PKArc.Com -a" zip32 "PKZip.Exe -ex"
    lzh32 "LHA.Exe a /m /o"
    pak32 "Pak.Exe a /ST /P /WN"
    zoo32 "Zoo.Exe aP:"
    arj32 "ARJ.Exe a -e -u -y"
    sqz32 "SQZ.Exe a /p3"
    uc232 "UC.Exe a"
    rar32 "RAR.Exe a -y -s -m5 -ep -std -cfg-"
    jar32 "JAR.Exe a -y"
    unArc32 "PKXArc.Com -r"
    unZip32 "PKUnzip.Exe -o"
    unLzh32 "LHA.Exe e /cm"
    unPak32 "PAK.Exe E /WA"
    unZoo32 "Zoo.Exe eO"
    unArj32 "ARJ.Exe e -c -y"
    unSqz32 "SQZ.Exe e /o1"
    unUc232 "UC.Exe e"
    unRar32 "RAR.Exe e -y -std -cfg-"
    unJar32 "JAR.Exe e -y"
    But these are the defaults from the DOS era. I currently use the
    infozip versions, with these command lines:

    Time to update the defaults for the next release. :)

    And maybe remove the more obscure ones (pak, zoo, arj, sqz, uc, jar). I wonder if there ever was anyone who used any of those!? ;-)

    Bye, Wilfred.

    --- FMail-lnx64 2.2.0.0
    * Origin: FMail development HQ (2:280/464)
  • From Michiel van der Vlist@2:280/5555 to Wilfred van Velzen on Sun Aug 20 14:46:34 2023
    Hello Wilfred,

    On Sunday August 20 2023 13:31, you wrote to Tommi Koivula:

    Time to update the defaults for the next release. :)

    And maybe remove the more obscure ones (pak, zoo, arj, sqz, uc, jar).
    I wonder if there ever was anyone who used any of those!? ;-)

    These are the only ones still defined in my congfig (W32)

    ZIP PKZip25.Exe -add -nozipextension

    ZIP PKzip25.Exe -ext -nozipextension -over

    For the vast majority of my links Fmail does no compression. It is left to Binkd. For a few links ZIP is used.

    So by all means remove the default for the obscure ones. As long as the user cam still add a seldom used compression method.




    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Wilfred van Velzen@2:280/464 to Michiel van der Vlist on Sun Aug 20 15:08:17 2023
    Hi Michiel,

    On 2023-08-20 14:46:34, you wrote to me:

    Time to update the defaults for the next release. :)

    And maybe remove the more obscure ones (pak, zoo, arj, sqz, uc, jar).
    I wonder if there ever was anyone who used any of those!? ;-)

    MvdV> So by all means remove the default for the obscure ones. As long as
    MvdV> the user cam still add a seldom used compression method.

    I meant remove them completely. If I leave them in, I can just as well keep the defaults...

    But on the other hand, why remove them. It doesn't hurt to keep them, although maybe no one uses them.

    Bye, Wilfred.

    --- FMail-lnx64 2.2.0.0
    * Origin: FMail development HQ (2:280/464)
  • From Michiel van der Vlist@2:280/5555 to Wilfred van Velzen on Sun Aug 20 16:32:03 2023
    Hello Wilfred,

    On Sunday August 20 2023 15:08, you wrote to me:

    And maybe remove the more obscure ones (pak, zoo, arj, sqz, uc,
    jar). I wonder if there ever was anyone who used any of those!? ;-)

    MvdV>> So by all means remove the default for the obscure ones. As
    MvdV>> long as the user cam still add a seldom used compression
    MvdV>> method.

    I meant remove them completely. If I leave them in, I can just as well keep the defaults...

    I was thinking about allowing the user to define his own compression method. A method that is not in the list (yet). There is an option "Custom" but I am unsure how that works. It may be usefull in the unlikely eventy an new compression method pops up that is ideal for use in Fidonet. :)

    But on the other hand, why remove them. It doesn't hurt to keep them, although maybe no one uses them.

    I am in favour of throwing out no longer used stuff. KISS..


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Wilfred van Velzen@2:280/464 to Michiel van der Vlist on Sun Aug 20 16:50:47 2023
    Hi Michiel,

    On 2023-08-20 16:32:03, you wrote to me:

    And maybe remove the more obscure ones (pak, zoo, arj, sqz, uc,
    jar). I wonder if there ever was anyone who used any of those!? ;-)

    MvdV>>> So by all means remove the default for the obscure ones. As
    MvdV>>> long as the user cam still add a seldom used compression
    MvdV>>> method.

    I meant remove them completely. If I leave them in, I can just as well
    keep the defaults...

    MvdV> I was thinking about allowing the user to define his own compression
    MvdV> method. A method that is not in the list (yet). There is an option "Custom"
    MvdV> but I am unsure how that works.

    Packing is simple, just use it... For unpacking you need some kind of detection mechanism. Which incase of FMail is left to the "General Unpack Shell". Which is fed everything that is unknown to FMail itself...

    MvdV> It may be usefull in the unlikely eventy an
    MvdV> new compression method pops up that is ideal for use in Fidonet. :)

    But on the other hand, why remove them. It doesn't hurt to keep them,
    although maybe no one uses them.

    MvdV> I am in favour of throwing out no longer used stuff. KISS..

    That was my idea behind it, when I suggested it.


    Bye, Wilfred.

    --- FMail-lnx64 2.2.0.0
    * Origin: FMail development HQ (2:280/464)
  • From Tommi Koivula@2:221/6 to Wilfred van Velzen on Sun Aug 20 22:14:28 2023
    On 20.08.2023 13:31, Wilfred van Velzen wrote:

    WV>> But these are the defaults from the DOS era. I currently use the
    WV>> infozip versions, with these command lines:

    TK> Time to update the defaults for the next release. :)

    And maybe remove the more obscure ones (pak, zoo, arj, sqz, uc, jar).

    Yep. :)

    I wonder if there ever was anyone who used any of those!? ;-)

    Back in the day when I had millions of points and downlinks, some liked to use rar and uc. Nowadays it should be enough to support zip. :)

    'Tommi

    ---
    * Origin: nntp://news.fidonet.fi (2:221/6.0)
  • From Wilfred van Velzen@2:280/464 to Tommi Koivula on Sun Aug 20 21:54:19 2023
    Hi Tommi,

    On 2023-08-20 22:14:28, you wrote to me:

    WV>> But these are the defaults from the DOS era. I currently use the
    WV>> infozip versions, with these command lines:

    TK> Time to update the defaults for the next release. :)

    And maybe remove the more obscure ones (pak, zoo, arj, sqz, uc, jar).

    Yep. :)

    I wonder if there ever was anyone who used any of those!? ;-)

    Back in the day when I had millions of points and downlinks, some liked to use rar and uc. Nowadays it should be enough to support zip. :)

    I'm still using rar on two links. And outside fido rar is very much in use too. And lha is in use in AmigaNet, because it was and still is the default archiver for the Amiga.

    Bye, Wilfred.

    --- FMail-lnx64 2.2.0.0
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464.112 to All on Mon Aug 21 08:53:58 2023
    Hi All,

    On 19 Aug 23 12:21, Wilfred van Velzen wrote to Zazz:
    about: "Re: Fmail Compression and Decompression":

    What are values to enter in fmail for zip compression an
    decompression It came only with the arc defined and nothing else

    I tested this, and you seem to be right and found a bug... :-( ;-)

    I found and fixed this bug in my development version. And although this is a minor bug, I'll probably make a release, because this is important for new users. This new release might also include new default settings for (un)zip...

    Wilfred.

    --- FMail-W64 2.2.0.0
    * Origin: point@work (2:280/464.112)
  • From Michiel van der Vlist@2:280/5555 to Wilfred van Velzen on Mon Aug 21 09:57:51 2023
    Hello Wilfred,

    On Sunday August 20 2023 21:54, you wrote to Tommi Koivula:

    Back in the day when I had millions of points and downlinks, some
    liked to use rar and uc. Nowadays it should be enough to support
    zip. :)

    I'm still using rar on two links.

    Why? They do not support ZIP?

    And outside fido rar is very much in use too.

    That should be no concern of us. It is (was?) barely used in Fidonet.

    And lha is in use in AmigaNet, because it was and still is the default archiver for the Amiga.

    How many in Amiganet still actually use an Amiga? Hoe many of those do not also have a Fidonet node and support ZIP? ZIP has become de de facto compression standard in Fidonet.

    The problem with keeping all these antiquaria, is that you also have to support it. This will become increasingly difficult when the knowledge evaporates...

    KISS...

    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Tommi Koivula@2:221/6.600 to Wilfred van Velzen on Mon Aug 21 12:13:42 2023
    Hi Wilfred.

    19 Aug 23 12:21, you wrote to Zazz:

    unzip -ojq %a -d %f

    These work on both Windows and Linux.

    '-C' might also be a good thing to add.

    This is what I have in Husky:

    Unpack "unzip -Cjo $a $f -d $p" 0 504b0304

    'Tommi

    ---
    * Origin: ---------> (2:221/6.600)
  • From Tommi Koivula@2:221/6.600 to Wilfred van Velzen on Mon Aug 21 12:27:05 2023
    Hi Wilfred.

    21 Aug 23 12:13, I wrote to you:

    unzip -ojq %a -d %f

    These work on both Windows and Linux.

    '-C' might also be a good thing to add.

    On the other hand, Fmail seems to unpack everything from the arcmail bundle, so it has no effect.

    'Tommi

    ---
    * Origin: ---------> (2:221/6.600)
  • From Wilfred van Velzen@2:280/464 to Michiel van der Vlist on Mon Aug 21 10:40:13 2023
    Hi Michiel,

    On 2023-08-21 09:57:51, you wrote to me:

    Back in the day when I had millions of points and downlinks, some
    liked to use rar and uc. Nowadays it should be enough to support
    zip. :)

    I'm still using rar on two links.

    MvdV> Why? They do not support ZIP?

    Because I can. ;-)

    At the time the choice was made, because rar compressed better. And because it still works there is no reason to change this.

    And outside fido rar is very much in use too.

    MvdV> That should be no concern of us. It is (was?) barely used in Fidonet.

    It means it's a viable choice, where current supported versions are available.

    And lha is in use in AmigaNet, because it was and still is the
    default archiver for the Amiga.

    MvdV> How many in Amiganet still actually use an Amiga?

    Enough...

    MvdV> Hoe many of those do not also have a Fidonet node and support ZIP?
    MvdV> ZIP has become de de facto compression standard in Fidonet.

    Not in AmigaNet.

    MvdV> The problem with keeping all these antiquaria, is that you also have
    MvdV> to support it. This will become increasingly difficult when the
    MvdV> knowledge evaporates...

    This is true for all of Fidonet technology. Keeping this old techniques working is partly what makes it interesting...


    Bye, Wilfred.

    --- FMail-lnx64 2.2.0.0
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464.112 to Tommi Koivula on Mon Aug 21 12:09:01 2023
    Hi Tommi,

    On 21 Aug 23 12:27, Tommi Koivula wrote to Wilfred van Velzen:
    about: "Fmail Compression and Decompression":

    unzip -ojq %a -d %f

    These work on both Windows and Linux.

    '-C' might also be a good thing to add.

    On the other hand, Fmail seems to unpack everything from the arcmail bundle, so it has no effect.

    Indeed -C does nothing incase of FMails unpacking...

    Wilfred.

    --- FMail-W64 2.2.0.0
    * Origin: point@work (2:280/464.112)
  • From Michiel van der Vlist@2:280/5555 to Wilfred van Velzen on Mon Aug 21 14:30:53 2023
    Hello Wilfred,

    On Sunday August 20 2023 16:50, you wrote to me:

    MvdV>> I was thinking about allowing the user to define his own
    MvdV>> compression method. A method that is not in the list (yet).
    MvdV>> There is an option "Custom" but I am unsure how that works.

    Packing is simple, just use it...

    Indeed..

    For unpacking you need some kind of detection mechanism.

    That could be circumveneted by allowing the user to not only specify a compression method for outgoing mail but to als allow the user to specify a decompression method per node. To be used if autodetection fails.

    Or let the user specify the "fingerprint" for a custom compression method. From what I remember it is enough to look at the first two bytes of a compressed file. Fingerprint for ZIP is "PK"

    OTOH... It may not be worth the effort this late in the game...

    Which incase of FMail is left to the "General Unpack Shell". Which is
    fed everything that is unknown to FMail itself...

    GUS... I never used it myself, never had a need for it. It is still under development or is it abandonware like so many other FTN stuff?


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Michiel van der Vlist@2:280/5555 to Wilfred van Velzen on Mon Aug 21 14:45:17 2023
    Hello Wilfred,

    On Monday August 21 2023 10:40, you wrote to me:

    I'm still using rar on two links.

    MvdV>> Why? They do not support ZIP?

    Because I can. ;-)

    Bad argument.

    At the time the choice was made, because rar compressed better. And because it still works there is no reason to change this.

    It is no secret that I am not a member of the "more is better" club. In the POTS age with high cost of data transport "compressed better" was a valid argument. Although even then in the end of the compression evolution the added value was so small that it didn't really matter anymore. Is another one percent of compression efficiency realy worth it.

    In the age of FOIP it has become irrelevant. In addition to thet the trend is to not have mailer/tossers just process uncompressed packets and let binkd do any compression.

    And lha is in use in AmigaNet, because it was and still is the
    default archiver for the Amiga.

    MvdV>> How many in Amiganet still actually use an Amiga?

    Enough...

    Enough to lkep LAH alive?

    MvdV>> Hoe many of those do not also have a Fidonet node and support
    MvdV>> ZIP? ZIP has become de de facto compression standard in
    MvdV>> Fidonet.

    MvdV>> The problem with keeping all these antiquaria, is that you also
    MvdV>> have to support it. This will become increasingly difficult
    MvdV>> when the knowledge evaporates...

    This is true for all of Fidonet technology. Keeping this old
    techniques working is partly what makes it interesting...

    True but at some point one has to make choices that every museum has to make. What do we keep and what do we drop? I see little value in keeping more then one compression method alive for Fidonet. Yes, it is interesting to keep Fidonet alive. But not ALL of the technology that was ever used. Drop some and focus on keeping the rest alive.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Wilfred van Velzen@2:280/464 to Michiel van der Vlist on Mon Aug 21 16:25:23 2023
    Hi Michiel,

    On 2023-08-21 14:30:53, you wrote to me:

    For unpacking you need some kind of detection mechanism.

    MvdV> That could be circumveneted by allowing the user to not only specify a
    MvdV> compression method for outgoing mail but to als allow the user to specify a
    MvdV> decompression method per node. To be used if autodetection fails.

    I don't think that is a good idea...

    MvdV> Or let the user specify the "fingerprint" for a custom compression
    MvdV> method. From what I remember it is enough to look at the first two
    MvdV> bytes of a compressed file. Fingerprint for ZIP is "PK"

    The current detection mechanism in FMail uses up to 7 bytes for the detection, and an offset into the file for some archivers...

    MvdV> OTOH... It may not be worth the effort this late in the game...

    I don't think so either.

    Which incase of FMail is left to the "General Unpack Shell". Which is
    fed everything that is unknown to FMail itself...

    MvdV> GUS... I never used it myself, never had a need for it. It is still under
    MvdV> development or is it abandonware like so many other FTN stuff?

    I can't remember using it. I don't think it's still under development. A quick google only gives me this: https://archive.org/details/GUS_170_ZIP so 1993...

    Bye, Wilfred.

    --- FMail-lnx64 2.2.0.0
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Michiel van der Vlist on Mon Aug 21 16:33:06 2023
    Hi Michiel,

    On 2023-08-21 14:45:17, you wrote to me:

    At the time the choice was made, because rar compressed better. And
    because it still works there is no reason to change this.

    MvdV> It is no secret that I am not a member of the "more is better" club. In the
    MvdV> POTS age with high cost of data transport "compressed better" was a valid
    MvdV> argument. Although even then in the end of the compression evolution the
    MvdV> added value was so small that it didn't really matter anymore. Is another
    MvdV> one percent of compression efficiency realy worth it.

    It was way more then 1%...

    MvdV>>> How many in Amiganet still actually use an Amiga?

    Enough...

    MvdV> Enough to lkep LAH alive?

    Yes.

    MvdV>>> The problem with keeping all these antiquaria, is that you also
    MvdV>>> have to support it. This will become increasingly difficult
    MvdV>>> when the knowledge evaporates...

    This is true for all of Fidonet technology. Keeping this old
    techniques working is partly what makes it interesting...

    MvdV> True but at some point one has to make choices that every museum has to
    MvdV> make. What do we keep and what do we drop? I see little value in keeping
    MvdV> more then one compression method alive for Fidonet. Yes, it is interesting
    MvdV> to keep Fidonet alive. But not ALL of the technology that was ever used.
    MvdV> Drop some and focus on keeping the rest alive.

    Well, in this case it doesn't matter what you think. It's what the AmigaNet users want... ;-)

    And in a museum available "real" space is probably a lot more expensive then available "virtual" space in AmigaNet, which is kind of limitless...


    Bye, Wilfred.

    --- FMail-lnx64 2.2.0.0
    * Origin: FMail development HQ (2:280/464)
  • From Tommi Koivula@2:221/360 to Wilfred van Velzen on Mon Aug 21 20:13:52 2023

    Monday August 21 2023 16:25, Wilfred van Velzen wrote to Michiel van der Vlist:

    Which incase of FMail is left to the "General Unpack Shell". Which is
    fed everything that is unknown to FMail itself...

    MvdV>> GUS... I never used it myself, never had a need for it. It is still
    MvdV>> under development or is it abandonware like so many other FTN stuff?

    I can't remember using it. I don't think it's still under development. A quick
    google only gives me this: https://archive.org/details/GUS_170_ZIP so 1993...

    Got it here in my utils directory! :)

    === Begin OS/2 Clipboard ===
    #### # # #### General Unpack Shell | Copyright (C) 1995 and written by
    # ## # # #### for DOS | Johan Zwiekhorst
    #### #### #### version 1.95 | - ALL RIGHTS RESERVED -
    =====================================¤======================================

    Syntax: GUS «compressed_filespec» [filespec(s)] [target_path] [switch(es)]

    (Entries closed within [] are optional, those within « » are mandatory.)

    «compressed_filespec» : := specifies where to find the compressed file
    (ARC/ARC+/ARJ/DWC/HA/HAP/HPK/HYP/LZH
    /PAK/RAR/SQZ/UC2/ZIP/ZOO & SFXs supported)
    [filespec(s)] : := specifies which files should be unpacked
    [target_path] : := specifies where to store unpacked files
    [switch(es)] : := specifies one or more of the following switches:
    /D : Delete archive after successful unpacking
    /I : Identify only, don't shell out
    /M : unpack Mailarchives (use path for c'file)
    /N : do Not use embedded paths while unpacking
    /P : Print file(s) on standard output device
    /Q : Quiet mode, suppresses shell output
    /R : Replace existing files
    /S : Scan unpacked files for viruses
    /T : Test archive integrity
    /V : View archive contents
    /Bdir : move Bad archives to specified dir
    /Gpswd : supply password for Garbled file
    === End OS/2 Clipboard ===


    'Tommi

    --- GEcho/2 1.20/Pro
    * Origin: * RBB * Lake Ylo * Finland * (2:221/360)
  • From Wilfred van Velzen@2:280/464 to Tommi Koivula on Tue Aug 22 09:05:49 2023
    Hi Tommi,

    On 2023-08-21 20:13:52, you wrote to me:

    MvdV>>> GUS... I never used it myself, never had a need for it. It is
    MvdV>>> still under development or is it abandonware like so many other
    MvdV>>> FTN stuff?

    I can't remember using it. I don't think it's still under development.
    A quick google only gives me this:
    https://archive.org/details/GUS_170_ZIP so 1993...

    Got it here in my utils directory! :)

    #### # # #### General Unpack Shell | Copyright (C) 1995
    and written by
    # ## # # #### for DOS | Johan Zwiekhorst
    #### #### #### version 1.95 | - ALL RIGHTS RESERVED -

    Found that one too in my archive:

    wilnux5:/data/bck/wilnux3/home/wilfred/Documents/arc/COMPRESS # ls -l GUS* -rw-r----- 1 root root 42753 1995-04-15 19:50:00 GUS_150.ZIP

    ;-)

    It's not much newer...


    Bye, Wilfred.

    --- FMail-lnx64 2.2.0.0
    * Origin: FMail development HQ (2:280/464)
  • From Michiel van der Vlist@2:280/5555 to Wilfred van Velzen on Tue Aug 22 11:08:57 2023
    Hello Wilfred,

    On Monday August 21 2023 16:33, you wrote to me:

    MvdV>> It is no secret that I am not a member of the "more is better"
    MvdV>> club. In the POTS age with high cost of data transport
    MvdV>> "compressed better" was a valid argument. Although even then in
    MvdV>> the end of the compression evolution the added value was so
    MvdV>> small that it didn't really matter anymore. Is another one
    MvdV>> percent of compression efficiency realy worth it.

    It was way more then 1%...

    10%? Even if it was 30% it fades away against the increase in speed. I have seen the modems speeds increase from 300 bps to 30000 bps. A HUNDRED fold increase! What is a mere 30% better compression compared to that.

    Nowadays with speeds measeured in Mbps or even Gbps isntead of kbps itis completely irrelevant for Fidonet.

    MvdV>>>> How many in Amiganet still actually use an Amiga?

    Enough...

    MvdV>> Enough to leep LAH alive?

    Yes.

    Hmmm...

    MvdV>>>> The problem with keeping all these antiquaria, is that you
    MvdV>>>> also have to support it. This will become increasingly
    MvdV>>>> difficult when the knowledge evaporates...

    This is true for all of Fidonet technology. Keeping this old
    techniques working is partly what makes it interesting...

    MvdV>> True but at some point one has to make choices that every
    MvdV>> museum has to make. What do we keep and what do we drop? I see
    MvdV>> little value in keeping more then one compression method alive
    MvdV>> for Fidonet. Yes, it is interesting to keep Fidonet alive. But
    MvdV>> not ALL of the technology that was ever used. Drop some and
    MvdV>> focus on keeping the rest alive.

    Well, in this case it doesn't matter what you think. It's what the AmigaNet users want... ;-)

    Good point. ;-)

    And in a museum available "real" space is probably a lot more
    expensive then available "virtual" space in AmigaNet, which is kind of limitless...

    The virtual space needed to store the museum pieces may be "limitless", it is certainly not effortless. Once you store a painting in a storage hold, it does not require much attention any more. It can also easely be retrieved in case someone wants to see it. Digital data is different. Without the equipment to read it, it is useless. When storage media become obsolete you have to transfer the data to a new medium. I no longer have the means to read paper tape or punch cards. I could probably make pictures of it and have some smart optical recognition software read it. Floppy disks is more difficult. Compact disk is even more difficult. Long term storage of digital data is not all that easy without constant effort and cost...


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Michiel van der Vlist@2:280/5555 to Tommi Koivula on Tue Aug 22 11:25:19 2023
    Hello Tommi,

    On Monday August 21 2023 20:13, you wrote to Wilfred van Velzen:

    Got it here in my utils directory! :)

    === Begin OS/2 Clipboard ===
    #### # # #### General Unpack Shell | Copyright (C) 1995 and
    written by # ## # # #### for DOS | Johan Zwiekhorst #### #### #### version 1.95 | - ALL RIGHTS RESERVED
    - =====================================Ï==============================

    No OS/2 version?


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Wilfred van Velzen@2:280/464 to Michiel van der Vlist on Tue Aug 22 11:46:28 2023
    Hi Michiel,

    On 2023-08-22 11:08:57, you wrote to me:

    It was way more then 1%...

    MvdV> 10%? Even if it was 30% it fades away against the increase in speed. I have
    MvdV> seen the modems speeds increase from 300 bps to 30000 bps. A HUNDRED fold
    MvdV> increase! What is a mere 30% better compression compared to that.

    With that that increase in speed also came an increase in content. So better compression still made sense...

    MvdV> Nowadays with speeds measeured in Mbps or even Gbps isntead of kbps
    MvdV> itis completely irrelevant for Fidonet.

    That's true...

    And in a museum available "real" space is probably a lot more
    expensive then available "virtual" space in AmigaNet, which is kind
    of limitless...

    MvdV> The virtual space needed to store the museum pieces may be "limitless", it
    MvdV> is certainly not effortless. Once you store a painting in a storage hold,
    MvdV> it does not require much attention any more. It can also easely be
    MvdV> retrieved in case someone wants to see it. Digital data is different.
    MvdV> Without the equipment to read it, it is useless. When storage media become
    MvdV> obsolete you have to transfer the data to a new medium. I no longer have
    MvdV> the means to read paper tape or punch cards. I could probably make pictures
    MvdV> of it and have some smart optical recognition software read it. Floppy
    MvdV> disks is more difficult. Compact disk is even more difficult. Long term
    MvdV> storage of digital data is not all that easy without constant effort and
    MvdV> cost...

    A few years back I wanted to read some stored CD's serveral years old, and I couldn't. In hindsight, it wasn't that surprising. They were stored in the living room in a rack, where light could get through to them. And they weren't the best quality, certainly not archive quality...


    Bye, Wilfred.

    --- FMail-lnx64 2.2.0.0
    * Origin: FMail development HQ (2:280/464)
  • From Tommi Koivula@2:221/360 to Michiel van der Vlist on Tue Aug 22 19:40:29 2023
    On 22.08.2023 12:25, Michiel van der Vlist wrote:

    Hello Tommi,

    On Monday August 21 2023 20:13, you wrote to Wilfred van Velzen:

    TK> Got it here in my utils directory! :)

    TK> === Begin OS/2 Clipboard ===
    TK> #### # # #### General Unpack Shell | Copyright (C) 1995 and
    TK> written by # ## # # #### for DOS | Johan
    TK> Zwiekhorst #### #### #### version 1.95 | - ALL RIGHTS
    TK> RESERVED
    TK> - =====================================¤==============================

    No OS/2 version?

    Would you need one?

    'Tommi

    ---
    * Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)
  • From Michiel van der Vlist@2:280/5555 to Tommi Koivula on Tue Aug 22 20:32:14 2023
    Hello Tommi,

    On Tuesday August 22 2023 19:40, you wrote to me:

    No OS/2 version?

    Would you need one?

    No, I said goodbye to OS/2 decades ago. But Johan Zwiekhorst was an OS/2 adept, so I would have expected him to compile an OS/2 version.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Ruben Figueroa@1:124/5014.5 to Wilfred van Velzen on Tue Aug 22 17:48:17 2023
    On <21 Aug, 08:53>, Wilfred van Velzen wrote to All :
    Hi All,

    On 19 Aug 23 12:21, Wilfred van Velzen wrote to Zazz:
    about: "Re: Fmail Compression and Decompression":

    What are values to enter in fmail for zip compression an
    decompression It came only with the arc defined and nothing else

    I tested this, and you seem to be right and found a bug... :-( ;-)

    I found and fixed this bug in my development version. And although this is a minor bug, I'll probably make a release, because this is important for new users. This new release might also include new default settings for (un)zip...

    Wilfred.

    --- FMail-W64 2.2.0.0
    * Origin: point@work (2:280/464.112)

    Thanks for the update

    - Ruben Figueroa - Prison Board BBS

    ... A dress makes no sense unless it inspires men to remove it.

    --- ProBoard v2.30-A1u4
    * Origin: PB Prison BBS (gapbbs.rdfig.net:2828) Mesquite, Tx (1:124/5014.5)
  • From Ruben Figueroa@1:124/5014.5 to Wilfred van Velzen on Tue Aug 22 17:48:17 2023
    On <21 Aug, 08:53>, Wilfred van Velzen wrote to All :
    Hi All,

    On 19 Aug 23 12:21, Wilfred van Velzen wrote to Zazz:
    about: "Re: Fmail Compression and Decompression":

    What are values to enter in fmail for zip compression an
    decompression It came only with the arc defined and nothing else

    I tested this, and you seem to be right and found a bug... :-( ;-)

    I found and fixed this bug in my development version. And although this is a minor bug, I'll probably make a release, because this is important for new users. This new release might also include new default settings for (un)zip...

    Wilfred.

    --- FMail-W64 2.2.0.0
    * Origin: point@work (2:280/464.112)

    Thanks for the update

    - Ruben Figueroa - Prison Board BBS

    ... A dress makes no sense unless it inspires men to remove it.

    --- ProBoard v2.30-A1u4
    * Origin: PB Prison BBS (gapbbs.rdfig.net:2828) Mesquite, Tx (1:124/5014.5)