The nfs rpc_lockd_flags and rpc_statd_flags was moved out of the ${name}_precmd() function and that broke things creating this regression.

I posted a patch to fix the 15.1-RELEASE nfs flags regression: bugs.freebsd.org/bugzilla/show_bug.cgi?id=296233#c2

There is also an easy workaround to implement until the problem is fixed in the next patch release.

jfc bugs.freebsd turned up their anubis

my fucking lptop fan kicked on

rtprio: Because of Anubis? Lol

Wow that is pretty slow on my laptop too. It didn't heat up and turn my fan on but it was like 20-30 seconds to get through it.

Okay. Now I gotta test it.

Whoa!

This has to be a mistake. Why did they turn the level up that high? Haha

That was definitely a good 15 seconds.

No fans or anything (but my laptop is no slouch). But even over 3-4 seconds is a LONG time.

"Don't sell yourself short, ek. Your laptop is an incredible slouch!"

hello folks

ek: yeah, usually difficulty is 2, this is 6, it took 30 seconds or more

oh god, Anubis in front of FreeBSD sites, yeah that is such a thing that makes me put on my shoes to go outside instead

www is dead. Switch to gemini over HF radio and never look back.

boru: isn't encryption banned on the radio

i mean, i'm not sure we've seen any reasonable alternatives to Anubis proposed

LXGHTNXNG: doesn't seem to stop meshtastic and friends.

git.gammaspectra.live/git/go-away fortasse?

boru: it's at least true specifically for radio amateurs, where they are operating under the conditions of their licence, which conditions are the main conditions much of the general public would be permitted to operate on HF under

I'm aware, I have licence.

"to obscure the meaning ..." unless you're controlling satellites or RC vehicles

at least in the US

what's wrong with anubis, it keeps many websites up and running in the modern era of AI harvesting

its annoying but what can you do, its just the nature of 2026

i will say i've not "failed" it yet, just wasted a second or two each site. and i can't say that about the centralized alternatives

Anubis is incompatible with browsers like Dillo

My understanding is that go-away is only incompatible in an absurd paranoia mode; most scrape bots don't pretend to be Dillo, yet.

Anubis is also hypocritical, being written with the same AI bots that are slamming your sites and making you need it

my understanding - I may be wrong - is that go-away is not

uh, it wasn't written by a bot

i don't believe. in fact i recall the author is in this channel from time to time

I have met the Anubis author Xe in person and I will vouch that she is a real person. You can watch on YT her lightning talk on it presented at BSDCAN 2025.

LXGHTNXNG: not sure where you're getting that AI & Anubis theory from. I know of nothing to substantiate it.

Anubis was written by a human. Xe's use of LLMs was for a specific implementation and generating piles of test cases, which, considering the product is _to reject LLMs_ seems like a uniquely appropriate use case.

hi

Speaking of :)

heh, kilostars

One of the kinda clever things I use locally hosted language models for is seeing if documentation is understandable

and by locally hosted i mean the box that is in my office that i can look at and only uses 130W power max running a very small model (Qwen 3.7 36b-a3b)

(though it usually idles at like 5 watts)

god i need more ram, i'm probably gonna have to buy another one of those boxes :(

hard part is figuring out a hostname

current box is zohar because it kinda looks like the zohar from Xenogears

ok, what box is it that only takes 130w

DGX Spark

and will it cost less than the memory to fill it

yes

god yes

128Gi of ram that will work in my tower (because AM5 is stupid) is like $7500 CAD

Starting at roughly $4,000 to $4,700, .. . oof

DGX Spark is $6700 CAD and comes with a 4Ti ssd which would be an additional $2000 CAD

plus taxable business expense so girl math makes it free

LXGHTNXNG: one cannot know how to combat a thing without understanding how that thing works in intimate detail

believe what you want though

if you think i'm evil, there is not likely much i can say to sway your opinion otherwise

my steam rig takes more power than this :|

if you're also thinking that because my job makes me use generative AI tools and i haven't quit out of protest, i don't currently accept complaints about my employment situation that are not also included with an equivalent or better job offer attached

well, i'll add it to the list of things to buy when i find a duffel bag full of cash

