Skip Navigation

Posts
6
Comments
454
Joined
2 yr. ago

  • The potential energy is determined by elevation difference and mass.

    That's correct, those are Joules in SI. Now if you turn this mass into mass per second by introducing the flow of water through the dam, you get the power (Watts) produced through the release.

    But here we are talking about energy storage (Watt.hours), which is, for how long will you be able to sustain emptying your container while delivering the desired power. And obviously this is a function of how large the container is because eventually you will run out of water no matter the elevation difference.

    So, now that we are back 3 messages up thread

    could you estimate the amount of water this container would need to be able to retain in a scenario where the grid relies primarily on intermittent energy sources?

    To help you out with the scale, again, your example from earlier (Bath county) has a storage capacity of only 24GWh, annual hydro production of the USA is 256TWh. Bath county has a reservoir of 34•10⁶m³, Oahe dam has 29•10⁹m³.

    Anyway, this is a good tool to keep an eye on this "solved problem", and relate to how the world is dealing with it, independently from the regulatory dissatisfaction you mentioned: https://sandia.gov/ess-ssl/gesdb/public/

    And this paper goes neatly through the variables at play and why oversimplifications are not helpful: https://www.frontiersin.org/articles/10.3389/fenvs.2023.1076830/full

  • I mean, you don't answer the billion dollar question here. Let's not call it a dam, but a container, and let's not mention the need to pump anything. The amount of (potential) energy you can store is a function of the volume of the above container, isn't it? Then, could you estimate the amount of water this container would need to be able to retain in a scenario where the grid relies primarily on intermittent energy sources? And can you propose an engineering solution to contain this much amount of water?

    The intuition here is that you are re-inventing dams, without the room to build more.

    I don't agree nor disagree with the rest of what you say, I just can't get beyond the "energy storage is a solved problem" point yet.

  • well, if there's one troll in this discussion, it's probably the only person making personal attacks and refusing to engage in a constructive discourse:

    • "When you definitely know what autocratic means."
    • "Nice try though, keep exposing yourself as an utter clown."
    • "spend your time doing obvious trolling" "Seems like you’re doing a bit of projecting there bud."
    • "Perhaps you really don’t realize you’re a troll."

    I don't see any argument being made here nor the discussion going forward as the exchange progresses.
    As I wrote before, you are entitled to your own ideas, and this place is to share them. But if you keep repeating that others are trolls and insulting them 5 messages in a row, well, that's some serious waste of electrons.

  • Pumped hydro storage is not a dam, it’s not a power source, it is a power storage system.

    In technical terms, could you lay out what's the difference? You've got a water retention system that empties into a generator and a capability to pump some of the water back upstream. What larger storages and generators do we have besides dams? None, and there's no topographic feature that could be at an advantage there. Because the problem at hand is one of scale: https://ourworldindata.org/grapher/electricity-prod-source-stacked?country=~USA

    Assuming that energy demand remains the same (instead of increasing, which we know will be the case with more electrification), and that, to keep targetting those 4000TWh produced, we replace coal and gas by wind and solar. That would mean having to store what amounts to 2000TWh of production (under an extremely optimistic assumption of 80% storage capacity for the replaced energy only). That would mean that, just to buffer out what solar+wind require in storage, we would have to surpass what current hydro produces, 8 times over.

    I know this isn't accurate (storage ≠ production, grid can be balanced out geographically, etc), but we are one order of magnitude in trouble already.

  • Who is trolling here? Who is posting uninformative comments? Mine were on topic, yours jumped on my neck with insults. It's your right to disagree with what I have to say, though none of what you posted here has any argumentative value.

  • Everything you might use relies on a protocol down the stack. XMPP happens to be the only one to date that is an internet standard (IETF), is extensible by design (past/present and future use-cases can be build into it, what makes it still relevant 25 years later), is federated (but not P2P, a good trade-off for mobile usage), has a diverse/multi-partite ecosystem of client and server implementers (sustainable and resilient), and is deployed successfully at scale (on billion of devices).

    unless it’s been revised, imparts no encryption

    Today's XMPP uses the same E2EE as Signal/WhatsApp/Matrix/… XMPP had end-to-end encryption 10 years before Signal was invented

  • Do you consider it normal that a mere dictionary citation triggers such a violent, unhinged and irrelevant response?

  • Large scale electricity storage is very much a solved problem actually.

    I don't want to sound pedantic, but how exactly do you believe pumped storage work? It's not that complicated: you have a dam, i.e. renewable hydro, and when you get excess electricity from elsewhere, some of the water downstream is pumped back upstream so the dam can do its thing once again. Essentially, developing hydro storage means developing hydroelectricity and dams, but if hydro's contribution to the grid hasn't increased much in a very long time, it's not because of conspiracies, but simply because most of the available capacity has been tapped already: https://en.wikipedia.org/wiki/Hydroelectric_power_in_the_United_States

    So, back to our initial problem: chemical storage (batteries) is expensive, environmentally dubious, problematic in many aspects and inefficient, chemical conversion (e.g. hydrolysis) is wasteful/inefficient, etc. So, no, we have no good answer to that.

  • https://en.m.wikipedia.org/wiki/Autocracy

    Autocracy is a system of government in which absolute power is held by the ruler, known as an autocrat. It includes most forms of monarchy and dictatorship, while it is contrasted with democracy and feudalism.

    That checks out.

  • What the other responders said (there are great clients out there, that fit mainstream and niche needs).

    Also, it is not a problem of "federated protocols" per se, but of community-led projects. On the downside it may lack consistence and direction, but on the upside you can step in and contribute feedback, tests, documentation, and why not, code :)

  • So, what would be the appeal compared to XMPP?

  • Of course I wouldn't complain if more and more clients popped up, but IMO what matters is that the ones we currently have remain well maintained over time, in the hands of people who know what they are doing, and that there is one such client per platform, which is effectively the case today.

    If you have ideas on how to improve current clients, I'm sure people would take your remarks and contributions kindly (for instance, there's a zoo of pretty clients that forked from Conversations on Android, Dino tries to be a minimalistic client for the simple needs and is getting an official Windows build soon, etc)

  • XMPP's E2EE is comparable to everything else out there (Signal, Matrix, WhatsApp, …) in that it uses Signal's double-ratchet algorithm (guaranteeing perfect forward secrecy and al.). All maintained clients support it: https://omemo.top/

  • Also mostly coding in Scala here (plus some python) and agreed with all that was said above.

    Learning Scala will probably make you a better developer (much more so than learning e.g. go/swift/rust...), you will first wrap your head around functional concepts that might not feel super compelling initially (why would I want to write a recursive function instead of a while loop+mutator?), but those, and the constant exposure to type level concepts and monadic/higher-kinded constructs will slowly make you write safer and self-documenting programs.

    Also, most of the intimidating language abstractions are not required to be mastered to be efficient with Scala, many of the bells and whistles serve library authors much much more than end users, so it's important to find resources that go just "deep enough", I think Martin Oderski's and Li Haoyi's books are perfect in that sense.

    Finally there was this video published recently which might give an idea of where future programming languages are heading (and why it might be a good idea to keep an eye on Scala for the years to come): https://m.youtube.com/watch?v=7mTNZeiIK7E

  • Anyone with basic knowledge about anything knows that diversification is generally a good thing, this applies to energy as well: you don't command the wind/sun and large scale electricity storage is to this day an unsolved problem. For all the big plans we have about a greener and carbon limited future, we need large amounts of dependable cheap and low-carbon energy, nuclear very much fits the bill (in complement to the other low-carbon energies).

  • Just give XMPP a shot... It's what Matrix has been promising to be without ever actually delivering, was there a decade prior and still will be after the next.

    Matrix's purpose was to be a VC unicorn for is founders, it's not tackling a new problem, it's not bringing a novel or interesting solution, and everything that it does differently on a technical level seems to go against its goals and those of its users. Time to drop them was someandsome ago, but it's never too late.

  • , and this is just the beginning.
    It's bad omen to criticize an opensource project, I know, but in my eyes Matrix is a big technical and organizational failure, for not having succeeded in stabilizing the protocol after a whole decade of unsuccessful explorations, and for having its leadership consistently fail to define clear goals and steer the project towards them (just get it done and working well before trying to make it "peer to peer" or "in the metaverse").

    If this is the electroshock that Matrix needs to reconsider its design and directions? good for them. If that kills them? Well too bad, but it's not like they are the only cool kid in town.

  • This isn't wishful thinking, this is in defense of a model where our digital needs would be distributed at a level lower than that of the tech majors, which was commonplace before everything on the internet was so consolidated.
    I'm not saying that everyone should self-host, I'm saying that federated services could be hosted at family&friends/regional/national levels, simultaneously, and deliver a resilient service at a negligible cost. Hardware, which is very much a problem for Signal & al right now, wouldn't be in a distributed model, and could be donated and repurposed easily. My example was perhaps a bit too extreme, but I think you get the gist of what I'm saying.

  • Sorry to hear. I've been using omemo (e2ee) without a single message lost since.. perhaps 5 years ? I also don't use movim (I don't trust its model and level of stability/maturity, especially with regards to doing e2ee in the browser). I would not recommend "XMPP via Movim" either.

    Edit: a word

  • I've tried both Matrix and XMPP but stuck with Matrix

    And so did I but ended up with XMPP instead of Matrix. Self hosting my messaging was important to me, and the cost of doing so is prohibitive with Matrix, the protocol and its implementations are just that inefficient, and there has been no progress in this area for as long as I've been keeping an eye on it. In my eyes, Matrix is broken by design.

    Now, Element is indeed a decent client, and above the average of all XMPP clients, but what matters is for XMPP to have at least one great client per platform, which is undoubtedly the case. In practice, all my daily messaging happens over XMPP, the people I interact with are far from the nerdy type, and to them it's pretty much equivalent to WhatsApp & al.

    Back to Matrix, besides the fact that after a decade there hasn't been any progress towards diversifying implementations (it's so messy, complex and changing that it's basically the same people implementing both client and server sides, and there is only one viable implementation to this day, by one entity), which is a big fat red herring, the entity who's behind 95% of the code of Matrix is now facing severe financing challenges. The future of Matrix is all but certain because of that, and there are reasons for concern.

    I don't "hate" Matrix/Element/the Foundation, I just don't understand why they painted themselves in the corner they are in today, and rode the pipe dream of their broken protocol for so long. Would they cease to exist, it would look like natural selection to me. They are just not competitive and sorry if it hurts.