asciimike

Hah, fair. 20 is probably a better choice for superchargers given the location.

I was just up in the Bakken and all I saw was F250's. Maybe if Cybertruck ever happens we'll see those adopted instead :)

I'm pretty sure that stock photo at the top of the article isn't actually a bitcoin miner, it's probably just power/control equipment for the site.

> I disagree that it's a good thing. It's still being burned, so the environment damage is still there.

I won't try and argue against "if we never had fossil fuels, the environment would be better" (I agree, but we also probably wouldn't be communicating right now, were that not the case), but by mitigating flares, you can significantly reduce methane emissions (98+%), CO2 (~70%)/CO (95%), VOCs, etc. It's not "good" for the environment, but it's a hell of a lot better than what's currently being done.

Lots of folks ITT have discussed a carbon tax on emissions; think of flare mitigation via crypto as an economic incentive for companies to voluntarily reduce their emissions much faster than a state/federal government can move to enact legislation. It achieves the same end result, just one is aligned with the current dominant economic system in the country, and one would likely end up in political gridlock.

ND has passed legislation to incentivize flare mitigation (e.g. https://www.ndlegis.gov/assembly/67-2021/documents/21-0935-0...) that aims for the carrot rather than the stick, though I anticipate that at some point in the near future we will see more jurisdictions go for the stick.

In the hierarchy of moving things around, from difficult to easy:

- natural gas (building a pipeline)

- electricity (generation, transformers, high voltage lines, etc.)

- bits (copper, fiber, microwave, cellular, satellite all are viable for low bandwidth operation)

It's orders of magnitude in terms of cost difference.

The issue with superchargers is mostly that these places are in the middle of nowhere--nobody is going to be driving their Tesla across the Permian.

No promises of course (I'm sure that an EC2 PM is already reading this thread and preparing to drop P4d prices to make me eat my words), but given the structural advantages we have, we're planning on being able to consistently offer top tier compute at a meaningful discount to major players.

A100s for ML training as well as simulations/FEA/CFD/etc. E.g. we're working with the physics dept at a large university to do various theoretical physics simulations.

A40s for rendering and transcoding. We've got some A5000s and A6000s for similar purposes, but at a lower price point.

ETH mining is something folks could do if they'd like, but not something we're explicitly targeting.

Hi! I'm the product lead for [Crusoe Energy's](https://crusoeenergy.com/) cloud product, which is building a climate aligned data center powered by stranded energy (e.g. flared natural gas). Can confirm it's definitely possible, though definitely a non-trivial problem :)

If you're interested in using our cloud or joining the team to help scale our data center deployments or software, feel free to reach out (mike at crusoecloud dot com).

I'm the product lead for Crusoe's Cloud; thanks for mentioning us!

Our data centers are currently in alpha with a number of A100's and A40's currently running on flared natural gas. We're able to offer a product that's carbon negative (each GPU running for a month offsets ~400kg CO2e) and also ~40% cheaper than hyperscale cloud providers.

If you're interested in giving our cloud a shot, feel free to email me @ mike at crusoecloud dot com.

And of course, we're always hiring: https://www.crusoeenergy.com/careers

> the number of cars with no license plate displayed at all is on the rise

I have noticed this too, and am curious if it is:

- DMVs being slow/understaffed or plates aren't available, but people need to drive

- conscious negligence of simply not registering your car and betting it won't be enforced

Mostly because it's more work to manually remove a bunch of spurious robotically added statuses (which look bad, because you're either down more than customers are noticing or your detection is flawed) than it is to manually add and remove real ones.

1) SLAs are almost always customer initiated (see "Customer Must Request Financial Credit." in https://cloud.google.com/appengine/sla for example)

2) The SLA isn't tied to the status page at all, a customer can request an SLA refund for any reason provided they have proof of damages.

TL;DR: status pages are a helpful tool to let folks know something's wrong and that the team isn't asleep at the wheel, not a legally binding contract.

Ish? I wrote some stuff up here: https://news.ycombinator.com/item?id=30182591

When I worked at GCP it was all manually updated as well so we could add a sentence about what was actually affected. In any sufficiently large system it's hard to indicate exactly what's broken/how to work around it, so it was just easier to `/status <system> <color> <reason for status>`.

Correct. SLAs aren't calculated off status pages, there are far better ways of calculating it (running a query over responses, for example). Most modern SLAs are customer initiated anyways, so the customer is writing in to request this rather than automatically calculating them. The status page doesn't need to show anything for a customer to provide logs indicating a QoS less than that promised in the SLA.

