
No Formats, no Format Wars - duck
http://www.loper-os.org/?p=309
======
RodgerTheGreat
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.

~~~
leoc
> 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.

------
mindslight
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.

~~~
asciilifeform
Re: FPGA bitstreams: Here’s one attempt at standardization in spite of the
hostility of chip vendors: the “MPGA”:

[http://web.archive.org/web/20050414203105/http://ce.et.tudel...](http://web.archive.org/web/20050414203105/http://ce.et.tudelft.nl/~reinoud/mpga/README.html)

~~~
mindslight
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.

------
jermy
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.

------
zdw
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.

~~~
asciilifeform
What input-validated your PC's operating system when you booted it?

~~~
zdw
Last I checked, CPU's generally don't react well to executing random data as
instructions.

~~~
asciilifeform
Mine is perfectly well-behaved in response to random/mistaken instructions.
Executed under VmWare, where they belong. (during OS prototyping, etc.)

~~~
alnayyir
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!

~~~
asciilifeform
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:

<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_.

~~~
zdw
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.

------
cageface
Yeah, replacing all data formats with a new, dynamic, "meta" format is going
to make everything simpler and more compatible.

Pass the pipe, please!

~~~
alnayyir
Classic crackpot formula.

~~~
asciilifeform
Yes, because even to hint at how we might climb out of a local-maximum
optimization valley is the act of a raving lunatic.

~~~
RodgerTheGreat
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.

~~~
jmillikin
The user you are replying to is the author.

------
jb3
Could Native Client be the way forward for this approach?

Link: <http://code.google.com/p/nativeclient-sdk/>

~~~
Detrus
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.

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.

------
jmillikin
e: interesting; HN won't let me post my full comment. It just times out. I'm
going to try posting bits of it at a time, as edits.

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> >

~~~
asciilifeform
> 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.

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.

~~~
jmillikin
> _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.

~~~
asciilifeform
> 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.

~~~
jmillikin
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.

~~~
asciilifeform
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.

------
eftpotrm
_> you don’t need anything more complex than something like X Windows_

I'm not sure X would be my prime example of simplicity...

------
rfugger
Quick, someone patent the meta-format.

~~~
asciilifeform
Think big! Skip straight to patenting the Turing-complete computing machine.

------
sliverstorm
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?

