matvore

  > Obviously the proper solution is to adjust your system thermal management / power targets,

I did solve this problem once upon a time by running the process in a cgroup with limited CPU, though I later rewrote my dwm config and lost the command, without caring enough to maintain the fix.

If the fan was turning on where it wasn't before, it seems like cooling was once happening through natural dissipation, but after your fix it needed fans to cool faster. So the fix saved time but burnt extra electricity (and the peacefulness of a quiet room.)

This is pretty easy to understand IMO. About 70% of the time I hear machine's fans speed up I silently wish the processing would have just been slower. This is especially true for very short bursts of activity.

  > all of the languages mentioned so far appear before the "Latin alphabet" 
  > style languages, but 閩南語 and 閩東語 appear after them.

The Wikipedia sort for the languages is as I stated above, with Literary Chinese and Japanese between Wu Chinese and Yue Chinese. I explained why it was sorted that way, because radical is considered first. You could not explain why Japanese appeared between Wu and Yue because you insisted and continue to insist that radicals are not used.

I didn't say sorting is never done by stroke count alone. But I have seen radical+residual stroke count much more often than stroke count alone. Probably a result of the content I'm accessing. It's mostly Japanese and not intended for children.

The dictionary and non-dictionary sorting distinction that you make doesn't sound like a real thing. The audience, the country, and the number of items sorted are bigger factors. But you're not wrong in that stroke count is sometimes used alone.

It is sorted FIRST by radical and SECOND by stroke order. This is roughly equivalent to the Unicode codepoint sort if you stay in the basic multilingual plane. The order also puts literary chinese afer wu Chinese, which breaks with a pure stroke-count sort:

中文 - 中 = 丨 + 3 strokes

吴语 - 吴 = 口 + 4 strokes

文言 - 文 = 文 + 0 strokes

日本語 - 日 = 日 + 0 strokes

粵語 - 粵 = 米 + 7 strokes

Note I work for Google and I've contributed to Chromium, though I'm not necessarily an expert on Chromium forks.

1. Google Chrome

This is offical Chrome you download from google.com and also comes on ChromeOS devices.

2. Chromium

This is what you get when someone builds Chromium from the official repo without access to confidential source.

Source is confidential for various reasons, and some code that seems should be confidential actually isn't, like Android-for-ChromeOS integration, some of which is here: https://crsrc.org/c/chrome/browser/ash/arc/

3. Ungoogled Chrome?

This seems a contradiction of terms. Only Google can build Chrome, so they are not likely to e.g. set Bing as default or remove Google password manager support.

4. Ungoogled Chromium?

A particular project run by a particular team which forks Chromium and removes pro-Google behavior and settings.

5. Googled Chromium?

I don't know the original context of the use of this term, but possibly this just refers to official Chrome.

Chromium is merely Chrome with only the open source parts. Chromium components are still implemented in a Google-controlled repo. So it has Google-oriented features and defaults.

This is the default font of my browser-based terminal emulator, http://github.com/google/werm, along with a handful of other retro fonts (uses the int10h.org ttf's--converted to bitmaps--which I suspect has all the same characters as Neue)

IMO it still looks rather nostalgic. I do remember using cmd.exe or command.exe in Windows 95 and later and this being the default (but it would different if you had a different legacy code page set, IIRC). Of course cmd.exe just rendered the pixels as-is, no emulation or retro effects.

Yes, let's take dozens of terminal emulator projects out of maintenance mode so app devs can individually and capriciously overload my shift and escape keys, because modern.

  > Context: Bitcoin miners have just adopted a 50% pay cut for themselves.

The halvening timing was coded a long time ago, and in order to change it, the nodes would need to adopt the new code by installing updated clients, and at that point, you have a hard fork, because there will be nodes on the old rules, either accidentally through not updating or intentionally through using a modified core distro, and you have the new rules' valid blocks is a disjoint set from the old rules'.

The new rules' block set being a subset of the old rules' is a strictening of the consensus rules. A strictening consensus scheme is a soft fork and can keep the network in one piece.

So, there is no real way for the miners to avoid the halvening without a hardfork and a great risk to the network.

