> most of the bugs were in the JS code, so for most things, hot reloading is enough for E2E validation and to run just the right tests. No need to run a full build and test suite (which takes 10+ minutes); the CI can do this.
Have you tried adding this instruction to your agents.MD? Avoiding situations were the agent start running a loop is the main use case of the file for me
I'm guessing the greatest reason behind each provider creating and agent harness is that (a) there is not a clear winner still and (b) it is harder to switch models with a competitor, as you also have to switch harness
Or by using a proxy, yeah. Personally I would still prefer a multi provider harness over CC when using it with another provider, if alone for the visible reasoning, model switcher, cost estimation and so on. So far I've only preferred CC when I needed to work with Jupyter Notebooks because it has built-in tools for that.
Aside from LLM architecture, that already is a complex issue, an issue is that training data is unstructured text.
An LLM able to structurally separate context and instructions, should logically need separated data to train, and we don't have it.
Moreover, while an equally powerful LLM architecture solving this may exists, there are no guarantees at all that we are able to come up with it in a reasonable timeframe.
Without some signals moving in that direction, the most pragmatic and realistic way of looking at the problem is that it will not be solved in the near future
I agree this doesn't mean we shouldn't try to address limitations with the current architecture. I just mean that I expect the root cause to be solved eventually if we ever really want to take steps towards AGI.
User identity attached is not a solution, it doesn't solve anything if you have to pull in external data that you can't control.
Like in the banking world, you can make everything super authenticated, but if you have an API that receives the latest wire transfer YOU received with the message attached, you don't control the message content and it can be an attack vector.
Being authenticated/authorized is not the solution, it is data that the user can access.
Aren't small local models worse efficiency-wise? It means that every person must have a powerful enough machine to power a small model, and we are very, very far away from that.
The best solution, from an efficiency point of view, is to use smaller models on datacenters, requiring much less of them.
There's an efficiency sweet spot where hardware that people have anyway gets a higher percentage of load.
MacBooks have a lot of memory and a lot of FLOPs. They mostly sit unused all day. Yes, the excess energy use will be higher than a GPU in a datacenter doing the same work, but you have to generate an absurd amount of tokens before the dollar-efficiency catches up with the MacBook.
I still don't see solutions on how a normal person can become a mantainer though.
If all relevant open source projects close up their contributions, you can't enter the project anymore from an external point of view.
Almost all open-source public figures started by being interested in a project and submitting PR to it, until eventually either joining the project as core mantainer or creating a separate open source project. The path is now closed, and I don't see a way in, outside of creating a popular open source yourself
> how a normal person can become a maintainer though.
Is the goal to produce high-quality software, or is the goal to produce an apprenticeship scheme for developers who are interested in the project but not so interested that they are willing to write an email to introduce themself or otherwise engage in normal human social interactions?
Normal people will still be able to get involved if they want to, just like normal people can get jobs. You learn about the organization you’re interested in joining, you try to meet some people and introduce yourself, you gain trust and prove your worth. It can be true that a pull request once embodied some of these tasks, but it is not true that being unable to submit a request means that these tasks are no longer possible to perform. It just means you’ll have to do them differently, just like the rest of humanity does when they want to get involved in an organization.
>Normal people will still be able to get involved if they want to,
there isn't much evidence that this is happening. When you eyeball the average age of maintainers on mailing lists these days for prominent open source projects like the linux kernel, it's been steadily creeping up, to somewhere in the 50s now I'd guess. There's a complete dearth of people in their 20s or even 30s in particular in positions of responsibility, there's no next generations of leaders.
That's fatal in the long run. You need to have an apprenticeship system or something like a vocational pipeline to engage people in a structured way so that you can produce talent and also be objective and systematic. Something like a guild system you have in the DACH region where companies survive centuries, and that's not because random people write mails, it's because there's a industry wide support system and training process.
Yes but that predates AI & projects rejecting pull requests, so I would argue this is a separate unrelated phenomenon. If anything, the fact that despite accepting PRs, most projects have little new blood, means that PRs were rarely a significant pathway for future maintainers.
The path is not closed; it must be earned through trust. It has always been this way. Also, note that "pull requests" are a GitHub invention; the concept is not native to Git or most other SCM systems. Before, you would have to submit your patch by email. It would be reviewed by the "maintainer" (or BDFL), who would then accept or reject it. If your contributions are accepted several times, you may be able to earn the rank of "maintainer."
Returning to the topic at hand, the challenge for new developers is to earn trust. I bet there are ways to do so aside from the muddy swamp of GitHub's (AI) bazaar.
In this case they seem to be firmly closing the path though
> There will not be a separate process for submitting patches by other means. We do not want to create a shadow contribution system through issues, comments, email, or forks. External code can of course exist under the terms of the license, but we will not treat forks or patch dumps as a review queue for upstream Ladybird.
This does raise the question on how they are going to get new maintainers. The only thing I can think of is by active outreach to people contributing to adjacent projects that are still open. But that does not seem ideal to me as that will not yield people specifically interested and caring for the project you invite them to.
They don’t even have an alpha product yet. This used to be called vaporware but I’ll give them the benefit of the doubt that something will come in the future and they’re just focusing on fixing their own crappy code.
The amusing thing is that emailed patches and a listserv aren't actually all that different from github pull requests at the end of the day. In either case you're sending some code you wrote along to a group and asking them to look over it. The only real difference is the lack of a familiar web interface that's uniform across all projects and reduces friction to near zero, but emailing a patch hardly adds much friction in practice.
I think the primary difference is that it removes some of the incentive to status seek because there's no centralized network operator tracking contributions and displaying them on your profile for others to look at.
That said, the linked post explicitly says that Ladybird won't be accepting emailed patches, reviewing changes from downstream forks, or anything else. Hopefully that's not the case since entirely closing off the project would probably be an overreaction as well as jeopardize its future.
It’s really different because there’s no public signal between the email and the project itself. You can maybe search the log and see your patch, but there’s no central identity where you can brag about it. At most you can get a notice in a CONTRIBUTORS text file, or in the copyright header.
> Why would normal people even want to become an unpaid janitor for someone else's stuff?
Social validation. Or, to be slightly more generous, sort of a compulsory way to force someone more experienced to provide some mentorship, by compelling them to review your pull requests.
That’s the point here, though. The maintainers of Ladybird don’t want to be compelled to mentor people making throwaway contributions without a commitment to the project. It’s pretty frustrating to try to mentor an absentee mentee who isn’t actually ready to learn from you.
You make a strong point. Large parts of a decision like this have less to do with what you can get from the community, but what you have person-hours available to do with it. The core team is pretty small, and a lot of these automatically coded PRs are bound to be huge. They’re taking back their own time to focus on their own project.
In programming forums like Hacker News people are incredibly detached from the average experience with technology, sometimes it is buffling.
Most non technical people I know asked questions to Google even before the AI overview. Instead of looking for the answer in seo-bloated articles, they find it in the overview.
I think google should improve in detecting the kind of query when I need a link that I don't remember, and deactivate the overview on those. If I search for "ryanair booking" I clearly need the url for booking a Ryanair flight, AI overview is useless
Most of the time I'm looking for something very specific that there are plenty of articles about, but clicking on the articles results in popups, banners and an unhealthy amount of scrolling to get to the answer.
AI overview provides me the answer instantly.
Think about suff like "does china borders afghanistan".
In those cases you can be confident that the AI overview is right, and saved you time.
If it is a complex or niche question I tend not to trust the overview and go straight for legitimate-looking results
Well it depends on the url. Usually shareable url where "anyone with the link may access that file" contain a random element that makes it hard to guess if you don't have it (e.g. an UUID).
In other cases the content is at easily guessable path, and that is a whole different story
I have seen lately a number of new productivity suite.
How is the Microsoft Office compatibility managed by these tools? There is a popular SDK providing the compatibility? I can't imagine everyone reimplementing the full compatibility layer
Good question, TinyCld does uses docx/xlsx files on the drive package as the native storage for text/calc. Drive is exported via webdav so doing so lets native clients load the files as well. Locking is used though so web & native _hopefully_ do not conflict.
Office compatibility really runs into the xkcd workflow problem[1]. For the overwhelming majority of users, any of these alternative office suites will work exactly as expected. They can save and open MS Office files, and can do all of the tasks most users need. But there will always be some user who has some hyper-specific need that decide they just can't get away from MS Office. This often comes down to some plugin, or some strange behavior of MS Office that the user has come to expect. Often, there's no technical reason these plugins couldn't be moved to some competitor, but they haven't been. Frequently, there's no reason the user needs this exact workflow, but it's what they know, and they don't want to change.
So how is MS Office compatibility manged by these tools? It depends on who you ask.
Have you tried adding this instruction to your agents.MD? Avoiding situations were the agent start running a loop is the main use case of the file for me
reply