If you tell me a piece of software that is not a password manager wants to send the first five characters of the hashes of my password to a third-party, without my explicit opt-in, I will say no without hesitation and without the need to hear more details. Not even if it's a random bit in the hash.
It's fascinating that you feel that way, but "I feel this is a threat" isn't really explaining why you feel it's a threat, especially when the purpose is to identify passwords whose full cleartext is exposed, which I'd rate as a far more substantial concern
I don't care about a popularity contest, man. If you don't want to talk about your own reasoning you can just say that. Wasting my time by explaining the concept of the wisdom of crowds is unnecessary.
People here act like HA includes a script that collects every password on your computer and sends them all over plaintext HTTP. I'm disappointed to be honest.
I would like to see the write-up from the red teamer and white hat hacker that claim they could break into thousands of systems with five characters of a SHA hash of a password. Should be a fun read.
Yeah. The use of the word "scan" in the original article and the title is misleading. It doesn't scan your system looking for passwords and testing them. It appears to take the password you give to HA (either as your HA Password to login to HA, or for an integration) and check those. That is a much smaller impact than is being assumed by many here.
For the most part, most games are antagonistic. And that's fine, that's the fun. Goombas are player-antagonism. Dark Souls is antagonistic. But they are engaging you and testing your ability to execute game mechanics with increasing amounts of precision.
Having to sit through a full hour of video to slowly trace a line is pointlessly antagonistic. It only tests a player's desire to sit through your bullshit. Being able to do it does not make you better at any other part of the game. It doesn't even make you better at that part of the game.
You don’t have to sit through it. It just asks the player to slow down and listen for just an hour. If something, it makes you better in general by just listening to a fantastic talk by Brian Moriarty, that’s the achievement.
You don't have to do it though. There is no reward, no achievement, nothing unlocks. It's functionally equivalent to "if you stand in one spot for an hour a special sound effect plays and some lights flash for 2 seconds." I think it's psychologically interesting how many people get angry that this sound effect is programmed into the game.
I consider the witness one of my favorite games, and I fully completed it, but I did not do that because it's dumb. The existence of the thing really has nothing to do with the game.
It's bad game design if it were the game, but it's not the game. You said "that's not a good puzzle. It's not good game design. It's antagonistic to the player in the worst possible way."
But it's not really a puzzle, or the game, or antagonizing you, because there's no purpose in doing it. Like I said, it's just something that exists in the game. It's not the game; it doesn't reflect upon the puzzle design or the game design because it's irrelevant to the actual puzzles and the actual game.
I'll repeat myself: if you stand in one spot for an hour a special sound effect plays and some lights flash for 2 seconds. If that happened in Call of Duty, it would be strange, but it also would have nothing to do with the game design quality of Call of Duty. It would not make sense to say Call of Duty has bad game design due to the presence of this thing.
I'm defending the witness because it's a good game, and this comment thread implies that doing that dumb thing is required to play or finish the game, when it is not. It is a misleading comment that gives an uninformed reader an incorrect impression of the product.
Cos that worked in the past right? Remember when Devs weren't checking error codes so languages added exceptions that were apparently meant to fix that gap. Except for the reality was a lot of empty try/catch blocks, or the errors just getting ignored anyway.
Same thing will happen to unsafe rust once it becomes ubiquitous and we will be back talking about how to fix the problem of stupid coders
Tools can enable diligence, and tools can discourage negligence. There's an all-or-nothing fallacy at work in the suggestion that tools must be perfect at both of these things to be useful in advancing the craft.
A great deal of Rust code need not ever involve the unsafe block, and in these cases there is no great temptation to stray off this path. This is pretty good, imo.
> A great deal of Rust code need not ever involve the unsafe block, and in these cases there is no great temptation to stray off this path
Rust was an attempt to have the compiler manage memory, but they couldn't crack it, so they had to just push all the failures to conquer c style UB under rusts unsafe keyword...
Good codebases already do what rust is doing with the borrow checker, it's not rocket science.
There's a serious argument for cherry picking rusts good parts and Retrofitting them into a more entrenched language.
>Good codebases already do what rust is doing with the borrow checker, it's not rocket science.
Rust allows you to achieve with syntax what these good codebases achieve through diligence. You're right that it isn't rocket science, but it's demonstrably challenging, given that plenty of people get it wrong.
People are certainly trying to bring more safety to existing languages (in various ways), and that's only a good thing.
> Rust allows you to achieve with syntax what these good codebases achieve through diligence
Rustaeceans often play this card... What you should really say is safe rust achieves it through syntax, yet as a systems language you will need to invoke unsafe rust, which by definition is not "memory safe". And memory unsafe is bad right? So bad it's worth changing the language to avoid it.... Yet rust doesnt avoid it?
"which runtime" is a separate discussion from "which package manager"; there's nothing in Node requiring you to use npm (or to rely on external dependencies at all)
A lot of replies here seem to be asserting that this "isn't that hard" without addressing the thing that makes it most hard: submodule compatibility and the breadth of tooling
They're the best way we have to reference other repositories from one repository. All other solutions don't have the benefit of being built in to git and having support built in to all git forges.
Ecosystems like Yocto are built around having meta layers as submodules. And, despite the usability flaws of submodules, it works really well.
I also use submodules to include dependencies into C++ projects a lot. It works fine.
git subtree and git subrepo are compatible with all git forges and don't require normal developers to install the extensions. Only the person/bot doing the occasional sync to the external repo has to install the extension. I prefer git subrepo for most (but not all) use cases.
Note that subtree and subrepo have the same SHA-1/SHA-256 incompatibility issue that submodules do, so this will be just as much of a trainwreck for them as well.
What's the advantage to using git subtree or git subrepo instead of git submodules? I've never heard of this, what's the difference between them? If it's an extension, how do people without the extensions end up downloading the code from the other repos?
How does it work with MRs, can I submit an MR which consists of changing the referenced SHA (and have it not show up as changes to every file in the referenced repo)?
They work by copying one repo inside another and providing tools to copy/sync it back out again. It's not a link, it's a copy. It's almost the same as copying the files into your repo and git add'ing them, but there are accounting and tools to pull changes from the subrepo back to the external repo.
The trade-offs are relatively obvious. It'd be a poor option for Yocto, but is a better option for most corporate repos.
Oh, I didn't want to vendor another repo into mine, I just want to store a reference to it. I'll keep using submodules then, as they're easier to work with than tools like gclient and repo.
I really don't get the hate. They're not hard to work with. Just a bit shitty UX but if you're using Git you're used to that already.
I won't defend submodules, but I also don't accept this as a response because it's irrelevant. They are used and it will be an unbearable pain when they break.
Someone started this FUD a long time ago and it has worked. Instead of using an elegant mechanism, project have built inelegant wrappers on top of git like go.mod which are actual mistakes.
It is the same people who say Git is unseasonably hard to learn. It isn't. Git and its command line is ugly and hard to remember. Understanding what those commands do at a commit and a branch level isn't really difficult. Even the internal object model is only moderately difficult.
I say this as a person who strongly dislikes many many aspects of Unix and Linux due to bad design and terrible UX. Git has a better design than any Unix program you get.
Submodules work okay. It is just Git LFS but for Git repos. Get over it.
reply