thats why I still program in text files and use gdb for debugging. They are fast and reliable, that's what you need for algorithms anyway. And who cares about abstractions.
Unless you regularly updated and worked on the latest 2.0 beta this is news ;). You have a complete list of images here http://pharo.gforge.inria.fr/ci/image/20/ including release dates.
During the beta update process it might happen that one or another update fails. Usually that should not happen though.
Yep I can only agree with you, and there is some communication issue for the matter of the image/vm downloads.
Some measures have been taken especially if you run from the commandline use the zeroconf scripts from http://files.pharo.org/scripts. However still some issue remain that are currently not nice!
- no full 64bit support (will be addressed but with a 32bit image format this isn't that straight forward)
- missing warning to install 32bit libs under linux (workaround on the way)
- proper packaging (rpm / deb) which installs the dependencies is missing (also, there are some attempts there)
- you have to explicitly tell the VM to run headless or not (I honestly don't know why! :D)
All in all you caught us, we mostly develop on mac, however our test infrastructure is running on linux hence imperatively Pharo has to run under linux. Yet there is some need for proper explanations, installation requirements!
Cleanups and a modern implementation with proper separation of the compiler toolchain. Additionally they introduced a nice new IR representation to do more sophisticated changes. All in all it does not come with fancy new features but a more solid and clean codebase.
Pharo has quite a decent set of command-line tools at hand for a Smalltalk (see also http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/late...). As for FFI we're about to fully integrate NativeBoost into the system which already provides decent FFI interaction on all X86 platforms: https://code.google.com/p/nativeboost/. The VM we use features a JIT, albeit not highly elaborate, it gives decent speedups. Besides that there is some research of mine going on, on how to implement the JIT native code generate at language side, which would give us the Smalltalk-level control over that piece.
Seaside works, yet it has not been officially release for 2.0 hence we rely on a gofer script to load all dependencies.
What error? I doubt it's related to seaside. And for the configuration we mostly need somebody to do it :) since the seaside config is pretty big on its own you got to be careful when changing things for a new release.
Nope, even though it is ready for 2.0 it was not included in the release. If you are more interested you can have a look at the prepared jenkins images https://ci.inria.fr/rmod/job/Opal/ .
Yes seaside is still in active development and there is progress on getting a nice configuration working on Pharo 2.0. Until then you can use our manual build from https://ci.inria.fr/pharo-contribution/job/Seaside-2.0/ to test it.