throwasehasdwi

9 anni fadiscuss

You don't get reliable wall clock time unless you're working in RTOS. In a threaded OS everything in userland is async to an extent. In this school of thought, having to specify that something should be async manually could be seen as a failure of the language.

throwasehasdwi

9 anni fadiscuss

await/promises/etc mostly exist to solve the problem that JavaScript doesn't have threads so it can't wait for callbacks.

About JavaScript, many other languages have had async/await for a long time. I have no idea why JS made such a huge deal of promises, I guess they're better than the callback hell before. Of course, in most languages using async isn't nearly as important for performance because they have thread pools.

Some interfaces aren't and won't be asynchronous (like Linux file IO) so eventually JS will support proper threads and we can stop talking about how great asynchronous programming is (it isn't).

throwasehasdwi

9 anni fadiscuss

It's insane that we're still using systems without ECC RAM. As memory shrinks bit errors get progressively more common. The more memory you have the better chance of corruption as well of course.

Literally everything else that holds "data" has been using some form of error correction forever. Hard drives, SSD's, USB flash drives, file systems, databases, even network packets. Even HDMI uses error correction, and how important is momentary pixel corruption on a screen???

It's totally insane that we're not using ECC with such large amounts of RAM built on tiny processes. Its definitely just a cartel artificially maintaining a situation that's bad for everyone not selling server chips.

throwasehasdwi

9 anni fadiscuss

Probably not but I was thinking either ML or VR could help

throwasehasdwi

9 anni fadiscuss

Eh, most developers I know are lazy and won't even measure the performance of the thing they're building if it's "good enough". I can't remember the last time any of us fired up a profiler. Optimization is generally hard and un-fun.

On the other hand, developers love to build shiny new stuff more than they like using things that are already there. The "Optimize" part you're talking about is more "reinvent the wheel" in my experience.

Figuring out how to use X new library isn't fun. Building this cool thing that does the same thing but better is a lot of fun! That's why things get overengineered and built for "scale", which is probably mostly what you'r referring to. Instead of taking something off the shelf that would work fine some developers are compelled to build something that can handle the entire traffic of the internet. They don't achieve this by optimizing what's there, they do it by building an enormously complex system for no reason :)

throwasehasdwi

9 anni fadiscuss

> undermining the success of the CEO search

Travis legally has control of the company just like an owner would. Nobody can "force" him to leave on run his company as certain way. Benchmark is just whining because they can't get their way.

Benchmark agreed to let him have permanent control when they invested, if they didn't want that they shouldn't have signed the contract.

throwasehasdwi

9 anni fadiscuss

They have nukes and working ICBM's... It's not that hard to put the two together.

Submarine launch is harder and the warheads must be smaller, but ICMB's are already considered unstoppable so it doesn't matter.

throwasehasdwi

9 anni fadiscuss

Well, North korea has been working on nukes for like 40 years and there hasn't been a war yet so I don't think the US is as eager as you think.

You don't see anything wrong with a madman in a country always on the edge of collapse that's constantly threatening to turn the USA into a crater having nuclear weapons?

Kimmy is over there threatening to bomb out the US and Japan and put everyone's heads on pikes pretty much weekly. I don't recall even our crazy fucker president Trump saying anything remotely close to that.

throwasehasdwi

9 anni fadiscuss

Whoever authorized the operation decided it was worth the many millions of damage it could do to Juniper.

throwasehasdwi

9 anni fadiscuss

add/remove is a better UX than the Windows Store even though it's barely been touched for 20 years :)

throwasehasdwi

9 anni fadiscuss

They are a current feature but not the baseline which means in practice implementations are buggy or non existent. I've had a few nicer routers where I could turn the options on but most clients are not able to connect :( .

I need to be in the baseline standard to get qualified or nobody will implement it.

throwasehasdwi

9 anni fadiscuss

I'm not a crypto expert and I'm sure even if I was it would be difficult to explain. Wiki page on SRP has a good description though:

Like all PAKE protocols, an eavesdropper or man in the middle cannot obtain enough information to be able to brute force guess a password without further interactions with the parties for each guess.

In layman's terms, given two parties who both know a password, SRP (or any other PAKE protocol) is a way for one party (the "client" or "user") to demonstrate to another party (the "server") that they know the password, without sending the password itself, nor any other information from which the password can be broken. Further, it is not possible to conduct an offline brute force search for the password.

https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

throwasehasdwi

9 anni fadiscuss

You can't brute force a nonce offline when you don't know if you answer is right unless you ask the AP. Different protocols than sending hashes where you can tell if your hash is correct just by looking at it.

You are right that the AP couldn't block you without blocking everyone, but since you need to check your answer with the AP for each guess your attack becomes extremely visible. I guess you could still DDOS the AP by sending auth requests faster than it allows but that doesn't hurt the channel any more than barrage jamming which is un-blockable.

throwasehasdwi

9 anni fadiscuss

It doesn't give you a hash to crack. It reduces your speed of guessing passwords from "how quick can you hash X", which is millions of times per second, to "how many times can I attempt to get in before the access point blocks me".

This major issue with WPA password cracking today is that it can be done "offline". You can pull the handshake out of the air and bang on it as long as you want. It's pretty much the same thing as trying to guess a password from some leaked hashes vs trying to guess a password using the gmail interface.

throwasehasdwi

9 anni fadiscuss

Yes, this is still a major problem with WPA. Also the fact that certain control packets aren't authenticated is nearly unforgivable. If correctly designed the only reasonable attack on wifi would be channel jamming, sadly after many years this still is not the case.

throwasehasdwi

9 anni fadiscuss

Wifi password cracking is only around 1000X slower than a SHA256 brute-force if I remember right. So your password needs to be secure enough that if a hash of it was leaked it would never be cracked.... So very strong.

WPA enterprise using certificates is usually much harder to crack since you need to interrogate server, you can't just brute force hash. This method only really applies to PSK mode (home networks and small businesses usually)

throwasehasdwi

9 anni fadiscuss

I'm not sure why this is amazing enough to make the first page but W/E it's HN :). Just so less informed are aware, this has been feasible for maybe 7 years (since GPU calculation became possible).

Just so nobody freaks out, this is cracking weak passwords, not broken WPA.

I have myself cracked countless WiFi passwords when security testing. It's easy if the passwords are bad, which is maybe 90% of the time for home networks and 60% for businesses. The attack is completely passive if you don't want to be noticed, and with a cheap dish you can pickup both ends of the handshakes from up to around a quarter mile away (line of sight).

throwasehasdwi

9 anni fadiscuss

this is sick

throwasehasdwi

9 anni fadiscuss

this is sick

throwasehasdwi

9 anni fadiscuss

This does NOT bode well for the future of humanity. It seems that war is only war when people on your side are dying. Once everything is sufficiently automated it will be possible to wage war without risking any of your humans. I don't want to know where that leads

comments