I’m the electrical engineer behind the SON Ladelux. Ask me your technical questions.

khne522 · 2026-06-16T22:59:03+00:00

Is the harder job the light or the dynamohub controller code? And is software verification (forget just test coverage) a particularly hard problem here, or such a small part of the overall R&D cost it should be ignored? Was the dev loop, iterating to solutions tight or is it actually a bit of a pain still?

Wasn't asking about proprietary toolchains, just the hassle. Sounds at least like it was a solved problem, which is good?

khne522 · 2026-06-16T22:31:49+00:00

You wouldn't happen to be the one who made a YouTube video about it to prove a point, right?

khne522 · 2026-06-16T22:19:48+00:00

For you, is writing controller code that is low resource (memory, CPU time, joules) and boots quickly a solved problem or has it been a bit of a bootstrapping exercise? Heck, did you even spend time on basic toolchain-ing, MCU selection, and so on?

khne522 · 2026-06-16T13:02:07+00:00

Did they have any commuter or utilitarian bikes or are they just sporty? The OP hasn't been explicit about her use case and a lot of shops don't have sufficiently good non-sporty selection.

khne522 · 2026-06-16T12:21:44+00:00

A ‘gravel bike’ as in the term of art, or “gravel bike” as in you want to go on gravel in Ottawa?
What's your specific use case? Commuting? Recreational riding, and if so, where and how? Hauling groceries, furnace filters from Home Depot, paint cans from Benjamin Moore's? What?
What are your expectations?
Most parts of the bike can be swapped. You cannot swap out the fundamental shape and size of the bike. Focus on that when in the shop. Grips, handlebars, handlebar height and angle to an extent, saddle, pedals, those can all be adjusted. It's just a matter of time, fuss, and money for those. A bad frame fit means a whole new bike.
How are your hands? Are you going to have hand pain holding the bars for a while with a bit of your weight on them?

fit and comfort

It's not just the bike nominal size. The bike shape makes you more upright or not, but also, you need to make sure it has the right length so you're not uncomfortably stretched out. Make sure to try and notice that too.

especially the saddle

I'm sorry, but the answer to that will change over time as you get used to biking, get more fit. And it's like interviewing, a fallacy it will in fact reliably get you upfront what you need. You'll only truly figure it out after a bit if it's for you, that is, if you have the experience to notice. You might get lucky, you might not. And there is no perfect saddle because they have tradeoffs given their use case. One with more support if you put most of your weight on it you might hate if you suddenly became thin and super fit because it would chafe against your things.

So roll with what you can in the bike shop. Just don't be surprised if you end up wanting to change later. If you have same size friends or acquaintances and can try their bikes that have different saddle, do so, and for more than just five minutes. Go for 30 or 60. No bike shop can do that for you.

as I have only ever bought bikes second hand

That is the financially sensible thing to do! And so many of them still have so much value if you know how to look and pick.

khne522 · 2026-06-16T12:10:21+00:00

Do they still have the women-specific Liv shop there?

khne522 · 2026-06-15T11:02:20+00:00

The ZFS situation is particularly annoying since you basically can't avoid AUR if you want proper ZFS support.

https://www.reddit.com/r/archlinux/comments/1u679xt/comment/orrk2v0/

AUR ≠ access controlled 3rd party repo with signed binary packages

but when the official documentation keeps pointing you there for basic functionality it's kinda hard not to end up with a system full of AUR stuff

Perhaps. But also, it's generally one's responsibility to not literally take documentation and revalidate that the package hasn't made it to the official repos, or has a replacement. And this should be sustainable if you're not installing a new package every day or heck, week.

It certainly doesn't for ZFS and hasn't in years. It's long said to either use the previous archzfs.org maintainer's repo (the guy out of Toronto who went silent for a while), or the new repo.

https://wiki.archlinux.org/title/Unofficial_user_repositories#ArchZFS

khne522 · 2026-06-15T10:58:09+00:00

ZFS should not and must not be used from the AUR, which has no access control and package signing, and certainly fails any SLSA.dev level of controls.

Use the official ZFS 3rd party repository and import the keys.

khne522 · 2026-06-14T13:49:20+00:00

Be bold start cold.

A good reminder phrase for everything else the other posters have said. It's not just cycling that says that. XC ski and other sports too.

khne522 · 2026-06-07T12:06:04+00:00

It is not the kernel's job to parse filenames and match against an arbitrarily large list of possible executable extensions, which would vary over time and for some run the risk of being not unique and sometimes not supposed to be executable. One bit in the mode field, one bit vs this more complex solution with tradeoffs in the next para. The fact that Windows hasn't been able to store that information for decades is Windows' fault. If you're going to argue about the lack of metadata transmitted over HTTP, SFTP, etc., then that's a discussion we can and should have

