![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://fry.gs/pictrs/image/c6832070-8625-4688-b9e5-5d519541e092.png)
TLS already has quantum-hardened algorithms in it.
TLS already has quantum-hardened algorithms in it.
It’s entirely possible to parse HTML in PCRE. You shouldn’t, but it is possible. The language stopped being strictly regular a long time ago and is entirely capable of doing it.
I don’t. It may look less like line noise, but it doesn’t unravel the underlying complexity of what it does. It’s just wordier without being helpful.
Edit: also, these alternative syntaxes tend to make some easy cases easy, but they have no idea what to do with more complicated cases. Try making nested capture groups with these, for instance. It gets messy fast.
Headline is terrible. The big red flags are that they don’t do end-to-end encryption by default, the servers are in Dubai, and use a proprietary algorithm.
Last part should be clarified further. They didn’t reinvent AES or anything. It’s more like a protocol that puts together existing algorithms. It means they can use transport layers without TLS or anything else that wraps your messages in crypto otherwise.
https://core.telegram.org/mtproto
I’d still say this is a red flag. How you wrap encryption around your messages has several pits you can fall into. It’s not as bad as reinventing AES, though.
Remember to unload and clean your breakfast gun. Put it away, and then get your lunch gun.
Théoden: “What do you expect of me? Run down to some cave and conjure up an undead army?”
Aragorn: brb
Lithium batteries are often -30 to 80C, but that’s just saying what’s possible to squeeze some kind of voltage out of them. Basic principle is that the colder it is, the harder it is for chemical reactions to happen, and thus this will affect all chemical batteries to some degree.
I am absolutely certain that experts have looked at it, and come to different conclusions.
I’ll even go as far as to accept that there is no scientific consensus.
And what reference do you have for that? A recent one, because as I said, the economics have totally changed in the last 30 years.
Nuclear power doesn’t really produce co2
Concrete does. Reactors need a lot of concrete. A lot.
Renewables are still not ready to deal with base load in a power grid long term
Which doesn’t matter. Base load exists because it’s cheap to make power plants that stay at the same level all the time. The economics of that don’t apply to renewables.
Nothing, nuclear power will buy us time
Utterly untrue. It’ll take 10 years to deploy a single new GW of nuclear. That’s not buying time.
You don’t have to pay to “prove” I’m right. You just have to accept that experts have looked at this, and nuclear does not need to be part of the conversation. Not beyond keeping whatever we have already, at least.
Oh, fuck a book, aahhhhhh
The newer sodium batteries are comparable to LFP batteries from a few years ago.
Nuclear power should be expanded, a lot, it is the only realistic way to replace fossil plats for base demand.
This 90’s talking point against Greenpeace is no longer valid. The economics have changed.
https://www.cambridge.org/core/books/no-miracles-needed/8D183E65462B8DC43397C19D7B6518E3
The other side of that is matching supply to demand is basically instant. You pull power from batteries and they give you more (provided they’re not at their safe limit). There’s always a lag in getting turbines to spin up and down, and so there’s a non-trivial mismatch time.
While you’re not wrong, sodium batteries coming on the market have 200 Wh/kg. This is comparable to where LFP batteries were a few years ago. That means the newer sodium batteries are about as good as what’s in lots of EVs right now.
They are dirt cheap, don’t have the fire safety issues as some lithium chemistries (not all lithium chemistries do that), and sodium is abundant.
As an example, Klipper (for running 3d printers) can update its configuration file directly when doing certain automatic calibration processes. The z-offset for between a BLtouch bed sensor and the head, for example. If you were to save it, you might end up with something like this:
[bltouch]
z_offset: 3.020
...
#*# <---------------------- SAVE_CONFIG ---------------------->
#*# DO NOT EDIT THIS BLOCK OR BELOW. The contents are auto-generated.
#*#
[bltouch]
z_offset: 2.950
Thus overriding the value that had been set before, but now you have two entries for the same thing. (IIRC, Klipper does comment out the original value, as well.)
What I’d want is an interface where you can modify in place without these silly save blocks. For example:
let conf = get_config()
conf.set( 'bltouch.z_offset', 2.950 )
conf.add_comment_after( 'bltouch.z_offset', 'Automatically generated' )
conf.save_config()
Since we’re declaratively telling the library what to modify, it can maintain the AST of the original with whitespace and comments. Only the new value changes when it’s written out again, with a comment for that specific line.
Binary config formats, like the Windows Registry, almost have to use an interface like this. It’s their one advantage over text file configs, but it doesn’t have to be. We’re just too lazy to bother.
Is a very good idea providing much needed fixes to the JSON spec, but isn’t really what I’m getting at. Handling automatic updates in place is a software issue, and could be done on the older spec.
I wish I could find a video–this scene is on the DVD version–but it’s definitely ecchi (lighthearted sexual humor). It’s pretty obvious in the dialog. Basically, one of the boys remarks how the older teenage girl has boobs and the younger girl doesn’t.
It’s a series where a dragon kidnaps a princess, and a plumber from New York must save her. To do so, he must gather mushrooms by hitting bricks while jumping with his fist, jump on turtles to make them hide in their shell, and dodge fire breathing plants.
In the most recent 2d incarnation, the fire breathing plants will sing at you.
The people who made this were on a lot of drugs.