posts
Microsoft has released LiteBox 0.1, the first version of its open-source, Rust-based Library OS designed to isolate applications from the underlying operating system, reducing access to host resources and limiting security risks.
Unlike a traditional operating system such as Linux or Windows, Library OS does not run independently or provide a complete environment for users. Instead, it implements operating system functionality as a library that applications use within a controlled execution environment.
In LiteBox’s case, the goal is to provide applications only the interfaces they need while minimizing interaction with the host operating system. This reduces the attack surface, meaning fewer ways for malicious or compromised software to interact with the underlying system.
LiteBox uses a modular architecture built around two interfaces: North and South. The North interface provides operating system functionality to applications through a Rust API inspired by the nix and rustix libraries. The South interface connects LiteBox to the underlying execution platform.
By separating these components, developers can combine different application interfaces with different platforms without redesigning the entire system.
Microsoft says LiteBox is intended to work in both kernel-mode and user-mode environments, allowing it to support several application isolation scenarios.
For Linux users, a relevant use case is sandboxing Linux applications directly on Linux. Another is running unmodified Linux programs on Windows, although LiteBox is not intended to replace WSL as a general-purpose Linux environment.
Beyond these scenarios, the project also targets more specialized security environments, including AMD SEV-SNP, which provides hardware-backed memory protection for virtual machines, and OP-TEE, an open-source trusted execution environment.
Microsoft additionally lists Linux Virtualization-Based Security among the supported use cases.
The project is still under active development. According to its maintainers, APIs and interfaces may change as the architecture matures. Developers requiring long-term stability are advised to wait for a stable release or be prepared to adapt their implementations.
LiteBox is available under the MIT license, with its source code, development information, and contribution guidelines hosted on GitHub.
For more information, visit the official LiteBox GitHub repository.
Since 2022, Google's Open Source Software Vulnerability Reward Program (OSS VRP) has been the path for outside researchers to get paid for reporting security flaws in the company's open source code, including projects like Flutter, Angular, Go, and Fuchsia.
With an announcement on X, they have now decided to discontinue the product-facing side of it.
They are calling the change temporary, while supply chain reports remain open and anything submitted before October 1 stays unaffected. What's closed, what's not?
Product vulnerabilities are bugs in the projects themselves, like a failing HTML sanitizer, memory corruption issues in file format parsers, or insecure code examples in documentation.
The updated rules do not limit the change to a specific project tier, as they just won't be accepting any reports related to this.
Supply chain reports, on the other hand, cover vulnerabilities in how the software is built and shipped. Exposed package manager credentials used to publish build artifacts is one case the rules page lists. It remains unaffected by this change.
There's also an exception for some Google Cloud repositories. If a bug there affects a Cloud product, Google may still accept the report, but through its Cloud VRP.
Why did it come to this?
Back in March, a post on the Bug Hunters blog from Google engineers said AI-generated reports were flooding the program. Some were serving up hallucinated information, while others were flagging legit coding errors that had little to no impact on the security posture of the targeted project.
Google's first response was to raise the bar on memory corruption reports for its two top project tiers. Researchers had to either reproduce the bug through an existing OSS-Fuzz fuzz target or point to a patch that maintainers had already merged.
An update to the same post the following month went further. The standard and low-priority tiers, OT2 and OT3, stopped offering rewards or credit for product vulnerabilities and other security issues. The top supply chain reward for OT2 projects also fell to $3,133.70.
Supply chain reports still pay, from $500 on OT2 projects up to $31,337 on flagship ones.
As an alternative, Google points to the Patch Rewards Program, which pays between $100 and $15,000, though only for patches that have stayed in a project for a month without being reverted.
An open question
Google has not said when or in what form product vulnerability reports will return. Their announcement only promises an update in the first quarter of 2027 while they continue reworking that part of the program.
There's also a loose end. At the time of writing, the OSS VRP page still lists reward ranges for product vulnerabilities, up to $7,500. Though, as you saw earlier, the rules page for it has already been updated, so it shouldn't be long before this is addressed.
I remember that comaps was forked from organic maps due to some drama around organic maps, but I am out of the loop on what exactly happened. Can someone get me up to date?
Even if it works despite being AI slop that's been developed in a mere 4 days (?) and somehow has all these contributors, I'm not sure I agree with the idea.
It's cool that they went with Rust for it, but I would have much preferred if all that effort went towards improving GIMP and existing open formats.
If it works then I guess it's the same end result at the end of the day, but it would suck if GIMP doesn't end up being the one to put a nail on Photoshop's coffin after all these years of serious development by humans.
Edit: I already see the kneejerk dislikes coming, I'm just interested in starting a conversation about the idea of it, I also dislike the fact that it's AI slop as I already implied. I'd appreciate joining the conversation instead of dislike bombing with no argument.
on the web, I came across the ReveriePaint app, it's kind of like krita, only for mobile devices🤩 https://github.com/LanRhyme/ReveriePaint
Given that Pixelfed is designed as an Instagram alternative, it seems like it'd make more sense to just put the short-form videos on there.
cross-posted from: https://slrpnk.net/post/43551913
After reading the article about 31 New species discovered in 2 weeks of exploration, it was mentioned that they used a microscope, known as Squid,which is an open-source, confocal microscope
From their site:
What is Squid?
Squid is a quantitative imaging platform with a full suite of hardware and software components and configurations for deploying facility-grade widefield microscopes at a fraction of the cost of commercial solutions. Developed with the goal of helping translate the rapid advances in the field of microscopy and microscopy-enabled methods, including those powered by deep learning, we envision Squid will simplify roll-out of microscopy-based applications - including at point of care and in low resource settings, make adoption of new or otherwise advanced techniques easier, and significantly increase the available microscope-hours to labs.
Significance
Manual microscopy has served as a bedrock for the diagnostics of various infectious diseases, although at a cost of tedious labor and human errors. Imagine looking for 1 to 5 parasites amongst 5 million red blood cells. Currently, microscopists can take up to 10-15 minutes to review a single slide. Automated robotic microscopes are poised to enable a new era of smart field microscopy but current platforms remain cost prohibitive and largely inflexible, especially for resource-poor and field settings.
github repos
CAD models linked available here (a lot of google links there (docs, drive, etc))tags frugal science microscopy tracking fluorescence excitation patterned illumination instrumentation frugal science malaria
The aim for this project is being as simple as possible. It hasn't got a way to track statistics nor some submission form. All are to be implemented using external means.
Currently, I'm using it for https://bchwebring.com/ on a tiny FreeBSD VPS.
LibreSSL 4.3.3 has been released as a maintenance update to the OpenBSD-developed TLS and cryptography library, bringing several security and reliability fixes alongside portability improvements for macOS and Windows.
The most notable fix in LibreSSL 4.3.3 addresses an Online Certificate Status Protocol responder authorization bypass affecting both libtls and the ocspcheck utility.
OCSP is used to determine whether a TLS certificate has been revoked. LibreSSL’s fix tightens validation around which responders are authorized to provide that information.
DTLS, which provides TLS-style encryption for datagram-based protocols such as UDP, also receives several corrections. The developers fixed an incorrect size check in dtls1_preprocess_fragment(). They introduced a limit on buffered DTLS handshake data and addressed a potential overread that could occur when retransmission was interrupted.
Certificate verification receives attention as well. LibreSSL 4.3.3 ensures that verification callbacks configured to always return success can still detect a hostname mismatch. In addition, support for RelativeDistinguishedName in CRL distribution points has been removed.
On the portability side, the release adds support for building LibreSSL on macOS Golden Gate 27.0.
Windows users also get a couple of fixes. The developers worked around incorrect code generation produced by the MSVC ARM64 optimizer in constant-time big-number code, while LibreSSL’s Windows socketpair() emulation now correctly sets close-on-exec on the appropriate handle.
Lastly, projects building LibreSSL through CMake can now override TLS_DEFAULT_CA_FILE, providing more flexibility over the default location used for trusted certificate authorities.
For additional detail, see the release notes.
LibreSSL is a fork of OpenSSL created by the OpenBSD project in 2014, focusing on simplifying the codebase, removing legacy components, and improving security and maintainability. Besides being used by OpenBSD, a portable version is available for Linux, macOS, Windows, and other Unix-like systems.
Darktable 5.6.2 has been released today as the second point release to the latest Darktable 5.6 series of this open-source, free, and cross-platform raw image editor for GNU/Linux, macOS, and Windows.
Coming a little over a month after Darktable 5.6.1, the Darktable 5.6.2 release adds white balance presets for the Leica SL3-P (DNG) and Sony Alpha 7R VI (Sony ILCE-7RM6) cameras, improves highlights modes for 4BAYER (CYGM/RGBE) raws, and improves OpenCL support for recent Intel graphics drivers.
Darktable 5.6.2 also fixes OpenCL input gamma-corrected scaling for some devices, an OpenCL error in filmicrgb leading to wrong masks, a crash that occurred when importing a style whose module order is empty, and small memory leaks when expanding variables, which grew with the number of images imported or exported with each instance.
On top of that, this release fixes a small memory leak that occurred each time a history stack was pasted onto the image open in darkroom, corrupted output or a crash when an AI model returns more data than darktable reserved for it, which affected object masks and Lua models, and an issue with transparent dialog title bars on macOS 27.
Also fixed is a crash that occurred at the end of neural restore’s raw denoise on certain sensor sizes, where blending the tile seams wrote past the edge of the image, an OpenCL error in filmicrgb leading to wrong masks, and highlights Laplacian OpenCL code.
For Windows users, this release addresses a crash or hang when checking a faulty custom ONNX Runtime library, a bug causing Alt+Tab to fail to switch away from darktable when the mouse pointer was over a lighttable thumbnail, and an issue with the console windows that appeared repeatedly when darktable or a Lua script ran an external command.
Lastly, Darktable 5.6.2 fixes a stealing focus issue from other apps on Windows, which could happen when hovering over lighttable thumbnails, during import and export, or when log messages appeared or expired. According to the devs, while Darktable was minimized, it took the keyboard without becoming visible.
Some documentation updates are present as well, so check out the release notes for more details. Meanwhile, you can download Darktable 5.6.2 as a universal AppImage binary from the official website, which you can run on virtually any GNU/Linux distribution without installing anything on your personal computer.
cross-posted from: https://leminal.space/post/40562232
From Fluxer's updated roadmap on their website
See the polyproto website they linked here
I hadn't heard of this protocol before, but the possibility of transferring accounts between homeservers sounds exciting!
Here's the text from the screenshot:
Federation lets people on different instances talk to each other as if they were on the same service, the way email works across providers. Fluxer's federation will be based on polyproto-core, a specification from the polyproto project, with our own extensions on top. polyproto is still young, and we hope that building a real implementation of it, and sharing what we learn, helps the specification mature and benefits everyone else who builds on it.
polyproto-core describes an identity that works across servers. Your identity is anchored on your home server and looks like name@domain. Behind it is a certificate that your home server signs over a key created on your device. To prove who you are to another server, your device signs a challenge from that server, so one identity works across servers and you don't need a separate account on each. Messages are signed by the sender, so a server you visit can't forge messages from you without being detected, as long as your home server and your device haven't been compromised. The specification also defines how to move to a new home server.
polyproto-core is an early beta specification maintained by the Polyphony project. As of October 2026 it is at v1.0-beta.13. It focuses on identity and leaves message formats and chat features to extensions. We'll write our own extensions for Fluxer's features and propose changes to the protocol where they would help others too.
We'll publish an experimental draft pull request in 2026 that you can try and give feedback on. The stable release follows in 2027. Until the draft is up, the discussion happens in Fluxer Labs, and you're welcome to join in.
You can already sign in to several instances from one app. You sign in to each instance separately and switch between them. The mobile apps already support several instances and accounts, and the desktop app gets the same in early October 2026 with the update described in #2.
I've been working on reverse-engineering Grindr and creating an open source client implementation for it since March.

