Largey Brage by Ciro Santilli 35 Updated +Created
The outcome of Larry Page and Sergey Brin performing a Dragon Ball fusion dance.
Both of them attended Montessori education at some point. Interesting! Mentioned in a talk by Sergey and highlighted at The Google Story.
As The Google Story puts it about Largey:
Scholarship was not just emphasized in their homes; it was treasured.Ciro Santilli likes that.
Dots in Gmail address by Ciro Santilli 35 Updated +Created
This allows you to create multiple non-anonymous accounts on any website that doesn't account for it, as this is not part of the email protocols in general.
tig (git UI) by Ciro Santilli 35 Updated +Created
This is good. But it misses some key operations, so much so that makes Ciro not want to learn/use it daily.
Selection rule by Ciro Santilli 35 Updated +Created
phys.libretexts.org/Courses/University_of_California_Davis/UCD%3A_Physics_9HE_-_Modern_Physics/06%3A_Emission_and_Absorption_of_Photons/6.2%3A_Selection_Rules_and_Transition_Times has some very good mentions:
So it appears that if a hydrogen atom emits a photon, it not only has to transition between two states whose energy difference matches the energy of the photon, but it is restricted in other ways as well, if its mode of radiation is to be dipole. For example, a hydrogen atom in its 3p state must drop to either the n=1 or n=2 energy level, to make the energy available to the photon. The n=2 energy level is 4-fold degenerate, and including the single n=1 state, the atom has five different states to which it can transition. But three of the states in the n=2 energy level have l=1 (the 2p states), so transitioning to these states does not involve a change in the angular momentum quantum number, and the dipole mode is not available.
So what's the big deal? Why doesn't the hydrogen atom just use a quadrupole or higher-order mode for this transition? It can, but the characteristic time for the dipole mode is so much shorter than that for the higher-order modes, that by the time the atom gets around to transitioning through a higher-order mode, it has usually already done so via dipole. All of this is statistical, of course, meaning that in a large collection of hydrogen atoms, many different modes of transitions will occur, but the vast majority of these will be dipole.
It turns out that examining details of these restrictions introduces a couple more. These come about from the conservation of angular momentum. It turns out that photons have an intrinsic angular momentum (spin) magnitude of , which means whenever a photon (emitted or absorbed) causes a transition in a hydrogen atom, the value of l must change (up or down) by exactly 1. This in turn restricts the changes that can occur to the magnetic quantum number: can change by no more than 1 (it can stay the same). We have dubbed these transition restrictions selection rules, which we summarize as:
Finance is a cancer of society by Ciro Santilli 35 Updated +Created
The financial industry does not serve society nowhere near its magnitude (London of course being the epitome of that). It serves only itself. It just grows without bound.
Video 1.
Why I chose quant trading to retire early by Lit Nomad
. Source. Ciro Santilli was not sure under which section classify this video. It is worthwhile despite the title
Cavendish experiment by Ciro Santilli 35 Updated +Created
Introduction by Ciro Santilli 35 Updated +Created
ELF is the dominating file format for Linux. It competes with Mach-O for OS X and PE for Windows.
ELF supersedes .coff, which supersedes a.out.
Global file structure by Ciro Santilli 35 Updated +Created
An ELF file contains the following parts:
  • ELF header. Points to the position of the section header table and the program header table.
  • Section header table (optional on executable). Each has e_shnum section headers, each pointing to the position of a section.
  • N sections, with N <= e_shnum (optional on executable)
  • Program header table (only on executable). Each has e_phnum program headers, each pointing to the position of a segment.
  • N segments, with N <= e_phnum (only on executable)
The order of those parts is not fixed: the only fixed thing is the ELF header that must be the first thing on the file: Generic docs say:
Although the figure shows the program header table immediately after the ELF header, and the section header table following the sections, actual files may differ. Moreover, sections and segments have no specified order. Only the ELF header has a fixed position in the file.
In pictures: sample object file with three sections:
            +-------------------+
            | ELF header        |---+
+---------> +-------------------+   | e_shoff
|           |                   |<--+
| Section   | Section header 0  |
|           |                   |---+ sh_offset
| Header    +-------------------+   |
|           | Section header 1  |---|--+ sh_offset
| Table     +-------------------+   |  |
|           | Section header 2  |---|--|--+
+---------> +-------------------+   |  |  |
            | Section 0         |<--+  |  |
            +-------------------+      |  | sh_offset
            | Section 1         |<-----+  |
            +-------------------+         |
            | Section 2         |<--------+
            +-------------------+
