AMD could arguably do it. But they have to focus to stay above water at all, and "put 128GB or more of DDR5 ram on any previous-gen GPU" is probably not in their focus. With the state of their software it's not even certain if the community could pick up the slack and turn that into a popular solution.
Their next generation of APUs will have a lot more memory bandwidth and there will probably be lots of AMD APU laptops with 64GB+ of RAM that can use HW acceleration and not be artificially segmented the way Nvidia can do it with VRAM being soldered.
The datacenters I've been in with emergency cooling fans in the walls all exhaust out, not in. Easier to get portable CRACs inside and get a good draft going.
The higher frequency of launches seems likely to have a big impact on reliability. It's no different than deploying once per day vs once per month. The more you do it, the more edge cases you hit and the more reliable you can make it.
SpaceX also has a simplification streak: the Raptor engines being the canonical example. Lower complexity generally means less unexpected failure modes.
My #1 rule for all engineering: simplicity is harder than complexity.
I truly wish more software engineers thought this way. I see a lot of mentality in software where people are even impressed by complexity, like "wow what a complex system!" like it's a good thing. It's not. It's a sign that no effort has been put into understanding the problem ___domain conceptually, or that no discipline has been followed around reducing the number of systems or restraint over adding new ones.
I've seen incredibly good software engineers join teams and have net negative lines of code contributed for some time.
If we ever encountered, say, an alien race millions of years ahead of us on this kind of technology curve, I think one of the things that would strike us would be the simplicity of their technology. It would be like everything is a direct response and fit to the laws of physics with nothing extraneous. Their software -- assuming they still use computers as we understand them -- would be functional bliss that directly represented the problem ___domain, with every state a pure function of previous state.
We might get to this kind of software eventually. This is still a young field. Simplicity, being harder than complexity, often takes time and iteration to achieve. Often there's a complexity bloat followed by a shake out, then repeat, over many cycles.
> Their software -- assuming they still use computers as we understand them -- would be functional bliss that directly represented the problem ___domain, with every state a pure function of previous state.
I love that this is also a model of reality. Everything is made of differential equations.
> SpaceX also has a simplification streak: the Raptor engines being the canonical example.
Not necessarily. Your engine which used to have 200 sensors perhaps now only has 8. But you now don't know when temperatures were close to melting point in a specific part of the engine. When something goes wrong, you are less likely to identify the precise cause because you have less data.
Many of those sensors are not to enable the rocket to fly at all, but merely for later data analysis to know if anything was close to failure.
In yesterdays launch, if the engines had more sensors musk probably wouldn't have said "an oxygen/fuel leak", but would have been able to say "Engine #7 had an oxygen leak at the inlet pipe, as shown by the loud whistling noise detected by engine #7's microphone array"
Say you run a small ISP. You pay for (and utilize) a 10Gbps link to the internet from a big ISP: Cogent, maybe.
You look at your network traffic and notice 5Gbps of it all seems to be going to a single AS: Google. Your customers just love Youtube, and they are pulling down a ton of video.
Rather than leaving that as an interesting factoid, you decide to reach out to Google and pitch them on cutting out Cogent. You run a cable (more-or-less literally) from your network to Google. That 5Gbps of Youtube traffic is running over your connection directly to Google.
Now you can go back to Cogent and drop your commit from 10Gbps to 5Gbps, saving you a bunch of money. Google doesn't have to pay them for transit either: they can serve content to your users straight through the cross-connect. Win-win.
If a particular company is _really_ big, say: Netflix, Cloudflare, etc: you, as a small ISP, might even offer to give them some space in your server racks to host local caches. This makes the performance better for your customers, and, again: saves transit costs.
Sending random packets at another AS just results in your traffic being blocked. The network engineers running these systems are smart, and the community is surprisingly small.
And embrace the future of e.g. AI models deciding if you get healthcare or government services or a loan or if you're a fraud, or not, with zero oversight, accountability or responsibility for the organisation deploying them? Check out the Post Office scandal in the UK to see what can happen when "computer says so" is the only argument to imprison people, with no accountability for the company that sold the very wrong computers and systems, nor the organisation that bought them and blindly trusted them.
Hard pass. The EU is in the right and ahead of everyone else here, as they were with data privacy.
The purpose of our state is to provide for its citizens. So we decided to use a market economy because it seems the most efficient way to do that. But we make up the rules that it runs by and we can change the rules as we see fit.
So it seems now we are saying DEI is not a good rule. Can we make a better rule or is the goal of that rule not good?
> they also told a senior vice president that he had been saying "you guys" a lot and do you know what happened? He thanked them, apologized, and corrected himself.
And you look back on this as a nostalgic memory? Something useful and productive?
result+no error: data returned, no error happened. - Typical function call where you want some data.
no Result+error: nothing to return, error happened. - That typical call failed.
result+error: partial result, up to error. - Wrote x bytes to disk, then ran out of space.
no result+no error: nothing to return, no error. - Data for a passed query. Nothing came back, but that's not an error.