Hacker News: lpribis

New comment by lpribis in "Git commands I run before reading any code"

lpribis — Wed, 08 Apr 2026 12:16:51 +0000

I was curious what information I could glean from these for some popular repos. Caveat: I'm primarily an low-level embedded developer so I don't interface with large open source projects at the source level very often (other than occasionally the linux kernel). I chose some projects at random that I use.

*Mainline linux*

Most changed files: pretty much what I expected for 1 and 2... the "cutting edge" of Linux development over other OSes -- bpf and containers. The bpf verifier and AMD GPU driver might get a boost in this list due to sheer LoCs in those files (26K and 14K respectively). An intel equivalent of amdgpu_dm is #21 in the list (drivers/gpu/drm/i915/display/intel_display.c) and nvidia is nowhere to be seen (presumably due to out-of-tree modules/blobs?).

    186 kernel/bpf/verifier.c
    174 fs/namespace.c
    162 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
    161 kernel/sched/ext.c
    159 fs/f2fs/f2fs.h

Bus factor: obviously none. The top 4

    10399 Christoph Hellwig -> I only know his name because of drama last year regarding rust bindings to DMA subsystem
     8481 Mauro Carvalho Chehab -> I also know his name from the classic "Mauro, shut the fuck up!" Linus rant
     8413 Takashi Iwai -> Listed as maintainer for sound subsystem, I think he manages ALSA
     8072 Al Viro -> His name is all over bunch of filesystem code

Buggy files: Intel comes out on top of GPU drivers this time (twice). Along with KVM for x86(64), the main allocator, and BTRFS.

    1477 drivers/gpu/drm/i915/intel_display.c
    1406 MAINTAINERS
    1390 sound/pci/hda/patch_realtek.c
    1102 drivers/gpu/drm/i915/i915_drv.h
     943 arch/x86/kvm/x86.c
     928 mm/page_alloc.c
     871 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
     862 drivers/gpu/drm/i915/i915_reg.h
     840 fs/btrfs/inode.c

*GCC*

Most changed files: IR autovectorization code, riscv heuristics tables, and C++ template handling (pt.c is "paramaterized types").

    152 gcc/tree-vect-stmts.cc
    145 gcc/config/riscv/riscv.cc
    131 gcc/tree-vect-loop.cc
    116 gcc/cp/pt.cc

Buggy files: DWARF debuginfo generation, x86 heuristics tables, RS6000(?!) heuristic tables. I had to look up RS6000, it's an IBM instruction set from the 90s lol. cp-tree.h is an interesting file, it seems be the main C(++) AST datastructures.

   1017 gcc/dwarf2out.c
    885 gcc/config/i386/i386.c
    796 gcc/cp/cp-tree.h
    740 gcc/config/rs6000/rs6000.c
    720 gcc/cp/pt.c

*xfwm4* Most changed files: the list is dominated by *.po localizations. I filtered these out. Even after this, I discovered there is very little active development in the last few years. If I extend to 4 years ago, I get: 1. src/client.c - Realizing this project is too "small" to glean much from this. client.c is just the core X client management code. Makes sense. 2. src/placement.c - Other core window management code.

This has not told me much other than where most of the functionality of this project lies.

Bus factor: Pretty huge. Not really an issue in this case due to lack of development I guess.

    3298  Olivier Fourdan
     530  Anonymous
     319  Xfce Bot
     121  Jasper Huijsmans

Files with bug commits: Very similar distribution to most changed files. Not enough datapoints in this one to draw any big conclusions.

I think these massive open projects (excl xfwm) are generally pretty consistent code quality across the heavily trodden areas because of the amount of manpower available to refactor the pain points. I've yet to see an example of "god help you if you have to change that file" in e.g. linux, but I have of course seen that situation many times in large proprietary codebases.

New comment by lpribis in "C89cc.sh – standalone C89/ELF64 compiler in pure portable shell"

lpribis — Fri, 03 Apr 2026 11:38:08 +0000

I don't think any realistic system will bootstrap C from shell. What is the shell implemented in if not C?

New comment by lpribis in "Writing my own text editor, and daily-driving it"

lpribis — Wed, 11 Mar 2026 23:39:28 +0000

He implied replacing nano was the first step, before using it for more complex (software development) tasks. First use it just for quick one-off edits of /etc/blah.conf then graduate to using it for longer editing sessions.

New comment by lpribis in "Google API keys weren't secrets, but then Gemini changed the rules"

lpribis — Thu, 26 Feb 2026 08:43:47 +0000

Rather than being about fast/simple/cheap, I think using SSN as a key was more about the fact that SSN is the only common identifier that almost all US citizens have.

New comment by lpribis in "Things Unix can do atomically (2010)"

lpribis — Fri, 06 Feb 2026 22:03:58 +0000

Sure, but splitting "atomic" operations across a reboot is an interesting design choice. Surely upon reboot you would re-try the first `mv a b` before doing other things.

New comment by lpribis in "IPv6 is not insecure because it lacks a NAT"

lpribis — Wed, 21 Jan 2026 10:48:09 +0000

