Yep, aware of that. I've watched it evolve over many years… from static management → `devfs` → `udev`. `udev` was introduced around 2005 so… initially it used plain `tmpfs`, but then they made `devtmpfs` as a hybrid of `devfs` and `tmpfs`; some default nodes were seeded by the kernel then `udev` did the rest.
`udev` initially started as a helper script that the kernel executed, later they also added a comms channel using netlink sockets.
Small embedded systems often have to cut niceties that make life easier, but they also have the luxury of a more fixed hardware configuration.
NetBSD has, from what I've seen, not made that same journey. I'm not suggesting that the way Linux has done it, is the way NetBSD *should* do it either. `udev` rules are obscure to debug, with a very bespoke domain-specific language describing the configuration file format. Not a fan of this approach … but that doesn't mean there aren't ideas that could be carried across.
An Intel NUC isn't a small embedded system: it is a desktop computer. I'm trying to do the sort of "desktop computer" tasks that I typically do with a "desktop computer".
Sometimes this means I have a few USB serial adaptors plugged in, and I'd rather address them by serial number through a symlink, than have to faff around with `dmesg` to figure out which one is which and manually edit configuration files to adapt to the order they enumerated.
Stuart Longland (VK4MSL)
npub12n…d9dex
2026-07-26 06:52:54 UTC
in reply to nevent1q…tk93
Author Public Key
npub12n5weher8thl0qlj398tvw2rmwpr33z8j443lpg28xyuzkef9dksnd9dexPublished at
2026-07-26 06:52:54 UTCEvent JSON
{
"id": "2d11069051766d581c1385d9a35d96ef498f0f278f0d9146fc1e8800ece41b2a",
"pubkey": "54e8ecdf233aeff783f2894eb63943db8238c447956b1f850a3989c15b292b6d",
"created_at": 1785048774,
"kind": 1,
"tags": [
[
"p",
"ddb62c796b1efe18b04bb841a12dba2aa2d65489a3fccce4a507b3ce787777da"
],
[
"p",
"54e8ecdf233aeff783f2894eb63943db8238c447956b1f850a3989c15b292b6d"
],
[
"e",
"3fd9debd32c9324cac1a5765aeb4f0c23c05a8af725d8777a51260e488ffcc88",
"",
"root",
"54e8ecdf233aeff783f2894eb63943db8238c447956b1f850a3989c15b292b6d"
],
[
"proxy",
"https://mastodon.longlandclan.id.au/@stuartl/116984956501313237",
"web"
],
[
"e",
"f710395ff75e5ec036a48771f43e18f4f1973177208f28ed997efe56d040a105",
"",
"reply",
"ddb62c796b1efe18b04bb841a12dba2aa2d65489a3fccce4a507b3ce787777da"
],
[
"proxy",
"https://mastodon.longlandclan.id.au/users/stuartl/statuses/116984956501313237",
"activitypub"
],
[
"L",
"pink.momostr"
],
[
"l",
"pink.momostr.activitypub:https://mastodon.longlandclan.id.au/users/stuartl/statuses/116984956501313237",
"pink.momostr"
],
[
"-"
]
],
"content": "Yep, aware of that. I've watched it evolve over many years… from static management → `devfs` → `udev`. `udev` was introduced around 2005 so… initially it used plain `tmpfs`, but then they made `devtmpfs` as a hybrid of `devfs` and `tmpfs`; some default nodes were seeded by the kernel then `udev` did the rest.\n\n`udev` initially started as a helper script that the kernel executed, later they also added a comms channel using netlink sockets.\n\nSmall embedded systems often have to cut niceties that make life easier, but they also have the luxury of a more fixed hardware configuration.\n\nNetBSD has, from what I've seen, not made that same journey. I'm not suggesting that the way Linux has done it, is the way NetBSD *should* do it either. `udev` rules are obscure to debug, with a very bespoke domain-specific language describing the configuration file format. Not a fan of this approach … but that doesn't mean there aren't ideas that could be carried across.\n\nAn Intel NUC isn't a small embedded system: it is a desktop computer. I'm trying to do the sort of \"desktop computer\" tasks that I typically do with a \"desktop computer\".\n\nSometimes this means I have a few USB serial adaptors plugged in, and I'd rather address them by serial number through a symlink, than have to faff around with `dmesg` to figure out which one is which and manually edit configuration files to adapt to the order they enumerated.",
"sig": "c5bfa16c78cddccc99379efbb19ccb5d470bb9541e968d5141433fb11d6438da8947f19cb07f394a9a9815888966ff7353058133574e33e6e68d35a1131c3ee9"
}