Make it a local or company-wide identification of FOSS packages, and a way for those individuals, teams, and businesses to score them by importance or criticality (or needs of the FOSS project if they are aware).
Not that I've used this extensively, but months would likely increase to quarters.
And if you're estimating something to the lengths of months, you're already into project management territory size, rather than broken down to development/delivery sizes... The amount of unknown unknowns and other uncertainty certainly warrant happily estimating years length, surely.
Of course there's a need for a lender, even at a microsecond transaction you do need funds to perform arbitrage, it's not just all theoretical funds - there's backing to them.
Else let's all just pretend trade on a real market until it collapses and just make sure they come a-knockin' on some non-existent firm...
Plus my conjecture, from my understanding, is the flash loan terms incentivise fast payback, whilst still retaining some fixed profit.
Akin to a credit card which has an effective 0% rate of you pay back within a certain time frame, but raises to 30% monthly after that.
I'd be happy to provide you with a flash loan at 0.001% fixed rate of profit for me/cost for you for the first 5mins and scare you with a 30% rate calculated every minute after that. For some pre-validated huge sum I know your business can be liable for, of course.
Which allows capital scarce firms to leverage these micro-loans on fast arbitrage opportunity where they should take any transaction that provides anything larger than that 0.001% in transacted profit. And let's them compete with larger firms on optimising pricing.
It’s not a microsecond, it is zero seconds. The entire series of trades either succeeds as a bundle, or does not happen at all.
This is quite different from "normal" arbitrage, which consists of a series of non-atomic trades. There’s various risks here, both on the side of the arbitrageur (offer books can change, making the trade non-profitable halfway through) and by extension for all counterparties (due to the arbitrageur not being able to settle for the promised/borrowed amount), as well as non-zero time of locking up capital. Both have a price.
Latest moves seem to imply Apple might want a slice of the Ad network pie.
So I wouldn't bet on capitalistic ideals/incentives not overtaking idealistic consumer protections.
I'm in a layer that just gathers chargeback signals and passes them off to other teams. I have effectively no insight to how the signals are used for your payment profile and your Google account overall. I mainly just pay attention to people issuing their chargeback against Google, and then posting about it on the internet and the fallout they see.
The article mentions "Transcendentalism", the above comment's author seems to have researched, and offered their opinion on the matter.
Seems like an appropriate comment, and a worthwhile discussion of what the transcendental ethos imply, coupled with what drives the behaviours that are antithetical to those goals, which leads to the historical moments the article refers to.
Have used the conditional that if current page is greater than last page, just return the last. And same with negative just returning the first.
If records are updated / deleted and the last page changed, then you'll just get the results of what the "new last page" are.
At scale you might care about the duplicate or up-to-date records. But cursor-based doesn't solve the problem if a results page is left open for "too long" and stuff was added behind your cursor (or after it, if navigating backwards).
It's as if making things less intuitive (to articles' reference to book pages), makes it any easier as long as you don't think about any pitfalls.
My suggestion is to just use pages, and optimise for the right order (I.e.: sequential IDs, or creation date, alphabetical, etc) that make sense for your data.
If you REALLY must care if results have changed, some delta being stored would be best (like some timestamp that allows the server side to indicate "hey, your results are out of date, from 7 days ago, maybe you left that page/API response unused for too long")
I absolutely agree with this, been there first hand on both sides of the aisle.
And my experience of those I've worked with, has been that the smaller projects that remove this potential to deceive (not profitable or large enough for bait-and-switch - not enough get-foot-in-door to be worthwhile to take at a loss). And by smaller I mean less than £/€/$ 500k, and not leading to multi-million deal later on.
And go away from the RFP process that sucks and is just trying to get the lowest bidder, for a fixed-end-goal, rather than bringing good and experienced people to support your business/organisation/project on achieving something.
I'm trying to launch this myself, and I feel you can get the best of both worlds: great talented people who you pay fairly with a scale model for (eventually needed) growth, and some cost control for mid/longer term projects as you can't really have a fixed price.
At the same time you have to remove some of the downsides like this lack of transparency (and honesty?), whilst having the needed support in place for projects to succeed!
Make it a local or company-wide identification of FOSS packages, and a way for those individuals, teams, and businesses to score them by importance or criticality (or needs of the FOSS project if they are aware).