They're talking about the font on the shirt
HN user
SebRollen
Kind of makes me wonder if the "more than 1,100 employees globally" actually means "1,111" employees. Talk about committing to the bit
About 1,200 kWh per transaction, currently[0]. I wrote about this back in 2022, when it was about 2,200 kWh per transaction[1].
Edit: made a chart with this data, but adding in a bitcoin transaction[2]
[0] https://digiconomist.net/bitcoin-energy-consumption
Do you have an API?
The constant "By the way..." from Alexa drove me nuts.
If you say "Alexa, stop by the way", it'll get the device to stop responding with follow-ups for ~24h. I ended up creating a routine that runs every night at 4am to lower the volume to zero, automatically say "stop by the way" to the device, and then raise the volume a minute later, and Alexa has stopped with the follow ups
I've been tickled by the idea of a follow-up version, Send Me To Hell, where users instead throw their phones _downward_. High scores are awarded based on the maximum speed achieved as the phone hits the ground.
The second example for each language sample where the generated squid ends up being “B4aajs” essentially reads as “P0ooop” to a Swedish speaker.
Which is fine, they don’t propose to filter “bad” words in other languages, but kind of funny when that’s one of the highlighted examples, right next to the goal of filtering words. Goes to show how hard it is to filter profanity generally for international audiences
EDIT: My reply below is wrong - you _can_ deal with in-flight requests with E-Tags as well using the if-match header. I had only seen them used with if-none-match. TIL.
E-Tags would probably not help here, because the client won't have a tag to send along with its request until after the original response returns. But the thing we're trying to prevent in the first place is multiple concurrent requests being processed.
The Idempotency-Key header[1] is probably a better fit, but that relies on the server implementing the spec, including properly dealing with multiple in-flight requests with the same header. I found this blog post[2] pretty good for exploring some of the implementation challenges.
[1] https://www.ietf.org/archive/id/draft-ietf-httpapi-idempoten....
[2] http://live.julik.nl/2021/12/actually-creating-a-gem-for-ide...
The Common Paper app[1], though not quite a git workflow, has always struck me as being pretty close to how an software engineer might approach contracts:
1. An immutable set of standard terms, with variable references.
2. A collection of cover page variables, that modify the standard terms by reference.
3. A structured negotiation workflow, where users "propose changes" to the cover page variables with automatic "diff-ing" (redlining).
It's not a product targeted to software engineers, but has always appealed to me as a way to sneak in some engineering best-practices into the world of lawyering :)
Full disclosure: I'm an employee
Betterment's Cash Reserve[1] might be of interest to you. It's a similar concept, where they spread your deposits among multiple program banks to give you a higher level of FDIC insurance.
I managed to get my rocket very very slowly rotating (<0.1° / s), so that I could just hold the acceleration and have it do one arc from launch to crash:
Unbelievable, the crater is visible from Earth
Score: 1712.2 point crash
Speed: 15226.2mph
Angle: 174.3°
Time: 5963 seconds
Flips: 0
Max speed: 15226.2mph
Max height: 1993862ft
Engine used: 21 times
Boosters used: 14 times
https://ehmorris.com/lander/RoQR: https://roqr.app/
It's a privacy-focused dynamic QR code application. Just got my first paying customer this past week, which I'm pretty stoked about!
The costs of running it are very low (~$15 / month), and it's not something I'm planning on ever turning into my main gig, but the fact that someone is willing to pay for an app I built on my own feels really fun
I'm building an open-source[1] alternative to qr-code-generator (Bitly), called RoQR[2]. The goal is to provide advertisers with analytics for the scans of their QR codes while still being as privacy-respecting as possible to the scanners of the codes - sort of like a Plausible.io for QR codes.
No, the calculation is done per transaction, not per block. You can calculate the per-block consumption pretty easily based on the stat that there are about 150[1] blocks mined daily and the total TWh used per year for the network is 200[2]. 200 TWh per year / (365 days * 150 blocks) = 3.6MWh per block. The amount of transactions per block is around 2,000[3], so if you divide that number by 2,000 you get around 1,800 kWh per transaction
[1] https://stats.buybitcoinworldwide.com/blocks-daily/ [2] https://digiconomist.net/bitcoin-energy-consumption/ [3] https://ycharts.com/indicators/bitcoin_average_transactions_...
I think this commenter put it pretty well, so I'll just link to it: https://news.ycombinator.com/item?id=31596781
You're right that the energy cost is incurred at the block-level, but since each block can hold a certain number of transactions, you can then infer what the effective cost is per transaction. The source for kWh per transaction comes from Digiconomist's bitcoin energy consumption index, and you can find their methodology here: https://digiconomist.net/bitcoin-energy-consumption#assumpti...