Things I’ve noticed. fly.io is better than railway now for simple, small low-cost deployments of sites. q32, for example, is just a static site, and deploying on fly was free and fast.

Fly has a strange approach to caching. Instead of having a purpose built cache, fly just runs instances of your program on the edge. “Edge running” instead of “Edge caching”.

This might work ok, but you wind up having to write your own “Edge aware” code to deal with it.

Railway is more traditional, but the “always on” nature of the apps means the costs go up faster.

Fly was more fun. But the “launch” feature basically always guessed wrong on a number of my sites (I tend to write mixed-language sites, using node+python+rust), and I had to write a custom Dockerfile to deal with it.

Railway, with nixpacks, was easier to configure (just tell it you’re using python/node and it will get that all into one image). But you’ll wind up optimizing and switching to docker eventually anyway.

Net Profit = Net Sale - Net Purchase

Tax Rate * (Net Profit) = Tax Amount

Now you give this to someone in a feed, but you round to the nearest penny, because… well, it’s meaningless to talk about 4/10 of a penny.

Net Profit = $1046.62
Tax Amount = $209.12

Except… you rounded down. And the accountant reconciling this feed will notice, after a sufficient number of differences, that the final value might be significantly different than he expected.

You can reduce this error, however, with “random rounding”. That is, if the number is 0.004, that gives you a 60% chance of rounding down to 0.00, and a 40% chance of rounding up to 0.01. The result of this is superior aggregation, and although it might not matter much, if you’re doing millions of small-value calculations, and they are actullay impacting customers, errors can add up (and not always in your favor).

• More information on stochastic rounding from the Royal Society.

• A simple library in python do to this is appended, with both random and deterministic versions.
  

Careful use of randomization comes into play when doing integer-only arithmetic. For example, the result of 1 + .01 is always 1, if all you have are integers available, as is often the case in optimized int8 ai-libraries, blockchain, and cryptographic arithmentic. The accumulated loss of repeatedly rounding this way can be infinite, and can lead to extreme hallucination, for example, in some memory-optimized image models.

But if you use stochastic rounding, the result of 1 + .01 is 1 : 90% of the time and is 2 : 10% of the time. Which means that over the long term, you get an average error of zero. Whew, no more crazy hands!

Python cround.py:

import random

def custom_round(value, n=2):
    factor = 10 ** n
    beyond_nth_decimal = (value * factor) % 1

    if random.random() < beyond_nth_decimal:
        return round(value - beyond_nth_decimal/factor + 1/factor, n)
    else:
        return round(value - beyond_nth_decimal/factor, n)

def deterministic_hash(value):
    # we just want something to rotate among rounded values
    int_repr = int.from_bytes(float(value).hex().encode(), 'big')
    hash_value = int_repr * 2654435761 % 2**32
    return (hash_value / 2**32)

def custom_round_fixed(value, n=2):
    factor = 10 ** n
    beyond_nth_decimal = (value * factor) % 1

    pseudo_random = deterministic_hash(value)

    if pseudo_random < beyond_nth_decimal:
        return round(value - beyond_nth_decimal / factor + 1 / factor, n)
    else:
        return round(value - beyond_nth_decimal / factor, n)

(Scene opens on a small stage with a single table and two chairs. Harry and Jenny sit across from each other, engaged in a heated debate.)

Harry: Jenny, I just don't understand how you can say that taxation isn't necessary. It's the backbone of any civilized society. It provides us with vital services like healthcare, education, and infrastructure. Without taxes, how would we maintain these essential components of our lives?

Jenny: Harry, I understand your concerns, but I believe that voluntary cooperation and contributions can achieve the same goals. When people see the value in something, they're more than willing to contribute their resources to it. Moreover, a society built on voluntary contributions is one where individuals have more freedom and autonomy.

Harry: That's all well and good, Jenny, but voluntary contributions are unreliable. You can't expect everyone to pitch in equally. Some people will take advantage of the system and benefit from the services without contributing.

Jenny: Harry, I think you're underestimating the power of people's goodwill and their desire to contribute to their communities. Additionally, when people are not burdened by taxation, they have more disposable income and resources to invest in the things that matter to them. This leads to a more efficient allocation of resources, where people directly invest in what they believe in, rather than having the government decide for them.

Harry: But Jenny, what about people who can't afford to contribute? If everything is based on voluntary cooperation, how will we ensure that everyone has access to essential services?

Jenny: That's a great point, Harry, but I believe that in a society where people have more control over their resources, they are more likely to be charitable. Wealthy individuals and businesses would have the opportunity to make significant contributions to causes they support, and there would likely be more incentive for innovation in providing essential services at a lower cost, making them accessible to all.

