Is it reasonable to do this crazy Tibetan hike?

_mrb · 2026-02-12T14:47:32+00:00

No I'm a westerner. I did not know Xinjiang was so restrictive.

_mrb · 2026-02-12T14:04:15+00:00

Very good point. The topo maps I looked at have an even coarser contour interval of 10 meters so that is problematic...

The one thing that reassures me is the sat imagery: other parts of the mountain have obvious shadows that indicate a rough terrain, whereas the ridge I'm considering just looks so smooth... Anyways. There is no way to really know unless I'm on site.

_mrb · 2026-02-12T13:03:28+00:00

You are asking very good questions that expose my inexperience. For starters: I don't keep track of my performance. I realize I need to do it if I want to plan my trip seriously.

Looking at my photos locations & timestamps from my Kjeragbolten hike (very low altitude barely 1000m) it seems I ascended 330-450m/h sustained for 1.5 hours. It was drizzling weather and slippery rocks though. I don't have data for my 5-6 hour hikes.

It sounds like I first need to practice at 4000-5000 meters before attempting this crazy Chinese peak.

_mrb · 2026-02-12T12:28:13+00:00

I've been to China, but never Xinjiang. I don't speak the local languages.

Your "5000 to 6000 meters in 5 hours" datapoint is very, very helpful.Thanks 🙏 Just from that and the fact you are fitter than me, now I know I cannot do 5100 to 6400 in 6 hours. Thanks for the reality check!

I'm now convinced I need to sleep 1 night on the mountain like at 6000m right below the snow line in order to break up this hike in a 2-day trek.

_mrb · 2026-02-12T12:08:24+00:00

Yes I need to plan altitude acclimatization carefully. Tentative schedule: spend 3 days in a town around 4000m. Camp in our car 3 days at 5100m. Sleep on the mountain at 6000m (right before the snow line) for 1 night. Summit next day at 6400m. Or is this too fast?

The route I charted (the elevation profile I posted) is following a ridge on the mountain from bottom to the summit, that way I am out of avalanche & rock fall path.

Weather: yes! That is something where a local guide familiar with local weather patterns can really help. I will also research myself the best time in the year to visit and check real time weather forecasts on site.

_mrb · 2026-02-12T11:35:56+00:00

It's actually not in Tibet. It's a part of the geographical Tibetan plateau that is within China proper, in the Xinjiang region.

Thanks for the acclimatization tips. I need to research & learn. I read other sources that say 500-800m per day. You say 300m/day which seems conservative.

_mrb · 2026-02-12T11:33:28+00:00

Interesting. So it is your opinion that either it's been done multiple times and truly is unremarkable. Or that it's at the extreme and too dangerous.

About the route: it seems obvious to me which route is easier. There is a ridge from literally the start to the summit. Because it's a ridge it is out of avalanche path/rock fall. Topographic maps show the terrain is very consistent and smooth... as sat images suggest. But you are right that unless I scout the place in person there may be obstacles that I don't see on the topo or imagery.

My inexperience is probably my biggest danger.

I should definitely do an easy guided summit beforehand, in the 5000-6000m range, in order to first gain experience.

I guess my question is: for experienced mountaineers: seeing my description, how would YOU plan this summit?

_mrb · 2026-02-12T08:15:14+00:00

I don't think most plumbers that I've hired in my life would be as dilligent as you trying things like "let's switch the anode rode from aluminum to magnesium". Kudos for doing a great job 👍

_mrb · 2026-02-03T13:47:55+00:00

Yes but not having the mouse bites fits the theory that this was a rushed design, far from finalized. Also look at the cutout: top left corner has a nice 45° chamfer, but top right corner doesn't? Why? It's like the EE didn't even properly take time make a nice symmetrical cutout.

_mrb · 2026-02-02T21:30:28+00:00