But nothing (except sanity) prevents the following topology:
            +-------------------+
            | ELF header        |---+ e_shoff
            +-------------------+   |
            | Section 1         |<--|--+
+---------> +-------------------+   |  |
|           |                   |<--+  | sh_offset
| Section   | Section header 0  |      |
|           |                   |------|---------+
| Header    +-------------------+      |         |
|           | Section header 1  |------+         |
| Table     +-------------------+                |
|           | Section header 2  |---+            | sh_offset
+---------> +-------------------+   | sh_offset  |
            | Section 2         |<--+            |
            +-------------------+                |
            | Section 0         |<---------------+
            +-------------------+
But some newbies may prefer PNGs :-)
Figure 1.
ELF Executable and Linkable Format diagram by Ange Albertini
. Source.
Program header table by Ciro Santilli 35 Updated +Created
Only appears in the executable.
Contains information of how the executable should be put into the process virtual memory.
The executable is generated from object files by the linker. The main jobs that the linker does are:
  • determine which sections of the object files will go into which segments of the executable.
    In Binutils, this comes down to parsing a linker script, and dealing with a bunch of defaults.
    You can get the linker script used with ld --verbose, and set a custom one with ld -T.
  • do relocation according to the .rela.text section. This depends on how the multiple sections are put into memory.
readelf -l hello_world.out gives:
Elf file type is EXEC (Executable file)
Entry point 0x4000b0
There are 2 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x00000000000000d7 0x00000000000000d7  R E    200000
  LOAD           0x00000000000000d8 0x00000000006000d8 0x00000000006000d8
                 0x000000000000000d 0x000000000000000d  RW     200000

 Section to Segment mapping:
  Segment Sections...
   00     .text
   01     .data
On the ELF header, e_phoff, e_phnum and e_phentsize told us that there are 2 program headers, which start at 0x40 and are 0x38 bytes long each, so they are:
00000040  01 00 00 00 05 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 40 00 00 00 00 00  00 00 40 00 00 00 00 00  |..@.......@.....|
00000060  d7 00 00 00 00 00 00 00  d7 00 00 00 00 00 00 00  |................|
00000070  00 00 20 00 00 00 00 00                           |.. .....        |
and:
00000070                           01 00 00 00 06 00 00 00  |        ........|
00000080  d8 00 00 00 00 00 00 00  d8 00 60 00 00 00 00 00  |..........`.....|
00000090  d8 00 60 00 00 00 00 00  0d 00 00 00 00 00 00 00  |..`.............|
000000a0  0d 00 00 00 00 00 00 00  00 00 20 00 00 00 00 00  |.......... .....|
Structure represented www.sco.com/developers/gabi/2003-12-17/ch5.pheader.html:
typedef struct {
    Elf64_Word  p_type;
    Elf64_Word  p_flags;
    Elf64_Off   p_offset;
    Elf64_Addr  p_vaddr;
    Elf64_Addr  p_paddr;
    Elf64_Xword p_filesz;
    Elf64_Xword p_memsz;
    Elf64_Xword p_align;
} Elf64_Phdr;
Breakdown of the first one:
  • 40 0: p_type = 01 00 00 00 = PT_LOAD: this is a regular segment that will get loaded in memory.
  • 40 4: p_flags = 05 00 00 00 = execute and read permissions. No write: we cannot modify the text segment. A classic way to do this in C is with string literals: stackoverflow.com/a/30662565/895245 This allows kernels to do certain optimizations, like sharing the segment amongst processes.
  • 40 8: p_offset = 8x 00 TODO: what is this? Standard says:
    This member gives the offset from the beginning of the file at which the first byte of the segment resides.
    But it looks like offsets from the beginning of segments, not file?
  • 50 0: p_vaddr = 00 00 40 00 00 00 00 00: initial virtual memory address to load this segment to
  • 50 8: p_paddr = 00 00 40 00 00 00 00 00: unspecified effect. Intended for systems in which physical addressing matters. TODO example?
  • 60 0: p_filesz = d7 00 00 00 00 00 00 00: size that the segment occupies in memory. If smaller than p_memsz, the OS fills it with zeroes to fit when loading the program. This is how BSS data is implemented to save space on executable files. i368 ABI says on PT_LOAD:
    The bytes from the file are mapped to the beginning of the memory segment. If the segment’s memory size (p_memsz) is larger than the file size (p_filesz), the ‘‘extra’’ bytes are defined to hold the value 0 and to follow the segment’s initialized area. The file size may not be larger than the memory size.
  • 60 8: p_memsz = d7 00 00 00 00 00 00 00: size that the segment occupies in memory
  • 70 0: p_align = 00 00 20 00 00 00 00 00: 0 or 1 mean no alignment required. TODO why is this required? Why not just use p_addr directly, and get that right? Docs also say:
    p_vaddr should equal p_offset, modulo p_align
