Author here: I get where you’re coming from and long term, I agree. I don’t want FreeBSD to slowly turn into "Linux but different."
For me though, the Linuxulator is about practicality today, not philosophy. It lets me use one or two tools (like the VS Code server) without changing how I actually run my system. Everything else stays native FreeBSD.
It's optional, isolated, and doesn't pollute the base system. If native ports exist and work well, I'll always prefer those. But when something critical doesn't, the compatibility layer keeps FreeBSD usable in modern workflows instead of becoming limiting.
So yeah.. I see it more as a bridge, not a direction.
We build and sell multi-service business gateways, basically devices that do networking, VoIP, etc. all in one box. https://difuse.io/ if you're interested!
I oftentimes run Linux Desktop fullscreen in a VM on macOS. macOS acts like a hardware abstraction layer in that case. Depending on the task and the tools, I sometimes prefer this option (I do like the macOS UI though (except for the current version), I just like to use the right tool for the job)
I don’t think there’s an existing tool that handles Markdown and Git repos without requiring users to interact with Git directly.
We’re currently developing a feature that allows you to push directly to Git from Kalmia. Instead of pushing Markdown, we’ll push the compiled HTML/JS output, eliminating the need for a build step in the Git repo and making CI/CD processes unnecessary.
One of the saas hosting companies made one for Hugo iirc, but it looks like crap and is pretty basic.
It's a pretty easily solvable problem but I guess developers are focussing on bigger markets.
I'd want to keep the build step since I may pull markdown from other sources like I think astra allows.
I really just want to be able to give access to a marketing team to update the blog etc as a nice UI over using markdown and git (which is never going to happen).
> I'd want to keep the build step since I may pull markdown from other sources like I think astra allows.
Pushing without building is not a difficult thing to do, in-fact it will make changes much faster too. But you mention pulling markdown files from other places, merge conflicts are bound to happen that way right? And AFAICS there would not be an easy way to manage that automagically without human intervention.
No I think it'd be enough to have them separate to avoid merge conflicts.
It could probably be done in a separate step or something so users can edit files once they've been pulled in from other sources, at which point the repo becomes the source of truth.
Thank you for the feedback! I understand the confusion. Kalmia is indeed a server-side CMS, but its Go-based architecture allows it to be lightweight and run on various platforms, from cloud servers to smaller setups like Raspberry Pi.
Think of Kalmia as similar to Docusaurus, but with a built-in GUI—one of the most requested features from the Docusaurus community (https://docusaurus.io/feature-requests/p/make-content-editin...). With Kalmia, non-technical users can contribute to documentation without needing to know Git or Markdown, making content editing much easier.
We store the documentation data in a database (Postgres or SQLite), and markdown/HTML is generated only when updates, deletions, or creations happen. The built HTML is stored in memory for fast access, ensuring performance remains smooth even for large docs.
We’re also working on features like export to zip and GitHub Pages support, so users can host their docs externally if needed.
Regarding SSO, it’s a great suggestion. We’re looking into integrating Single Sign-On (SSO) to streamline user management and improve security. This will help with easier adoption in environments that already use OIDC for authentication. (We already supported OAuth with Github/Microsoft/Google)
Thanks again for your thoughtful input, and I appreciate you checking out Kalmia!
This is accurate, we also use it for one of our other products here https://docs.difuse.io/, although a demo instance for people to play around with is not a bad idea, will look into that.
For me though, the Linuxulator is about practicality today, not philosophy. It lets me use one or two tools (like the VS Code server) without changing how I actually run my system. Everything else stays native FreeBSD.
It's optional, isolated, and doesn't pollute the base system. If native ports exist and work well, I'll always prefer those. But when something critical doesn't, the compatibility layer keeps FreeBSD usable in modern workflows instead of becoming limiting.
So yeah.. I see it more as a bridge, not a direction.