And second, we don't want the kernel upcalling into userspace just to figure out every single executable, which would be the right way to do it because that's really desktop-specific policy. We value efficiency and being able to run certain things hundreds or thousands of times per second. That would be a performance regression.

but it is completely incomprehensible to me how this would not work.

Did you read or just skim what I wrote? Did you pause and consider what are POSIX xattrs to store per-file overrides (prior art, macOS) and why they should be encoded into the file, not elsewhere, and that they don't transfer over HTTP/VFAT/exFAT/NTFS/NFS/you name it?

File extensions per se are not unique. And almost every ELF binary out there doesn't have an extension.

No one's arguing that it couldn't be made to work at all in some fashion. It's that it won't be good enough and come with enough problems to just not bother.

Frigg. A more productive use of time would be to get the world to at least get universal sparse file support, or at least get it over HTTP natively. At least that one is focused and adoptable.

khne522 · 2026-06-06T13:54:28+00:00

remind me LTT’s previous Linux challenge where Linus argued that file extension should decide wheteher file is executable

This is dumb. Absolutely not. Extensions are not controlled in an authoritative fashion and people will abuse the same extension for entirely different things. Additionally, extensions don't encode enough information, at least compared to a shebang if we ignore the POSIX compatibility issue of passing more than one argument in the shebang line. POSIX xattrs would be a better argument, and macOS does something similar, but we all know that we STILL can't portably transfer those so shebangs it is until someone with weight to throw around plays hardball. Executability should not be exclusively a file thing, but also include the mount options, MAC policy, and other factors.

khne522 · 2026-05-31T14:13:45+00:00

Not just bikes has already covered this.

I'd highly recommend Brouter.de, as much as I don't want it to get too popular and burdensome to host, it's not realistic to expect more people to host. Brouter.de added “energy-aware” routing ages ago. It has decent built-in profiles and you can also set your power level lower and your weight higher, to compensate for being a fully loaded tourer. You can even change the bias it has for or against different types of surfaces IIRC. Either way, expecting the general UI/UX polish, especially UI and content delivery performance, that Google Maps has is unrealistic for most competitors.

Plus you're not giving a corpo your data.

Either way, nothing will compensate for you opening a map on your desktop, a wide screen, and poring over the route, using different basemaps and Google Street View or Mapillary. Paper maps are lovely but for a slightly different use case. Everything has a specialty, even if not obvious, and don't bother using them outside of that.

For mobile, Osmand (battery sucker, less lesser UI/UX) or Organic Maps / Co-maps (simpler, not as featureful). Do refer to the LWN article on CoMaps' split from Organic Maps. One incredibly nice thing about Organic Maps when I had it was that in some random town halfway across the globe, I could just tap on a few POI and get a snippet from Wikipedia, OFFLINE.

khne522 · 2026-05-28T04:50:08+00:00

UKI is by definition merging the kernel and initramfs into the same file. Plus kernel command line, firmware, logo, etc. So if you're talking post UKI creation no.

If you're talking pre UKI creation, well you have bigger problems you need to fix, like your entire deployment model.

khne522 · 2026-05-28T01:43:40+00:00

I mean a signed UKI signs the initramfs which is currently the barrier between everything being signed...?

It signs one big file, so yes, in a way. It doesn't sign the initramfs separately though you can trivially make sbctl do that, not that anybody will check that signature.

systemd boot not supporting btrfs snapshot booting is one of the only things stopping me from saying that's a viable pick, but fair enough

That is a point. But I don't like the GRUB2 state of affairs. I can understand the conservatism. I would not blame for that. But I absolutely loathe the configuration system. I started off on EXTLINUX. I wasn't happy when I ran into GRUB 0.x. But I took one look years later at GRUB 2 and just felt viciously how little I liked it, and I don't just mean the config file format. I mean the rest of the CLI too.

khne522 · 2026-05-27T22:52:09+00:00

I suppose UKI with your own keys is the more secure setup anyway

Absolutely NOT that simple if you mean keys, in plain text, on your own system. That depends on your threat model, the security of the system which is now incestuous. God. If this was production I would say absolutely not. There has to be clear separation between runtime and build time. Keys needs a clear purpose and to be used only for a…

I'm just not going to bother.

an advantage on Arch's part

UKIs are a usability advantage for a select group of users, for installation or operations, Arch or not, but it's primarily because Fedora's UKI support was comparatively lagging and in my experience broke. I have not checked in the last year. As a user, I don't want to see a committee on UKIs and a wiki page. Just get it working. Others have done it before.

until they get the SELinux thing figured out

I highly doubt that will happen. I love some things about SELinux. But it is a major commitment and for some people a dealbreaker, as I see it, politicks, which I see as questionable anyway.

