Skip to content

Piero Bosio Social Web Site Personale Logo Fediverso

Social Forum federato con il resto del mondo. Non contano le istanze, contano le persone

FastRender: un browser scritto dall’AI

Uncategorized
4 2 0
  • FastRender: un browser scritto dall’AI

    Simon Willison ha scritto su Substack riguardo a Wilson Lin e un suo progetto: FastRender, un browser scritto dall’IA. Lin dice chiaramente che non ha mai pensato di ottenere qualcosa al livello di Chrome: il progetto, nato come esperimento nel tempo libero a novembre e poi ampliato con nuove risorse quando ha visto i primi risultati, serviva soprattutto come proof of concept e banco di prova per vedere le capacità di interazione degli agenti. Guardando i numeri, sono impressionanti: si è arrivati ad avere 2000 agenti che operavano concorrentemente, e vi lascio solo immaginare quante risorse computazionali servono. In effetti il demo, con l’apertura della home page di CNN e di Wikipedia, ha mostrato che il browser è piuttosto lento, oltre a non avere ancora JavaScript funzionante: un agente l’ha stoppato perché non funzionava :-)
    I programmatori potrebbero essere interessati sulla parte relativa ai commit – tutti chiaramente automatici – fatti dagli agenti. Per esempio, Lin ha trovato che era meglio lasciare una possibilità di un commit che non compilava, per non avere colli di bottiglia e rallentare lo sviluppo. Leggendo il resoconto, sono ragionevolmente certo che il progetto non potrà andare molto avanti senza interventi umani: però già solo avere più di un milione di righe di codice scritto in Rust e preparato da un singolo sviluppatore (e una quantità inconcepibile di potenza di calcolo, d’accordo) mi dà abbastanza da pensare.

  • FastRender: un browser scritto dall’AI

    Simon Willison ha scritto su Substack riguardo a Wilson Lin e un suo progetto: FastRender, un browser scritto dall’IA. Lin dice chiaramente che non ha mai pensato di ottenere qualcosa al livello di Chrome: il progetto, nato come esperimento nel tempo libero a novembre e poi ampliato con nuove risorse quando ha visto i primi risultati, serviva soprattutto come proof of concept e banco di prova per vedere le capacità di interazione degli agenti. Guardando i numeri, sono impressionanti: si è arrivati ad avere 2000 agenti che operavano concorrentemente, e vi lascio solo immaginare quante risorse computazionali servono. In effetti il demo, con l’apertura della home page di CNN e di Wikipedia, ha mostrato che il browser è piuttosto lento, oltre a non avere ancora JavaScript funzionante: un agente l’ha stoppato perché non funzionava :-)
    I programmatori potrebbero essere interessati sulla parte relativa ai commit – tutti chiaramente automatici – fatti dagli agenti. Per esempio, Lin ha trovato che era meglio lasciare una possibilità di un commit che non compilava, per non avere colli di bottiglia e rallentare lo sviluppo. Leggendo il resoconto, sono ragionevolmente certo che il progetto non potrà andare molto avanti senza interventi umani: però già solo avere più di un milione di righe di codice scritto in Rust e preparato da un singolo sviluppatore (e una quantità inconcepibile di potenza di calcolo, d’accordo) mi dà abbastanza da pensare.

    @notiziole è sostanzialmente codice copiato da Servo. La AI non ha prodotto nulla di nuovo, al solito. Se ne è parlato sul Fediverso.

  • @notiziole è sostanzialmente codice copiato da Servo. La AI non ha prodotto nulla di nuovo, al solito. Se ne è parlato sul Fediverso.

    @oblomov ma un LLM non si inventa nulla, se non per sbaglio (la parte casuale), che però ci metterebbe troppo a fare un algoritmo evolutivo su software così grande. Riuscire a trovare i pezzi non è già banale.

  • @oblomov ma un LLM non si inventa nulla, se non per sbaglio (la parte casuale), che però ci metterebbe troppo a fare un algoritmo evolutivo su software così grande. Riuscire a trovare i pezzi non è già banale.

    @notiziole non è che ci siano molti browser engine in giro. O rubava da lí, o da Gecko, o da WebKit o da Blink. Il prompt ha sostanzialmente diretto il furto. E questo è ovviamente il caso piú eclatante, molti altri non sono cosí pubblicizzati né cosí ovvî.


Gli ultimi otto messaggi ricevuti dalla Federazione
  • read more

  • Trump: “Canada contrario al Golden Dome”.
    (Eco Vicentino)

    read more

  • @phantasus sorta, yes!

    read more

  • @Bastacosi

    Come se non fossimo già a buon punto, tra l'altro.

    @matz

    read more

  • Copenaghen apre al dialogo con Washington su sicurezza artica e difesa missilistica. La Danimarca apre al dialogo sullo scudo Golden Dome dopo l’intesa quadro su Groenlandia.
    Milanofinanza

    read more

  • This brings back memories. Before Python had async/await, before asyncio became standard, I was happily writing concurrent code with gevent. I actually preferred it.

    The reason was simple: no function color problem. With async/await, you split the world into two kinds of functions—ones that block by default and ones that don't. You have to mark the latter with async and remember to await them. With gevent, everything just blocks by default, and you spawn when you need concurrency. It's the same mental model as multithreading, just lighter. Project Loom in Java does something similar, though the technical details differ.

    I sometimes wonder what Python would look like if it had embraced gevent-style coroutines in CPython instead of adding async/await. Or if Stackless Python had been accepted upstream. Maybe async programming would be more approachable today.

    The explicit await keyword gives you visibility into where context switches can happen, sure. But in practice, I/O points are obvious even without the keyword—you're reading from a socket, querying a database, making an HTTP request. The explicitness doesn't really prevent race conditions or timing bugs. Meanwhile, function colors infect everything. One async library forces your entire call stack to be async. You end up maintaining both sync and async versions of the same code, or the ecosystem just splits in two.

    With gevent, there's no such problem. You just call functions. Spawn them if you want concurrency, call them normally if you don't. Go's goroutines and Project Loom are popular for good reasons—they make concurrency accessible without the cognitive overhead.

    Python's choice is history now, and there's no going back. But looking at how things turned out, I can't help but think the more practical path was right there, and we walked past it.

    read more

  • 🌱 Proud to share: my online services are hosted green!
    Verified by The Green Web Foundation — powered by renewable energy via netcup GmbH.
    Small steps matter. 💚

    ✅ thegreenwebfoundation.org/green-web-check/?url=www.nicfab.eu
    ✅ thegreenwebfoundation.org/green-web-check/?url=www.fabiano.law

    read more

  • @cwebber is rawdogging ppp over a serial crossover cable still in vogue, or could this lightning talk just be a link to your dotfiles repo?

    read more
Post suggeriti