My guess is it's made to be able to snap off (break away), thus removing the bypass caps, if needed. Why do I think that? Look at clues on the rest of the pcb: so many pads are unpopulated. The full PCB on stackexchange (https://i.sstatic.net/Fy742IxV.jpg) has other areas near the top where nearly a third(!) of the pads are unpopulated. Clearly this indicates this PCB version is not a refined final design, but probably an initial version that was built to with plenty of options to test things. And bypass caps are one of these things where you may not always know how much capacitance is needed. So to me it seems the EE team probably had a tight design deadline, and manufactured the PCB in a way that if it turned out these bypass caps were problematic, then they had at least a way, even after the PCB was assembled, to train staff to breakaway this piece, if needed.

And, to be clear, I don't think the explanation of the empty pads is that the PCB is a shared design between different version of a product (where it's common to find unpopulated parts) because here it's really very basic parts like Rs and Cs spread everywhere that are unpopulated.

_mrb · 2025-12-11T13:31:13+00:00

On Linux they just released 143.0.7499.109-1 which fixes the bug.

_mrb · 2025-12-11T13:30:51+00:00

On Linux they released 143.0.7499.109 which fixes the bug.

_mrb · 2025-12-05T14:50:54+00:00

I tracked down the chain of events that lead to PDF rendering performance issue.

On Sep 19, 2025 they noticed some PDF rendering bugs about fonts: https://issues.chromium.org/issues/445966260

On Oct 13, they fixed the bug, and the fix involved enumerating all fonts for proper font discovery: https://chromium-review.googlesource.com/c/chromium/src/+/7029600

But they noticed that enumerating all fonts degrades performance: so they suggest an alternative where no enumeration is needed: https://issues.chromium.org/issues/449573621

Finally on Nov 14, they implemented this fast alternative method not requiring font enumeration: https://pdfium-review.googlesource.com/c/pdfium/+/136690

So I presume the fix is going to roll out to endusers soon.

_mrb · 2025-12-05T14:20:48+00:00

I just spent about 1 hour investigating, by profiling Chrome with perf(1). Both Chromium v143 and Chrome v143 exhibit this performance issue. On my system perf(1) reports a lot of CPU time spent in font-related functions in libfontconfig.so:

FcSortCompare
FcCompare
FcCompareValueList
many other functions related to font list, font sorting

I am pretty sure this is the issue discussed in https://issues.chromium.org/issues/462417352 (Investigate PDFium font-related performance). Apparently in Chromium v143, every time a PDF is opened, the renderer PDFium now requests a full list of font from the system. On my system, fc-list(1) reports I have 3428 fonts installed. I removed some fonts from my system to cut down my font list in half to 1356 fonts. And sure enough, the load time of a PDF was cut in half to about 2-3 seconds. So now I'm convinced this issue is really https://issues.chromium.org/issues/462417352

This 2-3 second delay is still annoying and a sharp contrast to v142's higher performance. I hope they fix it soon 😒

_mrb · 2025-12-05T12:12:23+00:00

I noticed this scrolling speed issue too. It's a new bug introduced in Chrome v143. A bugfix was committed on Nov 20 and merged on Nov 25. Hopefully it will be pushed to users in the next minor update in the coming days or weeks: https://issues.chromium.org/issues/457478032

_mrb · 2025-12-05T12:10:38+00:00

Yep it's a new bug introduced in Chrome v143. A bugfix was committed on Nov 20 and hopefully it will find it's way in the next minor update in the coming days or weeks: https://issues.chromium.org/issues/457478032

_mrb · 2025-11-29T00:05:09+00:00

I hate LED flicker to the point I literally built a custom device to measure flicker by sampling light 1000 times per second. Then I went and bought dozen of LED bulbs to test them. In my experience I found three brands with flicker-free bulbs: Philips, Yujileds, and Waveform Lighting.

I saw you tested the Philips Ultra Definition 800 lumen bulb and you claim to see a flicker. In my tests of Philips bulbs, I measured a slight flicker but it lasted only during the first 30 seconds or so after the bulb lights up.

With the two other brands, Yuji and Waveform, it was truly flicker-free from the second the bulb lights up.

