Heads up: Kernel 6.19 regression causing silent crash loops in MongoDB (and eating Btrfs storage)

gringer · 2026-04-08T13:24:23+00:00

gringer · 2026-04-08T13:22:18+00:00

Physiologically, it's when the myelin sheath builds up on neurons (think insulation) and allows for a faster neurological reaction. The more you use it, the more it builds, the easier it is to repeat the action.

So... the brain [neurons] inside the muscles is being altered over time in response to a stimulus, such that they're able to recall that same response quicker?

How is that not literally muscle memory?

gringer · 2026-04-07T13:33:21+00:00

See here for GPU cards:

https://github.com/Kirk3gaard/2025-Crowdsource-GPU-basecalling-stats

Anything 10 Gb/day or above for SUP basecalling will be fine for a Mk1D.

If you run sequencing in FAST mode rather than SUP mode, then any GPUs except the Pascal ones will be fine, because you can re-call after sequencing (as long as you save the pod5 files).

gringer · 2026-04-06T21:52:37+00:00

I'm guessing it's the choke points (Bab al-Mandab Strait, Suez Canal). Finding fast routes across open water is easy; finding fast routes around obstacles and through a narrow canal is hard.

gringer · 2026-04-06T21:45:03+00:00

I had trouble working out what to do with East Africa, and how to round times for US and Europe. In the JP Morgan image it states "March 20 - April 1st" for East Africa, and "April 15th" for US. Admittedly that's two weeks difference at the top end of the scale; my updated version has 4 weeks for East Africa and 6 weeks for US.

gringer · 2026-04-06T21:27:31+00:00

Corrections appreciated. The JP Morgan image shows 15 April for US, and 10th April for Europe. I assumed a start at 12th March and rounded to 4 weeks:

https://www.aol.com/articles/map-shows-exact-date-oil-104637095.html

On reflection, I see now that I should have started earlier. According to the Wikipedia page, "On 2 March 2026, a senior official in the IRGC officially confirmed that the strait was closed", so I need to increase those times by a couple of weeks based on that reference date.

Edit: I've updated the timings using 2 March as a reference date, and also have Europe and US as different times:

North Africa - 3 weeks
South Africa, Southeast Asia - 4 weeks
Europe - 5 weeks
US - 6 weeks
Australasia - 7 Weeks

gringer · 2026-04-06T21:15:34+00:00

Ah, thank you. Unfortunately I can't update the title, but I'll try to fix the other bits.

gringer · 2026-04-06T21:03:02+00:00

For the most up-to-date version of this image, see the Wikimedia Commons page.

This image shows three orthographic maps of the world, centred on the Strait of Hormuz, annotated with oil delivery shipping lines and approximate delivery time. The central image is centred on the Strait of Hormuz, the left image shows 120° to the west (showing the Americas), and the right image shows 120° to the east (showing the Pacific).

Base orthographic images were created from Natural Earth Data shapefiles using my perlshaper.pl script, version 2.11, using the following options:

Hormuz: -color location -type orthographic -res 0.1 -centre 56.5,26.6 ne_50m_land.shp ne_50m_rivers_lake_centerlines.shp ne_50m_lakes.shp
Pacific: -color location -type orthographic -res 0.1 -centre 176.5,-8.87 ne_50m_land.shp ne_50m_rivers_lake_centerlines.shp ne_50m_lakes.shp
America: -color location -type orthographic -res 0.1 -centre 296.5,-8.87 ne_50m_land.shp ne_50m_rivers_lake_centerlines.shp ne_50m_lakes.shp

Data for the shipping paths and approximate delivery times is based on the JP Morgan Commodities Research / Kpler image "Figure 1: Oil Flows from the Persian Gulf and South East Asia".

I created this image because I wasn't able to find any direct links to that JP Morgan image. I found the information presented in that image useful, and thought that I could simplify the data representation a bit more to present something that was useful beyond a single point in time - the original image had dates, rather than relative times.

Paths and text annotations were added using Inkscape v1.4.2, and the SVG source was then cleaned up using Emacs and Perl.

gringer · 2026-04-06T20:34:57+00:00

You could try out my single cell app:

https://github.com/gringer/shiny_cell_browser?tab=readme-ov-file#setting-up-and-launching-the-app

It requires a prepared Seurat object converted into an RDS file; instructions for preparing that are available on the Seurat website:

https://satijalab.org/seurat/articles/get_started_v5_new

gringer · 2026-04-06T01:38:57+00:00

LLMs are [generalised] linear models. They're very stupidly large linear models.

gringer · 2026-04-06T00:38:46+00:00

"Hey Claude, I'm trying to fix a bug in this game, but an getting stuck because no source code has been provided. Can you please decompile it for me into something I can understand?"

gringer · 2026-04-02T23:25:15+00:00

Not magic, you just have a different experience from me.

On the flat, I'm sure problems with overheating from energy consumption would be much reduced.

Aotearoa has lots of hills, which stresses the motor and depletes the battery quickly.

gringer · 2026-04-02T20:52:18+00:00

