j6m8

omg that rocks

interesting! the axidraw v3 that I used for this (https://shop.evilmadscientist.com/productsmenu/846) has a 0.0125mm stepper resolution, which means that it is pretty close to not-worth-it to go any finer since the sizes of the scratches are already many microns wide. But certainly with better etching technology that would be a super cool update!

less!

thank you so much for the kind words!!

author here — the second I did that, I considered handing it to the robot. but ... robot with oil in my living room... I decided against it :)

This is neat — I do think this is relevant to more than just the software engineering space. See also, healthcare and law (I wrote more at length here, not to derail this comment thread [1]). Our junior training on-ramps for a lot of knowledge-work fields are in some semblance of equilibrium, but it's an unstable one.

[1] https://blog.jordan.matelsky.com/AI-doctors-bum-me-out/

To those who are interested in reading more, I recommend Mary Roach's "Stiff" (and all her other work too!) highly highly highly!

you're welcome to use/snag any of it you like :) planning to keep that repo growing, so if you think of good synergies for us, I'd love to keep making useful stuff!

you could try my https://github.com/j6k4m8/goosepaper :)

no worries, good to know this would be a useful feature! I'll add it to my backlog.

    pip install 'git+https://github.com/j6k4m8/frof/'

and then

    frof myfile.frof

should work!

Was thinking about rewriting it in Go recently... :)

here they'll probably be executed simultaneously, since they both have zero dependencies and the machine can run multiple jobs at the same time. (can be disabled with `--max_jobs=1` or `-p=1`).

Here's another illustrative example:

    A -> B
    B -> C
    Z -> C

In this situation, frof will schedule `Z` to run in a parallel thread ASAP, so it will likely run alongside A... and if Z takes longer to run than A, Z will continue running when A stops and B starts. But C will wait for all other jobs to finish before it can schedule.

You write the file and ALL steps are run in topological order so that a job never runs until its dependencies have run. i.e., in a tool I'll have `build.frof` as a separate frof file than `download-dependencies.frof`, perhaps. (If your preference is that those belong in the same file I'd be down to have PRs that support that! Should be very easy, I'm happy to try implementing this if there's interest.)

So for a file with those contents called `mygraph.frof`, you can (after installing) run `frof mygraph.frof` to kick off the jobs in the current shell (inheriting env vars etc).

[edit] maybe a clarifying example here: https://blog.jordan.matelsky.com/frof-render/

I wrote frof [1] for exactly this purpose :)

Designed to be ultra-simple and with minimal "config-file acrobatics".

It looks like this [edit, formatting]:

    write -> analyze
    build -> analyze

    write:     echo 1 2 3 > data.txt
    build:     compile_tool.sh > tool.sh
    analyze:   tool.sh data.txt

https://github.com/j6k4m8/frof/

That's a question more suited to a microbiologist or bacteriologist than to me, but my educated guess, at least in the electron microscopy case, is that you'll see the bacteria inside the depth of the slices, rather than sitting "atop" the slices. i.e., if you cut open an apple and find half a worm, the worm was in the apple. If you cut open an apple and then see a worm on top of the slice, it's possible it arrived post-cut.

Very hard to clean a blender!

More nitpickfully, one of the big things we care about is if the bacteria are living _harmlessly_ in the brain. i.e., site of microbes, and a lack of inflammation, will answer more than just "are there microbes around".

Microbes are CRAZY. They're everywhere. Thermal vent-friendly microbes. Space-friendly microbes. Vacuum-resilient, heat-resilient, acid-resilient. Microbe-free-environment-friendly microbes [1]. It seems hard to imagine that a blood-brain barrier could really keep the brain sterile.

We're lucky to live in a scientific era during which a "gut microbiome" is taken for granted (heck, even FDA-approved treatments depend on it! Google FMT, but don't click "images" from your work laptop), but it wasn't so long ago that we felt microbes were unlikely to live endogenously and harmlessly anywhere in the body.

There were also some hypotheses (untested, if memory serves) that COVID-19 influenced olfactory neurons through direct infection. Don't tell the blood-brain barrier, but if I were a bacterium, the nasal palate would be my ingress strategy. Or maybe the gums or gut — one of the cranial nerves, certainly. [edit] I should clarify — covid is viral, not bacterial, but it does show that this is a potential entry vector.

The central nervous system is incredibly complicated, and our symbiotic relationship with microbes is extraordinary. I think it does a disservice to bacteria to suppose they DON'T get involved in an organ :)

[1] https://www.space.com/ryugu-asteroid-sample-earth-life-colon...

A few years ago my team mounted what I think was the largest-(to-date) scale search for this in electron microscopy brain tissue volumes [1].

I STRONGLY believe there is a substantial central nervous system microbiome, but (spoiler alert) no evidence found in that search :)

If you're excited about this work, the datasets are all freely available from BossDB [2] — well over a dozen petavoxels of it! I'd be so curious if models these days could pick up on something we missed!

[1]: https://www.biorxiv.org/content/10.1101/2022.07.12.499807v1 [2]: https://bossdb.org

raw data is O(petabytes) (single-digit); synapse-neuron graph will be probably order 100GB. But you also want morphology and locations, since it's not enough to just say "X connects to Y" if you want to know about dynamics!

i'm not hosting this dataset specifically, but check out https://bossdb.org/. my disclaimer and also my brag is that this is my job and research area :) if you're looking for a copy, let's talk! there are easy ways and hard ways :)

preprint coming out soon about this specifically :)

in the meantime, here's a simple tool paper we wrote explaining how you can treat this like a cool graph database challenge [1] and a preprint showing how you could approach that question when your number of samples per animal is close to N=1 [2]. basically..... it's hard! but also.... it's cool!

[1]: https://www.nature.com/articles/s41598-021-91025-5 [2]: https://www.biorxiv.org/content/10.1101/2023.10.16.562590v1....

The reMarkable company has been super adversarial to a lot of these tools, and the file standards and API have been moving goalposts for years. MOST of the tools on that Awesome list are defunct because the primary open source tools for getting data to the reMarkable cloud (rmapi and rmapy) are no longer maintained — the primary maintainers both cite reMarkable's moving target API as the final dealbreaker. SUPER sad.

I've been hoping to write my own now that the dust has settled, but it's definitely a MAJOR project yet to be done by the FOSS community.

ha — that's exactly what I've been working on on a separate reMarkable project posted earlier today [1] :)

[1] https://news.ycombinator.com/item?id=41437740

You can write software for it but reMarkable as a company has been downright adversarial to the open source community and MOST of the tools on that Awesome page are now defunct because reMarkable has obfuscated API endpoints or changed file-standards to prevent third party efforts.

Totally, the reMarkable has handwriting recognition as well — this project was partially borne of the workflow of "write text, auto transcribe, send to a computer, copy paste into an email." How do you like the Boox? My friend loves his!

ha, I learned shorthand in second grade (and yes, it was already an antique by then). I wonder what a multimodal language model would say to shorthand...

This is connecting via the reMarkable cloud tool, but everything is abstracted into a `DocumentManager`, so you could also use, for example, the document manager that just drops PDFs into the filesystem [1] so that you can use whatever tool you like, including, say, iPad, writing with a wacom on your laptop, etc.

[1] https://github.com/j6k4m8/epistolary/blob/main/epistolary/do...

Definitely want to try that too!! In general I think people sending an email expect a text format reply, but there's something sad about losing that handwritten letter :) Plus of course, drawings → attachments!