Content-addressed email breaks mailing lists, as those need to be able to add headers for subscribe/unsubscribe/list id, etc. There is a reason DKIM allows you to pick which headers to sign.
And i am wondering what do people even fill their storage with, and why do they need so much. In my case it is ~200-300 out of 1TB on 2 laptops, 37 out of 128gb on phone. And i don't even actively manage it.
I have one single video game I play that takes up around 650GB, so I have a dedicated drive for it. And between 1 and 2 TB of movies, TV, and photos. Everything else is ephemeral/scratch space for whatever I'm working on.
I used to be into amateur movie making and editing, and back then I needed many TB of space for the stuff I pulled off my cameras before it got edited down.
I don't know what it is for GP, but in my case it's Flight Simulator 2020 with over 700 GB. Not the standard installation though: it's community mods, mostly photogrammetric data for additional realism. There's a whole ecosystem around the base game that could easily fill several TB if you go all in.
I have 2TB filled and I need more. I make music so I need a lot of storage for my instruments and samples. This is measured in tens and often hundreds of gigabytes. I also play games. Games' sizes range wildly from 10 to 200 GBs. I also do gamedev. The textures get big and get duplicated between projects. Programming (npm modules for example), add to this personal data, media archives and 2TB is not enough
Late intel macs are in fact crimes against thermal design, but this is no longer a problem on most M-based ones (except the 14-inch M4 max, that one does throttle.). The keyboard is also no longer e-waste tier. The rest is true, but you may wish to update your talking points.
The Macs all throttle with heavy workload that raises the temps no matter what you do. The efficiency (and battery life) comes from the hardware being configured to do certain things very efficiently, like video decoding.
Compute is compute, Apple didn't circumvent physics. It just managed to take chunks of that compute that represents the most average use case, and make it more efficient, in the same way that ASIC mine bitcoins more efficiently than GPUS
As for keyboard, it still sucks. Impossible to clean without taking the thing apart, so if you get any dirt under the keys, its gonna be there for quite some time.
> but this is no longer a problem on most M-based ones
It definitely is. Apple's mistake with the Intel Macs was refusing to throttle the chips before they hit their T junction temp (~95c). This is why a lot of Wintel machines will max out around 70-80c in sustained load while Macs will fly past those temps.
The same behavior is present in both Intel Macs and Apple Silicon chips - you can very nearly boil water on your Macbook if you push the GPU with sustained load like LLM prefill.
Apple's PSCI interface is not a mystery, and there is perfect knowledge on how it is implemented. It isn't. Which is the actual problem, Linux wants PSCI, Apple platforms do not have it.
The segment model seems clever if you assume that you never have an object that is larger than 64kb. And once you have that you need to care about segment overflow, pointer comparisons no longer work, everything now has to carry around segment+offset instead of just offset, and so on. And if you want an example of a >=64kb object - the html alone for that page is one.
A lot of that is just bloat that you wouldn't have had back then. But it could still be handled by an 8086, not by storing the raw HTML in memory at all, but parsing it as it loads. Each DOM node would be its own object with child pointers, with attributes and names all converted into binary numbers of (at most) 32 bits each.
64K of actual text content in a single node could be reached in some documents, but it's not that small, more than a chapter of a typical book.
What was always a problem for segmented memory was graphics, at least if you wanted higher resolution than 320x200 at 256 colors. But you could have a segment pointer to each row of pixels instead of an entire image, as long as it would still fit within 1 MB (16 MB in the 286 protected mode).
True, graphics is a better example of a period-correct >=64k work, but the point is that there are multiple things where you don't expect the data to be that big until it suddenly is.
Just curious, why is there a login gate before seeing the list of projects that participate in the platform? Usually similar donation(?) websites list those publicly for better visibility and less friction.
Probably an oversight on my part. I was thinking that backers would find out about CleverCrow through the project maintainers so the public pages are repo specific.
As an aside, when you do login, CleverCrow shows projects that you've starred on GitHub to help find things you might want to support.
Full details on the permissions we request from GitHub are present here: https://app.clevercrow.io/github-access. Regarding bank access, all financial transactions are handled by Stripe in an incredibly conventional manner. Additional details on that in the privacy doc: https://app.clevercrow.io/privacy
I wonder why were relays mentioned only mentioned in passing and there was no elaboration on how they interact with the rest of the network. Maybe because doing that would show that there are in fact "instances" in atproto, but who knows?
I mostly skipped over it because a Relay is an optimization and not essential to the shape of the network. It's not a fundamental element in the same way that PDS (hosting) and AppViews (app servers) are. It's more like a "next reasonable thing" an engineer would bolt on to make it easy to create apps.
A Relay is not an "instance" in any meaningful sense because it is a dumb retransmitter. It is cheap to run one, and it is easy to pool them between multiple apps. (Fun fact for nerds: the Relay's API for subscriptions is literally the same as a single server's. So a Relay is kind of a facade for "a bunch of servers" that lets you listen to their events combined.)
Early on (more than a year ago), running a Relay used to be more expensive because any Relay was expected to store the entire network archive. This is no longer a part of the contract, but a lot of discussions still reference or assume that. The current cost of running your own Relay (if you don't want to pool with anyone) is about $30/month. There are community-run Relays like https://firehose.network/ that you can use too.
Not really, considering there aren't that many app servers. Each PDS sends out its events, those events are picked up by whoever wants them, mostly relays but some apps might directly subscribe. The more apps in play, the more connections, but it is not the case that for every new PDS, every other PDS now has to open an additional connection. It scales with the amounts of apps, not PDSs.
It's not centralized in any way that matters. The Relay Bluesky uses is open source, you can run your own for $30/month if you really insist on doing that, it's trivial to pool between multiple apps if you want to lower costs, and there are already a few independent ones you can just use directly now, for example:
You should read the report, it basically repeats what I just said:
> The power management architecture on this platform is incredibly complex, and there are a lot of moving parts involved in making it all work. There is Power Manager (PMGR), which is responsible for the SoC’s power domains, but there is also the Power Management Processor (PMP), which does… stuff?
> The actual low-level details of how power is managed across the SoC are quite opaque. [...] PMP will not read these reports if it is not booted, and certain power management functionality will not work. We are not sure exactly what it does with this information, but it likely involves controlling Apple Fabric power and clocking, among other things.
> There is obviously still work to be done to reach macOS levels of idle and suspend time
I still do not think that we will get advanced power management equivalent to ACPI within this decade, unless Apple starts documenting stuff. It took Asahi six years to replace cpuidle on M1, we're going to be here for a while.
They don't. ME and PSP are separate cores with full memory and configuration bus access. TrustZone is nothing like this, it is a higher privilege level on the main cpu cores, more similar to SMM and used for pretty much the same purposes. Secure enclave is yet again nothing like any of the former and is similar to a TPM.
Works here, here's the text for anyone who can't access it:
> Turns out APFS has an undocumented "VolBootable" flag that we were never setting since, well, it is undocumented, and the boot picker never cared about it (it read it and printed it's state to system log, just did not take any action). Anyway, fix PR-ed to asahi-installer, old installs will have an installer option to set the flag. But still, probably hold off on installing macos betas :P.