I wonder when this will make it into pfsense... The transition to kea has been a bit of a mess with tons of bugs. Thankfully it's controlled by an option, and it seems like 2.8.0 knocked out quite a few of them
I have been using Kea on pfSense CE for a long time — I think it was version 23.0.x. Or you mean 3.0 in particular? I also have OPNsense and I am not completely convinced of their aggressive update strategy yet. For a firewall, I prefer stability over features. Jumping to the newest releases every month can have tradeoffs.
Note: in general, both OPNsense and pfSense are excellent. I have never had any problems with either one.
I use pfSense CE, and rely on DNS entries to be automatically created for DHCP addresses. That worked fine for more than a decade, until they made Kea the default a couple of years ago (or did they just put a bunch of notices in the interface that old DHCPd was deprecated? It's been long enough that I don't remember).
Anyway, at the time Kea (at least in pfSense) wasn't able to do that, which caused things to break for me for a bit. It's a small thing (and, I mean, totally fair with free software) but the fact that they pushed an update to Kea before Kea (again, at least in pfSense) was at feature parity rubbed me the wrong way and has kept me from using it since then.
(edit: on the off chance anyone cares, I decided to check and it looks like this issue has been fixed as of pfSense CE 2.8.)
I don't follow pfsense too much but my understanding is OPNsense typically brings in package updates faster as they have a more frequent update cycle. I can't speak too much to bugs as I haven't migrated to Kea but imo some core functionality wasn't there until recently. And Dnsmasq seems like a better fit for me anyway, which is where I'll migrate to.
From the 25.1.6 OPNsense May update notes:
> Last but not least: Kea DHCPv6 is here. And with it full DHCP and router advertisement support in Dnsmasq to bridge the gap for ISC users who do not need or want Kea. We are going to make Dnsmasq DHCP the default in new installations starting with 25.7, too. ISC DHCP will still be around as a core component in 25.7 but likely moves to plugins for 26.1 next year.
I've been using it on opnsense since the first version it was released in. I aggressively switched because wanted to ditch my weird setup to do multi subnets (forwarding though a l3 switch). Haven't had any issues.
16-bit 44 Khz almost perfectly reproduces human hearing. It wasn't a coincidence that the makers of CDs chose it. Anything above is studio-grade stuff to give extra headroom for editing (applying filters in studio editing can amplify noise which is unwanted, for just playing audio there are no advantages).
With standard Bluetooth codecs you get nowhere close to that and there is a significant noticeable delay for video content. Headphone jack is easy to make IP68. All rugged phones have it and all non-rugged ones have a USB port which is bigger and more irregular than a frigging circle.
A much more useful (in the educational sense) question to ask, in my opinion, is the resistance between opposite corners of a cube of 1ohm resistors. There are some neat intuitions it can help build (circuit symmetry, KCL, etc). The infinite grid is too much an obscure math problem that seems like it might be solvable in an introductory circuits class.
It'll be a long while before either gets enough traction to be serious competition to system erilog, even if SV is, compared to modern software languages, outdated.
This looks much more likely to succeed tbh. Similar enough to SV that you can piggy back off the features that you're likely never going to replicate (SVA, functional coverage, multiple clock domains, etc. etc.) but also fixes the footguns.
As the author of Veryl and an ASIC frontend engineer, I aim to enable smooth transitions from existing SystemVerilog projects, making it immediately applicable to ASIC projects. (In fact, it’s already being applied to an ASIC currently under design.) I see languages like Spade and SUS as HDLs for a slightly more future-oriented.
Then could let everyone start with 100 one star ratings. If they rate their first thing it counts as 1/101 vote. If they start with a one star rating it will be their highest ever.
Alternatively you could apply the same rating to the customer and display it next to their user name along with their own review counter.
What also seems a great option is to simply add up all the stars :) Then the grumpy people wont have to do anything.
I really like the idea of immutable Linux and bootable containers. My next project will probably be switching to bazzite. But I took a look at the Containerfile[1], and I have some big concerns about the fragility of their supply chain. It uses 20 different copr repos (granted, half are their own), and I didn't count how many packages. Best I can tell, none of the versions are pinned. They do dump a diff of all package versions in the release notes[2], but I wonder if anyone actually reviews it before release. All it takes is one vulnerability in one repo / package and you can enjoy your new cryptominer.
There's something nice about running Debian and having confidence in all the packages because they're built and maintained by the Debian team. Of course there are exceptions, but in my experience they're rare. The only non-standard repo I regularly use is fish shell, and the updates are so few and far between (and very public) I think the risk is low.
I suppose this isn't strictly a container-specific problem; you could add the repos and install / update all those packages yourself too. But being able to package everything up into a single file that you can then boot into as your OS means you're also packing all the supply chain risk.
Curious if anyone else shares my concern or if I should just put my tinfoil hat back on...
> It uses 20 different copr repos (granted, half are their own), and I didn't count how many packages. Best I can tell, none of the versions are pinned.
Contributor here, we've been working on this diligently over the past cycle (the rest of the org is mostly done, Bazzite is largest so we're only getting to it now). We're hoping to be done over the summer with published SBOMs and all that good stuff.
That's good to hear; I'm definitely a fan of SBOMs. But it doesn't fully address the risk introduced with automatic selection of the latest package version. If a package has no dependencies, for example, the SBOM wouldn't change if it were compromised with something that's compiled in to the package...
Nothing holds you from using bootable containers in the same way you use Debian and only use packages from the official Fedora repositories, starting from Fedora's bootc base images.
I agree with your concerns—at least, last time I looked.
I looked over their code, saw some things (I believed) I would do differently, and it was very easy to make my own personal spin to use.
After doing that, maintaining it, and using it daily for the last year I went back on some of my original choices. I feel much less critical of the decisions Jorge Castro made and it's probably time to compare and contribute if I can. Like, Homebrew on Linux ended up being way better than I expected. But some things I liked better my way. Say, including the signing keys for Chrome's 3rd-party repo statically instead of fetching them over the network. (Writing this from my phone I don't exactly remember how they do/did it.)
Overall, I'd recommend trying it yourself! It's been a ton of fun.
> Say, including the signing keys for Chrome's 3rd-party repo statically instead of fetching them over the network.
This is a fantastic idea, it sucks to have an upgrade blocked by a slow repo, if you wouldn't mind filing an issue or sending a PR I'd love to have this. Thanks for the feedback!
I switched from official Fedora images when I got sick of dealing with nonfree stuff like codecs and nvidia drivers. They have much more lightly modified images that are better as a base to build on. I use https://github.com/ublue-os/main (and https://github.com/ublue-os/hwe for an nvidia system).
Right but everytime a new immutable release is created, it automatically pulls the latest version of every package. It's not a manual change of package versions.
Have you considered making something more expensive with better performance? Commercially? You mention Keysight VNA's in the $10,000+ range, but we regularly buy VNA's in the $100,000+ range. I imagine with a $1000 budget you could do quite a lot.
I've been pretty happy with its search and have never had issues finding emails. The UI isn't great and theres a lot of cruft to filter through but it does work...
