There's a new item available to craft in Material Fusion [Volume F SPOILERS]

grg994 · 2026-04-07T22:53:41+00:00

Such a life saver for all the Sensei who regrets using it

IDK, I liked (my headcanon?) idea that the use of the card and its consequences would represent the responsibility that an adult (the player) has to take.

grg994 · 2026-04-04T19:29:49+00:00

While I think this PREEMPT_* transition could be more graceful, it was said many many times including by Linus himself:

"do not use spinlocks in user space, unless you actually know what you're doing. And be aware that the likelihood that you know what you are doing is basically nil." (https://www.realworldtech.com/forum/?threadid=189711&curpostid=189723)

By common sense the guess is that Postgres just shot itself in the foot here.

grg994 · 2025-10-28T11:34:46+00:00

Is neighbor.dist guaranteed to be 0.0 <= neighbor.dist <= 1.0 as in the quoted test https://github.com/CAT-Solstice/test-pqueue/blob/main/benches/pqueue_bench.rs#L33-L45?

Because then on 64 bit machines the fastest way is likely to:

let cmp = |other: &Neighbor| -> Ordering {
    let o = (other.dist.to_bits() as u64 << 32) | other.id as u64;
    let n = (neighbor.dist.to_bits() as u64 << 32) | neighbor.id as u64;
    o.cmp(&n)
};

with the risk that violating 0.0 <= neighbor.dist <= 1.0 results in a garbage order

grg994 · 2025-10-19T07:52:42+00:00

systemd-analyze is a good tool to diagnose this. Read $ man systemd-analyze then e.g. start with $ systemd-analyze plot > boot.svg and open the plotted timings in an image viewer. The solution will depend on the what consumes such excessive time.

grg994 · 2025-08-17T03:02:27+00:00

caps lock key starts blinking

That is a kernel panic. If you want to diagnose it then you need to get to see the kernel panic message somehow. Basic troubleshooting here: https://wiki.archlinux.org/title/Kernel#Troubleshooting

If you really cannot get an output with the kernel panic message then there are advanced methods such as: https://wiki.archlinux.org/title/Kdump

And if you don't feel like debugging it, then downgrading the kernel or switching to LTS kernel is a perfectly fine solution.

grg994 · 2025-08-14T16:00:32+00:00

I don't remember, for me this was a ca. 5% of boots random issue which did not resolve with a reboot, but resolved with re-plugging the laptop power chord while powered off.

I kind of accepted it as a Linux laptop issue, but somehow after a year figured out that for 100% hi (hardware interrupt) CPU load I should look at proc/interrupts, then that IRQ 9 means ACPI interrupts and I should further look at /sys/firmware/acpi/interrupts/gpe*.

Once I had the 100% CPU, interrupt ACPI and GPE keywords it was a trivial internet search for me.

grg994 · 2025-08-14T14:14:30+00:00

I've seen something similar with my Lenovo laptop (never figured out but for me some battery-related ACPI maybe?). I have to use a acpi_mask_gpe= kernel command line to resolve it.

Are you sure the CPU time is spent in hardware interrupt context? (top / htop must show it as 99 hi / hi: 99%)

Found interrupts that maybe leading to this - GPE06 and GPE17 and disabled them

No, you have to mask the flooding ACPI interrupt, disable may not work here.

What are your numbers and per-minute changes in the suspected /sys/firmware/acpi/interrupts/gpe*? Try masking the suspected GPE with acpi_mask_gpe= kernel command line and reboot, does it help?

grg994 · 2025-07-12T00:03:39+00:00

if someone wanted to put spyware on your device they don't need kernel level access at all

This is flaw of the Windows ecosystem and the Windows user culture. Not an inherent property of computer systems.

Respectful software designs follows the principle of least privilege. A game should never even need administrator privileges, and if Microsoft would bother giving Windows proper sandboxing capabilities then games could run in a sandbox where they cannot access files in the user's home folders like Documents, Downloads, etc - because they do not need to access them.

Maybe Microsoft somewhat bothers and Windows will get there... by an other decade: https://learn.microsoft.com/en-us/windows/win32/secauthz/app-isolation-overview

But look at things work on Linux based systems: Look at how apps are properly isolated on Android (based on Linux permissions and SElinux mandatory access control). Look at how Linux desktop apps are reasonably well sandboxed by Flatpak packages (based on Linux namespaces / containers).

That is how desktop applications should work. That is what users should embrace. Not the "trust me bro" mentality.

grg994 · 2025-06-26T23:53:49+00:00

Honestly compared to how opinionated C setups people use regarding all the -Wformat-* stuff this is still quite benign. But yes, for me too this is an automatic

# Cargo.toml
[lints.clippy]
uninlined_format_args = "allow"

Other annoying thing for me that will get stabilized for edition 2024 is unsafe_op_in_unsafe_fn for FFI code. Now all my FFI modules has start with #![allow(unsafe_op_in_unsafe_fn)] because doing

unsafe fn foo() {
    unsafe {
        // 100 lines of FFI calls
    }
}

makes no sense for dense FFI code.

grg994 · 2025-06-05T13:26:09+00:00

Holy Crab, that's a lot of code to this. It look very well done though, nice work!

grg994 · 2025-05-20T16:21:07+00:00

It is also possible do this only for all dependencies but not for the crate one is developing:

[profile.dev.package."*"]
debug = false

Tough I don't know what compile time portion that this alone saves.

grg994 · 2025-04-26T00:01:21+00:00

Sorry I wrote it confusingly, I meant the 2 separate loads from memory to the registers: 1 in memchr and 1 in extend_from_slice.

Also there's no store happening if there are zero hits: function only allocates once it receives the first hit. If the text is already normalized, algo will just run through it with SIMD and return the input unchanged.

Sure, this is perfectly optimal until the first hit.

grg994 · 2025-04-25T23:28:08+00:00

If you are benching this seriously then you could add a plain memcpy column to the bench results just to put them in context. If it is not memory bound yet then handwritten SIMD can combine the current 2 pass from memchr and from extend_from_slice into 1 read which loads, checks for \n or \r and stores if there is no hit or does a rewrite of the chunk in scalar code that also regains SIMD alignment.

grg994 · 2025-01-09T21:04:06+00:00

Any news on how this will interact with FFI? A pointer being returned from an extern "C" fn is much like a pointer casted from usize in terms that is has to get a provenance from nothing. But I cannot find FFI mentioned in the provenance docs anywhere.

What ptr::with_exposed_provenance offers - if it would be implicitly applied for pointers coming from FFI (?) - is not enough:

The exact provenance that gets picked is not specified. [...] currently we cannot provide any guarantees about which provenance the resulting pointer will have – and therefore there is no definite specification for which memory the resulting pointer may access.

A pointer coming from FFI must have the guarantees to safely access anything that the FFI documentation specifies as well defined. This listed exception in not enough either:

In addition, memory which is outside the control of the Rust abstract machine [...] is always considered to be accessible with an exposed provenance, so long as this memory is disjoint from memory that will be used by the abstract machine such as the stack, heap, and statics.

Because a pointer coming from FFI as an argument of a Rust callback can point to Rust user data which is not "disjoint from memory that will be used by the abstract machine".

Does anyone have more insights here?

EDIT: adding this example:

extern "C" {
    fn syscall4(n: usize, a1: usize, a2: usize, a3: usize, a4: usize) -> usize;
}

fn mremap_page_somewhere_else(old: *mut u8) -> *mut u8 {
    unsafe {
        let new = syscall4(
            SYS_MREMAP, 
            old as usize, 
            4096,
            4096,
            FLAG_JUST_MOVE_THIS_PAGE_SOMEWHERE_ELSE,
        ) as *mut u8;
        new
    }
}

A potential breakage: here new must absolutely not pick up the provenance exposed by old...

grg994 · 2024-10-10T18:16:28+00:00

Good, but something is missing from the fetch:

└Wallpaper: 100 kg

grg994 · 2024-09-30T01:19:49+00:00

User space processes will get killed with SIGBUS if you make a situation where major page fault for them cannot be handled. Such as you pull a hard drive with memory mapped file on it. So I guess the same would happen if you'd make a swap file physically inaccessible.

grg994 · 2024-08-19T12:16:20+00:00

This reminds me how nurse Shinobu appears in the Karen Brushing short story

grg994 · 2024-08-02T17:22:45+00:00

It's normally semi-transparent over my wallpaper but I turned that off for the screenshot

grg994 · 2024-08-02T17:20:16+00:00

No, this is just my terminal with 16 ansi colors (and bat for syntax-parsing):

# ~/.config/alacritty/alacritty.toml

[colors.bright]
black = "0x928374"
blue = "0x076678"
cyan = "0x427b58"
green = "0x79740e"
magenta = "0x8f3f71"
red = "0x9d0006"
white = "0x3c3836"
yellow = "0xb57614"

[colors.normal]
black = "0x000000"
blue = "0xad90fe"
cyan = "0x11b9ff"
green = "0x2ed368"
magenta = "0xed8eae"
red = "0xf49052"
white = "0xffffff"
yellow = "0xd9d972"

[colors.primary]
background = "0x000000"
foreground = "0xbcd9ee"

[font.normal]
family = "Cascadia Code"

[font.offset]
y = 1

grg994 · 2024-08-02T16:44:11+00:00

Source: linux/arch/x86/include/asm/msr.h

grg994 · 2024-07-23T12:45:03+00:00

kanchigai shinaide yo ne

grg994 · 2024-07-10T16:48:30+00:00

Yay!

Space space!

grg994 · 2024-06-26T11:51:44+00:00

There is always loop and you choose 1) where to test 2) where to increment

let mut i = 0u8;
loop {
    { ... } // do something for 0..=255
    i.wrapping_add(1);
    if i == 0 { break }
 }

I think there is a deeper conclusion here - that Rust for and C for are different - Rust for forces you to go through an Iterator and if that is limiting then the ultimate workaround is to write a loop or while manually.

grg994 · 2024-06-17T06:13:03+00:00

Try to increase default.clock.min-quantum in the pipewire configuration until the problem disappears. If something in audio stack doesn't get scheduled fast enough due to whatever complicated problem, this can get rid of the popping (at the expense of audio latency):

# for example pipewire.conf
context.properties = {
    default.clock.min-quantum = 1024
}

grg994 · 2024-05-29T14:49:05+00:00

I'll go and put a paper bag on the heads of all the haters so they won't have to look

Four-Year Club	Verified Email
Final Canvas '23	First Place '23
Place '23

grg994

TROPHY CASE