@Bleukitty

Oooooh, hadn't thought of that!

It's a weird time to live in, but not confusing. It's obvious to see that what you really want as a vendor is control over the operating system stack itself, and relying on Microsoft has become challenging.

In essence what NVIDIA is doing is bringing it's entire GPU driver stack open source side, so that entire industries say go on buying tons more hardware.

Us Linux enthusiasts get to reap the benefit, what with entire open source movements bringing libraries to Linux side first that can turn GPU hardware into whatever tool you'd like. Projects like PyTorch and ffmpeg run as first class citizens on Linux.

Windows still relies on either shared DotNet stack (which will make a monkey out of you - cough cough) or the nearly ancient MSYS2 build environment. Microsoft of course prefers you run all that software inside their Linux container system known as WSL - and there's a reason for that.

The Linux graphics stack is looking more "feature complete" by the month, bringing up the question of where you actually get the best hardware support. This is a good question to have.

Now, if only the open source desktop movements could clean house, figure out funding and get their stacks in order, we might finally, for the umpteenth time, maybe see the year of the Linux desktop.

I grow old with anticipation, but seeing what NVIDIA did in the before time versus what they do in the now puts a smirk on this haggered face.

Onwards to the future.

I am on Pop!_OS, I ran sudo apt install cosmic*.

Don't worry, you're not missing out on much, running video games, or any OpenGL thing including 2D games and GPU-accelerated terminal emulators is a bad experience, and alt+f4 isn't implemented, and f11 to fullscreen is janky, and theming for buttons and such is clearly alpha.

The promise of an Arabic-supporting, Rust based, GPU-accelerated terminal is too attractive, however, as I was teared between multilingual terminal, Wezterm, Alacritty and Kitty for a while.

The first is horrible at everything but supporting languages, the second is really janky, the third doesn't support tabs, the fourth has bad theming and customization.

Any "How To" that doesn't just use Rufus isn't worth the page its text is rendered on. Rufus can do Linux boot disks, but is indispensable for Windows boot disk utilities. It's one of the only ways I know of to make a Windows ToGo installation (equivalent of a Linux Live USB), which I used to install Windows on a friends SD card for their Steam Deck so they can dual-boot.

rufus.ie/en/

If you're looking to make a Linux boot USB from Linux itself, BalenaEtcher is probably a better bet since Rufus is Windows-only.

github.com/balena-io/etcher

I've noticed there's tons of how-to's for making a bootable disk on Windows, hardly any for Linux. Perhaps we ought to remedy that?

GitHub - balena-io/etcher: Flash OS images to SD cards & USB drives, safely and easily.

Flash OS images to SD cards & USB drives, safely and easily. - balena-io/etcher

^GitHub

I abhor the idea of things made "for kids". I learned to program when I was 10 on a Commodore 64. And we would wear an onion on our belt which was the style at the time.... Sorry, where was I?

I'd just install a normal distro. Let the kiddo break shit and learn to fix it. Keep backups for recovery and probably isolate the system on your network for if/when kiddo does something stupid. Talk about security, being responsible, etc. We learn through mistakes not by playing in safe walled-gardens.

Last day for public comment: the FDA vaccine advisory committee plans to restrict covid vaccine eligibility to age 65+, require placebo trials (guaranteeing unprotected control groups and vaccines debuting so late they may be irrelevant.)

Given how quickly immunity wanes in the wake of a rapidly mutating coronavirus, which we're now collectively doing nothing whatsoever to slow, that sounds like going back to March 2020 to me.

Comment here before 11:59 PM EDT:
regulations.gov/document/FDA-2…

(ok i see, you're using the term CPU colloquially to refer to the processor. i know you obviously know the difference & that's what you meant - i just mention the distinction for others who may not be aware.)

ultimately op may not require exact monitoring, since they compared it to standard system monitors etc, which are ofc approximate as well. so the tools as listed by Eager Eagle in this comment may be sufficient for the general use described by op?

eg. these, screenshots looks pretty close to what i imagined op meant

now onto your very cool idea of substantially improving the temporal resolution of measuring memory bandwidth...you've got me very interested with your idea 😀

my inital sense is counting completed L3/4 cache misses sourced from DRAM and similar events might be alot easier - though as you point out that will inevitably accumulate event counts within a given time interval rather than an individual event.

i understand the role of parity bits in ECC memory, but i didn't quite understand how & which ECC fields you would access, and how/where you would store those results with improved temporal resolution compared to event counts?

would love to hear what your setup would look like? 😀 which ECC-specific masks would you monitor? where/how would you store/process such high resolution results without impacting the measurement itself? details pls 😁

Eager Eagle

2025-05-23 22:50:34

It seems pcm-memory can do it on Intel CPUs and uProf for AMD.

Other than these I've mostly seen benchmarking and profiling tools (like perf) but I guess these are not what you're looking for.

GitHub - intel/pcm: Intel® Performance Counter Monitor (Intel® PCM)

Intel® Performance Counter Monitor (Intel® PCM). Contribute to intel/pcm development by creating an account on GitHub.

^GitHub

• proprietary server (snap store), unlike flatpak
• snapd only allows one server (but it is foss so you could just patch it), unlike flatpak
• nonexistent security on snap store, multiple times malware, unlike flatpak
• no sandboxing without apparmor and specific profiles, so not cross platform, unlike flatpak
• the system apps are also requiring apparmor, so not cross platform
• they lack granular permission systems afaik
• they concur with flatpak, which is horrible as we need a universal packaging format, not 3
• seemingly no reproducible builds?
• no separation between all, opensource, verified repo, unlike flatpak
• they pollute the mount list with all the loop devices

And people complain abour resource usage etc, but that is just separating apps from the system. Flatpak does the same.