Harry: You might be right, Jenny, but what about the potential for corruption? If there's no central authority collecting and distributing funds, how can we be sure that the money is going to the right places?

Jenny: Corruption is a concern in any system, Harry, but in a voluntary cooperation-based society, people have more power to hold organizations accountable. Since they're choosing where their money goes, they can decide to stop supporting a corrupt organization and redirect their funds elsewhere. This creates a natural incentive for organizations to remain transparent and honest.

Harry: (pauses) I hadn't thought about it that way, Jenny. While I still have some reservations, I can see how voluntary cooperation might lead to more freedom, autonomy, and efficient allocation of resources. You've certainly given me something to think about.

Jenny: I'm glad I could provide a different perspective, Harry. I believe that considering alternative systems is crucial for the progress of society. Let's continue this conversation and explore the possibilities together.

function block_size() {( 
   [ "$1" ] && cd $1; echo 1 > block_size.tmp;  
   ls --block-size 1 -s block_size.tmp | cut -f 1 -d ' '; 
   rm block_size.tmp; 
)}

​1. daf-2 - Downregulation increases lifespan in c.elegans

Next steps:  RNAi and/or Crispr to cause daf-2 homolog (FOXO3) downregulation in mice + tests on resulting phenotype.

​

​2. PEPCK-C    - Beta-actin promoter linked to pepck gene shown to improve longevity, intelligence metabolism in mice.

Next steps:  Lentiviral transfection vector as a longevity vaccine (develop in mouse ageing model with human gene)

​

​3. m-CAT    -  Mitochondrial targeted catalase : upregulation shown to improve cancer resistance and longevity

Next steps:  Develop transfection vector as a cancer vaccine (develop in mouse ageing model with human gene)

​

4. HAS2 - Molecular weight and production of hyaluron decreases over time.   Organisms with large amounts of HMWHA live longer and resist cancer.

Next steps:  Test regular intravenous injection of HMWHA in rat models of cancer and aging.   Develop gene therapy intervention to increase HAS2 expression.

5. TERT - TERT+ mice live longer, but also produce more tumors.   HAS2, m-CAT and PEPCK-C all interfere with tumorgenesis.  The upregulation of TERT while simultaneously increasing m-CAT and HAS2 expression should have a strong synergistic effect.

Next steps:  Develop gene therapy intervention to increase TERT expression, matching prior experiments, but combine with other interventions.

Object storage: Some manky, idiosyncratic api that allows developers to store "stuff". Avoids dealing with things like partial writes, seeks, memory maps, etc. Generally space wasteful by design. Not a place you'd want to put anything you care about. Yet, secretly, is probably the location of everythingyou care about. Your bank probably keeps your PDF statements in something like this.

Block storage: Like a horse, one can mount this kind of storage... but only for exclusive access. No shared, lockable access, no parallel reads. Essentially it's the virtual hard drive for your virtual machine from which you derive your virtual paycheck.

Clustered storage: Typically one of the above, but your data is now copied ad nauseum. Someone probably didn't stripe it. The things you expect from clustered storage, like striped files, full POSIX support, parallel writes, and erasure coding don't work in your version of the software, but every whitepaper you read refers to them.

POSIX, Erasure Coded, Clustered, Storage (PECCS): 1. This is what you actually want if you run your own data center. Used in a sentence: "Wow, that guy's got PECCS". 2. A mythical beast. 3. Maybe some company named "NextEMCApp" does it. Maybe some guy names Xavier in Spain got it to work once, but then he got hired by [SOME BIG COMPANY] and nobody heard from him again.

When these laws of linguistic use are ignored, readability is demonstrably diminished.

Consider a variable, the hated "x", used 100 times in a file. If "x" is used 100 times in 40 lines of mathematical manipulation, such as in a digest function, this would be acceptable... the high frequency of use strictly precludes a longer name. If, however, it was spread out across 10000 lines of code, a far longer name would be needed.

Of course, suppose that function was embedded in 10k lines of code. Does this change the freqency of x? No. One important rule is that, for the purposes of linguistic calculation, the frequency of any variables usage should be computed relative to the scope of it's use.

As a demonstration, cluttering a short for i=1 to 10 ... loop with for iterationIndex = 1 to 10, can cause code to be nigh unreadable.

Operation can often be obscured by foolish verbosity:

for iterationIndex = 1 to 10
    countArray[iterationIndex]=sizeArray[iterationIndex]*factorArray[iterationIndex] + computeDensity(histogram,iterationIndex)

Versus

for i = 1 to 10
    countArray[i]=sizeArray[i]*factorArray[i] + computeDensity(histogram,i)

Likewise stuffing common prefixes on sets of variables in order to lengthen them can hide their meaning in a limited scope:

