It’s very much an embodiment of the law that says to monitor a system is to interfere with it; it would be very hard to say they “predicted” general suicide attempts vs they set up a scenario that allowed them to nudge people into such actions given everything.
And that idiot, Zuck, thought he was getting a good deal when he poached former head of design, Alan Dye, from Apple. We were relieved to see him go. Our desktop OS is already making small improvements now that he's gone.
Context: the guy doesn't understand fundamentals of UX and has made MacOS worse for years.
Good UI makes it easier to be selective. social media owners dont want you to be selective, they are selling you to advertisers and influencers after all.
Zuckerberg and his minions have changes html and obfuscate it so much, it is impossible to block ads these days. They are worst than google. Imagine google decided every video will require widevine & there is no way to block ads just like twitch.
Last I was on the platform, they eventually added a tab for only chronological posts on the timeline a-la how IG used to work. But they gave no exposure to it, _and_ it completely hid the IG stories of your friends so nobody would want to use it in the first place.
Interesting article but it gave me a bit of a panic attack. Benchmarking (with TPC or otherwise) is NOT the way to determine the correct approach here; that is strictly only to be used for databases (typically RDBMS) effectively “owning” the complete hardware they are running on. An embedded database might be used in that manner if it’s operating as the backend for a pure crud application that performs ~zero server side rendering, parsing, validation, etc and is essentially just an async http-to-SQLite interface. But more likely than not, an embedded db will be used and deployed on machines (not necessarily even servers) serving many a purpose, and need to perform best both within the confines of the resources available to the machine and in relative terms, necessarily making tradeoffs that might sacrifice performance for “value” in terms of CPU or memory usage.
This isn’t just with regards to benchmarking, it’s an essential consideration *any* time you are taking ownership of the cache away from the kernel, which is the only piece in the stack that has viability into the global state and can be trusted to give back memory under pressure to ensure everything plays nice together. It’s not limited to just databases or even just memory, for example FreeBSD has had greater than its fair share of issues that trace back to the ZFS having a separate cache from the kernel (despite the much tighter integration between the two and presence of various mechanisms to address pathological cases). You can also refer to any comparison or benchmark between the use of spinlocks vs mutexes: spin locks consistently perform better in/on (micro)benchmarks but are almost always actually the worse choice in the grand scheme of things because the benchmarks falsely assume complete and uncontended ownership over system resources.
This isn’t even io_uring specific and I’m hardly the first to bring this up in the context of O_DIRECT.
You’ve misunderstood what they’re saying. Not that the benchmark is invalid, but that it’s an incomplete picture if your use case is a mixed set of applications where DB performance is not the only important thing. Hence the comment about memory - O_DIRECT is optimal in terms of DB performance but then the caches are owned by the application and the kernel isn’t free to discard those caches whenever it wants like it can with the page cache. I’m not actually sold on this argument though - I have an embedded DB that with a very tiny block cache goes very very fast, and uses far less RAM than using the page cache because it knows when read ahead is called for vs when it’s not
What would be the correct way to do benchmarking/profiling here? I ask as I've started to run some for Vinyl cache to see what performance issues I can find, and I've quickly learned just how hard it is to get good, repeatable benchmarks that isolate the right thing.
No easy answer! You’d have to have a myriad of different test suites that as closely resemble your real world usage as possible. Or ship it behind a gate and let your users give you real world feedback if you’re at SQLite (not turso) scale - they’ve done that with a lot of ambiguous optimizations.
I think that’s only true on paper; in practice it’ll be true only when you have competing reads (at a thousand-foot view) and it might be possible to algorithmically bundle a portion thereof. It originally let SCSI controllers attached to spinning rust HDDs optimize physical manipulation of the disk heads to optimized queued reads of data in a “traveling salesman” sort of way, but modern nand flash can only internally read a full page at a time (which may be much greater than even the apparent physical sector size) anyway and with a strictly constant cost regardless of the “physical location” of the data on the non-existent platter. Old drives had optimization constraints like higher sequential read speeds at the outside of the platter (more bytes per physical rotation) and extremely pathological cases for data written to the innermost tracks of the platter. Individual requests were much finer-grained and the latency was much more varied, so a request from app/thread X for as little as 512 bytes from one location could be cheaply piggy-backed on an existing request from app/thread Y to read multiple megabytes from a physically proximate source that would otherwise have seriously delayed or starved the queued waiting read while the outstanding request was serviced.
In fact, one consistently sees higher bulk IO numbers when using physical media that has been formatted with a large sector size compared to the old 512 byte fixed emulated size. You’d routinely see lower latency and higher IOPs with 4kn (HDDs or SSDs) than you would with 512e disks, even with SCSI or AHCI controllers that featured similar pipelining support to today’s NVME controllers (or even if you place a spinning rust HDD behind NVMe today!).
Mostly true but as someone else pointed out it’s still better to issue a single large multi-page contiguous read than the same read broken down into separate requests because the I/O queue isn’t infinite. So both the Linux kernel and the SSD microcontroller still benefit from merging contiguous requests on their end. However, if you issue it correctly at the application level that’s still going to be better in that you’re never going to encounter a situation where you accidentally don’t get the desired coalescing.
> Mostly true but as someone else pointed out it’s still better to issue a single large multi-page contiguous read than the same read broken down into separate requests
FYI/fwiw Fish shell autocompletes branches sorted by last commit date when writing out git commands. It also provides completions for commitish objects grouped by class, giving precedence to the usual targets first, with each group sorted by its own sort key. Handy!
Not to knock on RISC-V, which I’ve been following from the embedded side of things for many years now, but I feel I must question the value of a license-free ISA in this specific market segment at this time.
Surely between the squeeze on RAM and storage pricing and the exorbitant costs of training or mass-inference scale GPUs (if you’re going into AI), the nominal cost of the CPU licensing is really not going to make or brake anything or unlock some new business viability?
Even RISC-V aside, we are essentially in a position that would have been impossible to even dream of ten or twenty years ago when Intel was the only player in the game.
Wouldn’t buying off-lease hardware (not even in bulk) give you better performance per dollar, better compatibility, and more options?
Not to say any of this will always be the case; even if RAM pricing doesn’t come down, storage will, and RISC-V processors will (maybe) eventually actually be competitive when it comes to SOTA performance, but today in 2026?
The promise of RISC-V is probably not that it cuts pennies of a $1 embedded ARM core (or dollars off a $100 core).
Instead, it’s that Moore’s law keeps on trucking along, so now we have lots of dark silicon (you cannot turn the whole core on at once, or it will turn into a puddle of glass) and specialized silicon.
RISC-V removes all the gatekeepers (except TSMC and the other fabs) that historically blocked new specialized silicon.
I could get an ARM license, but suspect that, at best, that means dealing with sales folks and also building out a legal division just to manage the license.
I could be wrong, but it’s easier to go with the open core, in the same way that I suspect I cannot afford to figure out how much I would have to pay in order to license windows for my servers.
The point with RISC-V is that you can first pick the architecture and then have many potential providers and you are sure to never be stuck with one provider.
Its not the cost that is the major change, its the business model.
Granted ARM potentially gives you part of that, but its still tricky.
And of course this theory only works out if you have enough competitive providers. But that's always questionable.
I think in the server space the story is more about Chinese autonomy from US regulation/control. As long as they're dependent on closed western IP there is risk of being rug pulled, that having their own RISC-V IP eliminates.
In the embedded / microcontroller space it's a different story. License cost there must be absolutely key, and I think less vulnerable on a per unit basis to the RAM etc storage factors you mention. I don't actually know the numbers but I'd expect that as a percent of total BoM cost the ARM license must be higher for microcontrollers than bigger machines? Maybe someone more qualified knows the answer to this.
The article doesn't put much emphasis on it, but like it says this is still a development system. It's not intending itself to be competitive with ARM and x86 servers for the typical server buyer in 2026.
Yeah it seems to be aimed at people wanting to do Risc-V CI for future stuff, not as a "Real" product thats competitive. They need software to work on Risc-V to sell stuff in future.
0% APR for 12 months (24 for iPhones only?) from Apple Financial Services for a device that can approach or even exceed what we were paying for new cars just a few years ago. Apple is definitely making bank off these financing offers, and with very little risk as unlike a car these Mac Studios don’t lose 20% of their value when you drive them off the lot.
Are you sayin 0% is bad? What is better then? If you have the means, pay outright, no? It used to be a lot worse, paying $16K+ for a 128MB Quadra something based RIP in mid nineties . Do you mean that these things are overpriced from the get go?
I am merely pointing out additional revenue streams for Apple here. They make money off the hardware and again off the financing. Car manufacturers and have much lower margins and finance via their financial arms with much less predatory terms than your average credit card. The zero percent APR is very attractive, and easy to convince yourself to go with something above what you can afford. Times are good for Apple.
Good for them. Things cost what they do. I hear you that one can fall into the 0% interest trap, but that’s on us.
Not that I want it to happen, but I wouldn’t be surprised if Apple could get away with even higher prices today. Like 50% more retail on everything. They are holding the line, but I wonder for how long and why. They can pretty much charge what they want.
My friend, the same way everyone else does. It goes from 0% to 28% interest when you miss a payment. Those are rates normal lenders fall asleep dreaming of.
reply