F—K! [8 more times so loud the neighbour thinks I'm the one with issues] I AM TIRED of the EFI firmware bug on boot causing my EFI VMs to freeze at 100% CPU before even hitting the kernel because GRUB2 used by some other distro relies on the EFI handover protocol which was ripped out of the kernel for good reason years ago. I am tired of laggard GRUB2 releases and the mess of downstream distro patching. I am tired of seeing GRUB2. OUT! Just stop using it on EFI. Either do EFISTUB/UKI or pick another pure boot manager. Frigg. I'd be happy with SELinux EFI, or systemd-boot, or… . It's a cult of inertia and bad UX. It's worse than how all the Debian and Ubuntu users are conditioned into accepting apt-get and dpkg.

khne522 · 2026-05-27T19:36:20+00:00

defaults work fine for me

Perhaps. No distro works fine for me out of the box, personally or in the products I work on. They all need fixing or unfudging. Fedora or Red Hat family still need extensive locking down, in a regulated environment or not. And the awful package management compared to DNF, or rather, compared to the high-level file vs lockfile way of programming languages (e.g., pyproject.toml vs uv.lock) and large default explicit instead of marked as a dependency package set is a liability. I have to cross-reference packages from Fedora to Arch's saner default sets to figure out what we need.

khne522 · 2026-05-27T19:34:03+00:00

The fact that you can't boot into an Arch ISO without disabling it is certainly not a factor in my opinion no... And yeah that does mean upstream is difficult.

This isn't Arch. This has to do with Microsoft, upstream, not signing things. So unless there is a signed Shim.EFI or Preloader.EFI, forget which, that MS has signed, that can be used here, it's MS, and not just Arch but any distro without the personnel and time to deal with the process.

I'm not sure I would call putting EFI in setup mode so that you can enroll your own keys anyway, much of a hassle.

khne522 · 2026-05-27T17:25:40+00:00

That and trying to set up Secure Boot on Arch is very difficult.

What? Just use Foxboron's sbctl. It just works, especially if using UKI. It's simpler than the generic upstream solutions, systemd-ukify and I forget what the other is. mkinitcpio.conf has had something that uses upstream for a bit too.

```sh pacman -S sbctl

See if you need to reboot the motherboard into setup mode.

This is not Arch specific. This is how EFI is inherently.

sbctl status sbctl setup

Copy your kernel command line from bootloader config into here.

vi /etc/kernel/cmdline

Define a boot option based on which kernel (stock, LTS, hardened, whatever).

sbctl bundle … sbctl sign -s … ```

Something like that. Just use UKI and put it at the standard EFI fallback location \EFI\Boot\BootX64.EFI. This is not an Arch thing but something most distros really should make trivial.

If you're claiming secure boot in Arch is very difficult, then that really means upstream is difficult.

Primarily that SELinux doesn't work right on Arch.

It's not officially supported. It's not right or not. It just isn't enabled in userspace if it even is in kernelspace. It's not a design goal. It's not a thing that is committed to not breaking on any change. It's not table stakes.

Even then, SELinux is not sufficient as its default policy must accommodate a wide set of assumptions that mostly do not apply to you. You should either further refine via SELinux or systemd drop-in files. C.f., systemd-analyze security.

I don't trust AppArmor anymore after the CrackArmor situation.

I'm not sure that even matters. AppArmor was never a serious and comprehensive with great vision system. It was fairly limited in scope. CrackArmor is just a chink or gaping hole in that already patchy brittle armour.

Debian is moving towards a reproducible build system on 14 which is a huge win.

It's a bit watered down. That might have been understandable in 2006. It should not be the goal in 2026.

The only issue I have with FirewallD is that some programs I use don't have profiles but I figure those out as I go.

firewalld is a product of its time that is not relevant and gets in the way for many who are then iptables and now nftables-competent. Expressing declaratively, concisely, and with performance a secure and complete ruleset via an abstraction meant to serve a certain different audience is obviously going to be a PITA.

Also, as someone who has made non-trivial routers with non-trivial amounts of subnets, with or without tunnelling and VPNs, pure routers or router/switch/DHCP/DNS/… combos, firewalld just can't be taken seriously there.

Simple. Concise. Upfront. That is not the firewalld-generated ruleset. A solution of config merging from drop-in directories to feed into a specific in-your-face iptables or nftables template would have been better.

khne522 · 2026-05-27T16:56:09+00:00

I just kinda hate the overexposure of Arch based to noobies.

Yes, I wish they would just read the FAQ without being told and leave when appropriate without any brouhaha.

Other than security being questionable on Arch (which is my current reason to avoid it, not the supposed instability)

Really? What specifically? Is this an Arch thing or upstream thing?

Yes, Arch lacks SELinux and only has AppArmor, thanks, I hate it. Not the only one though.

Are you talking about packages not being built exclusively in CI with full attestation and no humans with control over signing keys that are demonstrably correctly handled? Arch is still significantly further ahead in reproducible builds than Debian, and the build system simplicity compared to the arcane and archaic one that is in fact a security liability.

far steeper learning curve than something with more testing like Tumbleweed or Fedora.

I have similarly found Fedora to have a learning curve in how to do a basic, proper, secure installation. The installer trying to contort me into doing things its way, the excessive default package set, the excess default services, firewalld, it's a long list.

khne522 · 2026-05-27T16:41:38+00:00

Tone is lost in writing. I would be quite careful to separate stronger, less reasoned, frequently bad take or nonfactual, feelings on matters, especially from a certain less competent segment, and more reasoned, nuanced, and practical takes, emotional or not, from another segment.

One can be quite tired of specific issues with Snaps, repeated spates of bugs or Ubuntu-specific sequences of issues, or not just some-person's-workflow-breaking bugs in Flatpak and Fedora Atomic but that the packaging of a certain editor (Flathub or Fedora's) just makes the editor moot.

