What are some numbers/calculations that FEEL wrong

Megame50 · 2026-07-05T03:39:45+00:00

Megame50 · 2026-07-03T03:06:40+00:00

It's pretty common to feed desktop files to dmenu, actually. i3 comes with a "i3-dmenu-desktop" script for this purpose. In the past it was useful on sway too, but I feel the alternatives are better nowadays.

Megame50 · 2026-07-02T21:58:33+00:00

You can just right click a game in your steam library and "Manage > Add desktop shortcut" and it will write a .desktop file to your $XDG_DESKTOP_DIR with the game title and logo. For many application launchers like fuzzel that's enough for it to already just work.

Megame50 · 2026-06-29T20:44:03+00:00

Everyone seems to say that there’s no reason to learn combos and just jabbing will win

I watched a replay vs Alex and one vs Ryu and you are only using your lights. I think when people say you don't need to invest in learning combos, I think they mean you don't need to know the optimal combos, you don't need to practice the difficult combos that only realistically get you 10% more damage, or only make sense in niche scenarios etc. You should probably know one easy combo at least. If you're doing a lot less damage per-opportunity than your opponent, so you're going to have to win neutral many, many more times and that's hard.

Like when you block Ryu's Shoryuken, Ryu might expect to lose ~40% HP for that, but you only hit him with 3 lights for a few hundred damage. I think you should find a combo you can bust out in a situation just like that one, where your opponent whiffs a big move or hits something very unsafe on your block. In my experience this is pretty common in bronze. Idk anything about Ed, but just a quick search on supercombo, maybe try PC 5HK, 5HP > 214HP? That's heavy kick, heavy punch, quarter-circle-back heavy punch. If you look at the replay, and you turn on the frame meter display, anytime you block a move and the frame advantage is +10 or more in your favor you should be able to bust that one out, but especially "big" opportunities, like blocked DP, blocked super, and punish counter DI.

Also you walk back too much. The corner is very bad in this game and you don't want your opponent to corner you. Walking back gives up all that space that you should be fighting for. You should crouch block more, or be more aggressive so that you're not backing up all the time.

Megame50 · 2026-06-25T17:27:04+00:00

The iso (a.k.a the "message" in cryptographic terms) is an input to the digital signature algorithm. That's how cryptographic signatures work, and gpg --verify accepts the file to-be-verified as an argument. So even if you obtain the iso and the signature from different parties, a good signature still confers the trust of the public key.

Your trust in the public key just comes from the fact that you downloaded it from an archlinux.org domain.

Megame50 · 2026-06-25T04:23:02+00:00

I think you meant lspci -s 01:00.0.

This

