HackerTrans
TopNewTrendsCommentsPastAskShowJobs

haukem

no profile record

comments

haukem
·3 mesi fa·discuss
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.
haukem
·3 mesi fa·discuss
> 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.
haukem
·3 mesi fa·discuss
It is very likely this was done intentionally. Maybe not all people involved in making this law noticed it, but the person working on article 2 did this intentionally. They explicitly list that this article is always active now:

> (3) Außerhalb des Spannungs- oder Verteidigungsfalls gelten die §§ 3, 8a bis 20b, 25, 32 bis 35, 44 und 45.

https://www.gesetze-im-internet.de/wehrpflg/__2.html
haukem
·3 mesi fa·discuss
The article 3 of the Wehrpflichtgesetzes says this:

> (2) Männliche Personen haben nach Vollendung des 17. Lebensjahres eine Genehmigung des zuständigen Karrierecenters der Bundeswehr einzuholen, wenn sie die Bundesrepublik Deutschland länger als drei Monate verlassen wollen, ohne dass die Voraussetzungen des § 1 Absatz 2 bereits vorliegen. Das Gleiche gilt, wenn sie über einen genehmigten Zeitraum hinaus außerhalb der Bundesrepublik Deutschland verbleiben wollen oder einen nicht genehmigungspflichtigen Aufenthalt außerhalb der Bundesrepublik Deutschland über drei Monate ausdehnen wollen. Die Genehmigung ist für den Zeitraum zu erteilen, in dem die männliche Person für eine Einberufung zum Wehrdienst nicht heransteht. Über diesen Zeitraum hinaus ist sie zu erteilen, soweit die Versagung für die männliche Person eine besondere – im Bereitschafts-, Spannungs- oder Verteidigungsfall eine unzumutbare – Härte bedeuten würde; § 12 Absatz 6 ist entsprechend anzuwenden. Das Bundesministerium der Verteidigung kann Ausnahmen von der Genehmigungspflicht zulassen.

See: https://www.gesetze-im-internet.de/wehrpflg/__3.html

This was not changed.

The article 3 of the Wehrpflichtgesetzes was previously only active in a war or close to war situation (Spannungs- oder Verteidigungsfall). Article 2 said this before:

> § 2 Geltung der folgenden Vorschriften

> Die §§ 3 bis 53 gelten im Spannungs- oder Verteidigungsfall.

See: https://github.com/bundestag/gesetze/blob/master/w/wehrpflg/...

Now it says this:

> § 2 Anwendung dieses Gesetzes

> (1) Die nachfolgenden Vorschriften gelten nach Maßgabe der folgenden Absätze.

> (2) Die §§ 3 bis 52 gelten im Spannungs- oder Verteidigungsfall.

> (3) Außerhalb des Spannungs- oder Verteidigungsfalls gelten die §§ 3, 8a bis 20b, 25, 32 bis 35, 44 und 45.

> (4) Die §§ 15a und 16 sind nur auf Betroffene anzuwenden, die nach dem 31. Dezember 2007 geboren sind. Satz 1 gilt nicht im Spannungs- oder Verteidigungsfall.

See: https://www.gesetze-im-internet.de/wehrpflg/__2.html

This law changed it: https://www.recht.bund.de/bgbl/1/2025/370/VO

Is the a up to date git repository with all German law changes? The one I found was last updated 4 years ago.
haukem
·3 mesi fa·discuss
I am also surprised that I haven't read about this in German news before. I am following the news. If Trump would have signed an executive order with a similar content affecting US citizen, German media would probably report about this multiple days long with many articles.

I was looking in Google news for other reports about this, but only found an article from Berliner Zeitung published 5 hours after this article from Frankfurter Rundschau.

I am worried about what other information which could be important to me, the news did not report on.

As far as I understood the law the article from FR is correct: https://www.gesetze-im-internet.de/wehrpflg/__3.html
haukem
·10 mesi fa·discuss
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.
haukem
·10 mesi fa·discuss
MediaTek chips are well supported by OpenWrt. Broadcom is not good supported. Mainline Linux kernel supports recent MediaTek Wifi chips quite well [1]. MediaTek is also working on these upstream Linux drivers, but they still have a proprietary Linux driver in addition.

Also the rest of the recent MediaTek SoC is supported quite well by upstream Linux and OpenWrt.

You can run OpenWrt on recent MediaTek SoCs with all code running on the main CPU being open source, no closed source code needed inside the Linux kernel address space or in user space. The chips need firmware running directly on the IP cores. It needs a firmware running on the wifi core itself, there are probably one or more CPUs inside the wifi cores doing real time stuff. The Ethernet PHYs also need a firmware which is running on the PHY.

[1]: https://elixir.bootlin.com/linux/v6.17-rc5/source/drivers/ne...
haukem
·10 mesi fa·discuss
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.
haukem
·10 mesi fa·discuss
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.
haukem
·5 anni fa·discuss
Intel does this all the time, but they want normal Ubuntu, RedHat and so on to support their hardware when their hardware gets into the market. With these phones the hardware and the software is shipped together in a bundle, it is a different thing.
haukem
·5 anni fa·discuss
I haven't see this as a problem, but I am working for a consumer network equipment semiconductor company. I haven't worked with graphics drivers which could be different. Normally we get the driver code from Cadence and Synopsys under a permissive license, it can be integrated in what ever you want. The documentation and especially the RTL is under strict NDA.

This driver code is often very self contained and does not use many or any Linux frameworks, it should be easy to integrate it into any operating system in any way. Normally you have to rewrite the driver code you get from Cadence and Synopsys to get it integrated in upstream Linux, because it does not meet the upstream Linux guidelines. This is a general problem with the out of tree drivers you get from the semiconductor industry.

There are also big players in the semiconductor industry which demand that every code inside the Linux kernel they ship has to be under GPL for legal compliance.

There is also not a single bad guy in the semiconductor industry which prevents upstream Linux support. Every player could do it, Google probably got most of the drivers in source for their Pixel phones and could have upstreamed them, but most of them probably need a rewrite. They could have offered Qualcomm some money to port support for the SoC used in a Pixel phone to a more recent major kernel version, I am pretty sure Qualcomm would have done it for the right amount of money.