sirn

The first issue is due to the assumption that character count equals character display width. Thai tone markers usually[1] should not contribute to the display width (เพื่อน is chars = 6, width = 4), so it caused a layout shift.

The second issue is due to the program's layout engine not adjusting the glyph width of a fallback font to that of the main font. A lot of terminals do this, but it's not common for text editors or browsers (arguably this is the correct behavior for non-terminals, since you cannot assume everything must be snapped to a grid).

Fun test for this:

     |กล้วยหอม|
     |Bananas|

[1]: some layout engines render free-standing tone markers as 1 character; in that case, this rule only applies to when tone markers are following a character.

When I still used Git, I used to have a minimized `magit-init.el` that essentially did:

    (setq user-emacs-directory (format "~/.emacs.d/magit/%s/" emacs-version))
    (setq custom-file (concat user-emacs-directory "custom.el"))
    (setq make-backup-files nil)
    (setq auto-save-default nil)
    (setq create-lockfiles nil)
    (setq inhibit-startup-screen t)
    (setq initial-scratch-message nil)

    (require 'magit)
    (defun setup-standalone-magit ()
      (magit-project-status)
      (delete-other-windows))
    (add-hook 'after-init-hook 'setup-standalone-magit)

    #!/bin/sh
    if [ "$(git rev-parse --is-inside-work-tree)" = "true" ]; then
        exec emacs -nw -q --no-splash -l "/path/to/magit-init.el"
    fi

Oh thanks. Corrected. My brain saw TW (instead of TC) and short-circuited that as a language name for some reason!

I also have to use LINE every day, and I can't say I love it (but it's either this or Facebook). They've been trying to push LINE Premium and LINE AI very hard (at least in Japan) to the point that some features are now blocked (e.g. you cannot unsend photos anymore unless you pay for Premium) and I absolutely hate it.

As someone who regularly works with Japanese and Thai, I'm very excited about this, given it has English, Japanese, Korean, Thai, and Traditional Chinese as its basic set. Thai itself is complex to layout[^a], and it can be very hard to find a matching typeface. I guess LINE has this problem too, given the app is popular in both Japan and Thailand.

It is, however, a bit unfortunate that this is yet another unlooped Thai typeface[1]. Loopless is impossible to read as a body text for people above thirty. Historically, IBM Plex Sans Thai Looped[2] was pretty much the only open-source stylized Thai font that is looped (not including the standard Tlwg set). I remembered that Noto Sans Thai[3] used to be looped, but they switched to a loopless version at one point. Thankfully they've (re?)introduced the looped version[4] in recent years.

[1] https://en.wikipedia.org/wiki/Thai_typography#Looped_vs_loop...

[2] https://fonts.google.com/specimen/IBM+Plex+Sans+Thai+Looped

[3] https://fonts.google.com/noto/specimen/Noto+Sans+Thai

[4] https://fonts.google.com/noto/specimen/Noto+Sans+Thai+Looped

[^a]: Since Thai text typically requires another ascent level above cap height and ascender, and another level under descender for tone markers and vowels, on iOS, if you add Thai as one of the phone languages, iOS will apply a 1.2x line height modifier to all text in the system, either by expanding line-height when allowed, or shrinking the font size.

