You can't as far as I'm aware unless you control the entire batch during inference, or don't use batching which would require you to run your own inference.
A creditor calling debt because you violated your covenants is not a rugpull. That's how creditors insure they can be paid back before you predictably run out of money.
Well, I can see how it might be a rugpull or it might not. It depends on what the terms were and what the motivation was for invoking them. I don't have a dog in this particular fight.
Did they actually formally file for insolvency before the new buyout? If they did then there eventually should be an impartial report on this, otherwise we might never know exactly what happened.
So, essentially the system has a serious denial of service flaw. I wonder how many variations of flight plans can cause different but similar errors that also force a disconnect of primary and secondary systems.
Seems "reject individual flight plan" might be a better system response than "down hard to prevent corruption"
Bad assumption that a failure to interpret a plan is a serious coding error seems to be the root cause, but hard to say for sure.
Reject the flight plan would be the last case scenario, but where it should have gone without other options rather than total shutdown.
CORRECT the flight plan, by first promoting the exit/entry points for each autonomous region along the route, validating the entry/exit list only, and then the arcs within, would be the least errant method.
You can’t just reject or correct the flight plan, you’re a consumer of the data. The flight plan was valid, it was the interpretation applied by the UK system which was incorrect and led to the failure.
There are a bunch of ways FPRSA-R can already interpret data like this correctly, but there were a combination of 6 specific criteria that hadn’t been foreseen (e.g. the duplicate waypoints, the waypoints both being outside UK airspace, the exit from UK airspace being implicit on the plan as filed, etc).
The more I think about it, the more convinced I am that completely failing is the correct approach. There are two possible causes for the system not being able to process a flight plan:
1. The flight plan was really invalid. In this case the assumption must be that the upstream system is sending invalid flight plans, which can’t be processed by a correctly programmed downstream app. All data from upstream must now be treated as potentially incorrect
2. The flight plan was not invalid and there is some unforeseen issue in the downstream system (this was actually the case). If this is true, then the downstream system cannot assume it is behaving correctly when receiving valid flight plans, so can’t continue to process flight plans in case it incorrectly process another plan in a more subtle way.
Both cases need urgent manual intervention and should result in a manual review before more flight plans could potentially be processed incorrectly.
What happens with debris or micro debris? They say it's stronger than steel, but steel doesn't really on the entire piece being critical to the structure, so holes won't necessarily lead to catastrophic failures. Or what am I missing?
You’d probably want an auto sealing system. You can coat the inside of your bike tire in a goop that hardens if a puncture happens. The positive pressure squishes the liquid out the hole and it hardens. That will probably be standard equipment in space soon.
"Inflatable" doesn't have to mean "tightly stretched rubber like a balloon" or "lowest bidder plastic heat-bonded together with a picture of a flamingo in it". You can build strong materials that will still inflate, especially with .5-1 atmospheres of pressure, no problem.
I'm pretty sure everyone is using a standard pressure and composition on their spacecrafts and stations now. If you want to dock with existing craft and not have managing atmospheres be a big problem, you want to stick to the standard.
This is very well thought out advice. That said you do need to be focused on the right areas of tax code, and understand that some things can be changed later and some things cannot (at least, not easily or without significant expense).
For example, I relocated to Puerto Rico several years ago and am taking advantage of a 50% transferrable R&D tax credit. Because it's transferrable I can sell the tax credit to people that have a tax liability even if I don't.
After fees, this means I get roughly 40% cash back on my R&D expense. This is a big deal to me and my company.
If you don't do your home work you can potentially miss out on some great opportunities. That said, you do still need to build a good business, or the best tax structure in the world won't save you.
Cleaning out my attic last month, I just found a stash of punch cards left over from the 1980's. Some paper-tape that has my phd dissertation. And a fortran manual from my high school's IBM-1620. Oh my...
I read your book for the first time a few months ago after someone here recommended it. I was hooked. It took me back to my beginnings (99/00) when the internet was different, when we had dial up and there was still discovery.
I appreciate the time you put into writing it — and the nostalgic enjoyment it brought me.
What are you up to these days? Were you able to predict or see the advent of modern AI and LLMs coming from earlier in your career? Thoughts on the future of computing?
All truth is one. In this light may science and religion labor here together for the steady evolution of mankind from darkness to light; from prejudice to tolerance; from narrowness to broadmindedness.
We have been using bullmq in production for just over a year. It is a piece of technology that our team doesn't have to think about, which is pretty much all I could ask for.
We did end up adding some additional generics which allows us to get strong typing between producers and consumers. That I think has been a key piece of making it easy to use and avoiding dumb mistakes.
One step we have taken is to build an auth system that requires you as the developer to explicitly specify the security of an endpoint using a decorator. If no decorator is provided, then the endpoint is completely locked down even to admins (effectively disabled).
If an endpoint is decorated with something that is considered dangerous (i.e. public access), that triggers additional review steps. In addition, the authentication forbids certain combinations of decorators and access patterns.
It's not perfect, but it has saved us a few times from securing endpoints incorrectly in code.
.NET web apps / APIs have an option where you can require authorization on all controllers (and their actions) by default. If you need an anonymous controller/action, you can use the `[AllowAnonymous]` attribute on it.
A reasonable scenario to me seems to be: An automatic "upgrade to the enterprise plan" requirement was triggered, and then in the process of the sales calls to make that happen, Cloudflare got serious eyes on the customer for the first time (whereas at a paltry $250/month previously they wouldn't have), and realized exactly what line of business the customer was involved in, and decided to fire them.
I was rushing to judgment until I heard this... pretty plausible.
In support of your theory particular is I don't think enterprise sales "ragequits" a conversation when the customer is mid-evaluation based simply on the idea that they are considering multiple options.
Why would they walk away at this point, let alone ban the customer.
From the write-up I bet CloudFlare had it as a "60% to close" in their CRM at this moment. It doesn't make sense for them to drop the ban hammer in this moment.
PS: explanation or not, this is deeply shady behaviour from CloudFlare. Just perhaps a little less so.
> In support of your theory particular is I don't think enterprise sales "ragequits" a conversation when the customer is mid-evaluation based simply on the idea that they are considering multiple options.
> Why would they walk away at this point, let alone ban the customer.
It wasn't just that they were considering multiple options. Looking at the timeline, this was about a month after their initial soft gloves approach/enforcement action and they drug their feet the entire way through it.
Once CF got to the top of the leadership chain at their company and it was clear that all the relevant decision makers were involved in the conversation but were unwilling to pay, they just folded their cards, resumed the initial enforcement action, and moved on with their day.
If this was a small account they probably wouldn't have even blinked twice with just striking down the user for causing reputation harm and violating TOS but since they were a large account CF clearly went out of their way to meet with them multiple times and try to find a solution. But after a month of little to no progress while the account continues causing reputational harm and is unwilling to budge, they just called it quits and moved on.
It seems like the sales team went out of their way to try and land a $10k/mo deal. Then when they heard there was a second potential suitor in the mix they got upset and said “well we never wanted your $10k anyways!” and destroyed any chance of reconciliation. Very sour grapes/ no second date on tinder type of reaction.
If there is a TOS issue I’m not listening to a sales pitch on it. You better tell me what the issue is upfront in the first email instead of dicking around with the commission based workers. Like very low level stuff here imo
If it's legal but burdensome (somehow) to host a particular industry, requiring more money to deal with the increased burden seems reasonable. For instance, if their legal department needs to deal with complaints from various countries, that probably costs more than $250/month.
That being said, I doubt that's the core issue in this case.
If you think something your client wants could explode into a liability, you can turn them away or you can just make sure their bill covers your exposure.
If it's a legally questionable service, there's likely to be plenty of abuse contact, or they're going to be a big target of crime, they're going to end up paying more. This is the same reason why some industries (eg porn sites) have always paid more for card processing.
It's not just 10k a month. it's 10k a month for the plan that allows you to BYOIP (Bring your own IP addresses). That was cloudflare's issue.
Their business was causing IP reputation damage and all plans but the enterprise BYOIP plans share the same IP pool.
Essentially it was "use your own IP pool and pay us for the cost of maintaining that pool for you or GTFO".
This wasn't just a normal sales rep hitting them up. This was trust and safety (i.e. the moderation team) coming to them with a compromise that would allow them to stay on the platform. They chose against that and were dragging their feet.
The timeline of the article also really makes this clear. This wasn't over the course of 24 hours. This started a full 4 weeks prior with sustained back and forth. They only included a few images of emails from the discussions but the article makes clear that there was more discussion happening.
And to quote the article. After receiving the ultimatum, they got an entire extra week to deliberate.
> We managed to buy a week of time by letting it escalate to our CEO and CTO and having them talk directly with Cloudflare.
Then finally when they told CF that they were just buying time while looking to move elsewhere, CF dropped their act of goodwill and the moderation team resumed the moderation action they would have taken in the first place had this been a smaller account.
----
So yeah it sounds bad from the snippets but this was basically "hey you are a big customer and you are breaking rules we would normally ban anyone else for but if you can compensate us we'll spend the labor hours and infra to let you keep operating in your own little quarantine box.". So this really should be seen as an act of goodwill rather than malice.
You can't start the timeline from the first email, because clearly Cloudflare didn't communicate the actual issue to the customer. (Yes, the customer could be lying about what was said in that meeting, and they could have been told what the problem was rather than it being just Cloudflare trying to upsell them the enterprise plan without telling why. But then the "omg, we just discovered a problem with your site during a routine inspection!" email sent two weeks later wouldn't make sense.)
They also were clearly lying in those email messages: The second email says that domain rotation is strictly forbidden, but a few days later in the third email they're explicitly selling features for rotating domains more effectively.
And sorry, but a company selling "we'll override the Trust and Safety team if you pay us $$$" is absolutely unacceptable. There are only two options, both bad. Either they're not running a real TnS operation, but just pretend-staff one in order to run these kinds of shakedown operations. Or they're running a real TnS team that found a real problem but are letting sales people override the TnS team's honest judgement.
I can reason my way into it, I think objectively. To protect their IP reputation, CF required BYOIP. This costs them something, and de-jure requires an Enterprise plan. Which for the customers usage costs $X. Is it right? Ehhhhhh. Does it follow corporate logic? Yeah. (Sales logic? YES)
I'm not defending Cloudflare's exact actions in this scenario, but it seems reasonable that there are cases where yes, for $10k Cloudflare is okay.
Risk can be mitigated, especially if you take care to know what the risk is, but risk mitigation and the salaries of the risk mitigation teams are not free.
The answer of "no, we will not host you unless you pay us enough money to hire people to make sure we're not breaking laws by hosting you" makes plenty of sense, and an online casino that is likely dubiously legal in many countries is definitely a place where you might use that answer.
I'd also expect there are cases where Cloudflare enter into enterprise agreements with customers, get a good hard look at exactly what's happening, and then tear up the agreement and walk away.
And all of that is fine when communicated properly. Even if OP is an unreliably narrator are we to believe they also left out some of CF's emails?
To me it looks like https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_pr... is entirely the wrong email to send in the situation and if you are as old as I am and come from where I come from, you will have flashbacks to "reading between the lines" of the party daily in the 1980s. The real content is at the bottom:
> As we have a very short window to report back to Trust & Safety team, please let me know if you can make time tomorrow
Big red flashing lights: the right questions are 1) why is T&S involved at all 2) What are their concerns which forces such a hurried deadline? 3) What are the consequences of missing this deadline.
The right email would start with something like this:
> Providing services to your business constitutes serious legal risk to Cloudflare. We are happy to work with you in the future if you are buying an Enterprise plan. As we need to commit significant resources to accommodate you, we need an annual commitment. Otherwise, with much regret we need to terminate our services provided to you as it is our right per Terms on date/time. ("We may at our sole discretion terminate your user account or Suspend or terminate your use or access to the Service at any time, with or without notice for any reason or no reason at all.")
T&S departments generally exist for one reason: to manage reputational risk. This sometimes involves legal risk, but it usually just means preventing relentless hit pieces about your company enabling something portrayed as horrible. This can result in customers and even employees leaving if the media is relentless enough.
Companies take risks if the reward is considered good enough. In this case, that reward is income from the customer (who can still be dropped if the hit pieces start getting published).
That's not true at all. That line of argument gets close to "if this product is free for open source, why is it not free for me? either it costs something to operate or it doesn't." You don't get to price the service.
The point is more that the author is an unreliable narrator and you need to apply a little salt to the rest of the story. Cloudflare absolutely shouldn't be taking bribes to permit regulatory evasion. But if they are, I want more evidence than a substack post.
Do you have a suggestion to make that not possible? It doesn't seem fair to punish them so aggressively because that might happen. The "may" there isn't a statement of intent.
It also seems strange they dont know their Traffic Numbers.
>Note that 80TB is the number they tried to sell us, I don’t know if it is accurate since they removed all our access to historical analytics.
I mean you dont need accurate Data but surely most would know by heart their traffic in rough figures? Or am I the old dog where every new Web Dev are so used to Cloud and Serverless they have no idea what they are using?
Over 90% of our traffic is cached, since it is static assets. I can look up how much traffic reaches our origin, but the main factor is the number of static files hit. We used Cloudflare Analytics (part of the business plan) to track this, and since it didn't really impact our tech much until now I don't have an exact overview. I mainly know which (uncached) endpoints are hit how much. Fastly is currently saying 15TB per week which seems roughly the same range as Cloudflare's 80TB / month number.
People seem to have a very laissez faire take on egress which I’ve never understood given the really impressive markups the cloud providers charge on it. But yeah, it seems like the attitude is that as long as you’re using “cloud-native” services (AKA locked-in proprietary offerings) then cost is low and doesn’t matter anyway because it’s opex, not capex.
I spend a lot of time wondering if the Emperor is wearing any clothes.
Depends on your scale. I would probably know the traffic for the project I looked at last, but the whole account? No way. Half of it I've never touched and would have to talk to different teams. I'd only look at that when discussing the contract again. Or if their TAM flags us crossing some threshold.
It would be completely different for a small project of course, but once you're counting in TBs... it's less important.
Eh, your traffic is a total cost you pay per month. That's how I would look at it. The one figure I know best of all is annual revenue, and how our annual revenue this year is on track to do compared to last year's.
As far as exact volume of QPS or TB/month or whatever, I really couldn't say.
