No dude, it was an analogy. Sorry to pick on you, you're just another ignorant uninformed take in this thread, but come on. This technology is progressing at an insane rate, the shit it's doing now is science fiction from just a year or two ago, and people just keep on moving the goal posts, it's maddening. The technology is unpredictable and that in itself has risks. You must realize that the window of possibility is widening the further into the future we go! Can you pick people with epistemology you trust and see if there's anything you can learn in this moment? Can you try to challenge your own ideas instead of retreating into comfortable certitude? There are real risks here, they are worth taking seriously, and serious people are doing so!
I would bet that using this, you could get pretty close to shippable PCB on first try. This is being used by some pretty big players to design complicated high frequency boards, and that's the main focus of the product, but it can handle basic designs just fine.
Visions of vast data centers surrounded by fields of browning grass, in which aging, rusting, formerly extremely expensive hardware is spending billions of compute cycles looking at anime catgirls
Warmer water holds less dissolved gases of all kinds, including CO2. You can see this yourself by heating water in your kitchen. Well below the boiling point, you can observe tiny bubbles, which are composed of nitrogen and oxygen dissolved in the water coming out of solution. The oceans will eventually become carbon sources, not carbon sinks, if they warm enough, but that's not projected to happen this century.
However, there are regions of the oceans which currently absorb lots of CO2 which will absorb much less as time goes on. One important example is the AMOC, which, by turning over lots of water, helps sink surface dissolved CO2 into the deeper ocean. In recent years, oceanographers have observed a weakening of the AMOC, which was predicted but is happening much earlier than expected. This is one of the important planetary tipping points, which could cause a dramatic shift in the planet's climate.
But don't worry -- the Trump administration is defunding programs like the Office of Oceanic and Atmospheric Research, decommissioning the Ocean Observatories Initiative, and is planning to shutter NOAA's research arm altogether -- thus solving the problem once and for all.
And one scary observation related to this is that warm water will also hold less oxygen for marine life, literally throttling that part of our life-support.
Back when I still used Google, in the dark old days of mid-late 2025, it sure seemed like the SEO was winning. Once you got to page 3, where the ads ran out, you would then smoothly transition into total scam. A common one was where they'd show you scraped SO (remember that one?) content which somehow placed higher in the rankings than actual SO, and there'd be like 3 of those in various skins. I assumed they wanted to show me more ads, though those were much more easily handled with an ad blocker, unlike Google's search results. I assume it's continued to deteriorate from there, does anyone know?
This is a genuinely huge deal, and I think it's worth appreciating why hydro makes sense here specifically, even though the headline cost looks steep.
On paper, this project runs around $5M per megawatt of capacity, while utility solar can be built for roughly a fifth of that. But that comparison is misleading once you factor in capacity factor --Churchill Falls runs near 74% of its max output almost all the time, while solar in most places only hits 20-25%. To match the same annual output, you'd need to build solar at more than 3x its nameplate capacity.
And even then, batteries only solve the day/night problem. Labrador can get stretches of overcast, snowy weather for a week or more at a time, and multi-day battery storage is still wildly expensive compared to a reservoir that just stores water until it's needed.
Try this same approach somewhere sunny and cloud-free like Texas, and solar+storage would almost certainly win, especially when accounting for the land area that needs to be submerged by the reservoir. This project makes sense because it's matched to the geography.
One problem with hydro is we've long ago exhausted the easy wins, and then went on to build the kinda wash outs. See the fight over Glen canyon, which even its architect went on to admit was a mistake. The wins now are in closed loop pumped hydro; see https://www.volts.wtf/p/whats-the-deal-with-pumped-hydro
> A number of prominent Westerners have spoken out against the dam over the years - Republican icon Barry Goldwater, former congressman and interior secretary Stewart Udall, his brother and another former congressman, Mo Udall, and David Brower, a patriarch of the environmental movement.
> All supported dam legislation in 1956. All now say it was a mistake. Goldwater calls the dam "the one vote I wish I could take back."
Thanks for providing an update, but none of those people were the "architect" in any sense, political or otherwise.
The main person responsible for getting the dam built was Floyd Dominy, and he still supported the dam up to his death, which is why I asked in the first place.
I tried repeatedly with several credit unions, with poor results. The final straw was the patelco hack that made the entire bank unavailable for over a week. In the aftermath they implanted crazy security measures where talking to a rep required 6 layers of increasingly invasive authentication. But... The hack was of the bank infrastructure. It had nothing to do with individualized fraud, all accounts were affected --it was just security theater. I went back to a major bank after that.
I'm not going to argue since I haven't used mise, but how beginner friendly is it? The nice thing about "just" is literally the "can learn in an afternoon". When I was in a team of, well, less motivated developers, that mattered. It meant they could modify and maintain the justfile without everything depending on me.
Of course, if those aren't dynamics you have to deal with, definitely go with what works.
There's also invoke (https://www.pyinvoke.org/). I suspect it too is more powerful than just, and I know teams that use them.
One issue with Just is that by default each line in a recipe is executed in a sub shell. Set a variable in line 1 and you can’t use it in line 2. Mise `run` blocks are embedded shell scripts. Alternatively, you can pull those scripts out into individual files so that you can edit them with syntax highlighting etc with any editor that understands shell scripts. Perhaps you can with just now, too, but mise makes it trivially easy. You can get away without a mise.toml at all if you just put your scripts in the right directory.
> One issue with Just is that by default each line in a recipe is executed in a sub shell. Set a variable in line 1 and you can’t use it in line 2. Mise `run` blocks are embedded shell scripts.
just supports the same. If you begin a recipe with a shebang (#!/bin/bash), then it dumps the whole recipe to a file and executes it as a shell script.
Not limited to bash - you can do the same with Python, etc.
As for scripts in their own files vs embedded in a justfile: I've noticed people's opinions vary. Even in my team we'd debate the issue. I prefer them in the justfile so I can read them in one place - as long as it's not huge. Some team members preferred them in their own files.
There was something about the shebang method that made someone else that I wanted to use not work but I forget the details. In any case, just is very nice — I just like mise more at the moment.
The own-file bit comes in nice when you want to run them standalone (CI/CD; maybe someone doesn’t want to use the runner) or you’re fighting against escaping rules. I like having them in the mise file when they’re just a couple of lines. If it turns into a full-on thing, then I prefer to extract it.
reply