stevelosh
Joined 17 years ago
Karma
4,417
Submissions
460
Member since
Aug 31
Move slow and make things.
View on Hacker NewsRecent submissions
Comment · 1 year ago
If you were around in the 80's and 90's you might have already memorized the prime 8675309 (https://en.wikipedia.org/wiki/867-5309/Jenny). It's also a twin prime, so you can add 2 to get another prime (8675311).
Comment · 2 years ago
That quote is from https://berthub.eu/articles/posts/immune-system/
Could have also seen it via https://jsomers.net/i-should-have-loved-biology/ which quotes it directly
Comment · 4 years ago
I've been using it during the beta and plan on paying for it once they start charging. Previously I had tried switching to DuckDuckGo, but found myself using !g half the time because I knew the DDG results would be garbage compared to the Google results.
I haven't found Kagi's results to be significantly better than Google's results, but unlike DDG they're not hugely worse than Google. It's all the extra stuff that makes me want to use Kagi instead of Google:
* Ability to banish sites from results forever. E.g. I never want to see the Concordia Lutheran High School's website when I search for things in the Common Lisp HyperSpec with clhs.
* Ability to weight sites higher. E.g. there are two mirrors of the Common Lisp HyperSpec that appear in results, one at http://clhs.lisp.se and one at http://www.lispworks.com/documentation/HyperSpec/. The lisp.se mirror is hilariously slow for me (5-10 seconds to load) while the lispworks one is instant. Google always ranks lisp.se first which tricks me into clicking it and wasting my time. Kagi lets me weight that site lower so the lispworks site comes first. Banishing lisp.se would also work, but just upweighting it means I can still find it if the other mirror ever goes down or something.
* I reported a minor bug to Kagi and they fixed it within a few days. I doubt that would happen with Google.
* Supports DDG-style bang queries, which I use occasionally.
* No goddamn ads/tracking (I use uBlock Origin, but it's the principle of the thing). I've almost entirely de-Googled my life at this point (Youtube is the only holdout for me).
So it's not that it gives better results than Google, it's that the results aren't any worse and the extra quality-of-life features are really nice.
Comment · 4 years ago
Alternate source, with fixed formatting: https://gist.github.com/mjdominus/3841427
Comment · 4 years ago
Common Lisp isn't that esoteric!
(defun fun-reader (stream arg)
(declare (ignore arg))
(read-delimited-list #\⸨ stream t))
(set-macro-character #\⸨ (get-macro-character #\) nil))
(set-macro-character #\( #'fun-reader)
(defun square (x⸨
(* x x⸨⸨
(square 10⸨
; => 100Comment · 4 years ago
NES tetris and modern tetris are VERY different games. NES tetris didn't have hard drop, hold, SRS, 7-bag randomizer, or multiple piece previews, all of which are in all modern guideline tetris games and can help you go faster. Tetr.io and Jstris go even further than guideline tetris: there's no line clear delay and you can set DAS/ARR[1] to anything you want, which lets you go even faster.
The bottleneck isn't the keyboard input. Pretty much all top players use ARR 0 and 2-step finesse[2] (or something close to it), which means you can position any piece where you want in 2 keystrokes at most, plus 1 more to hard drop it. And certain stacking styles (e.g. 6-3 stacking[3]) lend themselves well to not requiring the full 2 keystrokes pretty often, so in practice you end up with ~2.6 keys per piece instead of 3. A typical DAS for a pro player (e.g. someone like Firestorm) might be somewhere around 70ms. So if we roughly estimate 100ms average per piece (70ms to DAS, with some extra for the sometimes-needed rotation and hard drop), that would be ~10 pieces per second, which is well over the ~6.5 PPS in the record sprints.
The physical pressing of the keys also isn't really a bottleneck. Keys per second in the top sprints is ~16. I just mashed my movement/rotation keys into `time | wc -c` and got ~35 KPS after 2 beers, and I don't even have a particularly gaming-focused keyboard.
The bottleneck also isn't reaction times. Someone might trot out a hastily-googled 250ms as a typical human reaction time and claim 100ms per piece isn't possible, but good players aren't reacting to each piece as it comes -- they're using the previews (and hold) to react to the piece that's coming 4-5 steps in the future, which is closer to a second away.
It's really just about how fast you can process the upcoming queue and still stack cleanly.
[1]: https://harddrop.com/wiki/DAS [2]: https://four.lol/mid-game/finesse [3]: https://harddrop.com/forums/index.php?showtopic=2985
Comment · 4 years ago
WR for 40L is 14.9 by Reset[1] last I heard. 15 is definitely humanly possible.
[1]: https://twitter.com/jstrisgame/status/1424548438096683011
Comment · 4 years ago
If your goal is to force a touch to decrypt passwords, https://www.palkeo.com/en/blog/perfect-password-manager.html works. You can keep the GPG private key on a Yubikey and require a touch to decrypt.
Comment · 5 years ago
The user might copy a block of text with multiple URLs, all of which get pulled out by the grep.
Comment · 5 years ago
The golang one also silently drops rows.Err() on the floor.
Comment · 5 years ago
Paper: https://www.sciencedirect.com/science/article/pii/S0022202X1...
> For instance, in our work, we noted that the algorithm appeared more likely to interpret images with rulers as malignant. Why? In our dataset, images with rulers were more likely to be malignant; thus the algorithm inadvertently “learned” that rulers are malignant.
Comment · 5 years ago
Postmodern can do the right thing if you use prepared queries. See `defprepared`.
Comment · 5 years ago
You can set this up with `pass` and a Yubikey: https://www.palkeo.com/en/blog/perfect-password-manager.html