HNHacker News
TopNewBestAskShowJobs

b1temy

116 karma · joined January 12, 2026

submissionscomments
b1temy··on Building Your Own Efficient uint128 in C++
I understand why a non-standard compiler-specific implementation of int128 was not used (Besides being compiler specific, the point of the article is to walk through an implementation of it), but why use

> using u64 = unsigned long long;

? Although in practice, this is _usually_ an unsigned 64 bit integer, the C++ Standard does not technically guarantee this, all it says is that the type need to be _at least_ 64 bits. [0]

I would use std::uint64_t which guarantees a type of that size, provided it is supported. [1]

Re: Multiplication: regrouping our u64 digits

I am aware more advanced and faster algorithms exist, but I wonder if something simple like Karatsuba's Algorithm [2] which uses 3 multiplications instead of 4, could be a quick win for performance over the naive method used in the article. Though since it was mentioned that the compiler-specific unsigned 128 integers more closely resembles the ones created in the article, I suppose there must be a reason for that method to be used instead, or something I missed that makes this method unsuitable here.

Speaking of which, I would be interested to see how all these operations fair against compiler-specific implementations (as well as the comparisons between different compilers). [3]. The article only briefly mentioned their multiplication method is similar for the builtin `__uint128_t` [4], but did not go into detail or mention similarities/differences with their implementation of the other arithmetic operations.

[0] https://en.cppreference.com/w/cpp/language/types.html The official standard needs to be purchased, which is why I did not reference that. But it should be under the section basic.fundamental

[1] https://en.cppreference.com/w/cpp/types/integer.html

[2] https://en.wikipedia.org/wiki/Karatsuba_algorithm

[3] I suppose I could see for myself using godbolt, but I would like to see some commentary/discussion on this.

[4] And did not state for which compiler, though by context, I suppose it would be MSVC?

b1temy··on Defeating a 40-year-old copy protection dongle
> You might think cracking dongles is fun and copy protection is evil, but without protection, our livelihood is affected.

I understand you might feel this way, but it seems to me customers are mostly business clients, who would are more inclined to spare the expense of purchasing said licenses, since they're not personally buying it themselves, and would want to have support and liability (i.e: Someone to hold liable for problems in said software.). In fact, having no copy protection would probably have saved you the problem you mentioned where a dongle breaks and replacement parts are no longer available; this is one of the talking points that anti-drm/copy protection people advocate for, software lost to time and unable to be archived when the entities who made such protections go out of business or no longer want to support older software.

> even on legitimate platforms like Shopee or Lazada.

On a slight tangent, but I personally don't find either platform legitimate (Better than say, wish[.]com or temu, but not as "legitimate" as other platforms, though I can't think of a single fully legitimate e-commerce platform). Shopee collects a ton of tracking information (Just turn on your adblocked, or inspect your network calls. It's even more than Amazon!), is full of intrusive ads, sketchy deals, and scammers. You yourself said you can easily find cracked versions of the dongle there, which doesn't speak well for the platform. And Lazada is owned by Alibaba Group, which speaks for itself. I'm not sure why consumers in South East Asian regions aren't more outspoken about this, since they seem to be the some of the more popular e-commerce platforms there.

b1temy··on Flameshot
I used to really like this software, and I still do. But there were a couple of dealbreakers for me.

1) As others mentioned, Wayland support. But it seems that it's gotten a lot better since I last used it. I resisted using Wayland for a long time because of several software breaking, but I've switched over now that most of the things I use now work (or because I've stopped using things that don't work).

2) it was broken for me with fractional scaling. This is the main reason why I switched, I started using fractional scaling on my second monitor and could not properly fix it for the life of me. I haven't tested it recently, but I just checked, and the github issue seems to still be open. https://github.com/flameshot-org/flameshot/issues/564

b1temy··on Microsoft forced me to switch to Linux
Well, we'll have to agree to disagree here.

You absolutely can design a non-intrusive anticheat that doesn't hook into the kernel layer, and many games do exactly that. They do checks server-side, without hooking into your system. Or design their game to make it harder, eg if a player is behind a wall and can't be seen, don't even send the packets saying there's a player there.

Even with invasive anticheat, any dedicated actor can (and usually eventually do) find ways around it, and it becomes a game of cat and mouse. I feel a similar way about DRM in general.

Imo the tradeoff and danger is not worth it for consumers, but most are just not aware of the risk. Game developers take advantage of this and also do it because it's easier than actually designing their game in a way to minimise cheating (be it through code, or game mechanics)

On a tangent, even though it's for the wrong reasons (Even if I were a full-time user and a fan of Windows, I would not want to install games with invasive anticheat and pollute my system, out of principle), I'm glad that there is at least some pressure and pushback on invasive anticheat by gamers that usually run Windows, just for the reason so that it can run on something like a Steam Deck.

