Now that Moores law is dead I think GPUs will depreciate a lot slower. I mean there's already a lot of hardware that has gotten more expensive in the last 5 years.
> I mean there's already a lot of hardware that has gotten more expensive in the last 5 years.
The vast majority of the price rise is mainly due to AI companies sucking all the air out of the room and everyone investing in "AI" regardless.
If China gets their process down to match US/Korea/Taiwan and they decide to flood the market to drown out competitors then hardware is going to be an order of magnitude (or two) cheaper than it is today.
That's 16.6rps. A single guy holding the F5 key on chrome can generate that much traffic and take down your website. That kind of performance was never acceptable.
People will always reframe their request numbers to avoid stating their pitiful requests per second numbers, it's hilarious. "This thing is handling hundreds of thousands of requests per day!" Like cool, you're barely making it double digit requests per second.
As soon as you get your TLS certificate you get bombarded with scraping. You don't need someone to "point a scraper at you".
What matters most is usually how much there is to scrape. If you have like 5 pages that's nothing. For forum like websites where each thread, each user profile, etc. gets scraped that's when traffic increases. I just let them have at it with no issues though, computers are fast.
That's really weird. My experience is quite different: I have several subdomains and all of them have TLS certs and I haven't (yet) seen this (thankfully). Either that, or my server is masking it. The weird thing is that my server is an OVH dedicated box that doesn't exactly have top-tier specs, so I have no idea what's going on there. Very weird indeed.
I mean... It may be that most of the things I run aren't really scrape-able. I run Matrix (which requires authentication), an XWiki instance, Zulip, Terraria, Forgejo, Nextcloud, a Mastodon server... Most of those require auth behind my Kanidm instance to actually do anything. Well and most of them have APIs that are much better than "scrape the universe".
You get downvoted for these opinions but I agree. Most people that complain that their servers get hammered by AI bots are those that run very unoptimized servers that can only handle like 100 rps. I've never had any issues with any of my moderately optimized websites. A $10 VPS can handle sooo much traffic.
I think people get annoyed when it's suggested they spend time optimising or even re-writing their websites to handle high traffic loads just to cater to AI bots ripping their content.
It's also not always easy to do. I run a small wiki which is fairly optimised, nearly every page manages at least ~3k rps on a small VPS. The only exception is the diff page which is ~150 rps. Optimising that while still giving good output isn't that easy, but the wiki doesn't have many users so that would be fine if it wasn't for the AI bots.
The AI bots ignore robots.txt and were initially hitting the site with ~1k rps crawling every combination. Even that would be manageable as there's currently ~150,000 combinations, except they kept re-crawling the whole lot each day. The server could manage it but it was a massive waste of resources.
They were using residential IPs and only sending 1 request from each IP making it impossible to block. In the end I gave up and put a Cloudflare challenge in front of it. I don't want to use Cloudflare but the alternative is forcing users to login to view diffs or remove them entirely.
What I do is have more strict rate limits for non logged in users. You tell them to log in if they hit the rate limit. For non logged in users, you have a rate limit not just for IP, but also for /24 and /16. Forget about IPv6, IPv4 scarcity is a feature not a bug.
The bot I had was using unique IPs for each request. Some were from cloud providers but most were just random residential ISPs. I couldn't see any obvious connections so rate limiting would've had to be a global rate limit.
Each IP only makes ~1 request though so easy to detect after the fact.
I guess they will run out of IPs at some point so maybe if I had logged each one forever and shown a challenge only to them, it would have fixed it eventually. Just depends how big their pool of IPs is.
You were getting 1k rps, and each request was from an unique IP? So after an hour you got hit by 3.6M different IPs? And all from uncorrelated /16s? That seems hard to believe. Not that I don't believe you, it's just hard for me to grasp that whoever was scraping you had such a large and distributed swarm.
This is called rotating residential proxy service. You can buy it off grey market sites that are probably getting it from botnet operators. It costs about $2-$5 per GB.
There really isn't a good reason for a wiki (or git host) to provide diffs between arbitrary revisions to unauthenticated users. Limit it to diffs compared to previous (which can be cached) and this problem goes away.
In any case, such labyrinths of expensive dynamically generated pages are no excuse for subjecting people requesting the start page to bot checks.
Curious, but how do the bots figure out the combinations? Or do you have links to the diffs from other sites? I assume the diff takes two files in query parameters or something.
I managed to solve my scraper problems without optimizing much, but if I had to optimize I think the only option might be "don't use mediawiki" and that's an extremely obnoxious solution. Though maybe I could get there by throttling specific kinds of pages.
Small models don't have enough parameters to memorize the entire internet. For very common prompts you don't notice that, but when you rely on some niche knowledge that might only appear once in the entire web, a single blogpost, a single github issue, a single pdf, you need to be lucky enough that the agent runs a web search AND it returns what you need.
Even as humans there's so much knowledge out there that exists but it's very hard to surface unless you know exactly what you're looking for beforehand.
Exactly, as humans you won't know everything... but you CAN know enough to roughly classify what to "google" for... And if you can google a problem summary, you could identify from a select list of domain specific AI models to use one or more to aggregate work results. And if a person can do that, a model can be trained to do/leverage the same.
You can have a domain limited classification model that then passes the query/work to best match model(s) that do the work... then rollup the results. Basically two very cheap requests instead of one much more expensive one.
If I was developing a rocket, I would prefer making it work first and then iterating on it.
SpaceX is iterating for the sake of a narrative. None of the development goals for Starship require reuse of the upper stages, that's a bonus that should happen after Starship started deploying Starlink satellites.
There is no point in having dedicated reentry tests. Every test flight comes with a free reentry test included.
Even if a company does iterative rocket development, it would never follow the SpaceX way of putting th most difficult but simultaneously unimportant objectives on the critical path at the expense of the essential objectives.
The development program of Starship is basically ignoring every aspect of Falcon 9 development that made it the success people take for granted these days.
The part that makes no sense to me is why they are going starship scale rather than falcon 9 scale. Had they done their prototyping on a rocket with 9 engines on the first stage and 1 on the second, they could have gotten to raptor 3 (and a falcon 9 replacement) while blowing up way fewer engines, launch complexes, etc. There's a reason Spacex started with the falcon 1 rather than the falcon 9. It's a lot cheaper to blow up fewer engines and smaller rockets while you're developing a new rocket engine.
The biggest part of this test campaign is learning to build Ships and Super Heavies quickly and efficiently. They are not just testing Starship, they are also testing and iterating on Gigafactory.
part of my argument is that if your test platform is 1/4th the size, you get much faster iterations. the path they took meant that every test destroys 39 engines, a huge amount of rocket fuel, and all of their construction. A falcon 9 design (9+1) with raptor engines would let them already have a falcon heavy capacity vehicle because everything about a smaller scale vehicle is way easier
They already have a falcon heavy capacity vehicle - Falcon heavy.
I guess I am confused about what you think they would get out of testing with a smaller platform. It seems like most of their focus is specifically figuring out how to make a large platform work. What do you think would translate?
I think that trying to make a large platform work with engines that aren't reliable and on a fuel system that you don't have experience with is a really dumb idea.
The raptor engine is a pretty giant advance over the merlin engine and methane seems like a reasonable fuel, but testing of the engine has been consistently held back by issues they're running into due to scaling up the rocket so much. Starship has only had 12 test flights in 3 years (vs 50 launches since january for falcon 9). Had raptor testing taken place on a smaller vehicle it seems pretty likely that they already would have a falcon heavy replacement in service that could be launching real payload.
I see where you are coming from. I dont think they are interested in relpacing falcon heavy. I have not heard anything about that. what would the point be?
from my perspective, the large platform is the goal, and engines are in service of that. It is hard to imagine that this would would advance the timeline of startship. It seems like there are substantial technical challenges around the fueling system, as well as re-entry, and potentially engine restart in space. Any of these could be fatal, so they need to start working on them as soon as possible, even if the engines themselves arent perfect.
If they had a 1/4 scale test platform, they wouldn’t be testing what they need to learn.
They wouldn’t be testing how to transport, generate, store, load and offload massive quantities of liquid oxygen and methane quickly and reliably.
They wouldn’t be testing the simultaneous ignition of 33 engines, the massive fuel demands of that (which appears to be very difficult), and blasting the pad with 33 engines.
They wouldn’t be testing the structural loads and stresses of max Q of such a massive vehicle.
They wouldn’t be testing tank slosh and pressure issues of massive tanks.
They wouldn’t be testing the heat loads on the shield with huge mass.
All the manufacturing too would be learning how to do things on such a large scale.
In short, they simply wouldn’t be learning the lessons they need to learn to make this work.
The point was more that there is a point where (to borrow the software terminology) "iterative design" becomes "death march". Trying a few times in the early days and being willing to throw stuff out and start over is a powerful tool.
I think blowing up a handful of rockets is a fine idea. But at some point you have to ask yourself if it will ever work? Why are we on a another engine redesign? Why is this the third iteration of the second stage? How many more?
And what number is that point? Six? Nine? I'm thinking thirteen may be getting into the danger zone.
In a somewhat similar situation Sergey Korolyov stopped his colleague in front of the Party officials asking a similar question and explained: "We are exploring terra incognita, this is the process of getting knowledge". He was sort of right - even though there were many specific engineering problems, and many of those were rather solvable, especially in hindsight, overall process was stepping into the unknown.
Here we have a cutting edge rocket design - scale, sophistication of engines, design goals - and a commercial evaluation, which path would get to the intended success cheaper. NASA doesn't like public embarrassments, and, as Henry Spencer reminds us, when failure is not an option, the success could be quite costly. So NASA spends billions and many years for a fragile system. If the goal is an airline-like operations, the design should be thoroughly shaken up. It's known that no simulation, no static testing can equate the actual flights in the ability to get the data best describing what conditions the system will encounter in real use. And also, given the industrial scale of Starship production, each flight hardware costs way less than if we'd built them manually, in quantities justifying naming each unit separately.
In Soviet Union, where rocket departments were part of artillery, the testing with actual launches seemed logical. In this case the approach to run a massive test flight program seems logical too, and we can't complain about the lack of progress - first Starship had way less capabilities and performed way worse. In USA we had more than 1000 tests for injector head for F-1 engine in Apollo program, and this number was justified at that time. Starship is way bigger - but the progress is also undeniable, and it would be odd to stop test flights now, when the 3rd iteration of design looks promising.
So, while we can't pin a particular number of tests, I don't think we should worry yet. This year and the next one should be important for Starship program, given SpaceX commitments to help NASA Artemis. If we won't have orbital Starship then - we can come back to this question.
Not relevant to the discussion, but while it's fairly bland and feels right, I can't find a reference to that quote anywhere. Is this a hallucination? Where did you get it? The fact that you're quoting directly implies you copied it from somewhere.
“Everything that Chertok was about to tell you will take a lot of time.
An explanation of what caused all the failures while solving the soft landing
problem is presented in detail on these posters, focusing on each individual
launch. But there is one general cause that explains everything—this is a
learning process. In our plans and schedules, we did not make provisions for
the expenditure of resources and time on the learning process. That is where
we made our mistake; we have paid for it, and I dare say that in the very near
future the mission will be accomplished. Our learning process has taken us
down a rough road, but we have gained invaluable experience. I request that
the commission permit us to conduct a launch and make the final decision, if
you deem it necessary, based on the results of that launch.”
So what if they blow up literally 100 rockets, if they can eventually perfect it faster and more cheaply than the traditional approach, recently typified by SLS.
SpaceX have already proven that the iterative approach works with Falcon 9, literally the most successful rocket program ever. SpaceX have also proven that this specific Super Heavy/Starship rocket design isn’t a dead end. Criticising them for failing to succeed in the future is a valid but uninteresting opinion.
The point is that by the 100th test flight, your competitor has already proven the first version of their design to the point of being retired by the second version that has a 55% higher payload capacity and had a history of dozens of moon landings and is busy manufacturing solar panels on the lunar surface using lunar regolith, thanks to the orbital infrastructure for lunar transit that they've painstakingly built over several initial launches is paying off.
Meanwhile SpaceX having proven that the iterative development cycle works by first building a successful rocket and accepting customer payloads as soon as possible and then upgrading the rocket as they flew, fell behind because they decided to abandon their origin and instead try to delay success as much as possible which is antithetical to their origin and the success of the launch vehicle. In their hubris, they doubled down on failure, excusing it at every opportunity, while pretending that this is how Falcon 9 succeeded, which is simply not true. You cannot have a radically different development process and call it the same because you're the same company.
It’s cheaper and faster to make in volume. It doesn’t require nearly as much shielding, because it’s less fragile, which saves a lot of weight. The engine itself is lighter. And on top of that, it develops more thrust, at higher fuel efficiency.
The net result is cheaper and lifts significantly more mass to space, which significantly drops the cost per kg to orbit.
It already worked, they’re making it much better, and getting it ready for a level of mass production that we’ve never seen anything close to in the space industry, even from SpaceX. They are much more ambitious than I think people who haven’t been watching them closely understand. The US grid is 1.4 TW of generation, they’re aiming to put up 1 TW of AI compute every year. Maybe they’ll stop well short of that, but their stated goal is insanely ambitious.
v3 is the first version that was made with the intention of being used for actual payload delivery. The versions before were about testing and proof of concept.
The spreads on most markets always seemed like a hint that polymarket transferred wealth from the impatient that don't really understand how it works, to those that play mostly as patient market makers with just an educated guess.
The problem is that volume is generally too low to make significant money.
I'm not saying this as an argument for or against prediction markets, but that's essentially what the vig is at traditional sportsbooks.
Someone calculates what they think the odds of an outcome happening are and then they allow people to take positions on either side at worse odds than what they think the real odds are. As long as their prediction is correct, over time they make money. It's why putting $1 on a 50/50 bet on a sportsbook will usually only pay out around $1.91 instead of $2 if you win.
What's the tremendous externality of gas generators? People heat their own homes with natural gas and it's no big deal. How can a datacenter that is miles away be worse than that?
Its totally inefficient - burning the same gas in a co-generation plant, ideally combined with district heating, would produce the same amount of pollution and basically make use of all the energy.
reply