kevans91

One might be interested in the not-very-alive FatELF implementation, though: https://icculus.org/fatelf/

While not receiving a response isn't ideal, I note that we actually have two secteams: secteam@ and ports-secteam@; something like luatex should go to the latter, but their level of activity has been kind of hit or miss in my experience. Curating security issues in ports is kind of hard due to the size of it and we probably more often than not end up getting hit with patching things a little after disclosure because of it.

It's on the FreeBSD Foundation's roadmap: https://github.com/FreeBSDFoundation/proj-laptop/issues/22

Illumos keeps the tradition alive: https://src.illumos.org/source/

fwiw, characterizing Andres as a sysadmin isn't really the whole picture; he's a postgres developer that conducts benchmarking operations with some frequency (and he's quite good at what he does)... he's perhaps naturally a bit more sensitive to things like the cumulative effect of 500ms or so over a number of sshd invocations.

To be fair, for the vast majority of FreeBSD users flua is essentially nonexistent; it was pushed off into /usr/libexec and renamed so that it doesn't get used by consumers of base in such a way that it can't be updated.

We (FreeBSD) should really reconcile our diff against OpenBSD and figure out what of the work I've done downstream makes sense and what doesn't. I'd imagine there's a healthy amount in both categories.

Also worth noting, while we're here, that there is a patch set from a GSoC project to integrate mfsBSD into the project's release(7) tooling:

- https://reviews.freebsd.org/D41704 - mfsBSD: Vendor import mfsBSD (mmatuska/mfsbsd@0da8061)

- https://reviews.freebsd.org/D41705 - release: Integrate mfsBSD image build targets into the release tool set

- https://reviews.freebsd.org/D41706 - release(7): Add entries for the new mfsBSD build targets

Right, in this case specifically we're running off a limited bootstack allocated in the kernel's .bss (somewhere between 2 to 6 pages, generally); we won't finish initializing VM until shortly after this sort is done (in some of the SYSINITs that we're sorting).

> [...] But if you use pkg, and the new point release added a syscall, you will have problems installing new packages (or upgrading) once the package builders update; I don't quite remember the timeline, but it's usually a few months after the point release. [...]

The previous release in the branch gets dropped after ~3 months, probably aligned to the end of the month that its EOL lands in; then pkg builders switch to the newer release in the branch.

Yes, this is great... I was given a Macbook with a Norweigan keyboard for testing a port of FreeBSD on it, and I quickly discovered that the keyboard layout remapping stuff available via the UI won't remap at least this one key to what I'd find on my US keyboard.

Race conditions in places like this are exceedingly hard to write reliable tests for. It may take one, two boots; dozens, or thousands, or you may just get insanely lucky and whatever arbitrary # boots you do to try and reproduce it was still simply not enough. It's hard to have any level of confidence, in many cases.

iocage as well... I've been trying to sucker someone into writing a new jail manager in flua, since we have that in base. It hasn't worked yet.

Not sure we have anyone that could really call themselves a maintainer for sed, but I am a FreeBSD committer that has put thought into this problem in the past.

I'd like to change it in FreeBSD, but haven't really (yet) come up with a clever way to make it work without breaking years of scripts that may be using -i.

It depends on how you were running before -- if you had the wireguard-kmod package, then yes, the only difference is that you don't have to install it manually. If you only had the wireguard-go pkg before, then see the other responses where you'll now be using the kernel implementation instead of userspace.

edit to note: we can't really provide wg-quick in base at the moment (uses bash-isms), so that still ends up needing installed manually if wg(8) isn't sufficient for your needs.

Colin's done a lot of work in improving boot time on EC2 and in general, so I'm a little surprised he didn't actually mention the boot time in this article. In 2022Q1 he had boot time down to 8s (in EC2, IIRC); based on how cut down the FIRECRACKER config he added is and that there's no loader involvement, I don't think it'd be too surprising if he hits ~5-6s or less.

FWIW, I have no interest in making a similar change to bsdgrep and I can't imagine anyone else would be compelled to bother, either. I just don't see the value in removing these historical names that makes the hassle worth it.

IMO it was just a relatable example of a somewhat extensive user of netlink that demonstrates compatibility. Some folks may want to run it under the Linuxolator, which seems reasonable.

I only have limited knowledge about netlink, all coming from a devsummit presentation by Alexander, but it seems like an actually good generic kernel interface to have.

minor nit: /usr/local/bin as it comes from ports

I read that as "the hardware is failing but FreeBSD is still trucking right along"

I'd be concerned about the non-zero number of PHP CLI apps that exist in the wild, though.

Right, platform specific. On FreeBSD, we have SO_REUSEPORT_LB for load-balancing.

Only a number of years too late...

It's worth noting that as far as changes in FreeBSD forbidding long-standing permitted behavior goes, this one was notably very uncontroversial.

As I said in the previous post, the first half of it just landed within the last month. iwlwifi[0] and dozens of linuxkpi commits[1] over the past couple of months by bz@. My frame.work laptop works generally well with -CURRENT (and presumably with stable/13, since iwlwifi's been mfc'd) with some wifi stability issues that have been reported.

[0] https://cgit.freebsd.org/src/log/sys/contrib/dev/iwlwifi [1] https://cgit.freebsd.org/src/log/sys/compat/linuxkpi

That's an odd and misinformed attack on the foundation. They're actively sponsoring WiFi work, the first half of which recently landed in tree. You can see what they're involved in on on their website: https://freebsdfoundation.org/our-work/projects/

It was quite blown out of proportion even outside of the published articles.

I work with Klara; I can attest that there are definitely some interesting people here. :-)

I note that the author of the comment you're responding to and the author of these commits is one and the same, fwiw.

No, wayland bits generally run well enough without needing the linuxolator.