PowerfulWizard

I haven't heard of that being a problem for Starlink, whatever they've done there seems to be working. The Orbital AI would be at a higher orbit but still within LEO which reduces the radiation. I wonder if occasional bit flips even matter for typical AI calculations. Quantization seems to suggest a lot of the lower bits aren't all that important. Either way SpaceX has already had success building systems with commercial-off-the-shelf products in space.

To me the biggest problem of the system is the dependence on launch cost. The more launch cost can be lowered the more viable the system is and the more options there are for solving every problem. But IMO the reason Musk is building this system is to lower launch cost. He needs a project that can fund a high volume of launches and create economies of scale to lower launch cost, the way that Starlink did for Falcon 9.

I think it's possible, I'm not familiar with what's really been tried but I see that there are some publications on it, for example there's an ESA project under way: https://connectivity.esa.int/archives/projects/heat-pump-cen...

Musk is deliberately creating a business that needs high volume low cost launch services because in order to get low cost launch high volume is needed, and in order to get high volume a customer is needed. In the same way that Starlink launches were used to create the Falcon 9 economies of scale, the orbital AI will be used to create the Starship economies of scale. He also wants to bet the whole company on this which creates pressure to deliver and not just coast on what they've already accomplished. There are a bunch of related high risk bets but they ultimately connect back to bringing Mars within reach with frequent low cost launch capability.

To remove heat by radiation there's a big benefit to running the GPUs hotter as the radiation will be proportional to the fourth power of temperature. This resource is using 85 deg C versus 60 deg C for OP which will improve cooling performance.

If Nvidia/SpaceX can make the chips run at a higher temperature that would help a lot although I assume it would have already been done if it were possible. Another option is to add a heat pump to raise radiator temperature if the smaller radiator mass can pay for the heat pump mass.

On judging vs. making, also someone has to take time away from development to do code review. If the code being reviewed is written by someone who is involved and interested then at least there's a benefit to training and consensus building in discussing the code and the project in the review phase. The time and energy of developers who are qualified to review is quite possibly the bottleneck on development speed too so wasting review time will slow down development.

For AI generated code if previous PRs aren't loaded into context then there's no lasting benefit from the time taken to review and it's blank slate each time. I think ultimately it can be solved with workflow changes (i.e. AI written code should be attributed to the AI in VCS, the full trace and manual edits should be visible for review, all human input prompts to the AI should be browsable during review without having scroll 10k lines of AI reasoning.)

I don't know what I want exactly but I'm thinking along the lines that SQL is already doing a lot so it would make the most sense to start with a database interface and augment from there, to try to build a system to handle all the common forms of durable storage used by applications.

The type of situation I'm thinking about is for example storing a blob in S3, storing metadata and a reference to the blob's path in a database row, sending a message into a queue to trigger some async processing, and updating a cache. It would be nice to be able to do this through a single API or service, and it would be really nice to do all this within some type of transaction abstraction that would allow all operations to pass or fail collectively, really really nice if the whole thing could be pay-as-you and scale horizontally-ish on shared infrastructure without managing nodes or slots or whatever.

I'm not a Postgres user so I don't know how far you can get currently and I should probably look into it in detail. Coordinating blob/ject storage, database, and pubsub operations is a pain point for me presently. I think that overall system design is going to prevent a database-type system from being a good idea for blob storage but I would still like to see someone try to put three systems in a trenchcoat and try to make it work behind one interface.

Very interesting. My dream is to have something like this, a KV-store, a blob store, and pubsub all behind the same interface.

This looks useful, I usually use guestfish to put files into the image before flashing but this could be a lot more flexible.

Here's what I use (as a bookmark):

    data:text/html,<body contenteditable style="line-height:1.5;font-size:20px;">

No save function obviously but this lets me open a new tab and dump some text.

It's true that Relativity Space Terran-R, Rocket Lab Neutron, and Blue Origin New Glenn are under development and are planning first stage re-use although none have flown. And also Stoke Space is developing a 2nd stage re-use solution which SpaceX hasn't solved yet. I think another American company could have a Falcon 9 competitor within 5 years if they really move fast. But they haven't yet reached the stage that SpaceX reached 10 years ago.

SpaceX’s propulsive recovery testing began over ten years ago, meaning a development campaign starting today would be ten years behind SpaceX if they can progress at the same speed. It seems crazy to me that essentially no one is even trying to follow the path demonstrated by SpaceX.

I think above grabbed Gross Profit rather than Total Revenue, this page shows a 1.1% profit margin: https://finance.yahoo.com/quote/KR/key-statistics?p=KR

Thanks I was looking for this.

One solution is to have the key on paper in a safe, and then let the lawyer know the key is in the safe. If you die they can drill the safe. The nature of the private key makes digital solutions possible, but they aren't necessary. It doesn't have to be handled differently from any highly valuable small object.

