Notices by Adrian Chadd <verified.png> (erikarn@mstdn.social)

@dalias @navi @jschauma @gantua @mirabilos @lispi314 oh I'm thinking about POSIX AIO on everything that isn't linux.

They are zero copy - once you call aio_read / aio_write, you're not allowed to touch the payload buffers. Thus the OS is free to wire them down and use them as payloads to NICs and filesystem/disk buffers.

Source: I did this for a long, long time in FreeBSD and Solaris to get much higher raw disk / O_DIRECT filesystem throughput back when we had proxy caches on spinning rust ;-)

@dalias @navi @jschauma @gantua @mirabilos @lispi314 it's also zero-copy! don't forget that. it can be a huge performance boost compared to read/write syscalls w/ memcpys.

And "your active developers retire or die out" is not a new problem.

It's a general project health/sustaining problem to solve.

You can't solve this with only users who don't donate code or money.

So to finish - if you're trying to use open source and it's not a well funded project. Donate. Like, right now. Shit's not getting cheaper any time soon.

If it's a no-LLM project then they triply need your help now. Code or money. Your choice. Using it isn't enough.

Code or money.

I just want to be a bit .. annoying about LLM or anti LLM stuff in the real world.

If you want to see your favourite no-AI/LLM project survive, it needs:

* developers, who are -
* writing code, which typically needs -
* money

It's not enough just being a user. There's plenty of users and potential users out there.

So if you REALLY want to see the no-AI projects be sustainable, you either need to contribute work to them or money. A lot of money.

You can't expect them to survive otherwise.

Note this isn't because the "projects embracing AI are getting AI money." Only a small amount of them are.

This is just me reiterating that software doesn't evolve with only users. Someone has to improve it, fix bugs, contribute new features.

The internet is full of open source projects dying a slow death because people keep using them and they keep ticking along, and it's nice to see new users come on board. But if your developer base is aging out .. you're eventually going to see them die.

RE: https://mastodon.social/@Corax42/117207570116265813

The under-rated part of all of this is that .. they all likely know or know of each other. They likely travel in the same groups, chat in the same signal/telegraph/whatsapp threads, go to the same parties, etc.

A lot of people in that donation / sponsorship list are long term technology / startup folks. They cross breed their beliefs and their money frequently.

(which is why it's hard for OTHER OSS projects to get similar notice - we don't travel in those groups.)

@raster @grahamperrin @lykso @lianna Our job as freebsd maintainers is to hold a way way higher bar regardless of source.

@cwebber @erincandescent right, now it's time to focus on avoiding people poisoning training data and prompting.

I'm much more worried about code being merged that introduces subtle back doors that the LLM judges as "safe".

(And I'm not talking about it without seeing it actively being used like this right now, fwiw.)

@skinnylatte ah dang, i like their salad (from the alameda restaurant)

@whitequark @hailey oh yeah i forgot to mention how utterly bonkers the timing can be.

It's not always the controller either. Like, you can submit a buffer for completion to the controller and context switch / copy it - this is what userland libusb + ugen devices do! - if you can do it to a process then you can do it to a VM! - but the devices themselves are also very latency sensitive and in a lot of cases shit the bed if your transfers aren't setup fast enough!

@whitequark @hailey also holy crap usb-over-ip in linux isn't virtualising the endpoints, but is .. exposing hardware? oh holy crap

@whitequark @hailey oh /lord/ ew ;p

@whitequark @hailey I'll have to go dig to see if I misquoted and the USB-3 things are doing to 3 to 3 only and what they do when you plug a usb-3 hub into a usb-2 port.

There /are/ weird shenanigans though!

@hailey i kinda know? do you REALLY want to know? like really really REALLY really? :P

@hailey ok so

at the top level, before usb-c, it's mostly easy to move the whole controller into the VM. That's a mostly self contained thing. It's doubly easy if it's behind an IO-MMU which virtualises all the DMA addressing.

however, moving a USB device is problematic. All the hub and port control would be done by your host OS. You'd have to tell the host OS to pass something in by rule, eg "hey any mass storage device on this physical controller? please map to the VM."

@hailey Now, that means all the hub/port control between that controller and your device needs to be done by the host, then you need to basically proxy all of the USB transfers from the host to the guest.

But there's no standardised "paravirtualised USB" stuff. So the VM has to basically take your device, "fake" a USB controller and port, and then have those USB transfers to/from that particular device into the VM via this fake USB controller.

@hailey Now all the devices on a given controller kind of look like a LAN with automatically enumerated endpoint and device IDs. The USB controller doesn't REALLY care about all the devices its speaking to, it's just given a set of transfers to do to endpoints and when it issues the transfers it hopes to heck they're there.

But like, when you plug in hubs, those are store and forward things. And these days doing USB2 or USB1 on a USB-3 port can actually end up with a "hub" doing translation!

@hailey ie, depending upon if you plug in a USB-3, USB-2, or USB-1 device, your XHCI USB-3 controller may actually be speaking that itself, or it may be speaking USB-3 only and USB-2 / USB-1 via a translation hub that will handle translating USB-2/USB-1 to USB-3. (or USB-1 to USB-2 for EHCI.)

So suddenly your device ID and topology can change based on the /type of device you plugged in/!

@dalias A quck bit of googling shows the 'eject' command has some button control

https://www.man7.org/linux/man-pages/man1/eject.1.html

maybe see if that does lock the drive against button press -> eject? And at least then we know all the software bits are there?

@dalias it was still in early 00s in freebsd, they did mostly fix it in linux by then!

i remember when the UX changed to match what windows did and I also disliked it then, heh.