for i = 1 to 10
    wordSuffixCountArray[i]=wordSuffixSizeArray[i]*wordSuffixFactorArray[i] + ComputeDensityForWordSuffix(currentWordSuffixHistogram,i)

It's clear that a minimum set of descriptive, distinct terms within the scope of use should, instead, be used.

Recently, software engineering pundits seem to take the stance that there is no such thing as a variable with too-long a name. This is false. Numerous linguistic studies on readability, word length and frequency, bear that out and so, of course, does common sense. Maximum clarity can be achieved in coding languages by using the same types of statistical distributions that occur in natural languages.

IIIIIIIIICCCCCCCCCCCCIIIIIIIIIIIIIICCCCCCCCCCCCC

IIIIIIIIICCCCCCCCCCCCIIIIIIIIIIIIIICCCCCCCCCCCCC

IIIIIIIIICCCCCCCCCCCCIIIIIIIIIIIIIICCCCCCCCCCCCC

IIIIIIIIICCCCCCCCCCCCIIIIIIIIIIIIIICCCCCCCCCCCCC

IIIIIIIIICCCCCCCCCCCCIIIIIIIIIIIIIICCCCCCCCCCCCC

Where 'I' is one second of I/O intensive operation, and 'C' is one second of CPU intensive operation. The result of a perfectly fair scheduler is that there will be periods of high I/O contention and high CPU contention, as the 5 processes are "fairly" switched between, and each keeps the pace with the other.

Using a more "capricious" scheduler, where processes may "get lucky" for a while, my processes will be staggered

IIIIIIIIICCCCCCCCCCCCIIIIIIIIIIIIIICCCCCCCCCCCCC lucky (goes first)

IIIIIIIIICCCCCCCCCCCCIIIIIIIIIIIIIICCCCCCCCCCCCC unlucky (goes last)

IIIIIIIIICCCCCCCCCCCCIIIIIIIIIIIIIICCCCCCCCCCCCC

IIIIIIIIICCCCCCCCCCCCIIIIIIIIIIIIIICCCCCCCCCCCCC

IIIIIIIIICCCCCCCCCCCCIIIIIIIIIIIIIICCCCCCCCCCCCC

It's clear that "everyone wins" when this method is chosen.

