Jcat 0.1 Released As Alternative To Microsoft Catalog Files

[phoronix]

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?page=news_item&px=Jcat-0.1-Released

[caligula]

gzip in 2020? Why not zstd?

[Syfer]

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.

[mos87]

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.

[ermo]

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?

[NotMine999]

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/02/28/introducing-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

[dud225]

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 ?

[ermo]

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/02/28/introducing-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

[jntesteves]

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/02/28/introducing-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

[RahulSundaram]

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/pipermail/lvfs-announce/2020-March/000043.html