I don't think it's politics (maybe AWS's is, but GCP wasn't IMO), it's really a function of "in large scale software systems things are constantly failing in all sorts of ways, and it's really hard to output a meaningful automated signal that things are broken. Sure you can set up pingdom type health checks on every endpoint, but even then you're not necessarily guaranteeing that things are working properly.

Source: worked at a few cloud providers, paid out a few SLA violations

github.com is having issues across the site, the API including git operations (and CLI) still work. Status page is manually updated, and we're working to get it updated.

EDIT: it's updated now.

EDIT EDIT: github.com is back up and running, apologies for the disruption :(

Source: GitHub employee

Ah yes, where NFTs are stored on CVS receipts. Given the recent meter long receipts I've gotten from my local CVS, it's entirely possible they are already doing this.

In the event of using 2 1GB drives with one stored in the sock drawer, how do we prevent the quite literal "evil maid" attacks altering the CSVCHAIN?

Additionally, if we do use this mechanism, I petition to fork the name from CSVCHAIN to SockChain.

I see that CSVCHAIN is "held in cold storage on this USB drive" a 1 GB thumb drive. This seems to imply an upper bound on the number of NFTs on CSVCHAIN. How, I wonder, does the creator of this project expect to scale CSVCHAIN beyond this limit?

Additionally, can we secure guarantees that the project owner is safely ejecting the USB drive in question?

I was also skeptical until I stood next to a statue of the Colonel, dressed in a Santa suit, outside a KFC in Akihabara (photo proof available on request). I agree it's probably mostly clever marketing, but they definitely do lean into it over there too.

ACX had some good commentary on this in recent posts:

- https://astralcodexten.substack.com/p/whither-tartaria

- https://astralcodexten.substack.com/p/highlights-from-the-co...

Lots of potential discussions on why we're stuck with "ugly" modern architecture (is it due to materials/construction costs, environmental/safety regulation, architect's desires to be different...), and generally a more enjoyable piece than this one.

Plus there's a brief discussion on a hilarious conspiracy theory.

I paid $65.28 (before tip) for a Lyft from downtown to SFO last night (14.27 miles), for a $120 flight to DEN.

I'd like to think that Uber/Lyft changed the industry for the better (and in many ways they did: app is easier, upfront pricing, easier/safer payment, more accountability through location tracking and ratings), but I don't think that the underlying economics have changed all that much (other than the period of time where Sand Hill Road was footing half the bill).

James Mickens' "Blockchains are a bad idea" talk [1] is a great explanation that discusses exactly that.

[1]: https://www.youtube.com/watch?v=15RTC22Z2xI

Here's a good analysis of the financials in the S1: https://cloudedjudgement.substack.com/p/gitlab-benchmarking-...

Re 3: Michelin has a "track connect" for their track tires ( https://www.michelinman.com/auto/why-michelin/technological-...)

I haven't used it, and most serious track rats have a separate data system so the track connect features are potentially redundant, but I assume that it's an MVP of what a consumer product might look like in the future.

I think you forgot about the drop bears

It doesn't, and was meant as a question

Dependabot PM here:

We've provided an action that will provide metadata (e.g. semver bump) that you can use to enable granular automerge. See https://github.com/dependabot/fetch-metadata/#enabling-auto-... for an example.

> I end up having to add an entire docker block scoped to each directory that has a Dockerfile which is painful. Ideally, I would have a way to specify using */Dockerfile as a way to scan for Docker dependencies.

Glob syntax in `directory` would be sufficient, yes?

Let me know if https://github.com/github/roadmap/issues/148 is in the right spirit of what you're aiming for.

I think that what will get implemented will be a bit broader (covering version updates and security updates) and will allow for grouping by manifest, language, vulnerability, and potentially arbitrary labeling in the config file.

Dependabot PM following up a few days late

> Is there an option to tell dependabot "make one PR per week at most ...

You can set the `open-pull-requests-limit: 1` (https://docs.github.com/en/code-security/supply-chain-securi...) and the `schedule.interval: weekly` to limit the number of created PRs to one per week

> ... and bundle your changes"?

We've referred to this feature as "grouped updates" and it's tracked on the roadmap: https://github.com/github/roadmap/issues/148

Potentially using `allow: direct` (https://docs.github.com/en/code-security/supply-chain-securi...) to ignore the random sub dependencies, or ignoring minor versions (https://docs.github.com/en/code-security/supply-chain-securi...) of some/all dependencies might help reduce that noise.