Readit Newsylere commented on Starship Flight 5: Launch and booster catch [video] twitter.com/SpaceX/status... · Posted by u/alecco
"... Super Heavy[1] has 3400000 kg of fuel at launch ..."
So, 34M kg of fuel has to be burned (in this booster alone) to facilitate a flight ... and I see that the propellant is CH4 / LOX[1].
Burning methane is much, much better than simply releasing methane but the release becomes CO2 instead ...
What is the back-of-the-envelope conversion of 34M kg CH4 vs., for instance, 34M kg of kerosene/JP ?
[1] https://en.wikipedia.org/wiki/SpaceX_Super_Heavy#Engines
Methane has 28% more energy per kg than kerosene and also produces slightly less CO2 (2.75kg CO2/kg burned vs 3.00 for kerosene) when burned [1]. SpaceX uses a 78:22 LOX to CH4 ratio, so for 34M kg of fuel burned, 20.57M kg of CO2 are produced (34×0.22×2.75).
[1] https://www.engineeringtoolbox.com/co2-emission-fuels-d_1085... [2] https://x.com/elonmusk/status/1298426245991063554?lang=en
ylere commented on What, Me Worry? The Art and Humor of Mad Magazine nrm.org/2024/08/mad/... · Posted by u/bookofjoe
I love MAD magazine. I remember my mom half-jokingly telling me to stay away from my older cousins' copies as a kid. Funny now, considering how tame it is compared to Tiktok/twitter humor. But as a kid it felt otherwordly.
Anyways here's the example MAD folding picture from the exhibit when its folded -- https://www.google.com/url?sa=i&url=https%3A%2F%2Fbtwberkshi...
> Anyways here's the example MAD folding picture from the exhibit when its folded -- https://www.google.com/url?sa=i&url=https%3A%2F%2Fbtwberkshi......
Working link to the page that contains the picture: https://btwberkshires.com/arts/visual-arts/mad-magazine-draw...
ylere commented on Pains of building your own billing system arnon.dk/the-14-pains-of-... · Posted by u/arnon
What are y'all using for entitlements? Do you use your feature flag system? A different saas like Stigg? Or a separate internal system?
I was just coming to hn this morning because I wrote about using FF for entitlements: https://prefab.cloud/blog/modeling-product-entitlements-with... I took some inspiration from another of Arnon's posts about SKU format for the post.
FF don't seem like the perfect place for entitlements, but in my experience they're often the best tool at hand to deal with the challenges. I'd love to hear alternative opinions.
I think as long as "feature flag entitlements" are seen as distinctly different from what engineers usually use feature flags for (small incremental changes of individual components, testing, roll-outs, A/B testing) they can work well. An entitlement should have a clear link to a customer-facing feature, which are conceptually much larger blocks of functionality. One difficulty with this approach is that you still have to take into account a lot of billing-related aspects, e.g., handling customers in arrears, overage charges if they go over a certain limit, having different pricing models for the same feature, or resetting/carrying over usage counters on plan changes/upgrades - this can add a lot of complexity over time!
That's why we decided to offer separate feature entitlements that are tightly coupled to the billing chain and metering as part of Wingback (disclaimer: I'm the CTO). In the end, depending on your plan complexity and how much you have already invested in feature flags, I think both approaches can work well. Having some kind of feature gating in place for your customers will also make your life a lot easier for provisioning customer accounts and being able to offer custom packages.
ylere commented on Pains of building your own billing system arnon.dk/the-14-pains-of-... · Posted by u/arnon
This is a great article for people who are in the situation where they have to make decisions about billing and don't have much experience (and as a handy reference for those who do, but want some reminders, too.)
However, I will admit, I had a hearty chuckle at this line:
> "why can’t we just dump a file of what we need to bill on S3, and have a CRON job pick it up and collect payment?"
Under no circumstances does my engineer brain think this is a good idea. At all.
But, I will dump one aspect of my engineer-brain thoughts: My favorite "billing architecture" decision is to try to decouple billing as much as possible from credit in a system. For example, if you have a subscription system where the user pays ahead for a given billing period, I prefer to have the entitlement itself just store the expiration date and the details about what entitlements the subscription grants during the time period it is active. The billing system can store the subscription and sync back to the entitlement as-needed. This makes both manual billing by human operators (not to mention debugging and patching around momentary issues) and something like a Stripe integration very easy. You should, of course, be very careful to leave it open for extension in the future, but this seems to be a very nice decision that doesn't, in itself, limit you too much.
Obviously, this is not my original idea, but it's still something I've grown to like a lot, especially after having tried other things less successfully.
My experience has been that there are typically two types of engineers: those who have worked on billing systems before and those who haven't.
I think a lot of the issues arise from the difference between payments and billing [0]. When just starting out and signing up your first customers, you primarily care about collecting a few (recurring) payments - and it's really easy to set that up with Stripe (or even just manually invoicing your first customers).
However, over time, more billing requirements gradually sneak in, such as more complex entitlements, multiple plans, grandfathering, and eventually enterprise/high touch sales customers (where the money is!) who need custom billing cycles, terms, and entitlement provisioning. Since billing is never a technical focus, numerous additions and small hacks accumulate over time, taking engineering resources away from the actual product. Eventually, this turns into an unmanageable mess that can significantly slow down the sales process or limit what you can sell.
The complexity of billing is riddled with hidden pitfalls and edge cases, and it has become even more complex now that most plans include many different limits and usage-based components and that most SaaS companies sell globally. Many later-stage companies have teams of 15+ engineers working solely on billing. I fully agree with the author that, unless it's at the core of your product, no organization should build a billing system themselves (Disclaimer: I'm the CTO of Wingback, a SaaS Billing Platform).
[0] https://www.wingback.com/blog/saas-payment-vs-saas-billing
ylere commented on Privacy focused platform Skiff is joining Notion, Skiff to be sunset notion.so/blog/meet-skiff... · Posted by u/mirshko
Been using them on the paid plan for a 1yr+ and apart from working great and reliably I've been really appreciating how no-nonse and to the point their communication has been. Never realized it's also OSS, thank you for pointing that out!
Really easy to set up too, just make sure to also set up DKIM/SPF/DMARC to make sure the forwarded emails don't go to spam.
ylere commented on VirtualBox KVM Public Release cyberus-technology.de/art... · Posted by u/CyberusTech
The blog post mentions an open source license but I can’t immediately see it in the post or the repo (perhaps I’m just missing it). Any idea what license this is released under?
It seems to be a fork of VirtualBox under the same dual license as the original project.
ylere commented on Zeiss's "Holocam" turns glass windows into cameras digitalcameraworld.com/ne... · Posted by u/toss1
Thanks for sharing. More of an animation than a proper video
I found a recording of it here (from IAA 2023):
https://youtu.be/NORPeCcIXRQ
[1] https://www.engineeringtoolbox.com/co2-emission-fuels-d_1085... [2] https://x.com/elonmusk/status/1298426245991063554?lang=en