Slashdot Mirror

The problem here is that you're trying to start with DNA forming a complete organism with 'accurate' self-replication. This is hard, yes.

Start simpler. If you look at the citric acid cycle, it is a self-replicating chemical reaction (in the sense that given the building blocks, the main molecule that goes around the cycle ends up doubling itself after one cycle). So all you really need to do to start things off is to randomly generate the citric acid cycle. The various reactions necessary to form the molecules needed for the cycle are a matter of current study, and there are missing points in the chemical theory there, but resolve those points and its a matter of inevitability, not a matter of probability (i.e. you're no longer trying to figure out the chance of this one very rare combination forming, you're just trying to figure out what environment will guarantee the origin of the citric acid cycle within X amount of time)

Now, lets say you don't buy that (there are still those missing reactions/conditions, after all) and you want to start with DNA or RNA. You still don't need a complete organism to take off - you can make do with any sort of analogue of the PCR reaction which amplifies strings currently found in solution. A (very) slow version of this has been observed in water in arctic regions, where the high salinity, low temperature water trapped between a lattice of ice allows the replication to occur without the strands breaking apart over time - this is without the usual PCR enzymes, mind you. You can read that paper at http://www.et1.tu-harburg.de/downloads_et1/ep/publikationen/trinks_ea85.pdf

Additionally, hydrothermal vents could provide an environment perfect for that, since a chamber cycling via thermal convection has been found to be quite good for PCR reactions [Braum, Goddard, and Libchaber "Exponential DNA Replication by Laminar Convection" PRL 91, 2003).

So, while the exact pathway is still a matter of research, I think that this at least shows that the 'critical initial chain' thing may be quite a bit softer of a constraint than you expect.

Genera

I've used to have rather profound C++ experience (about ten years now). I've wrote a Race-Track Microtron control system in it and some other stuff like that, really :-) But I still fail see in which way it's better than Lisp, besides some (but not 10x-20x as when compared to languages like Python in Perl) performance gain, which is not always critical. It's possible to write applications, device drivers and operating systems in it, as well as databases, compilers, GUIs, web applications and lots of other stuff in it. I have some doubts concerning hard real time, but given the fact that GC can be locally avoided/inhibited using rather simple techniques, I think there should be no much problems there. C++ experience is useful thing, but I think that Lisp is in no way less important.

Surely you were using a Symbolics machine, and not an MIT CADR?

This is not Genera.

One can see in this software and the CADR the start of what evolved into the Symbolics 3600 series and its software.

Since you mention a price tag (in non-US currency even), and imply that it was used for commercial purposes, you are almost certainly not thinking of the CADR prototype and research system.

Probably this is what you are thinking of: Symbolics Lisp Machine Museum.

There is a link on that page to the CADR, under "Precursors and Competitors". The CADR was a precursor.

I'm studying a course in 3D Computer Vision right now, at TUHH. It's part of the Erasmus exchange program I'm having here - the eigth and last semester (excluding the thesiswork) of my master of engineering in automation and mechatronics at Chalmers in Gothenburg. I can easily say this course is the most difficult one of all I've been taking for all of my study time, hopefully the three weeks I have between that exam and the last of my others, will be enough to learn what doesn't stay in my head during the lectures...

In fact, I have the course book right beside me. To begin, the description of it would be more or less along the lines "an orgy in linear algebra, mathematical statistics, with some flavouring of image processing, geometry, optimization and algorithms". Basically, it's 30-40% mathematical formulas, 650 pages, some containing things not even all MSc even learn like tensor notations etc. Not something I'm even sure is a good thing to recommend to very many slashdotters, even. You'll get its name though - "Multiple View Geometry in Computer Vision", by Hartley & Zisserman. ISBN 0-521-54051-8.

What I see as problems in the book, is that almost everything is working on corner detection. This is great, if you want to make 3D-models of houses or other man-made objects (at least half of the examples in the book are architectural, I would say). It's not so great if you want to image bushes, rocks and other things with not so obvious corners on them. Also, the process involves quite heavy processing - both image processing, finding all those corners, statistical processing (to sort out outliers, which there will be), and optimization to find the best fitting backprojection of the image planes). I don't have a sure grip on the needed processing power but I doubt, when considering realtime demands in a car, that it'll hardly be easy to get it working.

Also, it's still to a big deal itself an area under research. The situation with using 5+ images (from different cameras och just consecutive images from the same, moved camera), isn't very well known. Using more images, of course would mean a bigger chance to get a decent 3D model of the scene...

And still, you would at least need two cameras to do anything useful. You can't reconstruct 3D space without having at least two images of the object to reconstruct. And probably you will need more - you would probably want to reconstruct all the way around (ie more cameras on the sides and backwards), and add extra sensors like radar etc for extra checks.

And then you really haven't solved the problem of driving the car. You have only built a decent mapping of the 3D surroundings of it. You have to add AI/some kind of steering logic, which only in itself is a demanding task. Just look at all FPS games out there - if it would be easy to construct good AI, with a known 3D-world, tailormade for the figures, would we really be seeing that many games with crap-AI? I'm happy I ain't taking an AI course too, for sure!

