Hacker News: accelbred

New comment by accelbred in "Why I love NixOS"

accelbred — Mon, 23 Mar 2026 16:48:19 +0000

The lock file is the major feature I'm missing.

New comment by accelbred in "Why I love NixOS"

accelbred — Sun, 22 Mar 2026 20:35:18 +0000

Does guix have a flake equivalent yet?

New comment by accelbred in "Don't post generated/AI-edited comments. HN is for conversation between humans."

accelbred — Wed, 11 Mar 2026 20:42:10 +0000

These days, I've noticed that lobsters feels a lot more genuine to me, like hn was a few years ago. These days it feels like hn is bland and homogeneous, which I suspect is due to LLM-written comments.

New comment by accelbred in "Give Up GitHub – Software Freedom Conservancy"

accelbred — Sun, 08 Mar 2026 06:59:43 +0000

Moving mostly to codeberg was a simpler affair than I expected. It's been a breath of fresh air. Its like github without the gamification, ads, copilot, and social features.

New comment by accelbred in "Ladybird adopts Rust, with help from AI"

accelbred — Mon, 23 Feb 2026 20:26:33 +0000

Its for the time being is stuck with LLVM, so I can't currently LTO with GCC objects. Its got a lot higher complexity than I perfer in a language. A lot of features I find important seem perma-unstable. Pin is unnessesarily confusing. No easy way to define multiple compilation units for use with linker object selection and attribute constructor. The easy path is downloading binary toolchains with rustup and not using your disto package manager. You can't use unstable features without the bootstrap env var on distro rust toolchains. Cargo leads to dependency bloat. The std/core crates are prebuilt binaries and bloat binary sizes. Bindgen doesn't translate static inline code. The language has a ton of stuff it exposes just to std and not user code. Unsafe code is unergonomic. No easy way to model a cleanup function that needs more args. No support for returns_twice. No ability to use newer stuff like preserve_none. Can't go-to-definition from a bindgen binding to original header file. Macros pollute global namespace. Can't account for platforms where size_t and uintptr_t are different. Traits can only be relied on if marked unsafe. Can't implement something like defer since it holds a borrow. no_std code still can pull in core::fmt. Can't enforce dependencies are also no_std. Panics are considered safe. No way to add non-function fields to dyn vtables. No way to declare code separately from definition. No way to have duplicate type definitions that merge, making interop between different bindgen generated modules annoying.

New comment by accelbred in "Ladybird adopts Rust, with help from AI"

accelbred — Mon, 23 Feb 2026 19:39:34 +0000

Its possible to dislike Rust but pragmatically use it. Personally, I do not like Rust, but it is the best available choice for some work and personal stuff.

New comment by accelbred in "Man accidentally gains control of 7k robot vacuums"

accelbred — Mon, 23 Feb 2026 01:49:21 +0000

Isn't Eufy the one that marketed fully local smart cameras that actually just streamed to the cloud unencrypted?

New comment by accelbred in "C and Undefined Behaviour"

accelbred — Mon, 09 Feb 2026 02:47:46 +0000

I think you are entirely missing the author's point. The author is generalizing from the specific technicalities of C/Rust/etc UB, to the problem with UB which is that should it be triggered, then you can't know what the program will do. This does not have to be the result of language specification. If writing safe Rust yourself, yes no UB will occur usually, and you can know what will happen based off of what code you wrote. The author extends UB to vibecoding where there is no specification to understand the translation of prompts to code. Without thorough review, you are unable to be sure that the output code matches the intent of your prompting, which is analagous to writing code with UB. The issue the author has with vibecoded Rust is not that the code can trigger undefined behavior at the language layer, but that the perfectly "safe" code generated may not at all match the intended semantics.

New comment by accelbred in "Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust"

accelbred — Tue, 03 Feb 2026 20:08:08 +0000

I wouldn't want hooks modifying the code. They should be only approve/reject. Ideally landlock rules would give them only ro access to repo dir

