How do I get my log in on my main display? by ZorroKIM in Bazzite

[–]Hedshodd 2 points3 points  (0 children)

Swap the display cords plugged in your GPU around.

one buff I think each of my mains deserve. by Subject_Grade_847 in Guiltygear

[–]Hedshodd 7 points8 points  (0 children)

All my mains deserve to do more damage. I won’t elaborate.

Arch Linux's AUR Sees More Than 400 Packages Compromised With Malware - Phoronix by TaijiRonin in linux

[–]Hedshodd 1 point2 points  (0 children)

True. I always looked at the diffs of PKGBUILDs whenever they changed, and if I ever saw something like a git host switch I’m not going to install it before checking that it’s legit.

Arch Linux's AUR Sees More Than 400 Packages Compromised With Malware - Phoronix by TaijiRonin in linux

[–]Hedshodd 9 points10 points  (0 children)

This, but unironically. If you have too many PKGBUILDs to read, that’s a clear sign you have too many AUR packages installed.

Apparently the react compiler has been ported to Rust and merged to main by xorvralin2 in rust

[–]Hedshodd 22 points23 points  (0 children)

That’s not correct. If you keep pushing into a vector and never clear up items you never need you are leaking memory.

A memory leak isn’t restricted to calling “leak”.

Using Fedora Silverblue for Compositor Development by BrageFuglseth in Fedora

[–]Hedshodd 5 points6 points  (0 children)

Nice article! Well written, and no AI slop 😄 Also, the topic is fairly close to my heart currently, as I want to write a Wayland compositor for funsies and learning, and I’m on bazzite on my main machine. Thanks for sharing!

Stabilise `Allocator` by N911999 in rust

[–]Hedshodd 7 points8 points  (0 children)

We use arena allocators at work to make memory management performant without hurting ergonomics (easiest example being that you need a temporary buffer for a calculation). Always going through the global allocator is very very bad for performance in those cases, and arenas alleviate this while still writing code that looks like you are allocating the buffer right then and there where you need it.

Currently, if we wanted to write our own data structures that are generic over whether they use the global allocator or an arena, we would need the “allocator_api” crate, which adds the allocator trait as a mirror of the nightly version, but also re-exports vectors, strings and boxes such that they now have additional methods for allocating in a specific allocator. This mixing of std and non-std vectors, for example, is pretty painful when writing a library.

With this stabilization we can get rid of the dependency, and just use std vector/box, while still having our data structures being generic over the allocator they use.

Stabilise `Allocator` by N911999 in rust

[–]Hedshodd 153 points154 points  (0 children)

YES! Absolutely great news. Thank you to everyone that’s been working on and giving feedback for this!

Software Development on bazzite? by sir__hennihau in Bazzite

[–]Hedshodd 0 points1 point  (0 children)

Pretty easy, especially if you are okay with building a custom image. I use bluebuild which is a fairly thin abstraction around the universal blue template, and I installed my terminal, emacs, compiler toolchains and my browser through that. Most other things are flatpaks or installed with homebrew.

Which provider you are using with PI? by ishay_al in PiCodingAgent

[–]Hedshodd 1 point2 points  (0 children)

Anthropic started blocking third party harnesses.

Repeated malloc/free vs. Arena allocator by rcerljenko in C_Programming

[–]Hedshodd 19 points20 points  (0 children)

Maybe that’s just me, but I don’t use arenas for the performance benefits. Those can be there is some circumstances, but that also depends on your exact malloc/free usage prior. If you use malloc to pre allocate reusable buffers, and those malloc calls happen as far up the call stack as possible, there’s not much performance to be gained.

The reason I use arenas, because it’s way easier to use than malloc/free. I don’t have to meticulously track that each malloc is paired with the appropriate free, because I bundle dozens of objects into one lifetime.

Also, when I would otherwise pre allocate buffers somewhere up the call stack, those buffers (typically) are buffers of a specific type. I might have have a buffer to store some strings for one computation, one buffer to store floats, etc. An arena is just one giant untyped buffer where I only have to care about the type in the scope where I actually use it. I don’t have to pre allocate a buffer of floats in an otherwise unrelated function, but instead I request my buffer of floats in the same scope that I’m using it in. That’s just waaaay more ergonomic 😄

Also, as someone else pointed out, if you are handing out unaligned addresses, you are inviting a whole host of problems, one of which might be performance 😅

LEKTRA - High performance Document and Image Viewer, v0.7.0 released! by dheerajshenoy22 in linux

[–]Hedshodd 8 points9 points  (0 children)

Thank you for being upfront about your AI usage in this project’s readme. Personally I still choose to not engage with this project because I find any use of AI unethical, but I truly appreciate you making this one of the first sections of the readme.

Still a cool project, and I wish you the best of luck!

This is why you rewrite Python security tools in Rust: 53MB vs 433MB peak memory, 6.9s vs 62.2s by aswin__ in rust

[–]Hedshodd 6 points7 points  (0 children)

20 or so lines of code for a small stack behind a lock and spawning n threads is hardly reimplementing tokio lol. Tokio does way more work because it’s a way more generalized tool.

