Not just mass optimization either. Intense effort and cost are expended through verification because a single payload simply must work. But using commodity hardware with reduced verification effort, launching many, and tolerating some amount of attrition has resulted in reduced costs for Starlink.
I think if they had a big f-ing rocket at their disposal and could bundle a couple dozen of them MIRV style there would be no political downside if a bunch went splat so long as a bunch didn't
"look guys 9/24 of the rovers are transmitting back, great success"
Testing of using commodity parts was part of the Mars helicopter and it worked well enough that making many of them seems plausible. I'd love to see multiple drones flying faster/further than rovers. Just not really sure what instruments would make them useful.
That's another great example. And ridesharing on the mission allowed them to prove it very inexpensively and with much lower risk than a dedicated mission.
I think the question of technical possibility answers differently from the question of organizational feasibility. Starlink is optimizing costs because they have a financial incentive to do so. The less each satellite costs, and costs to maintain, the more income they make. I fear incentives are not so direct in governmental orgs. Outside contractors performing most of the work have outsized influence, and incentive to inflate costs. Budgetary decision makers all want to see investment in their own districts.
I think Starlink and cubesats have definitely proven the approach can reduce costs.
The engineering does not seem as challenging to me as figuring out how to get such a policy approved and pushed through all the administrative and decision making layers without watering down and budgetary inflation.
Maybe if we launched 30 Starships carrying 30 rovers each. With only 30 units, the prices would likely be similar to current commercial satellites, which are already built on standardized platforms.
I'd go even more radically low cost, and kit the first lander out with wifi, and a half dozen each of every commercially available robot dog, humanoid, and wheeled or tracked robot of any interest. Rumble in the Mars Robodome. Bit of publicity for the existing manufacturers who may be willing to pay for the privilege, and who will undoubtedly learn valuable things about how their designs fail and can be improved. And you figure out in one stroke if there's a COTS platform you can buy for $30k that gets you 80% of what you need. If any of them function for any period of time, you use them to prepare the space for future landings. Rinse, repeat. After a few iterations, you have a half dozen manufacturers with commercially produced platforms with a few strategic modifications to which you can bolt your science instruments.
All I can think about now is a bunch of e-waste littering Mars. At some point, other visitors will show up to investigate Mars and come to the conclusion that the Earthlings are just so trashy their trash even started filling another planet.
The surface of mars is roughly the size of Earth's dry landmass. They'd have to spend quite a lot of effort looking for it to find it. And at that point it'd probably look more like a treasure trove of useful thermoplastics, refined metals, magnets, and other useful things otherwise difficult or expensive to source on Mars directly.
How do these perform for cold-starts? I remember one of the disadvantages of using web assembly for Workers was more spin-up time, but maybe they figured out a way around that.
The cold start numbers on that blog post show that its faster than AWS Lambda but your linked benchmark page [1] shows that Lambda is not only much faster but also much more consistent.
My experience with Rust Wasm workers was that they eventually had shorter cold-start and runtime than JavaScript ones because your wasm is significantly more optimized than a JavaScript one that loads whatever packages/dependencies into its memory.
In many cases, the cold-start time might not be visible to users. E.g. if you serve your static content from a CDN, maybe you have stale content in local storage you can show while fetching updated data. If it all happens on a sub-100ms timescale, it should feel quite instant?
Have you tried Astro? It lets you do exactly that: server-side rendering with HTML templates in component form, with css scoped to the component. No shadow dom needed, no JS frameworks either.
Astro is still fundamentally different, it's not server-side rendered in the sense of dynamic pages. I can't, in a language agnostic way, use Astro to receive a request, get data from the database and render an HTML representation of this data. This won't work in a Go, Rust, or whatever server. Astro at a minimum requires its own compiler to build the static assets, a server to serve them, and a custom API to answer the calls so it can build the dynamic part of pages.
Very handy for nav bars with expandable drop-downs for more links - can now be done with zero JS. Requires much less CSS boilerplate now, and you don’t have to use z-index at all (which eliminates a whole bunch of tricky issues). They also handle all the tricky aria/keyboard/focus mgmt bits for you, too. It works really, really well.
Supposed to be real handy for tooltips too, but haven’t used that myself yet.
Edit to avoid potential confusion: these are separate from modal dialogs, think more like very small popups anchored to one point on the page that still allow you to interact with everything else. Theoretically you can make them modal, but it would be silly to - you’d be better off using <dialog> and the invoker api
This doesn't really hold water. Iron weapons aren't really any better than Bronze, it's stiffer and lighter with an equivalent size blade but not any harder or sharper. Bronze can be cast in more complex shapes that can help with weapon effectiveness and even during the Iron Age bronze Weapons were used alongside iron ones. Iron is much more abundant so the revolution of the iron age was having much cheaper and accessible metal, not superior. It isn't until Steel that you really see bronze (and iron) become clearly inferior.
Actually, maybe we should. Get him distracted and focused on solving that using all of Palantir's might, and then he'll leave the rest of the world alone.
I’m a bit skeptical of the accuracy of the traffic data claimed in this article, 30% of users not being able to use baseline widely available features is a suspiciously large number. Unless this is a very unique set of users, I doubt that it is accurate. Maybe bot traffic messing up the data?
For context, baseline widely available requires that your browser have updated at some point in 2023, which happens automatically for almost all users. For mobile devices, any device that supports Android >= 7.0 or iOS >= 17 would meet this requirement. Chrome even supported Windows 7 through Feb 2023, too.
* iOS >= 17.0 covers 95% of global active iOS devices
* Android >= 7.0 covers at least 99% of global active Android devices
It seems reasonable to me to drop support for Windows XP, IE, and phones that are a decade or more old (iPhone 8, Galaxy S5). And if you claim to be supporting stuff that old, but you don’t test your site on it, you’re just kidding yourself.
https://youtube.com/watch?v=fmkHjDeECps
Also hosted directly on SpaceX website:
https://www.spacex.com/launches/starship-flight-14