kevans91

Minor nit that we mostly hadn't moved to GPL3 stuff, and now we're working on replacing the remainder of the GPL2 stuff.

I interpreted it as a missing 'if'...

> Even [if] I was interested before, ... after reading this?

I personally don't see the need, pfSense is rock-solid for my uses.

pkgbase? We split base up into packages and deploy binary updates via our package manager, pkg(8), instead of with patches distributed via freebsd-update(8). We have a lot of build knobs that can make some parts optional, and some of those get turned into their own pkgs that end-users can simply not install (or remove) rather than having to manually extricate those or rebuild with some knobs set.

You can find a better (though slightly outdated) description here: https://wiki.freebsd.org/PkgBase

Pretty much anything that would need to come from Broadcom, really

The docs that most recently bit us are pcie/ethernet on the RPi4; I got in touch with Broadcom, who is now in a multi-year effort to figure out how to disperse usable docs (under NDA?) to the broader community. I lost faith after 9ish months of poking and getting back "oh, you know how it is" in response.

I speak as a FreeBSD developer who has dabbled with RPi, having tested and shuffled in a lot of the initial RPi4 patches and did some not-insignificant hacking to get a single RPi image to actually support RPi3 + RPi4.

Speaking from personal experience, it's an absolute pain -- they're already an odd duck (w.r.t. booting, for instance), add on that the documentation is incredibly lacking compared to competitors and you've got a platform that's not too appetizing.

Allwinner and Rockchip tend to be pretty solid, as far as SoC go; start here: https://wiki.freebsd.org/arm

This is pretty unlikely, unfortunately. We're generally looking out for a Pi maintainer because it doesn't really have one -- it's not the most desirable platform to hack on, from a developer POV.

That's just 2021- check back at 2020 and you'll find a couple more.

Yeah, sorry, I'm mostly lamenting that there's not a more objective overview. This whole situation is pretty tiring at this point, so it's unlikely that one will surface except as a post-mortem down the road.

FWIW, "good review" is pretty debatable (source: was involved) -- it provides a decent overview, but you should read it with the thought in mind that the author did some pretty heavy cherry-picking to support their arguments. Also, this indeed is not "Kernel Debugging Quarterly."

I was linked back to your reply because it seems that I've not really communicated this very well- there's nothing wrong specifically with how you represented the situation, and I'm sorry if I came across as angry about you specifically. Read the rest of this in that same tone.

I'm angry that this has blown up like it has, and I realize that Netgate hasn't helped themselves out at all with the statements they've been releasing. If I was a PR person, my immediate reaction would have been "Hey, we're pulling this from the build. Know you guys were all excited about it, but points to press release"

I'm trapped here, you know? I can't speak for the proportions of how bad it was because I'm just a kernel guy, not a security guy. If I say "I don't think it was really that bad," I can pretty much immediately be written off as unqualified to make those kinds of statements.

We did end up nearly entirely rewriting the driver, but a significant chunk of that was removing iflib to fix a load of vnet issues and simplify it. I'm proud of what we ended up with, but I'm not proud of how this was handled by pretty much everyone around me.

Finally, to me, the deadline was very real. I thought we could end up with something that I'd be able to merge in time for 13.0rc3 (builds started today) in a relatively non-disruptive manner. It wasn't until most of the time was up that time had passed until I realized what we had come up with, and started hoping that I could still pull it off with significant testing.

I've been trying to stay quiet here because I just want to part ways, but the last sentences here got to me.

This wasn't a "mission to fix if_wg," at least it didn't start that way, and I think that it's important to acknowledge that my motivations here weren't exactly what's happened.

Let me start with: folks can hate me for this, but I generally like mmacy. I don't like specific things he did with this driver, but we usually get along. I don't really like how he's getting dragged around like this.

Now, this didn't start as a campaign to fix what was put into the tree, or to get Matt hit with the crap-bombs he's been dealt. This is the rough sequence of events:

- I use openvpn

- I don't like my openvpn setup, let's try if_wg

- oh, there are a couple problems here, let's fix those

- ok, what would it take to get wireguard-tools support?

This is where I get in touch with Jason.

- "oh, we gotta fix this"

- yeah, I can believe that

Cue hackathon session, we fix:

- All the jail bugs I can spot

- The race conditions we spot

- Number of panics

- Buffer overflow

- Privilege check

- Resync a lot of stuff with OpenBSD

- A number of things that I don't see, but I'm not a qualified expert in the area