http://c2.com/cgi/wiki?GeneraOs

Lisp Machines

Been there, done that.

Hehe. Well this is my IDE The rest of the os isn't too bad.

Hehe. Well this is my IDE The rest of the os isn't too bad.

Hehe. Well this is my IDE The rest of the os isn't too bad.

Hehe. Well this is my IDE The rest of the os isn't too bad.

Hehe. Well this is my IDE The rest of the os isn't too bad.

Hehe. Well this is my IDE The rest of the os isn't too bad.

Naturally it was used for many things.

Smalltalk wasn't the only one.

"Then I suddenly understood that you don't have to be a super guru who understands all the systems sourcecode to gain from open source. One day there will be some little thing that is bothering you that you actually CAN do something about."

Then you would have loved these systems. You would be using the system as you described, then if you wanted to change something on a running system? Pull up the development tools, change the source code (inherent to the system), while the system is running and then close them, and go back to work.

Something that's rarely been duplicated.

"To me is seems that this project will only work if it is managed as a coherent whole, like BSD or Squeak, and that means being open source with a strong leader. And now that I've gotten completely off-topic of your question I'll end my post :)"

A Coherent Interface has been available for quite some time. Unfortunately Good Enough won instead of it's nearest Competitor.

"Heading 3 from the article: Programs as Data. Yep, lisp was doing that decades ago :P"

And Forth was Data as code.

It sounds like we all are pining for the "Good , old, days".

When men were men, and our development environments respected that. None of these 'sissified' "Can I wipe your chin?" we presently have. :)

"Back in the 80s when the Mac was released People said the same thing. Why do you need a GUI Interface where we can get all that we need done in text mode."

This may be before your time? But GUI's predate even Apple's Lisa.

Well well, the fates pervail.

Remember this? That's what's coming to Linux. Here's a summary for those who haven't seen the video, and explains the environment better. Couple that with this or this environment. And you begin to see the future of working with Linux. Collaboration is the OSS way, and with such a foundation. Everyone will be able to participate. Programmers, and non alike.

This quote is for real. It's from Albert Einstein's address to the Prussian Academy of Sciences in Berlin on January 27th, 1921.. Here's a link for
an English version of this paper which, like everything Einstein wrote, is very interesting in it's entirety.

Yes, and I was interested since I had my first grasp of TCP/IP, packet switching and all that.

I imagined every house with free space optical (FSO) devices on top of it+a router, long distance would be the last task for phone companies/ISPs. But sadly, it didn't happen.

Maybe the telcos are trying to prevent that? Maybe people are too lazy and too stupid to grasp the whole idea? Remember, you'd have to convince many people to 'relay' packets before such a network gets usable. I don't really know, but IMHO it is both technically and socially superior. (Promotes local exchange etc.)

Anyway, appropiate routing protocols and also research exists nowadays:
Manet routing protocols, IETF
Fleetnet, mobile adhoc for cars (very interesting!)

Maybe I'm pessimistic, but I think you'd pay
a fee in such a network, even if you only exchange
data between you and your neighbour (the telcos want to live, right?).

I think it is common for people to make up something that helps fill gaps in science. sometimes it turns out right many times it turns out wrong. many times this happens such as space ether.

When we can't explain something we are sometimes better off makeing something up that fills the gap until we can find the more correct answer. There is no such thing as exact science. Only reproduceable observation which eventually becomes accepted fact. Although there is no reason for it to always stay fact if someone says, "Hey, I tried to do the experiment and used this method to test it and I got a diffrent observation!" Well, now it's time to re think that scientific fact.

What happens typically is that the person is downplayed as doing something wrong, adding some new variable to the mix, or something that would throw off the observation in some way. Politics in science is as complicated and painful as anywhere.

Or better yet, LISP.

But this is still very confusing because Fresco is a C++ based widget/GUI interface for X11 based on Corba.

Schematic entry is for people who do not know VHDL. There is hardly any other reason to use schematic entry when doing CPLD or FPGA programming, because schematic entry does hardly give you more control over the PAR process.

Cleverly done VHDL can also give you close control over the actual logic. Just look at this CPU: 8 Bit CPU in CPLD. Even though it is done in VHDL it is optimized to fit just into the smallest CPLDs available.

Btw. I found above link on http://www.fpgacpu.org which is another good starting point for FPGA based cpus.

The system transmits data of two polarization channels with 40Gbit/s each, i.e., together 80Gb/s bit per second, over a 212km long optical fiber - much further than otherwise possible.

1. PMD compensators are being built by many research groups. You still can't call up an order one (AFAIK), but soon.
2. PMD (mean DGD, differential group delay). DGD changes with time and wavelength.
3. PMD on buried fiber varies slowly. It is easy to compensate.
4. Nortel, Alcatel and others with be releasing 40 GB/s (per WAVELENGTH) systems next year. They are suppose to run 100's of km, between regens and at many wavelengths (160?).

