sirn

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.

I'm not denying that the problem exists, but I don't think Alderon provided enough data to come to a conclusion, unlike on the desktop, where it's supported by other parties in addition to Alderon's data (where you can largely point to 14900KS/K/non-K/T, 13900KS/K/non-K/T, 14700K, and 13700K being the one affected)

Right now, the only example given is HX (which is a repackaged desktop chip[^], as mentioned), so I'm not denying that the problem is happening on HX based on their claims (and it makes a lot of sense that HX is affected! See below), but what about H CPUs? What about P CPUs? What about U CPUs? The difference in impact between "only HX is impacted" and "HX/H/P/U parts are all affected" is a few orders of magnitude (a very top-end 13th Gen mobile SKUs versus every 13th Gen mobile SKUs). Currently, we don't have enough data how widespread the issue is, and that makes it difficult to assess who is impacted by this issue from this data alone.

[^]: HX is the only mobile CPU with B0 stepping, which is the same as desktop 13th/14th Gen, while the mobile H/P/U family are J0 and Q0, which are essentially a higher clocked 12th Gen (i.e., using Golden Cove rather than Raptor Cove)

Are you talking about Xeon Scalable? Although they share the same core design as the desktop counterpart (Xeon Scalable 4th Gen shares the same Golden Cove as 12th Gen, Xeon Scalable 5th Gen shares the same Raptor Cove as 13th/14th Gen), they're very different from the desktop counterpart (monolithic vs tile/EMIB-based, ring bus vs mesh, power gate vs FIVR), and often running in a more conservative configuration (lower max clock, more conservative V/F curves, etc.). There has been a rumor about Xeon Scalable 5th Gen having the same issue, but it's more of a gossip rather than a data point.