When GrindrPlus closed, my project turned out to be its de-facto successor and immediatelly several thousands of people started following it. Now it has 70k+ downloads on Forgejo and the authorship is dedicated to public domain :)
- MIT licensed, no ads, no analytics, no trackers, no diagnostics, no statistics, no telemetry, only opt-in updates checking
- Signed releases, reproducible builds on all four platforms, full transparency
- And it's now in Google Play (for the time being) and being reviewed for F-Droid!
Already applied for Apple developer enrollment and going to publish this to EU alt stores as well as in the TestFlight. Then a classic unsigned ipa and also going to attempt Apple AppStore just for completeness.
You need an existing Grindr account. Downloads: https://opengrind.org/download
Questions and criticism welcome.
Hi! I’m a table tennis player, club captain and referee who apparently decided that what the world desperately needed was another tournament manager.
So I made LibreTT. 🏓
It’s a desktop app for running table tennis tournaments: players, registrations, fees, groups, draws, matches, knockout brackets, results, backups and exports. It runs on Linux, Windows and macOS, works offline and requires no account.
So why another one?
Because I don’t think competition data should belong to the software that records it.
A result is created by players, clubs, referees and organizers. The software is just a tool. If LibreTT disappears tomorrow, your tournament history shouldn’t disappear with it.
That’s why LibreTT is licensed under AGPL-3.0-or-later. No subscriptions, activation servers, paid feature tiers or vendor lock-in. The source is public, the data stays local, and the community should always be able to preserve, move and continue its own infrastructure.
This is the first public beta (0.1.0-beta.1), so the next milestone is testing it against its natural predator: an actual tournament organizer who is 15 minutes behind schedule.
Development is AI-assisted and I disclose that in the README. I review and test what goes into the project and take responsibility for it.
Feedback, criticism and contributions are very welcome.
Disclaimer: LibreTT website is still in development, expect bugs
I have been noticing an increasing amount of apps on droidify, that are not supposed to have trackers, obtain trackers after being updated. I dont know if its amongst the developers themselves or Google's forced pushed on getting apps approved through their store, but it should be put in the description of these apps before they are downloaded that trackers have been added.
For example, these are some apps that are NOT supposed to have trackers, in fact do have trackers:
Or
Some of these apps, my phone dosent pick up that it contains trackers unless i look at Tracker Control
- Blorp (Lemmy)
- FossWallet (this one just happened, this wallet NEVER had trackers until a recent update)
- All of the browser apps on drodify (even the private ones) - the only one that admits to have anti-privacy features is Tor.
- Rush (Music Lyrics App) (description has been updated to show it has trackers) i dont understand why a music lyrics app has trackers on it
- PipePipe (viewed on tracker control)
- Tuta(viewed on tracker control)
- Droidify (yes, droidify itself contains trackers)
- AntennaPod(viewed on tracker control)
Wi-Fi networks continue to grow in complexity as Wi-Fi 7 introduces new capabilities and consumers expect seamless connectivity throughout the home. EasyMesh has become the industry's leading standard for interoperable managed Wi-Fi, enabling service providers and device manufacturers to build multi-vendor mesh networks that deliver a consistent user experience.
Join Cihangir Odabaş for an in-depth look at Wi-Fi EasyMesh Release 6, including the latest capabilities, the motivation behind the new features, and what implementers should understand before bringing R6 into their products.
Drawing on real-world implementation experience, this session will explore how prplMesh v6.0 builds on previous versions, the architectural considerations for controllers and agents, and how open-source projects such as prplMesh help accelerate adoption across the broadband ecosystem.
I'm not an Android developer, but I plan to learn this along with the Kotlin language. The Android Studio seems to have proprietary components and therefore marked as non-FOSS on Flathub store. The Android SDK specifically (at least builds provided by Google) is also seems to be licensed under non-FOSS license.
Android Studio is a powerful IDE with rich toolbox for Android development, but it feels like strong lock-in on closed technology even in case we have Android as a FOSS platform in face of AOSP.
I'm just curious to learn, is Android development can be setup to be 100% FOSS? What environment, toolchain, and editors like IntelliJ IDEA CE/VSCodium/Neovim we can possibly use to achieve this?
After 5 years, Minecraft: Java Edition (version 26.3+) can finally run out-of-the-box on the Rockchip RK3588 ARM SoC using a fully open-source graphics pipeline!
My setup:
- Operating system: Vanilla OS 3 Reunion (Linux kernel 7.1)
- Drivers: Mesa PanVK (Vulkan 1.4)
Hey everyone!
I’d like to introduce TypeType, because I don’t think many people here have seen it yet.
TypeType is an open-source, self-hostable video app for YouTube, NicoNico and BiliBili. You run one private instance, then use it from the web app or from the native Android client. Your accounts, subscriptions, history, playlists, favorites, watch progress and settings stay on the instance you control, instead of living only inside the platforms.
IF YOU DONT WANT TO READ ALL THE POST (and that's alright no worries), HERE IS A TLDR !
TL;DR: TypeType is an open-source, self-hostable video app for YouTube, NicoNico and BiliBili, with a web app and a native Android client. It’s built on PipePipeExtractor with its own MSE/SABR playback engine. You can import and export your data with a dozen other apps, no lock-in. 1.9.0 is out, focused on playback reliability. Contributions are welcome, in code, translations or testing.
Source code: https://github.com/TypeType-Video/TypeType
Some background, because TypeType didn’t come out of nowhere
If you’ve been around open-source YouTube tooling for a while, you probably know the family tree. NewPipe is the libre Android streaming front-end, and NewPipeExtractor is the library that does the extraction behind it. PipePipe is a hard fork of NewPipe started in early 2022, and it also handles other services, including NicoNico and BiliBili, with its own extractor, PipePipeExtractor.
Then there’s the self-hosted side. Piped and Invidious are the two big alternative frontends, both AGPL, one built around Vue with its own backend, the other written in Crystal. LibreTube is an Android client that supports YouTube content, and it can use Piped for optional account sync. Those projects are the ones that showed a lot of people that running your own YouTube frontend was even possible.
Before TypeType, I had spent years around PipePipe, and that’s really where the project comes from.
The SABR part
My main work this year was on SABR, the protocol YouTube moved to after cutting the older methods used to fetch streams. I started with a proof of concept, the support landed in PipePipeExtractor, and then came the harder parts: live streams, cold start, session recovery, memory growth from segment buffers. I also maintain the PipePipe wiki and wrote the SABR guide there: https://priveetee.github.io/Docs-PipePipe/developer-guide/introduction.html
That work is really why TypeType exists in its current form. Once the extraction and the session logic are yours, you can build an app that owns the entire chain, instead of relying on someone else’s frontend.
What TypeType is in practice
On the web side you get multi-service search, personal libraries, downloads, comments, subtitles, SponsorBlock, administration, and SABR playback in the browser. The Android client adds background audio, Picture in Picture, audio-only playback, native playback controls and notifications, and it works from Android 6.0 without Google Play Services. The web app and the Android app share the same account and the same library, because they talk to the same instance.
One thing I’m quietly proud of is the portability. It works in both directions. You can import and export across TypeType, PipePipe, NewPipe, Invidious, Piped, LibreTube, ViewTube, Materialious, youtube-local, Flow, SkyTube, Grayjay, YouTube Takeout and even OPML, and that covers subscriptions, history, playlists, favorites, watch progress, settings and more.
And to be clear, there’s no competition here. I genuinely don’t care if you leave and use something else. The point is that your data is yours, so you can come from another project without starting over, and leave with it too if you want.
How it works
TypeType is several services rather than one big blob.
The core is a Kotlin/Ktor server. It wraps PipePipeExtractor for the extraction side: streams, manifests, search, suggestions, trending, comments and channels. It also owns the user data, accounts, subscriptions, playlists, favorites, progress, imports and administration, stored in PostgreSQL with Dragonfly as cache.
Next to it, a TypeScript token service handles the YouTube specifics: visitor data, BotGuard challenges, Proof-of-Origin tokens, player signature decoding, and the WEB and MWEB SABR session metadata. Player decoding stays on our own service path, we don’t rely on third-party decoder endpoints.
For downloads, there’s a separate Go service. It takes jobs from the server, downloads the selected streams with concurrent HTTP Range requests or SABR segments, and muxes audio and video without re-encoding, then publishes the artifact to local or S3-compatible storage. No yt-dlp wrapper under the hood.
On the client side, a React and TypeScript web app handles the interface and the library, and playback goes through our own MSE engine, TypeType-Player. It’s written in TypeScript, has no runtime dependencies, and is published on npm and JSR as @typetype/mse.
So the chain is: client asks the server, the server extracts through PipePipeExtractor, the token service supplies what YouTube requires, and the player turns the resulting session into audio and video.
What we built on top
The extraction engine does the hard part, and I credit it every time, because TypeType would not exist without it. But the project is a lot more than a wrapper now: SABR playback sessions with recovery and bounded buffers, opaque media handles, a custom MSE engine, multi-service search, personal libraries, RSS feeds, profiles, notification delivery, downloads and muxing, portability across a dozen apps, OIDC and instance administration.
Around it there are separate repositories: the React web client, the MSE/SABR playback engine, the Go downloader, and the token service. Licenses vary per component: the server is GPLv3 because of the PipePipeExtractor integration, the downloader is GPL-3.0-or-later, and the rest is MIT.
1.9.0 is out
Most of this release is about making playback more dependable rather than adding new screens. YouTube web playback is now SABR-only, and recoverable live requests stay inside the active playback session instead of leaving playback stuck. There’s also work on Takeout imports, subscription groups on desktop, and the self-hosting documentation.
Honestly, the part I’m the most proud of is that this is not a one-person project anymore. Several people sent PRs for this release, on subscription groups, playback and character encoding. That’s still new to me and it makes me really happy :)
And the community around TypeType is something I did not expect. There are amazing people who test builds, report bugs with real details, help with translations, answer each other, and just hang around. It’s warm, it’s genuinely helpful, and I will never thank them enough.
We also published an AI transparency statement, explaining how AI is used in the project and what we expect from contributions: https://github.com/TypeType-Video/TypeType/blob/dev/AI_TRANSPARENCY.md
Links:
Source code: https://github.com/TypeType-Video/TypeType
1.9.0 release notes: https://github.com/TypeType-Video/TypeType/releases/tag/v1.9.0
Android client: https://github.com/TypeType-Video/TypeType-Android
Playback engine: https://github.com/TypeType-Video/TypeType-Player
Self-hosting docs: https://typetype-video.github.io/Docs-TypeType/self-hosting/introduction
Extractor: https://github.com/InfinityLoop1308/PipePipeExtractor
Contributions are welcome, whatever part of the stack interests you: Kotlin/Ktor on the server, the React web client, the TypeScript playback engine, the Go downloader, or the Android app.
And you don’t even need to write code. Translations are handled on Weblate, so if you want to help translate TypeType into your language, you can do it right there: https://translate.typetype.video/engage/typetype/
If you want to follow the project, there’s also a community here on Lemmy: https://lemmy.zip/c/TypeType
Thanks for reading :)
As a major disappointment to the open-source community, Siemens has decided to end -- and close-up access -- to the OpenRadioss project as the open-source version opened up by Altair Engineering under the GNU AGPL License back in 2022. This was an open-source version of the industry-leading finite element solver that Altair developed. Siemens acquired Altair Engineering last year and have now completely shut the door on OpenRadioss.
Originally from Altair, Radioss has been an industry-leading solver for analyzing crashes, blasts, and other purposes. Altair creating OpenRadioss was a huge milestone for the technical computing industry. It also had other effects like for myself in finally being able to benchmark with this (Open)Radioss code for CPU performance testing compared to the expensive licensing on Radioss itself.
To much disappointment, I find out today they have completely closed down OpenRadioss. The Siemens.com page now explains of OpenRadioss:
"OpenRadioss is transitioning to a new phase. Visitors looking for crash and impact simulation solutions can now explore Simcenter Radioss and the Radioss R&D program through Siemens. These offerings provide pathways for both production engineering and advanced research activities.
...
The OpenRadioss website is being retired and visitors are being redirected to this transition page. If you are looking for simulation software, technical information or opportunities to engage with future development activities, Siemens provides resources and programs to support those needs."
Even worse, it's just not the OpenRadioss website being "retired" a.k.a. shutdown but they closed up their GitHub repository too. OpenRadioss on GitHub is now a 404. It would be one thing just to archive it and at least keep the open-source code readily available, but instead it's been removed.
OpenRadioss 404
Siemens argues the OpenRadioss closure as for consolidating efforts:
"After four years of successful community-driven research, Siemens is entering a new chapter for the Radioss solver. To accelerate innovation and provide the robust support our global users require for production-grade simulation, we are consolidating our efforts."
Very disappointing to see from such a very promising technical computing project these past few years that was also very useful for real-world performance benchmarking purposes as my main interest in the project. At least for now I'll continue with OpenRadioss benchmarking using archived local binaries for there not being any other superior free or open-source solution available. A major disappointment out of Siemens.
The Document Foundation announced today the general availability of LibreOffice 26.8.1 as the first maintenance update to the latest and greatest LibreOffice 26.8 office suite series with compatibility and text import improvements.
Coming a little over a month after LibreOffice 26.8, the LibreOffice 26.8.1 update is packed with bug fixes for various issues, crashes, and other annoyances reported by users, as well as more reliable import of text and CSV files with various character encodings, including UTF-16, ISO Latin 1, Chinese, and Japanese.
LibreOffice 26.8.1 also improves compatibility with DOCX, XLSX, and PPTX files, and brings various other changes across most of LibreOffice’s core components, including Writer, Calc, Math, Draw, and others. In numbers, the LibreOffice 26.8.1 point release addresses a total of 40 bugs.
Details about these bug fixes can be found in the changelog for our tech-savvy readers. Meanwhile, you can download LibreOffice 26.8.1 from the official website as binaries for DEB and RPM-based GNU/Linux distributions, or as a source tarball if you’re a system integrator or want to install LibreOffice from sources.
LibreOffice 26.8 was released on August 26th, 2026, with new features like Paragraph Composer in Writer as a text layout algorithm that balances word spacing across consecutive lines, support for OpenType font variations, and the ability to detect paragraph direction automatically when documents or plain text are opened or pasted.
It also made the style list consistent across the Notebookbar, the Formatting toolbar, and the sidebar, added support for VeraPDF during automated testing when validating PDF output, updated the Quick Find sidebar to allow searching through comments, and implemented a Draft view to hide headers, footers, and margins.
The LibreOffice 26.8 office suite series will be supported with seven maintenance updates until June 13th, 2027. The next point release, LibreOffice 26.8.2, is planned for the end of October. Meanwhile, The Document Foundation recommends that all LibreOffice 26.8 users update to LibreOffice 26.8.1 as soon as possible.
Welcome to Bogdan Buzea 🇷🇴
https://blog.documentfoundation.org/blog/2026/09/29/welcome-bogdan-buzea-new-libreoffice-qa-analyst/
I know there are a lot of project management apps out there, but is there a simple one you could recommend for a small-scale personal project? It's mainly meant to keep myself organized, and to break down tasks.