HN user

throwasehasdwi

546 karma
Posts0
Comments109
View on HN
No posts found.

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.

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).

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.

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 :)

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.

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.

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.

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...

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.

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.

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.

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)

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).

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

Did you read the rest? I appreciate a reply from the core team but you must understand your potential audience of Rust users is a highly gender/racial biased cohort. If Rust becomes popular it will become near impossible to deviate from the mean unless you engage in affirmative action by selectively removing community members in the majority.

Edit: I'm not against these kinds of initiatives at all, I just don't think it's realistic to apply such goals to a free-form group of programming language users.

Are you implying that Rust should be the first programming language of these minority groups? Given the complexity of low level programming that doesn't sound like a good idea. If that is not your plan then this is a pointless exercise. The cohort of existing programmers is highly biased in these same ways. The bigger Rust gets the more difficult it will be to maintain anything far from the average. If rust becomes as popular as say Java or C++ it will be statistically impossible to maintain anything but the average within the community.

Yeah homeless people are not the same people that could afford any type of home most of the time. They're overwhelmingly people with mental and/or drug issues that prevent them from holding a job. Much more likely is that SF has many factors that make it a nice place to be homeless so these people migrate to it.

Why Choose Vue.js 9 years ago

the components should be reusable, not the styles on them.

Besides global font settings CSS nowadays is mostly used for positioning and isn't reusable.

Why Choose Vue.js 9 years ago

Separating CSS always seemed stupid to me, I was so happy when it finally became "best practice" to have inline styles within isolated components. HTML is the markup and as far as I'm concerned the styling is part of that markup.

I don't understand how anyone ever thought CSS's style inheritance was a good idea. I don't mind HTML and even JS these days but CSS really needs to be sent straight back to hell where it came from.

You can look at it from two ways. It might save some network bandwidth when designers want multiple fonts, but is it worth adding even more complexity to browsers?

Does the average user really care about fonts? I would say definitely not. Most people don't even notice the font.

What a wonderful way to add massive complexity to font rendering while delivering spectacularly little value.

Don't get me wrong, it's cool, I just don't see the point. And I don't look forward to my battery life being used for pointless sugar.