New comment by accelbred in "C Is Best (2025)"

accelbred — Tue, 06 Jan 2026 19:58:05 +0000

The amount of paranoia I need for unsafe Rust is orders of magnitudes higher than C. Keeping track of the many things that can implicity drop values and/or free memory, and figuring out if im handling raw pointers and reference conversions in a way that doesn't accidentally alias is painful. The C rules are fewer and simpler, and are also well known, and are aleviated and documented by guidelines like MISRA. Unsafe Rust has more rules, which seem underspecified and underdocumented, and also unstable. Known unknowns are preferable over unknown unknowns.

New comment by accelbred in "Rust--: Rust without the borrow checker"

accelbred — Mon, 05 Jan 2026 01:48:02 +0000

The code I have in C is often code that does't fit in Rusts safety model. Dealing with ffi is annoying because slices have no defined layout. `dyn` is limited compared to what I can do with a manual vtable. I have seriously attempted porting my personal stuff to Rust, but theres enough papercuts that I go back to C. I want the parts of Rust I find to be helpful without those parts I don't.

New comment by accelbred in "Rust--: Rust without the borrow checker"

accelbred — Thu, 01 Jan 2026 20:18:30 +0000

For me its everything being an expression, macro_rules, dyn, automatic conversions (the few that it does have), traits, and the ? operator.

New comment by accelbred in "Rust--: Rust without the borrow checker"

accelbred — Thu, 01 Jan 2026 19:28:29 +0000

I've been thinking of writing a language with Rust's ergonomics but less of the memory safety stuff. I prefer using no dynamic allocations, in which case the only memory safety feature I need is leaking references to locals into outer scopes. As for the thread safety stuff, most of my stuff is single-threaded.

New comment by accelbred in "Meta is using the Linux scheduler designed for Valve's Steam Deck on its servers"

accelbred — Tue, 23 Dec 2025 17:37:17 +0000

CFS was replaced by EEVDF, no?

New comment by accelbred in "Linux Kernel Rust Code Sees Its First CVE Vulnerability"

accelbred — Thu, 18 Dec 2025 05:04:43 +0000

The kernel policy for CVEs is any patch that is backported, no? So this is just the first Rust patch, post being non-experimental, that was backported?

New comment by accelbred in "Interview with Kent Overstreet (Bcachefs) [audio]"

accelbred — Wed, 17 Dec 2025 02:12:51 +0000

As far as I can tell, the only missing feature for me to try to switch to bcachefs is fs-verity.

New comment by accelbred in "It seems that OpenAI is scraping [certificate transparency] logs"

accelbred — Mon, 15 Dec 2025 19:16:17 +0000

Seems like you could set up a cert for a honeypot domain to collect ips of bots running off of the certificate transparency logs. If domain isnt linked from anywhere, then its pretty sure to be a bot isn't it?

New comment by accelbred in "Rust in the kernel is no longer experimental"

accelbred — Thu, 11 Dec 2025 02:35:48 +0000

That would be possible but also make its usage unergonomic and not the experience customers are expecting when requesting a Rust API.

New comment by accelbred in "Rust in the kernel is no longer experimental"

accelbred — Thu, 11 Dec 2025 02:33:49 +0000

Arenas aren't the issue. Its objects with mixed lifetimes and mutability. I cant easily model the lifetimes of objects when there are cases like an instance where buffer memory reachable from the object has a different lifetime than maps/lists. Also these objects could be transively shared or mutable. In order to make a Rust friendly model, I'd have the tree be all shared or all mutable, and have all reachable memory have the same lifetime. This would often mean allocating the full tree into one arena. That is where the overhead comes from. Each arena would need enough memory to store the entire object; currently they can be smaller since they often only need to hold parts of objects, not the entire thing.

New comment by accelbred in "Rust in the kernel is no longer experimental"

accelbred — Wed, 10 Dec 2025 21:21:48 +0000

That works for functions. For datatypes that are used throughout the API, it does not work so well.