On 10/10/10 2:25 AM, Dirk Pranke wrote:
On Sat, Oct 9, 2010 at 8:50 PM, Paul D. Fernhout
<pdfernh...@kurtz-fernhout.com> wrote:
On 10/9/10 3:45 PM, Dirk Pranke wrote:
C++ is a significant security concern; and it is reasonable to want a
browser written in a memory-safe language.
Unfortunately, web browsers are large, extremely
performance-sensitive, legacy applications. All of the major browsers
are written in some combination of C, C++, and Objective-C (and
undoubtedly assembly in isolated areas like the JITs), and it's
unclear if one can reasonably hope to see a web browser written from
scratch in a new language to ever hope to render the majority of the
current web correctly; the effort may simply be too large. I was not
aware of Lobo; it looks interesting but currently idle, and is a fine
example of this problem.
I continue to hope, but I may be unreasonable :)
Yes, that seems like a good description of the problem.
How about this as a possibility towards a solution ...
I think I'd rather try to write a browser from scratch than
debug/maintain your solution ;)
Sure, with today's tools "debugging" a solution developed at a higher level
of abstraction would be hard. So, sure, this is why no one does what I
proposed with parting C++ into an abstraction, working with the abstraction,
and then regenerating C++ as an assembly language, and then trying to debug
the C++ and change the abstraction and have round trip problems with all
that. Still, I bet people said that about Fortran -- how can you possibly
debug a Fortran program when what you care about is the assembler instructions?
But like I implied at the start, by the (imagined) standards of, say, 2050,
we don't have any "debuggers" worth anything. :-) To steal an idea from
Marshall Brain:
http://sadtech.blogspot.com/2005/01/premise-of-sadtech.html
"Have you ever talked with a senior citizen and heard the stories? Senior
citizens love to tell about how they did things "way back when." For
example, I know people who, when they were kids, lived in shacks, pulled
their drinking water out of the well with a bucket, had an outhouse in the
back yard and plowed the fields using a mule and a hand plow. These people
are still alive and kicking -- it was not that long ago that lots of people
in the United States routinely lived that way. ... When we look at this kind
of stuff from today's perspective, it is so sad. The whole idea of spending
200 man-hours to create a single shirt is sad. The idea of typing a program
one line at a time onto punch cards is sad, and Lord help you if you ever
dropped the deck. The idea of pulling drinking water up from the well by the
bucketful or crapping in a dark outhouse on a frigid winter night is sad.
Even the thought of using the original IBM PC in 1982, with its 4.77 MHz
processor, single-sided floppy disk and 16 KB of RAM is sad when you look at
it just 20 years later. Now we can buy machines that are 1,000 times faster
and have a million times more disk space for less than $1,000. But think
about it -- the people who used these technologies at the time thought that
they were on the cutting edge. They looked upon themselves as cool, hip,
high-tech people: ..."
So, people fire up GDB on C++ (or whatever) and think they are cool and hip.
:-) Or, for a more realistic example given C++ is a couple decades old,
people fire up Firebug on their JavaScript an think they are cool and hip.
:-) And, by today's standards, they are:
http://getfirebug.com/
But by the standards of the future of new computing in 2050, Firebug, as
awesome as it is now, lacks things that one might think would be common in
2050, like:
* monitoring a simulated end user's cognitive load;
* monitoring what is going on at hundreds of network processing nodes
* integration with to do lists and workflow management;
* really useful conversational suggestions about things to think about in
regard to potential requirements, functionality, algorithmic,
implementation, networking, testing, social, paradigm, security, and
stupidity bugs as well as all the other types of possible bugs we maintain
in an entomological catalog in a semantic web (a few specimens of which are
listed here:
http://weblogs.asp.net/fbouma/archive/2003/08/01/22211.aspx );
* easy archiving of the traces of sessions and an ability to run things
backwards or in a parallelized many-worlds environment; and
* an ability to help you debug an applications multiple abstractions
(even if it is cool that it can help you debug what is going on with the
server a bit: http://getfirebug.com/wiki/index.php/Firebug_Extensions )
So, to add something to a "to do" list for a universal debugger, it should
be able to transparently deal with the interface between different levels of
abstraction. :-) As well as all those other things.
Essentially, we need a debugger who is an entomologist. Or, to take it one
step further, we need a debugger that likes bugs and cherishes them. :-) And
at that point, it's not a debugger -- it's some kind of
scientist/engineer/artist/historian/librarian/etc. of bugs.
So, it's not your Papa's debugger. :-)
And, just to not get too AI-ish, the role of the human community in that
debugging process needs to be thought through in a joyful, healthy,
prosperous, and intrinsically/mutually secure way. :-)
So, if the (semantic) network is the computer, the (semantic) network is the
debugger? :-)
Also, re: running Chrome in VirtualBox, are you aware that the page
renderers are
already run in sandboxed execution environments? It's unclear how much
more protection
each page in a separate VM would really buy you.
Ah, but my point was that the "sandbox" doesn't protect you if the sandbox
is written in C++ and has a certain class of pointer or bounds check bug or
probably some other certain bugs... So, I was just putting up a "solution"
that addressed that, regardless of how impractical it might be at the
moment. :-)
I'm not sure it was part of the VanGogh environment but at the same time
there was a related effort there to partition Smalltalk images into
firewalled subsets (so, sort of like one VM could look like multiple VMs as
a kind of hypervisor?)
But, that security issue again moves across layers of abstraction
(HTML/JavaScript vs. the browser's implementation) so again we need a better
debugger to deal with that. :-)
John pointed out that debugging on a network would be different than
debugging locally, and I'll take that now a step further and say, debugging
across multiple different abstractions would be different than debugging
just one abstraction.
And that's all C++ is in a sense, a popular abstraction -- even when just
working in C++ with a debugger, do you have support for debugging whatever
abstractions you have built yourself on top of it and the way they interact?
Maybe you have a tiny bit of support in the sense that objects and classes
might sort of relate to your abstraction (the application) and you can kind
of trace through function calls that sort of reflect that abstraction. But
the debugger is not going to help with design flaws in your abstraction --
like, say, tracking cognitive load on the end user by young GUI the way it
might, say, tell you how much computer memory is in use by your application.
Although, I could ask, if, say, Microsoft's Silverlight (mentioned by John)
is written in C# with garbage collection and range checking (I don't know
what it is written in, but it might be?) maybe it is an example of a better
VM? Or the JVM might be pretty secure in that sense (if it is written in
Java at this point, I'm not sure how much is)? But even if those are good
solutions, they don't have the ubiquity of JavaScript in most people's lives
right now.
At what point does everyone agree to use a better VM (including whatever
comes out of FONC)? Is the fact that people don't agree on some simple
useful VM for the web (other than JavaScript) a big "social bug" we have?
And does it relate to commerce and competition (at least in the past)?
For example, Richard Stallman invented the GPL license after seeing
commercialism take out the open hacker culture at the MIT AI lab. So, is the
GPL an attempt by a hacker to patch a "bug" in our economy? :-)
I saw short-sighted commercial thinking take out Smalltalk as a player in
the open systems space (the
ParcPlace-Digitalk-ObjectShare-sold-to-Cincom-for-a-song fiasco that lead to
Green/Oak/Java as well as fifteen years of people struggling with a crippled
Squeak compared to what was available out of the box with VisualWorks), as I
mention here:
"Design Principles Behind Smalltalk, Revisited" (by me)
http://forum.world.st/Design-Principles-Behind-Smalltalk-Revisited-td58519.html
Of course, people or communities can overcome their crippling limitations in
various ways, and Pharo, for example, is a Squeak fork that is getting
better every day. And fifteen years later, the JVM is not that bad and is
finally free as in freedom, and, sadly, VisualWorks Smalltalk is just a
niche product instead of being the JavaScript of today.
So is it legitimate to say a broken socio-economic paradigm based around
scarcity thinking is the biggest bug in all our software (in a world where
everything computing touches become free or really cheap)? :-)
Otherwise, maybe we'd have the ObjectWorks VM everywhere with Van Gogh and
internal firewalls (and not JavaScript and an HTML DOM and XML and whatever
other junk we have now). From 1997!
http://www.mactech.com/articles/mactech/Vol.13/13.03/VanGoghSmalltalk/
"Using VanGogh and the next version of VisualWorks to build multiplatform
applications with an Object-Oriented Smalltalk Interface to the Macintosh
Toolbox... VisualWorks is a Smalltalk application development environment
from ParcPlace-Digitalk providing a very high degree of portability.
Applications developed in VisualWorks run unchanged on a variety of
platforms including Macintosh, Windows, OS/2 and unix. Unfortunately, it
achieves this portability at the expense of platform compliance, by
emulating all user interface elements ("widgets") using a small set of
platform-specific graphic primitives. This article discusses the VanGogh
platform architecture - the reasons for its creation, how it manages
cross-platform compatibility while providing native look-and-feel, how it
works with the VisualWorks framework, and how it can be used to write
Macintosh-specific code. ..."
Anyway, a web browser written in Smalltalk (or something like it that was
message passing) on top of a very solid cross-platform VM with advanced
firewalling features where Smalltalk was the language of the web (instead of
JavaScript) would have been awesome. But, sadly, a bug in our economy (and
probably our educational system) meant it was not to be.
Still, JavaScript (in Chrome) is probably not that bad, if I just ignore the
risky business going on in the C++ layer and it being 100X slower than it
needs to be. :-) Mistakes get made, and we just move on and learn to live
with them (though see my subsequent comment also in reply to John and
meshwork/hierarchy).
--Paul Fernhout
http://www.pdfernhout.net/
====
The biggest challenge of the 21st century is the irony of technologies of
abundance in the hands of those thinking in terms of scarcity.
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
