Rendered at 23:53:54 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
alsetmusic 2 days ago [-]
> Sylve supports both Bhyve virtual machines and Jail-based workloads from a single UI. It also includes Samba share management and ZFS snapshot automation with periodic schedules and retention policies, so teams can run workloads and protect data from one control plane.
This is awesome! I only started toying around with Proxmox after VMware became actively hostile towards users last year or maybe a bit earlier. This is a welcome alternative in the space. It's impressive. But the reputation of FreeBSD and the inclusion of ZFS and jails from the people I trust most to build a lightweight system is pretty great and I'm excited to see how this develops over time.
xinayder 1 days ago [-]
This looks promising. I might swap my Proxmox install for this.
Now we only need Sylve Community Scripts! Although creating a new jail (I guess FreeBSD alternative for LXC containers?) doesn't seem difficult.
arch1e 1 days ago [-]
LXCs are pretty similar to jails, and Sylve makes them really easy to use. One nice trick is that you can template a base jail and clone it any number of times straight from the UI, no need to drop into a shell and script it like I used to.
Another underrated part of FreeBSD is pkg. It’s often simpler than Linux package management. For example, installing Jellyfin on Debian or Ubuntu means adding a third party repo and dealing with updates, but on FreeBSD it’s just `pkg install jellyfin`. With pkgbase, even system updates are simple, just `pkg update && pkg upgrade` and you’re done, without worrying about breaking your system.
ggm 54 minutes ago [-]
One problem with pkg and jails, is that there aren't good instructions for how you separate the "this is the current list of pkg and their status in the repo" from "this is the current list of INSTALLED pkg and their specific state and version in this host"
If this can be documented, and work with an exterior common pkg repo state, then every jail can be updated on pkg upgrade, for it's specific pkg, when the exterior state is updated for pkg update, to get refreshed for what needs to be updated.
Right now, under bastille, I do pkg update && pkg upgrade inside each jail and I therefore have n copies of the state of the pkg repo.
Trivial attempts at this wind up with every jail having identical pkg state. I don't want that: one for plex, one for vaultwarden, one for adguard, they should have the minimum attack surface of just the pkg and the necessary dependencies.
no_time 1 days ago [-]
Kind of envious of this as a Debian user.
I know we have cockpit but it never really clicked for me. Functionality wise too crashy and not so nicely intergrated, design wise it has the information density of a grandparent brick phone.
arch1e 1 days ago [-]
It’s kind of funny, Debian was my distro of choice since I was 15, so about 10 years up until last year. I still envy its huge application ecosystem. But over time I’ve come to really appreciate simplicity and the principle of least astonishment.
I originally started Sylve with an OpenWRT/LFS mindset since I had a lot of experience there. But even then, Linux often feels a bit cobbled together. ZFS is awkward because of the GPL vs CDDL situation, userland and kernel development feel disconnected, and there are so many different ways to do the same thing. I won’t even get into systemd, you get the idea.
What really clicked for me was using a system where the kernel and userland are developed together. That cohesion makes a big difference. Technically, I was able to rely almost entirely on the base OS without pulling in extra dependencies, aside from libvirt to make migration easier and Samba for file sharing.
Going forward, Sylve leans into that even more. PF for the firewall, the rock solid iSCSI implementation in base, even things like smart(8) written by src committers just feel more consistent and thought through.
So yeah, Debian definitely wins on features and applications. But for me, FreeBSD wins on coherence and design.
traceroute66 1 days ago [-]
> Kind of envious of this as a Debian user.
You do know Proxmox is a fancy UI on top of Debian, right ?
arch1e 1 days ago [-]
It’s not really just a fancy UI though.
The entire Sylve bundle (backend + frontend) is ~55 MB, fully self-contained, and doesn’t mess with the base system in any destructive way. You can drop it in and remove it cleanly.
Proxmox, on the other hand, replaces core parts of the system, including the kernel, and its package ecosystem diverges quite a bit from standard Debian. I’ve tried using it on a desktop before and rolling that back cleanly isn’t exactly straightforward.
At that point it’s more of a tightly coupled platform built on Debian than just “a UI on top,” especially when the underlying system is no longer behaving like Debian in the usual sense.
traceroute66 1 days ago [-]
> I’ve tried using it on a desktop before and rolling that back cleanly isn’t exactly straightforward.
Well, sure, but Proxmox was never intended to be a desktop solution.
It was always intended as a server solution, installed on bare-metal, and therefore "rolling-back" is a re-format and re-install (or shredding the drives if the server is being decommissioned).
arch1e 1 days ago [-]
That’s fair, but that kind of reinforces my point.
If the expected recovery path is “wipe and reinstall,” then it’s clearly not just a thin layer on top of Debian. It’s effectively its own platform with its own assumptions, lifecycle, and upgrade path.
There’s nothing wrong with that, but it’s a very different model from something that can coexist with or cleanly detach from the base system. That distinction matters depending on how people want to use it, especially outside of a dedicated bare-metal server context.
So yeah, Proxmox is built on Debian, but in practice it behaves more like a tightly integrated appliance than a simple UI sitting on top.
no_time 13 hours ago [-]
Well said, you get what I'm looking for. This might be the reason for me to give freebsd a go. Though my current hardware probably wouldn't play nice with it.
lmz 2 days ago [-]
Surely that's "on" FreeBSD not "by" FreeBSD?
elcritch 2 days ago [-]
It’s funded by the FreeBSD foundation, so “by” fits.
lmz 2 days ago [-]
But it's got a separate entity providing paid support?
c-c-c-c-c 2 days ago [-]
svelte is very new, it’s supported by the foundation not by. also the foundation is not freebsd they are two separate entities. freebsd is the developers, the foundation is a bunch of canadians supporting said developers.
traceroute66 1 days ago [-]
> It’s funded by the FreeBSD foundation, so “by” fits.
No, it is not.
FreeBSD are listed as ONE of the three core sponsors.
The other two are commercial organisations.
The GitHub repo is not hosted by FreeBSD either, it is by one of the other sponsors, "AlchemillaHQ".
There is nothing "by" about this.
"for", sure, but "by", nope.
hoppp 2 days ago [-]
Should be "built on"
broken-kebab 2 days ago [-]
Looks good! Any reason why it is not in the ports?
arch1e 1 days ago [-]
Sylve Dev here! The port is in review and the maintainers has told me that it'll be merged into the next quarterly slush (which is next week). And the installation script on the website will automatically switch to ports when it's available.
traceroute66 1 days ago [-]
The title of this is highly misleading.
It is not "by FreeBSD".
The GitHub repo is "AlchemillaHQ" who are one of the three sponsors of the project.
h4ch1 2 days ago [-]
Looks great! Love seeing Svelte being adopted in the wild.
I've been experimenting with jails on my devserver to sandbox AI agents, going to give this a whirl.
arch1e 1 days ago [-]
I would've given up on this project without Svelte 5! It’s so hard to justify React after using it. Proxmox always felt sluggish, but Sylve with Svelte stays smooth even on large clusters. DX is also much better. We started on Svelte 4 but moved early to 5 for things like runes.
This is awesome! I only started toying around with Proxmox after VMware became actively hostile towards users last year or maybe a bit earlier. This is a welcome alternative in the space. It's impressive. But the reputation of FreeBSD and the inclusion of ZFS and jails from the people I trust most to build a lightweight system is pretty great and I'm excited to see how this develops over time.
Now we only need Sylve Community Scripts! Although creating a new jail (I guess FreeBSD alternative for LXC containers?) doesn't seem difficult.
Another underrated part of FreeBSD is pkg. It’s often simpler than Linux package management. For example, installing Jellyfin on Debian or Ubuntu means adding a third party repo and dealing with updates, but on FreeBSD it’s just `pkg install jellyfin`. With pkgbase, even system updates are simple, just `pkg update && pkg upgrade` and you’re done, without worrying about breaking your system.
If this can be documented, and work with an exterior common pkg repo state, then every jail can be updated on pkg upgrade, for it's specific pkg, when the exterior state is updated for pkg update, to get refreshed for what needs to be updated.
Right now, under bastille, I do pkg update && pkg upgrade inside each jail and I therefore have n copies of the state of the pkg repo.
Trivial attempts at this wind up with every jail having identical pkg state. I don't want that: one for plex, one for vaultwarden, one for adguard, they should have the minimum attack surface of just the pkg and the necessary dependencies.
I know we have cockpit but it never really clicked for me. Functionality wise too crashy and not so nicely intergrated, design wise it has the information density of a grandparent brick phone.
I originally started Sylve with an OpenWRT/LFS mindset since I had a lot of experience there. But even then, Linux often feels a bit cobbled together. ZFS is awkward because of the GPL vs CDDL situation, userland and kernel development feel disconnected, and there are so many different ways to do the same thing. I won’t even get into systemd, you get the idea.
What really clicked for me was using a system where the kernel and userland are developed together. That cohesion makes a big difference. Technically, I was able to rely almost entirely on the base OS without pulling in extra dependencies, aside from libvirt to make migration easier and Samba for file sharing.
Going forward, Sylve leans into that even more. PF for the firewall, the rock solid iSCSI implementation in base, even things like smart(8) written by src committers just feel more consistent and thought through.
So yeah, Debian definitely wins on features and applications. But for me, FreeBSD wins on coherence and design.
You do know Proxmox is a fancy UI on top of Debian, right ?
The entire Sylve bundle (backend + frontend) is ~55 MB, fully self-contained, and doesn’t mess with the base system in any destructive way. You can drop it in and remove it cleanly.
Proxmox, on the other hand, replaces core parts of the system, including the kernel, and its package ecosystem diverges quite a bit from standard Debian. I’ve tried using it on a desktop before and rolling that back cleanly isn’t exactly straightforward.
At that point it’s more of a tightly coupled platform built on Debian than just “a UI on top,” especially when the underlying system is no longer behaving like Debian in the usual sense.
Well, sure, but Proxmox was never intended to be a desktop solution.
It was always intended as a server solution, installed on bare-metal, and therefore "rolling-back" is a re-format and re-install (or shredding the drives if the server is being decommissioned).
If the expected recovery path is “wipe and reinstall,” then it’s clearly not just a thin layer on top of Debian. It’s effectively its own platform with its own assumptions, lifecycle, and upgrade path.
There’s nothing wrong with that, but it’s a very different model from something that can coexist with or cleanly detach from the base system. That distinction matters depending on how people want to use it, especially outside of a dedicated bare-metal server context.
So yeah, Proxmox is built on Debian, but in practice it behaves more like a tightly integrated appliance than a simple UI sitting on top.
No, it is not.
FreeBSD are listed as ONE of the three core sponsors.
The other two are commercial organisations.
The GitHub repo is not hosted by FreeBSD either, it is by one of the other sponsors, "AlchemillaHQ".
There is nothing "by" about this.
"for", sure, but "by", nope.
It is not "by FreeBSD".
The GitHub repo is "AlchemillaHQ" who are one of the three sponsors of the project.
I've been experimenting with jails on my devserver to sandbox AI agents, going to give this a whirl.
Jails are great if your packages are in ports, and if not, Linux jails work well too: https://sylve.io/guides/deployments/rocky-linux-jail/, Haven't hit a CLI app that doesn't run in a FreeBSD Linux jail yet!