HN user

etaoins

119 karma
Posts0
Comments30
View on HN
No posts found.

Genomes are sequenced when they're both accessible and are of scientific/economic interest. This results in an overrepresentation of:

- Humans and their pathogens

- Economically important organisms (e.g. crops and farm animals) and their pathogens

- Model organisms

For example, compare the number of Genebank sequences for HIV-1 [1] versus Feline immunodeficiency virus [2]. HIV-1 is additionally problematic because it has an extremely high mutation rate [3], making it more likely for a random sequence to match some sequenced HIV-1 genome.

[1] https://www.ncbi.nlm.nih.gov/Taxonomy/Browser/wwwtax.cgi?mod...

[2] https://www.ncbi.nlm.nih.gov/Taxonomy/Browser/wwwtax.cgi?mod...

[3] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4574155/

Using the number of BLAST hits as the basis of an argument is about as reliable as using the number of results when searching for a string on GitHub. Without further analysis of the specific sequence and its biological context it can be highly misleading. See a previous Twitter thread on some other purported HIV inserts: https://twitter.com/trvrb/status/1223666856923291648

There also seems to be some circular reasoning the argument. Apparently we can ignore RaTG13 because it’s obviously synthetic, which makes SARS-CoV-2 look even more synthetic. It would be interesting to compare to the BANAL family of SARS-CoV-2-related viruses that are even more closely related to SARS-CoV-2 than RaTG13 [1].

I’m not sure why only viral genomes were searched for the furin cleavage site sequence. Viruses famously exchange genetic material with their host organisms. The “smoking gun” sequence also appears Mycobacterium smegmatis, for example [2].

[1] https://www.nature.com/articles/d41586-021-02596-2 [2]: https://twitter.com/soychicka/status/1243547603746410500

Nuclear weapons do not have situational awareness. They’re intended to be used as part of a larger deployment system with a human in the loop. There’s no threat model for them that includes self-arming when mysterious aircraft approach their storage location.

Existing Intel software (with potentially broken version checks) will work on ARM Macs under emulation. Once they rebuild with the new SDK they'll get the receive the correct version.

The T2 chip is a derivative of the A10. It has similar power requirements to the SOC in modern iPhones.

They could probably use a cut down derivative of the W2 chip used in AirPods with the audio codec etc. removed. I’m guessing phone batteries reach a point where they’re still storing energy but can’t provide enough current to safely boot the whole phone. The BLE chip could sip on the remainder of the battery for a long time.

The way I’ve approached it in my compiler [1] is that garbage collection can never occur while Lisp/RFI (Rust function interface) code is executing. Once the program returns to the event loop GC can occur with a small number of known roots. This works because there will be no way to block without waiting on a future which can then return to the event loop. I’m considering adding a `conditional-gc` macro for long running computations that’s internally implemented as waiting on a future that’s immediately resolved.

This means that RFI code can treat GCed values as having a `'static` lifetime. One caveat is that RFI code cannot capture values except for a few special runtime functions. This works naturally with the language’s pure functional design, however.

As far as data structures go its impossible to support performant Lisp code by implementing lists as native vectors; the guarantees and idioms are too different. My runtime [2] provides Rust bindings for data types that e.g. allow you to create an `Iterator` from a list or construct a list from one. That should allow transparent interoperability with idiomatic Rust patterns and data structures.

[1] https://arret-lang.org/

[2] https://rustdoc.arret-lang.org/arret_runtime/index.html

The flip side of time dilation is Lorentz contraction. As you approach the speed of light objects in your direction of motion will become shortened from your frame of reference.

For example, there are particles from cosmic rays that should not be able to make it to the surface without decaying. However, they're detected all the time. Two valid ways to think of this are:

1. From the Earth's frame of reference time moves more slowly for the particle. This slows down the process of decaying.

2. From the particle's frame of reference the Earth's atmosphere is considerably shorter so it doesn't need to travel as far.

Things get a bit hairy to talk about once you actually reach the speed of light. One way to think of it might be from the photon's frame of reference its entire path has become infinitely short so it had no distance to travel at all.

This is a concern but it usually works for two reasons:

1. Most firmware is sufficiently broken that Linux drivers are already hardened against devices being brought up in arbitrary states.

2. kexec walks the device tree to shut down all devices before starting the new kernel. This usually gets devices closer to a startup state, or at least a smaller number of known shutdown states.

There is Barycentric Coordinate Time which is the time from a hypothetical clock at rest at the centre of mass of the Solar System. This is easier to calculate across spacecraft than an Earth-centric time would be. However, because it's outside of Earth's gravity well it ticks slightly faster than Earth time.

You can’t set FS/GS from user space on x64-64 until the FSGSBASE instructions were introduced in Ivy Bridge. The kernel only needs to be involved as its privilege is needed to set the register; the kernel doesn’t “know” that they’re being used for TLS.

It's contributed to the open source ARM desktop/server community quite a bit. While ARM has had first class support in for embedded and mobile for a long time people weren't really running X11, Gnome, database servers, etc. As a result the experience was rough around the edges.

Now it's easy for any open source developer to pick up a working ARM machine for $35 for testing. qemu is an option but running on actual hardware is more rewarding. I've personally worked on open source code that would not have ARM support if something like the Raspberry Pi didn't exist.

ARM desktops and servers have become more common recently but I think Raspberry Pi's laid some of the groundwork for that.

It's being mentioned more during product launches than it used to be. For example, Apple heavily promoted the iPhone XS's 7nm SOC where previously it wouldn't have been mentioned.

I would guess this is due to other vendors starting to surpass Intel and wanting to highlight their process lead.

Another use case is dealing with tokens that assume globally synchronised clocks such as JWTs and Kerberos/Active Directory. Ideally all clocks would be perfectly synchronised but things happen.

For example, you might have one container that’s exchanging JWTs with a micro service that should be using AWS’s NTP servers and another that’s joined an Active Directory domain that should be using the AD NTP server. Right now you either need to run them on separate machines or expose yourself to interesting problems if clock skew happens.

Go 1.11 and Beyond 8 years ago

It’s a slightly simplified version of Cargo which itself is an evolution of what yarn/npm/sbt/etc are doing. This is explicitly called out in the vgo paper.

It only seems like a revolution because the previous situation in Go was such a mess. As someone that writes a lot of both Rust and Go I’m not nearly as impressed.