On Wed, May 5, 2010 at 7:33 AM, John Zabroski <[email protected]> wrote: > Correction. I meant to say "Dan Amelgang's replacement for pixman"
...which I suspect is even better than mine. Dan > On Tue, May 4, 2010 at 10:41 AM, John Zabroski <[email protected]> > wrote: >> >> >> On Mon, May 3, 2010 at 3:25 AM, Pascal J. Bourguignon >> <[email protected]> wrote: >>> >>> I've not read it closely, but it seems we have here >>> http://fresh.homeunix.net/~luke/misc/repo/slitch/src/tcpip.lisp >>> an implementation of TCP/IP in lisp in less than one thousand lines >>> including comments. >>> The core of TCP/IP is indeed not big. Mind you, it had to run on >>> computers of 40 years ago, so it just COULD NOT be big! >> >> >> Honestly? I don't think your conclusion makes sense. >> >> TCP/IP does have flaws, they have been documented in the literature and >> unfortunately not really explained by VPRI, but its model size is roughly >> the "natural size" for a networking stack. When you speak of TCP/IP being >> "big", we're really talking here about either model size, or implementation >> size. Implementation size is historically very misleading. For example, X >> Windowing system effectively introduced "shared libraries" to UNIX, creating >> horrible verisonability issues, simply because the system itself was so >> monolithic that shared libraries was the only way to reduce bloat. But it >> was fundamentally done incorrectly -- in DLL Hell fashion -- and created >> massive security vulnerabilities. TCP/IP and windowing systems both show >> how dumb modern operating system design is. >> >> TCP/IP is not VPRI's only example, and currently it may not even be a >> killer example, since it is not literate enough and not hooked into a >> (loosely speaking) HyperCard-like system. >> >> What shocks me looking at Mark Guzdial's post providing Alan Kay's >> position on education, is that Mark doesn't seem to actually know how to >> Google for VPRI's work. He asks Alan for the example, rather than being >> aware of, say, Dan Amelgang's replacement for jitblt. jitblt reduces the >> size of pixman by an order of magnitude, but it does not preserve the same >> performance characteristics or currently afford the ability to reason about >> model tradeoffs. > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > > _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
