Enzyme by Ciro Santilli 40 Updated 2025-07-16
For an initial concrete example, consider e. Coli K-12 MG1655 gene thrA.
Video 1.
How Enzymes Work by RCSBProteinDataBank (2017)
Source. Shows in detail how aconitase catalyses the citrate to isocitrate reaction in the citric acid cycle.
Googling most domains gives only very few results, and most of them are just useless lists of expired domains. Skipping those for now.
Googling "dedrickonline.com" has a git at www.webwiki.de/dedrickonline.com# Furthermore, it also contains the IP address "65.61.127.174" under the "Technik" tab!
Unfortunately that website appears to be split by language? E.g. the English version does not contain it: www.webwiki.com/dedrickonline.com, which would make searching a bit harder, but still doable.
But if we can Google search those IPs there, we might just hit gold.
IP search did work! www.webwiki.de/65.61.127.174
But doesn't often/ever work unfortunately for others.
Searching on github.com: github.com/DrWhax/cia-website-comms by Jurre van Bergen from September 2022 contains some of the links to some of the ones reported by Reuters including some of their JARs, presumably for reversing purposees. Pinged him at: github.com/DrWhax/cia-website-comms/issues/1
async (JavaScript) by Ciro Santilli 40 Updated 2025-07-16
async is all present in JavaScript for two reasons:
Evil by Ciro Santilli 40 Updated 2025-07-16
Things that are not nice such as:
Phanerozoic by Ciro Santilli 40 Updated 2025-07-16
The term "visible life" refers to multicellular from before people knew there was life in the proterozoic.
God, it's impossible! You just have to convert the entire fucking call stack all the way up to async functions. It could mean refactoring hundreds of functions.
To be fair, there is a logic to this, if you put yourself within the crappiness of the JavaScript threading model. And Python is not that much better with its Global Interpreter Lock.
The problem is that async was introduced relatively late, previously we just had to use infinitely deep callback trees, which was worse:
myAsync().then(ret => myAsync2(ret).then(ret2 => myAsync3(re3)))
compared to the new infinitely more readable:
ret = await myAsync()
ret2 = await myAsync2(ret)
ret3 = await myAsync3(ret3)
But now we are in an endless period of transition between both worlds.
It is also worth mentioning that callbacks are still inescapable if you really want to fan out into a non-linear dependency graph, usually with Promise.all:
await Promise.all([
  myAsync(1).then(ret => myAsync2(ret)),
  myAsync(2).then(ret => myAsync2(ret)),
])
And then, after many many hours of this work, you might notice that the new code is way, way way slower than before, because making small functions async has a large performance impact: madelinemiller.dev/blog/javascript-promise-overhead/. Real world case with a 4x slowdown: github.com/ourbigbook/ourbigbook/tree/async-slow.
Anyways, since you Googled here, you might as well learn the standard pattern to convert callbacks functions into async functions using a promise: stackoverflow.com/questions/4708787/get-password-from-input-using-node-js/71868483#71868483
Figure 1.
async function Teletubbies meme
. Source. TODO find original source.
Node.js by Ciro Santilli 40 Updated 2025-07-16
WellSync, if you are gonna useSync this wonky language thing inSync one place, you might as well useSync it everywhereSync and make it more decent. See also: how to convert async to sync in JavaScript.
In this section we will use the file nodejs/bench_mem.js, tests are run on Node.js v16.14.2 from NVM, Ubuntu 21.10, on Lenovo ThinkPad P51 (2017) which has 32 GB RAM.
A C hello world with an infinite loop at the end has:
  • 2.7 MB
  • 770 KB
For a Node.js infinite loop nodejs/infinite_loop.js
topp infinite_loop.js
This gives approximately:
  • RSS: 20 MB
  • VSZ: 230 MB
Adding a single hello world to it as in nodejs/infinite_hello.js and running:
topp infinite_hello.js
leads to:
  • RSS: 26 MB
  • VSZ: 580 MB
We understand that Node.js preallocates VSZ wildly. No big deal, but it does mean that VSZ is a useless measure for Node.js.
Forcing garbage collection as in nodejs/infinite_hello.js brings it down to 20 MB however:
topp node --expose-gc infinite_hello_gc.js
Finally let's see a baseline for process.memoryUsage nodejs/infinite_memoryusage.js:
node --expose-gc infinite_memoryusage.js
which gives initially:
{
  rss: 23851008,
  heapTotal: 6987776,
  heapUsed: 3674696,
  external: 285296,
  arrayBuffers: 10422
}
but after a few seconds randomly jumps to:
{
  rss: 26005504,
  heapTotal: 9084928,
  heapUsed: 3761240,
  external: 285296,
  arrayBuffers: 10422
}
so we understand that
  • heapUsed seems constant at 3.7 MB
  • heapTotal is a very noisy, as it starts at 7 MB, but randomly jumps to 9 MB at one point without apparent reason
