orangeboats

joined 1 year ago
[–] orangeboats@lemmy.world 9 points 1 month ago* (last edited 1 month ago) (1 children)

Usually I sympathize with sentiments like this ("people use X because of uncontrolled circumstances"), but browsers are not one of them.

If you have a website that requires the use of Chrome, then just use Chrome for that website! It's not an either-or thing -- you can install both browsers and use Firefox as the primary one.

And some people will want to stay on Chrome.

And that's what makes this statement so problematic. You don't earn anything by staying exclusively on Chrome, when both it and Firefox can work alongside each other.

[–] orangeboats@lemmy.world 6 points 1 month ago (1 children)

Are the streamed data stored in a local cache? Surely the bandwidth costs are going up to the sky with the server sending data to every single player.

[–] orangeboats@lemmy.world 11 points 1 month ago

I think there's one key thing you missed: you have never bought a copy of the game on Steam! It's always been a license. Valve simply made the fact clear now because of legal changes.

so the next question, is this retroactive

So the answer for this is a solid no.

[–] orangeboats@lemmy.world 2 points 1 month ago (1 children)

In the past, fitness (and hence its proxy parameters like height and other beauty standards) correlated to the survivability of your bloodline. So it makes sense that people are programmed, to a certain degree, to admire things like tallness.

Nowadays because of technology the correlation no longer exists, or at the very least it is much diminished. But the programming is still there right in our DNA, so as a people we should artificially override this natural instinct because it no longer serves a purpose.

[–] orangeboats@lemmy.world 5 points 1 month ago (3 children)

Well, tallness surely would be a preferable criteria back then! To a certain extent, it is a proxy parameter for fitness.

I just think we can actually use evolution to explain a lot of things that we do, it doesn't mean we should do it.

[–] orangeboats@lemmy.world 24 points 1 month ago (6 children)

Unfortunately not just America. Heightism is also prevalent in a big part of Asia.

This is most likely one of the quirks brought to you by Survival of the Fittest rule. Thanks, evolution.

[–] orangeboats@lemmy.world 6 points 1 month ago* (last edited 1 month ago)

With proper punctuations: There are three words in "the English language". The other half of it is supposed to be a misdirection.

But yeah, the original joke was really bad in the first place. I don't blame the second guy for his reaction.

[–] orangeboats@lemmy.world 1 points 1 month ago* (last edited 1 month ago) (1 children)

For SSDs this has historically not been the case, there's no way in hell you could buy a 1TB SSD within $200 a decade ago.

[–] orangeboats@lemmy.world 12 points 1 month ago (1 children)

Hydrogen is troublesome as an energy storage. The roundtrip efficiency (electricity -> hydrogen -> electricity) is just... very not worthwhile compared to batteries. Then beyond efficiency there is still the question of "how do we store hydrogen safely?"

Storing energy indefinitely is not a problem for electricity storage, since we are pretty much guaranteed to use the stored energy up in a single day.

[–] orangeboats@lemmy.world 10 points 1 month ago* (last edited 1 month ago) (1 children)

It is all quite complicated.

  1. A renewable producer (e.g. solar panels) cannot produce energy 24/7. And when it produces energy, you are not guaranteed the production is stable.

  2. A consumer cannot consume energy 24/7. And when they consume energy, you are not guaranteed the consumption is stable.

  3. To make the issue worse, a producer may not be producing energy when the consumer wants it, and vice versa.

  4. Currently, energy storage is not widely installed. Hence any produced energy must be consumed at the same time.

The factors above combined means that there will be a mismatch. If the production is too great, your electricity appliances will probably explode and whatnot. If the consumption is too great, you experience blackouts. Neither are desirable.

Now consider there is a middleman. The grid. Producers sell energy to the grid. Consumers buy energy from the grid.

At some point in time, due to the factors above, the grid will need (A) zero to negative prices to encourage consumers to buy & use more energy from it, and to encourage producers to produce & sell less energy to it. Or (B) increased prices to encourage consumers to buy & use less energy and producers to produce & sell more energy. A flat price is not realistic. (Residential users only have a flat rate because our demand patterns are more stable.)

But due to the production patterns of renewable energy and consumption patterns of our society, there is a not-insignificant risk that renewable producers will consistently face scenario (A) above making it difficult to cover back the costs.

[–] orangeboats@lemmy.world 8 points 1 month ago

There are a lot more ways to store energy other than lithium and hydrogen.

Pumped storage, vanadium redox battery, sodium battery, ... I'd even say they are most suited for grid-level energy storage.

[–] orangeboats@lemmy.world 1 points 1 month ago* (last edited 1 month ago)
4
submitted 1 year ago* (last edited 1 year ago) by orangeboats@lemmy.world to c/rust@programming.dev
 

For context: I am trying to write a Rust wrapper over a C library.

Like many C libraries, most of its functions return an int. Positive return values are meaningful (provides information) and negative values are error codes.

To give an example, think of something like int get_items_from_record(const struct record *rec, struct item *items). A positive value indicates how many items were returned. -1 could mean ErrorA, -2 ErrorB, and so on.

Since this is Rust, I want to represent this kind of integer as Result<T, E>, e.g.:

enum LibError {
    A = -1,
    B = -2,
    // ....
}

// LibResult is ideally just represented as an integer.
type LibResult = Result<NonNegativeInteger, LibError>;

// Then I can pass LibResult values back to the C code as i32 trivially.

Is there a way/crate to do this?

view more: next ›