HN user

gdavisson

347 karma
Posts0
Comments82
View on HN
No posts found.

Classical brute force is embarrassingly parallel, but Grover's algorithm (the quantum version) isn't. To the extent you parallelize it, you lose the quantum advantage, which means that to speed it up by a factor of N, you need N^2 processors. The article discusses this in detail, and calculates that "This means we’ll need 140 trillion quantum circuits of 724 logical qubits each operating in parallel for 10 years to break AES-128 with Grover’s."

"Grue" has a surprising variety of meanings:

Obsolete/dialiectical English: to shudder with fear, or a shudder (related to "gruesome")

Computer games: in Zork, a monster that eats adventurers in the dark [0]

Linguistics: an English translation for words that cover the entire green-blue part of the spectrum (in languages that don't distinguish blue from green) [1]

Philosophy: a color name that is equivalent to green until a specific future time, at which point it becomes equivalent to blue (used to raise questions about how to validly extrapolate into the future) [2]

[0] https://zork.fandom.com/wiki/Grue

[1] https://en.wikipedia.org/wiki/Blue–green_distinction_in_lang...

[2] https://en.wikipedia.org/wiki/New_riddle_of_induction#Grue_a...

Except that sometimes chasing these unicorn entitles leads to... finding the unicorn entities.

That's basically what happened with the neutrino. Neutrinos were originally proposed in 1930 by Wolfgang Pauli to solve apparent violations of energy and momentum conservation in beta decay. He suggested that the missing energy and momentum were being carried off by some additional -- undetected and mostly undetectable -- particle. For a while, it looked like these proposed ghost particles might never be detectable, but Fred Reines finally managed it... in 1956, 26 years later.

So don't write off unicorn particles. Sometimes they're real, even if you have trouble detecting them.

You're refuting a strawman. The junk DNA claim is not, and as far as I can see never had been, that all non-coding DNA is junk. It's that most of our genome -- around 90% -- is junk[1][2]. But since the genome is over 98% non-coding, that implies that something like 8% is functional non-coding DNA, which is several times the amount of coding DNA. Finding small amounts of additional functional non-coding DNA does not significantly challenge this[3].

[1] https://sandwalk.blogspot.com/2022/08/junk-dna-vs-noncoding-...

[2] https://en.wikipedia.org/wiki/Junk_DNA#History

[3] https://judgestarling.tumblr.com/post/154553548091/long-nonc...

That's not correct; you cannot use a double-slit test to check for entanglement. Running a photon through a double-slit setup always just produces a single dot, not a any sort of pattern. To get a pattern, you need to run a bunch of photons through it and see if a fringe pattern appears [1].

(BTW, you never get a two-line pattern in a decent setup. This is an incredibly common mistake, but it's simply wrong. The interference (which produces fringes) only happens where the separate patterns from the two slits overlap, so if you want a lot of interference, you need them to overlap a lot. So in the no-interference case, you won't get two separate lines with a gap between, you'll get a single merged wash (with probably some fine structure due to diffraction within each of the slits, but that'll also be there when there is interference, on top of the two-slit interference fringes).)

You might think "ok, I'll do this with a bunch of photons, measure/not measure all of their twins, and see if the bunch of them show fringes." This is more-or-less what's done in the delayed-choice quantum eraser experiment, but it doesn't work out in a way that allows communication. What happens is that you always get the no-interference pattern. In order to see interference fringes, you need to split the individual photons' dots up based on the result of the measurement you made on their twins. Based on those measurements (if you made them), you can split the photons up into two groups, which'll have fringes with equal-and-opposite patterns (i.e. each will have bands where the other has gaps [2]).

If you didn't measure the twin photons (or made some other measurement on them instead), you can't split them up, so you won't see the fringes. But that's not because the measurements were different, it's just that you can't split them up afterward to see the fringes. And even if you did measure the twins, you can't split them up until you get a list of which twin got which result -- which can't be sent faster-than-light.

Net result: no, you can't send information via entanglement, you can only get correlation.

[1] https://www.researchgate.net/figure/Electron-Fringe-Pattern-...

[2] https://algassert.com/quantum/2016/01/07/Delayed-Choice-Quan...

Brackets are used in shell wildcard ("glob") expressions. For example, if you try to use "[bar]" as a command, the shell will first look for files named "b", "a", and "r" in the current directory, and if it finds any it'll use the first one as the command name and any others as arguments to it.

