Free, Libre, and Open Source Software and Standards

posted by Roy Schestowitz on Aug 27, 2025

• Eric MacAdie ☛ Emacs Carnival: Elevator Pitch and Post-Pitch Talking Points

  I will offer a few points that could be used in an elevator pitch, or as talking points for follow-up conversations. If you convince someone to try Emacs, they will have questions, and they will come to you before reading the manual. Some of these are related, so there might be some repetition. trifecta accuses choosiest

• Productivity Software/LibreOffice/Calligra

  • Document Foundation ☛ PyPos3DLO: Python 3D App based on LibreOffice

    Today we’re talking to Olivier Dufailly, who’s working on PyPos3DLO, an app based on LibreOffice to create mechanical characters, edit and optimize Poser files, and manipulate WaveFront files: Tell us a bit about yourself!

• Funding

  • Unicorn Media ☛ Advantages and Pitfalls of Public Investment in Open Source Infrastructure

    Open source powers the world, but who should to keep it running—and who should decide where the money goes?

    >

• FSF

  • FSF ☛ FSF Events: Community meetup in Palm Beach County, Florida, United States

  • FSF ☛ FSF Events: Free Software Directory meeting on IRC: Friday, August 29, starting at 12:00 EDT (16:00 UTC)

    Join the FSF and friends on Friday, August 29 from 12:00 to 15:00 EDT (16:00 to 19:00 UTC) to help improve the Free Software Directory.

• Standards/Consortia

  • [Old] Scott Laird ☛ The Limits of NTP Accuracy on Linux

    So — finally — I have multiple NTP servers, presumably synced to GPS satellites as accurately as possible, and multiple servers, all synced to the NTP servers over a relatively low-latency network. How accurately are my servers syncing to GPS time? And where is that going wrong?

  • GNU Savannah ☛ Xz format inadequate for general use

    One of the challenges of digital preservation is the evaluation of data formats. It is important to choose well-designed data formats for general use. This article describes the reasons why the xz compressed data format is inadequate for most uses, including long-term archiving, data sharing, and free software distribution. The relevant weaknesses and design errors in the xz format are analyzed and, where applicable, compared with the corresponding behavior of the bzip2, gzip, and lzip formats. Key findings include: (1) safe interoperability between xz implementations is not guaranteed; (2) xz is vulnerable to unprotected flags and length fields; (3) LZMA2 is unsafe and less efficient than the original LZMA; (4) xz's extensibility is unreasonable and problematic; (5) xz includes useless features that increase the number of false positives for corruption; (6) xz shows inconsistent behavior with respect to trailing data; (7) error detection in xz is less accurate than in bzip2, gzip, and lzip.

    Disclosure statement: The author is also author of the lzip format.

    Acknowledgements: The author would like to thank Lasse Collin for his detailed and useful comments that helped improve the first version of this article. The author would also like to thank the fellow GNU developers who reviewed this article before publication and the people whose comments have helped to fill in the gaps.

    This article was originally published under the title "Xz format inadequate for long-term archiving", but further analysis revealed that xz is significantly less safe than bzip2, gzip, and lzip for most uses.