I think I can answer that, though I'm not a Pakistani but as a Nigerian in a developing country, you might also have a petrol generator for night times. But for the majority of people just having your phone and power bank charged for the night is pretty ok, a plus if you can keep a handful of bulbs on also.
Batteries are dirt cheap already and getting cheaper all the time. Pakistan would be buying them at the Chinese prices without a lot of tariffs or nonsense that might be misleading you into believing otherwise.
Think a bandwidth of 50-80$ per kwh cost levels for the manufacturer with a margin on top in a market where there's over production and prices are still trending down and margins are probably under quite a bit of pressure. That's the widely publicized cost levels for Chinese manufacturers that dominate the world supply currently. Some of the sodium ion batteries that are coming to market now are already at the lower end of that price bandwidth and could go to 10-20$/kwh over the next 5-10 years; maybe faster.
At those prices, anyone can afford plenty of battery to survive the sun not shining for days/weeks. Which in places like Pakistan would be redundant. It's far south and you can count the number of days that you shouldn't be wearing sunglasses outside per year on the fingers of one hand. Even when it's cloudy, there's plenty of light filtering through in that part of the world..
Prices you might be seeing in the US tell you more about the local politics there than the economics of batteries. The US has it self to blame for bad economics like that. Places like Pakistan aren't going to slow down because the US can't figure out all this new stuff. For them this is economic growth unlocked by vastly more energy than they've ever had access to. All they'll ever need basically.
Unless you are proposing the laws of physics are different in the US, this is just a matter of market friction and blockages from regulations and tariffs. You know, the sort of things nuclear bros dismiss with a wave of their hand?
Battery modules (not home scale, but utility scale) are around $50/kWh in China. If we assume a 20 year lifespan and 50% charge/discharge once a day, that adds (ignoring interest) $0.013/kWh to the energy cycled through the batteries (plus a small add from efficiency being not quite 100%).
This is quite cheap compared to (say) the fully loaded cost of energy from a nuclear power plant.
Smaller units will be more expensive per kWh, but not so enormously so as to render them impractical. And they will get cheaper quickly like all electronics do.
For $800 you can get a complete 2kWh system, including cells, inverter and panels shipped to your home in Europe, so if you're paying more than that for half the storage either your government or contractor is fleecing you.
I can confirm that prismatic 1kWh LFP cells cost ~$60 in single digit numbers.
You can order 2kWh of plug-in-ready battery for 400€ or so on Amazon. That's single digit cents per kWh over the lifetime of the battery. Bigger systems are cheaper.
They can be depending on your needs. Lithium iron phosphate batteries are pretty cheap for their capacity. If you build your own power station with them you'd be surprised how far your money goes.
In Australia, if you have the space for rooftop solar, it's far cheaper in the long run to buy solar+battery. We did the math for our household and even if grid prices are stable (which they aren't, they're fast increasing) we're still going to make money back on the investment in less than 4 years.
Granted this includes a government rebate for the battery, but overall the prices have plummeted. Any government that isn't pushing for renewables and energy storage at this point is actively working against it's citizens.
No, and once the Solar Sharer scheme kicks in it'll be very helpful in avoiding leaning too hard on the grid in the evening after rainy or overcast days.
It's a fantastic way to solve oversupply; give it to everyone, including those who have batteries in areas where the weather restricts solar output.
For my experience a lot of installations really doesn't have much battery capacity cause batteries are pretty expensive at least here in Nigeria, but a lot of people are really happy with the system as long as they get electricity even if it's only during the day.
The difference between off-peak and on-peak rates there is about $0.21/kWh in the summer and $0.29/kWh in the winter, so assume an average delta of $0.25/kWh.
Assuming no solar panels, if you charge the battery on the grid at off-peak rates and discharge it completely at on-peak rates, you break even after using about 3200kWh. Assuming 2 kWh used every day during peak rates that's a breakeven period of 4.38 years.
Maybe my calculations are wrong somewhere, and I'd love to learn if that's the case.
I also acknowledge some big assumptions: namely, that you will always need to use all your stored energy day at the peak time (reasonable in the summer when the AC is running) and that you can use all your battery power for those loads instead of grid power. On the other hand electricity rates tend to go up over time and batteries last for years.
That’s not true, at least in France. Perhaps it’s true in some other dialect, e.g. Quebec French; I don’t know.
From Wiktionary, the pronunciation of English bit is /bɪt/, and French bite is /bit/. The sounds represented in IPA by ɪ and i are not the same, which is precisely why “bit” and “beet” sound different to Americans.
It's pronounced the same only by people speaking English with a French accent. An American, Brit, Indian, or any other native speaker of English absolutely does not pronounce "bit" the same way a French person pronounces "une bite."
Rather than measuring whose French pedigree is longer, I will put down a wager on this. ₹3? :D
I don’t doubt that you speak French. French people tend to have difficulty distinguishing those sounds because they are not distinguished in French. In English, they are: English has a much larger inventory of distinct vowel sounds than French (or indeed most European languages). In typical French-accented English, “bit” is indeed pronounced like the French word “bite”, but in native speaker English, it is not.
I am a native speaker of American English and also speak French quite well. If you neither accept personal experience, nor what is written on Wiktionary, what evidence would you accept?
I'm moving from Python to Java because of how much easier it is to actually use all CPU cores in Java and strict typing prevents so many bugs and it is much faster. I don't think it is actually that much more complicated than Python in 2025.
Agreed. It's sort of crazy how little people understand about multicore software design given nearly everyone is using machines with >8 CPU cores these days (even a cheap android phone tends to have 8 cpu cores these days).
In python and node it is _so_ painful to use multiple cores, whereas in .net you have parallel for loops and Task.WhenAll for over a decade. Java is similar in this sense that you don't have to do anything to use multiple cores and can just run multiple tasks without having to worry about passing state etc between 'workers'.
This actually becomes a really big problem for web performance, something I'm deeply passionate about. Not everything is just IO driven holdups, sometimes you do need to use a fair bit of CPU to solve a problem, and when you can't do it in parallel easily it ends up causing a lot of UX issues.
I am doing backend in Kotlin, but I must admit that Java has been catching up quickly, and it seems like Kotlin has been shifting its focus to Kotlin Multiplatform. Modern Java is a good, pleasant language and a safer bet.
Gradle with Kotlin DSL is nice, what's annoying is Gradle's constant API reshuffling for the sake of it that breaks plugins. Some plugins also introduce pointless breaking changes just to have a fancier DSL.
The IDE support is not an issue in practice, in my opinion, because IDEA is the best IDE for both Java and Kotlin. The official Kotlin LSP was released 6 months ago, but I haven't tried it.
I'm dabbling and like it but there is just SO MUCH JAVA code. There are 1000 Java examples for every 1 Kotlin. Maybe LLMs make this less of an issue now though.
Has too much sugar, and without JetBrains IDE you're stuck with a plain text editor. Not sure if it's generalizable to normal Kotlin or not, but learning Gradle Kotlin DSL made me want to rip my hair out when trying to understand what happens under the hood.
Something vaguely along those lines, and not the same thing on Google vs AWS.
But this isn’t the desired behavior! If you upload the same logical bytes as a single part or as multiple parts, you should get the same thing, and BLAKE3 could do this.
I'm also finding Gemini 3 (via Gemini CLI) to be far superior to Claude in both quality and availability. I was hitting Claude limits every single day, at that point it's literally useless.
The NSA changed the S-boxes in DES and this made people suspicious they had planted a back door but then when differential cryptanalysis was discovered people realized that the NSA changes to S-boxes made them more secure against it.
That was 50 years ago. And since then we have an NSA employee co-authoring the paper which led to Heartbleed, the backdoor in Dual EC DRBG which has been successfully exploited by adversaries, and documentation from Snowden which confirms NSA compromise of standards setting committees.
> And since then we have an NSA employee co-authoring the paper which led to Heartbleed
I'm confused as to what "the paper which led to Heartbleed" means. A paper proposing/describing the heartbeat extension? A paper proposing its implementation in OpenSSL? A paper describing the bug/exploit? Something else?
And in addition to that, is there any connection between that author and the people who actually wrote the relevant (buggy) OpenSSL code? If the people who wrote the bug were entirely unrelated to the people authoring the paper then it's not clear to me why any blame should be placed on the paper authors.
The original paper which proposed the OpenSSL Heartbeat extension was written by two people, one worked for NSA and one was a student at the time who went on to work for BND, the "German NSA". The paper authors also wrote the extension.
I know this because when it happened, I wanted to know who was responsible for making me patch all my servers, so I dug through the OpenSSL patch stream to find the authors.
I'm asking what the paper has to do with the vulnerability. Can you answer that? Right now your claim basically comes down to "writing about CMake is evidence you backdoored CMake".
> Right now your claim basically comes down to "writing about CMake is evidence you backdoored CMake".
This statement makes it clear to me that you don't understand a thing I've said, and that you don't have the necessary background knowledge of Heartbleed, the XZ backdoor, or concepts such a plausible deniability to engage in useful conversation about any of them. Else you would not be so confused.
Please do some reading on all three. And if you want to have a conversation afterwards, feel free to make a comment which demonstrates a deeper understanding of the issues at hand.
Sorry, you're not going to be able to bluster your way through this. What part of the paper you're describing instructed implementers of the TLS Heartbeat extension to copy data into an uninitialized buffer and then transmit it on the wire?
> What part of the paper you're describing instructed implementers of the TLS Heartbeat extension to copy data into an uninitialized buffer and then transmit it on the wire?
That's a very easy question to answer: the implementation the authors provided alongside it.
If you expect authors of exploits to clearly explain them to you, you are not just ignorant of the details of backdoors like the one in XZ (CMake was never backdoored, a "typo" in a CMake file bootstrapped the exploit in XZ builds), but are naive to an implausible degree about the activities of exploit authors.
If you tell someone you're going to build an exploit and how, the obvious response will be "no, we won't allow you to." So no exploit author does that.
Think the above poster is full of bologna? It's less painful for everyone involved, and the readers, to just say that and get that out of the way rather than trying to surgically draw it out over half a dozen comments. I see you do this often enough that I think you must get some pleasure out of making people squirm. We know you're smart already!
I think their argument is verkakte but I literally don't know what they're talking about or who the NSA stooge they're referring to is, and it's not so much that I want to make them squirm so much as that I want to draw the full argument out.
I think your complaint isn't with me, but with people who hedge when confronted with direct questions. I think if you look at the thread, you'll see I wasn't exactly playing cards close to my chest.
I don't make a habit of googling things for people when they could do it just as quickly themselves. There is only one paper proposing the OpenSSL heartbeat feature. So I have not been unclear, nor can there be any confusion about which it is. Perhaps we'll learn someday what tptacek expects to find or not to find in it, but he'll have to spend 30 seconds with Google. As I did.
Informing one's self is a pretty low bar for having a productive conversation. When one party can't be arsed to take the initiative to do so, that usually signals the end of useful interaction.
A comment like "I googled and found this paper... it says X... that means Y to me." would feel much less like someone just looking for an argument, because it involves effort and stating a position.
If he has a point, he's free to make it. Everything he needs is at his fingertips, and there's nothing I could do to stop him, nor would I want to. I asked for a point first thing. All I've gotten in response is combative rhetoric which is neither interesting nor informative.
Means, motive, and opportunity. Seems to check all the boxes.
There's no conclusive evidence that it wasn't purposeful. And plenty of evidence of past plausibly deniable attempts. So you can believe whatever lets you sleep better at night.
The NSA also wanted a 48 bit implementation which was sufficiently weak to brute force with their power. The industry and IBM initially wanted 64 bit. IBM compromised and gave us 56 bit.
Yes, NSA made DES stronger. After first making it weaker. IBM had wanted a 128-bit key, then they decided to knock that down to 64-bit (probably for reasons related to cost, this being the 70s), and NSA brought that down to 56-bit because hey! we need parity bits (we didn't).
This is the fundamental paradox of hardware secured keys. Basic ones generate the private key inside and never let it be exported. This allows you to be very sure it won't ever leak but also doesn't let you back it up. Higher end Hardware Security Modules allow the private key to be exported but only when encrypted with the valid public key of a destination HSM.
reply