b1temy··on Microsoft forced me to switch to Linux
A few years ago, I would have said that any game that uses such a level of anticheat that makes wine/proton unable to play it (ie: kernel level anticheat) is basically malware and you _shouldn't_ play it anyway, out of both principle, and also because if they had a bug in their code, you're just opening up your device to an unnecessary privilege escalation vector that other malware can abuse to escalate their privileges. (This is not theoretical, this has happened before, eg: with Genshin. Though I believe just the mere existence of a signed driver was enough, since malware can just "Bring your own Driver" (BYOD) and download the driver, at least before it was revoked)

Now, I still hold this belief in most regards. But I do see the appeal, especially if your friends and peers are gamers and actively play these sorts of games, and you feel that you're missing out on socialising or making new friends in that aspect. But there are plenty of other games and consoles, if you could just convince them to switch...

b1temy··on Microsoft forced me to switch to Linux
Similar story here.

Started a new job about a year and a half ago and got a powerful laptop with a really top of the line CPU and GPU, 64 GB of RAM (Now upgraded to 96GB, needed for my work, even with these specs compile times are longer than I'd like...), and it was a terrible experience, coming from someone who's used to Linux having used it for a bit (started in 2013 with Ubuntu with a dual boot. Moved all-in to Arch in 2016, distro-hopped or played with different desktop enviroments/wms after that (Recently switched to niri), but all of which are leagues ahead of Windows 11 IMO. Only occasionally ran Windows on a spare device or a VM on the rare occasion I needed to, eg for work / school.)

Tons of issues, slow in some operations, weird bugs (in the explorer like you, or with my Bluetooth headphones, or other issues), and even occasional blue screens! It's not just my setup too, my coworkers have similar issues. Plus, it just isn't a nice environment to use.

At first, I tried to set up a nicer environment (as much as IT would allow). I installed PowerToys for QOL improvements, GlazeWM to emulate a tiling window manager setup, I tried debloating as much as I can, I installed Wezterm for my terminal (Why is Windows Terminal so hyped up? It seems like an extremely basic terminal emulator to me...), oh-my-posh theming for my shell, and several other things.

But every convenience program I added just noticeably slowed down my laptop, to the point I just gave up some of the niceties and lived with it. Why is such basic functionality able to be run so smoothly on a much weaker device on Linux, but struggle on Windows on a much more powerful device? I can only think of one reason...

b1temy··on The state of Linux music players in 2026
Slint may be of interest to you, which is similar but is allegedly better in some ways. It was also made by former Qt team devs.

http://slint.dev/

b1temy··on AISLE’s autonomous analyzer found all CVEs in the January OpenSSL release
Even if it does have false positives, I expect it would make a nicer starting point for finding and verifying bugs/vulnerabilities, compared to wading through the entire codebase until you find something. Even if it is a false positive, it would probably be due to sketchy looking code (hopefully, unless it hallucinated completely new code) that you can take a look at, and maybe spot something else that the AI didn't catch.

Besides the HN submission, XBOW and Hacktron AI has found plenty of vulnerabilities in code.

b1temy··on OpenSSL: Stack buffer overflow in CMS AuthEnvelopedData parsing
The link in the HN submission contains the same text and excerpt from your link.

Additionally they note: -

"While exploitability to remote code execution depends on platform and toolchain mitigations, the stack-based write primitive represents a severe risk."

IMO, probably in of itself, this alone is not able to do much besides maybe a crash / Denial of Service on modern systems. But it might be able to be used as part of a more advanced exploit chain, alongside other vulnerabilities, to potentially reach remote code execution, though this would be a much more sophisticated exploit and is maybe a bit of a reach. Still, I hesitate to call it impossible on modern systems due to the creativity of exploit developers.

b1temy··on I made my own Git
>... have the OS generate a hash each time the file changes...

I'm not sure I would want this either tbh. If I have a 10GB file on my filesystem, and I want to fseek to a specific position in the file and just change a single byte, I would probably not want it to re-hash the entire file, which will probably take a minute longer compared to not hashing the file. (Or maybe it's fine and it's fast enough on modern systems to do this every time a file is modified by any program running, I don't know how much this would impact the performance.).

Perhaps a higher resolution timestamp by the OS might help though, for decreasing the chance of a file having the exact same timestamp (unless it was specifically crafted to have been so).

b1temy··on I made my own Git
> A timestamp wouldn't be reliable

I agree, but I'm still iffy on reading all files (already an expensive operation) in the repository, then hashing every one of them, every time you do an ls or a commit. I took a quick look and git seems to check whether it needs to recalculate the hash based on a combination of the modification timestamp and if the filesize has changed, which is not foolproof either since the timestamp can be modified, and the filesize can remain the same and just have different contents.