(note: **offer**, not **opportunity**)

yeah rtprio it's kinda nuts

my tower's 4080 uses more power idling in ffxiv than the entire box does doing AI model finetuning

unforced slop use is unforced slop use

go unforce your opinions somewhere else

Are opinions not allowed on IRC now?

Apparently not.

also LXGHTNXNG Anubis does work with Dillo if the administrator configures the meta-refresh challenge mode

if **the administrator**

thus, their problem, not mine

i mean, tbf, this isn't really the forum for AI rants; #freebsd-social would be a bit more appropriate

This discussion tags onto one about the HTTPS service at freebsd.org. So it started ontopic and then kinda just fell off the motorway.

yes, you're welcome to create a port of whatever Anubis alternative works and try to convince clusteradm@ to use it, but it has to be pretty effective

kevans: but they did turn up the difficulty lately, yeah?

it solves real problems that created complaints from our users, so it's not like it just got deployed because it's the going trend- it happens to be very easy to deploy

I've been working on a database of known datacentre IP addresses after trying and failing that way

no idea re: difficulty

(I've also been recovering from some pretty major surgery, which is why development has been kinda stalled)

I think it did crank up the difficulty. Modest laptops such as my Thinkpad X270 take 20-30 seconds to pass the challenge on bugs.freebsd.org now.

yeah, the worst offenders have started using headless chrome

i've been trying for at least half a year to try and identify headless chrome better up to and including using a ralph wiggum loop to try and identify it better

IMHO, stonewalling them isn't the way to go. That just becomes an arms race. If they fail the anubis gate, send them off to a tarpit and let them run up their electricity bill.

And poison their data set.

anubis invoking a script with failed client details would be kind of cool, but maybe also problematic with incurred load for each bot that failed? I guess that tapers off, though

(if you're just promptly tossing them into your firewall rules)

small problem there

if the client fails because the JS isn't running and the HTML isn't being interpreted by a browser

there's no way to know if it actually failed or not

fair point

i reckon you risk just blocking legitimate users with shit luck in their browsers often enough to be annoying

Xe: i didn't realize you can just chain all sparks together

kevans: i mean the false "block" rate is already kinda too high because people will anger at me and sometimes email my boss calling me a threat to children because i built anubis

Xe: yikes. I've only really had problems with what I assume must be poorly configured deployments

it's a hard balance to meet

i'm working on a lighter weight proof of work challenge using webassembly

which i expect will get people angering at me

but i also am compiling the webassembly to JS a-la the birth and death of javascript

the problem is that people that disable wasm also usually disable the JS JIT (the thing that makes javascript fast) so

/shrug

ain't no winning in detroit

leads to finding fun bugs though

like this one in LLVM: llvm/llvm-project #204883

(first legit compiler bug of my career)

lol

the reason for that ended up being blog-worthy: xeiaso.net/notes/2026/anubis-wasm-vendor-binary

oh heck i need to test the wasm stuff on freebsd

it should be fine, but i don't know if wazero's jit works there or not

Certainly worth testing!

<kevans> i mean, i'm not sure we've seen any reasonable alternatives

^^ This right here. Anubis works fantastically for me (and many, many others).

I'm not sure why bugs.* has raised the level to what they have, but surely there must be a reason. Even if it was accidental or just testing something.

It's not a terribly big deal, but I do understand some people's frustration with waiting 30+ seconds to continue moving forward.

it was getting pounded with LLM shit causing breakage

zi: Of course it was.

Before I put Anubis into place, one of my web servers was literally being pounded so hard it was no longer able to keep up. Fans, CPUs, RAM all at 100%.

ek: the thing people don't get is that it's either annoy people or take the service offline in many cases :/

Xe: Sure. In my case, I'd rather annoy people for a few seconds as opposed to annoy them them their entire site visitation by have super slow responses.

Anubis works great!

I try <3

anubis does not take 30s for me

maybe 3-4s

it's luck-based

Never seen 30sec either, even on older devices... bugs.freebsd.org took about 3 or 4 sec

I know you do and I'm very thankful. So, thank you!

ah same time

yeah half of my problem is that i believe in the axiom of pay for better hardware or pay in your time

zi: This was yesterday on bugs.* and may have changed now after things slowed down.

money is replaceable but time is not

It wasn't 30+ for me (but it was 15-20).

so i tend to buy allyesconfig machines lol

Just checked. Difficulty dropped to 4 so definitely quicker.

yeah, the new wasm checks are much more granular

i didnt read all of the backscroll--is there a specific problem?

And, again, it doesn't really bother me. It's a one-time thing for that session. I go ahead and get my stuff on bugs done.

the current ones work difficulty being matching nibbles (4 bits), the new ones is bit-wise granularity

zi, The trigger for this was that bugs.freebsd.org cranked up the difficulty and it caused longer than normal delays.

i think the cool part about the new one is that i have the same .wasm code running on both the client and server

zi: Not a problem. Just someone noticed it was taking 30+ seconds to access bugs.* yesterday via the Anubis difficulty change.

rwp: ah ok. yeah--we had $things pounding the crap out of the instance to the point where it was unusable

it does add rust to the build closure of anubis, but i can't avoid that

zi, I understand. I fight that problem on other servers myself. It's a global problem.

It's a thing.

(doing the equivalent in Go would add at least 10Mi to download sizes for the solver wasm blob, which is unacceptable in my book)

Xe: That doesn't surprise me at all.

rwp: yea :/

rwp: we do have plans for some $newer hw, but that's only gonna get us so far

the limiter is usually not the hardware, it's the scripting language bugs. was implemented in

Yep. My web server that being brought to it's knees was pretty beefy. Those $things are relentless. Anubis literally saved that web server.

thought about making a UI and API compatible version of bugzilla in Go/Rust with giga caching as a thing for exiting projects to migrate to, but i don't have enough time in the day :(

The free software conundrum!

if my husband was employed i could risk taking a chance on techaro

Dang. I had a question for you, Xe, and now I can't remember what it was. Typical.

That would be cool.

i've been working on ideas for the techaro seed round arc, but i may end up not going down that road

Xe: Not going down the techaro road at all or just not the arc road?

i'm the only income earner for this household, nothing techaro does has the word "agents" in it, and i really don't want to job hunt in this market

i'm just gonna go for moonlight bootstrapping i guess? idk

That's fair. And job hunting right now is definitely no picnic. The market is absolute junk (at least here in the USofA.)

It's worse in Canada lol

it's bad worldwide

I am running FreeBSD 15.0-CURRENT on my desktop, can you guys recommend anything better ?

bsdrobert: I would think so based on the reasoning.

mzar: 15.1-RELEASE?

what about upgrade to 16.0-CURRENT ?

sure, why not

15 was branched quite a while ago, so you're very out of date either way

Nothing wrong with that either as long as you don't encounter any issues. But, be prepared for the possibility of breakage. -CURRENT is not a stable release, but the latest. And code changes A LOT.

TBH I am running 16.0-CURRENT, but I am getting dyslectic with age and misstyped it

Ah. Gotcha'. If you're not having any problems, just keep running with that.

thanks ek !

And, obviously, if you DO have any problems, please report them. :)

sure, I will

Any ideas how to keep several bootable kernels (and their modules) on same machine/rootfs ? I came to this simple but bogus solution: I create /boot-14.4 and /boot-15.1, I put corresponding kernel and modules there, than I symlink /boot to one of these before reboot. Is there any better solution ? Also can I change where loader finds kernel and modules during boot time ?

checkpoint: Using root on ZFS?

If so, use the Boot Environment Controller (bectl)

That works with UFS as well doesn't it?

Or at least, _someone_ got it to work.

boru: I'm not sure. Obviously, snapshotting the BE won't be an option on UFS. But, maybe it uses something else if it detects UFS?

I haven't used UFS in years.

Been a few years for me, as well.

Ah, here we go: vermaden.wordpress.com/2021/04/02/ufs-boot-environments

From 2021, though

Not nearly as convenient as zfs, naturally.

Definitely not.

UFS on Solaris

Certainly not surprising that it was Vermaden, though. Haha

ek: bectl is for zfs only

checkpoint: See boru's link above. It works with UFS as well (albeit, differently)

ek: I'm on UFS and prefer to leave it that way on laptops

Yeah, but in that page, I recommend reading the last part first.

all this reminds me that I need to get porting bectl to linux

I'm not sure if it will suffice for your needs on UFS.

Yeah, I won't vouch for it, because I haven't tried it.

LXGHTNXNG: That would definitely be nice!

checkpoint: er, loader searches all of the directories in /boot for kernels

checkpoint: the normal convention is to just install them into /boot/kernel.foo

kevenas: yes, but I would like to make it search some other directory, like /boot-15.1 in my case. Is that possible ?

checkpoint: why, exactly? I'm not sure why you wouldn't just install a 15.1 kernel into /boot/kernel.15 or some such

it wouldn't be hard to fix this, but i'm curious of the use case

kevans: because besides kernel there are modules and tons of other kernel related files, all of them a spread under single /boot/

checkpoint: most things are relatively self-contained, presumably you're mostly concerned about installing kmods from ports?

kevans: it would be great to tell loader and kernel where to search. Say, if I want to boot 15.1-RELEASe I would setenv boot_dir=/boot.15 in boot prompts. As simple as that.

kevans: not only kmods, there tons of firmware files which depend on kernel (wonder why?).

as I said I can switch now between kernels with something like "rm /boot && ln -s /boot.15 /boot && reboot", but I would like to be able to to that during boot time, in boot prompt or even in Boot Menu. :)