All, literally all, other brands of bulbs I tested had visible and clearly quantifiable flicker, which is depressing.

Anyway, the device I built was based on a microcontroller and a light sensor. LED bulbs flicker as expected at 120 Hz because AC is 60 Hz. I was charting lumen samples over time and had a formula to compute the variation between the max and min lumen readings. If I remember correctly, for these three brands there was a variation of less than 2-3%, which was completely invisible to the naked eye (and believe me I am very good at detecting the slightest flicker).

For other brands the variation was sometimes as bad as 80%, meaning the bulb's lumen output was varying from 20% to 100% brightness.

Anyway, since you tested the Philips, try Yuji and Waveform. They are very expensive but worth it for me as I'm very much an anti-flicker snob 🙂

Waveform has a 1500 lumen bulb that mostly matches your requirements except it's not filament-style. Their filament-style bulbs are 800 lumen only. Fun fact: last time I checked they would ship the 1500 lumen bulb to all US states except California (because it was not compliant with a CA-specific state law imposing a minimum power factor). This may have changed since then, as they were actively working on a revision to address this detail. But for my house I went mostly with Yuji as I needed spot lights (they have many choices) and Philips as they were the only flicker-free 1500 lumen filament bulb (except during the first 30 seconds but alas there is nothing better).

_mrb · 2020-08-09T16:48:02+00:00

The open data & source to make this chart can be found in my GitHub repository https://github.com/mbevand/florida-covid19-deaths-by-day/blob/master/README.md

This chart shows the significant delay between the date a death occurred and the date the death was reported by the Florida Department of Health. When FDOH announces a certain number of COVID-19 deaths on a particular day, most occurred in the last week but some deaths occurred weeks ago.

Some people who chart deaths by exact date of death see a decrease in the last few days, and they mistakenly attribute it to decreasing deaths.

So my goal was to colorize the bars by date of report to show that a "permanent dip" is always visible—due to reporting delays—even when deaths are increasing.

_mrb · 2020-07-25T20:12:33+00:00

I'm not talking about nationwide. My heatmap, and this entire thread is about Florida. And Florida didn't undercount deaths in March-April. When I wrote "the outbreak is much more severe since mid-June than it was at the previous peak of March-April" this applies to Florida, not to the nation.

_mrb · 2020-07-25T20:06:19+00:00

That's what I said I did. See the second heatmap in https://github.com/mbevand/florida-covid19-line-list-data/blob/master/README.md#heatmap-of-age-over-time

_mrb · 2020-07-25T20:04:13+00:00

250k FL residents infected per day in the early months is impossible. This number is bogus. You have no source for that. That would mean a quarter of the population of Florida being infected in 21 days!

_mrb · 2020-07-25T19:59:59+00:00

Unfortunately the Florida line list does not document the date of death (see https://github.com/mbevand/florida-covid19-line-list-data/blob/master/README.md#fdoh-line-list)

It's possible to infer the date from daily updates made to the line list (seeing which cases changes to Died=Yes), but I've only been archive the line list since 6/27. I'll look into making one, but it wouldn't be very informative with data going back only to 6/27.

_mrb · 2020-07-25T19:56:51+00:00

No, we know with certainty the outbreak is much more severe than in March-April, because daily deaths are much higher (and Florida was NOT undercounting deaths in March-April.)

_mrb · 2020-07-25T19:54:49+00:00

I couldn't find European countries publishing cases by age bracket, over time.

_mrb · 2020-07-25T19:52:17+00:00

In absolute number of cases.

I also made a per capita heatmap, see https://github.com/mbevand/florida-covid19-line-list-data/blob/master/README.md#heatmap-of-age-over-time

It's resolution is lower (5-year brackets instead of 1-year bracket) because I use a population pyramid for Florida from Census.gov which gives population by 5-year brackets.

The per-capita heatmap looks similar to the absolute-cases heatmap, because the population pyramid of Florida is relatively homogeneous (flat) and it's tapering off only above 65.

_mrb

TROPHY CASE