Correction. I meant to say "Dan Amelgang's replacement for pixman"
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<http://fresh.homeunix.net/%7Eluke/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
