Yeah, it should work for clis, even now. For larger codebases we just need to get two things right:
- create good plans with the adequate tradeoffs for the type of service
- make sure to have enough lints and tests to verify the completion end to end, either with browser, or with typechecking or like for c++ - complex static analysis.
We're constantly iterating on setup instructions and our repository analyzer, and during the integration we have a set of linters to prevent the model to generate completely broken code - it checks types, compiler errors for starters.
The scope of the integration is explicitly limited, we make sure that the model doesn't do extra stuff.
Yup, that's the plan! We're starting with SDKs to nail code understanding and then we'll add browser tools for traversing web uis as part of integration
For the Camera? You don't want to know, it's a PDF that's in Chinese that for a C++ SDK in Linux!
For my future web stack the biggest chunk will probably be Daily https://docs.daily.co/reference/daily-js (by @kwindla) as the backbone of our teleoperation orchestration
Daily would be easy to add. We can technically add C++ library, but we don't have nearly enough linters in our agent even for me to trust it, so that's a task for the future!
But then you get annoying firmware providers like Broadcom who refuse to write OSS drivers for linux and a lot of work is being spent on the reverse engineering
The amusing thing about that is that broadcom, not Cisco, was the culprit in the original WRT54G GPL violation. Cisco, of course, were legally liable and should have checked that the code they obtained was not encumbered - although the usual way to do that is to specify contractually that your vendor will do the checking. It was a huge issue for them that they had tripped a customer who provided a significant fraction of their revenue into legal difficulties. I suspect that to this day, a big reason that parts of broadcom are reluctant to open-source stuff is because certain executives are still angry about the experience.
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.
Ok, but this should not be a major limiting factor.
From my experience, there is sufficient amount of routers based on well-supported chips which work okay with OpenWRT.
When I consider to buy a new router, I go to the OpenWRT device support page, filter for features I would like to get and choose one of the supported routers listed there.
I gave up on openwrt when I realized that a lot of the recent WiFi standards seem to be badly supported. I think 802.11ac was significantly faster with vendor firmware than openwrt, for example.
> 802.11ac was significantly faster with vendor firmware
Yes, I also remember similar issues with TP-Link Archer C7 running earlier versions of OpenWRT. It got better with later versions when they started supporting some kind of flow off-loading.
I am unsure if at the moment the recent OpenWRT WiFi performance of this router is on par with the vendor firmware's WiFi performance.
But yes, your point is valid. However, I do not consider this kind of issues to be deal-breaking. If I remember correctly, a fair amount of devices can achieve the same performance with OpenWRT as with vendor firmware. I would just check for these potential issues in advance and buy only the devices which are confirmed to be working as fast as with the vendor firmware.
The point here is that I rarely have any preferences as to which brand of a router to buy. Many of the marketed features they offer, like proprietary software or mobile apps to control the router, are mostly irrelevant for me. So I choose primarily based on the OpenWRT support level.
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.
GPU vendors have come to the realization that the in-kernel driver needs to be open-source, but the userspace portion can be closed-source. There's just really no good reason to accept a design where outdated closed-source drivers could keep you from running a current kernel. WiFi NIC vendors have for generations been moving more complexity into the closed-source firmware blob that runs on the NIC's own processor core(s), so there's no good reason for the kernel driver to remain closed-source.
Broadcom has been doing FullMAC designs for over a decade now, and that is exactly what you describe: moving all the functionality into firmware and having thin opensource kernel driver
Congrats on the launch! I’m curious, do you have to store the tool inputs and outputs on the server side while either of the sides are waiting for response? I’m building a specialized coding agent for integrations and I had to avoid stateful api, because I don’t want to store user code.
We tried to keep things simple, so our runner utility class is currently stateless.
However, it's highly extensible, and we can support stateful logic if we wanted to. For instance, we have a cool concept called "Policy" in our SDKs, which is basically a user-defined callback function that is run after each runner step (see our docs for more info). You can build some pretty advanced use cases with this, e.g. executing conditional database calls on a per-step basis.