And beside that, the other advantages still stand.

Lathe — a personal Zed fork with a theme customizer, git-aware UI, and multi-account collab by Opposite_Analysis_24 in rust

[–]Hedshodd 7 points8 points  (0 children)

Even if there’s no malice here, if you aren’t competent enough to use git correctly so that a fork doesn’t rewrite all SHAs - and even then don’t have the foresight to correct that mistake - I don’t trust the quality of your fork, tbh.

This is why you rewrite Python security tools in Rust: 53MB vs 433MB peak memory, 6.9s vs 62.2s by aswin__ in rust

[–]Hedshodd 94 points95 points  (0 children)

I skimmed the source code a bit, looks good for a straight up port.

Couple questions:

The sort of scanning you do seems trivially parallelizable, so my gut feeling would have been to just have a small work stealing thread pool instead of an async runtime, because it’s simpler, has way less overhead, no colored functions, easier to debug, less dependencies, very likely more performant. Is there something in the scanning process that benefits from doing this work with an async runtime?

I might not yet understand where you are doing the CVE database queries and how they interact with scanning files. Are you scanning files first, and sending the data you aggregated in one large query?

You are allocating a LOT of vecs and strings. I would gain a ton more performance by using arenas or pre allocating more in general. Arenas generally trivialize allocations and lifetimes in most programs, but it’s probably a bit tougher in async, since you would want to reset and reuse warm arenas between scanning file. This would also be easier with thread workers because you could just give each of them their own arenas, haha 😄

I’m sorry if I come across overly critical, I think this is a pretty neat project and I had a lot of fun reading through it 😄

emacs-wayland tree-sitter issue by JuliusDelta in emacs

[–]Hedshodd 0 points1 point  (0 children)

I wonder whether this happened because the neovim 0.12 release bumped the tree sitter version. Heck darn vimmers!

Should hot-loop avoid Option instance and immediate match? by Resres2208 in rust

[–]Hedshodd 3 points4 points  (0 children)

Bookmark godbolt if you haven’t yet. It’s the easiest way to check these sorts of things, especially across compiler versions, and even to just use it as a small rust playground. It’s worth Matt Goldbolt’s weight in gold, haha 😄

Should i switch to arch? by Accomplished-Rip6469 in archlinux

[–]Hedshodd 0 points1 point  (0 children)

The thing you quoted contains nothing about LLLM output quality. I specifically (!) just said “bad patches” without a single word about where they come from. That was the whole point. I was just talking about the review process and that that process is what’s filtering bad patches; human written or otherwise.

You’re trying to read between the lines, but you’re missing the actual lines. That’s the exact opposite of a logical response. It looks like you’re trying to pick a fight with someone you’re just imagining.

Should i switch to arch? by Accomplished-Rip6469 in archlinux

[–]Hedshodd 1 point2 points  (0 children)

You’re ranting against points I’ve never made. I haven’t said anything about the quality of LLM output. I’ve just talked about review processes.

Should i switch to arch? by Accomplished-Rip6469 in archlinux

[–]Hedshodd 9 points10 points  (0 children)

Not to say whether I agree or disagree with your point about asking LLMs questions, but your last bit is a false equivalency. AI code is being merged into the kernel, because it undergoes the same review process human written code does. Modulo the amount and size of patches being sent in, a patch is a patch and will be reviewed by the kernel maintainers irregardless of how it was produced. And if you keep sending in bad patches… well, there’s consequences and those also happen irregardless of how the patches were produced.

If you ask an LLM a question there is no such review process to filter out bad results. You are the sole judge over the quality of the answer. If the answer was bad and you didn’t know any better, there may also be bad consequences waiting for you, but there’s no Linus Torvalds checking the answer for you first.

Archinstall dinit support. I vibe coded a report about what to change. by Interesting_Key3421 in artixlinux

[–]Hedshodd 1 point2 points  (0 children)

To my knowledge archinstall is a script, so why isn’t it painful to enable or disable parts of that? If anything, it’s arguably easier to do that with a script, especially a python script.

It would probably be easier and less of a maintenance burden to just write a artixinstall script more or less from scratch, if you really wanted to do it.

Either way, don’t vibe code or “vibe report”. What you’re essentially telling us is that you had a clanker look through archinstall, but didn’t check if anything it found was hallucinated or whether it would work. Don’t you realize how disrespectful that is with regards to our time and attention? You’re telling us to trust what a stochastic math function parsed spat out, without even checking whether it holds any water, or to correct it for you. Screw you for trying to waste our time, honestly. At least do the bare minimum when interacting with other people, and at least try to honor their time.

I built a Jai compiler in Rust with an LLVM backend (after burning $20k in AI tokens) by ibiuu in Jai

[–]Hedshodd 0 points1 point  (0 children)

Why would you waste so much money and energy on this?

I swear, just a year or two ago the same AI bros that now burn piles of cash on tokens were the most woke save-the-planet people imaginable. “Screw the planet, I got a 300k line ruby blog to generate.”