Then we're here, where the stories start dropping and all hell breaks loose. For me, this isn't a story about how skilled people rallied to get it together, this is a story I'm not particularly proud of.

No further comment, because I'd like to get back to what I do. I know this isn't going to end well for me, so I likely won't check back.

Personal project:

> This is a personal project, not backed by the author's employer.

Note that there's additional follow-up available here: https://lists.freebsd.org/pipermail/freebsd-hackers/2021-Mar...

Oh man, this brings me back to writing Redvex plugins long ago... looks like it's gone far, far away.

I think someone reported the latest firmware or something pulling some shenanigans if there's no display connected, whether we use it or not. I don't recall the specifics at the moment, though.

FWIW, RPi 4 is fraught with peril on FreeBSD < 13.0 -- and even if you could have gotten it to boot, you'd find neither ethernet nor USB.

FreeBSD >= 13.0 has an aarch64 RPI image that should boot OOTB for both RPi3/RPi4 -- the medium article referenced predates the introduction of this image, and it should generally make all the firmware steps obsolete. The dts replacement might still be necessary with it, I hadn't really looked at the differences between the one placed in review vs. upstream.

This is outdated; the RPI3 image has been removed for 13.0/14.0-CURRENT with a new RPI image that should serve all (~both) aarch64 Pi.

Sorry, a bit late; the ARM64 "RPI" image should work out of the box and recognize all of your RAM.

> However, BSD's do not guarantee that their userlands will work with a mismatched kernel. Sure, it often does work, hence why jails only give a warning on mismatch rather than refuse to run at all.

FWIW, FreeBSD tends to go to pretty great lengths to ensure newer kernel with older userland works. A stock GENERIC kernel comes with COMPAT_FREEBSD* options back to COMPAT_FREEBSD4, and parts of the project's infrastructure tend to explicitly rely on at least supported releases to be functional in a jail on a -CURRENT kernel.

Ugh, that's unfortunate. =\

After looking at this repo more closely, this really is pretty suboptimal. build.sh is incredibly flexible, but yeah- no documentation on what you'd need to build a non-pfsense branded product.

That's pretty weird, given how much of this system seems to be geared towards being generically applicable and has some replacements aimed directly at rebranding some literal occurrences of "pfSense".

I haven't tried it, but this doesn't seem to be the case anymore. Notably, [0] is clearly a pretty up-to-date copy of the stable/12 that they're almost certainly running given some of the recent direct commit references (e.g., patch pulled from [1]) and that it has a wireguard kmod that hasn't actually been ported to this branch upstream.

I would guess that pfsense/pfsense should be able to build it, but you probably won't have any luck on !FreeBSD/pfSense.

[0] https://github.com/pfsense/FreeBSD-src

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252894

Huh, cool!

Are all Prosody modules pure-lua, or can/do some have a C/binary component to them? I note that the API documentation describes only lua bits, at least.

I can't speak for anyone else, but from my perspective (and I suspect others are similar): I like the idea of a jail-backed OCI runtime, but it's not interesting enough to my personal use to overtake any of the other OS-adjacent projects I'd otherwise work on in my spare time.

I could be convinced (well, paid) to make it a higher priority, but ultimately it's currently at the bottom of a barrel of much more enticing fish since I'm not really in the demographic that that kind of stuff targets.

A little late to the party, but- MacOS has actually beaten FreeBSD to the punch by shipping with bsdgrep as grep for years at this point.

FreeBSD should be able to switch before 13.0, but the bsdgrep developer is a slacker. It's only missing a couple of GNU extensions that are somewhat surprisingly (to me) common.

I see no reason not to also provide the compatible long option on FreeBSD: https://svnweb.freebsd.org/changeset/base/365954

Note that we haven't yet introduced .lua configuration capabilities (that's a project branch off to the side), but it does certainly make modifying menu entries and other fun stuff a lot more palatable in my experience.

Yeah, this... though it'd be awesome if they updated their setup for working ZFS boot environments OOTB. Last I checked they were setting vfs.root.mountfrom explicitly in /boot/loader.conf.local, which is not stellar. =-(

Generally- so far, flua only drives the generation of the various files we derive from syscalls.master.

There's been some WIP to also use it for some pkgbase stuff, as well as an ldconfig lua script for use in post-install scripts now that pkg supports post-install.lua.

I've had my eye on a couple of other components that could use a rewrite with flua. A new flua-based replacement for kernel config(8) could be quite excellent, for instance.