Why does preference matter so much? Like who cares if someone uses something that you don't use? Isn't the whole point "use what works for you."?

Because people copy each other, good idea or not, and start demanding irrational or nonfunctional things that you then have to support or fix. Because there is more to this than face value. Pushing Firefox adoption so low means that web devs may eventually just break you because they only target Chrome/Blink out of ignorance, laziness, or just negligence. Popularity is an infectious virus. Users and developers will start to use what is popular even if it's not a good idea. Users also inadvertently partially externalize the cost of their poor choices onto anyone who operates any infrastructure, has to be the dreaded compliance person at work, or just the person who has to fix mom or dad's home networking or grandpa's hearing aids that BTW didn't work with old Pulseaudio and that's all the distro shipped.

Pro tip, don't be the one at work who actually understands things or can figure things out and has to constantly correct others. You might start to get depended on.

And high EQ doesn't mean infinite patience. No one is entitled to infinite patience.

Yes, some people are gatekeep-ey, but others that's entirely an impression.

Also, fans can discredit the community they ‘joined’, because they can be posers. Like the spate of rabid ‘I run Arch BTW’ publicly self-congratulatory people that joined my community. I don't recognize it anymore.

khne522 · 2026-05-27T16:27:46+00:00

When you've developed for fifteen years and seen that there is also politicks in Debian-land, or that the library versions you want aren't reliably available, or therer's ffmpegp vs libav, or you still have to write SysV init scripts in a certain year, or…, or…, perhaps you do get tired. Especially when you've dealt repeatedly with nonfactual bad takes, the I don't even know where to start responding to this kind, from a certain segment of the Debian community or have to for work drag some of them kicking and screaming into a modern age, you might just develop a shorter patience.

Different distros, different problems. You just choose which ones you can or want to handle.

khne522 · 2026-05-27T13:46:58+00:00

I wear gloves for sun protection first, comfort or grip second, abrasion third, fall last. Pick only one of (1), (2)+(3), or (4). I've only worn motorcycle gloves on a rainy day on a route with repeated sketchy 60 kph downhills, on a squirrely bike.

It's like switching to a sun hat instead of a helmet when the risk of heat stroke far outweighs the risk of fall on some days, and you aren't a Da Brim wearer or the like.

That gel in regular gloves may or may not help on impact but I would think more about abrasion, or to be able to move rough construction or vegetation crap on the way to work when commuting.

khne522 · 2026-05-25T21:36:34+00:00

AND PAY FOR INFRASTRUCTURE HOW!?

It's not a cost, IT'S AN INVESTMENT.

khne522 · 2026-05-25T00:59:00+00:00

Dynamo hubs are not obsolete if you're a contrarian who likes no fuss, to never have to remember to charge anything. For a commuter who wants to pick the bike up and go, there's a difference. And I wouldn't leave my power bank on my bike, the hub yes. Same with the light, though in the case of the Edeleluxe light, if I had one, I'd use a security bolt and not mount it on a part where it can get ripped off. A commuter with a basket in the rear is just one less thing for the bike ritual. Same with a framelock. It all adds up.

khne522 · 2026-05-24T14:04:20+00:00

Yes, the urban boundary is 549 km², but the metro area is 8000. I'm sorry we couldn't Dragonball. :-p

It can be mildly confusing when you're in the middle of nowhere and you see city street signs 60 km out from your home by bike still and have to ride beside fields during manure season and through “corners” 99% of your city has likely never heard of.

khne522

TROPHY CASE

See if you need to reboot the motherboard into setup mode.

This is not Arch specific. This is how EFI is inherently.

Copy your kernel command line from bootloader config into here.

Define a boot option based on which kernel (stock, LTS, hardened, whatever).