yeah, firmware and untied modules make it a little more complicated

hmm

from reading boru's link: "The idea behind UFS Boot Environments lays in several additional root (/) partitions that will be used as alternate boot environments." -- kind of same Idea, but uses mount(8) instead of "ln -s"

I mean, you if you have /boot/bananas and /boot/badgers, you can `set kernel=badgers`

boru: right, but firmware and untied modules live in generic paths that are baked into module_path

Firmware should be mostly kernel agnostic, no? KOs on the other hand, yeah, depends where they are, I guess.

new-style firmware is, old-style firmware wasn't

Could always just make multiple /boot partitions and then efibootmgr it or something. Lots of ways to skin this particular cat, imho

old-style we wrapped the firmware into a .ko and it was ugly

boru: ok, if you go `set kernel=badgers`, where kernel finds its modules and firmware ?

See above, kevans is probably right.

boru: firmware should NOT be kernel agnostic, firmware depends only on hardware. That's how it works in Linux, btw.

Do you know what agnostic means?

boru: please explain ?

If you get a dictionary, go to the A section, find "agnostic" and read the definition of what the word means.

boru: thank you, bro. ;)

You're welcome.

anyways, the idea of having multiple /boot partitions seems ok, but it's hard to implement it on already deployed system.

i'm still munching on some notion of 'kernel profiles' or something to swap out the bits you need

