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.
[^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.
I wish they'd put this much effort into the app itself. Line is by far the worst messaging app I've ever used (and I have no choice, but to use it). Files and photos expire and disappear, giant ads in the UI, chats that disappear, notifications and calls that fail to show up on the receiving side (happened to me both on iOS and Android), inane process of transferring chats to a new device or the chats will just disappear, PC app that logs me out every single day (somehow Telegram and Signal stay logged in just fine).
Exactly this. Instead of inventing another useless typeface noone is gonna use (I am pretty sure there are numerous typefaces exist that excel for Thai and Japanese languages) they would better work on simple case chats backup that's doesn't work if you move the app cross OS.
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.
I hate the expiring photos/videos in message threads too. Overall the UX is clunky. I also use Wechat everyday, and even though their UX is also pretty clunky, it's still somehow efficient, and doesn't it bother me as much as having to use Line.
This sounds plausible. Unicode as used and implemented on modern OS has a nasty quirk that texts become patchy mix of the language in use + random Simplified Chinese equivalents(apparently the opposite still randOmly haPPEn in Simplified Chinese systems too - showing Japanese pieces out of nowhere). The official Unicode Consortium sanctioned solution to this problem is to specify and switch fonts wherever and however appropriate, even mid-sentences, which isn't a great solution, if not unreasonable for a lot of developers.
Creating language-specific fonts that can be just forced everywhere to eliminate random pieces from other languages solves this problem. At least everything will be consistent.
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).
Sorry for the tangent: I was very eager to try vterm until I read that people have had issues with evil-mode [1]. Any idea whether eat and evil can get along?
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.
> 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.)
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.
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!
The upcoming Zen6c will have 256 Core per socket, and dual socket gets you 512 Core. Since the Zen 6c support SMT while E-Core doesn't, the Zen6c would support 1024 vCPU in a single server!
I am looking forward to Zen6C vs Xeon 7-Ecore. Wondering about the cost / pref.
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.
Indeed! Now with Up 2-4TB of Memory, and 1-2 PB of SSD. All inside 1-2U. By 2030 we will have server with 1000W CPU. We are fundamentally close to be limited by cooling.
And I forgot to include this. We have 1U of Server that could replace 1 Rack. That is 40x density increase. I wouldn't be surprised if we could increase this to 80x to 100x within another 10 years.
If that is the case, why do we need more DataCentre? Wouldn't it be easier to retrofit existing DC. Sometimes these sort of hyper scale is just so big they are beyond my imagination.
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>
Whereas Sonnet/Opus on average took me more tries to get it to the implementation plan that I'm satisfied with, but it's so much easier to steer to make it produce the code that I want.
When I use amazon-q for this, I make it write a plan into a markdown file, then I clear context and tell it to read that file and execute that plan phase by phase. This is with Sonnet 4.
Sometimes I also yeet that file to Codex and see which implementation is better. Clear context, read that file again, give it a diff that codex produce and tell it do a review.
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.
I am always confused about which drivers need installing to fully enable all hardware acceleration features on Broadwell. Also not all distros maintain the drivers equally resulting in mismatches between the vaapi driver or some other driver.
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.
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.
The problem is that a cable saying that it's something does not mean that it actually conforms to the standard and can deliver that speed/power. And proper testing requires complex hardware.
That's true of every cable that has ever existed, including basic electrical wiring, and so feels like a separate problem than merely identifying what kind of cable a cable even intends/claims to be in a world where they all have the same shape connector: don't let the perfect be the enemy of the good.
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.