Announcement

Collapse
No announcement yet.

Jcat 0.1 Released As Alternative To Microsoft Catalog Files

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Jcat 0.1 Released As Alternative To Microsoft Catalog Files

    Phoronix: Jcat 0.1 Released As Alternative To Microsoft Catalog Files

    Richard Hughes of Fwupd/LVFS, PackageKit, and Colord notoriety last month announced Jcat as a new open-source project he initiated to serve as an alternative to Microsoft's Catalog files proprietary format...

    http://www.phoronix.com/scan.php?pag...t-0.1-Released

  • #2
    gzip in 2020? Why not zstd?

    Comment


    • #3
      Originally posted by caligula View Post
      gzip in 2020? Why not zstd?
      Backwards compatibility. gzip is omnipresent, while zstd is up and coming on Linux and alien to developers from the Windows ecosystem. gzip isn't there for amazing compression, it's only to mitigate the impact of duplicate signatures.

      Comment


      • #4
        so it's a new thingy to store... signatures matched to files, right? employing the JSON format? proposed to flash firmware? json, firmware, ascii strings. a new format. Sounds right, very modern approach.. yeah.

        Comment


        • #5
          Originally posted by mos87 View Post
          so it's a new thingy to store... signatures matched to files, right? employing the JSON format? proposed to flash firmware? json, firmware, ascii strings. a new format. Sounds right, very modern approach.. yeah.
          Maybe the design and implementation choices make more sense once you read the JCAT announcement?

          Comment


          • #6
            Is the JSON license still encumbered with Crockford's "The Software shall be used for Good, not Evil" requirement?

            https://lwn.net/Articles/707510/

            If yes, then some distributions might have problems allowing it in their repositories.

            https://wiki.debian.org/qa.debian.org/jsonevil

            I wonder if a simple text file with delimited fields would work better rather than some fancy format derived from Javascript. Text files are also language-neutral and easily parsed by any number of tools and applications. When I worked as a programmer I always tried to practice the "keep it simple" approach; it made debugging & updating much much easier. Nowadays I cringe at programmers that look at fancy languages like cats look at sqwerl. ('sqwerl' mis-spelling is intention)

            If the picture shown in Hughes own blog is any indication, then the textfile format for the catalong would have a line for each entry and each line/entry would only have 3 fields (name, size, type).

            https://blogs.gnome.org/hughsie/2020...roducing-jcat/

            A simple textfile with a line for each entry and 3 fields per line would be easily compressed with gzip for widespread compatibility.

            Would gzip really save that much space when then file contents are so simple? In other words, what's a few KB of textfile when binaries are measured in MB, archives in GB, and diskspace in TB? Perhaps it's not "compression" that's the goal but a form of simple "corruption prevention" for the catalog file as gzip can't open a '.gz' file that is corrupt, and gzip can test '.gz' archives.

            For your own quick reference, here's the Wikipedia link to JSON.

            https://en.wikipedia.org/wiki/JSON

            Comment


            • #7
              I don't much about LVFS, but this article implies that no signature check is currently been carried out for firmware updates, is that accurate ?

              Comment


              • #8
                Originally posted by NotMine999 View Post
                Is the JSON license still encumbered with Crockford's "The Software shall be used for Good, not Evil" requirement?

                https://lwn.net/Articles/707510/

                If yes, then some distributions might have problems allowing it in their repositories.

                https://wiki.debian.org/qa.debian.org/jsonevil

                I wonder if a simple text file with delimited fields would work better rather than some fancy format derived from Javascript. Text files are also language-neutral and easily parsed by any number of tools and applications. When I worked as a programmer I always tried to practice the "keep it simple" approach; it made debugging & updating much much easier. Nowadays I cringe at programmers that look at fancy languages like cats look at sqwerl. ('sqwerl' mis-spelling is intention)

                If the picture shown in Hughes own blog is any indication, then the textfile format for the catalong would have a line for each entry and each line/entry would only have 3 fields (name, size, type).

                https://blogs.gnome.org/hughsie/2020...roducing-jcat/

                A simple textfile with a line for each entry and 3 fields per line would be easily compressed with gzip for widespread compatibility.

                Would gzip really save that much space when then file contents are so simple? In other words, what's a few KB of textfile when binaries are measured in MB, archives in GB, and diskspace in TB? Perhaps it's not "compression" that's the goal but a form of simple "corruption prevention" for the catalog file as gzip can't open a '.gz' file that is corrupt, and gzip can test '.gz' archives.

                For your own quick reference, here's the Wikipedia link to JSON.

                https://en.wikipedia.org/wiki/JSON
                If you want to engage with the author over design decisions, phoronix is hardly the best place to do so?

                For reference: https://github.com/hughsie/libjcat

                Comment


                • #9
                  Originally posted by NotMine999 View Post
                  Is the JSON license still encumbered with Crockford's "The Software shall be used for Good, not Evil" requirement?

                  https://lwn.net/Articles/707510/

                  If yes, then some distributions might have problems allowing it in their repositories.

                  https://wiki.debian.org/qa.debian.org/jsonevil

                  I wonder if a simple text file with delimited fields would work better rather than some fancy format derived from Javascript. Text files are also language-neutral and easily parsed by any number of tools and applications. When I worked as a programmer I always tried to practice the "keep it simple" approach; it made debugging & updating much much easier. Nowadays I cringe at programmers that look at fancy languages like cats look at sqwerl. ('sqwerl' mis-spelling is intention)

                  If the picture shown in Hughes own blog is any indication, then the textfile format for the catalong would have a line for each entry and each line/entry would only have 3 fields (name, size, type).

                  https://blogs.gnome.org/hughsie/2020...roducing-jcat/

                  A simple textfile with a line for each entry and 3 fields per line would be easily compressed with gzip for widespread compatibility.

                  Would gzip really save that much space when then file contents are so simple? In other words, what's a few KB of textfile when binaries are measured in MB, archives in GB, and diskspace in TB? Perhaps it's not "compression" that's the goal but a form of simple "corruption prevention" for the catalog file as gzip can't open a '.gz' file that is corrupt, and gzip can test '.gz' archives.

                  For your own quick reference, here's the Wikipedia link to JSON.

                  https://en.wikipedia.org/wiki/JSON
                  wow! just wow! out of words. wow

                  Comment


                  • #10
                    Originally posted by dud225 View Post
                    I don't much about LVFS, but this article implies that no signature check is currently been carried out for firmware updates, is that accurate ?
                    No. If you read the linked references, you can read more details

                    https://lists.linuxfoundation.org/pi...ch/000043.html

                    Comment

                    Working...
                    X