The second segment (.data) is analogous. TODO: why use offset 0x0000d8 and address 0x00000000006000d8? Why not just use 0 and 0x00000000006000d8?
Then the:
 Section to Segment mapping:
section of the readelf tells us that:
  • 0 is the .text segment. Aha, so this is why it is executable, and not writable
  • 1 is the .data segment.
Positron by Ciro Santilli 35 Updated +Created
E. Coli genome starting point by Ciro Santilli 35 Updated +Created
The conventional starting point is not at the E. Coli K-12 MG1655 origin of replication.
biocyc.org/ECOLI/NEW-IMAGE?type=EXTRAGENIC-SITE&object=G0-10506 explains:
This site is the origin of replication of the E. coli chromosome. It contains the binding sites for DnaA, which is critical for initiation of replication. Replication proceeds bidirectionally. For historical reasons, the numbering of E. coli's circular chromosome does not start at the origin of replication, but at the origin of transfer during conjugation.
If it is a bit hard to understand what they mean by "origin of transfer" though, as that term is usually associated with the origin of transfer of bacterial conjugation.
Magnetoresistive disk head by Ciro Santilli 35 Updated +Created
Custom encoded images of unknown source by Ciro Santilli 35 Updated +Created
Figure 1.
bitcoin.jpg
. Source.
A bitcoin logo on block 123573 (2011-05-13).
This is the very first ASCII string to show up at github.com/cirosantilli/bitcoin-inscription-indexer after only the Genesis block message.
This version of the image was just ripped from Hidden surprises in the Bitcoin blockchain by Ken Shirriff (2014).
Reconstructing it should likely be a simple matter of copy pasting the ASCII yEnc encoding present in the two transactions from tx ceb1a7fb57ef8b75ac59b56dd859d5cb3ab5c31168aa55eb3819cd5ddbd3d806 into a text file and decoding the yEnc, but after searching for 20 minutes Ciro couldn't find a working yEnc decoder on Ubuntu 21.10. How can a format be so dead, even after considerable extensive use in the Usenet??? It makes you think about life.
As mentioned by Ken, the logo is split across two transactions: ceb1a7fb57ef8b75ac59b56dd859d5cb3ab5c31168aa55eb3819cd5ddbd3d806 and 9173744691ac25f3cd94f35d4fc0e0a2b9d1ab17b4fe562acc07660552f95518.
There appears to be nothing strictly linking the two transactions, besides that they are very close by and the only ASCII strings around back in those pre-infinite-spam days, as can be seen at: github.com/cirosantilli/bitcoin-inscription-indexer/blob/master/data/out/0123.txt#L11, so you could just see both of them by eye.
Also the first one starts with:
=ybegin line=128 size=8776 name=bitcoin.jpg
and the second one ends in:
=yend size=8776 crc32=a7ac8449
so this is likely clearly part of the yEnc format for someone who knows it, and the filename bitcoin.jpg gives the file format.
They are not even in the same block:both from 2011-05-13. Also note that they ended up being committed reverse order, since you don't have a strict order control over the final blockchain.
Figure 2.
v27sSra.jpg
.
An image of a dozen people siting at a dinner table, with each person identified by a Twitter handle that was edited in.
This image is present tx 4be3a833ee83b4ca7d157d60fbf7411f7528314ce90df8a844f855118bc6ca11 from block 357239 (2015-05-20), an input transaction.
It contains a base 64 encoded image:
v27sSra.jpg

