will noone claim the Rick and Morty reference? I've seen that show like, once and somehow I know this?
the paper already says "Butter-Bench evaluates a model's ability to 'pass the butter' (Adult Swim, 2014)" so
Readit Newshalf-kh-hacker commented on Our LLM-controlled office robot can't pass butter andonlabs.com/evals/butte... · Posted by u/lukaspetersson
> prohibitively expensive
fact checking
Apple Tier 1 mandatory store services:
0.5€ Core Technology fee per install
2% Initial acquisition fee
5% Store service fee
Compare that to 20-30% that Apple's own AppStore take and its a bargain.
Even with Tier 2 with marketing tools, automatic updates, app recommendations, analytics dashboards, and promotional features the cost is only 10% for small business program members, 15% for others.
50c per install (of which there are hundreds of thousands) to a party who should be uninvolved is not reasonable
> /dev/shm is typically world-writable by default:
You are relying on random implementation details instead of universal APIs that work across OSes and environments. Please stop.
So help me God, if I make a Linux system, I will make it _not_ have a /dev/shm just to avoid people relying on non-standard stuff for no good reason. Honestly, it's because of stuff like this that we need Docker.
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
What allocator does Apple use?
you probably want to look at their 'libmalloc'
Most climate change advocates naively believe that because an energy resource in renewable it must be infinite too. Simple energy balance over a given area will show how much extraction of wind energy will reduce available energy downstream.
Moreover, the economics of offshore wind farms is often commingled with state enterprises and various subsidy schemes, which makes them uneconomical even in the best of times, so a 2% capacity reduction coupled with inevitable maintenance and repair costs escalations might make many wind farms uneconomical.
Onshore wind farms are much more economical but the best locations such as Texas, Oklahoma and New Mexico already have been developed.
"climate change advocate", in contrast to some "climate change opponent"?
half-kh-hacker commented on Apparently Bluesky has one centralized service, the "relay" mastodon.online/@mastodon... · Posted by u/doener
> the relay storage volume scales only with the backfill window for consumers that drop briefly […] bluesky's feed gen post-dropping is about internal operation of their appview and not anything to do with network sync semantics
Gotcha; thanks for the clarifications/corrections. Good to know that the firehose bandwidth is a lot less than I thought (though 20Mbps can certainly add up to some hefty pricetags depending on how you're billed for traffic).
> 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.
Right, but how much of that actually needs to hit the disk? I'd imagine most appviews can readily get away with just keeping posts in RAM, and even if disk storage is desired (e.g. to avoid needing to pull everything from the PDSes if an appview server reboots), it ain't like the writes need to be synchronous or low-latency. A full-blown ACID-compliant DBMS is probably overkill.
It'd also be overkill to cache all posts, rather than subsets (e.g. each users' "Discover" and "Following" feeds), so I reckon that'd also reduce the in-appview caching needs further.
the reference bluesky backend does just keep everything around but this idea has merit!! you're actually reinventing something like AppViewLite right now, which does throw away old data: https://github.com/alnkesq/AppViewLite
bluesky chooses to not refetch data from PDSes all the time so that the load for a PDS stays low (they like it to be possible to run on a home connection)
half-kh-hacker commented on Apparently Bluesky has one centralized service, the "relay" mastodon.online/@mastodon... · Posted by u/doener
Re: the relay, that depends on your needs. My impression from these sorts of "run a relay on an RPi" projects is that they're only dealing with a subset of the full firehose Bluesky's relay has to deal with - be it a shorter timeline (as you mention) or only concerning themselves with specific accounts (like the relay operator's own "following" feed, in the case of someone running a personal relay) or what have you. Pretty sure even Bluesky's relay doesn't try to drink from the whole firehose (or if it does, it's tolerant of "dribbling" so to speak; I recall a Bluesky dev blog post about how temporarily dropping posts from users' feeds is acceptable if the relay can't keep up).
Re: write traffic, my understanding is that the appviews shift most (if not all) of that burden to the PDSes, no?
- 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.
half-kh-hacker commented on Apparently Bluesky has one centralized service, the "relay" mastodon.online/@mastodon... · Posted by u/doener
Genuine question: if it's so easy and cheap to host a relay, why then "Free Our Feeds" initiative [0] looking to raise $4,000,000 [1] to establish a second relay [2]? Most of that money must be earmarked for administrative and human expenses then, right?
[1] https://www.gofundme.com/f/help-us-free-social-media-from-bi...
[2] https://freeourfeeds.com/ § FAQ § What will the money be used for?
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
half-kh-hacker commented on When imperfect systems are good: Bluesky's lossy timelines jazco.dev/2025/02/19/impe... · Posted by u/cyndunlop
A frontend is (can be) part of an App View. It is quite literally the app you view the network through. There can also be headless app views and app views which have no backend
this is not correct
half-kh-hacker commented on When imperfect systems are good: Bluesky's lossy timelines jazco.dev/2025/02/19/impe... · Posted by u/cyndunlop
The App View frontend is open source: https://github.com/bluesky-social/social-app
Much of the backend is open source as well: https://github.com/bluesky-social/atproto/tree/main/packages
What is not are the extra services they run to provide a better and faster UX. Even if it was open source, it likely costs 10s of thousands to run per month (they have moved largely to "onprem" hardware instead of the cloud aiui)
that's not the appview, that's the client