There must be a process for unpaid bills, whatever that process is they could just enact it at the user's threshold instead of their own threshold. Ideally a soft limit that would disable networking and resource creation and then later a hard limit where your account is wiped out.

Because of the potential overhang before the billing system catches up I think it would be appropriate to lower the service quotas on this type of account. I'm not sure if the customer can lower their own quotas which would be an alternate cost control strategy but a beginner wouldn't know to think of that anyway. The solution with billing alerts is good at a company level but too much for a beginner in my opinion.

I know unexpected costs were a concern for me when I started using AWS as a student in 2008 and it is still a concern for people in the same situation, just with so much more complexity on top of it all. It will be a tiny fragment of their revenue but as time goes on a higher and higher level of expertise is required to get started, even though you can accomplish a lot with just the free tier. The amount of progress they've made on this issue in the last 13 years is just not impressive.

One thing that would make a difference on small accounts is the ability to do prepaid billing only. That way you define your budget in advance and they enforce it. The problem with the current billing is that people who are new to the system have no hope of understanding what is going on and they have to accept the open-ended nature of the billing system to learn.

For those of us who are helplessly impatient, run this in console:

    document.querySelectorAll(".countdown-calendar__door").forEach(e => e.classList.add("will-open"))

Yes, in the air I'm expecting a very different scenario than on land. No pedestrians just an element of collision avoidance for birds, all vehicles legally required to be broadcasting their position to an automated air traffic control, probably maintaining 100 meters between vehicles versus road traffic being 1 meter from oncoming. In the air it would be almost a pre-planned route with a 50 meter collision avoidance corridor. Plus an emergency landing site selection process, potentially the ability to land on water or an emergency parachute.

Part of the reason I found the paper I linked to be persuasive is that they predict the EVTOL aircraft only needing 2-3x the total energy of an EV. The energy cost in dollars could be less than gas for an ICE vehicle making the same trip. There are very light aircraft with 100HP engines, I'm picturing something light and birdlike.

I'm optimistic about electrical. Here is a high level analysis of power and energy density required for some electric vertical takeoff aircraft, compared to some existing batteries: https://www.pnas.org/content/118/45/e2111164118 (h.t. kittyhawkcorp twitter). The necessary power density is achieved, the energy density needs to improve by about 2x for these vehicles to attain their intended range.

The article also compares the range and energy efficiency to electric and ICE vehicles, accounting for the distance reduction by flying in a straight line versus driving on the road. If I recall it doesn't apply any extra value for time savings. The overall energy used in flying could be as little as 2-3x the energy used driving a terrestrial electric vehicle. Combine that with vertical takeoff and no traffic and we're looking at something pretty compelling.

And how much does it really need to cost compared for example to a Tesla? The weight will be more optimized and the safety regulations I assume are much sterner. The technical complexity seems similar but the volume will be much lower. I don't think it really works if you need a pilot's license so full autonomy is probably also a prerequisite for an everyday application.

I think EVTOL will still be embryonic in 2 years, but impressive in 5 years.

I've enjoyed learning Rust and there is is a lot I like about it, I've just been doing leetcode problems with it though and not working on large projects. In my view, the biggest advantages and steps forward with Rust the language are:

1. Memory management

2. Typing

I think your listed languages all have Garbage Collection? It will probably take quite a bit of mental effort to get comfortable with memory management in Rust but it is a valuable topic if you want to understand performance and language runtimes.

These are great and provoked me to really look into how it worked when I discovered them a few months ago.

I'd suggest watching the 2nd (retrospective) video first, and then the first video if you're interested in more detail.

I grew up reading the newspaper every day and I prefer quite a narrow margin, here is my bookmarklet for narrowing pages (and it changes font).:

    javascript:!function(){var e,t;e='body {margin: auto;margin-left: 100px;max-width: 540px;font-family: "Helvetica Neue", Helvetica, sans-serif;}',t=document.createElement("style"),t.type="text/css",t.appendChild(document.createTextNode(e)),document.getElementsByTagName("head")[0].appendChild(t)}();

You could change the "540" to "900" for your needs. I prefer this to narrowing the window because I prefer the whole screen to have a uniform background color.

Edit I don't think it is infaillible, it didn't work on this page, but it works well on pages with no markup. For more complicated site you may try this: https://oxal.org/projects/sakura/bookmark/

I bought a small-ish amount MobileCoin last weekend after the Signal announcement made me realize it was available. I might as well write up my thesis for why I like it so much, so sorry in advance for the stream of semi-consciousness following.

I sympathize with the people who are worried this will degrade the Signal app. I like Signal over iMessage and WhatsApp partly because of the purity of purpose of the app. I like Signal because it doesn't create a treadmill of constant change and features added to drive engagement. I like Signal because it doesn't have Stories.