It works somewhat more reliable (I've found vterm to break in some interesting ways depending on your cursor position even with evil-collection), but it's pretty awkward to use with evil, at least without any configuration.

For example, pressing 0 to go to beginning of line goes to before the $PS1, rather than the input beginning, going from NORMAL → INSERT inserts text at the end instead of at the cursor, Emacs motion keys doesn't work, etc. I think if I take some time to remap the key it might work, but usually I just switch to Emacs mode or just restrict myself to use only cursor key to navigate.

I usually use `emacsclient -nw` inside a terminal (sometimes over mosh). I've found eat[1] to be much a better than vterm at being a terminal emulator inside Emacs (inside a terminal). It flickers less, and seems to handle key forwarding a lot better. The only downside is it's slightly slower than vterm at handling a large chunk of data (e.g. cat an access log).

[1] https://codeberg.org/akib/emacs-eat

How is it that people were able to create so many mule accounts in the first place? What sort of KYC was going on?

They pay a low-income/no-income person a small fee (possibly monthly) to let them borrow their account. Sadly, people who would fall into this are not hard to find in Thailand.

What sort of KYC was going on?

There are accounts that are grandfathered in and don’t require KYC but have been able to access online banking, etc. Mine is such, and my bank (BAY) is discontinuing that particular loophole at the end of this month. (I'm in Thailand right now to do this KYC, despite having not come back here for the last 6 years.)

It's still mind-blowing to me to think that a decade earlier this would have been a few racks. Now it just fits within 1U or 2U. What an insane world we live in.

N150 is still using the old Gracemont core (same as N100, but with higher clock). From there, there is Crestmont (node-shrink Gracemont in Meteor Lake), and Skymont (in Lunar Lake/Arrow Lake), whose performance is already comparable to that of Golden Cove (12th Gen P-core). Chips and Cheese has written a very detailed analysis for Skymont[1] if you're interested.

[1] https://chipsandcheese.com/p/skymont-intels-e-cores-reach-fo...

This is more of a successor to the Xeon 6E (Xeon 6700E / Sierra Forest-SP), which had 144 cores. There was supposed to be a 288-core variant (presumably Xeon 6900E / Sierra Forest-AP), but they never released it to the public. I was looking forward to it since Sierra Forest-AP was supposed to support a 2-socket configuration (from motherboard spec). That's 576 physical cores in a single server!

I've found that Gemini 2.5 Pro is pretty good at analyzing existing code, but really bad at generating a new code. When I use Gemini with Aider, my session usually went like:

    Me: build a plan to build X
    Gemini: I'll do A, B, and C to achieve X
    Me: that sounds really good, please do
    Gemini: <do A, D, E>
    Me: no, please do B and C.
    Gemini: I apologize. <do A', C, F>
    Me: no! A was already correct, please revert. Also do B and C.
    Gemini: <revert the code to A, D, E>

My rough mental Intel driver matrix is something like this (might not be entirely correct):

    iGPU:

    | Arch                                         | KMD     | DRI (Mesa)  | Vulkan (Mesa)  | VA         |
    | -------------------------------------------- | ------- | ----------- | -------------- | ---------- |
    | <  Broadwater (Gen4)                         | i915    | i915        | N/A            | N/A        |
    | >= Broadwater (Gen4), < Westmere             | i915    | i915        | N/A            | i965       |
    | >= Westmere (Gen5), < Haswell                | i915    | crocus      | N/A            | i965       |
    | >= Haswell (Gen7), < Broadwell               | i915    | crocus      | hasvk          | i965       |
    | == Broadwell (Gen8)                          | i915    | iris/crocus | anv/hasvk      | iHD        |
    | >= Skylake (Gen9), < Tiger Lake              | i915    | iris        | anv            | iHD        |
    | >= Tiger Lake (Xe/Gen12), < Lunar Lake (Xe2) | i915/xe | iris        | anv            | iHD/libvpl |
    | >= Lunar Lake (Xe2)                          | xe      | iris        | anv            | iHD/libvpl |

    dGPU:

    | Arch                                  | KMD     | DRI (Mesa)  | Vulkan (Mesa)  | VA         |
    | ------------------------------------- | ------- | ----------- | -------------- | ---------- |
    | >= DG1 (Xe/Gen12.1), Battlemage (Xe2) | i915/xe | iris        | anv            | iHD/libvpl |
    | >= Battlemage (Xe2)                   | xe      | iris        | anv            | iHD/libvpl |

i915 is still the main kernel mode driver on Linux for every Intel GPUs up to Alchemist. xe kmd is used by Battlemage by default (as of 6.12).

There's a Mesa DRI driver, called i965 (originally made for Broadwater chipset, thus the 965 numbering), which has since been replaced by either:

- Crocus for anything up to Broadwell (Gen 8)

- Iris for anything from Broadwell and newer

Then there's a Video Acceleration driver, which is (also) called i965. I think this is what you're referring to. There are:

- i965 (aka Intel VAAPI Driver), which supports anything from Westmere (Gen 5) to Coffee Lake (Gen 9.5)

- iHD (aka Intel Media Driver), is a newer one, which supports anything from Broadwell (Gen 8)

- libvpl, an even newer one, which supports anything from Tiger Lake (Gen 12) and up

Battlemage users had to use libvpl until recently because Media Driver 2024Q4 with BMG support was only released 2 weeks ago. Using libvpl with ffmpeg may requires rebuilding ffmpeg, as some distro doesn't have it enabled (due to conflict with legacy Intel Media SDK, so you have to choose).

I have B580 for my Linux machine (6.12), and xe seems pretty stable/performant so far.

Fun anecdote: Thailand's entire banking network (including regular wire transfer) was implemented with ISO 8583 (!). Part of the AnyID master plan (later renamed to PromptPay) was to replace the country's (ab)usage of ISO 8583 with ISO 20022. The Ministry of Finance hired a UK-based Vocalink to build this converter, among with other systems MoF hired them for. (AFAIK, the entire stack was written in Erlang.)

It's also a hardware problem. For example, Alchemist's EUs being SIMD8 but games requiring SIMD16, so it needs to be dispatched to two EUs in a lockstep, or the lack of support for Execute Indirect instruction commonly used in UE5 games, which is currently emulated in software, makes game compatibility a very hit-or-miss.

Battlemage is supposed to fix all these architectural issues. EU in Xe2 is now SIMD16 (which is why the number of EUs per Xe2 core is halved from that of Xe1), and they've added all the previously software-emulated instructions, including Execute Indirect, so in theory Battlemage should be in a much better position in game compatibility side of things.

On Linux side of things, lacking sparse residency support in i915 also contributes to game compatibility[1] (though this is now available under Mesa 24). This is something the new xe driver is supposed to fix, but it's still a long way to go until it's actually usable.

[1] https://www.phoronix.com/news/Intel-Vukan-Sparse-TR-TT

Not an app, but some USB testers (e.g. POWER-Z KM003) can do this by reading an e-Marker chip on the cable. I'm not sure if there's a way to access eMarker purely through software without some sort of driver support, though.

What they provide is a text transcription of every words spoken (文字起こし) accompanying by a screenshot of the relevant scenes (in its original language). It’s less like elaborated summaries and more among the line of "posting a closed caption along with a relevant screenshot"

DDR5 doesn't have an In-Band ECC. What they have is On-Die ECC, and is not visible to the memory controller (i.e. error information won't be reported by EDAC), and only corrects 1-bit when they're stored/retrieved, where Side-Band ECC (regular ECC) and In-Band ECC can correct 1-bit and detect 2-bits, and can also correct/detect memory corruption during transit.

ECC is supported on any higher end 12th/13th Gen, but it's locked behind a chipset feature lock. If you can find any board that uses W680 (e.g. W680D4U-2L2T which can be had on Amazon for $569), then it's possible to use ECC UDIMM on Intel Core and have ECC detected/reported.

Some N100 do have In-Band ECC (which uses the same data lane as regular memory channel, so less usable memory space/effective memory bandwidth), such as the Beelink S12 Pro box (DDR4) and is recognized by EDAC subsystem on Linux.

    [    8.485808] [    T703] caller igen6_probe+0x138/0x780 [igen6_edac] mapping multiple BARs
    [    8.487601] [    T703] EDAC MC0: Giving out device to module igen6_edac controller Intel_client_SoC MC#0: DEV 0000:00:00.0 (INTERRUPT)
    [    8.487625] [     T67] EDAC igen6 MC0: HANDLING IBECC MEMORY ERROR
    [    8.487626] [     T67] EDAC igen6 MC0: ADDR 0x7fffffffe0
    [    8.487664] [    T703] EDAC igen6: v2.5.1

Some comments:

- You don't really need to repeat built-in VCLs in default.vcl. In the article, you can omit `vcl_hit`, `vcl_miss`, `vcl_purge`, `vcl_synth`, `vcl_hash`, etc. If you want to modify the behavior of built-in VCL, e.g. adding extra logs in vcl_purge, then just have `std.log` line and don't `return` (it will fall through to the built-in VCL). You can read more about built-in VCL on Varnish Developer Portal[1] and Varnish Cache documentation[2].

- Related to the above built-in VCL comment: `vcl_recv` current lacks all the guards provided by Varnish default VCL, so it's recommended to skip the `return (hash)` line at the end, so the built-in VCL can handle invalid requests and skip caching if Cookie or Authorization header is present. You may also want to use vmod_cookie[3] to keep only cookies you care about.

- Since Varnish is sitting behind another reverse proxy, it makes more sense to enable PROXY protocol, so client IPs are passed to Varnish as part of Proxy Protocol rather than X-Forwarded-For (so `client.ip`, etc. works). This means using `-a /var/run/varnish.sock,user=nginx,group=varnish,mode=660,PROXY`, and configuring `proxy_protocol on;` in Nginx.

[1] https://www.varnish-software.com/developers/tutorials/varnis...

[2] https://varnish-cache.org/docs/7.4/users-guide/vcl-built-in-...

[3] https://varnish-cache.org/docs/trunk/reference/vmod_cookie.h...

I'm curious – if open standards such as 2FA (TOTP) and Passkeys are considered locked-in, what would be a solution in your mind for an authentication scheme that doesn't subject to the inherent problems of passwords (phishing, weak passwords, password reuse, database exposure, etc.) that fits your requirement?

What if I don't want to pay for Bitwarden, or buy a smartphone, or tie my log-ins to my computer?

Even with passwords, you'd still need an application or a device for 2FA, unless you keep a pack of scratch cards with you everywhere. So unless you go out of the way to avoid 2FA or use scratch cards, I don't think this change anything from the status quo, only now you have one less thing to remember.

Do you know which BIOS/microcode you were running before updating to 0x129? Multicore workload should never hit anywhere near 1.55V which is the cap from 0x129, and 13700K should be capable of doing 5.4GHz at 1.3V even with the worst bin, so it's a bit strange to see this 20% performance hit on CB.

If this is compared to <= 0x123 (before the introduction of "Intel Default Settings") then this drop may be attributed to low AC Load Line configuration in previous configuration, which essentially undervolting the CPU out-of-the-box. >= 0x125 BIOS usually bumped this up/lower this down to Intel's recommendation. It could be very possible that AC_LL is setting too high on the MSI board after the fix.

It's still very strange though, even if AC_LL is the culprit, that 253W is running 20% slower than 125W. For what it's worth, I have two systems running 13900K and 13700K both with ASRock board, and I see no difference in MT performance with 1-2% drop in ST (though 13700K is running with PL1=PL2=125W, but that shouldn't affect ST).

This is why I think it's going to be much harder for Xeon to be affected by this, as they're normally running in a more conservative voltage settings. I don't have Xeon E-2400 to look at, but Raptor Lake should be able to do 5.6 GHz at 1.3-1.4V-ish, which should be within a safe voltage range. (even the "power hungry" w9-3495X only runs at ~1.25V during 4.8 GHz TVB, and ~1.15V at non-TVB 4.6 GHz boost.)

I feel like the entire fiasco has been multiple issues being lumped together as one, and muddied to the point that even a bluescreen out of an attempt to run XMP at extremely high MT/s are now being claimed as degradation. From what I can make out of this mud, there seems to be (1) a failure caused by high current due to some boards unlocking IccMax/PL1/PL2 by default, and (2) high voltage during a single-core boost (TVB). The former is caused by overclocking, and the latter seems to be Intel's failure to validate the CPUs at low load/long period of single-core boost, where IccMax/PL no longer matters as much (since single-core boost never exceeds PL1 anyway).

Most Raptor Lake "server boards" right now are W680 with client CPUs because the C266/Xeon E-2400 took a long time to come out. The one intended for workstations typically has overclockable settings or is even overclocked by default, which means it's likely to get hit with the failure (1). The one intended for servers do have more conservative settings, but can still be hit with failure (2) under some conditions.

Buildzoid released a video on the Supermicro W680 blade a bit ago that were having issues after running a single-core load 24x7, which is essentially 24x7 boost[1] (aka issue (2)). Xeon E-2400 _could_ be affected in this scenario, although even the highest clock E-2400 SKU (E-2488) is only running at 5.6GHz without Thermal Velocity Boost, and most others are ranging from 4.5 to 5.2 GHz boost (rather than the 5.8 to 6 GHz boost some client SKUs do). I feel like the actual B0 Xeon E-2400 would be a lot less prone to both failures (1) and (2) due to this (but it could happen, though there's no reports of such).

But then the conversation gets muddied enough that "even servers and Xeons are affected" becomes the common narrative (while the former is true, the circumstances needs to be noted; and for Xeons, it's a _maybe_ at most, since right now there's no report of Xeon E-2400 failing).

[1] https://www.youtube.com/watch?v=yYfBxmBfq7k

The concept is the same (given a definition file, build a package from a central repo, aka ports-like), but one of the features of PKGBUILD has is that it's easy to build an ad-hoc package outside the main tree. For example, you can download a bundle of PKGBUILD and `makepkg` in any directory to build a package.

In other ports-like build systems, this can be a bit more complicated. For example, MacPorts allows you to use a local repository, but it requires configuring that local repository in `/opt/local/etc/macports/sources.conf` and `portindex` it beforehand before MacPorts could pick it up. Some others don't support building out of the main tree at all.

Personally, out of all ports-like building systems, I like MacPorts' Portfile the most. It's similar to FreeBSD Ports' BSD Makefile (MacPorts was created by Jordan Hubbard who also co-created FreeBSD Ports) but using DSL via Tcl interp instead of being a shell script (POSIX shell in the case of Alpine's APKBUILD, bash in the case of others). From my experience, the syntax is very nice to work with, though you need to know a bit of Tcl for a non-trivial package.

Not the OP, but my ASRock N100DC-ITX idles at around 9W at the wall.

I haven't watched the video in its entirely, but it does feel like single core boost might be the main culprit in this scenario. That actually makes a lot of sense why game servers are the one that's affected the most. Though that makes me wonder about HX CPUs failing, since these SKUs doesn't have TVB, but given Wendell's 10-25% failure rate on all-core load, it does seem like Intel may actually have multiple issues with RPL here. Things definitely doesn't look good.