/9j/4AAQSkZJRgABAQEASABIAAD/2wBDACgcHiMeGSgjISMtKygwPGRBPDc3PHtYXUlkkYCZlo+A
...
TAkBaMxbbhuYXGDMyXw/MIV84IqrE//Z
...
By manually copy pasting that into a file v27sSra.base64 we can obtain the image with:
base64 -d <v27sSra.base64 >v27sSra.jpg
The exact same content appears to be present on the next input transaction 56d23a230042c094bc54bb72fc4c10a3f26750030b9927994e741d3689f5c09e on the same block.
Google reverse image search leads to freedom-to-tinker.com/2015/05/21/the-story-behind-the-picture-of-nick-szabo-with-other-bitcoin-researchers-and-developers/ The story behind the picture of Nick Szabo with other Bitcoin researchers and developers by Arvind Narayanan (2015), in which Arvind (@random_walker) who attended the meeting clearly lists all names and handles, and talks about the background of gathering of Bitcoin devs that happened in March 2014. The article also contains a higher resolution version of the image uploaded to the blockchain.
It also links to a popular Reddit thread that contains the image from May 2015: www.reddit.com/r/Bitcoin/comments/36hfu4/pic_coredevs_having_dinner_with_nick_szabo/
Googling v27sSra.jpg leads to bitcointalk.org/index.php?topic=1061926.220;wap "New York Times identifies Nick Szabo as Satoshi Nakamoto" which links to i.imgur.com/v27sSra.jpg so this is a Satoshi Nakamoto-real-identity thing.
Marijuana plant by Ciro Santilli 35 Updated +Created
j(-> 1EGa1izEFDHzEobDDQny73re9BwXdzhZvH <-
j(                 ,
j(                dM
j(                MMr
j(               4MMML                  .
j(               MMMMM.                xf
j(              "M6MMM               .MM-
j( h..          +MM5MMM            .MMMM
j( .MM.         .MMMMML.          MMMMMh
j( )MMMh.        MM5MMM         MMMMMMM
j(  3MMMMx.     'MMM3MMf      xnMMMMMM"
j(  '*MMMMM      MMMMMM.     nMMMMMMP"
j(    *MMMMMx    "MMM5M\    .MMMMMMM=
j(     *MMMMMh   "MMMMM"   JMMMMMMP
j(       MMMMMM   GMMMM.  dMMMMMM
j(        MMMMMM  "MMMM  .MMMMM(        .n
j(         *MMMMx  MMM"  dMMMM"    .nnMMMM
j(Mn...     'MMMMr 'MM   MMM"   .nMMMMMMM*
j(4MMMMnn..   *MMM  MM  MMP"  .dMMMMMMM""
j( ^MMMMMMMMx.  *ML "M .M*  .MMMMMM**"
j(    *PMMMMMMhn. *x > M  .MMMM**""
j(       ""**MMMMhx/.h/ .=*"
j(                .3P"%....
j(              nP"     "*MMnx
The transaction before the ASCII art tx 9b08c00ced2bca4525d74e82db9af2aec8ef213eb1c1bf68a48b6be929968332 starts with what is likely a "Legalize" and must be a Tor Onion service:
j(-> 1EGa1izEFDHzEobDDQny73re9BwXdzhZvH <-
but that address as is + .onion is invalid, TODO find the correct one.
Other marijuana plants can be found contained entirely in single transactions:
tx d338da06d13a21a296506c0c8cd8c8533ba8fa076ff5c2c1fd02a457aac3ef77 via cryptograffiti.info contains a marihuana plant followed by a complaint:
[ mirrored by http://dmabraham.info/ | moarrr ]
[ CryptoGraffiti: Donate BTC: 1MVpQJA7FtcDrwKC6zATkZvZcxqma4JixS ]
[ Latest News: EU/Greece chaos due to huge debts! ]
[ Bless! ]

{ Supa - https://bitcoin-otc.com/viewratingdetail.php?nick=supa }
William Robert Girdlestone
1535 Dingwall RD Apt 35
Courtenay
British Columbia
Canada
V9N 3S8

( https://bitcointalk.org/index.php?topic=575743.0 )
[ One of the lowest rated #bitcoin-otc users, owing me at least 10 BTC ]
[ Most likely much more with compounding interesting, but its all ]
[ written off as a huge loss to me. Never again deal with him! ]
NADP+ by Ciro Santilli 35 Updated +Created
Citric acid cycle by Ciro Santilli 35 Updated +Created
Calcite by Ciro Santilli 35 Updated +Created
Assign the hard task to the lazy person by Ciro Santilli 35 Updated +Created
quoteinvestigator.com/2014/02/26/lazy-job/ (archive):
I will always choose a lazy person to do a difficult job because a lazy person will find an easy way to do it.
Hash table by Ciro Santilli 35 Updated +Created

Unlisted articles are being shown, click here to show only listed articles.