I didn't intend it that way, but I guess I can see it now. The point they made had not crossed my mind (as evidenced by my response of how I usually make projects, it wouldn't have) So to me the OP was complaining about something I saw as what would be a normal process for like a whole bunch of developers working on normal projects.
Frankly I think this is faux outrage now that a lot of people are getting wise to the fact a substantial amount of modern programming is basically simple pipefitting.
It was always true that the amount of people providing the foundations the rest of us do work on was super tiny and that was just kind of accepted as fact at least from my > 11 years in industry and overall 20+ years of programming now. It's only now that the pipefitting may be devalued are people getting in a tizzy.
What point are you making here? The author of the review doesn't seem to be affiliated with any keyboard. Are you suggesting the distributor of the MoErgo Glove80 provided the author with this image and/or a general narrative?
Regarding guns and chat bots. You've said as much and the origin of the discussion says as much. Where does anyone suggest they are referring to use of LLMs in military deployments other than you?
> The store obviously has an obligation to hand over either money or the goods, but it's not clear that obligation is transient to anyone that ends up with the goods.
It is extremely clear. You are just detailing the buffer being used to pretend otherwise.
In answering whether Nguyen's argument holds, Runciman decides Nguyen isn't talented enough to be worth judging, then judges him anyway. A book about scoring systems gets scored on the wrong axis. Runciman then uses this to great effect, blending this silly aesthetic complaint with a real structural one.
The structural point I even agree with. You can always take up a new game, but at the social level there is often no other game to play, and you can't opt out of a metric that has power over you. But Runciman doesn't trust the point to carry the piece, so the verdict on Nguyen's prose is enlisted to stand in for a verdict on Nguyen's case.
The irony: to fault the book for not being "compelling reading" is to let a convenient proxy displace the value it was meant to track. That is "value capture" as Nguyen puts it.
Being that can be understood is language. The previous commenter is making an particular argument for how we can improve this understanding. They didn't suggest we should use less familiar words, but different familiar words. Why is this strange?
I believe it was emergent from FPS gaming culture, particularly following the popularity of Apex Legends. In Apex Legends you have an energy shield which serves as a buffer of hit points. When playing cooperatively it is useful to communicate when this energy shield is "cracked", thus the line "they are cracked" emerged. This originally meant a target player's shield is down in Apex Legend specifically, but it was then the Fortnite (and broader FPS) community which took this phrase and warped it to mean someone is precise or an excellent shot. Today it is certainly used in the context the original poster intended.
edit: Looking again, this may be overstated. Apex-era gaming culture likely helped popularize the usage, but considering older idioms like "crack shot," the actual etymological root is more likely there.
A few small things. You might call this nitpicking. And, as I wrote, I found the technical details generally accurate.
> "Then there is also the fact that having a fully-fledged graphical desktop environment running in the background at all times is not quite optimal to say the least. 99 percent of the time when cracking passwords, you will be staring
at a black terminal filled with white text, so using Windows, which is especially GUI-heavy, is usually impractical unless you are specifically
testing something or showcasing some process."
I am reasonably sure that the Windows UI has rather little practical effect on hashcat's speed, and this thread implies the same: https://hashcat.net/forum/archive/index.php?thread-8958.html
Also, 99 percent of the time when cracking passwords, I am not staring at a black terminal filled with white text.
(I am generally taking it a little bit personally when the author directly addresses me and tells me what I am probably thinking or doing.)
> "Behind a hash function are a series of complicated mathematical operations that make deriving the input from the output literally impossible."
I'd argue that the mathematical operations themselves are usually not that complicated. More importantly, the whole book seems to be about ways to derive the (probable) input of a hash function from the output. It is not literally impossible.
> "It is important to note, however, that hash functions are not truly random;"
As the author writes elsewhere, hash functions are deterministic and not random at all. Calling them not truly random seems to imply that they are somewhat random.
> "When encrypting a file or any kind of data with AES for example, the program leveraging AES will prompt you for a password. Yes, a password."
Yes, this is a book about password cracking, but there are lots of cases where programs use AES with a computer-generated key and won't prompt you for a password. E.g., TLS.
(Just to reiterate: I am not trying to diminish the author's work, I wanted to suggest ways for improvement. I might be wrong or overly pedantic.)
> I'd argue that the mathematical operations themselves are usually not that complicated. More importantly, the whole book seems to be about ways to derive the (probable) input of a hash function from the output. It is not literally impossible.
I think you're not being pedantic enough here. "Probable" is doing some heavy lifting. And the phrasing is "derive the input," which I think is fair to say. The best you can do with a proper hash is discover one or more possible inputs, but you're not deriving them from the output; the output is just used to check the result. The many-to-one nature of a hash precludes determining the exact input.
Fair point. I was initially thinking about rainbow tables. Taking a hash and looking up associated passwords in a table feels like deriving to me - but I'm not a native speaker so I might have a wrong feeling here.
(It is obvious that one cannot directly derive the exact input - but one can derive potential inputs and then use other means to find the exact one.)
To me, "deriving from x" means performing a mathematical function operating on input x. By my own definition, I suppose a rainbow table lookup is a derivation, but I wouldn't consider actually computing the table to be one. Hash-cracking is more like guess-and-check than mathematical decoding; the hash to be cracked is just a verifier and not an input, which is why I make the (admittedly pedantic) distinction.
> (I am generally taking it a little bit personally when the author directly addresses me and tells me what I am probably thinking or doing.)
I think it's a canonical way to generalize the audience as in "99 percent of the time when cracking passwords, one will be staring at a black terminal filled with white text" just as in the German "man". So with that in mind maybe you no longer have a reason to be offended :)
I absolutely agree. There were no other comments on this post when I wrote my comment. Thus, I wanted to encourage the author and provide some constructive feedback in case nobody else would reply.
Thanks for the feedback. I did my best with grammar. Unfortunately, English is not my native language. I'll definitely keep grammar corrections in mind for future revisions!
