haukem

I used the claude-code-action GitHub Action to review PRs before, but it is pretty buggy e.g. PRs from forked repositories do not work, and I had to fix it myself. This should work better with Claude Code Routines. claude-code-action only works with the API and is therefore pretty expensive compared to the subscription.

I think LLM reviews on PRs are helpful and will reduce the load on maintainers. I am working on OpenWrt and was approved for the Claude Code Max Open Source Program today. The cap of 15 automatic Claude Code Routines runs per day is a bit low. We get 5 to 20 new PRs per day and I would like to run it on all of them. I would also like to re-run it when authors make changes, in that case it should be sufficient to just check if the problems were addressed.

Is it possible to get more runs per day, or to carry over unused ones from the last 7 days? Maybe 30 on Sonnet and 15 on Opus?

When I was editing a routine, the window closed and showed an error message twice. Looks like there are still some bugs.

> First of all, there is no process yet for exactly requesting permission, secondly, the army already said they will not enforce the rule unless the Parliament declares combat readiness is necessary, and lastly, there is no punishment for not asking permission at this point in time.

Previously this article 3 was only active in the "Spannungs- oder Verteidigungsfall" which the Parliament has to declare. The law was extended with: "Außerhalb des Spannungs- oder Verteidigungsfalls gelten die §§ 3, 8a bis 20b, 25, 32 bis 35, 44 und 45." so this article is always active now.

OpenWrt accepts binary only firmware running outside of the Linux kernel address space on the wifi chip itself. This matches what upstream Linux also accepts. This works well with most recent Wifi drivers. OpenWrt does not accapt binary only kernel modules or binary only userspace applications, they are very hard to maintain if you do not have the source code.

This works well with Mediatek and also Qualcomm and most other vendors.

I assume that about 20% to 50% of the home routers, Access points and Wifi mesh devices sold world wide are based on OpenWrt. Often some old versions of OpenWrt with many vendor modifications, the UI is always custom.

I know that the main vendor SDKs from Qualcomm, Mediatek, and Maxlinear are based on OpenWrt. I think only Broadcom uses an own Linux distribution which is not based on OpenWrt in their main SDK. Linux has a market share of about 99% in this market, I haven't seen VxWorks in any recent home router or access point.

Sorry, we know that the EU and NA distribution channels are not so good. The OpenWrt project depends on Banana Pi here. There are some resellers on Amazon.

About 10k OpenWrt one units were sold as of today. The first 900 were sold in about 3 days.

Thank you for all the insights.

Nice to know that all supported Pixel phones are not only on the same kernel version, but actually are build fro the same source tree now.

Do you also contribute your fixes back to the upstream projects like the upstream Linux kernel, AOSP or Google?

Many of the security features you are using are already included in AOSP, why does Google not activate them by default? Do they have a different balancing of performance, stability and compatibility on the one side and security on the other? I understand that Google has a different view on privacy for business reasons.

> If we make our own device with an OEM using Snapdragon, we'd have access to most of the sources for their driver libraries/services and a lot of firmware. It's not open source but OEMs have access.

Is it normal that phone OEMs have access to most of the source code of the kernel drivers and user space libraries provided by the SoC vendor.

I worked in the home router business and there it was normal that a OEM gets most of the kernel drivers and user space code in source code, but it was often restricted what they are allowed to publish in source code. Many vendors even published much less than they had to according to GPL and allowed by the SoC vendor.

I have heard that in the smart TV industry OEMs sometimes are only allowed to write an app and have no kernel source code access for their product.

The Raspberry Pi Foundation does not do a good upstream support. It is not very bad, but also not good. They should start adding support for their new chips in the upstream projects before they get into the market, like Intel does it for example. They could add support for some new IP cores, without reveling when and how it will be used later. When the product comes out the only add small patches linking the code together like device tree files.

It would also be good if they would release all the closed source firmware files needed for their devices under a redistributable license in the linux-firmware repository. For some time it was not allowed to redistribute the binary wifi firmware needed for the Raspberry Pi devices. This is needed for Linux distributions to package the binaries.

I hope they do this only because of lack of resources and not intentionally to lock people into their Linux distribution.