I'm not too sure how to solve this myself. Apparently this is a known thing in git and is called the "racy git" problem https://git-scm.com/docs/racy-git/ But to be honest, perhaps I'm biased from working in a large repository, but I'd rather the tradeoff of not rehashing often, rather than suffer the rare case of a file being changed without modifying its timestamp, whilst remaining the same size. (I suppose this might have security implications if an attacker were to place such a file into my local repository, but at that point, having them have access to my filesystem is a far larger problem...)

> I'm just not that familiar with toml... Though I would argue that the choice doesn't really matter to the user, since you would never actually write...

Again, I agree. At best, _maybe_ it would be slightly nicer for a developer or a power user debugging an issue, if they prefer the toml syntax, but ultimately, it does not matter much what format it is in. I mainly asked out of curiosity since your first thoughts were to use yaml or json, when I see (completely empirically) most Rust devs prefer toml, probably because of familiarity with Cargo.toml. Which, by the way, I see you use too in your repository (As to be expected with most Rust projects), so I suppose you must be at least a little bit familiar with it, at least from a user perspective. But I suppose you likely have even more experience with yaml and json, which is why it came to mind first.

b1temy··on I made my own Git
Nice work, it's always interesting to see how one would design their own VCS from scratch, and see if they fall into problems existing implementations fell into in the past and if the same solution was naturally reached.

The `tvc ls` command seems to always recompute the hash for every non-ignored file in the directory and its children. Based on the description in the blog post, it seems the same/similar thing is happening during commits as well. I imagine such an operation would become expensive in a giant monorepo with many many files, and perhaps a few large binary files thrown in.

I'm not sure how git handles it (if it even does, but I'm sure it must). Perhaps it caches the hash somewhere in the `.git`directory, and only updates it if it senses the file hash changed (Hm... If it can't detect this by re-hashing the file and comparing it with a known value, perhaps by the timestamp the file was last edited?).

> Git uses SHA-1, which is an old and cryptographically broken algorithm. This doesn't actually matter to me though, since I'll only be using hashes to identify files by their content; not to protect any secrets

This _should_ matter to you in any case, even if it is "just to identify files". If hash collisions (See: SHAttered, dating back to 2017) were to occur, an attacker could, for example, have two scripts uploaded in a repository, one a clean benign script, and another malicious script with the same hash, perhaps hidden away in some deeply nested directory, and a user pulling the script might see the benign script but actually pull in the malicious script. In practice, I don't think this attack has ever happened in git, even with SHA-1. Interestingly, it seems that git itself is considering switching to SHA-256 as of a few months ago https://lwn.net/Articles/1042172/

I've not personally heard of the process of hashing to also be known as digesting, though I don't doubt that it is the case. I've mostly familiar of the resulting hash being referred to as the message digest. Perhaps it's to differentiate between the verb 'hash' (the process of hashing) with the output 'hash' (the ` result of hashing). And naming the function `sha256::try_digest`makes it more explicit that it is returning the hash/digest. But it is a bit of a reach, perhaps that are just synonyms to be used interchangeably as you said.

On a tangent, why were TOML files not considered at the end? I've no skin in the game and don't really mind either way, but I'm just curious since I often see Rust developers gravitate to that over YAML or JSON, presumably because it is what Cargo uses for its manifest.

--

Also, obligatory mention of jujutsu/jj since it seems to always be mentioned when talking of a VCS in HN.

b1temy··on The state of Linux music players in 2026
I'm surprised the author didn't list KDE's Elisa: https://apps.kde.org/elisa/ Especially since they referenced KDE when they voiced their wish for Strawberry to be more modernized to match the appearance of KDE's Plasma desktop.

I haven't used it for a while (I generally don't listen to music outside of my drive to work these days), but I remember it being a pleasant replacement for MusicBee when I first switched over to a Linux distro full-time, coming from Windows. The Elisa UI is nice too imo, though it's more of a "native UI" look compared to some of the others in the list, though which style is nicer is up to personal preference.

It may also be a plus to some that it is not using Electron , and uses Qt instead (Well, apparently it uses QML, so still kind-of using ECMAScript/Javascript. But only for the user interface, and not the main business logic.)

b1temy··on This game is a single 13 KiB file that runs on Windows, Linux and in the Browser
> An exception is regedit.exe

This might have changed at some point. I was curious about the latter part of your question on how it made changes without the Windows API (I assumed it used an older DOS API), but my `regedit.exe` _does_ have the `This program cannot be run in DOS mode.` DOS stub in it.

← PreviousPage 2 of 2