Now let's run our main test program.
First a baseline case with an array of length 1:
node --expose-gc bench_mem.js n 1
This gives the same results as node --expose-gc infinite_memoryusage.js. The same result is obtained by doing:
a = undefined
with:
node --expose-gc bench_mem.js dealloc
Not let's vary the size of n a bit with:
node --expose-gc bench_mem.js n N
which gives:
NheapUsedheapTotalrssheapUsed per elemrss per elem
1 M14 MB48 MB56 MB1030
10 M122 MB157 MB176 MB1815
100 M906 MB940 MB960 MB99.3
"rss per elem" is calculated as: rss - 26 MB, where 26 MB is the baseline RSS seen on n 1.
Similarly "heapUsed per elem" deduces the 4 MB (approximation of the above 3.7 MB) seen on n 1.
Note that to reach MAX_SAFE_INTEGER we would need 8 bytes per elem worst case.
Everything below 100 million (8) is therefore very memory wasteful in terms of RSS.
If we use Int32Array typed array buffers instead of a simple Array:
node --expose-gc bench_mem.js array-buffer n N
we see that the memory is now, unsurprisingly, accounted for under arrayBuffers, e.g. for N 1 million:
{
  rss: 31776768,
  heapTotal: 6463488,
  heapUsed: 3674520,
  external: 4285296,
  arrayBuffers: 4010422
}
Results for different N:
|| N
|| `arrayBuffers`
|| `rss`
|| `rss` per elem

| 1 M
| 4 MB
| 31 MB
| 5

| 10 M
| 40 MB
| 67 MB
| 4.6

| 100 M
| 40 MB
| 427 MB
| 4
We see therefore that typed arrays are much closer to what they advertise (4 bytes per element), even for smaller element counts, as expected.
Now let's try one million objects of type { a: 1, b: -1 }:
node --expose-gc bench_mem.js obj
gives:
{
  rss: 138969088,
  heapTotal: 105246720,
  heapUsed: 70103896,
  external: 285296,
  arrayBuffers: 10422
}
Disaster! Memory usage is up to 70 MB! Why?? We were expecting only about 24, 4 baseline + 2 * 10 for each million int?!
And now an equivalent version using class:
node --expose-gc bench_mem.js class
gives the same result.
Let's try Array:
node --expose-gc bench_mem.js arr
is even worse at 78 MB!! OMG why.
{
  rss: 164597760,
  heapTotal: 129363968,
  heapUsed: 78117008,
  external: 285296,
  arrayBuffers: 10422
}
Let's change the number of fields on the object? First as a sanity check:
node --expose-gc bench_mem.js obj 2
produces as expected the smae result as:
node --expose-gc bench_mem.js obj
so adding properties one by one doesn't change anything from creating the literal all at once. Good.
Now:
node --expose-gc bench_mem.js obj N
gives heapUsed:
  • 1: 70M
  • 2: 70M
  • 3: 70M
  • 4: 70M
  • 5: 110M
  • 6: 110M
  • 7: 110M
  • 8: 134M
  • 9: 134M
  • 10: 134M
  • 11: 158M