Here is a link with almost all peer reviewed papers on PMD:

Here one can see many references to PMD compensation and even some at bit rates of 160 GB/s. With PMD compensation the line speed isn't that important, it is the accuracy and speed of your compensation.

This is not a break through.

The problem is that Berlin utterly throws away compatibility with the huge bodies of works currently running using Motif, TK, GTK, Qt, Xt, and FLTK (to name the likely "top" GUI libraries used on X).

As a result of discarding compatibility, Berlin is pretty useless until ALL your favorite software is rewritten to use Berlin. Some emulation may be possible, but this is nontrivial, and it'll literally take years for this to be robust enough for production use.

The Berlin Architecture is said to be based on
Fresco. If they have kept the Fresco Painter interface, Berlin would have a rendering model similar to PostScript, which should be interesting from a GNUStep point of view.

The Berlin Architecture is said to be based on
Fresco. If they have kept the Fresco Painter interface, Berlin would have a rendering model similar to PostScript, which should be interesting from a GNUStep point of view.

• The Ancient Past

  In the beginning, Berlin was a project started by some Assembly-Language "uberhackers" that really disliked X, who had the notion that they could somehow write a windowing system that would be so fast that it would somehow displace X.

  In that "distant past," there was much unfriendly flaming, and there were "dueling web pages" between myself and some Berlin folk. My page has since evolved into On the Thesis that X is Big/Bloated/Obsolete and Should Be Replaced, which is rather less "anti-Berlin" now.

  Acrimony arose over a generally "uncooperative" attitude; the designers were quite prepared to eschew CPU architecture portability, only to ever run on IA-32, quite prepared to eschew networking support, never to be able to display apps remotely, and quite prepared to ignore any and all existing GUI APIs, requiring that all-new apps be deployed.

  The original grouping of designers largely evaporated; they seemed to get the beginnings of a font renderer working, but apparently little else.

  I get the impression that there was some politicking along with the GGI Project that was involved in the "staff turnover;" 'tis not completely clear...

• Berlin: The New Generation

  A largely new generation of folks came along, bringing a somewhat more cooperative spirit, and an interest in being hugely "buzzword-compliant," between "being 3D-compliant" via OpenGL, network transparent via CORBA, and by the same token, as architecture independent as C++ and GGI get you, and language-independent (sort of) via UNICODE.

  I had a nice chat with Graydon Hoare last year in Atlanta; they hadn't gotten too far, but certainly had a more useful attitude.

  In particular, they are now not presenting the former, laughable, message that "X is Dead, And Berlin Is About To Replace It."

• My Take on Why They Haven't Progressed Quicker

  After about 3 years, you'd expect there to at least be a text editor or something available. At this point, they're fairly happy to now have some apps that can display widgets that show that there's some working code.

  I would suggest that they are still labouring under some significant handicaps as compared to some of the alternatives, and am skeptical that there is a good likelihood of success:

  • They can't attract effort to produce applications until they have a functioning environment, but can't get a functioning environment without considerably more effort.

    This is a vicious circle; it's hard to attract developers to a system that doesn't work yet, and other projects like GNOME and KDE, as they do function today are vastly more attractive, as well as being vastly less risky propositions.

    This effect is vastly magnified when you consider that commercial enterprises are investing considerable effort in X-based efforts.

    The high probability of failure completely discourages commercial investment of time/effort/money.

  • Unlike other projects that represent improvements alongside of X, Berlin depends on a whole lot of components getting developed. This magnifies risks further.

    The fact that the GGI project developed a library to allow GGI apps to run atop X means that at least that forcible dependency has been cut, but there's still just too many things that need to work for Berlin to work.

    Contrast this with GNUstep, which, it seems to me, has a strategy more likely to succeed.

  • GNUstep is based on an API that is known to be technically and economically viable, namely OPENSTEP.
  • GNUstep requires one "partially unavailable" component, namely the still-being-developed Display Ghostscript substrate.

    It is thus based on the use of a substrate that is feasibly run on X, but which, unlike Motif, doesn't force vast amounts of X dependancies onto programs, it would be conceivable for X to be replaced, eventually, by Display GhostScript Running On Something Else. (Similar is actually true for some of the major "X" GUI toolkits like Tk, GTK, Qt, and FLTK, which all can run on things other than X...)

Good News Even If The Big Project Fails

• There may be components that are of value.

  For instance, they may wind up producing a font rendering engine that could be useful elsewhere.

• The learning about how to use CORBA to build a graphical environment may help steer other projects towards good/feasible ideas, and away from infeasible directions.
• There may be some useful IDL definitions.
• Some of what appears valuable in Berlin is the recasting of Fresco ideas.

  It is arguable that the adoption of Motif (with sundry ugly implementationness as well as proprietariness) over Fresco is part of what has set back progress in X development for a goodly five or so years. (I'd argue that...)

here I used rpms from this site
esp. I installed GNOME (then new) rpms on suse5 from here. Quite useful site to remember. -a