17

I'm trying to learn some Smalltalk. First found was Squeak, but since it has been removed from Gentoo ebuild tree because of security problem, so I decided to find an alternative.

Then I found Pharo through Seaside project, after I downloaded Pharo 1.0 package, there are actually a SqueakVM inside!

So, my question is: Is Pharo just a repackaging/rebranding of Squeak? And are those security problem of Squeak (bundle unsecure libs) still applied to Pharo?

Thanks!

number5
  • 15,913
  • 3
  • 54
  • 51

3 Answers3

16

Pharo started as a fork of Squeak to target "practical" Smalltalk development. The two environments use the same virtual machine, same image format, and share nearly the entire low-level class libraries. They use the same version control systems, and (last I checked) shared the same fileIn/fileOut format as well.

At the same time, I don't think it's fair to say that Pharo is merely a rebranding. The two projects are taking increasingly different directions: while Squeak shows no sign of wanting to remove its educational and research packages, Pharo is narrowly focused on making a tiny, lightweight environment suitable for corporate and commercial development. Where Squeak is concerned about keeping backwards compatibility with its previous releases, Pharo has been very willing to break compatibility in the name of slimming things down, speeding things up, and just generally simplifying the library system. The two systems now have different compilers, will soon have different FFI (native code) interfaces, and have increasingly divergent windowing systems.

For these and other reasons, I treat Pharo in my mind as a currently-mostly-Squeak-compatible Smalltalk, and not as a mere "rebanding" of Squeak. As time progresses, I would expect the situation to get closer and closer to Emacs/XEmacs, where it's possible to make programs that run under both systems, but most people target one or the other.

I have absolutely no idea what security problem you're mentioning, so I have no idea whether the situation's better than Pharo. It'd be helpful if you could outline what you have in mind.

Benjamin Pollack
  • 27,594
  • 16
  • 81
  • 105
  • 1
    Thanks for the detailed answer. As for the security concern, Gentoo maintainer found Squeak bundled jpeg and pcre version with known vulnerabilities, http://bugs.gentoo.org/show_bug.cgi?id=247363 – number5 May 27 '10 at 17:28
  • 2
    Interesting. Those bugs are in the VM, so they'll apply to Pharo, Squeak, Cog, and any other Smalltalk that uses Squeak's virtual machine. Meanwhile, despite a bunch of complaining about how the Squeak devs won't fix it and are being obstinate in your linked bug, I see no bug filed for any of those three vulnerabilities in Squeak's bug tracker, and no mention of the bug on the mailing list. It'd probably be worth letting the Squeak dev team know there's a problem. – Benjamin Pollack May 27 '10 at 17:45
  • 2
    There's discussion right now in the vm-dev list about how to address the issue. David T Lewis posted a bug report now too: http://bugs.squeak.org/view.php?id=7539 – Frank Shearar May 28 '10 at 09:19
6

I'm no expert, but from what I've read Squeak has quite a bit of stuff in it (educational etc). Pharo was a fork which attempts to remove a lot of the extra bits and make it more commercial grade.

Pharo About
Another article discussing this

Justin
  • 4,434
  • 4
  • 28
  • 37
6

While agreeing entirely with Benjamin's answer, there's nothing stopping the two forks from being nearly identical again in the future.

Both projects aim for a tiny kernel with a cluster of loadable packages. The main difference (at least from what I can see, in the discussions on squeak-dev is in the philosophy of how to reach that goal.

Some folk have suggested that in the future the main difference between Pharo and Squeak would thus be which packages come loaded by default.

Community
  • 1
  • 1
Frank Shearar
  • 17,012
  • 8
  • 67
  • 94
  • Except that Pharo people explicitely don't want to care too much of backward compatibility, because it is a major obstacle to simplification and cleaning of core library, and because it consumes too many cycles for a small reward (packages not updated become obsolete anyway). So there is not any guaranty of compatibility in the long term, even if global community interest is to preserve a certain level of compatibility... – aka.nice Jan 27 '14 at 18:03