Summary: this is just a red herring. Wakatime owner likely registered the domains just after this article was published as a publicity stunt. Fair play though.
As raised at: news.ycombinator.com/item?id=36280666, many, but not all, of the domains currently redirect to wakatime.com/ as of 2023, and apparently they were taken up in 2013 (TODO how to confirm that). TODO what is the explanation for that? Some examples that do:But some failed resolution examples:Even more suspiciously, according to his LinkedIn: www.linkedin.com/in/alanhamlett/, the owner of Wakatime, Alan Hamlett, worked at WhiteHat Security, Inc from Aug 2011 - Sep 2013. The company was then acquired by Synopsys in 2022. Holy crap!!! As shown at: web.archive.org/web/20131013193406/https://www.whitehatsec.com/ that company made website security tools. Did that dude use the tools to find the vulnerabilty and then just gobble up all the domains??? What a fucking legend if he did!!!
Running e.g.
curl -vvv dedrickonline.com
gives:
*   Trying 162.255.119.197:80...
* Connected to dedrickonline.com (162.255.119.197) port 80 (#0)
> GET / HTTP/1.1
> Host: dedrickonline.com
> User-Agent: curl/7.88.1
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Date: Mon, 12 Jun 2023 20:30:19 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 55
< Connection: keep-alive
< Location: https://wakatime.com
< X-Served-By: Namecheap URL Forward
< Server: namecheap-nginx
<
<a href='https://wakatime.com'>Moved Permanently</a>.

* Connection #0 to host dedrickonline.com left intact
so we see that he must have setup redirection with Namecheap as mentioned at: www.namecheap.com/support/knowledgebase/article.aspx/385/2237/how-to-redirect-a-url-for-a-domain/
Let's also try DNS history
  • whoisrequest.com/history/:
    • dedrickonline.com: registered: 1 Nov, 2010, dropped: 24 Nov, 2013
    • activegaminginfo.com : registered: 1 Feb, 2010, dropped: 1 Apr, 2012
  • tools.whoisxmlapi.com/whois-history-search
    • dedrickonline.com:
      • CIA (registrar: Godaddy, registrant name: domainsbyproxy.com)
        • Created Date: October 27, 2010 00:00:00 UTC
        • Updated Date: October 28, 2013 00:00:00 UTC
        • Expires Date: October 27, 2014 00:00:00 UTC
      • Alan (namecheap):
        • Created Date: June 11, 2023 09:59:25 UTC
        • Expires Date: June 11, 2024 09:59:25 UTC
    • activegaminginfo.com:
      • CIA (Network Solutions, registrant name: LLC. Corral, Elizabeth|ATTN ACTIVEGAMINGINFO.COM|care of Network Solutions)
        • Created Date: January 26, 2010 00:00:00 UTC
        • Updated Date: November 27, 2010 00:00:00 UTC
        • Expires Date: January 26, 2012 00:00:00 UTC
      • Alan:
        • Created Date: June 11, 2023 09:59:40 UTC
        • Expires Date: June 11, 2024 09:59:40 UTC
    • iraniangoalkicks.com:
      • CIA (registrar: Godaddy, registrant name: domainsbyproxy.com)
        • Created Date: April 9, 2007 00:00:00 UTC
        • Updated Date: March 2, 2011 00:00:00 UTC
        • Expires Date: April 9, 2011 00:00:00 UTC
      • Alan:
        • Created Date: June 11, 2023 09:59:20 UTC
        • Expires Date: June 11, 2024 09:59:20 UTC
    • iraniangoals.com:
      • CIA (registrar: Godaddy, registrant name: domainsbyproxy.com):
        • Created Date: March 6, 2008 00:00:00 UTC
        • Updated Date: March 7, 2011 00:00:00 UTC
        • Expires Date: March 6, 2014 00:00:00 UTC
      • Reuters:
        • Created Date: September 29, 2022 11:16:09 UTC
        • Updated Date: September 29, 2022 11:16:09 UTC
        • Expires Date: September 29, 2023 11:16:09 UTC
So these suggest Alan might have just come along in 2023 way after the 2022 Reuters article and did the same basic IP range search that Ciro is doing now, so possibly no new tech. Let's ask... twitter.com/cirosantilli/status/1668369786865164289
The domain name history presented is however of interest, and could lead to patterns being found.
Searching tools.whoisxmlapi.com/reverse-whois-search with term "Corral, Elizabeth" gave no results unfortunately.
Basic search under tools.whoisxmlapi.com/reverse-whois-search for "Corral" also empty. They can't see their own data? Ah, need advanced. Marked "Historic" and selected "Corral, Elizabeth", ony one hit, activegaminginfo.com.

Pinned article: Introduction to the OurBigBook Project

Welcome to the OurBigBook Project! Our goal is to create the perfect publishing platform for STEM subjects, and get university-level students to write the best free STEM tutorials ever.
Everyone is welcome to create an account and play with the site: ourbigbook.com/go/register. We belive that students themselves can write amazing tutorials, but teachers are welcome too. You can write about anything you want, it doesn't have to be STEM or even educational. Silly test content is very welcome and you won't be penalized in any way. Just keep it legal!
We have two killer features:
  1. topics: topics group articles by different users with the same title, e.g. here is the topic for the "Fundamental Theorem of Calculus" ourbigbook.com/go/topic/fundamental-theorem-of-calculus
    Articles of different users are sorted by upvote within each article page. This feature is a bit like:
    • a Wikipedia where each user can have their own version of each article
    • a Q&A website like Stack Overflow, where multiple people can give their views on a given topic, and the best ones are sorted by upvote. Except you don't need to wait for someone to ask first, and any topic goes, no matter how narrow or broad
    This feature makes it possible for readers to find better explanations of any topic created by other writers. And it allows writers to create an explanation in a place that readers might actually find it.
    Figure 1.
    Screenshot of the "Derivative" topic page
    . View it live at: ourbigbook.com/go/topic/derivative
  2. local editing: you can store all your personal knowledge base content locally in a plaintext markup format that can be edited locally and published either:
    This way you can be sure that even if OurBigBook.com were to go down one day (which we have no plans to do as it is quite cheap to host!), your content will still be perfectly readable as a static site.
    Figure 2.
    You can publish local OurBigBook lightweight markup files to either https://OurBigBook.com or as a static website
    .
    Figure 3.
    Visual Studio Code extension installation
    .
    Figure 4.
    Visual Studio Code extension tree navigation
    .
    Figure 5.
    Web editor
    . You can also edit articles on the Web editor without installing anything locally.
    Video 3.
    Edit locally and publish demo
    . Source. This shows editing OurBigBook Markup and publishing it using the Visual Studio Code extension.
    Video 4.
    OurBigBook Visual Studio Code extension editing and navigation demo
    . Source.
  3. https://raw.githubusercontent.com/ourbigbook/ourbigbook-media/master/feature/x/hilbert-space-arrow.png
  4. Infinitely deep tables of contents:
    Figure 6.
    Dynamic article tree with infinitely deep table of contents
    .
    Descendant pages can also show up as toplevel e.g.: ourbigbook.com/cirosantilli/chordate-subclade
All our software is open source and hosted at: github.com/ourbigbook/ourbigbook
Further documentation can be found at: docs.ourbigbook.com
Feel free to reach our to us for any help or suggestions: docs.ourbigbook.com/#contact