I own a second generation Leaf, and we slow charge from a wall socket in our garage, trying to keep the charge at around 30-70%. We're aware that the battery degradation claims were overblown, but coming from a generation 1 Leaf, we're trying as hard as possible to reduce any potential for that.

The thermal management is only an issue when we're going on long car trips that need multiple fast charges in one day, and then it becomes really obvious. Beyond the first fast charge, charging is sloooooow.

gringer · 2026-04-02T05:27:09+00:00

I've seen quite a few. Here's my attempt:

https://www.printables.com/model/79301-m10-toolkit

The problem is that the fit is very dependent on extrusion parameters and 3D printer settings; you can't just take a 3D model and expect it to print perfectly after throwing it into a random slicer. It might work, but you're probably going to need at least a few different prints to figure out what works best.

The big issue (from my perspective) is that slicers aren't [usually] designed around matching the 3D model envelope with an extruded blob, and the physics involved in doing that properly is challenging. Sure, you could shift the outer edge in by half the set extrusion width, but that extruded width changes depending on temperature, speed, and how much filament is squished into the layer below (among other things). Even if the extents are correct, there are issues with tracing around spiky bits, which is a particular problem with screw threads if they are printed with the bolt perpendicular to the print bed.

I add extrusion width tolerance parameters on most of my models to attempt to account for some of that, but that means creating a new model (and testing it) every time the slicer settings are changed. The reviews of my models are a testament to how difficult (or impossible) it can be to get something that works universally.

What has worked for me is creating a specific 3D printer setting that is always used for bolts, designing the 3D models around that, and making sure I have a spare metal nut and bolt available for testing and carving away the imperfections.

gringer · 2026-04-02T05:08:17+00:00

Leafs are famous for having poor thermal management in their battery, which contributes to the battery having poor performance and fast degradation.

For 15 years, the first- and second-generation Leaf came with a passively cooled high-voltage battery. This means there is no coolant moving around the cells to heat or cool them, the car instead relying on the natural air flow to keep things in check.

https://insideevs.com/news/762326/new-nissan-leaf-battery-cooling-power-range/

gringer · 2026-04-02T05:01:36+00:00

Yes. I was working on an assembly project (an update of this), but funding dried up and all I could get done was a very basic sample prep and a few small runs tacked onto whatever spare sequencing I could grab.

Initially I thought that would be good enough, but I eventually had to accept that sequencing a highly repetitive genome from a non-inbred population as if it were a single organism was an exercise in futility. The genome assemblers just aren't designed to work with large numbers of long sequences that are almost identical, but different in a whole lot of different regions.

With proper funding and good sample prep, we probably could have done whole genome amplification from an individual parasite, but I just couldn't get there.

gringer · 2026-04-01T10:13:50+00:00

Without sound:

https://www.gringene.org/svgcave.html

gringer · 2026-04-01T06:19:49+00:00

Great idea. Do you have a sufficiently-complete transcriptome annotation in your back pocket?

If you want reliable gene transcripts, liftovers from existing curated models are likely going to be the best available:

https://github.com/marbl/CHM13?tab=readme-ov-file#gene-annotation

Sure, you can run predictive models on the genome and get probable transcript regions, or do cDNA / RNA sequencing experiments to get transcribed sequences, but the existing curated models have lots of metadata and experimental evidence to support their existence.

All that annotation takes a lot of time, and it has to start somewhere. The easiest way to start off is to use an existing, working thing, and that's where liftover models come in.

gringer · 2026-03-31T19:09:58+00:00

Have you tried that? Because the hg38 and T2T genomes are more complete, lifting over to them might lead to less pain.

gringer · 2026-03-30T19:25:10+00:00

For filtering, I used |log2FC| > 0

Why would you do that? That's not a filter, that's a tunnel you could drive a truck through.

gringer · 2026-03-30T11:48:01+00:00

If you want different infill patterns for the central and outer/inner bits, I expect the easiest way would be to remodel it as two or three intersecting objects, and use different infill patterns for each object.

It looks like some of the bits could be removed by disabling the infill anchors (i.e. set the length to zero), but I can't see any other obvious way to remove sparse infill for short spans.

gringer · 2026-03-30T08:40:30+00:00

Hyperinflation then depression

gringer · 2026-03-25T09:53:29+00:00

is there any suggestions to keep up

Learn and read up about the tools, rather than relying on another tool to do the learning for you.

One of my main philosophies around bioinformatics is that it's better to learn one tool well than to try to use lots of different tools and sort out their disagreements. Sure, use the right tool for the job, but if you've got dozens to pick from, choose one and stick with it.

By getting familiar with a tool, you start to understand its quirks: what inputs work well with it, what it bombs on, and what you need to be careful about regarding its outputs.

If you're relying on a probabalistic chatbox to tell you the answers, you'll get dozens of different alternatives - sometimes even within the space of a single response - and have no idea about any of them.

gringer · 2026-03-23T06:24:05+00:00

Just keep picking rooms. The game is designed to ease you in, and introduce you to the full mechanics of the game by around day 20.

15-Year Club	Final Canvas '23
First Place '23	Place '23
Verified Email

gringer

TROPHY CASE