But as far as I can see, using a close-bracket as the first character in a command is safe, since it cannot be treated as part of such a pattern. Open-bracket (without a matching close-bracket) would work in many shells, but will get you a "bad pattern" error in zsh.

True, but since everyone in the study -- both those with and without diagnosed COVID-19 infections -- had been subject to this, it shouldn't affect the results. Essentially, they're comparing people who were just trapped indoors vs those who were trapped indoors and also had diagnosed COVID-19 infections (and they also broke the infected group down by severity of infection, what variant was prevalent when they were infected, etc).

echo -n is not safe, because some versions of echo will just print "-n" as part of their output (and add a newline at the end, as usual). In fact, XSI-compliant implementations are required to do this (and the same for anything else you try to pass as an option to echo). According to the POSIX standard[1], "If the first operand is -n, or if any of the operands contain a <backslash> character, the results are implementation-defined."

[1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/e...

I (vaguely) remember playing games with terminal echoback on physical terminals back in the early-mid 1980s when I was in college. This was on a VAX/VMS system.

Someone (I don't remember who did what here) discovered that they could get `SHOW SYSTEM` (roughly analogous to unix `ps` command) to display their name in reverse video by adding escape sequences to their process name. So a bunch of us started experimenting to see what else we could embed in there.

Most of the terminals attached to the VAX were Zenith Z-19s, which mostly emulated DEC VT-52s but with some added features. One of those added features was an enablable 25th line (in addition to the regular 24x80 display) that functioned as a sort of status line. We found we could enable that, write something into it, then use the "transmit 25th line" escape sequence to send its contents back to the VAX. I remember having to work around limitations like it sending an escape sequence before the 25th line (which confused VMS), and I think it didn't send a carriage return at the end... or something like that.

I don't think we ever got it to do anything terribly interesting, but it was fun to play with. And then IIRC a VMS update blocked control characters in the `SHOW SYSTEM` listing.

That's what I do. I have one account ("Apple ID") for iCloud, and a separate one for music and App Store purchases.

A couple of caveats, though: Apple encourages using the same account for everything, and their interfaces try to autopilot you into that setup. You have to pay attention, and find & choose the "I'll set it up myself" options. Also, Apple uses email addresses as the name/identifier for Apple IDs, so to set up multiple IDs, you need multiple email addresses. iCloud includes an optional email account, do it's easy to use that for the iCloud account yourself and your personal email address for the other.

Which reminds me: don't tie your personal stuff (iCloud, purchases, whatever) to an Apple ID under your company email address. If it's stuff you should keep after leaving your current job, it should be under an Apple ID that's tied to an email address you'll still have after leaving the job. On the other hand, for things that're part of the job (e.g. apps purchased by the company for the job), it should be under an Apple ID "owned by" the company and tied to a company-controlled email address.

I find that the `pbpaste | something | pbcopy` idiom is common enough that it's worth having a shell function for it:

  pbfilter() {
      if [ $# -gt 0 ]; then
          pbpaste | "$@" | pbcopy
      else
          pbpaste | pbcopy
      fi
  }       

Then you can use something like `pbfilter json_pp` or `pbfilter base64 -d` or `pbfilter sed 's/this/that/'` or whatever.

This version also can also act as a plain-text-only filter. If you just use `pbfilter` with no argument, it'll remove any formatting from the text in the pasteboard, leaving just straight plain text.

It does have a some limitations, though: you can't use it with an alias, or pipeline, or anything complex like that. The filter command must be a single regular command (or function) and its arguments.

It usually doesn't matter much, but there are some situations where it can matter a lot. For one thing, you can't use seek() on a pipe, so e.g. `cat bigfile | tail` has to read through the entire file to find the end, but `tail bigfile` will read the file backward from the end, completely skipping the irrelevant beginning and middle. With `pv bigfile | whatever`, pv (which is basically a pipeline progress indicator) can tell how big file is and tell you how for through you are as a percentage; with `cat bigfile | pv | whatever`, it has no idea (unless you add a flag to tell it). Also, `cat bigfile | head` will end up killing cat with a SIGPIPE signal after head exits; if you're using something like "Unofficial bash strict mode" [1], this will cause your script to exit prematurely.

Another sometimes-important difference is that if there are multiple input files, `somecommand file1 file2 file3` can tell what data is coming from which file; with `cat file1 file2 file3 | somecommand` they're all mashed together, and the program has no idea what's coming from where.

In general, though, I think it's mostly a matter of people's expertise level in using the shell. If you're a beginner, it makes sense to learn one very general way to do things (`cat |`), and use it everywhere. But as you gain expertise, you learn other ways of doing it, and will choose the best method for each specific situation. While `cat |` is usually an ok method to read from a file, it's almost never the best method, so expert shell users will almost never use it.

[1] http://redsymbol.net/articles/unofficial-bash-strict-mode/

I don't know about that particular analysis, but there've been a number of such claims that don't stand up (mostly because, as you ask, the districts themselves don't follow Benford's law). See, for example, "Inappropriate Applications of Benford’s Law Regularities to Some Data from the 2020 Presidential Election in the United States" by Walter R. Mebane, Jr. [0], and "Why do Biden's votes not follow Benford's Law?" by Matt Parker [1]. This fits the general pattern that there's been a lot of suspicion raised about fraud in the 2020 election, but none of it actually seems to pan out.

[0] http://www-personal.umich.edu/~wmebane/inapB.pdf

[1] https://www.youtube.com/watch?v=etx0k1nLn78

I recently watched a YouTube video from someone who'd tracked a nasty intermittent parasitic draw [0]. The problem only happened after turning the ignition on & back off (so the standard test of disconnecting the battery & reconnecting via the ammeter wouldn't show it), and the draw cycled between 3.6A and 0.3A.

Also, after turning the ignition on & back off there were a lot of (normal) transient draws (from things like the dome light that don't turn off immediately). Even with the problem circuit disconnected, it drew around 6A (!) immediately after the ignition was switched off, dropped to 0.4A after about a minute, and sat at that level for another 9 minutes before dropping again to 0.06A. That means if he hadn't waited ~10 minutes per test, he'd have been chasing draws that were actually normal.

Combine an intermittent fault with intermittent normal behavior, and you've got a troubleshooting nightmare.

[0] https://www.youtube.com/watch?v=rVScppKsfHs

"They filter AT LEAST 95% of the particles above a certain size."

That's a common misunderstanding; they filter at least 95% of particles of all sizes. It's actually intermediate-sized particles (around 0.1 - 1 micron) that're hardest to capture. Smaller particles are more subject to Brownian motion, which makes them jiggle around more, and hence makes them more likely to bump into one of the respirator's strands... where they'll stick, thanks to Van der Waals forces.

N95 masks (if properly fitted) block at least 95% of particles in that 0.1 - 1 micron range (they're tested with particles around 0.3 microns), and even higher percentages of particles that're either larger or smaller than that.

Reference: https://blogs.cdc.gov/niosh-science-blog/2009/10/14/n95/ (especially figure 2)

That study didn't compare suicide rates with and without surgery, it compared post-op trans people with the general population (i.e. mostly cisgender people). It explicitly says "This study design sheds new light on transsexual persons' health after sex reassignment. It does not, however, address whether sex reassignment is an effective treatment or not."

That's just plain wrong. Mental properties in general (e.g. personality) are not easily measurable, but that doesn't mean they don't exist (or can't exist without a non-material soul), and I see no reason to think that an innate sense of gender would be any different.

In any case, while gender is not directly measurable, it does seem to correlate with some aspects of brain structure. A number of studies have shown that, at least in some respects, the brain anatomy of transgender people is more similar to that of cisgender people of the same gender than those of the same sex. It's clearly more complicated than trans people having one type of brain in the other type of body, but something sort of like that is going on. See https://www.scientificamerican.com/article/is-there-somethin... and the links at https://sitn.hms.harvard.edu/flash/2016/gender-lines-science....

But whatever the basis of transgender identities is, it's clear that something real is going on. Dismissing trans people as "simply mistaken" is, well, simply mistaken.

EDIT: I should probably point out that the idea of someone developing some male-type features and some female-type should not be particularly surprising. Sexual differentiation is complex and has a lot of moving parts that don't always operate completely in sync. For example, a genetic male with complete androgen insensitivity syndrome will generally develop male-type internal organs (i.e. testes) and female-style external anatomy (a vagina, generally female appearance, etc).

First, why do you consider it to be a problem in the mind, rather than the body? It seems to me that, fundamentally, gender dysphoria is a mismatch between the mind and the body. Declaring the body to be correct and the mind wrong seems arbitrary (as would declaring the mind to be right and the body wrong). It's not really a question of right and wrong, it's the mismatch that's the problem.

Second, I don't know of any treatments for gender dysphoria (in trans people, not people with other conditions that've been misdiagnosed) that "fix" the mind and actually work. Gender reassignment, on the other hand, works, in the sense that it improves peoples' lives (see https://www.scimex.org/newsfeed/transgender-teens-receiving-... for example).

Note that not all transgender people experience gender dysphoria. Some are fine with the bodies they were born with, and for them gender reassignment would be unnecessary and irrelevant.

Also, note that this is different from treatment for e.g. anorexia nervosa. If someone with anorexia loses weight, it doesn't help; they'll continue to see themselves as overweight. Treatment for anorexia has to focus on the patient's mind. Helping them lose weight would make their outcome worse, not better, which is why it's not done.

Scott Alexander gives an interesting analogy to a case from the mental hospital where he works here: https://slatestarcodex.com/2014/11/21/the-categories-were-ma.... A woman with OCD was constantly worrying that she'd left her hair dryer on, and was having to drive home 10-20 times a day to check whether it was really off, or was on and going to burn the house down. Nothing they'd tried worked, until someone suggested she take the hair dryer with her. That effectively solved the problem for her, because she could always just look over at the dryer, see that it was unplugged, and go about her business. But caused a huge controversy among the psychiatrists between those who thought "This Is Not How One Treats Obsessive Compulsive Disorder" vs those who just said "it worked".

I'm with the "do what works" crowd.

They weren't in the medical literature. The 10k prediction was in STAT news (https://www.statnews.com/2020/03/17/a-fiasco-in-the-making-a...) (note: it wasn't a hard prediction, but he seems to treat it as the best estimate based on the data at the time). The 40K prediction was quoted in the Washington Post (https://www.washingtonpost.com/opinions/without-mass-testing...). There's a good summary with additional links, quotes, and commentary here: https://sciencebasedmedicine.org/10000-deaths/

I have an example of the opposite: When I was quite young, I got into model rocketry as a hobby. Buying engines required a pyrotechnician's license, and I was too young to get one, so I talked both of my parents into applying for licenses. My dad had been in the Manhattan Project at Los Alamos in WWII, so when he got to a question on the form that asked if he had any previous experience with explosives, he put something like "Yes, conventional and nuclear." His application took significantly longer than my mom's to process.

bash is the default interactive shell for users, but dash is the default shell for scripts with a #!/bin/sh shebang (or no shebang, unless they're run from bash), system() calls, etc. This means bashisms will work sometimes, which can be worse than not working at all.

I agree about the importance of differentiating bashisms from basic scripting, but I think the root cause of that is documentation (including this book) that don't make the distinction.

The Democrats' Senate Majority PAC is planning to return $1M contributed by SBF and $2M from Nishad Singh; the House Majority PAC got $6M from SBF and "will send funds in question wherever authorities instruct us". Source (and more details): https://www.cnbc.com/2022/12/20/ftx-democrats-senate-majorit...

My understanding is that SBF also made similar contributions to Republicans and conservative PACs etc, but generally hid them (e.g. by giving in other people's names), so those may be harder to track down & return.

That's not true. Death rates are now much lower, but that seems to be mostly due to people having (partial) immunity due to vaccination and/or previous infection, and better treatment. Omicron variants are less intrinsically severe than delta, but delta was more intrinsically severe than the earlier variants, so it's not clear omicron's actually any lower than the original strain, alpha, etc.

For example, according to "Challenges in Inferring Intrinsic Severity of the SARS-CoV-2 Omicron Variant" (https://www.nejm.org/doi/full/10.1056/NEJMp2119682?query=fea...): "This meaningful but fairly small difference [vs Delta] implies that omicron, alpha, and wild-type SARS-CoV-2 have similar intrinsic severity."

Interesting. If you use curl -v, you can see that the difference is that the newer version of curl canonicalizes(?) the Host: header to "1.0.0.1", which the server recognizes and responds to with a redirect. The older version sends "1.1" as the Host: header, which the server doesn't recognize, so you get a "403 Forbidden" response with the cryptic "error code: 1003" in the body.

I get the same behavior from other nonstandard ways of specifying 1.0.0.1, like "curl http://01.00.00.01/"

The recommendations look clear to me: you should use CRYSTALS-Dilithium (unless you need smaller signatures, in which case use FALCON), but you should also be prepared to switch to SPHINCS+ on short notice if someone breaks CRYSTALS-Dilithium (or structured lattices in general).

So best practice would seem to be to implement both CRYSTALS-Dilithium and SPHINCS+, set CRYSTALS-Dilithium as the default, and provide a switch (config setting, whatever) to switch to SPHINCS+. If you have long-term keys, you should have both forms set up & ready to use.