API pricing rates probably. If I take a look at my current usage since it came out, it'd be about $12000 CAD if paid at API rates. Ridiculously easy to rack up absurd bills via the API, and I'm mostly just using it for code review. Someone using it heavily could easily, easily get way over 70k.
Also the statement was "We". It's not a single user's billable usage and we have zero details as to how many people made up "We". So any analysis into the cost or value are meaningless.
"even pulling up a file via search is more accurate in Cursor"
Huh? it takes it sometimes like 40s to find some file with the fuzzy search for me. In that time im going to the terminal running a "find" command with lots of * before I get some result in cursor
> don't cripple your own horizontal scalability by always reaching for local storage (e.g. when S3 might be better suited) or local application memory (e.g. when Redis might be a good idea).
Is reaching for local storage\memory crippling or not?
Whenever there is something that might need to service more than one request, reach for attached external resources. You don't want to store business state (e.g. something like the current status of an auction or its bids) in application memory, unless you're okay with your app being a singleton application: one that can only ever have a single instance running concurrently, with all of the risks that it brings.
Similarly, if your application generates reports, generally it's good to put them somewhere like S3 and perhaps persist the metadata about this, instead of just spewing them in your local file system, because at a certain scale there are issues related to the filesystem approach (e.g. max number of files in a folder, inode limits), though admittedly something like ActiveStorage in Ruby at least makes an honest attempt at solving it for most folks.
They had a choice between slowing the device or providing a substandard user experience when the old battery couldn't keep up and the phone shut down. I think there are plenty of reasons to criticize Apple but I have no idea why people have latched onto this obviously false narrative.
That’s called replacing your battery. All phone batteries degrade and start underperforming over the years. What Apple did only affects those people with years old underperforming batteries.
Batteries begin to degrade the moment you start to use them. All phones do this. Apple does not have some sort of magical technology to stop it from happening. No one does.
I wouldn’t expect a device that’s likely being drained and recharged daily to retain full capacity after two years. To suggest that shows a lack of understanding in the basic physics of a battery.
No company, Samsung, Google, etc. will “recall” your phone for normal wear and tear items like a battery. If that’s what you’re expecting, you’re going to be very disappointed.
I never claimed anything like. You demonstrate dirty sophistry there.
The issue is not that battery degrades, it is that their phones could not handle it and shut off when charge still remained. 2 years is a very little time. None of the devices with batteries I had exhibited that behavior. And I have devices that are over 5 years old in regular use.
This is a nice headline, but doesn't match reality. I really hate how much of an Apple fanboy I'm coming off in this thread, but if you're just going to spout straight lies, it's hard to ignore.
It's true that overtime iOS has become way more bloated, but they have released major updates which actually sped up older devices because they were focused on bug fixes and improvements, rather than something that's flashy and looks good in a commercial.
Is it a useful tactic to sell more phones? Absolutely. It also means that iOS completely destroys Android's statistics on % of users who run the latest version of their OS.
Yeah, good point, if I remember they did give you the option to override the battery safety feature and preserve your clock speed. Still, I think it is fair to say that iOS did over time start to feel more sluggish as they were adding more ambitious features which an aging chip couldn't handle.
I'll take updates that slow my phone as long as I'm also getting security updates. I don't like have my banking app cut off because I no longer get Android updates.
I used to work at G, so my view is based on that. The three key infrastructure services that handle this for you are: Colossus (scale-out distributed filesystem), Chubby (lock service), and Spanner/Bigtable (scale-out databases). All three of these handle concurrency for you, and as long as you are okay accepting their concurrency models, you basically get the hard parts of a distributed system done for you. Of these three, only Spanner and Bigtable have similar competitors that are publicly available.
On top of those services, Google also has distributed systems that handle higher-level things like authentication, and they have libraries that help you do things like load balancing and load shedding. To top it off, the monitoring available is top-notch, and there are lots of administration tools that allow you to make sure that your service and all of your customers are well-behaved.
Seems like a market opportunity here for an app that makes all of this work in a sensible way. Difficulty may be in making it possible to integrate into the target users' idiosyncratic editor+Linux tools setups though. And convincing said users to pay for something instead of hacking config files and scripts.
I got used to it and cannot make the switch to Wezterm because everything is unreadable to me now.