trying to port a program called continuwuity and I'm having problems related to crates

WARNING: Do not know how to handle git+https://forgejo.ellis.link/continuwuation/core_affinity_rs?rev=9c8e51510c35077df888ee72a36b4b05637147da#9c8e51510c35077df888ee72a36b4b05637147da

WARNING: If it points to a GitLab instance try adding the hostname to gitlab_hosts[] at the top of cargo-crates-git-common.awk

Is there a way to force files from Windows NFSv3 clients to inherit/take on a default permission set? Tried NFSv4 and spent hours in the man pages but from what I gathered, NFSv4 just won't work with Windows??

thermos: Even with Linux to Linux I am using Samba now, and would recommend for performance, stability, and reliability reasons that you do the same. I had 3-5+ second freezes off and on with NFS between my two machines, and had to tinker with it a lot to even get the share going between them after routine reboots

Samba has resolved my prior drive sharing problems and performs much better

Okay, I hear ya. I use Samba at home but thought I heard NFS worked well for Windows (maybe that's the case if running Window's Server?)

Simply opening File Explorer causes the entire workstation to freeze for a solid 5 seconds... it's bad.

Yeah, I wanted to use NFS because it seemed like the right choice between two Linux systems. But Samba has done MUCH better for me between them

It would probably save me the hassle in the long run. If no one had any obvious tips here I was going to start figuring out what I need to do to write some sort of 'callback' for the share - simply to run a 'chmod 666' on new files.

I have a Intel 10G copper NIC with these machined cabled directly to each other. I shouldn't have had issues with anything. But NFS was pretty bad

The only functionality I lost, I didn't actually need anyway. And that was I could install Games on the NFS share with Steam, I can't do that on the Samba mounted share :P

Everything else works a LOT better

Same here, and I was willing to overlook it since the share is used for by a program (not users) but the main problem is that Windows accesses it as an 'Other', so it will save a file as 644 and then can't write to it again until I 'chmod 666' it.

Good point, the share is strictly files, so Samba probably is the best solution here.

my smb.conf is really simple. I can post it to my pastebin if you want to see it

I should be okay, I figured out how to set it up for Mac TimeMachine backups (pita), just need to find out what I'll need for windows. I am curious though how well running games over NFS was for you as I'm running out of storage on my personal PC

this is my first time using quarterly after using main for years, so i wasn't quite sure what to expect, but a surprising number of security updates seem to be missing despite being in main for weeks

That's one reason I don't use quarterly

i resisted it for a long time, but keeping up with constant updates and breakage in main became too much hassle

ivy: you mean main vs quarterly in pkg?

gbon121: yes

so I figured out the bridge weirdness: the bridge will stall out because it's removing incompatible flags when adding an interface that doesn't support them, such as tso and tso6. Could we perhaps log when that happens, so that it's clear from the logs why the physical interface goes down/up in the process?

well, really i'm asking if I can/should file a bug for it

zip: is this the issue you're having? bugs.freebsd.org/bugzilla/show_bug.cgi?id=280074

ivy: I think it might be, it's a bridge with epairs

I'm doing the cool new 15.0 thing of having one bridge and then setting the various ports as having various vlans

there's also this which seems related: bugs.freebsd.org/bugzilla/show_bug.cgi?id=286689

i don't really like the way bridge fiddles with underlying interface flags and i think we should stop doing that and require the user to do it, but it's difficult to change that without breaking existing setups

it's an igc interface, I think it's behaving itself though

and it's possible at least some of these issues might be fixed by reviews.freebsd.org/D54948, which removes the need to disable csum on the interface, but that doesn't help for other flags like tso or mextpg

I do still have the receive checksums on, it seems to hiccup for half a second if I start a VM but turning off the txc option stops it from freezing for three to four seconds

I shall wait patiently then. This isn't a "production" system, it's my tinkering-with-freebsd-and-running-jails-and-vms system

however I'll also add those links to the comments in my `rc.conf` so that I do eventually revisit my configuration

it may be worth logging what bridge is doing here, separately from fixing any underlying issue in the driver...

I'd have certainly figured it out a lot faster than by simply stumbling across the solution while looking up something else

while I'm not exactly a code contributer (yet! damn you, burnout…) maybe it's worth logging that for 16 wtih a deprecation warning and then switching to the behaviour you suggested for 17?

heck even a `lockflags` option on the bridge that one could add in order to get realtime "I won't do that until you set `-txc`" from ifconfig might be handy

zip: i'm not really convinced my suggestion is the right approach, although it may be more technically correct it would probably just annoy users (and also, other bridge implementations don't require this). i'll have a think...

you could post on net@ and see if anyone else has some ideas

"Brazil Law: All OS's Have 13 Days to Add Age Verification"

oh that's fun

lol

These laws are insane.

□ I swear I'm over 18.

printf "echo y | ageverify --min-age 18\n" >> ~.bashrc

mvanbaak: hey there buddy :D

im just checking in on the chatter and I saw your name. im guessing everyones buzzing about the laws right now