half-kh-hacker

How does post-training via reinforcement learning factor in? Does every evaluated judgement count as 'the training data' ?

the paper already says "Butter-Bench evaluates a model's ability to 'pass the butter' (Adult Swim, 2014)" so

50c per install (of which there are hundreds of thousands) to a party who should be uninvolved is not reasonable

file-hierarchy(7) states /dev/shm is tmpfs and that "all users have write access to this directory", so I think you'd have to be making a non-systemd distro

you probably want to look at their 'libmalloc'

"climate change advocate", in contrast to some "climate change opponent"?

- the relay storage volume scales only with the backfill window for consumers that drop briefly - the bluesky pbc operated relays let you reconnect up to 24h later and not miss any events but that requires around 200gb of scratch disk space -- live tailing an rpi relay without dropping a connection can give you events from the full network span (ie the complete set of the firehose) without requiring any backfill window, but it's nice to use a few tens of gigabytes anyway. -- the full firehose is like 20mbps at maximum so it's far from hard to serve a few live consumers

- bluesky's feed gen post-dropping is about internal operation of their appview and not anything to do with network sync semantics

- if you're running an AppView for the bsky data you are likely keeping a copy of all bsky posts in a database, since fetching from PDSes on-the-fly is network intensive over a relatively small pipe, which is what i mean by write volume requirements.

plainly, free our feeds are grifting.

the relay at this point is non-archival and can be spun up trivially. with a small sliding history window for subscriber catchup u can use like 32gb of scratch disk space and keep a few hours, the relay is literally just a subscribeRepos forwarder from PDSes.

the AppView is vastly more expensive to run since you need to handle the write volume of all bsky activity. if you build a non-bsky app on atproto this is a non-issue

the issue here really is that nobody writes about the state of things in long form outside the network so it's not really known how fast things move and change by those not engaged with the platform

this is not correct

that's not the appview, that's the client

you can run a resequencing relay good enough to feed an atproto appview pretty cheaply - it just needs to subscribe to a few thousand websocket endpoints to get a live tail of the whole network (incoming traffic is well under 50Mbps at peak in my experience)

running an archival mirroring relay is storage-intensive (on the order of tens of TB iirc?) but only serves as an optimization (you can backfill full atproto repositories straight from the relay instead of needing to reach out to the relevant data server)

one cool difference between Bluesky and Mastodon (et al) is that server choice on registration is not an immutable permanent decision and you can choose to seamlessly migrate at a later time by updating your DID document

so the slick registration flow nets you less lock-in compared to if e.g. the mainstream Mastodon app were funnelling users onto one megainstance, since you can still get away afterwards without needing people to re-follow you

gay online sociolect