I'm a long time Ricochet customer, and reluctantly switched to a CDPD modem after they shut down. CDPD is horrible -- extremely slow at its best, and usually much worse. It must be really low priority relative to voice traffic, because my cell phone conversations usually don't drop out and hang up all the time like CDPD always does.
I had one of the old Ricochet modems years ago before there was any security on the network. You could list out the names of all the other radio modems and poll top boxes that it could see. The pole top boxes had the names of the street intersections or buildings where they were mounted. Then you could dial into any of the pole top boxes, and remotely send them AT commands, to list out the other ones they could see, and walk around discovering the network that way.
But then my van was stolen, and my original Ricochet was in it, with a "Big Brother Inside" sticker on it. I immediately called Metricom and asked if my modem had been turned on and reported in. It had, and they checked the logs and gave me the address of the pole top box in a dangerous San Jose neighborhood. I rented a car and drove all around the neighborhood looking for my stolen van, but didn't find it. But a couple weeks later the van did show up right around that neighborhood, totally stripped.
I am enclosing the letterhead of Professor Darko Suvin, to go with information and enclosures which I have sent you previously. This is the first contact I have had with Professor Suvin. Listed with him are three Marxists whom I sent you information about before, based on personal dealings with them: Peter Fitting, Fredric Jameson, and Franz Rottensteiner who is Stanislaw Lem's official Western agent. The text of the letter indicates the extensive influence of this publication, SCIENCE-FICTION STUDIES.
What is involved here is not that these persons are Marxists per se or even that Fitting, Rottensteiner and Suvin are foreign-based but that all of them without exception represent dedicated outlets in a chain of command from Stanislaw Lem in Krakow, Poland, himself a total Party functionary (I know this from his published writing and personal letters to me and to other people). For an Iron Curtain Party group - Lem is probably a composite committee rather than an individual, since he writes in several styles and sometimes reads foreign, to him, languages and sometimes does not - to gain monopoly positions of power from which they can control opinion through criticism and pedagogic essays is a threat to our whole field of science fiction and its free exchange of views and ideas. Peter Fitting has in addition begun to review books for the magazines Locus and Galaxy. The Party operates (a U..S.] publishing house which does a great deal of Party-controlled science fiction. And in earlier material which I sent to you I indicated their evident penetration of the crucial publications of our professional organization SCIENCE FICTION WRITERS OF AMERICA.
"
Their main successes would appear to be in the fields of academic articles, book reviews and possibly through our organization the control in the future of the awarding of honors and titles. I think, though, at this time, that their campaign to establish Lem himself as a major novelist and critic is losing ground; it has begun to encounter serious opposition: Lem's creative abilities now appear to have been overrated and Lem's crude, insulting and downright ignorant attacks on American science fiction and American science fiction writers went too far too fast and alienated everyone but the Party faithful (I am one of those highly alienated).
It is a grim development for our field and its hopes to find much of our criticism and academic theses and publications completely controlled by a faceless group in Krakow, Poland. What can be done, though, I do not know.
Way back in 1945,
Vannevar Bush
wrote a prescient description of hypermedia browsers and window managers,
that will inspire anyone designing user interfaces,
especially web browsers and window managers.
His description of the "MEMEX" foretold of today's personal computers, and accurately predicted many specific features of modern window managers, web browsers and multimedia authoring tools.
In 1945, Vannevar Bush clearly and accurately envisioned
many useful and practical techniques to
"support the massive task of making more accessible
our bewildering store of knowledge".
Many of his visions have been implemented in modern applications, but what he wrote points the way to other useful information management techniques that remain to be implemented.
As Director of the Office of Scientific Research and Development,
Dr. Vannevar Bush has coordinated the activities of some six thousand
leading American scientists in the application of science to
warfare. In this significant article he holds up an incentive for
scientists when the fighting has ceased. He urges that men of
science should then turn to the massive task
of making more accessible our bewildering store of knowledge.
For years inventions have extended
man's physical powers rather than the powers of his mind. Trip hammers
that multiply the fists, microscopes that sharpen the eye, and engines
of destruction and detection are new results, but not the end results,
of modern science. Now, says Dr. Bush, instruments are at hand which,
if properly developed, will give man access to and command over the
inherited knowledge of the ages. The perfection of these pacific
instruments should be the first objective of our scientists as they
emerge from their war work. Like Emerson's famous address of 1837 on
"The American Scholar," this paper by Dr. Bush calls for a new
relationship between thinking man and the sum of our knowledge.
--THE EDITOR
[...]
Science has provided the swiftest communication between individuals;
it has provided a record of ideas and has enabled man to manipulate
and to make extracts from that record so that knowledge evolves and
endures throughout the life of a race rather than that of an
individual.
There is a growing mountain of research. But there is increased
evidence that we are being bogged down today as specialization
extends. The investigator is staggered by the findings and conclusions
of thousands of other workers -- conclusions which he cannot find time
to grasp, much less to remember, as they appear. Yet specialization
becomes increasingly necessary for progress, and the effort to bridge
between disciplines is correspondingly superficial.
Professionally our methods of transmitting and reviewing the results
of research are generations old and by now are totally inadequate for
their purpose. If the aggregate time spent in writing scholarly works
and in reading them could be evaluated, the ratio between these
amounts of time might well be startling. Those who conscientiously
attempt to keep abreast of current thought, even in restricted fields,
by close and continuous reading might well shy away from an
examination calculated to show how much of the previous month's
efforts could be produced on call. Mendel's concept of the laws of
genetics was lost to the world for a generation because his
publication did not reach the few who were capable of grasping and
extending it; and this sort of catastrophe is undoubtedly being
repeated all about us, as truly significant attainments become lost in
the mass of the inconsequential.
The difficulty seems to be, not so much that we publish unduly in view
of the extent and variety of present day interests, but rather that
publication has been extended far beyond our present ability to make
real use of the record. The summation of human experience is being
expanded at a prodigious rate, and the means we use for threading
through the consequent maze to the momentarily important item is the
same as was used in the days of square-rigged ships.
[...]
A new symbolism, probably positional, must apparently precede the
reduction of mathematical transformations to machine processes. Then,
on beyond the strict logic of the mathematician, lies the application
of logic in everyday affairs. We may some day click off arguments on a
machine with the same assurance that we now enter sales on a cash
register. But the machine of logic will not look like a cash register,
even of the streamlined model.
So much for the manipulation of ideas and their insertion into the
record. Thus far we seem to be worse off than before -- for we can
enormously extend the record; yet even in its present bulk we can
hardly consult it. This is a much larger matter than merely the
extraction of data for the purposes of scientific research; it
involves the entire process by which man profits by his inheritance of
acquired knowledge. The prime action of use is selection, and here we
are halting indeed. There may be millions of fine thoughts, and the
account of the experience on which they are based, all encased within
stone walls of acceptable architectural form; but if the scholar can
get at only one a week by diligent search, his syntheses are not
likely to keep up with the current scene.
Selection, in this broad sense, is a stone adze in the hands of a
cabinetmaker. Yet, in a narrow sense and in other areas, something has
already been done mechanically on selection. The personnel officer of
a factory drops a stack of a few thousand employee cards into a
selecting machine, sets a code in accordance with an established
convention, and produces in a short time a list of all employees who
live in Trenton and know Spanish. Even such devices are much too slow
when it comes, for example, to matching a set of fingerprints with one
of five million on file. Selection devices of this sort will soon be
speeded up from their present rate of reviewing data at a few hundred
a minute. By the use of photocells and microfilm they will survey
items at the rate of a thousand a second, and will print out
duplicates of those selected.
This process, however, is simple selection: it proceeds by examining
in turn every one of a large set of items, and by picking out those
which have certain specified characteristics. There is another form of
selection best illustrated by the automatic telephone exchange. You
dial a number and the machine selects and connects just one of a
million possible stations. It does not run over them all. It pays
attention only to a class given by a first digit, then only to a
subclass of this given by the second digit, and so on; and thus
proceeds rapidly and almost unerringly to the selected station. It
requires a few seconds to make the selection, although the process
could be speeded up if increased speed were economically warranted. If
necessary, it could be made extremely fast by substituting
thermionic-tube switching for mechanical switching, so that the full
selection could be made in one one-hundredth of a second. No one would
wish to spend the money necessary to make this change in the telephone
system, but the general idea is applicable elsewhere.
[...]
The real heart of the matter of selection, however, goes deeper than a
lag in the adoption of mechanisms by libraries, or a lack of
development of devices for their use. Our ineptitude in getting at the
record is largely caused by the artificiality of systems of
indexing. When data of any sort are placed in storage, they are filed
alphabetically or numerically, and information is found (when it is)
by tracing it down from subclass to subclass. It can be in only one
place, unless duplicates are used; one has to have rules as to which
path will locate it, and the rules are cumbersome. Having found one
item, moreover, one has to emerge from the system and re-enter on a
new path.
The human mind does not work that way. It operates by
association. With one item in its grasp, it snaps instantly to the
next that is suggested by the association of thoughts, in accordance
with some intricate web of trails carried by the cells of the
brain. It has other characteristics, of course; trails that are not
frequently followed are prone to fade, items are not fully permanent,
memory is transitory. Yet the speed of action, the intricacy of
trails, the detail of mental pictures, is awe-inspiring beyond all
else in nature.
Man cannot hope fully to duplicate this mental process artificially,
but he certainly ought to be able to learn from it. In minor ways he
may even improve, for his records have relative permanency. The first
idea, however, to be drawn from the analogy concerns
selection. Selection by association, rather than indexing, may yet be
mechanized. One cannot hope thus to equal the speed and flexibility
with which the mind follows an associative trail, but it should be
possible to beat the mind decisively in regard to the permanence and
clarity of the items resurrected from storage.
Consider a future device for individual use, which is a sort of
mechanized private file and library. It needs a name, and, to coin one
at random, "memex" will do. A memex is a device in which an individual
stores all his books, records, and communications, and which is
mechanized so that it may be consulted with exceeding speed and
flexibility. It is an enlarged intimate supplement to his memory.
It consists of a desk, and while it can presumably be operated from a
distance, it is primarily the piece of furniture at which he works. On
the top are slanting translucent screens, on which material can be
projected for convenient reading. There is a keyboard, and sets of
buttons and levers. Otherwise it looks like an ordinary desk.
In one end is the stored material. The matter of bulk is well taken
care of by improved microfilm. Only a small part of the interior of
the memex is devoted to storage, the rest to mechanism. Yet if the
user inserted 5000 pages of material a day it would take him hundreds
of years to fill the repository, so he can be profligate and enter
material freely.
Most of the memex contents are purchased on microfilm ready for
insertion. Books of all sorts, pictures, current periodicals,
newspapers, are thus obtained and dropped into place. Business
correspondence takes the same path. And there is provision for direct
entry. On the top of the memex is a transparent platen. On this are
placed longhand notes, photographs, memoranda, all sorts of
things. When one is in place, the depression of a lever causes it to
be photographed onto the next blank space in a section of the memex
film, dry photography being employed.
There is, of course, provision for consultation of the record by the
usual scheme of indexing. If the user wishes to consult a certain
book, he taps its code on the keyboard, and the title page of the book
promptly appears before him, projected onto one of his viewing
positions. Frequently-used codes are mnemonic, so that he seldom
consults his code book; but when he does, a single tap of a key
projects it for his use. Moreover, he has supplemental levers. On
deflecting one of these levers to the right he runs through the book
before him, each page in turn being projected at a speed which just
allows a recognizing glance at each. If he deflects it further to the
right, he steps through the book 10 pages at a time; still further at
100 pages at a time. Deflection to the left gives him the same control
backwards.
A special button transfers him immediately to the first page of the
index. Any given book of his library can thus be called up and
consulted with far greater facility than if it were taken from a
shelf. As he has several projection positions, he can leave one item
in position while he calls up another. He can add marginal notes and
comments, taking advantage of one possible type of dry photography,
and it could even be arranged so that he can do this by a stylus
scheme, such as is now employed in the telautograph seen in railroad
waiting rooms, just as though he had the physical page before him.
All this is conventional, except for the projection forward of
present-day mechanisms and gadgetry. It affords an immediate step,
however, to associative indexing, the basic idea of which is a
provision whereby any item may be caused at will to select immediately
and automatically another. This is the essential feature of the
memex. The process of tying two items together is the important thing.
When the user is building a trail, he names it, inserts the name in
his code book, and taps it out on his keyboard. Before him are the two
items to be joined, projected onto adjacent viewing positions. At the
bottom of each there are a number of blank code spaces, and a pointer
is set to indicate one of these on each item. The user taps a single
key, and the items are permanently joined. In each code space appears
the code word. Out of view, but also in the code space, is inserted a
set of dots for photocell viewing; and on each item these dots by
their positions designate the index number of the other item.
Thereafter, at any time, when one of these items is in view, the other
can be instantly recalled merely by tapping a button below the
corresponding code space. Moreover, when numerous items have been thus
joined together to form a trail, they can be reviewed in turn, rapidly
or slowly, by deflecting a lever like that used for turning the pages
of a book. It is exactly as though the physical items had been
gathered together from widely separated sources and bound together to
form a new book. It is more than this, for any item can be joined into
numerous trails.
The owner of the memex, let us say, is interested in the origin and
properties of the bow and arrow. Specifically he is studying why the
short Turkish bow was apparently superior to the English long bow in
the skirmishes of the Crusades. He has dozens of possibly pertinent
books and articles in his memex. First he runs through an
encyclopedia, finds an interesting but sketchy article, leaves it
projected. Next, in a history, he finds another pertinent item, and
ties the two together. Thus he goes, building a trail of many
items. Occasionally he inserts a comment of his own, either linking it
into the main trail or joining it by a side trail to a particular
item. When it becomes evident that the elastic properties of available
materials had a great deal to do with the bow, he branches off on a
side trail which takes him through textbooks on elasticity and tables
of physical constants. He inserts a page of longhand analysis of his
own. Thus he builds a trail of his interest through the maze of
materials available to him.
And his trails do not fade. Several years later, his talk with a
friend turns to the queer ways in which a people resist innovations,
even of vital interest. He has an example, in the fact that the
outraged Europeans still failed to adopt the Turkish bow. In fact he
has a trail on it. A touch brings up the code book. Tapping a few keys
projects the head of the trail. A lever runs through it at will,
stopping at interesting items, going off on side excursions. It is an
interesting trail, pertinent to the discussion. So he sets a
reproducer in action, photographs the whole trail out, and passes it
to his friend for insertion in his own memex, there to be linked into
the more general trail.
Wholly new forms of encyclopedias will appear, ready made with a mesh
of associative trails running through them, ready to be dropped into
the memex and there amplified. The lawyer has at his touch the
associated opinions and decisions of his whole experience, and of the
experience of friends and authorities. The patent attorney has on call
the millions of issued patents, with familiar trails to every point of
his client's interest. The physician, puzzled by a patient's
reactions, strikes the trail established in studying an earlier
similar case, and runs rapidly through analogous case histories, with
side references to the classics for the pertinent anatomy and
histology. The chemist, struggling with the synthesis of an organic
compound, has all the chemical literature before him in his
laboratory, with trails following the analogies of compounds, and side
trails to their physical and chemical behavior.
The historian, with a vast chronological account of a people,
parallels it with a skip trail which stops only on the salient items,
and can follow at any time contemporary trails which lead him all over
civilization at a particular epoch. There is a new profession of trail
blazers, those who find delight in the task of establishing useful
trails through the enormous mass of the common record. The inheritance
from the master becomes, not only his additions to the world's record,
but for his disciples the entire scaffolding by which they were
erected.
Thus science may implement the ways in which man produces, stores, and
consults the record of the race. It might be striking to outline the
instrumentalities of the future more spectacularly, rather than to
stick closely to methods and elements now known and undergoing rapid
development, as has been done here. Technical difficulties of all
sorts have been ignored, certainly, but also ignored are means as yet
unknown which may come any day to accelerate technical progress as
violently as did the advent of the thermionic tube. In order that the
picture may not be too commonplace, by reason of sticking to
present-day patterns, it may be well to mention one such possibility,
not to prophesy but merely to suggest, for prophecy based on extension
of the known has substance, while prophecy founded on the unknown is
only a doubly involved guess.
[...]
In the outside world, all forms of intelligence whether of sound or
sight, have been reduced to the form of varying currents in an
electric circuit in order that they may be transmitted. Inside the
human frame exactly the same sort of process occurs. Must we always
transform to mechanical movements in order to proceed from one
electrical phenomenon to another? It is a suggestive thought, but it
hardly warrants prediction without losing touch with reality and
immediateness.
Presumably man's spirit should be elevated if he can better review his
shady past and analyze more completely and objectively his present
problems. He has built a civilization so complex that he needs to
mechanize his records more fully if he is to push his experiment to
its logical conclusion and not merely become bogged down part way
there by overtaxing his limited memory. His excursions may be more
enjoyable if he can reacquire the privilege of forgetting the manifold
things he does not need to have immediately at hand, with some
assurance that he can find them again if they prove important.
The applications of science have built man a well-supplied house, and
are teaching him to live healthily therein. They have enabled him to
throw masses of people against one another with cruel weapons. They
may yet allow him truly to encompass the great record and to grow in
the wisdom of race experience. He may perish in conflict before he
learns to wield that record for his true good. Yet, in the application
of science to the needs and desires of man, it would seem to be a
singularly unfortunate stage at which to terminate the process, or to
lose hope as to the outcome.
I think Wine is an important step in the direction of making Linux more accessible and useful for everyone.
The fewer reasons anyone has to boot over to Windows, the longer time they spend running Linux.
Wine solves many more substantial real world problems, that far outweight any trivial ideological problems it causes.
Moore's Law guarantees that Wine's way will win.
I've developed on The Sims code on a now-obsolete 500 MhZ laptop, running Visual C++ and Outlook Express at the same time.
When it's running on a modern run-of-the-mill 1 Gigahertz desktop, there are plenty of cycles to burn.
All the time taken up by the layers of wrapper code, and even the simulation itself, is totally lost in the noise, compared to the time spent rendering, mixing sound, moving memory around, and reading from disk.
My previous message begs the question: Why did I port SimCity to Unix, if it was obviously not profitable? Two reasons: I didn't know that at the time, and I wanted to.
When I first saw SimCity, I was an undergraduate at the University of Maryland, working on user interface research and development for Ben Shneiderman at the Human Computer Interaction Lab.
As a programmer and user interface designer, I dreamed of understanding how SimCity worked, and having a chance to redesign its user interface (optimize it to run fast, enable scripting, use pie menus, display multiple views, support multi player colaboration, etc).
I was quite interested in cellular automata and visual programming and user interface design (which I still am).
So I naturally saw SimCity as a complex colorful organic CA;
with easy-to-use built-in real-time painting, zoning and bulldozer tools;
like a beautiful abstract visual data flow programming language, with its own grammar of roads, parks and buildings;
that just happened to look and behave like a city.
And I posted the following review of SimCity to comp.theory.cellular-automata:
From mimsy!brillig.umd.edu!don Fri Dec 29 13:03:18 EST 1989
Article 292 of comp.theory.cell-automata:
Path: mimsy!brillig.umd.edu!don
From: don@brillig.umd.edu (Don Hopkins)
Newsgroups: comp.theory.cell-automata
Subject: SimCity
Summary: Urban development simulation where it belongs: in a video game!
Message-ID: <21436@mimsy.umd.edu>
Date: 26 Dec 89 13:37:09 GMT
Sender: news@mimsy.umd.edu
Reply-To: don@brillig.umd.edu (Don Hopkins)
Organization: U of Maryland, Dept. of Computer Science, Human Computer Interaction Lab, Coll. Pk., MD 20742
Lines: 28
I just got a chance to play SimCity! It's like a drawing program that
lets you build cities, by zoning districts, putting down power plants
and football stadiums, wiring up the power grid, laying down roads and
railroads. The simulation is actually running *while* you're
constructing it! It acts like cellular automita with very high level
rules -- it keeps track of each cell's population, land value,
pollution, and many other factors, and the rules that govern how the
zones develop are based on the state of neighboring zones, and other
global factors (tax rate, etc). Districts that you've zoned don't come
online and start developing until they're hooked into the power grid,
by being connected through power line cells or adjacent buildings.
Buildings seem to "feed" off of people brought in by roads and
railroads. Residential zones in busy districts grow into high-rise
apartment buildings. Traffic patterns develop on the roads, and you
can see little cars zooming around based on the population of the
area, and the flow of the roads! Once you build an airport, a
helicoptor flies around the city and reports on heavy traffic,
encouraging you to redesign the roads in that area!
You may wonder what traffic copters have to do with cellular automita.
You just have to play it yourself to understand.
SimCity is absolutely the most amazing game I've seen on the Macintosh
to date! (It's available on other computers like the Amiga, as well.)
The graphics and animation are beautiful. I'll leave it at that --
mere text cannot do it justice.
What do you mean by "letting non-native go by"? You are totally off base.
Please explain how you could possibly characterize the fact that I did a native port of The Sims to Linux, as "letting non-native go by"?
I did everything within my power to help Loki get a native port of The Sims for Linux to market as soon as possible. They're the ones who dragged their feet, left me hanging, and failed to take advantage of the situation.
I still don't understand what it is that I did, that makes you so mad. It's more like you're mad at me for something I didn't do, or allowed to happen by my inaction.
The fact remains that you've visciously attacked me, and gotten all of your facts wrong. So I think you owe me an explanation or an apology.
-Don
PS: You said:
"Of course you don't seem to understand that loki is still releasing games, and Don Hopkins is still charging 80 dollars for a networkable version of sim city (the original) in tcl/tk. I've heard that the networking doesn't work, and 80 dollars is a bit steep for any game. Especially when you can get Sim City 3000 from Loki which isn't using tcl/tk for less. Don Hopkins seems to enjoy lining his pockets and repeating the market speak of native ports being bad so he can draw attention to this fantastic non-native port which is ruining future ports which are actually native, and not emulating a closed source API." -
Time Doctor
The facts you got wrong: The price wasn't $80, it was $49. I'm not "still charging" anything, because I haven't sold it for years before Loki ever existed. At the time (1993), $49 was dirt cheap for a Unix workstation game, compared to $150 for Aviator. Single player SimCity was $49 in 1993 dollars, while Loki's SimCity currently costs $49.95 in 2001 dollars. So Loki's SimCity is actually $.95 more expensive, so you're wrong about it costing less than mine. And you can't buy Multi Player SimCity from Loki for any price, while I was asking only $89 in 1993, which certainly didn't cover my time and effort. Lining my pockets??! I haven't seen a royalty check in many years, and the few I got were quite small. And I just don't understand the rest of your criticisms.
It's entirely possible to do anything, given an infinite amount of time, resources and optimism. But that's not how it works in the real world.
I'm just telling you how it is, not how it should be in the idea world.
Ultima Online and other games download patches over the network, to keep the clients in sync with the server.
That's how The Sims Online will work too.
I'm not just making this up.
I specifically asked Will Wright about the feasability of a Linux port of The Sims Online client. (In case you don't know, he's the founder of Maxis and designer of The Sims and SimCity.)
I'm just telling you what he told me, and what I know first hand from working with the code since 1997.
I'm familiar with The Sims source code, because I wrote a bunch of it, worked with all of it, ported it native to Linux, and optimized it.
The Sims wasn't designed to be a multi player game in the first place, and it's the result of more than 8 years of evolutionary design, redesign, tweaking and overhaul.
In other words, the code is hell ugly, but it does what it's supposed to. That probably applies to a lot of other games, too.
The simulator is quite tangled up with the rest of the code, and it's a lot of hard work to sort it all out into a networked multi player game.
Please believe me when I say that The Sims Online server wouldn't be able to tolerate an out-of-date client. It pains me to think about how horribly it would crash. And that applies to a lot of other online games, for economical if not technological reasons.
No online game developer in their right mind would ever choose to take on such a nightmare of supporting out-of-date clients, when they can simply download patches, which is the standard industry practice.
Ultima Online has been doing it successfully for years, and it wouldn't have worked any other way.
Online games, especially community oriented ones like Ultima Online and The Sims Online, constantly evolve in response to the needs their users.
For any non-trivial online game, evolution requires dynamically patching client binaries, and changing the server in ways that depend on the client updates.
It's extremely difficult and expensive to develop, maintain and support more than one platform, especially when you must download client updates.
Even if cross platform development were effortless and free, it would still be impossible for a third party company like Loki to develop a native port of a game like The Sims Online. That is because it would still require all clients of every platform to be synchronized and updated at the same time, which would be impossible if third party developers were involved.
On the other hand, the Wine approach should hopefully make it possible to run The Sims Online client, the very day it's released for Windows, and even download and apply the patches in real time.
It'll probably require a bit of testing and coordination between Transgaming and Maxis to make sure that it works well, but obviously they already have a good working relationship.
Wine is a win-win deal for everyone, not just Transgaming.
To the players, it means that not only can they play The Sims on Linux, but they can also run the free content creation tools like Transmogrifier, Art Studio and other third party tools. Without Wine, you will never be able to run most of those tools on Linux. They won't ever be ported to Linux, because they were written over time by many different people.
To Maxis, it means they will sell more copies of The Sims, and they will have more paying Sims Online subscribers, without having to invest resources or effort in developing cross platform clients.
So please stop trying to blame all your problems on Wine. Wine solves many more substantial real world problems, that far outweight any trivial ideological problems it causes. Attacking Wine for the good of Linux is like cutting off your nose to spite your face.
Please stop trying to censor and sabotage what other people want to do with their own computers.
If Wine offends you so much, then simply don't use it!
"Congratulations Don, you could have been an innovator in these times of bad sales for Linux ports, and yet you choose to be hurting the market with allowing non-native ports under your nose. Thanks for nothing." -Time Doctor
Imagine John Candy, making the funny "quotation marks" in the air with his finger as he rants and raves:
Thank you for "analysing" my "problem", mister "Time Doctor," sir.
Oh, so I "choose" to be "hurting" the market? Just what am I "doing" that's "causing" so much "damage"?
So I'm "allowing" these "non-native" ports, huh? Oh, really?
"Allowing"? That's not very "active". Maybe I should get off my "passive" ass and do something more?
Would you rather I "prohibit" instead of "allowing"? How do you suggest I go about "prohibiting" other people from running "The Sims" on "Wine"?
Should I have somehow "prohibited" Loki from doing a "native" port, instead of trying to "cooperate" with them?
Or am I the one "responsible" for "allowing" Loki to "fail"?
How could I have "prohibited" Transgaming from getting away with improving Wine?
By visciously "attacking" them in public, in spite of all the wonderfully useful work they've done? Is that what you mean?
So "get" to the "point": what exactly have I done to "allow" this "hurting" of the market?
Was it by "porting" The Sims to run "native" on Linux myself?
How did that "allow" Loki to fail? Or "allow" Transgaming to succeed? Is it all really my "fault"?
To cop an attitude from Scott Draeker, "go away kid, you're bothering me".
Time Doctor, you are obviously replying to articles after only having read a few words of them, totally out of context. Please go back and read the entire message. You will realize that you have made a fool of yourself in front of anyone who bothered reading the whole message.
The price for a single player license is $49.
There's nothing wrong with charging more for the multi player version of SimCity game, especially after I put literally years of my own original work into designing and implementing it, using my own equipment.
I was not paid for my time, and the only way to recoup my investment of time and effort was through royalties on sales, which didn't come close, believe me.
Remember that this was 1993, and the market for games on Unix workstations was extremely small at the time. The price of Aviator, the only other commercial Unix game I knew of, was $150. Aviator was a multi player game that you could run over the network, and I charged a lot less than Aviator cost for the multi player version of SimCity.
Time Doctor, please realise that the extremely foolish religious fanaticism of people like YOU is the reason that there will never be any successful commercial games developed for Linux.
"Except if you'd bothered to read the parent instead of trolling, you'd see that the poster was previously unaware that such an independent library exists for multi-platform gaming from the start of development." -Time Doctor
I don't know where you get all your incorrect information.
First of all, I started porting SimCity to Unix in back in 1991, and DUX published multi player X11 SimCity for Unix 1993, which is
reviewed here.
Before that, I released
HyperLook SimCity
for NeWS in 1992, which was awarded
"Product of the year 1992" from Unix World magazine (in the Jan 1993 issue).
Secondly, you have the price wrong -- it wasn't $80.
Single Player Node Locked License: $49.
Multi Player Node Locked License: $89.
Single Player Floating License: $129.
Multi Player Floating License: $149.
Such prices for Unix workstation software were unheard of at the time, and there were hardly any other commercial games available for Unix. (Despite their bluster, Loki wasn't the first Unix game company.)
For comparison: In May 1991, Curtis Priem's and Bruce Factor's "Aviator" flight simulator for the Sun workstation from Artificial Horisons sold for $150.
The authors worked for Sun designing the GX graphics accelerator board, wrote Aviator in their spare time to demonstrate the hardware, and published one of the first commercially available real time 3D games for the Sun. Good thing they had a day job.
Because right after they published it, some butt-head Sun employee posted a crack to defeat the licensing scheme to the tstech alias at Sun. They had to send around a message begging people to please delete the crack and pay for it.
I haven't made a penny off of Unix SimCity for years, because you can't buy it any more.
Loki didn't exist for years after I saw my last penny from porting SimCity to Unix.
I don't know where you got your unattributed misinformation that the networking in Multi Player SimCity Classic didn't work.
I first demonstrated it at the
Interactive Experience
of the 1993 InterCHI conference in Amsterdam.
It worked just fine then, and even better now that computers and networks are faster.
Just recently in May 2001 I showed it to the MIT Media Lab
sponsors and researchers, at the
Digital Life
confence.
I demonstrated the colaborative multi player game user interface and voting dialogs,
running over the network between two linux laptops, and it worked just fine. It's just not available as a product any more, and hasn't been for a long time.
I am not "repeating the market speak of native ports being bad". I am making a point, based on my own experience as well as talking with other people who I trust, like Will Wright and John Gilmore.
My point is that Wine solves many more problems than it causes, and that native ports to Linux aren't worth it, unless you put a lot of time, energy and creativity into improving the game so it substantially takes advantage of the platform.
Even then, there's no guarantee that it'll be worthwhile. There are many more important economic issues that totally override trivial technical implementation details like porting versus emulation.
On the other hand, I think that any effort put into improving Wine is well spent, that will truly benefit many people over the long term.
If it can run games, then it can do a lot more. Double duh.
It's much more productive to practically solve real problems right now, than to argue over how you would solve imaginary political problems in the ideal world, if only the Supreme Court appointed you Dictator and Congress burned the Constitution in your honor. That job's already taken.
Of course I talked to people from Maxis and EA corporate, because I was a Maxis employee at the time. I worked with Will Wright on The Sims for three years, developing the character animation system and user interface. Now I work with Maxis/EA as a contractor. Will and other people at EA suggested I talk to the people at Loki myself, which is what I did.
Why do you say Scott Draeker is not the person to talk to about porting The Sims to Linux? Is there someone else at Loki I should have been talking to instead? Or some other company than Loki I should have approached instead?
Please clarify just what you mean by "...not to mention the fact that Hopkin's previous work is enough to get him dismissed out of hand by any Unix user or game company employee."?
What previous work do you mean?
I hope you at least appreciate that I'm taking the time to personally answer your message and directly address all of your accusations, instead of copping a "go away kid, you're bothering me" attitude.
If you're going to play fast an loose with the definition of "emulator", even though the name "WINE" means "Wine Is Not an Emulator",
then you should accept that Wine is also an "accelerator", in the sense that it replaces the slow inefficient Windows file system, virtual memory and networking with Linux.
So let's just agree to call Wine an "accemulator".
Games spend most of their time rendering graphics, drawing pixels on the screen, mixing sound, and moving big blocks of memory around. Everything else in-between gets lost in the noise.
These days, the cost of the wrappers and even the game simulation itself is lost in the noise, compared to the time spend rendering and reading media from disk. That certainly applies to The Sims, and many other games as well.
The trick to making Wine work well is having an efficient set of 3D and 2D rendering libraries, file system, network and virtual memory system behind those wrappers.
Draeker assumes that the readers of his response as well as all of his customers are on a religious Jihad against Windows.
But I think it's a bad idea to narrowly limit your customer base to one particular brand of religious zealot, for no good reason.
He says his customers demand more than Windows software can offer, but how can he deliver that if Loki is only porting games straight across, but not putting much effort into substantially redesigning them to take real advantage of Linux, or even developing a new games from the ground up, unlike anything that's ever been seen on Windows?
Native ports certainly benefit from the robust, efficient Linux virtual memory and file system, but so do games running under Wine.
Perhaps Loki should try putting more original creative development effort into the games they port, to really take substantial advantage of Linux features that you can't get through emulation.
When I ported SimCity Classic to Unix from 1991 to 1993, I took the time to rewrite all of the graphics code and user interface from scratch (twice: first in PostScript, then in TCL), and added unix-specific features to the game like
scalable graphics
using
NeWS PostScript, and
multi-player support using
X11 networking.
Maybe Loki should change their approach, take some of their single player games, and really exploit Linux by turning them into networked multi player games, like I did with SimCity classic. Then they might have an argument against Transgaming's assertion that Wine makes their current approach to porting obsolete.
I worked full time at Maxis on The Sims for three years, and all that time I kept the idea of porting The Sims to other platforms in mind. So I wrote code as portably as I had time to, and thought a lot about what would need to be done.
I evangelised to my co-workers and managers at Maxis about how I thought Loki would be the ideal company to port The Sims to Linux. Since there really isn't much demand for a Linux port, I proposed doing a Mac port in a way that would facilitate them both. Before The Sims was ever released, I wrote and sent a proposal around Maxis, outlining how to port The Sims to the Mac and Linux, using SDL and Open GL.
I met Scott Draeker at the Game Developers conference on March 7 2000, about a month after The Sims shipped on Feb 4. I suggested that Loki port The Sims to Linux, because I was optimistic that it was going to be a popular game. He didn't seem to think so, and brushed me off, with a "go away kid, you're bothering me" attitude.
But I gave Scott Draeker the benefit of the doubt, that he was just tired after a long day in the trade show booth, and not really as curt and indifferent to the idea as he seemed.
Once The Sims shipped, I left my full time job at Maxis to work on some of my own projects, but I kept working on The Sims for Maxis as a contractor. I worked on content creation tools, developed Transmogrifier and other stuff. I still have legitimate access to The Sims source code, and I keep Will Wright up to date on what I'm doing.
As a proof of concept, I started porting The Sims to Linux on my own time. I hoped to overcome the skepticism of some people at Maxis, as well as Scott Draeker at Loki, by demonstrating that it was indeed possible, and experimenting to find the best approach empirically.
My goal was to find the best approach to getting The Sims to run on Linux. Not just to use one particular technology or another. The end result is what matters most, not the way it's implemented.
Thanks to the encouragement of John Gilmore, I certainly did consider using Wine, but at the time it was nowhere near sufficient. (But since then, Transgaming has made astounding progress with Wine, and it's now obviously quite sufficient, to my delight.)
So I used SDL to do a native port of The Sims to Linux, and got most of the game running quite well, except for drawing the people and roofs (which would require hacking a system memory back end to Mesa), and sound (which would require using OpenAL, with which I hoped Loki would have been able to help me).
I was actually quite surprised at how quickly I was able to get a native port of The Sims running on Linux. My previous experience porting SimCity to Unix took a lot more time. But the tools are much better and computers are way faster now. And of course I was more familiar with the code base.
I offered the results of my work to Loki on reasonable terms. They didn't seem interested. I talked to some people at Maxis about it, and they said that Loki had been discussing it with Maxis, but they hadn't heard back from them in a long time.
I finally got some brusque uninformative email from Scott Draeker, and we talked briefly on the phone, but he said that he was really busy, he had a lot of paperwork in progress that had to be finish, and he'd get back to me some time. So I stopped working on the port, and waited to hear back from him...
I considered approaching other Linux game companies about porting The Sims to Linux, but decided to wait, because I still believed Loki was the best company to do it, and I did not want to undercut their ongoing negotiations with Maxis. Just the opposite -- I encouraged Maxis to quickly reach a fair deal with Loki, because I believed we could work together to get it to market fast. But Maxis wasn't the only company dragging their feet.
Months later, I finally read on the net that Loki had decided not to port The Sims to Linux, because "Maxis wanted too much money". By that time, The Sims had been topping the charts for months, so of course Maxis was asking a lot for it.
What I didn't know at the time, was that Loki was soon to declare Chapter 11. So it was actually a combination of Maxis wanting a lot for it, and Loki not having any money. But of course Draeker didn't mention that fact at the time.
But fortunately, my time and effort porting The Sims to Linux was not wasted, because Maxis needed The Sims to run on Linux, as the multi-player game server for The Sims Online.
So I used the original port at a guide, and more cleanly ported and optimized the newer Sims Online code to Linux again, making a headless build without all the graphics (removing SDL and DirectX). But the Linux build of the code is for Maxis's internal use on their servers, not as a commercial product for Linux.
I made the same code base compile on both Windows and Linux, and both with or without graphic. The SDL graphics code still works on Linux, but it's only used for diagnostic and debugging purposes, and not for production.
It's nice to run the graphical build of the Linux server in order to see what the server's doing during development. But the production server can't require a connection to an X server, and doesn't read in any graphics, because many must run on the same machine in parallel.
Even though Loki blew their chance to port The Sims to Linux, I still wanted to see it happen anyway. But because so much time had passed since the release of The Sims, I would rather put my efforts into finishing porting The Sims Online client to Linux, and work with some other company than Loki.
But I discussed it with Will Wright, and he explained to me in his reasonable, thoughtful, well considered manner: a native port of The Sims Online client to Linux would not be practical as a commercial product, because of its nature as a dynamically updated online game.
The way The Sims Online and many other online games work, is that the server and the clients all run the same deterministic simulation in lock step, funneling any user requested changes through a central "headless" server, so the actions can be scheduled to happen at the same time in all parallel universes.
So the server simulation and protocol must be *EXACTLY* the same as the clients, or all hell will break loose. Any online game, no matter what the architecture, requires that the client and the servers be in sync. That's not so hard if the game is trivial like Othello or Quake, but The Sims network protocol is much more complex and quite sensitive to incompatibilities.
So there is absolutely no way to support any more than one client executable, because the clients and servers must be updated together in real time by downloading patches, just like Ultima Online and other games.
In order for there to be a Linux port (or a Mac port), it would necessarily have to be done in-house at Maxis, built off of the same code tree, developed in parallel.
It is simply not possible for a third party developer like Loki to stay in sync with the ongoing development at Maxis of The Sims Online. That would require enormous overhead and resources on the part of Maxis, all for an extremely negative return on investment: it would extremely complicate and slow down the development process, require extra programmers, quality assurance people with Linux skills, etc.
Cross platform development requires a LOT of overhead -- please believe me if you haven't tried it. The gross income from selling Linux clients would be infintesimal, and would never outweigh the enormous cost of development. There is absolutely no way EA would ever allow Maxis to flush their stock holders' money down the toilet like that.
That is the harsh, real, undenyable reason that Wine is the most practical and economical way to run games on Linux.
I am quite pleased that Transgaming has developed Wine so far that it can now actually run The Sims! What's wrong with one Linux company coming up with a free and practical implementation of a great idea, that puts another Linux company out of business? Think of it as evolution in action, to quote somebody whose name doesn't deserve mentioning.
The way Transgaming has improved Wine is so generally beneficial, that running The Sims Online on Linux the very day it's release on Windows, is now practically in the bag! With Loki's pace and approach, there was never any hope of that.
The thing that matters most is the fact that a game DOES run on Linux, not HOW it's implemented. Real People in the Real World don't care about religious issues like if it's running under Wine or if it's a native port. It takes over the whole screen anyway, so what does it matter? The end experience is the same.
Thanks to the generality of Wine, now there exists a whole spectrum of solutions, from binary emulation, to recompilation, all the way to native porting. Wine could be an extremely useful tool in the process of doing a fully native port.
Those irrational people who reject Wine for purely political reasons, are doing much more damage to Linux than Wine will ever do. They're trying to argue that trivial invisible implementation details matter so much to users, that they would reject Linux if their favorite games weren't native ports, even if they ran under Wine. That's totally ridiculous.
The fact that a game runs on Linux at all, is MUCH more important than whether or not it's a native port.
Another advantage to Transgaming's Wine approach, is that all the existing free external tools like Transmogrifier, SimShow, Facelift, Art Studio,
Home Crafer, Menu Edit, File Cop, and the many third party tools, will all probably run under Wine. And if they don't, Transgaming considers it a bug in Wine, and wants to fix it. Most of those tools will never be ported native to Linux, so the only way to use them is though Wine.
I just can't believe that people would attack Transgaming for all that they've done and given back to the community. The alternative is for Linux to simply hold its breath and go without most games.
The consequences of that alternative are dreadful, and much more harmful to Linux than the imaginary consequences of Wine. Now that Wine has been improved enough to run games like The Sims, it has so many other wonderful uses as well. Why would you ever consider sacrificing all that?
It's not worth attacking Wine out of political correctness, in order to wait around forever for native ports that will never happen.
Please don't cut off your nose to spite your face.
Micropoly is the Microsoft Monopoly Game! It's a parody of Microsoft that's fun to play, a free board game based the rules of Anti-Monopoly, and a political statement protected under the First Amendment.
This web site exists to freely distribute the full set of graphics and rules for Micropoly, in the "open source" spirit of the original folk game monopoly invented by an Atlantic City Quaker woman.
You are encouraged to download the graphics, print out copies of the game set for yourself and friends, and have fun playing Micropoly!
Micropoly synergistically illustrates several important points, by drawing parallels between the time of the Great Depression and the end of the Twentieth Century:
Monopolies are bad, and competition is good.
The original rules of monopoly require everyone to play as a monopolist. That's why companies like Microsoft and Parker Brothers like the lesson it teaches: being a monopolist is good, and in order to win you have to make the biggest monopoly. But the rules of Anti-Monopoly divide players into monopolists versus competitors, resulting in a dynamic, unpredictable, more interesting game. Competition has the same benefits in real life!
The "open source" philosophy has been around a long time before computers.
The Atlantic City Quaker woman who invented the original board game spread it around to her friends for free. She would invite people over to play, and they loved the game, so they made their own copies with crayons on oil cloth. This free folk game spread around the country and was played by many people, long before Parker Brothers knowingly decided pirated it. Today we have computer networks, desktop publishing, color printers, and the "open source" model of software development, so it is much easier to spread the free Micropoly game all over the world.
Big companies abuse the patent and legal systems to pirate and exploit other peoples original ideas.
Parker Brothers pirated monopoly from its original inventors, illegitimately patented an "open source" folk game, perpetrated an extremely successful propaganda campaign to convince the world that Monopoly(TM) was invented by Charles B Darrow, and aggressively drove other companies out of business with frivolous lawsuits.
They waged a nasty 10 year legal assault on Ralph Anspach, inventor of the "Anti-Monopoly" game, ruining his successful game company, even though his case finally made it to the Supreme Court and won!
As a result of his hard fought victory, the true story of Parker Brother's Billion Dollar Monopoly Swindle has been published for all to read, and it's safe to call a game "anything-opoly".
We are very grateful that he never gave up, and won in spite of Parker Brothers' dirty tricks. We thank him, because he made it possible for us to publish Micropoly, and generously offered to let us use his superior Anti-Monopoly rules, which so perfectly illustrate the point of Micropoly.
The similarities in the monopolistic behaviors of Parker Brothers and Microsoft should be obvious.
OpenOpoly
The software used to produce Micropoly will be freely distributed, as well as the Micropoly content, to serve as an example of how to make your own personalized monopoly game.
We are developing a free "Openopoly" architecture based on XML, whose purpose is to automate the production of custom monopoly games, both printed board games and multi-player online computer games.
Micropoly will be the first example of such a custom game, so anyone will be able to drop in their own text and graphics, turn the crank, and produce a version of monopoly localized for their own city, university, company, church, sports team, or favorite political cause.
In a nutshell, nobody needed Broadway, because it was designed for totally the wrong reasons.
Broadway was trying to solve an extremely complex non-problem for which it was never intended, that doesn't do anyone any good.
The only people who need Broadway are the people desparately promoting trash like X11 and Motif and CDE, who were put out of business by the web, Linux, Gnome, KDE, TCL/Tk, Python, and other useful technology.
What I said about the ICCCM would certainly apply to Broadway, had it ever gotten off the ground:
"In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry's standard naked emperor."
And of course JWZ's comment still applies:
"Using these toolkits is like trying to make a bookshelf out of mashed potatoes."
- Jamie Zawinski
And here are some notes on why X11 window management has gone so horribly wrong, which helps to explain why Broadway is necessarily such a horrible failure.
Oh we're filling the bottle for Ronnie
Filling it up to the brim
And we'll never rest
Till we all pass the test
'Cause we all think so highly of him.
Oh we're filling the bottle for Ronnie
And we'll never kick up a fuss
'Cause we're only doing to that little bottle
What Ronnie's been doing to us
Urine Trouble
(c) Copyright 1986 tojo
There's information in your wee-wee
Reveals the secrets of your lifestyle
Detects if you've been smoking thai weed
On alternate Fridays in the middle of the night
(Chorus 1)
We need a sample of your yellow discharge
So go into the bathroom and fill up this jar
We'll send the sample to the boys down in the lab
Dressed in plaid,
How drab
They've got your bladder on the witness stand
The perpetrators are among us
Their numbers growing like a rampant fungus
They think their habits are private
But urinalysis will clearly deny it
(Chorus 2)
You're in Urine Trouble
You're in Urine Trouble
They've got your bladder on the witness stand
A memo from the office of the president
We must submit or he'll fire the whole darn bunch
This executive decision
Arrived at during a three martini lunch
(Chorus 1)
"Jones, I'd like to see you in my office right away!"
"Y-yes, sir!"
"Close the door behind you, Jones"
"R-right away, sir!"
"Miss Nelson, hold all my calls"
"The fellas from the lab have submitted this
It's a list of the substances in your piss
It seems your performance, while fine on the surface
Is really just a front for your deviant purpose!"
"I can't believe we made you employee of the week
When all the while you were a closet freak
You thought you could hide behind your perfect attendence
Just to conceal your drug dependence!"
(Chorus 2)
There's information in your wee-wee
Reveals the secrets of your lifestyle
Detects if you've been smoking thai weed
On alternate Fridays in the middle of the night
(Chorus 1)
"Oh No!"
"What's wrong?"
"Remember that joint I toked last month?"
"Yeah"
"I think I'm having a flashback!"
"I want to operate heavy machinery!"
"I want to cause an industrial accident!"
"I want to exercise poor judgement!"
"I want to unwisely make a critical decision!"
You're in Urine Trouble
You're in Urine Trouble
They've got your bladder on the witness stand
You're in Urine Trouble
You're in Urine Trouble
They've got your bladder on the witness stand
Most people are just too damn dumb to recognise how great Lisp is.
The bias against Lisp is based on the simple fact that the first word that springs into most peoples pointy little heads when they hear the word "Lisp" is: "Gay". And that scares off all the homophobic repressed closet queens, which includes a large percentage of the computer industry. Especially Perl programmers, who use Perl as a means of expressing their manhood and covering up their repressed homosexual tendencies.
KMP wrote a great program on ITS called "Teach-Lisp", that helped me and other people to learn Lisp.
And he wrote a wonderful hack called "EVAL-IN-OTHER-LISP" that used an interprocess communication mechanism in ITS called "Core Link Interrupts," which enabled one Lisp to send Lisp expressions to another Lisp interpreter to evaluate. He used it to mischeviously change the output base of my Lisp process to Roman numerals, among other things. I suppose that qualifies KMP as a pioneer of "distance learning".
KMP also wrote an animal guessing game that would get upset and warn you not to use naughty words. If you didn't relent and kept on cussing, it would get angry at you, and send some email to you and KMP, telling on you and demanding an apology. So you couldn't play the game again until you emailed an apology to his program.
It's great to know KMP is still teaching lisp.
But I've always wondered: who was the bright-12-old (who's now about 28) who benefited from recycling Jerry Pournelle's account?
Date: Fri, 31 May 85 09:39 EDT
From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
To: CStacy at MIT-MC.ARPA
cc: Klotz at MIT-MC.ARPA, KMP at SCRC-STONY-BROOK.ARPA, Gumby at MIT-MC.ARPA
Subject: Pourne
Date: Fri, 31 May 85 01:11:16 EST
From: Jerry E. Pournelle <POURNE@MIT-MC.ARPA>
To: KLOTZ@MIT-MC.ARPA
I find this thoroughly distasteful. If you have some authority to order me off the net, do so. If not, leave me alone.
Personally, I'd just turn off his account. It's not like it's the first time, and he not only flaunts his use of our machines but stabs us in the back with grumblings about why he doesn't like this or that program of ours when he gets a chance. (Am thinking particularly of an article he wrote which condemned Lisp for reasons amounting to little more than his ignorance, but which cited Teach-Lisp in a not-friendly light... The man has learned nothing from his presence on MC and sets a bad example of what people might potentially accomplish there. I'd rather recycle his account for some bright 12-yr-old...)
Slashdot Mirror
I had one of the old Ricochet modems years ago before there was any security on the network. You could list out the names of all the other radio modems and poll top boxes that it could see. The pole top boxes had the names of the street intersections or buildings where they were mounted. Then you could dial into any of the pole top boxes, and remotely send them AT commands, to list out the other ones they could see, and walk around discovering the network that way.
But then my van was stolen, and my original Ricochet was in it, with a "Big Brother Inside" sticker on it. I immediately called Metricom and asked if my modem had been turned on and reported in. It had, and they checked the logs and gave me the address of the pole top box in a dangerous San Jose neighborhood. I rented a car and drove all around the neighborhood looking for my stolen van, but didn't find it. But a couple weeks later the van did show up right around that neighborhood, totally stripped.
-Don
Author of The Cyberiad, starring Trurl and Klapaucius, which inspired the game SimCity.
A articulate Polish universal fiction writer, who thinks that Philip K Dick is a Visionary Among the Charlatans.
Nobody can figure out how he writes in Polish, yet the English translations of his books are full of brilliant poetic puns and neological phonetic jokes. He's got a great translator, Michael Kandel, to say the least.
His son Tomasz Lem created and maintains his father's official Stanislaw Lem Web Site.
-Don
PS: But here's what Philip K Dick, another great writer, had to say about Stanislaw Lem to the FBI:
Philip K. Dick to the FBI, September 2, 1974
I am enclosing the letterhead of Professor Darko Suvin, to go with information and enclosures which I have sent you previously. This is the first contact I have had with Professor Suvin. Listed with him are three Marxists whom I sent you information about before, based on personal dealings with them: Peter Fitting, Fredric Jameson, and Franz Rottensteiner who is Stanislaw Lem's official Western agent. The text of the letter indicates the extensive influence of this publication, SCIENCE-FICTION STUDIES.
What is involved here is not that these persons are Marxists per se or even that Fitting, Rottensteiner and Suvin are foreign-based but that all of them without exception represent dedicated outlets in a chain of command from Stanislaw Lem in Krakow, Poland, himself a total Party functionary (I know this from his published writing and personal letters to me and to other people). For an Iron Curtain Party group - Lem is probably a composite committee rather than an individual, since he writes in several styles and sometimes reads foreign, to him, languages and sometimes does not - to gain monopoly positions of power from which they can control opinion through criticism and pedagogic essays is a threat to our whole field of science fiction and its free exchange of views and ideas. Peter Fitting has in addition begun to review books for the magazines Locus and Galaxy. The Party operates (a U..S.] publishing house which does a great deal of Party-controlled science fiction. And in earlier material which I sent to you I indicated their evident penetration of the crucial publications of our professional organization SCIENCE FICTION WRITERS OF AMERICA. "
Their main successes would appear to be in the fields of academic articles, book reviews and possibly through our organization the control in the future of the awarding of honors and titles. I think, though, at this time, that their campaign to establish Lem himself as a major novelist and critic is losing ground; it has begun to encounter serious opposition: Lem's creative abilities now appear to have been overrated and Lem's crude, insulting and downright ignorant attacks on American science fiction and American science fiction writers went too far too fast and alienated everyone but the Party faithful (I am one of those highly alienated).
It is a grim development for our field and its hopes to find much of our criticism and academic theses and publications completely controlled by a faceless group in Krakow, Poland. What can be done, though, I do not know.
-Philip K Dick
From Stanislaw Lem Questions and Answers.
His description of the "MEMEX" foretold of today's personal computers, and accurately predicted many specific features of modern window managers, web browsers and multimedia authoring tools. In 1945, Vannevar Bush clearly and accurately envisioned many useful and practical techniques to "support the massive task of making more accessible our bewildering store of knowledge". Many of his visions have been implemented in modern applications, but what he wrote points the way to other useful information management techniques that remain to be implemented.
-Don
http://www.theatlantic.com/unbound/flashbks/comput er/bushf.htm
As We May Think
By Vannevar Bush
[...]
Science has provided the swiftest communication between individuals; it has provided a record of ideas and has enabled man to manipulate and to make extracts from that record so that knowledge evolves and endures throughout the life of a race rather than that of an individual.
There is a growing mountain of research. But there is increased evidence that we are being bogged down today as specialization extends. The investigator is staggered by the findings and conclusions of thousands of other workers -- conclusions which he cannot find time to grasp, much less to remember, as they appear. Yet specialization becomes increasingly necessary for progress, and the effort to bridge between disciplines is correspondingly superficial.
Professionally our methods of transmitting and reviewing the results of research are generations old and by now are totally inadequate for their purpose. If the aggregate time spent in writing scholarly works and in reading them could be evaluated, the ratio between these amounts of time might well be startling. Those who conscientiously attempt to keep abreast of current thought, even in restricted fields, by close and continuous reading might well shy away from an examination calculated to show how much of the previous month's efforts could be produced on call. Mendel's concept of the laws of genetics was lost to the world for a generation because his publication did not reach the few who were capable of grasping and extending it; and this sort of catastrophe is undoubtedly being repeated all about us, as truly significant attainments become lost in the mass of the inconsequential.
The difficulty seems to be, not so much that we publish unduly in view of the extent and variety of present day interests, but rather that publication has been extended far beyond our present ability to make real use of the record. The summation of human experience is being expanded at a prodigious rate, and the means we use for threading through the consequent maze to the momentarily important item is the same as was used in the days of square-rigged ships.
[...]
A new symbolism, probably positional, must apparently precede the reduction of mathematical transformations to machine processes. Then, on beyond the strict logic of the mathematician, lies the application of logic in everyday affairs. We may some day click off arguments on a machine with the same assurance that we now enter sales on a cash register. But the machine of logic will not look like a cash register, even of the streamlined model.
So much for the manipulation of ideas and their insertion into the record. Thus far we seem to be worse off than before -- for we can enormously extend the record; yet even in its present bulk we can hardly consult it. This is a much larger matter than merely the extraction of data for the purposes of scientific research; it involves the entire process by which man profits by his inheritance of acquired knowledge. The prime action of use is selection, and here we are halting indeed. There may be millions of fine thoughts, and the account of the experience on which they are based, all encased within stone walls of acceptable architectural form; but if the scholar can get at only one a week by diligent search, his syntheses are not likely to keep up with the current scene.
Selection, in this broad sense, is a stone adze in the hands of a cabinetmaker. Yet, in a narrow sense and in other areas, something has already been done mechanically on selection. The personnel officer of a factory drops a stack of a few thousand employee cards into a selecting machine, sets a code in accordance with an established convention, and produces in a short time a list of all employees who live in Trenton and know Spanish. Even such devices are much too slow when it comes, for example, to matching a set of fingerprints with one of five million on file. Selection devices of this sort will soon be speeded up from their present rate of reviewing data at a few hundred a minute. By the use of photocells and microfilm they will survey items at the rate of a thousand a second, and will print out duplicates of those selected.
This process, however, is simple selection: it proceeds by examining in turn every one of a large set of items, and by picking out those which have certain specified characteristics. There is another form of selection best illustrated by the automatic telephone exchange. You dial a number and the machine selects and connects just one of a million possible stations. It does not run over them all. It pays attention only to a class given by a first digit, then only to a subclass of this given by the second digit, and so on; and thus proceeds rapidly and almost unerringly to the selected station. It requires a few seconds to make the selection, although the process could be speeded up if increased speed were economically warranted. If necessary, it could be made extremely fast by substituting thermionic-tube switching for mechanical switching, so that the full selection could be made in one one-hundredth of a second. No one would wish to spend the money necessary to make this change in the telephone system, but the general idea is applicable elsewhere.
[...]
The real heart of the matter of selection, however, goes deeper than a lag in the adoption of mechanisms by libraries, or a lack of development of devices for their use. Our ineptitude in getting at the record is largely caused by the artificiality of systems of indexing. When data of any sort are placed in storage, they are filed alphabetically or numerically, and information is found (when it is) by tracing it down from subclass to subclass. It can be in only one place, unless duplicates are used; one has to have rules as to which path will locate it, and the rules are cumbersome. Having found one item, moreover, one has to emerge from the system and re-enter on a new path.
The human mind does not work that way. It operates by association. With one item in its grasp, it snaps instantly to the next that is suggested by the association of thoughts, in accordance with some intricate web of trails carried by the cells of the brain. It has other characteristics, of course; trails that are not frequently followed are prone to fade, items are not fully permanent, memory is transitory. Yet the speed of action, the intricacy of trails, the detail of mental pictures, is awe-inspiring beyond all else in nature.
Man cannot hope fully to duplicate this mental process artificially, but he certainly ought to be able to learn from it. In minor ways he may even improve, for his records have relative permanency. The first idea, however, to be drawn from the analogy concerns selection. Selection by association, rather than indexing, may yet be mechanized. One cannot hope thus to equal the speed and flexibility with which the mind follows an associative trail, but it should be possible to beat the mind decisively in regard to the permanence and clarity of the items resurrected from storage.
Consider a future device for individual use, which is a sort of mechanized private file and library. It needs a name, and, to coin one at random, "memex" will do. A memex is a device in which an individual stores all his books, records, and communications, and which is mechanized so that it may be consulted with exceeding speed and flexibility. It is an enlarged intimate supplement to his memory.
It consists of a desk, and while it can presumably be operated from a distance, it is primarily the piece of furniture at which he works. On the top are slanting translucent screens, on which material can be projected for convenient reading. There is a keyboard, and sets of buttons and levers. Otherwise it looks like an ordinary desk.
In one end is the stored material. The matter of bulk is well taken care of by improved microfilm. Only a small part of the interior of the memex is devoted to storage, the rest to mechanism. Yet if the user inserted 5000 pages of material a day it would take him hundreds of years to fill the repository, so he can be profligate and enter material freely.
Most of the memex contents are purchased on microfilm ready for insertion. Books of all sorts, pictures, current periodicals, newspapers, are thus obtained and dropped into place. Business correspondence takes the same path. And there is provision for direct entry. On the top of the memex is a transparent platen. On this are placed longhand notes, photographs, memoranda, all sorts of things. When one is in place, the depression of a lever causes it to be photographed onto the next blank space in a section of the memex film, dry photography being employed.
There is, of course, provision for consultation of the record by the usual scheme of indexing. If the user wishes to consult a certain book, he taps its code on the keyboard, and the title page of the book promptly appears before him, projected onto one of his viewing positions. Frequently-used codes are mnemonic, so that he seldom consults his code book; but when he does, a single tap of a key projects it for his use. Moreover, he has supplemental levers. On deflecting one of these levers to the right he runs through the book before him, each page in turn being projected at a speed which just allows a recognizing glance at each. If he deflects it further to the right, he steps through the book 10 pages at a time; still further at 100 pages at a time. Deflection to the left gives him the same control backwards.
A special button transfers him immediately to the first page of the index. Any given book of his library can thus be called up and consulted with far greater facility than if it were taken from a shelf. As he has several projection positions, he can leave one item in position while he calls up another. He can add marginal notes and comments, taking advantage of one possible type of dry photography, and it could even be arranged so that he can do this by a stylus scheme, such as is now employed in the telautograph seen in railroad waiting rooms, just as though he had the physical page before him.
All this is conventional, except for the projection forward of present-day mechanisms and gadgetry. It affords an immediate step, however, to associative indexing, the basic idea of which is a provision whereby any item may be caused at will to select immediately and automatically another. This is the essential feature of the memex. The process of tying two items together is the important thing.
When the user is building a trail, he names it, inserts the name in his code book, and taps it out on his keyboard. Before him are the two items to be joined, projected onto adjacent viewing positions. At the bottom of each there are a number of blank code spaces, and a pointer is set to indicate one of these on each item. The user taps a single key, and the items are permanently joined. In each code space appears the code word. Out of view, but also in the code space, is inserted a set of dots for photocell viewing; and on each item these dots by their positions designate the index number of the other item.
Thereafter, at any time, when one of these items is in view, the other can be instantly recalled merely by tapping a button below the corresponding code space. Moreover, when numerous items have been thus joined together to form a trail, they can be reviewed in turn, rapidly or slowly, by deflecting a lever like that used for turning the pages of a book. It is exactly as though the physical items had been gathered together from widely separated sources and bound together to form a new book. It is more than this, for any item can be joined into numerous trails.
The owner of the memex, let us say, is interested in the origin and properties of the bow and arrow. Specifically he is studying why the short Turkish bow was apparently superior to the English long bow in the skirmishes of the Crusades. He has dozens of possibly pertinent books and articles in his memex. First he runs through an encyclopedia, finds an interesting but sketchy article, leaves it projected. Next, in a history, he finds another pertinent item, and ties the two together. Thus he goes, building a trail of many items. Occasionally he inserts a comment of his own, either linking it into the main trail or joining it by a side trail to a particular item. When it becomes evident that the elastic properties of available materials had a great deal to do with the bow, he branches off on a side trail which takes him through textbooks on elasticity and tables of physical constants. He inserts a page of longhand analysis of his own. Thus he builds a trail of his interest through the maze of materials available to him.
And his trails do not fade. Several years later, his talk with a friend turns to the queer ways in which a people resist innovations, even of vital interest. He has an example, in the fact that the outraged Europeans still failed to adopt the Turkish bow. In fact he has a trail on it. A touch brings up the code book. Tapping a few keys projects the head of the trail. A lever runs through it at will, stopping at interesting items, going off on side excursions. It is an interesting trail, pertinent to the discussion. So he sets a reproducer in action, photographs the whole trail out, and passes it to his friend for insertion in his own memex, there to be linked into the more general trail.
Wholly new forms of encyclopedias will appear, ready made with a mesh of associative trails running through them, ready to be dropped into the memex and there amplified. The lawyer has at his touch the associated opinions and decisions of his whole experience, and of the experience of friends and authorities. The patent attorney has on call the millions of issued patents, with familiar trails to every point of his client's interest. The physician, puzzled by a patient's reactions, strikes the trail established in studying an earlier similar case, and runs rapidly through analogous case histories, with side references to the classics for the pertinent anatomy and histology. The chemist, struggling with the synthesis of an organic compound, has all the chemical literature before him in his laboratory, with trails following the analogies of compounds, and side trails to their physical and chemical behavior.
The historian, with a vast chronological account of a people, parallels it with a skip trail which stops only on the salient items, and can follow at any time contemporary trails which lead him all over civilization at a particular epoch. There is a new profession of trail blazers, those who find delight in the task of establishing useful trails through the enormous mass of the common record. The inheritance from the master becomes, not only his additions to the world's record, but for his disciples the entire scaffolding by which they were erected.
Thus science may implement the ways in which man produces, stores, and consults the record of the race. It might be striking to outline the instrumentalities of the future more spectacularly, rather than to stick closely to methods and elements now known and undergoing rapid development, as has been done here. Technical difficulties of all sorts have been ignored, certainly, but also ignored are means as yet unknown which may come any day to accelerate technical progress as violently as did the advent of the thermionic tube. In order that the picture may not be too commonplace, by reason of sticking to present-day patterns, it may be well to mention one such possibility, not to prophesy but merely to suggest, for prophecy based on extension of the known has substance, while prophecy founded on the unknown is only a doubly involved guess.
[...]
In the outside world, all forms of intelligence whether of sound or sight, have been reduced to the form of varying currents in an electric circuit in order that they may be transmitted. Inside the human frame exactly the same sort of process occurs. Must we always transform to mechanical movements in order to proceed from one electrical phenomenon to another? It is a suggestive thought, but it hardly warrants prediction without losing touch with reality and immediateness.
Presumably man's spirit should be elevated if he can better review his shady past and analyze more completely and objectively his present problems. He has built a civilization so complex that he needs to mechanize his records more fully if he is to push his experiment to its logical conclusion and not merely become bogged down part way there by overtaxing his limited memory. His excursions may be more enjoyable if he can reacquire the privilege of forgetting the manifold things he does not need to have immediately at hand, with some assurance that he can find them again if they prove important.
The applications of science have built man a well-supplied house, and are teaching him to live healthily therein. They have enabled him to throw masses of people against one another with cruel weapons. They may yet allow him truly to encompass the great record and to grow in the wisdom of race experience. He may perish in conflict before he learns to wield that record for his true good. Yet, in the application of science to the needs and desires of man, it would seem to be a singularly unfortunate stage at which to terminate the process, or to lose hope as to the outcome.
Copyright © 1945 by Vannevar Bush. All rights reserved.t er/bushf.htm
The Atlantic Monthly; July, 1945; As We May Think; Volume 176, No. 1; pages 101-108.
http://www.theatlantic.com/unbound/flashbks/compu
The fewer reasons anyone has to boot over to Windows, the longer time they spend running Linux.
Wine solves many more substantial real world problems, that far outweight any trivial ideological problems it causes.
Moore's Law guarantees that Wine's way will win. I've developed on The Sims code on a now-obsolete 500 MhZ laptop, running Visual C++ and Outlook Express at the same time. When it's running on a modern run-of-the-mill 1 Gigahertz desktop, there are plenty of cycles to burn.
All the time taken up by the layers of wrapper code, and even the simulation itself, is totally lost in the noise, compared to the time spent rendering, mixing sound, moving memory around, and reading from disk.
-Don
When I first saw SimCity, I was an undergraduate at the University of Maryland, working on user interface research and development for Ben Shneiderman at the Human Computer Interaction Lab.
As a programmer and user interface designer, I dreamed of understanding how SimCity worked, and having a chance to redesign its user interface (optimize it to run fast, enable scripting, use pie menus, display multiple views, support multi player colaboration, etc).
I was quite interested in cellular automata and visual programming and user interface design (which I still am). So I naturally saw SimCity as a complex colorful organic CA; with easy-to-use built-in real-time painting, zoning and bulldozer tools; like a beautiful abstract visual data flow programming language, with its own grammar of roads, parks and buildings; that just happened to look and behave like a city.
And I posted the following review of SimCity to comp.theory.cellular-automata:
From mimsy!brillig.umd.edu!don Fri Dec 29 13:03:18 EST 1989
Article 292 of comp.theory.cell-automata:
Path: mimsy!brillig.umd.edu!don
From: don@brillig.umd.edu (Don Hopkins)
Newsgroups: comp.theory.cell-automata
Subject: SimCity
Summary: Urban development simulation where it belongs: in a video game!
Message-ID: <21436@mimsy.umd.edu>
Date: 26 Dec 89 13:37:09 GMT
Sender: news@mimsy.umd.edu
Reply-To: don@brillig.umd.edu (Don Hopkins)
Organization: U of Maryland, Dept. of Computer Science, Human Computer Interaction Lab, Coll. Pk., MD 20742
Lines: 28
I just got a chance to play SimCity! It's like a drawing program that lets you build cities, by zoning districts, putting down power plants and football stadiums, wiring up the power grid, laying down roads and railroads. The simulation is actually running *while* you're constructing it! It acts like cellular automita with very high level rules -- it keeps track of each cell's population, land value, pollution, and many other factors, and the rules that govern how the zones develop are based on the state of neighboring zones, and other global factors (tax rate, etc). Districts that you've zoned don't come online and start developing until they're hooked into the power grid, by being connected through power line cells or adjacent buildings. Buildings seem to "feed" off of people brought in by roads and railroads. Residential zones in busy districts grow into high-rise apartment buildings. Traffic patterns develop on the roads, and you can see little cars zooming around based on the population of the area, and the flow of the roads! Once you build an airport, a helicoptor flies around the city and reports on heavy traffic, encouraging you to redesign the roads in that area!
You may wonder what traffic copters have to do with cellular automita. You just have to play it yourself to understand.
SimCity is absolutely the most amazing game I've seen on the Macintosh to date! (It's available on other computers like the Amiga, as well.) The graphics and animation are beautiful. I'll leave it at that -- mere text cannot do it justice.
-Don
I did everything within my power to help Loki get a native port of The Sims for Linux to market as soon as possible. They're the ones who dragged their feet, left me hanging, and failed to take advantage of the situation.
I still don't understand what it is that I did, that makes you so mad. It's more like you're mad at me for something I didn't do, or allowed to happen by my inaction.
The fact remains that you've visciously attacked me, and gotten all of your facts wrong. So I think you owe me an explanation or an apology.
-Don
PS: You said:
The facts you got wrong: The price wasn't $80, it was $49. I'm not "still charging" anything, because I haven't sold it for years before Loki ever existed. At the time (1993), $49 was dirt cheap for a Unix workstation game, compared to $150 for Aviator. Single player SimCity was $49 in 1993 dollars, while Loki's SimCity currently costs $49.95 in 2001 dollars. So Loki's SimCity is actually $.95 more expensive, so you're wrong about it costing less than mine. And you can't buy Multi Player SimCity from Loki for any price, while I was asking only $89 in 1993, which certainly didn't cover my time and effort. Lining my pockets??! I haven't seen a royalty check in many years, and the few I got were quite small. And I just don't understand the rest of your criticisms.
-Don
I'm just telling you how it is, not how it should be in the idea world. Ultima Online and other games download patches over the network, to keep the clients in sync with the server. That's how The Sims Online will work too.
I'm not just making this up. I specifically asked Will Wright about the feasability of a Linux port of The Sims Online client. (In case you don't know, he's the founder of Maxis and designer of The Sims and SimCity.)
I'm just telling you what he told me, and what I know first hand from working with the code since 1997. I'm familiar with The Sims source code, because I wrote a bunch of it, worked with all of it, ported it native to Linux, and optimized it.
The Sims wasn't designed to be a multi player game in the first place, and it's the result of more than 8 years of evolutionary design, redesign, tweaking and overhaul.
In other words, the code is hell ugly, but it does what it's supposed to. That probably applies to a lot of other games, too. The simulator is quite tangled up with the rest of the code, and it's a lot of hard work to sort it all out into a networked multi player game.
Please believe me when I say that The Sims Online server wouldn't be able to tolerate an out-of-date client. It pains me to think about how horribly it would crash. And that applies to a lot of other online games, for economical if not technological reasons.
No online game developer in their right mind would ever choose to take on such a nightmare of supporting out-of-date clients, when they can simply download patches, which is the standard industry practice.
Ultima Online has been doing it successfully for years, and it wouldn't have worked any other way. Online games, especially community oriented ones like Ultima Online and The Sims Online, constantly evolve in response to the needs their users.
For any non-trivial online game, evolution requires dynamically patching client binaries, and changing the server in ways that depend on the client updates.
It's extremely difficult and expensive to develop, maintain and support more than one platform, especially when you must download client updates.
Even if cross platform development were effortless and free, it would still be impossible for a third party company like Loki to develop a native port of a game like The Sims Online. That is because it would still require all clients of every platform to be synchronized and updated at the same time, which would be impossible if third party developers were involved.
On the other hand, the Wine approach should hopefully make it possible to run The Sims Online client, the very day it's released for Windows, and even download and apply the patches in real time.
It'll probably require a bit of testing and coordination between Transgaming and Maxis to make sure that it works well, but obviously they already have a good working relationship.
Wine is a win-win deal for everyone, not just Transgaming.
To the players, it means that not only can they play The Sims on Linux, but they can also run the free content creation tools like Transmogrifier, Art Studio and other third party tools. Without Wine, you will never be able to run most of those tools on Linux. They won't ever be ported to Linux, because they were written over time by many different people.
To Maxis, it means they will sell more copies of The Sims, and they will have more paying Sims Online subscribers, without having to invest resources or effort in developing cross platform clients.
So please stop trying to blame all your problems on Wine. Wine solves many more substantial real world problems, that far outweight any trivial ideological problems it causes. Attacking Wine for the good of Linux is like cutting off your nose to spite your face.
Please stop trying to censor and sabotage what other people want to do with their own computers. If Wine offends you so much, then simply don't use it!
-Don
"Congratulations Don, you could have been an innovator in these times of bad sales for Linux ports, and yet you choose to be hurting the market with allowing non-native ports under your nose. Thanks for nothing." -Time Doctor
Imagine John Candy, making the funny "quotation marks" in the air with his finger as he rants and raves:
Thank you for "analysing" my "problem", mister "Time Doctor," sir.
Oh, so I "choose" to be "hurting" the market? Just what am I "doing" that's "causing" so much "damage"?
So I'm "allowing" these "non-native" ports, huh? Oh, really?
"Allowing"? That's not very "active". Maybe I should get off my "passive" ass and do something more?
Would you rather I "prohibit" instead of "allowing"? How do you suggest I go about "prohibiting" other people from running "The Sims" on "Wine"?
Should I have somehow "prohibited" Loki from doing a "native" port, instead of trying to "cooperate" with them?
Or am I the one "responsible" for "allowing" Loki to "fail"?
How could I have "prohibited" Transgaming from getting away with improving Wine? By visciously "attacking" them in public, in spite of all the wonderfully useful work they've done? Is that what you mean?
So "get" to the "point": what exactly have I done to "allow" this "hurting" of the market?
Was it by "porting" The Sims to run "native" on Linux myself?
How did that "allow" Loki to fail? Or "allow" Transgaming to succeed? Is it all really my "fault"?
To cop an attitude from Scott Draeker, "go away kid, you're bothering me".
-Don
The price for a single player license is $49. There's nothing wrong with charging more for the multi player version of SimCity game, especially after I put literally years of my own original work into designing and implementing it, using my own equipment.
I was not paid for my time, and the only way to recoup my investment of time and effort was through royalties on sales, which didn't come close, believe me.
Remember that this was 1993, and the market for games on Unix workstations was extremely small at the time. The price of Aviator, the only other commercial Unix game I knew of, was $150. Aviator was a multi player game that you could run over the network, and I charged a lot less than Aviator cost for the multi player version of SimCity.
Time Doctor, please realise that the extremely foolish religious fanaticism of people like YOU is the reason that there will never be any successful commercial games developed for Linux.
-Don
PS: Oh, and Time Doctor: for someone who obviously doesn't read messages before he replies to them, you shouldn't go around telling other people to do what you won't bother to:
That is what I call pure unbridled hypocrisy.
First of all, I started porting SimCity to Unix in back in 1991, and DUX published multi player X11 SimCity for Unix 1993, which is reviewed here. Before that, I released HyperLook SimCity for NeWS in 1992, which was awarded "Product of the year 1992" from Unix World magazine (in the Jan 1993 issue).
Secondly, you have the price wrong -- it wasn't $80. Single Player Node Locked License: $49. Multi Player Node Locked License: $89. Single Player Floating License: $129. Multi Player Floating License: $149. Such prices for Unix workstation software were unheard of at the time, and there were hardly any other commercial games available for Unix. (Despite their bluster, Loki wasn't the first Unix game company.)
For comparison: In May 1991, Curtis Priem's and Bruce Factor's "Aviator" flight simulator for the Sun workstation from Artificial Horisons sold for $150.
The authors worked for Sun designing the GX graphics accelerator board, wrote Aviator in their spare time to demonstrate the hardware, and published one of the first commercially available real time 3D games for the Sun. Good thing they had a day job.
Because right after they published it, some butt-head Sun employee posted a crack to defeat the licensing scheme to the tstech alias at Sun. They had to send around a message begging people to please delete the crack and pay for it.
I haven't made a penny off of Unix SimCity for years, because you can't buy it any more. Loki didn't exist for years after I saw my last penny from porting SimCity to Unix.
I don't know where you got your unattributed misinformation that the networking in Multi Player SimCity Classic didn't work. I first demonstrated it at the Interactive Experience of the 1993 InterCHI conference in Amsterdam. It worked just fine then, and even better now that computers and networks are faster.
Just recently in May 2001 I showed it to the MIT Media Lab sponsors and researchers, at the Digital Life confence. I demonstrated the colaborative multi player game user interface and voting dialogs, running over the network between two linux laptops, and it worked just fine. It's just not available as a product any more, and hasn't been for a long time.
I am not "repeating the market speak of native ports being bad". I am making a point, based on my own experience as well as talking with other people who I trust, like Will Wright and John Gilmore.
My point is that Wine solves many more problems than it causes, and that native ports to Linux aren't worth it, unless you put a lot of time, energy and creativity into improving the game so it substantially takes advantage of the platform.
Even then, there's no guarantee that it'll be worthwhile. There are many more important economic issues that totally override trivial technical implementation details like porting versus emulation.
On the other hand, I think that any effort put into improving Wine is well spent, that will truly benefit many people over the long term. If it can run games, then it can do a lot more. Double duh.
It's much more productive to practically solve real problems right now, than to argue over how you would solve imaginary political problems in the ideal world, if only the Supreme Court appointed you Dictator and Congress burned the Constitution in your honor. That job's already taken.
-Don
Why do you say Scott Draeker is not the person to talk to about porting The Sims to Linux? Is there someone else at Loki I should have been talking to instead? Or some other company than Loki I should have approached instead?
Please clarify just what you mean by "...not to mention the fact that Hopkin's previous work is enough to get him dismissed out of hand by any Unix user or game company employee."? What previous work do you mean?
Are you refering to my work writing The X-Windows Disaster chapter for The Unix-Haters Handbook? I wrote that AFTER porting SimCity to X11 with TCL/Tk, compared with my previous experience porting SimCity to NeWS with HyperLook.
Or has my work with pie menus for ActiveX, Internet Explorer and other crass commercial products tainted me as Politically Incorrect?
I hope you at least appreciate that I'm taking the time to personally answer your message and directly address all of your accusations, instead of copping a "go away kid, you're bothering me" attitude.
-Don
#include <stdio.h>
int foo(int i)
{
return fork() ? i : 0;
}
main()
{
fprintf("%d\n",
foo(1) + foo(2) + foo(4) + foo(8));
return 0;
}
(No fair running it to find out.)
-Don
Owch.
If you're going to play fast an loose with the definition of "emulator", even though the name "WINE" means "Wine Is Not an Emulator", then you should accept that Wine is also an "accelerator", in the sense that it replaces the slow inefficient Windows file system, virtual memory and networking with Linux.
So let's just agree to call Wine an "accemulator".
These days, the cost of the wrappers and even the game simulation itself is lost in the noise, compared to the time spend rendering and reading media from disk. That certainly applies to The Sims, and many other games as well.
The trick to making Wine work well is having an efficient set of 3D and 2D rendering libraries, file system, network and virtual memory system behind those wrappers.
-Don
He says his customers demand more than Windows software can offer, but how can he deliver that if Loki is only porting games straight across, but not putting much effort into substantially redesigning them to take real advantage of Linux, or even developing a new games from the ground up, unlike anything that's ever been seen on Windows?
Native ports certainly benefit from the robust, efficient Linux virtual memory and file system, but so do games running under Wine.
Perhaps Loki should try putting more original creative development effort into the games they port, to really take substantial advantage of Linux features that you can't get through emulation.
When I ported SimCity Classic to Unix from 1991 to 1993, I took the time to rewrite all of the graphics code and user interface from scratch (twice: first in PostScript, then in TCL), and added unix-specific features to the game like scalable graphics using NeWS PostScript, and multi-player support using X11 networking.
Maybe Loki should change their approach, take some of their single player games, and really exploit Linux by turning them into networked multi player games, like I did with SimCity classic. Then they might have an argument against Transgaming's assertion that Wine makes their current approach to porting obsolete.
-Don
-Don
I evangelised to my co-workers and managers at Maxis about how I thought Loki would be the ideal company to port The Sims to Linux. Since there really isn't much demand for a Linux port, I proposed doing a Mac port in a way that would facilitate them both. Before The Sims was ever released, I wrote and sent a proposal around Maxis, outlining how to port The Sims to the Mac and Linux, using SDL and Open GL.
I met Scott Draeker at the Game Developers conference on March 7 2000, about a month after The Sims shipped on Feb 4. I suggested that Loki port The Sims to Linux, because I was optimistic that it was going to be a popular game. He didn't seem to think so, and brushed me off, with a "go away kid, you're bothering me" attitude.
But I gave Scott Draeker the benefit of the doubt, that he was just tired after a long day in the trade show booth, and not really as curt and indifferent to the idea as he seemed.
Once The Sims shipped, I left my full time job at Maxis to work on some of my own projects, but I kept working on The Sims for Maxis as a contractor. I worked on content creation tools, developed Transmogrifier and other stuff. I still have legitimate access to The Sims source code, and I keep Will Wright up to date on what I'm doing.
As a proof of concept, I started porting The Sims to Linux on my own time. I hoped to overcome the skepticism of some people at Maxis, as well as Scott Draeker at Loki, by demonstrating that it was indeed possible, and experimenting to find the best approach empirically.
My goal was to find the best approach to getting The Sims to run on Linux. Not just to use one particular technology or another. The end result is what matters most, not the way it's implemented.
Thanks to the encouragement of John Gilmore, I certainly did consider using Wine, but at the time it was nowhere near sufficient. (But since then, Transgaming has made astounding progress with Wine, and it's now obviously quite sufficient, to my delight.)
So I used SDL to do a native port of The Sims to Linux, and got most of the game running quite well, except for drawing the people and roofs (which would require hacking a system memory back end to Mesa), and sound (which would require using OpenAL, with which I hoped Loki would have been able to help me).
I was actually quite surprised at how quickly I was able to get a native port of The Sims running on Linux. My previous experience porting SimCity to Unix took a lot more time. But the tools are much better and computers are way faster now. And of course I was more familiar with the code base.
I offered the results of my work to Loki on reasonable terms. They didn't seem interested. I talked to some people at Maxis about it, and they said that Loki had been discussing it with Maxis, but they hadn't heard back from them in a long time.
I finally got some brusque uninformative email from Scott Draeker, and we talked briefly on the phone, but he said that he was really busy, he had a lot of paperwork in progress that had to be finish, and he'd get back to me some time. So I stopped working on the port, and waited to hear back from him...
I considered approaching other Linux game companies about porting The Sims to Linux, but decided to wait, because I still believed Loki was the best company to do it, and I did not want to undercut their ongoing negotiations with Maxis. Just the opposite -- I encouraged Maxis to quickly reach a fair deal with Loki, because I believed we could work together to get it to market fast. But Maxis wasn't the only company dragging their feet.
Months later, I finally read on the net that Loki had decided not to port The Sims to Linux, because "Maxis wanted too much money". By that time, The Sims had been topping the charts for months, so of course Maxis was asking a lot for it.
What I didn't know at the time, was that Loki was soon to declare Chapter 11. So it was actually a combination of Maxis wanting a lot for it, and Loki not having any money. But of course Draeker didn't mention that fact at the time.
But fortunately, my time and effort porting The Sims to Linux was not wasted, because Maxis needed The Sims to run on Linux, as the multi-player game server for The Sims Online.
So I used the original port at a guide, and more cleanly ported and optimized the newer Sims Online code to Linux again, making a headless build without all the graphics (removing SDL and DirectX). But the Linux build of the code is for Maxis's internal use on their servers, not as a commercial product for Linux.
I made the same code base compile on both Windows and Linux, and both with or without graphic. The SDL graphics code still works on Linux, but it's only used for diagnostic and debugging purposes, and not for production.
It's nice to run the graphical build of the Linux server in order to see what the server's doing during development. But the production server can't require a connection to an X server, and doesn't read in any graphics, because many must run on the same machine in parallel.
Even though Loki blew their chance to port The Sims to Linux, I still wanted to see it happen anyway. But because so much time had passed since the release of The Sims, I would rather put my efforts into finishing porting The Sims Online client to Linux, and work with some other company than Loki.
But I discussed it with Will Wright, and he explained to me in his reasonable, thoughtful, well considered manner: a native port of The Sims Online client to Linux would not be practical as a commercial product, because of its nature as a dynamically updated online game.
The way The Sims Online and many other online games work, is that the server and the clients all run the same deterministic simulation in lock step, funneling any user requested changes through a central "headless" server, so the actions can be scheduled to happen at the same time in all parallel universes.
So the server simulation and protocol must be *EXACTLY* the same as the clients, or all hell will break loose. Any online game, no matter what the architecture, requires that the client and the servers be in sync. That's not so hard if the game is trivial like Othello or Quake, but The Sims network protocol is much more complex and quite sensitive to incompatibilities.
So there is absolutely no way to support any more than one client executable, because the clients and servers must be updated together in real time by downloading patches, just like Ultima Online and other games.
In order for there to be a Linux port (or a Mac port), it would necessarily have to be done in-house at Maxis, built off of the same code tree, developed in parallel.
It is simply not possible for a third party developer like Loki to stay in sync with the ongoing development at Maxis of The Sims Online. That would require enormous overhead and resources on the part of Maxis, all for an extremely negative return on investment: it would extremely complicate and slow down the development process, require extra programmers, quality assurance people with Linux skills, etc.
Cross platform development requires a LOT of overhead -- please believe me if you haven't tried it. The gross income from selling Linux clients would be infintesimal, and would never outweigh the enormous cost of development. There is absolutely no way EA would ever allow Maxis to flush their stock holders' money down the toilet like that.
That is the harsh, real, undenyable reason that Wine is the most practical and economical way to run games on Linux.
I am quite pleased that Transgaming has developed Wine so far that it can now actually run The Sims! What's wrong with one Linux company coming up with a free and practical implementation of a great idea, that puts another Linux company out of business? Think of it as evolution in action, to quote somebody whose name doesn't deserve mentioning.
The way Transgaming has improved Wine is so generally beneficial, that running The Sims Online on Linux the very day it's release on Windows, is now practically in the bag! With Loki's pace and approach, there was never any hope of that.
The thing that matters most is the fact that a game DOES run on Linux, not HOW it's implemented. Real People in the Real World don't care about religious issues like if it's running under Wine or if it's a native port. It takes over the whole screen anyway, so what does it matter? The end experience is the same.
Thanks to the generality of Wine, now there exists a whole spectrum of solutions, from binary emulation, to recompilation, all the way to native porting. Wine could be an extremely useful tool in the process of doing a fully native port.
Those irrational people who reject Wine for purely political reasons, are doing much more damage to Linux than Wine will ever do. They're trying to argue that trivial invisible implementation details matter so much to users, that they would reject Linux if their favorite games weren't native ports, even if they ran under Wine. That's totally ridiculous.
The fact that a game runs on Linux at all, is MUCH more important than whether or not it's a native port.
Another advantage to Transgaming's Wine approach, is that all the existing free external tools like Transmogrifier, SimShow, Facelift, Art Studio, Home Crafer, Menu Edit, File Cop, and the many third party tools, will all probably run under Wine. And if they don't, Transgaming considers it a bug in Wine, and wants to fix it. Most of those tools will never be ported native to Linux, so the only way to use them is though Wine.
I just can't believe that people would attack Transgaming for all that they've done and given back to the community. The alternative is for Linux to simply hold its breath and go without most games.
The consequences of that alternative are dreadful, and much more harmful to Linux than the imaginary consequences of Wine. Now that Wine has been improved enough to run games like The Sims, it has so many other wonderful uses as well. Why would you ever consider sacrificing all that?
It's not worth attacking Wine out of political correctness, in order to wait around forever for native ports that will never happen. Please don't cut off your nose to spite your face.
-Don
-Don
========
http://www.micropoly.com
Micropoly is the Microsoft Monopoly Game! It's a parody of Microsoft that's fun to play, a free board game based the rules of Anti-Monopoly, and a political statement protected under the First Amendment.
This web site exists to freely distribute the full set of graphics and rules for Micropoly, in the "open source" spirit of the original folk game monopoly invented by an Atlantic City Quaker woman.
You are encouraged to download the graphics, print out copies of the game set for yourself and friends, and have fun playing Micropoly!
Micropoly synergistically illustrates several important points, by drawing parallels between the time of the Great Depression and the end of the Twentieth Century:
Monopolies are bad, and competition is good. The original rules of monopoly require everyone to play as a monopolist. That's why companies like Microsoft and Parker Brothers like the lesson it teaches: being a monopolist is good, and in order to win you have to make the biggest monopoly. But the rules of Anti-Monopoly divide players into monopolists versus competitors, resulting in a dynamic, unpredictable, more interesting game. Competition has the same benefits in real life!
The "open source" philosophy has been around a long time before computers. The Atlantic City Quaker woman who invented the original board game spread it around to her friends for free. She would invite people over to play, and they loved the game, so they made their own copies with crayons on oil cloth. This free folk game spread around the country and was played by many people, long before Parker Brothers knowingly decided pirated it. Today we have computer networks, desktop publishing, color printers, and the "open source" model of software development, so it is much easier to spread the free Micropoly game all over the world.
Big companies abuse the patent and legal systems to pirate and exploit other peoples original ideas. Parker Brothers pirated monopoly from its original inventors, illegitimately patented an "open source" folk game, perpetrated an extremely successful propaganda campaign to convince the world that Monopoly(TM) was invented by Charles B Darrow, and aggressively drove other companies out of business with frivolous lawsuits.
They waged a nasty 10 year legal assault on Ralph Anspach, inventor of the "Anti-Monopoly" game, ruining his successful game company, even though his case finally made it to the Supreme Court and won!
As a result of his hard fought victory, the true story of Parker Brother's Billion Dollar Monopoly Swindle has been published for all to read, and it's safe to call a game "anything-opoly".
We are very grateful that he never gave up, and won in spite of Parker Brothers' dirty tricks. We thank him, because he made it possible for us to publish Micropoly, and generously offered to let us use his superior Anti-Monopoly rules, which so perfectly illustrate the point of Micropoly.
The similarities in the monopolistic behaviors of Parker Brothers and Microsoft should be obvious.
OpenOpoly
The software used to produce Micropoly will be freely distributed, as well as the Micropoly content, to serve as an example of how to make your own personalized monopoly game.
We are developing a free "Openopoly" architecture based on XML, whose purpose is to automate the production of custom monopoly games, both printed board games and multi-player online computer games.
Micropoly will be the first example of such a custom game, so anyone will be able to drop in their own text and graphics, turn the crank, and produce a version of monopoly localized for their own city, university, company, church, sports team, or favorite political cause.
Broadway was trying to solve an extremely complex non-problem for which it was never intended, that doesn't do anyone any good.
The only people who need Broadway are the people desparately promoting trash like X11 and Motif and CDE, who were put out of business by the web, Linux, Gnome, KDE, TCL/Tk, Python, and other useful technology.
What I said about the ICCCM would certainly apply to Broadway, had it ever gotten off the ground:
"In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry's standard naked emperor."
And of course JWZ's comment still applies:
"Using these toolkits is like trying to make a bookshelf out of mashed potatoes." - Jamie Zawinski
For more thoughts on the subject: The X-Windows Disaster.
And here are some notes on why X11 window management has gone so horribly wrong, which helps to explain why Broadway is necessarily such a horrible failure.
Window Manager Flames: Why the ICCCM Sucks.
-Don
-Don
-Don
From a song by Tom Paxton:
Oh we're filling the bottle for Ronnie
Filling it up to the brim
And we'll never rest
Till we all pass the test
'Cause we all think so highly of him.
Oh we're filling the bottle for Ronnie
And we'll never kick up a fuss
'Cause we're only doing to that little bottle
What Ronnie's been doing to us
Urine Trouble
(c) Copyright 1986 tojo
There's information in your wee-wee
Reveals the secrets of your lifestyle
Detects if you've been smoking thai weed
On alternate Fridays in the middle of the night
(Chorus 1)
We need a sample of your yellow discharge
So go into the bathroom and fill up this jar
We'll send the sample to the boys down in the lab
Dressed in plaid,
How drab
They've got your bladder on the witness stand
The perpetrators are among us
Their numbers growing like a rampant fungus
They think their habits are private
But urinalysis will clearly deny it
(Chorus 2)
You're in Urine Trouble
You're in Urine Trouble
They've got your bladder on the witness stand
A memo from the office of the president
We must submit or he'll fire the whole darn bunch
This executive decision
Arrived at during a three martini lunch
(Chorus 1)
"Jones, I'd like to see you in my office right away!"
"Y-yes, sir!"
"Close the door behind you, Jones"
"R-right away, sir!"
"Miss Nelson, hold all my calls"
"The fellas from the lab have submitted this
It's a list of the substances in your piss
It seems your performance, while fine on the surface
Is really just a front for your deviant purpose!"
"I can't believe we made you employee of the week
When all the while you were a closet freak
You thought you could hide behind your perfect attendence
Just to conceal your drug dependence!"
(Chorus 2)
There's information in your wee-wee
Reveals the secrets of your lifestyle
Detects if you've been smoking thai weed
On alternate Fridays in the middle of the night
(Chorus 1)
"Oh No!"
"What's wrong?"
"Remember that joint I toked last month?"
"Yeah"
"I think I'm having a flashback!"
"I want to operate heavy machinery!"
"I want to cause an industrial accident!"
"I want to exercise poor judgement!"
"I want to unwisely make a critical decision!"
You're in Urine Trouble
You're in Urine Trouble
They've got your bladder on the witness stand
You're in Urine Trouble
You're in Urine Trouble
They've got your bladder on the witness stand
The bias against Lisp is based on the simple fact that the first word that springs into most peoples pointy little heads when they hear the word "Lisp" is: "Gay". And that scares off all the homophobic repressed closet queens, which includes a large percentage of the computer industry. Especially Perl programmers, who use Perl as a means of expressing their manhood and covering up their repressed homosexual tendencies.
-Don
KMP also wrote an animal guessing game that would get upset and warn you not to use naughty words. If you didn't relent and kept on cussing, it would get angry at you, and send some email to you and KMP, telling on you and demanding an apology. So you couldn't play the game again until you emailed an apology to his program.
It's great to know KMP is still teaching lisp.
But I've always wondered: who was the bright-12-old (who's now about 28) who benefited from recycling Jerry Pournelle's account?
====
From http://catalog.com/hopkins/text/pourne-smut.html:
====
-Don