This is local to the device though. Nothing to do with the WAN. Would still work even on the "serverless" ipv6 network.

New comment by lpribis in "The Z80 Membership Card (2015)"

lpribis — Thu, 15 Jan 2026 11:13:34 +0000

The Z80 instruction set lives on via the eZ80, Z180 and others which are binary compatible with the original Z80 instruction set. Unfortunately Zilog stopped making the 40 pin DIP package a couple years ago so yeah this specific board will be hard to source. You can still find them on gray market, mostly ones that have been desoldered from existing boards.

Even if you made a version of this board with the footprint changed to the QFP eZ80, it probably wouldn't work because the eZ80 has different memory mapping and clocking differences.

New comment by lpribis in "Dell admits consumers don't care about AI PCs"

lpribis — Fri, 09 Jan 2026 01:40:08 +0000

Really, the best we can do with the NPU is a less battery intensive blurred background? R&D money well spent I guess...

New comment by lpribis in "Kidnapped by Deutsche Bahn"

lpribis — Mon, 29 Dec 2025 15:36:29 +0000

They can't realistically do this in Germany because the tracks are so much more busy than the US. There would more than likely be a train coming the other direction within the next few minutes, and they cannot guarantee all the people have time to vacate the track area.

New comment by lpribis in "Fabrice Bellard Releases MicroQuickJS"

lpribis — Wed, 24 Dec 2025 08:55:41 +0000

TCO is not just for parse trees or AST, but in imperative languages without TCO this is the only place you are "forced" to use recursion. You can transform any loop in you program to recursion if you prefer, which is what the author does.

New comment by lpribis in "Common Lisp, ASDF, and Quicklisp: packaging explained"

lpribis — Thu, 11 Dec 2025 08:53:24 +0000

Don't forget about UIOP (Utilities for Implementation and OS Portability) which is part of the ASDF project. Also very easy to type!

New comment by lpribis in "How Google Maps allocates survival across London's restaurants"

lpribis — Thu, 11 Dec 2025 08:42:57 +0000

Sample of 1, but the hidden gem near me I would actually consider a "hidden gem" that only people from the area know about, and it's a very good family run business.

New comment by lpribis in "DRAM prices are spiking, but I don't trust the industry's why"

lpribis — Wed, 26 Nov 2025 20:00:56 +0000

> Following the plea agreement he was sentenced to 8 months in prison and fined US$250,000.[6] Lee was subsequently promoted to President of Samsung Germany in 2009, and then President of Samsung Europe in 2014.

Lmao he got rewarded for taking the fall.

New comment by lpribis in "Shai-Hulud Returns: Over 300 NPM Packages Infected"

lpribis — Mon, 24 Nov 2025 12:24:20 +0000

99% of releases do NOT fix zero-days. But 100% of releases have a small risk of introducing a backdoored build-script.

There's nothing wrong with pinning dependencies and only updating when you know for sure they're fixing a zero-day (as it will be public at that point).

New comment by lpribis in "Giving C a superpower: custom header file (safe_c.h)"

lpribis — Mon, 17 Nov 2025 22:31:08 +0000

Yes but "atomic" operations with the DMA engine are accomplished through interrupts (atomic) or memory mapped IO configuration (atomic).

New comment by lpribis in ".NET 10"

lpribis — Wed, 12 Nov 2025 22:35:41 +0000

> All you would guess is there are probably 9 others that were just like it.

Lol, even this is not true. For the current runtime/stdlib package known as ".NET", they started numbering at 5. The actual sequence (only counting major version numbers) is: .net framework 1, 2, 3, 4, .net core 1, 2, 3, .net 5, 6, 7, 8, 9, 10. Easily the worst naming/version history for any product (worse than Windows).

New comment by lpribis in "Recursive macros in C, demystified (once the ugly crying stops)"

lpribis — Thu, 06 Nov 2025 08:56:45 +0000

The CPP does allow quite advanced metaprogramming, it's just so obtuse to use and requires insane hacks so almost nobody does. See one of my favorite projects https://github.com/hirrolot/metalang99

New comment by lpribis in "Hard Rust requirements from May onward"

lpribis — Sat, 01 Nov 2025 18:54:27 +0000

The unfortunate reality is that you must write almost all of your drivers from scratch if you want to rust in embedded. There is no OEM driver support, and as you said the open source drivers are all crap and written for arduino-level hobby projects.

Lack of drivers is prohibitive if your are a small/medium team or are using a lot of complicated peripherals or SoC. Compare to C where any MCU or embedded SoC or moderately complex peripheral normally comes with C driver code.

New comment by lpribis in "Minecraft HDL, an HDL for Redstone"

lpribis — Thu, 30 Oct 2025 22:18:07 +0000

This compiler does not support sequential logic, meaning no flip flops/registers.

New comment by lpribis in "StageConnect: Behringer protocol is open source"

lpribis — Sat, 18 Oct 2025 10:02:49 +0000

It's already common to put digital data over XLR in stage environments, like DMX lighting and AES3. Also venues will have an XLR snake but definitely not a TRS jack snake from stage to mixer.