That figures. Their patents talk quite a bit about caching translated code. Since the size of the translated code likely is rather large (think VLIW...), using normal caches would probably be quite a bit too expensive, hence the relatively fast DRAMS...
While I agree with you on most of your points, I don't really like to be called an idiot...
Berlin can't be a replacement for X; it's not a hardware-oriented system.
Only idiots compare Berlin to X, as the systems have very little functionality in common. X knows how to talk to hardware, whereas Berlin doesn't. Berlin needs to have some combination of GGI and OpenGL.
Some X servers talk to hardware, but not all. XGGI doesn't, and neither does XNest, the XFree86 frame buffer server, or most (all?) of the X servers for Mac and MS-Windows. X is not a hardware-oriented system. There is nothing in the spec that says what an X server should talk to.
It is true that the only implementation of Berlin uses GGI for graphics, but that doesn't mean that it wouldn't be possible to write a Berlin server that talks directly to hardware, like some X servers do.
What X really does is to allow programs to display graphical interfaces across networks, which is exactly what Berlin tries to do.
It would be vastly more sensible to compare Berlin to GTK, Qt, or FLTK, as that is where there might be properties in common.
Not at all. GTK and QT (don't know anything about FLTK...) are toolkits that allow programs to be written that can work independantly of the windowing system (X11, MS-Windows, etc). They are somewhat comparable to the Warsaw library in Berlin.
Note that I'm not trying to say that Berlin could ever replace X (or that there's even a reason to replace it), just that one can compare Berlin and X without being an idiot.
Depending on how expensive the EPIC logic is to compile to, this might or might not be a big boost to Java, etc
This might also benefit free software alot. With propriertary software you have to supply one version for every processor variant to get the most out of it, while with free software, users can recompile the package themselves. BSD ports collection, anyone?
Slashdot Mirror
The Eternity project already does this (implemented a slightly different way, though)
That figures. Their patents talk quite a bit about caching translated code. Since the size of the translated code likely is rather large (think VLIW...), using normal caches would probably be quite a bit too expensive, hence the relatively fast DRAMS...
It is true that the only implementation of Berlin uses GGI for graphics, but that doesn't mean that it wouldn't be possible to write a Berlin server that talks directly to hardware, like some X servers do.
What X really does is to allow programs to display graphical interfaces across networks, which is exactly what Berlin tries to do.
Not at all. GTK and QT (don't know anything about FLTK...) are toolkits that allow programs to be written that can work independantly of the windowing system (X11, MS-Windows, etc). They are somewhat comparable to the Warsaw library in Berlin.Note that I'm not trying to say that Berlin could ever replace X (or that there's even a reason to replace it), just that one can compare Berlin and X without being an idiot.
Doh!
import string, sys, operator
print string.join(map(chr, map(lambda s:reduce(operator.add, map(lambda p, s=s:{'0':0, '1':1<<p}[s[7-p]], range(8))), string.split(sys.stdin.read()))), '')
import string, sys, operator
print string.join(map(chr, map(lambda s:reduce(operator.add, map(lambda p, s=s:{'0':0, '1':1
BSD ports collection, anyone?
I'm surprised nobody has suggested the obvious name comming from a web contest: Hank the angry, drunken company ;-)