People who routinely take photos in social situations. Camera phones don't have features that appeal to professionals, they do things that appeal to casual photographers.
Pro photographers aren't professionals because they have expensive cameras, it's because they get paid to deliver professional results. A phone camera can be the most usable camera for a result because it's smaller and fits in more places.
Though the camera isn't even the most important equipment, that's lenses/lighting (plus stabilizers, studio backdrops, etc.)
They say the best camera is the one you have with you, and your phone is usually with you. In any case, some professional photographers actually prefer shooting on their phone even for planned, high-profile shoots—perhaps they like its convenience, or that its unassuming nature puts subjects at ease. Or perhaps they find it creatively freeing to be burdened down by only minimal gear.
Yeah, idk. That seems like an awful idea to me. I’m not sure why she would shoot with an iPhone for such a job unless she got paid by Apple. Some practical reasons:
- Such an important moment is something you often wanna blow up in a large/hi-res print.
- An ultrawide lens is suboptimal for portraits and usually makes the face look puffy from the perspective.
- Unless you know the exact color & aesthetic for the cover you want to preserve the raw capture for changes in post to match the vibe.
While I can certainly appreciate the casual and intimate vibe she’s going for, as a pro she could have brought any decent camera with a portrait lens and keeping the shoots equally short without compromising quality and adding risk for the poor layout person who has to work with it later.
I consider myself a hobby photographer, and I love having a phone camera. I can then have the tele glass on for entire hike/session, and do landscapes on the phone. Currently, 2 weeks in, I didn't even touch the landscape glass in it's case.
In any event, that makes no sense. Pretend for a moment that glibc has working DNS and musl doesn't have working DNS (not true, but let's pretend). You don't build your compiler chain with working DNS support and then use it to build programs without working DNS.
Take a look at the official “basic scaling” guide especially the metric about state transitions / second.
To get an idea of what you’ll need that metric to be try running 1/10th of your workload as a benchmark against it.
In order for our particular setup to handle barely 5000 of these we have almost 100cpus just for cassandra. To double this, it’s 200 cpus just for database.
Oh and make sure you get your history shard count right as you can’t change it without rebuilding it.
Maybe it makes sense for low volume high value jobs e.g uber trips, for high volume low value this doesn’t work economically.
I would love it if Apple just fully embraced Asahi, dedicated resources to it. Imagine 'you can now run either macOS or Linux on your Mac, or both, your choice' - not an an Apple subsystem for Linux, actual Linux, and all peripherals working right across the line.
Seems like as impressive as the work & project is, it's always going to be struggling to play catch-up: you're not happy with the extent of M1 implementation, my understanding is M3/M4 just barely work headlessly.
Yeah I've been using Claude to review a bunch of m68k asm that I've been working on and it's been helpful at catching silly mistakes like using a direct address instead of an immediate value, clobbering registers, incorrect branches etc.
Of course if you just blindly ask it to write asm it will occasionally invent new instructions or address modes but it's very good at reviewing and making adjustments
> Turns out the competition had done the most stupid thing and built a read buffer
This isn't really stupid though as explained in the pdf
> Paradise had stuck a read FIFO
between display memory and the video output stage of the VGA, allowing the video output to
read ahead, so that when the CPU wanted to access display memory, pixels could come from
the FIFO while the CPU was serviced immediately. That did indeed help performance--but not
as much as Tom’s write FIFO.
VRAM accesses are contended, so during the visual display period the VGA circuitry has priority.
CPU accesses result in wait states - a FIFO between the VRAM and the VGA means less contention and more cycles for CPU accesses
Why improve read performance though? Games accessing VRAM I presume would be 99% write.
Perhaps it was to improve performance in GUIs like Windows?
The first thing to understand at an even higher level about payment cards is that they have always had two separate and barely related components, Authorisation and Settlement.
Authorisation is concerned with whether this specific transaction has been approved in some sense by a card issuer. Authorization today is relatively high tech, there's somewhat decent cryptography, tamper resistance, uniqueness = they really care - and that's because when Authorization problems occur the banks might lose money, which they hate.
Settlement is "just" moving the money from one customer to another. $123.45 from Jim Smith to Terrible Goose Inc, done. This is very mid-late-20th century technology, we're not talking pieces of paper and scribbly hand writing, but fixed width ASCII fields on magnetic tape is fine - it's the customer's money so the banks don't care more than legally required.
Settlement replays are how you get "accidents" where a big store's customers all get charged twice for a whole day - the associated Authorizations can't be replayed, that's the banks money at risk - but the settlements aren't protected.
Merchants can, and some do, choose not to care about Authorization. In a huge business it could make sense to eat say 2% of sales as undetected fraud (ie you never receive payment) rather than have any transactions fail. If you operate a food truck using a terminal to take $1000 per day on your iPhone the people who supply your terminal may not let you opt out because that's risk they don't want. But if Jeff Bezos or Doug McMillon makes more without Auth he's turning it off.
This terminology is not quite right for the US. I'm assuming you're from elsewhere due to the "s" in authorization. :)
In the US, the two steps for the merchant are Authorize (optional) and Capture. If both steps are performed, it's a dual-message transaction. If you skip Auth, it's a single-message transaction.
Settlement of funds is a multiparty bank-bank-bank operation, in which merchants are not directly involved.
It's over the Internet, because you're not going to run a dedicated fiber to every card reader. But it's not over the unprotected internet; your card reader will establish a VPN connection of sorts, or at least talk via an encrypted channel (think TLS) is you use e.g. a Square terminal.
Not that a random person can hit these endpoints, unauthenticated, and try to run a transaction.
Correct. In point of fact, payment cards/merchant networks are quite literally just that. You get a credential, and that credential can be revoked if you get up to something sufficiently heinous to warrant the ostracizing.
People would be surprised if they really took the time to learn how much of life is just operating on good graces.
I mean, maybe they don't have an open API, but they sure do have an API on the internet. Surely the payment terminals are communicating with the issuing bank in someway, perhaps over an interface of some kind.
I believe what this comment is getting at is that making fake transactions is useless without a connection to a bank that will execute them.