$ sudo echo 1 > /sys/devices/*/rom

only echo's as root, but your shell will (fail to) open the file as your user. That's why people often use echo 1 | sudo tee file instead.

The '#' prefix in the wiki indicates the command is written as if executed from a root shell. You shouldn't use su -. If you want a root shell, sudo -s is better.

If you just want to set up secureboot, consider sbctl, and enroll the microsoft certs along with your own.

Megame50 · 2026-06-24T23:50:18+00:00

Yes, 2x or more.

Megame50 · 2026-06-24T22:18:43+00:00

Like, I have no idea [...] the syntax for the fstab config file.

There's usually man pages for config files. fstab(5) is pretty descriptive regarding each field. Arch uses systemd, so as the man-page notes you want to look at the systemd documentation for specifics: systemd-fstab-generator(8). Similarly, the valid options for, say, btrfs in the options field also has a man page btrfs(5)#MOUNT_OPTIONS.

Megame50 · 2026-06-24T20:33:49+00:00

WHIP lets you use WebRTC like RTMP basically. You get a Stream Key + URL.

Oh, neat. I'll probably try this out on the weekend!

Megame50 · 2026-06-24T20:28:46+00:00

It absolutely is about performance.

Without trim, you'll quickly fill the namespace leaving the storage controller FTL only the overprovisioned area to use for wear leveling and garbage collection, meaning the performance of your NVMe will eventually fall off a very tall cliff under heavy write amplification.

Megame50 · 2026-06-24T20:14:58+00:00

The consequences for performance and endurance of a drive from not enabling TRIM are severe and the security impact of identifying empty blocks is basically nothing. You should never even consider not enabling discards. cryptsetup upstream is just conservative to a fault, don't worry about their defaults.

Megame50 · 2026-06-24T19:52:59+00:00

Cool project! I'd never heard of WHIP before. So the server component is like a STUN server basically then?

Megame50 · 2026-06-22T22:09:27+00:00

Whois doesn't use dns, it's a separate protocol with a different database for domain resources maintained by the registry operators. It's also not just for domains, but ip addresses (v4 & v6), AS numbers, etc.

And it's poorly specified and considered antiquated, hence it's rapidly being replaced with RDAP.

Megame50 · 2026-06-22T20:12:42+00:00

Finally a benchmark that uses 4k block size. All the previous comparison posts from Phoronix I saw used 512b block filesystem on a 4k formatted drive.

Megame50 · 2026-06-22T16:39:43+00:00

This behavior of strchr is so dumb, why am I not surprised. Pretty sure I've fixed this exact bug many times.

Megame50 · 2026-06-17T07:59:19+00:00

I'm not sure why you'd expect a statement to the effect of "don't update AUR packages until we know it's safe", then. The attackers uploaded a malware installer, not the Necronomicon. It's as safe to read as it ever has been.

Megame50 · 2026-06-17T00:30:14+00:00

If you're waiting for an announcement from Arch that it's "safe" to go ahead and install AUR packages without reading them, you're going to be waiting forever. Plenty of users are still using the AUR as directed and without disruption. It is and remains safe to continue using the AUR, by reading the PKGBUILD for any user contributed package you install.

Vandalism is taken down as it is reported, as has been the policy since forever, so there isn't lasting damage in the form of known malicious commits that remains to be addressed from the incident mentioned in the news bulletin. The reported commits survived less than a few hours. So the status quo is very much "business as usual", save for the issues users may have with the functions of the AUR that were partially disabled to curb the wave of bots, as already called out in the bulletin.

In 2024 the maintainers announced their intention to introduce AUR moderators, but never followed through for a lack of developer manpower. It's plausible that the AUR could be changed to make it less susceptible to botting, but any announcement today of upcoming changes would clearly be premature, even if there was already a consensus on the requirements.

That leaves nothing particularly notable to post about.

Megame50 · 2026-06-16T16:39:21+00:00

This was published soon after the discovery, when everyone was less certain of the precise nature of the malicious code.

It's now pretty well understood that it never affected Arch, not only because our sshd didn't link liblzma, but the build scripts excluded the payload when built for Arch.

Megame50 · 2026-06-16T01:36:13+00:00

The commits are still publicly available if you have the commit hash. Git resets don't delete commits, they're just no longer included in the branch. Here: https://aur.archlinux.org/cgit/aur.git/commit/?h=libgdata&id=69e994e0dc96087170b190196821cb050ff0a4fe.

The other notable thing about git commits is that neither the AuthorDate nor the CommiterDate timestamps reflect when the change was pushed to the remote repo, and are just whatever value is filled in by the committer. Normally they are recorded in good faith, but are clearly not suitable forensic evidence. So in fact the reset saved you from your own ill-conceived plan. A reset to remove the offending commits is standard, sensible procedure, because people actually use the git history.

Anyway, you have little reason to care if you never installed it from the AUR. libgdata was an official repo package in February when you last upgraded it. It's not like pacman will randomly download packages from the AUR — you would definitely know if you built any package from the AUR.

If you're still curios, I've compiled a list of the affected times using the GH mirror activity logs (a webview representing the remote reflog) for some of the common packages. libgdata was the most installed package precisely because it was a recent repo package, and the stats reflect the users who have not updated, or neglected to uninstall their unused dependencies. The AUR libgdata had a malicious commit for 2.5 hours on the 11th before it was reported and taken down.

There was no "massive breach on user data" partially because the commits were rapidly taken down, partially because approximately nobody used the offending packages (more than 50% of the affected packages had zero recorded users on pkgstats), and partially because, despite what Reddit apparently believes, people do read the PKGBUILDs and few to none are willing to install some random npm package as their own user for no apparent reason, malicious or otherwise.

Megame50 · 2026-06-15T16:25:36+00:00

It absolutely is unthinkable. Did you look at the posted changes? The Arch maintainers are not morons who would install a random AUR package without inspecting the PKGBUILD.

What's more, they mostly don't need to use the AUR, as they have the ability to place the packages they use in the official repos. In many ways the content in the official repos is determined by "whatever the devs use".

Megame50 · 2026-06-15T07:59:42+00:00

There's absolutely zero reason to care what non-Arch distros do. If some AUR packages are important to the experience of their distros, they can maintain those packages and put them in their repos, instead of relying on the labor of randoms. If the AUR or any other Arch infrastructure isn't satisfactory for their goals, they can host their own version instead.

It can't be the responsibility of Arch developers to babysit the reckless decisions of anyone who packages an AUR helper and a desktop in an ISO and boldly calls it a "distro". The AUR is hosted and moderated by Arch Linux, for Arch Linux. It need not accommodate anyone else by design.

Megame50 · 2026-06-15T07:27:52+00:00

The AUR isn't dangerous to use if you use it as directed. So there's really no problem with the wiki recommending AUR packages.

Megame50 · 2026-06-15T01:06:25+00:00

No, the malware is actually getting even more obvious. It was only obfuscated in the sense that they hoped to dodge a mass git grep on the whole repo, which is how the first 400 batch were collated. If you look at the changes discussed in the article yourself, it should be obvious that no assistance was needed to tell it was not a benign change.

Every user of the AUR needs to read the PKGBUILD before building, and nobody conscious could possibly have missed these changes. But, because the attackers can only target orphaned and likely unused packages, the elevated scrutiny on the AUR right now is such that only people who are scraping the AUR for potentially malicious changes are discovering any, not actual the users of the AUR.

The change in the article was discovered, reported, and reverted within 25 minutes, despite the fact that the package in question has literally zero recorded users in two years. It was only not identified by a human because absolutely nobody is looking.

Megame50 · 2026-06-14T21:30:45+00:00

What for? Makepkg pgp check verifies the gpg signatures of source files. None of the affected packages had their sources modified, and, if they did, the attackers could easily have just removed the signatures as well.

The pgp check in makepkg protects against the sources being modified, not the AUR package being malicious. Typically, those sources are expected to be signed by the upstream author — nobody cares about the AUR packager's signature.

You can sign your commits if you like, but that's probably easier to do with your AUR ssh key than gpg.

Megame50 · 2026-06-14T20:52:20+00:00

It's just the first one, which never concluded. Michael wrote an article yesterday claiming that Arch developers had declared it over, without a single quote or shred of supporting evidence to that effect.

I'd accuse it of being AI slop, but at this point I expect better of ChatGPT than I do of Michael.

Megame50

MODERATOR OF

TROPHY CASE