On 1/21/2012 11:23 AM, Shawn Morel wrote:
Reuben,
Your response is enlightening in many ways. I think it re-inforces for me how computer science is really more
of an "automation pop culture." As a society, we've become engrossed with product yet we spend only
a few minutes at most usually playing around with the artefacts produced - forming surface judgements and
rarely if ever deconstructing them in order to understand their inner environment. As an academic discipline,
I fear we've become entrenched in dogma around the accidental complexities we now consider "core"
to our understanding of a problem - a running executable, bits of ASCII sigels organized in "files".
dunno if you are objecting just to the notion of executables, or to
files in general.
I suspect in both cases though, it may be due to some extent on a
user/psychological need for humans to be like "there is something, and
there it is".
users then need to have a sense of files existing, and to be able to
interact with them (copy them around, ...). otherwise, there would
likely need to be something to take on a similar role. if it were merely
"a sea of data", some people might be happy, but others would be
somewhat less happy (the OS and File-System is often becoming enough of
such a "sea of data" as it already is).
to some extent, the program binary is also, similarly, a representation
of the "thing" that is the program (although, some naive users gain the
misconception that it is the icon which "is" the app, leading sometimes
to people copying the icon onto a thumb-drive or similar, going onto
another system, and having little idea why their "application" no longer
works on the new system).
but, like the FS, applications have increasingly started to become a
"sea of data", as the program becomes a whole directory of files, or has
its contents spread all over within the OS's directories.
hence, some systems have made use of an "executable" which is really an
executable read-only archive or database (JVM and .NET).
a few systems have gone further still, having the app be essentially
distributed as a self-contained virtual file-system. Steam does this,
with the program being itself a self-contained read-only VFS, but
allowing the application to write into its VFS (the actual file data is
stored separately in this case).
I have even encountered a few applications before distributed as VMware
images (with an entire OS, typically FreeDOS or a stripped-down/hacked
Win9x or WinXP, bundled as a part of the "app"), granted, in the cases
where I have encountered this, I have been left to doubt both the
legality and competence of the developers (just how poorly made and
hacked-together crap does an app need to be before it justifies shipping
an entire OS with the app in order to run it?... meanwhile does MS
necessarily approve of Win9x or WinXP being used as a redistributable
run-time for said app?...).
granted, at least if Win98 blue-screens in VMware, it is a little less
annoying than on real HW, but then one can be left to wonder if it just
doesn't run well in an emulator, or if it really was that unreliable?...
(granted, I do sort of remember Win98 being one of those OS's I thought
was too terrible to really bother actually using, me instead mostly
running Linux and later Win2K, before later migrating back mostly into
Windows land just prior to the release of WinXP...).
nevermind unverified reports that WinME was worse than Win98 (with both
poor reliability and also software compatibility problems...).
but, anyways, "application as a runnable VFS" is possibly an idea which
could be worth possible exploration. now, whether or not it is
allowed/possible for a user to extract the contents of such an
application, is a more open issue (as-is whether or not the VFS is
read-only or self-modifying).
ideally, if it could also be done better than with the Valve/Steam GCF
system is more open (ideally... it could be done without manual
"LoadLibrary()" / "GetProcAddress()" and API-fetching hacks, or an
otherwise overly constrained/annoying bootstrap process...). if one were
still using native binaries, a probable strategy could be to compile the
program as native DLLs or SO's, and have the launcher potentially
incorporate a customized loader (launcher opens the VFS, looks for
appropriate binaries for the architecture, loads them into the address
space, and executes them).
one "could" make the VFS be an EXE, but my personal testing shows this
to be pointless on modern Windows (if executed directly, the associated
program will be invoked, including with any file extensions).
say, image exists "foobar.myvm", and is called as "foobar.myvm Arg0
Arg1", apparently the VM will be called with a commandline something like:
"C:\Program Files (x86)\MyVM\myvm.exe" "E:\...\foobar.myvm" Arg0 Arg1
(note that, if launching via "WinMain()", it will be a single big string
as-above, but if by "main()" it will of course be split into the
relevant entries in "argv[]").
taken further, one doesn't need to type the file-extension (in the CMD
shell) if the extension is present in the "PATHEXT" environment variable.
I could be wrong somewhere, but this the behavior I saw in my own tests.
for Linux, I am aware also of the "shebang" / "hash-bang" system, which
AFAICT "should" work for binary files (provided it looks something like
"#!/usr/local/bin/whatever\n\0"), but I am not necessarily sure if this
is "generally portable" (seemed to work on Cygwin and Linux at least).
there is apparently also the "binfmt_misc" mechanism on Linux.
I am less certain which strategy would be preferable though given a
binary format capable of using either strategy (they may be mutually
exclusive though, as the use of a shebang would render the magic no
longer being necessarily at a fixed-address, but granted there is always
still the file extension...).
then again, all of this may itself be a result of the mountain of
complexity and cruft that is, anymore, taken for granted. like, "in a
better tomorrow" there will not be a need for ugly application-loading
hacks?...
(nevermind that my "magical program binary format" is essentially just a
hacked variation of the Quake1 "WAD2" format, with some stupid 16-byte
alignment restrictions for sake allowing space to be allocated using a
bitmap...).
Every year, a thread similar to this pops up and I've never really known how to respond.
Now, I'd like to propose that if we are indeed to be considered a "science of
computation" then we should do as other scientific disciplines and try to reproduce
the findings.
interesting idea...
After all, given that more or less robust implementations of OMeta exist, if I truly understand,
for example, "nothing" the low level machine language, then I should be able to spend an
afternoon with OMeta and this year's report's appendix and have a crude "nothing"
interpreter. The same could be said about most parts of the system. If I can't reproduce this work
then either:
- conceptual bits are missing
- I've found a better way to do it
- I don't really yet understand the concept
In all cases, sharing THAT experience here is more constructive for everyone.
Build you're own interpretation of nothing or build a set of Nile programs as
you understand Nile to work and put it on git hub.
also a cool idea.
much like a generalization of "hey, here are some random files in a
random file format, how easily can I make this stuff work in my stuff?..."
if things don't map well, or would likely require a bunch of
architectural hacks to make it work, maybe there is a bit of problem
somewhere?...
although not particularly small, after implementing Java ByteCode
support for my VM stuff, I had looked at adding .NET MSIL/CIL support.
at the time, it looked like a nasty-enough problem that I had
half-considered incorporating a dedicated CLI implementation ("Dot Net
Anywhere") and daisy-chaining the thing.
granted, this was a few years ago, and I have since figured out the
concept of threaded-code and how to (albeit inefficiently) map a
table-driven structure onto a hierarchical database (the .NET CLR uses a
table-driven / RDBMS-like database structure, whereas my VM uses a
hierarchical database more similar to the Windows Registry or similar...).
I could probably manage to make it work if I wanted, but I am not
certain there is a whole lot of point (I would not gain much over what I
can gain either by daisy-chaining to .NET or Mono, or by just using
Java, all of which were concluded to be "generally deficient" for my uses).
I think the one thing that I might like to see is a screen capture of a live
essay to make sure my understanding is in line. But then, I can build my own
live essay in HTML / JS or something else.
I truly believe that the goals of VPRI are better served by NOT handing out executable
forms of their findings but rather disseminating the concepts of "executable
Maths"
very possibly...
if the goal is looking for "the theory", it may be preferable to avoid
being tied down to a particular/concrete implementation (in which case,
people might expect the designer/creator to actually *maintain* the
thing, rather than merely going off and researching other possibilities).
admittedly, I am not as personally driven to avoid a concrete
implementation, but at the same time, I am not particularly much doing
research either... (but, yeah, I do understand wanting to avoid being
"chained down" as, after all, who knows what things tomorrow may
hold?... so a person can sit around "doing their own thing", ...).
like, for example, if a musician wanted to pursue various musical forms.
say, for example: a dubstep backbeat combined with rap-style lyrics sung
using a death-metal voice or similar, without "the man" (producers, ...)
demanding all the time that they get a new album together (or that their
fans and "the man" expect them to stay with their existing sound and
theme), and if they just gave them something which was like "and so
wub-wub-wub, goes the sub-sub-sub, as the lights go blim-blim-blim, as
shorty goes rub-run-run, on my hub-hub-hub, as my rims go
spin-spin-spin" or something... (all sung in deep growls and roars), at
which point maybe the producers would be very unhappy (say, if he was
hired on to be part of a tween-pop boy-band, and adolescent females may
respond poorly to bass-filled "wubbing growl-rap", or something...).
or such...
shawn
On Jan 20, 2012, at 5:52 PM, Reuben Thomas wrote:
I have just skimmed VPRI's 2011 report; lots of interesting stuff
there. The ironies of a working system that the rest of us can only
view in snapshot form grow ever-stronger: the constant references to
active documents are infuriating. The audience would like to see the
active document, but instead we only get a printout. It's as if,
waiting for a new film, we got only reviews of trailers rather than
the trailers themselves.
The irony is then compounded by a code listing at the end of the
document (hint: a URL is shorter and actually useful; this is not the
1980s).
And then just when we thought it was going to end, the agony
continues: you've pushed the deadline back a year.
I wish you all a joyful and productive 2012; unlike many projects,
it's clear that with this one the question is not whether what is
finally released will be worth the wait, it's whether it'll ever
actually be released.
You do shoot yourselves in the foot at one point: "The Web should have
used HyperCard as its model, and the web designers made a terrible
mistake by not doing so." Yes, but the web shipped and revolutionised
the world; meanwhile, you lot have shipped stuff that, at best, like
Smalltalk, has inspired revolutions at one remove. Many of the lessons
of your work are decades old and still not widely learned. Contrast
with Steve Jobs, who spun an ounce of invention into a mile of
innovation, by combining a desire for better computing with the
understanding that without taking people with you, your ideas will die
with you. It's a shame and an embarrassment that to the world at large
he's the gold standard.
Please, no more deadline extensions. Whatever you have by the end of
this year will unquestionably be worth releasing, for all its
imperfections. It's high time to stop inventing the future and start
investing it.
--
http://rrt.sc3d.org
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