kevans: I think something similar can be achieved by manipulating kern.module_path sysctl and/or module_path kenv during boot

checkpoint: yes, this is what it would do

the boot menu we have (1. Normal boot, etc), how is it made ? in lua ?

yes, pua

lua

you can add a local.lua for personalization likw this

happy to advise if you go that route

Haha. "pua" is never going to leave my mind now.

kevans: did you write that bootloader lua stuff ?

checkpoint: yes, quite a bit of it

kevens: Cool. Thank you very much for doing that!

kevans: If you find time to implement "Kernel Profiles" feature that would be just great, it would help people to test/debug differnels kernels on real hardware without much effort. :)

amusing

checkpoint: yeah, unfortunately it might go on the ol' backlog for a while. need to remember if there are any other useful things besides per-profile module_path that should be included

maybe per-profile module sets

foo.iwx_load=YES -> foo profile loads iwx

iwx_load=YES -> all profiles load iwx

but why

because it actually is useful functionality

particularly for their case where the default values for some things aren't really globally applicable

(it dawned on me after the iwx_load messages that it probably just makes sense to infer the variable sets from the kernel path; /boot/kernel.foo -> foo.module_path, /boot/foo -> foo.module_path

A little more complicated if you try to name a kernel like `kernel.15`, but maybe let's just not do that