AnyOldName3 @ AnyOldName3 @lemmy.world

Posts

1

Comments

352

Joined

2 yr. ago

Like other commenters have said, start by asking the upstream developer (whether that's by sending a message with a link to the fork or by sending a mega-PR that says you don't expect it to be merged as-is in the description). They should be the best judge of how they'd prefer to handle it. The thing I'd add is that you should try to avoid taking it personally if their preferred approach isn't one you think is a good idea. Sometimes good fixes end up never merged because of disagreements becoming too heated even if everyone's basically on the same page about the fox being good. There's also a decent chance that your refactors are things the upstream developer explicitly doesn't want and would otherwise have done them themselves and implemented the same fix, too, or they don't agree that your fix is good enough. They won't want to be on the hook for maintaining contributions that use approaches and code style that they don't like, and that's okay. They also might know something you don't about their project that would make something that's obviously a good idea to you obviously a bad idea to them.

Basically, just try and remember that if it's a hobby project, it makes progress when the maintainer is having a good time, and gets abandoned when they're not anymore, so try and avoid making a mess and having arguments when they're the one that'll have to deal with any fallout from any mistakes.

You're not throttling between 0% output and 100% output, as that takes weeks or months, and instead throttling within a limited range at the upper end of the output power. Because a nuclear reactor puts out so much power compared to a combined cycle gas turbine, going down to 80% power has a comparable impact to totally shutting down a gas turbine. It doesn't need to be instant to be used for dynamic load - throttling a gas turbine isn't as it takes time for the heat exchanger to warm up or cool down after increasing or decreasing the fuel flow, and time for the first turbine to speed up or slow down after the flow of the Brayton-cycle coolant changes, and then more time for the second heat exchanger to heat up/cool down and more time for the Rankin-cycle turbine to speed up or slow down as the flow of steam changes, and only then is the new desired output power achieved.

Wikipedia puts the average emission time for delayed neutrons at fifteen seconds, which while ludicrously slow compared to a bomb, is really fast compared to the day-night cycle that represents most dynamic load variance in a country with plenty of renewables or heavy industry that doesn't operate at night time, so there's plenty of time for the power output to respond as long as you're restricting the range that it's operating in.

There are plenty of nevers and almost nevers with this case already, so it's not unreasonable to worry that there might be more.

It's likely that my data's out of date, and that graph does include it. If it didn't, it's hard to see how photovoltaics could kill enough people to have such a similar death rate to nuclear if accidents like Chornobyl are included.

The ones in service right now are mostly/all designed that way, but that's a design decision rather than an inherent limitation. They cost basically the same to run whether they're at maximum output or minimum, so they're most cost-effective as base load and if you need responsive output, you can probably build something else for less money. If you ignore that and build one anyway, you only need fast motors on the control rods and the output can be changed as quickly as throttling gas turbines, but there's no need for that if you know you're just building for base load.

Lots of people die mining the materials for photovoltaics, even with emerging technologies that reduce rare earth usage, especially because the countries with a lot of rare earth mineral wealth mostly have terrible human rights, slavery and worker safety records. In principle, this could be reduced without technological changes, e.g. by refusing to buy rare earth metals unless they're extracted in line with best practice and that can be proven (it's typically cheaper to fake the evidence that your workers are happy, healthy and alive than keep them happy, healthy and alive), but then things get more expensive and photovoltaics are already not the cheapest.

Something I've not seen mentioned here yet is that one of the reasons it's such an effective way to make money is specifically because loads of people are buying into it. When you buy a stock (or a derivative like an S&P 500 index tracking fund), it increases its price. If you're just one person with a normal-person amount of money, it won't be enough to register, but if you're part of a group of millions of people, or an investor with billions at your disposal, it'll make a visible difference, and if people see that happening consistently, they'll want to join in and there'll be a positive feedback loop. It only stops when there's a big enough panic that lots of investors can no longer afford to maintain their investment and have to sell at the same time, and then you can even get a positive feedback loop in the other direction when people see the price plummeting and decide they need to sell before it plummets any further.

Stocks are supposed to represent the value of a company's current assets and expected future profits, but this kind of feedback loop muddies the water. With something like Bitcoin, which intentionally has no inherent value, because enough people have agreed to pretend otherwise, it's gained effective value, and can be exchanged for money, or in some cases, goods and services. That'll remain the case until everyone agrees that they don't want Bitcoin, so could go on forever.

Even when disasters like Chernobyl are included, nuclear energy kills fewer people per Watt than any of the alternatives. E.g. dams burst and people like building towns downstream of hydro plants. Even with wind where it's basically only deadly due to accidents when installing and repairing turbines (e.g. people falling off, fires breaking out too abruptly to climb down), it happens often enough that it ends up more dangerous than nuclear. Burning gas, coal and biomass all work out much deadlier than renewables and nuclear, but if your risk tolerance doesn't permit nuclear, it doesn't permit electricity in any form.

It doesn't help when all the senior employees from last time you built a reactor have retired and anyone who hasn't retired was pretty junior the last time around. For projects where you have to get everything right the first time, so can't just try things to see what works, it's devastating to stop doing them if you ever might need to start again.

I thought I was clear enough there that I could get away without a /s at the end. Of course the real meaning isn't it's a really good idea to spend a day automating four mouse clicks you only need to do one more time.

We've had !openmw@lemmy.ml for ages, and been present on Mastodon and Matrix for a long time, too.

I'm one of OpenMW's developers, so that's understandable.

This is silly. Everyone knows that DRY is telling you that if you do the same sequence of mouse clicks three times in a row, you should spend the day writing a script to automate the task instead of quickly finishing what you were doing by doing the same sequence of clicks a fourth time. If you are supposed to apply it to the code you write, then there'd never be boilerplate-heavy languages like Java.

Yeah, looks like I'd remembered it backwards. It's still an easily solvable problem by not using a load everything as whatever type you feel like function.

You're allowed to charge before you give access to the software, but then can't restrict the people you give it to giving it to more people. The beer licence sounds like those people would be on the hook for beer, too.

no doesn't become false, it becomes Norway, and when converted to a boolean, Norway is true. The reason's because one on YAML's native types is an ISO country code enum, and if you tell a compliant YAML implementation to load a file without giving it a schema, that type has higher priority than string. If you then call a function that converts from native type to string, it expands the country code to the country name, and a function that coerces to boolean makes country codes true. This paragraph was wrong. The other paragraphs are unaffected.

The problem's easy to avoid, though. You can just specify a schema, or use a function that grabs a string/bool directly instead of going via the assumed type first.

The real problem with YAML is how many implementations are a long way from being conformant, and load things differently to each other, but that situation's been improving.

It's generally accepted that file formats aren't protected IP, so you can write a compatible reader or writer and be in the clear as long as you reused no code from the original reader/writer. The specification may have licence terms that restrict who you can share the spec with, but you don't necessarily need the official spec to come up with a compatible implementation. Plenty of file formats have been reverse engineered over the years even when the original didn't have a written spec.

I don't think bacterial excretions count as farts, so it's probably more like 800 million years worth of farts as that's when animals started existing.

I think it's pretty likely that you've seen loads and never known they were different. The difference is small enough that you wouldn't realise it was significant until you were told:

Pozidriv is intentionally not backwards compatible, and one of the biggest problems it has is looking enough like Phillips that people assume it must be compatible, use a mismatched screw and driver, and strip a head.