Some say hunky dory comes from "honcho doori" or 本町通り (personally I don't see how ki can come from cho)

I wish I knew awk as well as I know perl, since then I wouldn't need to hear recommendations for CPAN modules and spurious style prescriptions.

Perl has the advantage of only having one implementation, unlike sed and grep (e.g. BSD or GNU) and /bin/sh (can be one of many POSIX shells), so upgrading this pipeline to 100% perl is safer in some respects. The example in the article is light on details so it's hard to comment very deeply.

I have heard snarky Perl putdowns ad nauseam at work and on HN and may have regretted using it a handful of times but I can say worse or similar for other popular tools, languages...

If we're going to talk about unnecessary extra processes like useless cat, we should merge the head and grep commands into a sed, and possibly just merge everything into perl:

    <access.log sed -n '/mail/p; 500q' | perl -e ...

  > To prove a point, I spent an hour reading his opensource project
  > and found several resource leaks

  > To prove a point, I spent an hour reading his opensource project
  > and found several resource leaks

  > > if I find [… typo words(?) omitted … ] a leak in the code I
  > > usually refactor to make the correctness more obvious.

There are non-language mechanisms that help code run safely, like Wasm, which is a sandbox. Also msan and asan should be used more.

Thinking that changing the language is the right way to fix all the problems you mentioned still seems like a premature assumption. The fact that 100% perfection is worth pursuing at all costs is theoretical and you could be losing things more valuable in the process - e.g. FFI bindings suck, and the added fragmentation in having so many languages in the craft is a pernicious cost with a multitude of aspects to it.

Don't worry, we enjoy that kind of stuff.

I usually put all the resource freeing at the end of a function under a goto label, or only a few lines within the allocation, so it's easy to visually confirm everything is cleaned up. The way this commit frees the resources inside of if blocks is not how I would have done it. And if I find I let a leak in the code I usually refactor to make the correctness more obvious.

In this example, the fact that m3_ParseModule takes ownership of the wasm pointer is very tricky. It looks like there is still a leak but there is not.

If you store the number of zeros as value z, computing z+1 is O(log n) in the long run for unbounded values of z.

If you define predictable as computable with finite memory, it is correct.

If you have finite memory, you have a finite number of states and will eventually return to a previous state. In your example, you eventually will run out of memory to track the number of consecutive zeros.

  > No, they're crazy. I already have a window manager I like; I don't need my 
  > terminal to implement their own half-assed one,

  > I notice no 1 second delay when switching modes with the Esc key, so perhaps 
  > this is something you can configure in your terminal.

What does `Ctrl + [` send to the terminal for you if not esc? In my experience these are always the same, so Vim shouldn't be able to tell the difference unless it's a GUI-integrated version like gVim.

Try to run `xxd` and then press Ctrl-V and either Ctrl+[ or Esc, then Enter and Ctrl+D. Typical terminal setups will show the same codes both times (1b0a for esc and \n).

Alt+Space (or Alt+J Alt+K Alt+B to go up, down, left one word from current position after returning to normal mode) is what I often do which should work universally.

  > I stick with emacs because of the modal and recursive minibuffer(s) (ie. command-line(s)). What vim setting do I change to be able to use normal mode down there?

The last time I used a leak finder, a memory allocation which still has a ptr to it is not a leak.

You are conflating unfreed memory with unreferencable memory.

I tried swapping CAPS and Ctrl, and I understand the appeal, but I guess I just like pressing Ctrl in the default row - sometimes swapped with superkey - with my palm.

Huh? People use their fingers to press ctrl? :p

For most terminal emulators (and not gVim or editors with Vim bindings), you can also use Alt+[first key you want to type in normal mode]. e.g. Alt+J to enter normal mode and go down one line. Or Alt+Space to enter normal mode and go forward one space (which usually has the apparent effect of entering normal mode without shifting the cursor backwards, which is pretty intuitive).

I sympathize a bit with the dislike of enum. We could also probably get away with replacing typedef's with either #define (for simple types) or one-field structs (for arrays and function pointers; the latter usually need a void* to go along with them anyway).

There are reasonable low-level optimizations you can do that switch is needed for. You can have cases that start or end around blocks in non-hierarchical ways. This makes it similar to a computed goto.

Would it be solved with a simple macro such that Ctrl+F2 (i.e. switch to menu bar, which is the way I mostly start to interact with UI using the keyboard) automatically reverted to Latin alphabet input? Hypothetically speaking.