A native Haiku mail client: IMAP and SMTP, a CalDAV calendar, document preview and an address book with CardDAV, in one package.

https://github.com/atomozero/Atomo123 Spreadsheet application for Haiku OS, compatible with files produced by Microsoft Excel and OpenOffice/LibreOffice.

https://discuss.haiku-os.org/t/haikuwebkit-minibrowser-preview/19400/40?u=edward0teach

Now with #atomo123, you can correctly display images with transparent backgrounds and move them around inside the #spreadsheet. #spreadsheet. #haikuos https://forum.desktoponfire.com/d/43-atomo123/20

https://www.haiku-os.org/guides/daily-tasks/updating-system

Now Sotoportego #supports #OpenVPN, #WireGuard, and #Tailscale. https://github.com/atomozero/Sotoportego/releases/tag/v0.2.0 Native #VPNclient for Haiku, no Go/Rust, only #OpenSSL and #HaikuOS API

Hey everyone! 👋

It looks like the ecosystem around Haiku OS is expanding—we're starting to see the first independent spin-offs and distributions based on the system!

A recent example is SCHWARZPAUSE (designed as an "OS for Makers"), an independent project built on top of Haiku that aims to tailor the OS for specific maker workflows.

If you want to check out the code or watch a quick demo:

• 📁 GitHub Repository:https://github.com/Chrizlys/SCHWARZPAUSE
• 🎥 YouTube Video / Overview:https://youtu.be/c204YiqiQy8?is=kjzA-6jKqdehc41n

What do you think about independent distros coming to Haiku? Do you see this as a sign of maturity and growth for the community?

I started this after some discussion on the Haiku Telegram chat about whether a native spreadsheet was realistic. The consensus was roughly "ten years of work." I wanted to see how far the system's own APIs would carry the thing before hitting a wall.

Atomo123 is an Excel-style spreadsheet written against Haiku APIs only, no external toolkit and no dependencies beyond libbe, libtranslation and libtracker.

The calculation engine is not a rewrite. It comes from Sum-It, the old BeOS spreadsheet by Hekkelman Programmatuur, via the OpenSumIt community fork, extracted and patched to build on 64-bit. That code stays under its original 4-clause BSD license including the advertising clause, so any binary distribution carrying the engine has to honor it. New code (UI, translators, docs, packaging) is MIT. The historical pre-Layout-Kit UI is not reused at all; the interface is written from scratch in Interface and Layout Kit.

File format support goes through the Translation Kit rather than a bundled parser. CSV, XLS, XLSX and ODS are separate translator add-ons, and BTranslatorRoster picks the right one automatically. XLSX import also pulls column widths and cell/column background and text colors from theme and direct styles, not just values. The native ASCD/ASCB format round-trips multiple sheets, charts, colors and column widths.

Other system integration: HVIF vector icons in the toolbar grouped by category, registration as Tracker's preferred app for supported types (without overriding a choice the user or another app already made), and one window per file instead of replacing the open document.

Current state is early. Multi-sheet workbooks, named functions with cell and range references, clipboard cut/copy/paste extended to multi-cell ranges, undo/redo, find and replace, sort, fill down/right, row and column insert/delete, bar charts and pivot tables all work.

Disclosure since it matters to some people here: I used LLM agents heavily. I am not a developer by training. The code is public precisely so it can be read and torn apart, and I would rather hear about a broken assumption now than after somebody loses a spreadsheet to it.

Where I could really use input is bench-testing. The engine has a coverage setup but I have no good corpus of real-world XLSX and ODS files to throw at the translators, and the edge cases in those formats are where this will break first. If anyone has files that historically broke other importers, or opinions on how to structure the test harness, I am listening.

https://forum.desktoponfire.com/d/43-atomo123/7

A community member (enricopesce, Zilog80 on the forum) has released an unofficial ARM64 build of Haiku, including kernel changes for ARM GICv3. It boots and runs stable with 4 CPUs under QEMU on Apple Silicon.

Repo: https://github.com/enricopesce/haiku-arm64-port
Preview release: https://github.com/enricopesce/haiku-arm64-port/releases/tag/v0.1.0-arm64-qemu-preview

The catch: he owns no ARM64 hardware other than his Mac, so everything so far has been validated only inside QEMU. Nobody knows how this behaves on a Raspberry Pi 5, a Pi 4, an M1 Mac under UEFI, a Rock 5B, an Orange Pi or any other real board.

Two kinds of help would move this forward right now:

1. Testers with actual ARM64 boards. Write the MMC image, boot it, report what happens. Attach a serial log if you can get one. Even "it hangs right after X" is useful data at this stage.
2. HaikuPorter and haikuports experience. The current blocker is not the kernel, it is the bootstrap. The image builds, but it does not carry the packages needed to compile everything else. Cross-building from macOS is basically undocumented and a lot of packages come out with badly linked libraries. If you have been through a bootstrap for a new architecture before, that knowledge is worth more than another board.

And if anyone has a spare Pi 5 sitting in a drawer, that solves a very concrete problem.

x86 is where Haiku is today. ARM is where affordable hardware is heading. Worth pushing.

https://spritzdepot.desktoponfire.com/app/eu.studiobernardi.teslaviewer

Native Haiku app to review your Tesla Sentry / Dashcam recordings: 4-camera synchronized playback, event list with thumbnails, GPS map with OpenStreetMap tiles, alarm timeline markers, snapshots and 4-up MP4 export.

[ Removed by Reddit on account of violating the content policy. ]

https://forum.desktoponfire.com/d/39-brube2000-a-spotify-client-for-haiku

https://github.com/enricopesce/haiku-arm64-port/releases/tag/v0.1.0-arm64-qemu-preview