There's a pretty serious difference between arguing for reduced abstraction in software (which can be quite reasonable, and is probably more like what the author actually envisions) and arguing for no abstraction in software. The latter comes across as ignorance of the purpose of layers of abstraction.
The author points to Alan Kay's anecdote about a simple, standardized way for formatting data on cards in 1961 and then immediately turns around and uses it to argue that standardized formats do not improve interoperability. Sounds hypocritical to me.
> "I liken starting one's computing career with Unix, say as an undergraduate, to being born in East Africa. It is intolerably hot, your body is covered with lice and flies, you are malnourished and you suffer from numerous curable diseases. But, as far as young East Africans can tell, this is simply the natural condition and they live within it. By the time they find out differently, it is too late. They already think that the writing of shell scripts is a natural act."
> Ken Pier, Xerox PARC
but while that jab illustrates the Everything Is Fine; Nothing Can Be Done mentality in computing very clearly, it's probably unfairly disrespectful to East African people.
The development team proposed NaCl as a potential solution to many of the format problems. We could make a lot of custom compression formats that would be better than gzip. A multitude of image formats tuned for various categories of images or videos.
NaCl project has social forces going against it. People want a homogenous platform. Platforms solve a social problem, developers become familiar with the same API, make libraries for it, make development easier, etc.. NaCl would have to play that game and it takes a long time. By the time it's done it won't be a good fit for problems of the day, just like high level VMs today.
The writer obviously hasn't had to deal with input validation of anything ever.
Formats exist so that programs can make good assumptions based on content. Given a good format, the content can be transformed or fitted to the device - for example, web pages on smartphones vs computers.
Also, given a format, the programmer is freed to make performance enhancements that aren't dictated by a specific platform or set of technologies. Want to write a CSV parer in Ruby? Go right ahead! Need to rewrite it in assembler for speed? Sure! You can't easily do that with a closed platform/tech like Flash or MS's binary formats.
And I bet you just have all the answers don't you? I'll even bet that you think everyone else is stupid for not seeing the OBVIOUS solutions that you're presenting!
Damn those corporate conspiracies to keep programmers down!
I haven't many answers; only questions. And someone appears to think they are interesting, as I do not submit my articles to this site, and have tried to discourage others from doing so:
Taking a better look at your site, I must apologize for my original statements - I was overly crude and insulting, which was not fair. (I'd edit it, but HN won't let me...)
While I don't agree with exactly where you're coming from, you are pushing the envelope in ways that I'm frankly not used to, and making people think, which is quite noble.
That said, I'm a firm believer in data being separate from code, so that the code can be innovated/iterated on in ways independent of data. Tying them too closely together allows less than ideal programming and laziness lead to data and code interdependence which becomes a nightmare to deal with.
If you can solve the problem of dumb/myopic programmers being let loose with the tools you propose, I'd love to hear it.
This is ridiculous. Even if you handwave away security concerns of running arbitrary native code fetched from the web as the operating system's problem, you have locked yourself into a single hardware architecture with (presumably) a single API for those binaries to run against. Even if you expect these things to run on metal you need a standard hardware configuration that exposes known I/O devices, etc. In a world where x86 coexists with ARM, PPC-derivatives and the occasional MIPS machine (not to mention dozens of other variations) native executables are not a sensible option unless you pass that buck to the server and have it spin off a custom binary for any client that may come along.
Ok, ok- so we use a VM that everyone agrees on and- wait, we're back where we started, aren't we? Except, of course, we have a ton of mandatory overhead because browsers are no longer specialized to deal with the kinds of media users expect in a browsing experience.
Unless you honestly expect that everyone, everywhere will use identical computers for everything, standardized formats will always be necessary.
> Even if you handwave away security concerns of running arbitrary native code fetched from the web as the operating system's problem
Between ye olde Java sandboxing, hardware and software OS virtualisation (Qemu, VirtualBox, VMWare etc.), JavaScript, NaCl, and other examples, it seems clear that this is a problem we now know how to manage.
> you have locked yourself into a single hardware architecture with (presumably) a single API for those binaries to run against
NaCl appears to have a grip on this problem. Write portable code in one of several languages supported by LLVM; compile with LLVM to the native NaCl format that exists for various CPU architectures, and to Portable NaCl ("PNaCl") bytecode. LLVM can be replaced by another compiler that targets NaCl.
> In a world where x86 coexists with ARM, PPC-derivatives and the occasional MIPS machine (not to mention dozens of other variations) native executables are not a sensible option unless you pass that buck to the server and have it spin off a custom binary for any client that may come along.
All the server really needs to do is to pre-compile (or be given) a set of NaCl binaries for the presently popular archs as well as a PNaCl bytecode executable for everyone else, but yes indeed, it might also dynamically compile native binaries for minority archs it knows how to support in response to client demand. If the compile is too slow to serve the first such request with a native binary, then the server can serve the PNaCl code until the new native code is ready.
(As a matter of fact, it wouldn't really be necessary to replace every single HTML file with executables. But that's another story.)
> Even if you expect these things to run on metal you need a standard hardware configuration that exposes known I/O devices, etc.
It seems that NaCl provides a syscall-like interface with its "service runtime". Something similar could surely be created for a runtime based on hardware VMs (in other words, something like Ethernet emulation in implementation terms but with an API more suitable for a Web-browser plugin).
This part of the design is a weak spot of course, as it can break and fork and version and vary across implementations, but compared to the sinking sands of the browser interface it should prove much smaller and more stable. (HTML files which are genuinely documents rather than webapps are relatively robust against some API breakage but, again, it wouldn't actually be necessary to turn every HTML document with an executable blob.)
> Ok, ok- so we use a VM that everyone agrees on and- wait, we're back where we started, aren't we? Except, of course, we have a ton of mandatory overhead because browsers are no longer specialized to deal with the kinds of media users expect in a browsing experience.
Portable C or C++ compiled to NaCl should be decently fast for almost all purposes. Failing that, there's always the possibility of hand-writing raw NaCl code as an optimisation for popular architectures. (Or writing 100% native assembler if hardware virtualisation is being used instead of NaCl.) Failing that, even if a few high-performance AV formats have to be hardwired into the browser alongside WebGL (or whatever), we're still nowhere near being back where we are - in a madhouse world where a cartel of browser vendors empowers a tin-pot Napoleon to dictate, among many other things, how we will all mark up our documents, down to the minutest details.
Smalltalk and System/38 did this in the mid-70s. System/38 code can be run on IBM Power Systems (AS/400) made today. Open Cobalt (Croquet) does peer-to-peer virtual reality by passing Smalltalk bytecode around. Read up on some computing history before flaming.
I believe this was the original plan for Xiph's Vorbis, for similar reasons. I believe they abandoned it because of practicality but I can't Google up a link to where I originally read about this. I seem to recall it also involved Monty doing a demo for some company (Apple?) where they thought he was mental to suggest such a thing.
Monty: The previous Ogg generation, Stormbringer, was a "meta-codec", a language and virtual machine for writing other codecs. It turns out very few people at the time were interested; they didn't want meta-codecs, they wanted the codecs themselves. A particularly abysmal demo of Stormbringer at Apple finally drove that point home (in addition to the fact that Apple was uninterested in Stormbringer, which needed more work to be practically useful, our demo laptop decided to overheat and break down in the middle of our pitch to the Quicktime group). That took our sense of direction away for a while; for most of 1998, no one worked on anything related to Ogg.
Then in the fall, Fraunhofer decided to start cracking down on free encoder implementations of mp3. That worried me. It also seemed like things were only likely to get worse; the trend was clearly for companies to start "cashing in" on the Net any way possible, often involving the basic technology itself, and it looked like digital audio would be no different. In 1998 this sense of foreboding was mostly a vague suspicion, but the trend strengthened and clarified over time. That gave me a clear direction to begin Vorbis; I knew what the world was going to need in a codec and soon.
You're only thinking about one dimension of the problem. In reality, you will run up against the "expression problem", in that your immediate use will be more apparent, but orthogonal un-thought-of reuses will become harder or impossible. A java/flash applet executes instructions and is a step towards the kind of universal object format you talk about, yet it is harder or impossible to index, style, and adapt to local UI conventions.
The primary feature of declarative protocols/formats/languages is to convey a common meaning of data without specifying how it should be interpreted. Try to pull meaning out of imperative code and you'll run up against the halting problem. We could just be happy with our binary blobs, but moving beyond take-it-or-leave-it single-purpose content is exactly what as allowed "the web" the flourish.
Programmable logic as a standard PC feature would be great, but there would still be video ASICs for low power decoding or high-quality realtime encoding. also how would you propose to set a standard format for FPGA bitstreams when the balance of topology/block capability/timing is ever-changing. Once again we'd need a common declarative format as a base, and software tailored for the different nodes.
Interesting, but seems that even fully developed, it would be limited to cases of when only a (lower requirement) portion of a chip needed online reconfigurability. Even one of the mailing list messages admits the routing is severely limited compared to the host, and timing hadn't been characterized. (that "ascii bitstream" format is quite cute)
If one was to flesh this idea out and create a "universal bitstream" -> specific FPGA "compiler", at what layer do we stop and declare that we have reached the proper primitive abstractions? What happens when technology moves on from those primitives, and more performance is demanded by the majority of the applications? An older CPU can go about its business a bit slower while an older FPGA trying to run new code won't even fit the design.
The nice thing is that Alan Kay's call for the Web browser to be refounded on (effectively) something like NaCl + WebGL and Tim Berners-Lee's embrace of what he called the Principle of Least Power http://www.w3.org/DesignIssues/Principles.html are both correct, and they can both be adhered to at the same time. Thesis, antithesis, synthesis. Declarative formats are a Good Thing for the reasons you mention, but it's not necessary or desirable to weld the code needed to interpret them into the browser. As it stands, the web browser is a half-hearted attempt at a dedicated reader for one particular declarative format, which has been worked up into a messy approximation to a generic application runtime. Much better to start with the generic runtime and write for it programs to handle (view, edit, inspect etc.) various different declarative formats. When it's told to open a file that's in a declarative, non-executable format, the browser can (by default) find and run a generic display program for files of that type.
I'm not arguing for the status quo, I just think the OP throws the baby out with the bathwater. The pivotal question is where does this code come from?
If I've got a "page" that displays an image, how is the code to display that image specified? In lisp terminology, does that reference involve a relatively opaque gensym that is bound (by the page) to the code to interpret it? Or does the page instead include a well-known semantically meaningful unbound symbol, which is then interpreted by my software stack as referencing code that is administered by my package manager?
There's certainly a continuum between the two, but everything in the OP strikes me as arguing for the opaque and locally bound symbol, at the expense of control by the end-user.
> The pivotal question is where does this code come from? [...] If I've got a "page" that displays an image, how is the code to display that image specified?
Here's a quick-and-dirty outline of how it could work. The webclient has a local map of file associations from a given file type to a generic-runtime display program for files of that type, specified by a URL (or maybe a URI). When the webclient has to determine the default display program for a particular file it is loading, it first looks up the local table. (Obviously the default action for a file which is itself a generic-runtime executable is to run it directly.) If there's no local mapping for the file's filetype then, for that loading sequence only, the webclient takes as the default the display program suggested (again using a URL/URI) by the file's webserver in the response header.
Of course display programs can be cached locally. There's also no assumption that the default display program will always be the one used - on any given occasion that a file is loaded, the user (or a default-runtime program which is XHRing the file) can specify a non-default display program, in order to get a different UI or a non-standard view or just a different display-program implementation. (And a program doing an XHR could just take the file itself if it desires.) Finally, the process can chain, so a particular file might be given to a display program which is a Ruby script which would in turn be given to a generic-runtime interpreter for the appropriate version of Ruby.
> There's certainly a continuum between the two, but everything in the OP strikes me as arguing for the opaque and locally bound symbol, at the expense of control by the end-user.
Yes, the OP is basically advocating Alan Kay's floor-wax over TBL's dessert topping. But talking about a continuum implies that I'm hawking some horrible compromise substance made by mixing floor-wax and dessert topping in a bucket in whatever ratio. In fact, I'm offering a delicious synthesis product which really is a perfect specimen of both things at the same time! ;) http://en.wikipedia.org/wiki/List_of_Saturday_Night_Live_com...
> this model is the polar opposite of Free software. Instead of users having absolute control over what runs on their system, they have practically no control at all. They surrender everything to the first webpage they open, and to whatever agent is controlling that page at a time.
For the impatient: I advocate a switch to direct hardware execution of exclusively high-level (human readable!) code. Does it get more user-modifiable than that? I'd like to know.
> I advocate a switch to direct hardware execution of exclusively high-level (human readable!) code. Does it get more user-modifiable than that?
What sort of code the hardware executes is irrelevant to whether that code is Free. JavaScript is high-level and mostly human-readable, but it's trivial to obfuscate JavaScript such that modification by the user is difficult or impossible. And JavaScript is a relatively limited language; a LISP-like language executed directly by the hardware could be even more difficult to modify.
> it's trivial to obfuscate JavaScript such that modification by the user is difficult or impossible.
This is a moral, rather than technological problem. Anyone writing any kind of code can choose to make life less-pleasant for those who will read it.
Under current architectures, you do not even have the option of making life pleasant for those who wish to read the code that is presently running on their machine, at the time it runs. In fact, the very idea sounds like schizophrenic soapbox heresy to most people. Which is a crying shame.
You're missing the point. Currently, I do not have to run proprietary software to use the Web. Under your design, I would have to surrender control of my computer to arbitrary third parties to use even the most basic features.
What kind of control do you presently have over your computer, that would be taken away?
Current CPUs come with hypervisors; running native code need not lead to any loss of control. Sanely designed CPUs would give the user yet more control.
Where does the code come from and how is its use specified? To be able to change code, my edit must affect all copies. If I'm receiving code dependencies over the network from the same source as my data, I need some sort of override rule that will use my edited copy instead. The package also needs a global name such that the datasource cannot change the name and put me back to the old code. And how do we reconcile changes to the code bundle from the datasource with my local changes?
We can mitigate most of these issues with cryptographic identities and trust systems, but with that amount of surrounding infrastructure, why does the datasource even need to specify which code to run for well-known datatypes if those packages already have to be on my trusted sources?
I would love to post a reply which answers these and other excellent questions from some of the replies here!
But if I were to write such a comment, it would, in a sense, be the code. Not that I wouldn't love to post the latter, when it is ready, but this is not the intended use of this site.
My apologies if this sounds like a slick excuse, but it is the truth.
Well, I'm curious about your conceptual design for this, because to me, the whole No Formats post directly contradicts your seventh rule. We can make the network transparent, but we cannot ignore the authority boundary between our two nodes. If I am to control the code running on my node, then I can't be expected to pull in common library code from your service to view your published data.
For example, this is the way things work with a standardized format. ( -x-> means depends on and trusts through some interface (non-transitive!))
Interface 1 defines what I may do with images, while interface 2 defines how I may interact with your service. MyImageLib and YourImageLib may of course be the same library, or they may not.
This is what I interpret your post as saying:
MyEnv -3-> YourCode -4-> YourImageLib
In this new relationship, I am relying on interface 3 both for my relationship with you and for what I am allowed to do with images. If you are nice as well as thorough, I am able to rely on interface 3 to get the identity of interface 4 such that I can both work with the image library directly, as well as override the reference after forking my own copy. However, if you wish to restrict me, or even simply update reference 4 to an incompatible api, my ability to work with the library directly goes away and/or my local modifications are no longer referenced.
And, as I've said before, you can't "technology-away" moral problems. All you can do is to refrain from deliberately hardcoding them into your creations.
Are not your laws of computing, specifically (VII, VI, IV, II, I), moral judgments? Trying to "technology-away" a preexisting moral problem is folly, but software, platforms especially, set a stage of default behaviors. One could argue that those who blindly go along with said default are moral failures (for their lack of analysis), but this would do little to negate the resulting effects of those masses.
On the technical front, what do you propose to copy-on-write? I'll presume by "morals", you mean that I should trust the authors of the hypothetical ImageLib and YourCode to not restrict my use of images through technical means, and to generally do the right thing when it comes to library changes.
Let's say I wish to modify ImageLib as used in your application. For copy-on-write, what is "written" ? Forking YourCode along with ImageLib (immutable references) is a non-starter, as the common case is that YourCode changes periodically, and that I'm uninterested in manual merging, as YourCode just isn't a large part of my life.
So, I've got my locally forked version of ImageLib, but any changes I make are only applied to that specific version of ImageLib. Every other XXCode which uses a different lineage or revision of ImageLib will lack the customizations I've made!
So how can this be solved? Freezing the API of ImageLib would alleviate the need for incompatible releases. But to freeze the API, it needs to be trimmed down to the bare minimum of core functionality, with extras pushed out into other modules using well thought out hooks. After eventually reaching perfection, the API can finally stop changing, and overriding all possible ImageLibs is easy (as only one exists). However, we have completely locked down the API (and thus cut off unexpected new functionality), and have effectively created a format!
Ah, I understand now. It all makes sense! To get out from under them thumb of the evil Formats, we must subjugate ourselves to an even greater, larger and more complex (but singular) Format! What could possibly go wrong?
What is described is already reality - I see it every day.
I work for a company writing its own video codecs, who have a format that downloads a 70KB jar file before streaming the video. It's a Java applet (and still supports Java 1.1 - we've been doing this for a number of years now) and largely allows the model that Stanislav wishes. Is it ideal? Probably not. We can't do fullscreen or hardware-optimised playback. We have to implement our own controls that are out of place of the L&F of the OS and browser. We need people to install the Java VM. On Java versions older than JDK6u18 we still only get to use 64MB of memory (on a 2GB machine? Hah!). Not always going to work on your latest smartphone.
On the flip side, I also see a lot of video container formats where people try to standardise something as generic as possible. Particularly OMFI (Bento), Quicktime, AAF. The simplest AAF File which simple refers to a piece of video content elsewhere is 250KB, because it has to define a complete vocabulary of items that it might deal with in the file, and jumps from pointer to pointer to actually get to the data. It's pretty much the closest we have to Stanislav's 1961 Air Force quote example, with everything short of actually including a decoder specification for the audio and video content. It's a minefield to work with. It's too flexible for its own good, and reading or writing it is anything but a trivial task (cue large libraries, larger than video decoders, to do that. Anything but ideal).
So, one side involves a virtual machine to standardise hardware, and the other needs large libraries to parse and emit even the simplest of files. I've seen this world, and I think I'd rather have well-implemented standard decoders working on simpler wrappers instead.
47 comments
[ 3.3 ms ] story [ 99.7 ms ] threadPass the pipe, please!
The author points to Alan Kay's anecdote about a simple, standardized way for formatting data on cards in 1961 and then immediately turns around and uses it to argue that standardized formats do not improve interoperability. Sounds hypocritical to me.
> "I liken starting one's computing career with Unix, say as an undergraduate, to being born in East Africa. It is intolerably hot, your body is covered with lice and flies, you are malnourished and you suffer from numerous curable diseases. But, as far as young East Africans can tell, this is simply the natural condition and they live within it. By the time they find out differently, it is too late. They already think that the writing of shell scripts is a natural act."
> Ken Pier, Xerox PARC
but while that jab illustrates the Everything Is Fine; Nothing Can Be Done mentality in computing very clearly, it's probably unfairly disrespectful to East African people.
Link: http://code.google.com/p/nativeclient-sdk/
Fast JavaScript could go a long way in that direction too https://github.com/antimatter15/weppy With types and WebGL hardware access who knows.
NaCl project has social forces going against it. People want a homogenous platform. Platforms solve a social problem, developers become familiar with the same API, make libraries for it, make development easier, etc.. NaCl would have to play that game and it takes a long time. By the time it's done it won't be a good fit for problems of the day, just like high level VMs today.
Formats exist so that programs can make good assumptions based on content. Given a good format, the content can be transformed or fitted to the device - for example, web pages on smartphones vs computers.
Also, given a format, the programmer is freed to make performance enhancements that aren't dictated by a specific platform or set of technologies. Want to write a CSV parer in Ruby? Go right ahead! Need to rewrite it in assembler for speed? Sure! You can't easily do that with a closed platform/tech like Flash or MS's binary formats.
Damn those corporate conspiracies to keep programmers down!
http://www.loper-os.org/?p=91
And to explain the present status quo, we need no conspiracies. Only people who laugh off the very idea of re-thinking foundations.
No one is asking you to throw out your PC. I only ask that you think.
While I don't agree with exactly where you're coming from, you are pushing the envelope in ways that I'm frankly not used to, and making people think, which is quite noble.
That said, I'm a firm believer in data being separate from code, so that the code can be innovated/iterated on in ways independent of data. Tying them too closely together allows less than ideal programming and laziness lead to data and code interdependence which becomes a nightmare to deal with.
If you can solve the problem of dumb/myopic programmers being let loose with the tools you propose, I'd love to hear it.
Ok, ok- so we use a VM that everyone agrees on and- wait, we're back where we started, aren't we? Except, of course, we have a ton of mandatory overhead because browsers are no longer specialized to deal with the kinds of media users expect in a browsing experience.
Unless you honestly expect that everyone, everywhere will use identical computers for everything, standardized formats will always be necessary.
Between ye olde Java sandboxing, hardware and software OS virtualisation (Qemu, VirtualBox, VMWare etc.), JavaScript, NaCl, and other examples, it seems clear that this is a problem we now know how to manage.
> you have locked yourself into a single hardware architecture with (presumably) a single API for those binaries to run against
NaCl appears to have a grip on this problem. Write portable code in one of several languages supported by LLVM; compile with LLVM to the native NaCl format that exists for various CPU architectures, and to Portable NaCl ("PNaCl") bytecode. LLVM can be replaced by another compiler that targets NaCl.
> In a world where x86 coexists with ARM, PPC-derivatives and the occasional MIPS machine (not to mention dozens of other variations) native executables are not a sensible option unless you pass that buck to the server and have it spin off a custom binary for any client that may come along.
All the server really needs to do is to pre-compile (or be given) a set of NaCl binaries for the presently popular archs as well as a PNaCl bytecode executable for everyone else, but yes indeed, it might also dynamically compile native binaries for minority archs it knows how to support in response to client demand. If the compile is too slow to serve the first such request with a native binary, then the server can serve the PNaCl code until the new native code is ready.
(As a matter of fact, it wouldn't really be necessary to replace every single HTML file with executables. But that's another story.)
> Even if you expect these things to run on metal you need a standard hardware configuration that exposes known I/O devices, etc.
It seems that NaCl provides a syscall-like interface with its "service runtime". Something similar could surely be created for a runtime based on hardware VMs (in other words, something like Ethernet emulation in implementation terms but with an API more suitable for a Web-browser plugin).
This part of the design is a weak spot of course, as it can break and fork and version and vary across implementations, but compared to the sinking sands of the browser interface it should prove much smaller and more stable. (HTML files which are genuinely documents rather than webapps are relatively robust against some API breakage but, again, it wouldn't actually be necessary to turn every HTML document with an executable blob.)
> Ok, ok- so we use a VM that everyone agrees on and- wait, we're back where we started, aren't we? Except, of course, we have a ton of mandatory overhead because browsers are no longer specialized to deal with the kinds of media users expect in a browsing experience.
Portable C or C++ compiled to NaCl should be decently fast for almost all purposes. Failing that, there's always the possibility of hand-writing raw NaCl code as an optimisation for popular architectures. (Or writing 100% native assembler if hardware virtualisation is being used instead of NaCl.) Failing that, even if a few high-performance AV formats have to be hardwired into the browser alongside WebGL (or whatever), we're still nowhere near being back where we are - in a madhouse world where a cartel of browser vendors empowers a tin-pot Napoleon to dictate, among many other things, how we will all mark up our documents, down to the minutest details.
edit: http://www.systemtoolbox.com/bfarticle.php?content_id=6
Monty: The previous Ogg generation, Stormbringer, was a "meta-codec", a language and virtual machine for writing other codecs. It turns out very few people at the time were interested; they didn't want meta-codecs, they wanted the codecs themselves. A particularly abysmal demo of Stormbringer at Apple finally drove that point home (in addition to the fact that Apple was uninterested in Stormbringer, which needed more work to be practically useful, our demo laptop decided to overheat and break down in the middle of our pitch to the Quicktime group). That took our sense of direction away for a while; for most of 1998, no one worked on anything related to Ogg.
Then in the fall, Fraunhofer decided to start cracking down on free encoder implementations of mp3. That worried me. It also seemed like things were only likely to get worse; the trend was clearly for companies to start "cashing in" on the Net any way possible, often involving the basic technology itself, and it looked like digital audio would be no different. In 1998 this sense of foreboding was mostly a vague suspicion, but the trend strengthened and clarified over time. That gave me a clear direction to begin Vorbis; I knew what the world was going to need in a codec and soon.
The primary feature of declarative protocols/formats/languages is to convey a common meaning of data without specifying how it should be interpreted. Try to pull meaning out of imperative code and you'll run up against the halting problem. We could just be happy with our binary blobs, but moving beyond take-it-or-leave-it single-purpose content is exactly what as allowed "the web" the flourish.
Programmable logic as a standard PC feature would be great, but there would still be video ASICs for low power decoding or high-quality realtime encoding. also how would you propose to set a standard format for FPGA bitstreams when the balance of topology/block capability/timing is ever-changing. Once again we'd need a common declarative format as a base, and software tailored for the different nodes.
http://web.archive.org/web/20050414203105/http://ce.et.tudel...
If one was to flesh this idea out and create a "universal bitstream" -> specific FPGA "compiler", at what layer do we stop and declare that we have reached the proper primitive abstractions? What happens when technology moves on from those primitives, and more performance is demanded by the majority of the applications? An older CPU can go about its business a bit slower while an older FPGA trying to run new code won't even fit the design.
If I've got a "page" that displays an image, how is the code to display that image specified? In lisp terminology, does that reference involve a relatively opaque gensym that is bound (by the page) to the code to interpret it? Or does the page instead include a well-known semantically meaningful unbound symbol, which is then interpreted by my software stack as referencing code that is administered by my package manager?
There's certainly a continuum between the two, but everything in the OP strikes me as arguing for the opaque and locally bound symbol, at the expense of control by the end-user.
Here's a quick-and-dirty outline of how it could work. The webclient has a local map of file associations from a given file type to a generic-runtime display program for files of that type, specified by a URL (or maybe a URI). When the webclient has to determine the default display program for a particular file it is loading, it first looks up the local table. (Obviously the default action for a file which is itself a generic-runtime executable is to run it directly.) If there's no local mapping for the file's filetype then, for that loading sequence only, the webclient takes as the default the display program suggested (again using a URL/URI) by the file's webserver in the response header.
Of course display programs can be cached locally. There's also no assumption that the default display program will always be the one used - on any given occasion that a file is loaded, the user (or a default-runtime program which is XHRing the file) can specify a non-default display program, in order to get a different UI or a non-standard view or just a different display-program implementation. (And a program doing an XHR could just take the file itself if it desires.) Finally, the process can chain, so a particular file might be given to a display program which is a Ruby script which would in turn be given to a generic-runtime interpreter for the appropriate version of Ruby.
> There's certainly a continuum between the two, but everything in the OP strikes me as arguing for the opaque and locally bound symbol, at the expense of control by the end-user.
Yes, the OP is basically advocating Alan Kay's floor-wax over TBL's dessert topping. But talking about a continuum implies that I'm hawking some horrible compromise substance made by mixing floor-wax and dessert topping in a bucket in whatever ratio. In fact, I'm offering a delicious synthesis product which really is a perfect specimen of both things at the same time! ;) http://en.wikipedia.org/wiki/List_of_Saturday_Night_Live_com...
e2: I give up; HN just won't let me post the whole thing. I've moved this comment to a pastebin, at < http://pastebin.com/bVn91ApU >
If you read my "laws of computing" piece:
http://www.loper-os.org/?p=284
do you still believe this?
For the impatient: I advocate a switch to direct hardware execution of exclusively high-level (human readable!) code. Does it get more user-modifiable than that? I'd like to know.
What sort of code the hardware executes is irrelevant to whether that code is Free. JavaScript is high-level and mostly human-readable, but it's trivial to obfuscate JavaScript such that modification by the user is difficult or impossible. And JavaScript is a relatively limited language; a LISP-like language executed directly by the hardware could be even more difficult to modify.
This is a moral, rather than technological problem. Anyone writing any kind of code can choose to make life less-pleasant for those who will read it.
Under current architectures, you do not even have the option of making life pleasant for those who wish to read the code that is presently running on their machine, at the time it runs. In fact, the very idea sounds like schizophrenic soapbox heresy to most people. Which is a crying shame.
Current CPUs come with hypervisors; running native code need not lead to any loss of control. Sanely designed CPUs would give the user yet more control.
We can mitigate most of these issues with cryptographic identities and trust systems, but with that amount of surrounding infrastructure, why does the datasource even need to specify which code to run for well-known datatypes if those packages already have to be on my trusted sources?
But if I were to write such a comment, it would, in a sense, be the code. Not that I wouldn't love to post the latter, when it is ready, but this is not the intended use of this site.
My apologies if this sounds like a slick excuse, but it is the truth.
For example, this is the way things work with a standardized format. ( -x-> means depends on and trusts through some interface (non-transitive!))
Interface 1 defines what I may do with images, while interface 2 defines how I may interact with your service. MyImageLib and YourImageLib may of course be the same library, or they may not.This is what I interpret your post as saying:
In this new relationship, I am relying on interface 3 both for my relationship with you and for what I am allowed to do with images. If you are nice as well as thorough, I am able to rely on interface 3 to get the identity of interface 4 such that I can both work with the image library directly, as well as override the reference after forking my own copy. However, if you wish to restrict me, or even simply update reference 4 to an incompatible api, my ability to work with the library directly goes away and/or my local modifications are no longer referenced.What have I misunderstood?
And, as I've said before, you can't "technology-away" moral problems. All you can do is to refrain from deliberately hardcoding them into your creations.
On the technical front, what do you propose to copy-on-write? I'll presume by "morals", you mean that I should trust the authors of the hypothetical ImageLib and YourCode to not restrict my use of images through technical means, and to generally do the right thing when it comes to library changes.
Let's say I wish to modify ImageLib as used in your application. For copy-on-write, what is "written" ? Forking YourCode along with ImageLib (immutable references) is a non-starter, as the common case is that YourCode changes periodically, and that I'm uninterested in manual merging, as YourCode just isn't a large part of my life.
So, I've got my locally forked version of ImageLib, but any changes I make are only applied to that specific version of ImageLib. Every other XXCode which uses a different lineage or revision of ImageLib will lack the customizations I've made!
So how can this be solved? Freezing the API of ImageLib would alleviate the need for incompatible releases. But to freeze the API, it needs to be trimmed down to the bare minimum of core functionality, with extras pushed out into other modules using well thought out hooks. After eventually reaching perfection, the API can finally stop changing, and overriding all possible ImageLibs is easy (as only one exists). However, we have completely locked down the API (and thus cut off unexpected new functionality), and have effectively created a format!
(also, a tidbit that's kind of a continuation: http://news.ycombinator.com/item?id=2121549)
I work for a company writing its own video codecs, who have a format that downloads a 70KB jar file before streaming the video. It's a Java applet (and still supports Java 1.1 - we've been doing this for a number of years now) and largely allows the model that Stanislav wishes. Is it ideal? Probably not. We can't do fullscreen or hardware-optimised playback. We have to implement our own controls that are out of place of the L&F of the OS and browser. We need people to install the Java VM. On Java versions older than JDK6u18 we still only get to use 64MB of memory (on a 2GB machine? Hah!). Not always going to work on your latest smartphone.
On the flip side, I also see a lot of video container formats where people try to standardise something as generic as possible. Particularly OMFI (Bento), Quicktime, AAF. The simplest AAF File which simple refers to a piece of video content elsewhere is 250KB, because it has to define a complete vocabulary of items that it might deal with in the file, and jumps from pointer to pointer to actually get to the data. It's pretty much the closest we have to Stanislav's 1961 Air Force quote example, with everything short of actually including a decoder specification for the audio and video content. It's a minefield to work with. It's too flexible for its own good, and reading or writing it is anything but a trivial task (cue large libraries, larger than video decoders, to do that. Anything but ideal).
So, one side involves a virtual machine to standardise hardware, and the other needs large libraries to parse and emit even the simplest of files. I've seen this world, and I think I'd rather have well-implemented standard decoders working on simpler wrappers instead.
I'm not sure X would be my prime example of simplicity...