Signal as a messaging app is the best of its category, but there are other near-peers, new messaging apps are created every year, and I have ten other apps on my phone right now with DM capabilities.

I view MobileCoin as unique in the cryptocurrency space as a cash-like, private, fast and efficient payments platform and store of value and as that alone it would be great. My biggest issues with using cryptocurrency in a physical-cash-like way are mostly proposed to be addressed by MobileCoin+Signal:

- The hassle of using a non-custodial wallet, which is needed to truly possess your wallet. MobileCoin promises to let you control your own private-key on a mobile device. The iPhone is the most secure device I own: encrypted, biometric'd, and sandboxed. Having my private key on the phone plus a paper backup of the seed phrase is my ideal scheme for holding amounts under five figures.

- Waiting 10+ minutes for a transaction to go through isn't good enough for everyday use. (Look up Monero and Zcash block times and how many confirmations exchanges require for a comparison.) Faster is better.

- The meaninglessness of addresses: sending coins to a 40-character random string has already caused so much confusion. Linking it to your existing Signal address book is far superior.

- Broadcasting your financial life to the universe just seems imprudent, I think privacy wins over non-privacy for this reason. Privacy has intrinsic value.

- Proof-of-work systems just have a certain inelegance that I'm happy to leave behind. And the last few years in the Ethereum world shows how challenging this can be.

It doesn't address the potential volatility that causes problems for a store of value. Which is a negative but not a deal-breaker in my opinion. It might be addressed with something like Stellar USDC but I really don't know enough about the MobileCoin design to know if it is possible on the MobileCoin network. The technology is still useful for transaction processing, it is just more useful if it is also a stable store of value.

I don't view other cryptocurrencies as a risk to MobileCoin. If someone else can create better technology I'll use it happily and I'm guessing the people involved in MobileCoin would do the same.

I don't view MobileCoin as a risk to Signal messenger, because I think Signal will do a good job, or if they don't, someone else will, and myself and my close contacts will switch apps for the nth time.

The biggest risk to MobileCoin is that there might not be a citizen alive with the legal freedoms to actually use it. I really hope the project succeeds and I think Signal has a unique opportunity and unique credibility to do this. I think it will take 2-3 years to fully play out.

This is a slightly more correct command I think:

    du -cb $(ldd $(which ffmpeg) | egrep -o "/[^ ]+" | cat <(which ffmpeg) - | xargs readlink -f) | tail -n1

I think this is what the ffmpeg.wasm-core project is compiling in:

https://github.com/ffmpegwasm/ffmpeg.wasm-core/blob/n4.3.1-w...

Overall I think the wasm size is pretty good, maybe even smaller than the non-wasm binaries to a first approximation.

I agree it makes a lot of sense for stuff that could never be offered as a free back-end service. FFmpeg is a complex app as well, I tried to measure the the size of the binary + all shared libraries on my linux system and I came up with almost 180MB. I couldn't tell if the .WASM file was being transferred compressed either, it should compress more than 2x.

(This is how I tried to measure FFmpeg binary size, I have no idea if it is correct:

    ldd $(which ffmpeg) | egrep -o "/[^ ]+" | \
      xargs readlink -f | xargs stat -c '%s' | \
      python3 -c 'import sys; print(sum(map(lambda s: int(s.strip(), 10), sys.stdin.read().split())))'

178092232

)

It is a really good idea. My #1 question with this type approach was how big the WASM would end up -- 24MB in this case.

Yeah, I'm looking at the rationale for HBM which looks physically similar and it seems to be closeness and the ability to have more wires.

https://en.wikipedia.org/wiki/High_Bandwidth_Memory

But the HBM photos have the 'interposer' layer and look to be using bare dies, the M1 looks to not have the interposer and to be using the DRAM package. I'm not fully convinced with why the DRAM needs to be on the M1 but there must be a reason. Apple's marketing site says their 'Unified Memeory Architecture' uses a 'custom package' so maybe the DRAM package appearance is the same but the interface is not.

Something I was personally wondering about is how the DRAM was added to the M1 'chip'. This image shows clearly: http://web.archive.org/web/20201118042108/https://egpu.io/wp...

I guess they must be using much higher density for their 16G than a typical 16G SODIMM for example. I'm not fully understanding why the memory chips need to be on the M1 package if they're using the same package as all other memory.

This is called gron, I prefer it for reading JSON with a lot of nesting.

https://github.com/tomnomnom/gron

The fuel mileage sounds incredible, it's in the same range as an F150. The pilot must be a major part of the expense, meaning it could also be well positioned for an autonomous shuttle future, if those are ever fully trusted, bringing the cost down even further.

Obviously they still have a long way to but they are saying the right things to get me excited, even though my knowledge of aircraft efficiency is pretty minimal.

edit: It looks like the Yak-152 mentioned elsewhere in the thread can do about 14 mpg if wikipedia & my math is right.