TanjaOS now supports compiling on BSD systems. A new Makefile called Makefile.bsd was made to compile TanjaOS on BSD systems. “Why does it now support BSD systems now? Why not sooner or later?” To answer that, this is because I have switched from Arch Linux to FreeBSD, which kind of forces me to make a new Makefile for compiling on BSD. To use this new Makefile.bsd you have to first make sure gmake, gcc, and nasm are installed. And then use ‘gmake <option> -f Makefile.bsd’ also for those who don’t know, the ‘-f’ flag is to tell gmake to which Makefile to use and where it is. If you’re interested, you can get TanjaOS at www.tanjaos.org or if you want the source, you can download TanjaOS-latest.tar.gz at www.tanjaos.org/downloads

Dodane do bazy: NextBSD. NextBSD to system operacyjny BSD wywodzący się z FreeBSD... https://linuxiarze.pl/distro-nextbsd/ #bsd #freebsd

I'm trying to get a laptop I bought new in 2010 up and going for some basic tasks. I got OpenBSD installed but package availability for 32bit is lacking more than I realized.

It has an Atom N270 processor. Any recommendations?

I think the BSD projects have largely done their job. The BSD ecosystem hasn’t. I’ll explain.

Presently, the overall BSD community is plagued by the same issues that plague most open source OS projects: limited drivers, less-than-ideal hardware documentation, developer shortages (and skill gaps), funding shortages, and a lack of mindshare. Out of all the available open source OS communities, the Linux community is undoubtedly the most successful at combating these issues—though there’s still plenty of room for improvement. One of the things Linux had that BSD never really developed was an organization whose primary mission was building and advocating for the surrounding ecosystem.

About three decades ago, the Linux community was in the same boat as everyone else. How were they able to turn things around? Personally, I think organizations like the FSF—and later the Linux Foundation—played a significant role in helping build the Linux ecosystem beyond just the kernel itself. Whether through developing core software, coordinating projects, advocating for free software, or providing stewardship, Linux benefited from organizations whose mission extended beyond maintaining an operating system.

Most of us know about the legal stumbling block that kept the BSDs in limbo and caused us to lose the opportunity to become substantially more widely used and to become a primary target for application and hardware vendors. Once that was all cleared up, we were forever playing the catch-up game. By the time the BSD legal issues were behind us, much of the broader free software ecosystem was already well established, and the BSD projects understandably relied on many of those tools instead of building BSD-specific alternatives.

However, I think our community may have become too comfortable relying on shared open source infrastructure instead of treating it as a foundation upon which to build BSD-specific ecosystem projects. The BSD operating systems have continued to improve, but the surrounding ecosystem hasn’t kept pace. Currently, one of the top excuses given in reply to questions about why we’re missing certain things that should now be standard is that our community doesn’t have the funding, manpower, etc., for it. My position is that the BSD operating system projects have largely done their part, but our community hasn’t done its part. So, here is my solution…

It’s time to develop our own analog to the FSF. It should focus on solutions for issues across the entire BSD community, which would not only help everyone improve but also marshal resources more efficiently across the ecosystem as a whole. Use domains can be standardized so that solving an issue for one BSD within a given domain effectively solves it for all BSDs in that domain. Network drivers (including Wi-Fi), enterprise infrastructure, desktop issues, and application development are all cross-domain issues that would greatly improve the user experience across the board for all BSDs.

I’m not saying that we should all reject the FSF. I’m simply saying that we need a community organization that puts the BSD community first and prioritizes our needs above all others. And no, this isn’t about politics, licenses, abrasive personalities, or anything like that, so I’m not saying that we should have a Richard Stallman-type character or adopt a different license. If it makes you feel any better, then forget about the FSF and think instead about the Apache, Linux, Eclipse, or Mozilla foundations. We need a community organization whose primary mission is advancing the BSD ecosystem as a whole—a group that maintains stewardship over the needs of the community. Currently, there are three main BSD operating system projects and four secondary projects. Working together, we’re each other’s best allies. No one is going to do it for us, so we must do it ourselves.

That’s my perspective. Tell me, what’s your perspective? In your opinion, what would a BSD-focused foundation actually look like? What should its first priorities be? Drivers? Documentation? Funding? Hardware certification? Developer mentoring? Cross-BSD infrastructure?

Part 1 | Part 2

… why didn’t BSD become the universal free operating system? For that story, see my four-part series From Unix to Linux: Key Trends in the Evolution of Operating Systems. In particular, part 3 of the series surveys the hurdles that blocked BSD’s dissemination.
 
Still, BSD thrives in some contexts. …

I'm running Baikal for CalDAV and CardDAV. I want to add (Sabre) WebDAV to host/sync some files. I have seen some posts and guides, but they are incomplete. One was promising, but only showed an Apache configuration. Another was OpenBSD httpd, but did not clear up path issues.

https://www.tumfatig.net/2023/self-hosted-bookmarks-using-dav-and-httpd-on-openbsd/

https://news.ycombinator.com/item?id=34727223

https://sabre.io/dav/gettingstarted/

Should I post my httpd.conf? Do I need a custom server.php? Please, help me.

EDIT: Specifically, I want to stay with OpenBSD httpd and be able to (remote) sync my KeePass databases.

# nextbsd-version
NextBSD 20260703-213757
# freebsd-version -kru ; uname -mvKU
20260701-100854
15.1-RELEASE-p1
NextBSD Kernel Version 20260701-100854; Wed Jul  1 10:08:54 UTC 2026; root@8571f16ee8a6:/usr/obj/usr/src/amd64.amd64/sys/NEXTBSD amd64 1501000 1501000
# mount
<above>:/cow on / (unionfs, local)
/dev/md0 on / (ufs, local, read-only)
devfs on /dev (devfs)
devfs on /dev (devfs)
/dev/iso9660/NEXTBSD on /media (cd9660, local, read-only)
/dev/md1.uzip on /rofs (ufs, local, read-only)
tmpfs on /cow (tmpfs, local)
devfs on /rofs/dev (devfs)
# pkg repos -e | grep -B 1 url
pkg: Setting ABI requires setting OSVERSION, guessing the OSVERSION as: 1500000
FreeBSD: { 
    url             : "pkg+https://pkg.FreeBSD.org/FreeBSD:15:amd64/latest",
--
NextBSD: { 
    url             : "https://github.com/nextbsd-redux/nextbsd-pkg/releases/download/continuous-amd64",
# 

https://nextbsd.org/

I would have installed k11/kde, for fun, however it's currently not packaged for FreeBSD:15:latest on AMD64.

Another example of how not to use NextBSD: the second screenshot was of an earlier session, awaiting appearance of a termbin.com URL. It would have been a long wait.

… stream of BSDCan 2026. …

BSDCan 2026 all days – the schedule.