My argument for "capricious" scheduling is that a system cannot know, in advance whether something will be an I or a C. Programs can be profiled over time (modern o/s systems don't do this... but probably should), but most program execution paths vary to the point where profiling may be impractical. Accordingly, a scheduler should be, to some extent, random.

https://github.com/earonesty/bowtie

Support for compiling on Apple, stream i/o, and gzip support has been added.

We've come to a point in our evolution as a species where it's not possible to limit the "things" people can obtain. What's more important is creating a world where people have no reason to do harm.

"Well there's no way to guarantee that". Sure. But we allow corporations to draft zoning laws so that people have to drive further to work and so that public transportation remains a failure in most cities. We also allow gross wealth inequity. We try to con mothers into abandoning breast feeding (yes, this still happens, I witnessed it a couple weeks ago), and when that doesn't work we make it as difficult as possible for families to spend time with their kids.

When the majority of the population is stuck in a perpetual state of inadequacy, when the society is structured around things like "employment" and not "enjoyment", it's not surprising that violence seems a means to an end.

A more radical transformation of society, where from birth a nation's citizens feel nurtured, loved and supported would probably go further to prevent violence than "gun laws" possibly could.

If only 10% of the people in America went to work, or if we worked only 10% of the time, we could, with the technology we have, produce all the food, shelter and goods needed for every citizen to live a decent middle class lifestyle. But the focus is not on creating awesome lifestyles. The focus is on more expensive stuff for the few stakeholders that got in early in the pyramid scheme that is capitalism.

We continue to blame the weapon, and not the society that produces it's wielder.

You download printable firearms here: http://kickass.to/defdist-defcad-mega-pack-4-5-otacon-zipped-t7677520.html

The site is https://bitk.in, and it allows you to spend bitcoin & litecoin to get fair-valued gift cards at big online stores like Amazon, Walmart, etc.

It uses the API from http://liteapi.org for Litecoin and Blockchain's wallet API for Bitcoin.

Bitcoin/litecoin integration was trivial. Mojolicious allowed me to spend more time focusing on integration with vendors and payment systems, and just about no time worrying about HTTP.

To be honest, I spent more time thinking about the color than the back end.

The end result is that you will see an error "invalid character for encoding" while restoring.

The utility "iconv" can help, and it was really hard to find the answer online, which is why I'm reposting for my own sanity:

gunzip -c dumpall.gz | iconv | sudo -u postgres psql > restore.errs 2>&1 

Miraculously, iconv worked without options, cleaning up version incompatibilities, while maintaining all the data... even the funny French city names.

If you're changing encodings while also upgrading, that's fine too. iconv takes a "from" and "to" argument, so log in to the source db and destination db, and use:

SHOW client_encoding;

Then use the results as the "-f FROM" and "-t TO" arguments to iconv. No conversion is perfect, but iconv seems to do as good a job as possible.

https://passhash.com/

So, the memory forgetting pill isn't available, but there is Chelerythrine, another kinase inhibitor, that's the natural product of "Zanthoxylum_clava-herculis" aka: southern prickly ash or pepperwood. This compound has already been shown an effective memory disruptor (References: http://bit.ly/HQ6jSt, http://bit.ly/1fwwys5). And it's bioavailable, since chewing pepperwood bark (readily available online) quickly numbs your mouth, and is an ancient herbal pain remedy.

PTSD is another kind of pain.

One treatment for PTSD, CISD is known to be effective, and sometimes is done in conjunction with beta-blockers.

Chewing pepperwood bark during a recall event might work even better - especially since propranolol (the current unproven drug of choice) has had low/no significant reported efficacy in placebo controlled trials. MDMA was shown to be very effective (83% respond to treatment this way), but since it's very illegal, it's a lot harder to work with.

For fun I'm going to try this: chewing the bark until I feel strong numbing effects in the mouth and overall relaxation. Then having someone coach me to recall something painful or annoying. (Yes MDMA would be more fun, but I can click and buy that bark.)

We used RNA-Seq to detect viral homologs in tumor sample expression data obtained from The Cancer Genome Atlas (TCGA) 1. We compared normal tissue viral expression to cancer tissue expression using sequence alignment to a repeat-masked virome, quantification and differential expression. We validated the viral homologs using pileup+scaffold assembly and

BLAST of high-complexity contigs.

Conclusions:

Roughly 30% of lymphoma cancer samples are associated with EBV, and the majority are associated with either EBV, XMRV or SMRV. The use of controls is essential for removing ubiquitous viruses and viral homologs from results. It was difficult obtaining information about public samples. Each TCGA contributor used different processing methods. Many samples (thyroid, ovarian) did not have whole FASTQ’s (an artifact of using BAM as the primary submission format). Although there are often stringent sample submission guidelines for large-scale projects, there appear to be insufficient guidelines for sequencing and bioinformatics.

Link to poster:

Click to view poster from ASHG

grun was written to be an "extremely lightweight" and yet big-featured job scheduler. The early version was not much more than "ssh to remote host, run job, wait for response", while logging and keeping track of resources. It's evolved to use a TCP messaging system allowing the compute nodes, queue nodes, and clients to communicate. By v 1.0 the plan is to have better support for arbitrary metrics, and better handling of priorities.

Going from 0.8 to v 0.9, I decided to try using the zeromq library instead of TCP. At first it was hard to remember that you really don't need to worry about things like sending to a socket you just created, even with no one on the other end.

The net result of the ZMQ port:

1. speed improved

1. implicit perl moved to optimized c

1. built-in multithreading takes better advantage of cpu

1. ability to stop/restart any queue without losing messages

1. improved reliability of message delivery

1. improved code organization orientated around messaging

1. 20% smaller code base, because we removed:

1. all "double checks" to see if connections are there

1. code that "breaks up" large messages

1. all issues with blocking/vs nonblocking i/o

1. the whole "select" loop complexity

ZMQ is not perfect (yet), but it was an overall improvement over straight TCP. Because of the forking needed to launch jobs, I had to do some fiddling with dup'ed file descriptors to prevent zmq from acting wonky. The learning curve was worth it. I doubt I'll be using TCP again, especially since ZMQ has package support with most Linux distributions.

usage: ./ln-abs2rel.pl [-noexec] [-recursive]  ... 

Converts absolute to relative links.

Use -noexec to see what would be done.
Use -recursive to do this for all subdirs.

Setup: 

• 2  "fielders" with gloves and a ball stand a baseline-width apart

• A 3rd kid is the “runner”, standing on base with the fielder who has the ball

Rules: 

• The runner starts running at any time, and the fielder with the ball tries to throw them out

• The person with the ball can’t throw until after the runner starts running

• Start by assuming the play is a force... any good throw is an out

• For kids where this is easy…. it’s not a force…you’ve got to tag them in a rundown

Options … add points for kids who no longer seem motivated by the game (some kids love points, others don’t) ... for example:

• Runner gets two points if he gets to the other base

• Fielders get one point if they throw him out

• Fielders lose two points if they overthrow! 

Purpose:

The point is to develop and value consistency in young fielders… where unnecessary risks aren’t taken, and accuracy/speed are stressed.  Points, rules, etc. change as skills and the coaches needs change.