You can even charge once a week or even less, depends on the usage.
You also don't have a gas station inside your apartment. Depending on which car you get, you could go charge it to charging station. I'm not saying this is instant process.
I'd love to hear more about this kind of attack being exploited in the wild. I understand it's theoretically possible, but...good luck! :)
You're guessing a cipher key by guessing typed characters with the only information being number of packets sent and the time they were sent at. Good luck. :)
I'm baffled about this "security feature". Besides from this only being relevant to timing keystrokes during the SSH session, not while typing the SSH password, I really don't understand how can someone eavesdrop on this? They'd have to have access to the client or server shell (root?) in order to be able to get the keystrokes typing speed. I've also never heard of keystroke typing speed hacking/guessing keystrokes. The odds are very low IMO to get that right.
I'd be much more scared of someone literally watching me type on my computer, where you can see/record the keys being pressed.
Anyone who can spy on the network between the client and server can see the timing. This includes basically anyone on the same LAN as you, anyone who sets up a WiFi access point with a SSID you auto-connect to, anyone at your ISP or VPN provider, the NSA and god knows who else.
And the timing is still sensitive. [1] does suggest that it can be used to significantly narrow the possible passwords you have, which could lead to a compromise. Not only that, but timing can be sensitive in other ways --- it can lead to de-anonymization by correlating with other events, it can lead to profiling of what kind of activity you are doing over ssh.
So this does solve a potentially sensitive issue, it's just nuanced and not a complete security break.
> For me personally, I have decided I will never be an Anthropic customer, because I refuse to do business with a company that takes its customers for granted.
Archaeologist.dev Made a Big Mistake
If guided by this morality column, Archaeologist should immediately stop using pretty-much anything they are using in their life. There's no company today that doesn't have their hands dirty. The life is a dance between choosing the least bad option, not radically cutting off any sight of "bad".
> How much better would this library be if an expert team hand crafted it over the course of several months?
It's an interesting assumption that an expert team would build a better library. I'd change this question to: would an expert team build this library better?
user = { name: "Alice", age: 30 }
puts user[:name] # Alice
puts user["name"] # nil
I'm 100% convinced that every Ruby developer has at least once made a bug where they tried to access a hash entry using a symbol, where the key was actually a string or vice-versa.
It would be great if Ruby would finally have immutable strings by default and, at that point, it would be possible to make symbols be strings.
This would prevent any such user[:name] vs user["name"] bugs while not breaking any other functionality. And also keeping the memory "optimized" by reusing a single immutable string.
> I'm 100% convinced that every Ruby developer has at least once made a bug where they tried to access a hash entry using a symbol, where the key was actually a string or vice-versa.
Yeah, that is true. It adds a cognitive load onto the ruby developer writing the code as well. Personally I prefer symbols as keys in a Hash, mostly because I like symbols, I assume it may be faster usually (this depends on factors, such as how many symbols one uses, the garbage collection kicking off and so forth, but by and large I think for most use cases, Symbols are simply more efficient). We also have abominations such as HashWithIndifferentAccess; Jeremy wrote an article why that is not good (indirectly, e. g. the article he wrote was about Symbols more, their use cases and differences to Strings, but from this it follows that HashWithIndifferentAccess is not a good idea. While I agree, I think some people simply don't want to have to care either way).
If I need to query a hash often, I tend to write a method, and the method then makes sure any input is either a string or a symbol for that given Hash.
> It would be great if Ruby would finally have immutable strings by default
But it has. I still use "# frozen_string_literal: true", but if you omit it, the Strings are frozen by default. People could set "# frozen_string_literal: true" in a .rb file if they want to retain the old behaviour.
> it would be possible to make symbols be strings.
But Symbols are not Strings. And bugs based on x[:foo] versus x['foo'] are always going to happen. They are very easy to avoid though. I don't really run into these in my own code, largely because I settled on symbols as keys for a Hash.
> And also keeping the memory "optimized" by reusing a single immutable string.
But a Symbol is not a String. Not even an immutable String. I understand what you mean (and internally it may be that way already, actually), but it is not a String.
I also prefer symbols as keys in hash. It just looks more aesthetically pleasing. :)
I think the optimization string vs symbol is negligent in most of the apps. If you need that level of optimization, you should probably switch to Rust.
> If I need to query a hash often, I tend to write a method, and the method then makes sure any input is either a string or a symbol for that given Hash.
This is terrible. This is the exact opposite of what Ruby is trying to achieve: developer happiness. You basically implement "symbol is a string" for hashes (aka HashWithIndifferentAccess).
> But it has. I still use "# frozen_string_literal: true", but if you omit it, the Strings are frozen by default.
This is not the case. If you omit "# frozen_string_literal: true", the strings are mutable, in all versions of Ruby, even in Ruby 4.0, which will be released on 25 Dec.
> But a Symbol is not a String. Not even an immutable String. I understand what you mean (and internally it may be that way already, actually), but it is not a String.
If it walks like a duck and quacks like a duck...
Who cares? What's the difference it makes for you whether symbols and string are interchangeable? Show me one valid use-case where having symbols and strings being different (user[:name] vs user["name"], or attr_reader "name") is useful.
Rails makes this more confusing with HashWithIndifferentAccess[1]. People coming from Rails are often confused by this when working with straight ruby and this kind of hash access doesn’t work.
Agreed. However had it should also be mentioned that this originated from rails.
Many bad things originate from the rails ecosystem. (Arguably some good too, but I am very pessimistic ever since shopify's recent powermove and DHH side-line commenting off-the-fence while being on shopify's board.)
No one thinks they are a dick. But you are. At least in many instances as many of the comments here and elsewhere point out. I had similar experience trying to start a discussion about something in one of the Homebrew repositories.
The fact that you have many friends who confirm your bias of not being a dick...means exactly nothing. You have people telling you your words made them perceive your comment as being arrogant/blunt and your reply is: I'm successful open-source maintainer and have many friends who think I'm not arrogant and I only take critique from them. Have it your way. But in my eyes, you're being a dick. (Don't misinterpret this as my judgement of your engineering skills. I love Homebrew and it's an incredible feat. Congrats.)
If you love Homebrew, maybe you might want to consider if repeatedly calling me a dick or arrogant/blunt is a particularly nice way to treat someone who spends their spare time building software you rely on.
This, this is being a dick. Holding your project hostage because you want to flex your power over someone. It's entitled behavior. Glad I moved to MacPorts years ago.
The variable naming convention used here could be improved for clarity. I prefer appending `El` to variables that hold DOM elements, as it makes identifiers like `tableEl` clearer and helps avoid ambiguity between variables such as `table` and `row`. Also, the variable named `table` does _not_ actually represent a table element; it would be more accurate to name it `data` or `tableData` to better reflect its purpose.
Probably because I first learned programming with JavaScript and very early started using jQuery, but I've always used prefixed `$` to indicate "This is a DOM element" (started doing this once jQuery stopped being so popular). So the example would be something like this for me:
let table = [
['one','two','three'],
['four','five','six']
];
let $body = document.body;
let $table = document.createElement('table');
$body.appendChild($table);
Always felt it worked out short and sweet, and as long as you're not refactoring a jQuery codebase, seems to work out well in practice.
You're right! Although I get faily far by using Bust-a-gem VS Code extension. (The underlying ripper-tags gem can work with any IDE)
https://github.com/gurgeous/bust-a-gem
I have an "on save" hook that runs ripper-tags on every file save. This keeps the definitions always up to date.
You also don't have a gas station inside your apartment. Depending on which car you get, you could go charge it to charging station. I'm not saying this is instant process.