The issue does happen with desktop chips that are being used in a server context when pairing with workstation chipset such as W680. However, there haven't been any reports of Xeon E-2400/E-3400 (which is essentially a desktop chip repurposed as a server) with C266 having these issues, though it may be because there hasn't been a large deployment of these chips on the server just yet (or even if there are, it's still too early to tell).

Do note that even without this particular issue, Xeon Scalable 4th Gen (Sapphire Rapids) is not a good chip (speaking from experience, I'm running w-3495x). It has plenty of issues such as slow clock ramp, high latency, high idle power draw, and the list goes on. While Xeon Scalable 5th Gen (Emerald Rapids) seems to have fixed most of these issues, Zen 4 EPYC is still a much better choice.

It's worth noting that W680 boards are not a server board, they're a workstation board, and often times they're overclockable (or even overclocked by default). Wendell actually showed the other day that the ASUS W680 board was feeding 253W into a 35W (106W boost) 13700T CPU by default[1].

Supermicro and ASRock Rack do sell W680 as a server (because it took Intel a really long time to release C266), but while they're strictly to the spec, some boards are really not meant for K CPUs. For example, the Supermicro MBI-311A-1T2N is only certified for a non-TVB E/T CPUs, and trying to run the K CPU on these can result in the board plumbing 1.55V into the CPU during the single core load (where 1.4V would already be on the higher side)[2].

In this particular case, the "non-OC'd server-style motherboard" doesn't really mean anything (even more so in the context of this announcement).

[1]: https://x.com/tekwendell/status/1814329015773086069

[2]: https://x.com/Buildzoid1/status/1814520745810100666

The problem may exist, but Alderon Games' report on the mobile chip is more of an anecdote here because there's not enough data points (unlike their desktop claims), and the only SKU they give (13900HX) is actually a desktop chip in a mobile package (BGA instead of LGA, so we're back into the original issue). So in the end, even with Alderon's claims, there's really not enough data points to come to a conclusion on the mobile side of things.

You could have named this an Electronic Monk!

Quoting from Dirk Gently's Holistic Detective Agency (Douglas Adams):

> The Electric Monk was a labor-saving device, like a dishwasher or a video recorder. Dishwashers washed tedious dishes for you, thus saving you the bother of washing them yourself, video recorders watched tedious television for you, thus saving you the bother of looking at it yourself; Electric Monks believed things for you, thus saving you what was becoming an increasingly onerous task, that of believing all the things the world expected you to believe.

iOS requires a browser to use the OS-provided WebKit, but you can still use your own networking layer, and doing your own scripts injection (e.g. for extensions, like what Orion is doing). Firefox for iOS used to use Alamofire as its networking engine, but switched over to NSURLSession/URLSession at some point. Chrome for iOS uses Cronet which was extracted from Chromium's networking stack (or maybe used, I have not followed the development recently).

Looks like there’s a new build with the 6.6 kernel. I’ll try this over the weekend and report back!

Edit: I just did a quick test, it seems to work pretty well. The volume control works, the camera works. So far, what doesn't seem to work is the fingerprint sensor and automatic orientation. The pen also seems to work.

I have not, partly because the most recent build I've found is still Android 9.0, which uses kernel 4.x, while the Radeon 780M in Minisforum V3 requires at least kernel 6.4.

I have tried Waydroid, but the lack of full USB passthrough means I cannot login to my Google Account (due to Advanced Protection; and U2F doesn't work over HID forwarding) so I didn't test it further.

It has multi-touch, but I don't think it has any special hardware for palm rejection.

My Minisforum V3 arrived a few days ago. I like the overall package, but there are a few things I would like to add, after using it for the past few days (running NixOS with Plasma 6):

- The screen panel QC seems very inconsistent. My unit got at least 2 dead pixels and over 6 bright pixels and a horizontal faint line across the screen, possibly caused by coating. I don't notice the dead pixels that much during the normal use due to the screen PPI being quite high (215 PPI), but it has way too many. (I'm trying to arrange a replacement with Minisforum, and JP store seems to have better support than the rest, so I'm keeping my fingers crossed.)

- The overall pen experience is quite good for writing. There's no perceivable lag in Krita as far as I can tell. I would still prefer Wacom Cintiq or iPad Pro for any serious drawing/painting session (the V3 pen pressure detection doesn't feel accurate enough to me).

- Everything mostly working out of the box as of kernel 6.6 (LTS). Sleep works great. The only thing that seems broken so far is the audio, which lacks any volume control. A lot of people suggest setting pipewire to use soft-mixer, but this caused the device to be muted during the machine startup. My workaround to this is to have a soft mixer Virtual Sink in pipewire and leave the audio device as-is.

- Tablet experience is suboptional. As mentioned in the article, if you happen to use more than one language, and have to use Fcitx5 for text input, then you're likely going to manually have to switch between Maliit and Fcitx5 every time you detach a keyboard (because Plasma only allow one Virtual Keyboard to be used).

- Also, Maliit lacks Ctrl/Alt/Cursor Keys, making this very unsuitable for an emergency console during travel/transit unless you also pack a keyboard, which adds thickness/weight. At this point, ThinkPad may have been a better choice. (I'm looking into possibly adding at least arrow keys to Maliit). (Also, Maliit Japanese keyboard uses a flick layout, which is broken because Maliit also uses a downward-drag gesture to dismiss itself... so you can't type any letters that require a downward flick)

- Battery life is, as mentioned in the article, 6 hours if I use powersave with power EPP, and around 4 hours if I use powersave with balance_performance EPP. Under Linux, battery drain during sleep is only around 1-2% over 8 hours (tested by charging to full before bed and leaving it unplug).

- The touchpad experience is fine. They're not amazing, but good enough to get the job done (there are certain angles that the touchpad sensor will stop registering touch events).

Charity is closer to ใจบุญ (jai-bun) than น้ำใจ (nam-jai).

A mixture of "act of kindness" and "good will" would be a more fitting translation, but the interesting part here is that "sportmanship" is also considered an act of น้ำใจ (น้ำใจนักกีฬา nam-jai nak-kee-la or literally. sportman's nam-jai).

We also have a word เสียน้ำใจ (sia-nam-jai) for when our nam-jai ended up as a waste, or for when the other party is being ungrateful for the kindness that's being given, and also เลี้ยงน้ำใจ (leang-nam-jai) for when you're doing/accepting nam-jai for the sake of not making the other party sia-nam-jai.

There were a few cases where Apple's Sherlocking resulted in an inferior version being included in the OS, but managed to kill the original anyway. For example:

- Konfabulator vs Dashboard (only caught up to Konfabulator with widgets in Sonoma)

- Growl vs. Notifications Center (I think Growl is still more configurable even now).

Another caveat is that if your workflow requires dealing with complex text layout on a regular basis (e.g., Asian languages), Affinity suite support for it is pretty much non-existent. For example, lack of a working right-to-left support, no vertical text support for CJK, broken tone markers handling in Thai layout, lack of complex word-break for any languages that is not space-based, etc.

Sadly, Adobe is still the only option in the market for this.

This only applies to hwmon, i.e. `sensors`. You can still read this through powercap/intel-rapl (even on AMD systems).

Since kernel 3.3 or so, RAPL is also exposed through `/sys/devices/virtual/powercap/intel-rapl/*/energy_uj` in micro-joules (if not, `modprobe intel_rapl`). So if you want to do a quick power measurement, it can be done using just POSIX sh (root required):

    # in milli-watt (1000 = 1W) because shell arithmetic doesn't do floating point 
    while true; do
        LAST_MJ=$MJ
        MJ=$(cat /sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/energy_uj)
        echo $(((MJ - LAST_MJ) / 1000))
        sleep 1
    done

Despite the powercap name being intel-rapl, the powercap interface is also available on AMD machines.

For a more detailed reading on several more metrics about the CPU, I think pcm[1] may be a better tool (it's a successor to the Intel Power Gadget the project was forked from). Though, it only works on Intel CPU.

[1]: https://github.com/intel/pcm

Zengin (the interchange network) actually supports 24x7 real-time transfers and EDI data (ZEDI based on ISO 20022, which is built so that you can include invoice number, reference number, etc.) since the end of 2018 or so with the introduction of More Time System and 7th Gen Zengin System. Sadly, it's the bank and bureaucracy that's holding back here (e.g., some smaller banks still refuse to connect to More Time outside their business hours).

Each My Number Card is a X509 certificate signed by a government agency (JPKI) and uses two passwords for signing and for user authentication. As far as I'm aware, there are currently two concerns with the JPKI part: though the password itself is not an issue (although the password requirement of 4 digits number for signing + lowercase letter for authentication may as well be), the ward office offered a piece of paper to write these passwords down when you issue the card, and many people did & folded it together with the card itself. Another one is that requesting user authentication means you'll get all the data on the card (name, DoB, gender, current address, image data) which may be too much from a privacy standpoint.

Apart from JPKI itself, another issue of My Number Card currently is that most of online KYC using MNC is still largely done by comparing the photo printed on the card with an image data taken from a web camera. There's a published paper of a group of researchers able to pass an eKYC using a photo of MNC and Deepfake[1] (and an actual case of someone doing a SIM-swap using a photo of My Number Card[2]). The government has recently been promoting the use of JPKI for eKYC instead of doing image analysis[3] (which loops us back to the privacy issue, though there have been talks about reviewing what to include/not include in the user authentication part of the card).

[1] https://www.jstage.jst.go.jp/article/pjsai/JSAI2021/0/JSAI20...

[2] https://finance.yahoo.co.jp/news/detail/e3801312bffeedcb1999...

[3] https://www.soumu.go.jp/main_content/000946152.pdf

systemd socket activation opens extra fds starting from fd 3 (SD_LISTEN_FDS_START). Though I can't think of a scenario where this may be relevant for dehydrated. Maybe some weird systemd unit somewhere that invoke dehydrated does this?

One of the biggest benefits of dehydrated is that it doesn't try to integrate with a DNS provider on its own. It just connects to ACME server and calls a hook, which can be implemented with a simple shell script[1]. The most popular third-party integration is lexicon[2], though you're not required to use Lexicon. (e.g. you're free to use awscli, gcloud, linode-cli, etc. to do the actual DNS record manipulation)[3]

This means its dependencies footprint is much smaller, and allows you to do things that can be a nightmare to configure with Certbot or other alternatives. For example, at one of the scenarios I had to set up was that we had to query a credential via HashiCorp Vault, which is then used to cURL into an API endpoint. The shell script in total was pretty short (~200 LOC) and it worked extremely well. The fact the shell script is so simple that I could test adding/removing records without ever invoking ACME process is also a huge benefit.

[1]: https://github.com/dehydrated-io/dehydrated/blob/master/docs...

[2]: https://github.com/AnalogJ/lexicon

[3]: https://github.com/dehydrated-io/dehydrated/wiki

iPhone has 51% market share in Japan across all age group[1] (and even as high as 84.8% in some demographic[2]). From my 5 years of living here, I’ve never seen anyone use iMessage even once. The dominant messaging app is LINE.

[1]: https://www.idc.com/getdoc.jsp?containerId=prAP51933524

[2]: https://japantoday.com/category/tech/study-shows-iphone-the-...

Modern CPUs have many limits to protect the CPU and later the clock behavior. For example, clock limit, current limit (IccMax, 307A for 13900K), long power limit (PL1, 125W), short power limit (PL2, 253W), transient peak limit (PL3), overcurrent limit (PL4), thermal limit (TjMax, 100c), Fast Throttle threshold (aka Per-Core Thermal Limit, 107c), etc. It also has Voltage/Frequency curves (V/F curve) to map how much voltage needs to drive a certain frequency.

Intel 13900K has a fused V/F curve until its maximum Turbo Boost 2.0 (5.5 GHz) in all cores, and two cores at its Thermal Velocity Boost (aka favored cores, 5.8 GHz). How much to boost depends on By Core Turbo Ratio. For stock 13900K, this is 5.8 GHz for 2 cores, and 5.5 GHz for up to 8 cores with E-cores capped at 4.3 GHz.

As you may have noticed, the CPU has a very coarse Turbo Ratio beyond the first 2 cores. This is to allow the clock to be regulated by one of the limits rather than a fixed number. In reality, 253W PL2 can sustain around 5.1 GHz all P-cores, and after 56 seconds it will switch to 125W PL1 which should give it around 4.7 GHz-ish (IIRC).

This is why when a motherboard manufacturer decides to set PL1=PL2=4096 without touching other limits, it results in a higher number in benchmark. The CPU will consume as much power as it can to boost to 5.5 GHz, until it hits one of the other limits (usually 100c TjMax). This is how we ended up in this mess in the consumer market.

Xeon, on the other hand, has a very conservative and granular Turbo Ratio. My Xeon w9-3495x do have a fused All Core Boost that does not exceed PL1 (56 cores 2.9 GHz at 350W), which makes PL2 exist only for AVX512/AVX workload.

(Side note: I always think that PL1=PL2=4096W is dumb since performance gain is marginal at best, and always set PL1=PL2=253W in all machines that I assembled. I think even PL1=PL2=125W makes sense for the most usage. I do overclock my Xeon to sustain PL1=PL2=420W though (this is around 3.6 GHz, which is enough to make it faster than 64-cores Threadripper 5995WX))

This requires `setopt HIST_IGNORE_SPACE` (zsh) or `HISTCONTROL=ignorespace`/`HISTCONTROL=ignoreboth` (bash/ksh) to be set and may not be enabled by default in many distros (e.g. NixOS doesn't, Alpine doesn’t, etc).

Always check your shell before assuming this will work!

Core count shouldn't matter given the benchmark is single threaded (mentioned in the article). My guess is that CPU frequency plays a huge role in the throughput. Here's the same benchmark on a baremetal Xeon w9-3495X (Sapphire Rapids Workstation). As seen in the log (best_frequency) this is running at ~4.4 GHz during the benchmark:

partial_tweets<simdjson_ondemand>/manual_time 107280 ns 132468 ns 6469 best_branch_miss=376 best_bytes_per_sec=8.10705G best_cache_miss=1 best_cache_ref=553 best_cycles=342.737k best_cycles_per_byte=0.542722 best_docs_per_sec=12.8375k best_frequency=4.39987G best_instructions=1.42334M best_instructions_per_byte=2.25385 best_instructions_per_cycle=4.15285 best_items_per_sec=1.28375M branch_miss=378.313 bytes=631.515k bytes_per_second=5.48235G/s cache_miss=0.655434 cache_ref=609.834 cycles=352.768k cycles_per_byte=0.558605 docs_per_sec=9.32143k/s frequency=3.2883G/s instructions=1.42334M instructions_per_byte=2.25385 instructions_per_cycle=4.03477 items=100 items_per_second=932.143k/s [BEST: throughput= 8.11 GB/s doc_throughput= 12837 docs/s instructions= 1423337 cycles= 342737 branch_miss= 376 cache_miss= 1 cache_ref= 553 items= 100 avg_time= 107279 ns]

Given in the article Xeon 8488C at 3.4GHz got 6.83 GB/s, and my 3495X at 4.4 GHz got 8.11 GB/s (1.29 times CPU freq, 1.18 times throughput), it does look like the throughput scales to the CPU frequency (although not entirely linear)

IANAL, but it's written in Immigration Act Article 19, Paragraph 1, No 2 (入管法19条１項２号)[1]. Here's a translation from Japanese Law Translation[2]^1

> Article 19 (1) Any foreign national who is a resident under a status of residence listed in the left-hand column of Appended Table I shall not engage in the activities set forth in the following items, with regard to the categories identified therein, except for cases where he/she engages in them with permission as set forth in paragraph (2) of this Article.

> (ii) A foreign national who is a resident with a status of residence listed in the left-hand column of Appended Tables I (3) and I (4): activities related to the management of a business involving income or activities for which he/she receives remuneration.

The quoted "Appended Table I (3)" (別表第一の三) says:

> Temporary Visitor

> Sightseeing, recreation, sports, visiting relatives, inspection tours, participating in lectures or meetings, business contact or other similar activities during a short stay in Japan.

None of this says "within Japan", which from my understanding is that it allows for the maximum interpretation of the law, i.e. "involving income or activities for which he/she receives remuneration [from anywhere]" with the noted activities in Appendix Table being the exception.

Either way, it depends on how immigration interpret the law.

[1]: https://elaws.e-gov.go.jp/document?lawid=326CO0000000319

[2]: https://www.japaneselawtranslation.go.jp/en/laws/view/1934/e...

^1:

- (i) is not quoted here since it's about a mid-long term stay visa, i.e. work visa

- Paragraph (2) is about obtaining permission to receive remuneration (which is a different thing from (ii) quoted above).

> the characters that got unified do share the same semantic meaning across languages

It doesn't in practice. For example: 机 in Japanese means "table", while the same codepoint in Simplified Chinese means "machine" (i.e. 機 in Japanese).

I haven't used Android since Nokia 7 Plus (back in 2019) but the variant that I had back then (TA-1062) doesn't have Japanese locale settings, despite being Android One and all that. I had to install MoreLocale2 and modify the settings via adb to make it work.

Every phone that was sold in the region I used to live (SEA) also lacks Japanese locale out-of-the-box. I had assumed this was still the case (locale availability tie to region being sold).

Ah yes, having both probably makes the prioritization fall apart :(

I have no idea if there's any sane way to make this work. Since I only speak Japanese, my fix on Linux is to prepend IPA PGothic/IPA PMincho (which only contains Japanese glyph) to lang=ja, which worked quite well.

This is actually less problematic on a Mac and on iOS (if you speak the language) because the rendering engine actually prioritizes CJK set according to OS' language preferences (System Settings → Language & Region → Preferred Languages).

It's a much bigger issue on Linux, Android, and Windows prior to Windows 10, however.

Kagi has been pretty good for me for Thai and Japanese results.

I've had countless occasion Google's result is much worse than Kagi, as far as returning actual useful results is concerned. For example, searching for a product in Japanese, Kagi may find fewer results, but Google shows a page full of affiliate spam, which is not really useful.

The only occasion where I found Google remotely useful is for image search and map search.