Hallo Squeaker.
Nachdem mich die Jungs von Cincom letzte Woche etwas verärgert haben, bin ich am ernsthaften Überlegen, fällt das Hauptargument für VisualWorks (plattformübergreifende "Standard"-GUI-Clients) weg.
Eine anstehende Web-Applikation hab ich zwar schon in VW angefangen, aber AIDA gibt's auch für Squeak, da sollte sich der Aufwand für den Umstieg in Grenzen halten. Die Daten liegen zurzeit in einer ca 120MB großen SQLServer-Datenbank, wo ich sie wohl auch liegen lassen muss, damit die übrigen Komponenten nach wie vor funktionieren.
Bevor ich da aber ernsthaft anfange, würde ich gerne wissen:
- Wie macht sich denn Squeak so als Langlauf-Server-Prozess auf einer (32-bit)-Linux-Kiste (2xPentium V 2.3 GHz, 3GB RAM)? Der Rechner selbst ist jetzt ein OpenXchange-Server für den Kunden und langweilt sich fürchterlich...
- Läuft das Ding in guter alter Linux-Manier "einfach so immer" oder sollte ich das Image wöchentlich oder täglich neu starten?
- Gibt's irgendwelche Besonderheiten zu beachten? Harte Grenzen wie die max. Zahl an Objekten oder sowas?
- Gibt's irgendwelche Tipps und Tricks für bzw. Warnungen vor bestimmten Tools, die fürs Arbeiten wichtig sind? Enorm hilfreich für mich wären z.b. die beiden "History"-Knöpfchen "<" und ">", die der alte RefactoringBrowser hatte, der neue OmniBrowser aber anscheinend nicht.
- Welche Image-Version nimmt "man" denn heute zum Entwickeln? Ich hab auf dem Windows-Laptop eine 3.10-er VM und das letzte 3.9-er image und ein Weilchen mit Universes und SqueakMap und Monticello@SqueakSource gekämpft, bis ich ein System beisammen hatte, in dem die Sachen drin waren, die ich haben wollte.
Schönes Wochenende, s.
Am 15.09.07 schrieb Stefan Schmiedl s@xss.de:
Hallo Squeaker.
Nachdem mich die Jungs von Cincom letzte Woche etwas verärgert haben, bin ich am ernsthaften Überlegen, fällt das Hauptargument für VisualWorks (plattformübergreifende "Standard"-GUI-Clients) weg.
Eine anstehende Web-Applikation hab ich zwar schon in VW angefangen, aber AIDA gibt's auch für Squeak, da sollte sich der Aufwand für den Umstieg in Grenzen halten. Die Daten liegen zurzeit in einer ca 120MB großen SQLServer-Datenbank, wo ich sie wohl auch liegen lassen muss, damit die übrigen Komponenten nach wie vor funktionieren.
SQLServer ist ein bisschen ein Problem denn es gibt keinen Treiber dafür. Kannst zwar ODBC verwenden, das ist aber recht suboptimal (blockiert die VM und so).
Bevor ich da aber ernsthaft anfange, würde ich gerne wissen:
Wie macht sich denn Squeak so als Langlauf-Server-Prozess auf einer (32-bit)-Linux-Kiste (2xPentium V 2.3 GHz, 3GB RAM)? Der Rechner selbst ist jetzt ein OpenXchange-Server für den Kunden und langweilt sich fürchterlich...
Läuft das Ding in guter alter Linux-Manier "einfach so immer" oder sollte ich das Image wöchentlich oder täglich neu starten?
Kommt darauf an, meine Erfahrung ist da recht Windows-mässig. Die Dinger hängen sich von Zeit zu Zeit immer mal wieder auf (Sockets, Semaphores, Delays, such dir was aus). Andreas hat vor kurzer Zeit einige Semaphore und Delay fixes gepostet mit denen es ihm möglich war eine Uptime von mehr als zwei Tagen zu erreichen und die auch Semaphore >> #critical: fixen sollte. Dann war da vor kurzem auch noch ein Patch von Elliot. Ich weiss nicht ob man mit denen jetzt Semaphare und Delay als funktionierend betrachten kann.
- Gibt's irgendwelche Besonderheiten zu beachten? Harte Grenzen wie die max. Zahl an Objekten oder sowas?
Also mit einer VM ohne die pointer fixes ist unter Umständen schon bei 128MB Schluss. In ein Set/Dictionary mit Objekten als key welche #hash von Object haben ist bei 4096 items Schluss. Finger weg von Weak* Datenstrukturen. Dann gibt es diverse harte Grenzen auf bytecode Ebene die dich aber nicht betreffen sollten. Wenn du was ernsthaftes hast, wirst du nicht draum rumkommen die GC parameter an das 21. Jahrhundert anzuspassen. John McIntosh hat einige gute Posts dazu. Der oldspace GC ist nicht inkrementell. Im Allgemeinen ist es besser du hast mehrere kleine Images, die sich die Last teilen statt ein grosses. Solche Sachen halt.
Also wenn du etwas grösseres und kritisches hast, würde ich es mir noch ein zweites mal überlegen. Da es ja sowieso um eine Webapplikation geht, kann dir ja egal sein, ob Cincom jetzt ein neues UI Framework bringt oder nicht.
Gibt's irgendwelche Tipps und Tricks für bzw. Warnungen vor bestimmten Tools, die fürs Arbeiten wichtig sind? Enorm hilfreich für mich wären z.b. die beiden "History"-Knöpfchen "<" und ">", die der alte RefactoringBrowser hatte, der neue OmniBrowser aber anscheinend nicht.
Welche Image-Version nimmt "man" denn heute zum Entwickeln? Ich hab auf dem Windows-Laptop eine 3.10-er VM und das letzte 3.9-er image und ein Weilchen mit Universes und SqueakMap und Monticello@SqueakSource gekämpft, bis ich ein System beisammen hatte, in dem die Sachen drin waren, die ich haben wollte.
Ist Geschmacktsfrage. Da gibt's das volle Spektrum von minimalem 3.7er Image, 3.8, 3.9 oder natürlich die dev-images von Damien. Je älter das Image, desto mehr Patches musst du dafür halt zusammensuchen. Und fürs deployment stellt sich die frage ob du einfach ein dev-image nimmst oder irgend was kleineres im Extremfall ein Kernelimage von Pavel.
Gruss Philippe
Hallo Philippe.
On Sat, 15 Sep 2007 16:44:07 +0200 "Philippe Marschall" philippe.marschall@gmail.com wrote:
SQLServer ist ein bisschen ein Problem denn es gibt keinen Treiber dafür. Kannst zwar ODBC verwenden, das ist aber recht suboptimal (blockiert die VM und so).
Schon mal ein wichtiger Punkt, danke. Die nächsten Sorgenkinder waren genau das, was ich hören wollte, bzw. eigentlich nicht :-/ Ich fasse das für mich mal als "mit unangenehmen Überraschungen ist zu rechnen" zusammen.
Also wenn du etwas grösseres und kritisches hast, würde ich es mir noch ein zweites mal überlegen. Da es ja sowieso um eine Webapplikation geht, kann dir ja egal sein, ob Cincom jetzt ein neues UI Framework bringt oder nicht.
Da hast du natürlich recht. Prinzipiell ist das egal. Aber wenn's egal ist, macht die VAR-Lizenz weniger Sinn als wenn's mit fortgeführtem Widgetry zwei Gründe geben würde.
Vielen Dank für die Hilfe, s.
Bevor ich da aber ernsthaft anfange, würde ich gerne wissen:
- Wie macht sich denn Squeak so als Langlauf-Server-Prozess auf einer (32-bit)-Linux-Kiste (2xPentium V 2.3 GHz, 3GB RAM)? Der Rechner selbst ist jetzt ein OpenXchange-Server für den Kunden und langweilt sich fürchterlich...
Normalerweise problemlos. Um einen solchen Server voll auszunutzen würde sich ein Load-Balancing über 2-4 VMs empfehlen.
- Läuft das Ding in guter alter Linux-Manier "einfach so immer" oder sollte ich das Image wöchentlich oder täglich neu starten?
Ich habe gute Erfahrungen mit den daemontools (http://cr.yp.to/daemontools.html) gemacht. So ist sichergestellt, dass die Images immer laufen.
- Gibt's irgendwelche Besonderheiten zu beachten? Harte Grenzen wie die max. Zahl an Objekten oder sowas?
- Alle Morphs im Image schliessen (insbesondere das Transcript). - Die VM mit einer festen Memory Obergrenze starten, e.g. -mmap 512m - Delay-Fixes benutzen (http://bugs.squeak.org/view.php?id=6576)
- Gibt's irgendwelche Tipps und Tricks für bzw. Warnungen vor bestimmten Tools, die fürs Arbeiten wichtig sind? Enorm hilfreich für mich wären z.b. die beiden "History"-Knöpfchen "<" und ">", die der alte RefactoringBrowser hatte, der neue OmniBrowser aber anscheinend nicht.
Das könnte man als Plugin in OB einbauen ;-)
- Welche Image-Version nimmt "man" denn heute zum Entwickeln? Ich hab auf dem Windows-Laptop eine 3.10-er VM und das letzte 3.9-er image und ein Weilchen mit Universes und SqueakMap und Monticello@SqueakSource gekämpft, bis ich ein System beisammen hatte, in dem die Sachen drin waren, die ich haben wollte.
Ich habe gute Erfahrungen mit 3.9 gemacht.
Grüsse, Lukas
Hallo Lukas.
On Sat, 15 Sep 2007 16:48:16 +0200 "Lukas Renggli" renggli@gmail.com wrote:
Normalerweise problemlos. Um einen solchen Server voll auszunutzen würde sich ein Load-Balancing über 2-4 VMs empfehlen.
naja ... theoretisch gibt's da an die 40 PCs, typischerweise gleichzeitig aktiv sind an die 20. Wir reden da wohl zu Stoßzeiten über ein paar hits/sec.
- Gibt's irgendwelche Tipps und Tricks für bzw. Warnungen vor bestimmten Tools, die fürs Arbeiten wichtig sind? Enorm hilfreich für mich wären z.b. die beiden "History"-Knöpfchen "<" und ">", die der alte RefactoringBrowser hatte, der neue OmniBrowser aber anscheinend nicht.
Das könnte man als Plugin in OB einbauen ;-)
Bis wann ist das fertig? :-)
- Welche Image-Version nimmt "man" denn heute zum Entwickeln? Ich hab auf dem Windows-Laptop eine 3.10-er VM und das letzte 3.9-er image und ein Weilchen mit Universes und SqueakMap und Monticello@SqueakSource gekämpft, bis ich ein System beisammen hatte, in dem die Sachen drin waren, die ich haben wollte.
Ich habe gute Erfahrungen mit 3.9 gemacht.
Ich habe im Wesentlichen den Donnerstag mit Squeak verbracht und an den Tools geschraubt (z.B. TestRunner nur mit einer einzelne Kategorie starten) und sogar ein bisschen Funktionalität geschaffen. War viel angenehmen als in VW, nicht ganz so schön wie in Dolphin. Nur mal so als persönlicher Eindruck.
Vielen Dank für die Hilfe, s.
Am 15.09.07 schrieb Stefan Schmiedl s@xss.de:
Hallo Squeaker.
Nachdem mich die Jungs von Cincom letzte Woche etwas verärgert haben, bin ich am ernsthaften Überlegen, fällt das Hauptargument für VisualWorks (plattformübergreifende "Standard"-GUI-Clients) weg.
Eine anstehende Web-Applikation hab ich zwar schon in VW angefangen, aber AIDA gibt's auch für Squeak, da sollte sich der Aufwand für den Umstieg in Grenzen halten. Die Daten liegen zurzeit in einer ca 120MB großen SQLServer-Datenbank, wo ich sie wohl auch liegen lassen muss, damit die übrigen Komponenten nach wie vor funktionieren.
Also wenn du das SQLServer und 32bit Requirement nicht hättest und das Projekt nicht schon am laufen wäre, dann wäre ev. GLASS einen Blick wert: http://seaside.gemstone.com/ Lass dich vom Seaside nicht verwirren. Du bist frei, was du damit laufen lassen willst. Janko hat einen Beta account und arbeitet damit. Es würde mich nicht wundern, wenn AIDA schon bald auf Gemstone/S laufen würde. Die Idee dahinter ist dass du deine Applikation in Squeak entwickelst und dann auf Gemstone/S deployst. Die haben auch eine Menge Squeak tools. So kannst du damit z.B. auch Monticello benutzen. Die Tools sind allerdings noch recht beta.
Gruss Philippe
Bevor ich da aber ernsthaft anfange, würde ich gerne wissen:
Wie macht sich denn Squeak so als Langlauf-Server-Prozess auf einer (32-bit)-Linux-Kiste (2xPentium V 2.3 GHz, 3GB RAM)? Der Rechner selbst ist jetzt ein OpenXchange-Server für den Kunden und langweilt sich fürchterlich...
Läuft das Ding in guter alter Linux-Manier "einfach so immer" oder sollte ich das Image wöchentlich oder täglich neu starten?
Gibt's irgendwelche Besonderheiten zu beachten? Harte Grenzen wie die max. Zahl an Objekten oder sowas?
Gibt's irgendwelche Tipps und Tricks für bzw. Warnungen vor bestimmten Tools, die fürs Arbeiten wichtig sind? Enorm hilfreich für mich wären z.b. die beiden "History"-Knöpfchen "<" und ">", die der alte RefactoringBrowser hatte, der neue OmniBrowser aber anscheinend nicht.
Welche Image-Version nimmt "man" denn heute zum Entwickeln? Ich hab auf dem Windows-Laptop eine 3.10-er VM und das letzte 3.9-er image und ein Weilchen mit Universes und SqueakMap und Monticello@SqueakSource gekämpft, bis ich ein System beisammen hatte, in dem die Sachen drin waren, die ich haben wollte.
Schönes Wochenende, s.
Nochmal Hallo!
On Sat, 15 Sep 2007 18:09:55 +0200 "Philippe Marschall" philippe.marschall@gmail.com wrote:
Also wenn du das SQLServer und 32bit Requirement nicht hättest und das Projekt nicht schon am laufen wäre, dann wäre ev. GLASS einen Blick wert: http://seaside.gemstone.com/
hmm... wäre lustig, aber ich will da weder den bestehenden OX-Server migrieren noch eine weitere Kiste in den eh schon zu vollen Server-Raum stellen, v.a. wenn's da schon einen Rechner gibt, der kaum was zu tun hat.
s.
Am 15.09.07 schrieb Philippe Marschall philippe.marschall@gmail.com:
Am 15.09.07 schrieb Stefan Schmiedl s@xss.de:
Hallo Squeaker.
Nachdem mich die Jungs von Cincom letzte Woche etwas verärgert haben, bin ich am ernsthaften Überlegen, fällt das Hauptargument für VisualWorks (plattformübergreifende "Standard"-GUI-Clients) weg.
Eine anstehende Web-Applikation hab ich zwar schon in VW angefangen, aber AIDA gibt's auch für Squeak, da sollte sich der Aufwand für den Umstieg in Grenzen halten. Die Daten liegen zurzeit in einer ca 120MB großen SQLServer-Datenbank, wo ich sie wohl auch liegen lassen muss, damit die übrigen Komponenten nach wie vor funktionieren.
Also wenn du das SQLServer und 32bit Requirement nicht hättest und das Projekt nicht schon am laufen wäre, dann wäre ev. GLASS einen Blick wert: http://seaside.gemstone.com/ Lass dich vom Seaside nicht verwirren. Du bist frei, was du damit laufen lassen willst. Janko hat einen Beta account und arbeitet damit. Es würde mich nicht wundern, wenn AIDA schon bald auf Gemstone/S laufen würde.
Läuft: http://mivsek.eranova.si:8888/
Philippe
Die Idee dahinter ist dass du deine Applikation in Squeak entwickelst und dann auf Gemstone/S deployst. Die haben auch eine Menge Squeak tools. So kannst du damit z.B. auch Monticello benutzen. Die Tools sind allerdings noch recht beta.
Gruss Philippe
Bevor ich da aber ernsthaft anfange, würde ich gerne wissen:
Wie macht sich denn Squeak so als Langlauf-Server-Prozess auf einer (32-bit)-Linux-Kiste (2xPentium V 2.3 GHz, 3GB RAM)? Der Rechner selbst ist jetzt ein OpenXchange-Server für den Kunden und langweilt sich fürchterlich...
Läuft das Ding in guter alter Linux-Manier "einfach so immer" oder sollte ich das Image wöchentlich oder täglich neu starten?
Gibt's irgendwelche Besonderheiten zu beachten? Harte Grenzen wie die max. Zahl an Objekten oder sowas?
Gibt's irgendwelche Tipps und Tricks für bzw. Warnungen vor bestimmten Tools, die fürs Arbeiten wichtig sind? Enorm hilfreich für mich wären z.b. die beiden "History"-Knöpfchen "<" und ">", die der alte RefactoringBrowser hatte, der neue OmniBrowser aber anscheinend nicht.
Welche Image-Version nimmt "man" denn heute zum Entwickeln? Ich hab auf dem Windows-Laptop eine 3.10-er VM und das letzte 3.9-er image und ein Weilchen mit Universes und SqueakMap und Monticello@SqueakSource gekämpft, bis ich ein System beisammen hatte, in dem die Sachen drin waren, die ich haben wollte.
Schönes Wochenende, s.
Am 18.09.07 schrieb Adrian Kuhn akuhn@gmx.ch:
On 18 Sep 2007, at 18:36 , Philippe Marschall wrote:
Es würde mich nicht wundern, wenn AIDA schon bald auf Gemstone/S laufen würde.
Was ist AIDA?
Ein web-framework: http://www.aidaweb.si/
Gruss Philippe
gruss, AA
Danke.
On 18 Sep 2007, at 20:07 , Philippe Marschall wrote:
Am 18.09.07 schrieb Adrian Kuhn akuhn@gmx.ch:
On 18 Sep 2007, at 18:36 , Philippe Marschall wrote:
Es würde mich nicht wundern, wenn AIDA schon bald auf Gemstone/S laufen würde.
Was ist AIDA?
Ein web-framework: http://www.aidaweb.si/
Gruss Philippe
gruss, AA
Schön auch einen Artikel über Squeak/Seaside momentan unter dieser Adresse (herunterladbar!!!) zu finden:
http://www.computer.org/portal/site/software
Kudos to Stef, Lukas und Adrian!
Markus
Hallo Stefan,
eines vorweg: ich habe keine ernsthafte Erfahrungen mit Squeak, beobachte und probiere es aber schon eine Weile.
Nachdem mich die Jungs von Cincom letzte Woche etwas verärgert haben, bin ich am ernsthaften Überlegen, fällt das Hauptargument für VisualWorks (plattformübergreifende "Standard"-GUI-Clients) weg.
Die letzten Wochen waren für Smalltalk-Freunde wirklich nicht erfreulich. Erst kündigt Object-Arts an, dass Dolphin nicht mehr weiter entwickelt werden kann und nun das Desaster bei Cincom.
Eine anstehende Web-Applikation hab ich zwar schon in VW angefangen, aber AIDA gibt's auch für Squeak, da sollte sich der Aufwand für den Umstieg in Grenzen halten. Die Daten liegen zurzeit in einer ca 120MB großen SQLServer-Datenbank, wo ich sie wohl auch liegen lassen muss, damit die übrigen Komponenten nach wie vor funktionieren.
Bevor ich da aber ernsthaft anfange, würde ich gerne wissen:
- Wie macht sich denn Squeak so als Langlauf-Server-Prozess auf einer (32-bit)-Linux-Kiste (2xPentium V 2.3 GHz, 3GB RAM)? Der Rechner selbst ist jetzt ein OpenXchange-Server für den Kunden und langweilt sich fürchterlich...
- Läuft das Ding in guter alter Linux-Manier "einfach so immer" oder sollte ich das Image wöchentlich oder täglich neu starten?
- Gibt's irgendwelche Besonderheiten zu beachten? Harte Grenzen wie die max. Zahl an Objekten oder sowas?
Schau Dir mal die Mailinglisten-Archive der letzten Wochen an. Dort findest Du interessante Diskussionen zum Thema Speicherverwaltung und Stabilität. Auch ein Blick auf Mantis (http://bugs.squeak.org) lohnt sich.
- Gibt's irgendwelche Tipps und Tricks für bzw. Warnungen vor bestimmten Tools, die fürs Arbeiten wichtig sind? Enorm hilfreich für mich wären z.b. die beiden "History"-Knöpfchen "<" und ">", die der alte RefactoringBrowser hatte, der neue OmniBrowser aber anscheinend nicht.
Meine Erfahrungen mit Squeak sind hier eher schlecht. Eigentlich passiert es mir regelmäßig, dass Aktualisierungen von Paketen zu ziemlicher Instabilität und Unbenutzbarkeit führen. Gerade das OmniBrowser-Framework tut sich hier m.E. besonders (negativ) hervor: Es wird recht intensiv weiter entwickelt, aber Aktualisierungen über das Package-Universe führen häufig dazu, dass ich ein neues Image erstellen muss.
- Welche Image-Version nimmt "man" denn heute zum Entwickeln? Ich hab auf dem Windows-Laptop eine 3.10-er VM und das letzte 3.9-er image und ein Weilchen mit Universes und SqueakMap und Monticello@SqueakSource gekämpft, bis ich ein System beisammen hatte, in dem die Sachen drin waren, die ich haben wollte.
Das ist eine interessante Frage. Diese zu beantworten hängt von Deinen Anforderungen ab. Leider laufen die VM-Varianten ein wenig auseinander. Andreas Raab (Windows) und John McIntosh (MAC) sind recht agil, Ian Piumarta (UNIX) ist eher zurückhaltend.
Zu den Images: Viele halten die 3.8er für die stabilste. 3.9 hat etliche Bugs, um die man leider selber kümmern muss. Es gibt zwar einige Patches (in Mantis), aber die fließen nur in die aktuell "entwickelte" Version 3.10 ein.
Hier komme ich auch zu meinem eigentlichen Eindruck von Squeak: Ich finde, dass man Squeak nicht guten Gewissens in einem kommerziellen Umfeld nutzen kann. Zumindest gilt das m.E. für kaufmännische und produktive Bereiche. Für Lehr- und Lernzwecke halte ich Squeak hingegen für ausgezeichnet geeignet.
Warum ist es im kaufmännischen Umfeld nicht benutzbar? Ganz einfach: es fehlt an Stabilität und Funktionalität. In meinen Augen fehlt es dem Squeak-Projekt an Geld und Führung. Es wird von verschiedenen Gruppen und einzelnen Leuten für eigene Zwecke weiter entwickelt: Forschung und Lehre sowie Multimedia sind die herausragenden Gebiete. Hier kommt es aber weitgehend nicht auf Stabilität und standardkonforme GUI an. Das bemerkt man in Squeak an vielen Stellen: Es gibt zwar viele interessante Programme und Frameworks, aber die sind meist nicht zuende gestellt worden, sondern nur soweit wie man es brauchte. Viele fragwürdige Dinge sind in den Jahren im Standard-Image gelandet und werden nun mühselig wieder entfernt. Auch die Qualität des Codes ist ziemlich unterschiedlich. Häufig fehlen Kommentare und über Dokumentation brauchen wir gar nicht erst diskutieren...
Zusammengefasst: Um die GUI ist es in Squeak noch schlimmer gestellt als bei VisualWorks. Datenbankanbindungen sind bis auf (rudimentäre) ODBC- und PostgreSQL-Treiber nicht vorhanden. Die Vorteile, die ich hier trotzdem sehe: man muss nicht auch noch horrende Lizenzgebühren bezahlen und (fast) alles ist OpenSource.
Insgesamt hat mich die Entwicklung der letzten Monate ziemlich traurig gemacht. In meinen Augen hat das Sterben von Smalltalk vor einigen Monaten mit dem Ausstieg von IBM begonnen, dann folgte vor Kurzem die Abkündigung von Object Arts und nun killt auch Cincom noch VisualWorks. Smalltalk ist die beste und eleganteste Programmiersprache, die ich kenne. Leider gibt es keine gute Implementierung (mehr). Meine letzte, geringe Hoffnung bereitet mir der Versuch des Buyouts von Dolphin, um es in den OpenSource-Pool zu stellen. Ich weiß allerdings nicht, ob wirklich genug Geld gesammelt werden kann.
Viele Grüße Andreas
Hallo Andreas.
On Sat, 15 Sep 2007 20:50:37 +0200 Andreas Wacknitz A.Wacknitz@gmx.de wrote:
eines vorweg: ich habe keine ernsthafte Erfahrungen mit Squeak, beobachte und probiere es aber schon eine Weile.
hehe ... trifft auf mich auch zu. Typischerweise vergehen so 0.2 bis 0.3 Versionen zwischen meinen Squeak-Besuchen.
Nachdem mich die Jungs von Cincom letzte Woche etwas verärgert haben, bin ich am ernsthaften Überlegen, fällt das Hauptargument für VisualWorks (plattformübergreifende "Standard"-GUI-Clients) weg.
Die letzten Wochen waren für Smalltalk-Freunde wirklich nicht erfreulich. Erst kündigt Object-Arts an, dass Dolphin nicht mehr weiter entwickelt werden kann und nun das Desaster bei Cincom.
Wie bei Krieg der Sterne... wir sind gerade im fünften Teil, wo's allen mies geht. Ich persönlich hoffe auf einen Return of the Dolphin durch die Buyout-Aktion :-)
Meine Erfahrungen mit Squeak sind hier eher schlecht. Eigentlich passiert es mir regelmäßig, dass Aktualisierungen von Paketen zu ziemlicher Instabilität und Unbenutzbarkeit führen. Gerade das OmniBrowser-Framework tut sich hier m.E. besonders (negativ) hervor: Es wird recht intensiv weiter entwickelt, aber Aktualisierungen über das Package-Universe führen häufig dazu, dass ich ein neues Image erstellen muss.
Würde mich eher wenig stören, weil ich jetzt gerade ein Image hab, in dem es kaum Überraschungen durch DNUs oder sonstige Fehler gibt. Das heißt, ich würde hier an den Tools wenig schrauben müssen.
Zu den Images: Viele halten die 3.8er für die stabilste. 3.9 hat etliche Bugs, um die man leider selber kümmern muss. Es gibt zwar einige Patches (in Mantis), aber die fließen nur in die aktuell "entwickelte" Version 3.10 ein.
Es hat mich ziemliche Anstrengung gekostet, den Updater das Image *nicht* auf 3.10 umstellen zu lassen, aber ich weiß noch von früher (3.6/7), dass ich dann vor lauter Update-Einspielen zu nichts anderem komme... Dabei gibt's dann zwar viel über Squeak zu lernen, aber das trägt nicht unmittelbar zum Tageschäft bei.
Warum ist es im kaufmännischen Umfeld nicht benutzbar? Ganz einfach: es fehlt an Stabilität und Funktionalität.
Den Eindruck vermitteln mir eure Antworten auch. Wenn die ODBC-Schnittstelle die VM blockiert, kommt das nicht gut an, fürchte ich. Wenn wir über Laufzeiten von zwei Tagen reden, ist das eher an der Untergrenze dessen, was ich bei einer Anwendung haben will, die werktags von 7 bis 18 Uhr laufen muss, weil sonst der sitzende Teil der Firma steht.
Insgesamt hat mich die Entwicklung der letzten Monate ziemlich traurig gemacht. In meinen Augen hat das Sterben von Smalltalk vor einigen Monaten mit dem Ausstieg von IBM begonnen, dann folgte vor Kurzem die Abkündigung von Object Arts und nun killt auch Cincom noch VisualWorks.
Naja ... IBMs Ausstieg interpretiere ich eher als Auslagerung zu wie-heißen-sie-gleich-wieder? Instantiations? Das Ding gibt's ja noch. Beim Rest hast du allerdings recht.
Smalltalk ist die beste und eleganteste Programmiersprache, die ich kenne.
Dafür hat Smalltalk das mieseste Marketing, wobei ich ausdrücklich alle Squeak-Vorträge ausnehme, die ich bisher (live oder als Video) sehen konnte. Die waren ausnahmslos klasse.
Leider gibt es keine gute Implementierung (mehr).
Bei ST/X geht's auch nicht wirklich weiter, glaub ich. Paolo Bonzini hat Gnu Smalltalk allerdings wieder kräftig vorangetrieben, wobei da halt immer noch keine Smalltalk-typische GUI-Integration vorhanden ist.
Meine letzte, geringe Hoffnung bereitet mir der Versuch des Buyouts von Dolphin, um es in den OpenSource-Pool zu stellen. Ich weiß allerdings nicht, ob wirklich genug Geld gesammelt werden kann.
Naja ... wenn ich eine Alternative zu VW finden würde, die nix kostet, würde ich die Kosten für meine VAR-Lizenz zu Dolphin umschichten. Aber so wie's aussieht, passiert das eher nicht.
Gerade hab ich ein Posting von Frank Lesser (http://www.lesser-software.com) gesehen, der sein firmeneigenes Windows-Smalltalk demnächst auch auf 64-bit Linux bringen will, was natürlich gut ist, mir aber *jetzt* gerade wenig hilft.
Vielen Dank für die Hilfe, s.
On Sep 15, 2007, at 20:50 , Andreas Wacknitz wrote:
In meinen Augen hat das Sterben von Smalltalk vor einigen Monaten mit dem Ausstieg von IBM begonnen, dann folgte vor Kurzem die Abkündigung von Object Arts und nun killt auch Cincom noch VisualWorks.
Was ist denn eigentlich los bei Cincom? Das ist an mir vorbeigegangen, und eine kurze Webrecherche hat auch nichts zu Tage gefördert.
- Bert -
Bert Freudenberg wrote:
On Sep 15, 2007, at 20:50 , Andreas Wacknitz wrote:
In meinen Augen hat das Sterben von Smalltalk vor einigen Monaten mit dem Ausstieg von IBM begonnen, dann folgte vor Kurzem die Abkündigung von Object Arts und nun killt auch Cincom noch VisualWorks.
Was ist denn eigentlich los bei Cincom? Das ist an mir vorbeigegangen, und eine kurze Webrecherche hat auch nichts zu Tage gefördert.
- Bert -
James Robertson, der Cincom Smalltalk-Produktmanager, hat am 10.09. angekündigt, dass Widgetry eingestellt wird. Widgetry ist in den letzten 6 Jahren entwickelt worden und sollte das betagte GUI-Framework "Wrapper" in VisualWorks ablösen. Daraus wird jetzt nichts mehr. Man hat angeblich festgestellt, dass eine Portierung der Werkzeuge nicht mit vertretbarem Aufwand durchführbar sei. Außerdem würden auf viele Kunden diese Aufwände scheuen. Statt Widgetry, dass erst vor etwa 2 Monaten Produktionsreife erlangte, soll nun das alte Framework weiterentwickelt werden. Einige Kunden sind wohl zurecht enttäuscht. In der VW-Mailingliste gibt es eine umfangreiche Diskussion über die Folgen.
Andreas
On Sep 15, 2007, at 23:21 , Andreas Wacknitz wrote:
Bert Freudenberg wrote:
On Sep 15, 2007, at 20:50 , Andreas Wacknitz wrote:
In meinen Augen hat das Sterben von Smalltalk vor einigen Monaten mit dem Ausstieg von IBM begonnen, dann folgte vor Kurzem die Abkündigung von Object Arts und nun killt auch Cincom noch VisualWorks.
Was ist denn eigentlich los bei Cincom? Das ist an mir vorbeigegangen, und eine kurze Webrecherche hat auch nichts zu Tage gefördert.
- Bert -
James Robertson, der Cincom Smalltalk-Produktmanager, hat am 10.09. angekündigt, dass Widgetry eingestellt wird. Widgetry ist in den letzten 6 Jahren entwickelt worden und sollte das betagte GUI-Framework "Wrapper" in VisualWorks ablösen. Daraus wird jetzt nichts mehr. Man hat angeblich festgestellt, dass eine Portierung der Werkzeuge nicht mit vertretbarem Aufwand durchführbar sei. Außerdem würden auf viele Kunden diese Aufwände scheuen. Statt Widgetry, dass erst vor etwa 2 Monaten Produktionsreife erlangte, soll nun das alte Framework weiterentwickelt werden. Einige Kunden sind wohl zurecht enttäuscht. In der VW-Mailingliste gibt es eine umfangreiche Diskussion über die Folgen.
Naja, das kann man ja wohl kaum als "VisualWorks killen" bezeichnen ...
- Bert -
Bert Freudenberg wrote:
On Sep 15, 2007, at 23:21 , Andreas Wacknitz wrote:
Bert Freudenberg wrote:
On Sep 15, 2007, at 20:50 , Andreas Wacknitz wrote:
In meinen Augen hat das Sterben von Smalltalk vor einigen Monaten mit dem Ausstieg von IBM begonnen, dann folgte vor Kurzem die Abkündigung von Object Arts und nun killt auch Cincom noch VisualWorks.
Was ist denn eigentlich los bei Cincom? Das ist an mir vorbeigegangen, und eine kurze Webrecherche hat auch nichts zu Tage gefördert.
- Bert -
James Robertson, der Cincom Smalltalk-Produktmanager, hat am 10.09. angekündigt, dass Widgetry eingestellt wird. Widgetry ist in den letzten 6 Jahren entwickelt worden und sollte das betagte GUI-Framework "Wrapper" in VisualWorks ablösen. Daraus wird jetzt nichts mehr. Man hat angeblich festgestellt, dass eine Portierung der Werkzeuge nicht mit vertretbarem Aufwand durchführbar sei. Außerdem würden auf viele Kunden diese Aufwände scheuen. Statt Widgetry, dass erst vor etwa 2 Monaten Produktionsreife erlangte, soll nun das alte Framework weiterentwickelt werden. Einige Kunden sind wohl zurecht enttäuscht. In der VW-Mailingliste gibt es eine umfangreiche Diskussion über die Folgen.
Naja, das kann man ja wohl kaum als "VisualWorks killen" bezeichnen ...
- Bert -
Ich sehe das schon so. Es ist zwar kein sofortiges, abruptes Ende, aber wie soll es denn weitergehen? Die Bestandskunden müssen die Kröte schlucken, auch wenn einige ihren Unmut momentan kundtun und wie Stefan nach Alternativen suchen. Fraglich ist aber, wie man neue Kunden gewinnen will. Wenn Smalltalk doch so überlegen ist, warum gibt es dann so ein unkomfortables Framework? Was hat man noch von der Produktivität Smalltalks, wenn sie bei der GUI wieder kompensiert wird? Heutezutage muss man sich an Java + Swing + Netbeans + Matisse messen. Und sieht es im gesamten Smalltalklager ziemlich bescheiden aus. In der VW-Mailingliste hat jemand die Situation in VW mit einem Wort umschrieben: Hackertalk. Dieser Begriff trifft leider an verschiedenen Stellen auch auf Squeak zu.
Andreas
On Sun, 16 Sep 2007 10:09:13 +0200 Andreas Wacknitz A.Wacknitz@gmx.de wrote:
Bert Freudenberg wrote:
Naja, das kann man ja wohl kaum als "VisualWorks killen" bezeichnen ...
Ich sehe das schon so. Es ist zwar kein sofortiges, abruptes Ende, aber wie soll es denn weitergehen? Die Bestandskunden müssen die Kröte schlucken, auch wenn einige ihren Unmut momentan kundtun und wie Stefan nach Alternativen suchen.
VW als Ganzes abwürgen wird ja wohl hoffentlich auch niemand wollen.
Das Argument: "Wir stellen nicht komplett auf Widgetry um, weil dann alles Alte umgeschrieben werden muss." verstehe ich ja auch. Aber das Teil jetzt zu begraben, und damit alles Neue zu vergrätzen, finde ich persönlich idiotisch.
Mir persönlich stößt unheimlich sauer auf, dass aus keiner offiziellen Quelle irgendwelche Unsicherheiten bzgl. der Zukunft von Widgetry zu hören waren, dass das Ding (zwar heimlich, aber doch) vor ein paar Wochen als ein von Cincom entwickeltes VW-Modul mit Version 1.0 deklariert wurde und damit salonfähig schien. Sam Shuster hat das sogar in einer Mail an die developer-Liste am 19.6. explizit so gesagt:
B. Popov> Does this mean it is now a fully supported framework? S. Shuster> Yes.
Ich hab ein bisschen damit rumgespielt und fand es schon bei der Erstellung eines "normalen" GUI ohne spezielle Widgets viel komfortabler als das krakelige alte Tool. Das hab ich dann in meinem jugendlichen Leichtsinn natürlich gegenüber einem Kunden auch so dargestellt und dass ich dem dann beim letzten Termin erzählen durfte, dass das Framework offiziell nicht mehr unterstützt wird, kam gar nicht gut an...
Jetzt hab ich genug geflennt, ich mach mich wieder an die Arbeit.
Schönen Sonntag, s.
Guten Abend, Bert,
On 9/15/07, Bert Freudenberg bert@freudenbergs.de wrote:
Was ist denn eigentlich los bei Cincom? Das ist an mir vorbeigegangen, und eine kurze Webrecherche hat auch nichts zu Tage gefördert.
Widgetry wird fallen gelassen: http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=336...
Viele Grüße,
Michael
On 15.09.2007, at 20:50, Andreas Wacknitz wrote:
Schau Dir mal die Mailinglisten-Archive der letzten Wochen an. Dort findest Du interessante Diskussionen zum Thema Speicherverwaltung und Stabilität. Auch ein Blick auf Mantis (http://bugs.squeak.org) lohnt sich.
Was ein bischen schade ist ist das 3.10 wohl bugtracking nicht mehr wirklich nutzt... am ende von 3.9 waren wir auf <250 entraege, jetzt sind es wieder 742
Zu den Images: Viele halten die 3.8er für die stabilste. 3.9 hat etliche Bugs, um die man leider selber kümmern muss.
Als 3.9 released wurde, hatte es keine bekannten bugs. Und es gibt durchaus Leute (auch ausser meiner wenigkeit), die 3.9 als besser als 3.8 (auch stabiler) ansehen. Es sind ne menge Bugs in 3.9 nicht mehr drin die in 3.8 drin sind...
Und 3.9 ist die erste (und wohl auch letzte) die die code-bases von Squeak.org, Small-Land, SCG und Squeakland merged. Dazu alles, was von Impara und Netstyle an anmerkungen kamm (Alles!). Leider keine fixes von Croquet, aber von dort wurden keine fixes submitted (leider).
Das war schon arbeit... glaubt mir aber wohl niemand.
Das Problem ist, dass man (oder besser: ich) schonmal bloede Fehler mache... dazu kommt, das es unmoeglich ist was zu aendern ohne neue Fehler einzugbauen. Sowas wie 3.9 kann man im grunde nicht machen ohne sich zu blamieren. Und die Zeit die man da reinsteckt kann man nix "cooles" machen. Am ende ist man nur der idiot.
Was bei 3.9 fehlt ist ein 3.9.1, ich bin seit einige Monaten nicht mehr aktiv, es muesste also von jemand anderem gemacht werden.
Es gibt zwar einige Patches (in Mantis), aber die fließen nur in die aktuell "entwickelte" Version 3.10 ein.
Und in Mantis passiert nicht wirklich viel... 500 mehr offene bug- reports als in 3.9 sieht nicht gut aus.
Viele fragwürdige Dinge sind in den Jahren im Standard-Image gelandet und werden nun mühselig wieder entfernt.
Point taken.
Fragwuerdig ist aber auch die Qualitaet des Codes von Squeak Central: Es ist hart, aber man muss einfach sagen: Das ist ueber weite strecken nicht gut, sondern ein einziger, haesslicher hack.
Es ist einfach nicht wahr, das Squeak das geniale, super refactorierte system war und dann nach 2001 (so Leute wie ich) alles kaputt gemacht haetten.
Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
Hallo Markus,
Marcus Denker wrote:
On 15.09.2007, at 20:50, Andreas Wacknitz wrote:
Schau Dir mal die Mailinglisten-Archive der letzten Wochen an. Dort findest Du interessante Diskussionen zum Thema Speicherverwaltung und Stabilität. Auch ein Blick auf Mantis (http://bugs.squeak.org) lohnt sich.
Was ein bischen schade ist ist das 3.10 wohl bugtracking nicht mehr wirklich nutzt... am ende von 3.9 waren wir auf <250 entraege, jetzt sind es wieder 742
Zu den Images: Viele halten die 3.8er für die stabilste. 3.9 hat etliche Bugs, um die man leider selber kümmern muss.
Als 3.9 released wurde, hatte es keine bekannten bugs. Und es gibt durchaus Leute (auch ausser meiner wenigkeit), die 3.9 als besser als 3.8 (auch stabiler) ansehen. Es sind ne menge Bugs in 3.9 nicht mehr drin die in 3.8 drin sind...
Und 3.9 ist die erste (und wohl auch letzte) die die code-bases von Squeak.org, Small-Land, SCG und Squeakland merged. Dazu alles, was von Impara und Netstyle an anmerkungen kamm (Alles!). Leider keine fixes von Croquet, aber von dort wurden keine fixes submitted (leider).
Das war schon arbeit... glaubt mir aber wohl niemand.
Das Problem ist, dass man (oder besser: ich) schonmal bloede Fehler mache... dazu kommt, das es unmoeglich ist was zu aendern ohne neue Fehler einzugbauen. Sowas wie 3.9 kann man im grunde nicht machen ohne sich zu blamieren. Und die Zeit die man da reinsteckt kann man nix "cooles" machen. Am ende ist man nur der idiot.
Was bei 3.9 fehlt ist ein 3.9.1, ich bin seit einige Monaten nicht mehr aktiv, es muesste also von jemand anderem gemacht werden.
Es gibt zwar einige Patches (in Mantis), aber die fließen nur in die aktuell "entwickelte" Version 3.10 ein.
Und in Mantis passiert nicht wirklich viel... 500 mehr offene bug-reports als in 3.9 sieht nicht gut aus.
Viele fragwürdige Dinge sind in den Jahren im Standard-Image gelandet und werden nun mühselig wieder entfernt.
Point taken.
Fragwuerdig ist aber auch die Qualitaet des Codes von Squeak Central: Es ist hart, aber man muss einfach sagen: Das ist ueber weite strecken nicht gut, sondern ein einziger, haesslicher hack.
Es ist einfach nicht wahr, das Squeak das geniale, super refactorierte system war und dann nach 2001 (so Leute wie ich) alles kaputt gemacht haetten.
meine Ausführungen waren in keinster Weise als Anklage oder Beschuldigung in Deine oder Stephanes Richtung gedacht. Im Gegenteil, Ihr habt viel Aufwand hineingesteckt und das muss und soll auch gewürdigt werden.
Ich glaube, dass es Squeak an einer starken Führung und Geld mangelt. Man merkt an vielen Stellen, dass Squeak kein Produkt ist, dass vermarktet werden muss. Mir erscheint es, als ob jeder im Wesentlichen seine eigenen Interessen verfolgen würde. Das steht natürlich jedem zu, schließlich erfolgt die Arbeit daran ja auf freiwilliger Basis. Aber die Folgen sind deshalb sichtbar: einige Bereiche bedürfen dringend der Überarbeitung, es geschieht aber nichts oder nicht genug. Wie man anhand von Widgetry erkennen kann, ist es auch keine leichte Aufgabe, mal eben ein neues GUI-Framework zu entwickeln. Gerade auf diesem Gebiet hat es bei Squeak in der Vergangenheit viele Versuche Einzelner gegeben, die aber alle vor der Fertigstellung aufgegeben wurden.
Mit Squeak zu "spielen" macht viel Spaß. Damit Smalltalk und Objektorientierung zu lernen ist prima möglich. Kommerzielle Produkte damit zu entwickeln halte ich aber für sehr gewagt, wenn auch sehr reizvoll. Ich glaube sogar, dass man in der Embedded-Welt damit einen guten Stand hätte, weil weder Datenbankanbindungen noch Standard-GUI dort wichtig sind. Aber leider werden anscheinend nur noch Virtuelle Maschinen für Mainstream-Betriebsysteme (Windows, MAC OS und Linux) gepflegt.
Andreas
On Sun, 16 Sep 2007 12:32:31 +0200, Marcus Denker wrote:
On 15.09.2007, at 20:50, Andreas Wacknitz wrote:
Schau Dir mal die Mailinglisten-Archive der letzten Wochen an. Dort findest Du interessante Diskussionen zum Thema Speicherverwaltung und Stabilität. Auch ein Blick auf Mantis (http://bugs.squeak.org) lohnt sich.
Was ein bischen schade ist ist das 3.10 wohl bugtracking nicht mehr wirklich nutzt... am ende von 3.9 waren wir auf <250 entraege, jetzt sind es wieder 742
Zu den Images: Viele halten die 3.8er für die stabilste. 3.9 hat etliche Bugs, um die man leider selber kümmern muss.
Als 3.9 released wurde, hatte es keine bekannten bugs. Und es gibt durchaus Leute (auch ausser meiner wenigkeit), die 3.9 als besser als 3.8 (auch stabiler) ansehen. Es sind ne menge Bugs in 3.9 nicht mehr drin die in 3.8 drin sind...
Das 3.9er ist das beste was jemals gemacht wurde (ich vergleiche hier nur 3.6/3.7/3.8/3.9), weil es Traits und die Grundlagen für BlockClosures enthält. Beides sind Differenziatoren (im Sinne von: das Besondere, das Unverwechselbare einer Marke/eines Produktes) welche bei nicht-kurzfristigen Vorhaben ihre Kraft zeigen werden. Das das von einigen (offenbar nur wenige Stimmen) so nicht gesehen wird deutet m.E. eher auf eine Führungsschwäche von "alten" Kämpen hin.
Und 3.9 ist die erste (und wohl auch letzte) die die code-bases von Squeak.org, Small-Land, SCG und Squeakland merged. Dazu alles, was von Impara und Netstyle an anmerkungen kamm (Alles!). Leider keine fixes von Croquet, aber von dort wurden keine fixes submitted (leider).
Das war schon arbeit... glaubt mir aber wohl niemand.
Das Problem ist, dass man (oder besser: ich) schonmal bloede Fehler mache... dazu kommt, das es unmoeglich ist was zu aendern ohne neue Fehler einzugbauen. Sowas wie 3.9 kann man im grunde nicht machen ohne sich zu blamieren. Und die Zeit die man da reinsteckt kann man nix "cooles" machen. Am ende ist man nur der idiot.
Was bei 3.9 fehlt ist ein 3.9.1, ich bin seit einige Monaten nicht mehr aktiv, es muesste also von jemand anderem gemacht werden.
Es gibt zwar einige Patches (in Mantis), aber die fließen nur in die aktuell "entwickelte" Version 3.10 ein.
Und in Mantis passiert nicht wirklich viel... 500 mehr offene bug- reports als in 3.9 sieht nicht gut aus.
Viele fragwürdige Dinge sind in den Jahren im Standard-Image gelandet und werden nun mühselig wieder entfernt.
Point taken.
Fragwuerdig ist aber auch die Qualitaet des Codes von Squeak Central: Es ist hart, aber man muss einfach sagen: Das ist ueber weite strecken nicht gut, sondern ein einziger, haesslicher hack.
Es ist einfach nicht wahr, das Squeak das geniale, super refactorierte system war und dann nach 2001 (so Leute wie ich) alles kaputt gemacht haetten.
Wie Andreas an anderer Stelle schon ganz richtig bemerkte fehlt es Squeak an einer starken Führung (ja, Du fehlst auch, Marcus). Andreas: ich bezweifle allerdings, dass Geld etwas "gutes" für Squeak bewirken würde, ausser es war als Kompensation für Support gemeint. Denn wie Marcus schon ganz richtig bemerkte kommt von den "Geld" Projekten nicht viel an Squeak zurück. Aber leider, an der Formel Support-für-Geld beisst sich Stéphane Ducasse schon seit einiger Zeit die Zähne aus ... wenn ich mich nicht irre ist er ja auch deswegen vom vorherigen SqF Board zurückgetreten.
Ich spekuliere jetzt einfach mal so, dass 3.9 noch eingestampft wird weil es bereits schuldig gesprochen wurde. Aber auch dazu bräuchte es starke Führung ;-)
Cheers Klaus
Marcus
Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
Klaus D. Witzel wrote:
Wie Andreas an anderer Stelle schon ganz richtig bemerkte fehlt es Squeak an einer starken FÌhrung (ja, Du fehlst auch, Marcus). Andreas: ich bezweifle allerdings, dass Geld etwas "gutes" fÌr Squeak bewirken wÌrde, ausser es war als Kompensation fÌr Support gemeint. Denn wie Marcus schon ganz richtig bemerkte kommt von den "Geld" Projekten nicht viel an Squeak zurÌck. Aber leider, an der Formel Support-fÌr-Geld beisst sich Stéphane Ducasse schon seit einiger Zeit die ZÀhne aus ... wenn ich mich nicht irre ist er ja auch deswegen vom vorherigen SqF Board zurÌckgetreten.
Ich denke eher an Geld für mehrere Vollzeitstellen. Das hat den Vorteil, dass man die "Angestellten" auch mit Aufgaben beauftragen kann, für die keine Freiwilligen gefunden werden. Wichtig für ein Produkt ist, dass es auch fertig gestellt wird. Freiwillige verlieren leicht kurz vor Fertigstellung die Lust. Projekte wie Eclipse, Netbeans oder auch OpenOffice werden massiv von großen Firmen gesponsort. So etwas fehlt Squeak leider.
Andreas
On Sun, 16 Sep 2007 19:32:30 +0200, Andreas Wacknitz wrote:
Klaus D. Witzel wrote:
Wie Andreas an anderer Stelle schon ganz richtig bemerkte fehlt es Squeak an einer starken Führung (ja, Du fehlst auch, Marcus). Andreas: ich bezweifle allerdings, dass Geld etwas "gutes" für Squeak bewirken würde, ausser es war als Kompensation für Support gemeint. Denn wie Marcus schon ganz richtig bemerkte kommt von den "Geld" Projekten nicht viel an Squeak zurück. Aber leider, an der Formel Support-für-Geld beisst sich Stéphane Ducasse schon seit einiger Zeit die Zähne aus ... wenn ich mich nicht irre ist er ja auch deswegen vom vorherigen SqF Board zurückgetreten.
Ich denke eher an Geld für mehrere Vollzeitstellen. Das hat den Vorteil, dass man die "Angestellten" auch mit Aufgaben beauftragen kann, für die keine Freiwilligen gefunden werden. Wichtig für ein Produkt ist, dass es auch fertig gestellt wird. Freiwillige verlieren leicht kurz vor Fertigstellung die Lust. Projekte wie Eclipse, Netbeans oder auch OpenOffice werden massiv von großen Firmen gesponsort. So etwas fehlt Squeak leider.
Ich verstehe die Richtung in die Du da schaust. Wie schätzt Du in diesem Zusammenhang GLASS ein
- http://seaside.gemstone.com/
Wenn ich den Business Ansatz von GLASS nicht falsch verstehe, möchte man dabei von der Popularität von Seaside profitieren (auch nicht verkehrt).
Cheers Klaus
Andreas
Klaus D. Witzel wrote:
Ich verstehe die Richtung in die Du da schaust. Wie schÀtzt Du in diesem Zusammenhang GLASS ein
Wenn ich den Business Ansatz von GLASS nicht falsch verstehe, möchte man dabei von der PopularitÀt von Seaside profitieren (auch nicht verkehrt).
GLASS? Zum Leben zuwenig, zum Sterben zuviel ;-) Im Ernst, ich hatte noch gar nicht über Synergieeffekte nachgedacht. Aber vielleicht kommen ja damit noch ein paar neue Leute auf den Geschmack.
Andreas
On 16.09.2007, at 22:15, Andreas Wacknitz wrote:
Klaus D. Witzel wrote:
Ich verstehe die Richtung in die Du da schaust. Wie schÀtzt Du in diesem Zusammenhang GLASS ein
Wenn ich den Business Ansatz von GLASS nicht falsch verstehe, möchte man dabei von der PopularitÀt von Seaside profitieren (auch nicht verkehrt).
GLASS? Zum Leben zuwenig, zum Sterben zuviel ;-) Im Ernst, ich hatte noch gar nicht über Synergieeffekte nachgedacht. Aber vielleicht kommen ja damit noch ein paar neue Leute auf den Geschmack.
Ich denke, das man das, was bei Cincom passiert nicht ohne GLASS in betracht zu ziehen sehen sollte. Cincom hat immer wieder betont, dass sie Seaside nicht unterstuetzen. Nur kurz nachdem GLASS announced war, da war ploetzlich Seaside in der roadmap.
Das ist doch schonmal ein Synergie-Effekt ;-)
Man muss immmer sehen, das alle der grossen Visualworks projekte Gemstone einsetzen. Ein Gemstone das ohne Visualworks auskommt ist eine existenzielle Bedrohung fuer Visualworks. Ohne diese Kunden waeren sie nicht profitabel.
Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
Am 16.09.07 schrieb Marcus Denker denker@iam.unibe.ch:
On 16.09.2007, at 22:15, Andreas Wacknitz wrote:
Klaus D. Witzel wrote:
Ich verstehe die Richtung in die Du da schaust. Wie schÀtzt Du in diesem Zusammenhang GLASS ein
Wenn ich den Business Ansatz von GLASS nicht falsch verstehe, möchte man dabei von der PopularitÀt von Seaside profitieren (auch nicht verkehrt).
GLASS? Zum Leben zuwenig, zum Sterben zuviel ;-) Im Ernst, ich hatte noch gar nicht über Synergieeffekte nachgedacht. Aber vielleicht kommen ja damit noch ein paar neue Leute auf den Geschmack.
Ich denke, das man das, was bei Cincom passiert nicht ohne GLASS in betracht zu ziehen sehen sollte. Cincom hat immer wieder betont, dass sie Seaside nicht unterstuetzen. Nur kurz nachdem GLASS announced war, da war ploetzlich Seaside in der roadmap.
Und man sagte an der ESUG explizit, dass man Leute vom Widgetry Projekt abgezogen und ins Seaside Team getan hat.
Philippe
Das ist doch schonmal ein Synergie-Effekt ;-)
Man muss immmer sehen, das alle der grossen Visualworks projekte Gemstone einsetzen. Ein Gemstone das ohne Visualworks auskommt ist eine existenzielle Bedrohung fuer Visualworks. Ohne diese Kunden waeren sie nicht profitabel.
Marcus-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
On 9/16/07, Andreas Wacknitz A.Wacknitz@gmx.de wrote:
Klaus D. Witzel wrote:
Wie Andreas an anderer Stelle schon ganz richtig bemerkte fehlt es Squeak an einer starken FÃŒhrung (ja, Du fehlst auch, Marcus). Andreas: ich bezweifle allerdings, dass Geld etwas "gutes" fÃŒr Squeak bewirken wÃŒrde, ausser es war als Kompensation fÃŒr Support gemeint. Denn wie Marcus schon ganz richtig bemerkte kommt von den "Geld" Projekten nicht viel an Squeak zurÃŒck. Aber leider, an der Formel Support-fÃŒr-Geld beisst sich StÃ(c)phane Ducasse schon seit einiger Zeit die ZÀhne aus ... wenn ich mich nicht irre ist er ja auch deswegen vom vorherigen SqF Board zurÃŒckgetreten.
Ich denke eher an Geld für mehrere Vollzeitstellen. Das hat den Vorteil, dass man die "Angestellten" auch mit Aufgaben beauftragen kann, für die keine Freiwilligen gefunden werden. Wichtig für ein Produkt ist, dass es auch fertig gestellt wird. Freiwillige verlieren leicht kurz vor Fertigstellung die Lust. Projekte wie Eclipse, Netbeans oder auch OpenOffice werden massiv von großen Firmen gesponsort. So etwas fehlt Squeak leider.
Jain. Es gibt Projekte wie etoys/OLPC, Croquet oder Sophie, die Vollzeitkräfte beschäftigen und deren Ergebnisse Open Source sind. Es liegt dann aber entweder an dem Willen der Beteiligten, Ergebnisse auch wieder in den main stream einzupflegen oder auch daran, dass in diesen Projekten einfach keine Zeit für diesen "Community Payback" eingeplant ist. Ausserdem verwenden diese Projekte alle eine ältere, stabile Version (in diesem Fall alle 3.8(.1) und können einfach nicht den Aufwand leisten, im Projektverlauf "ständig" auf neue Versionen zu portieren. Es ist aber andererseits auch verwunderlich, wie wenig von der Community aus diesen Projekten aufgegriffen wird. Man hat da schon den Eindruck, dass man die Community zum Jagen tragen muss ;-)
michael
On 16.09.2007, at 20:46, Michael Rueger wrote:
Jain. Es gibt Projekte wie etoys/OLPC, Croquet oder Sophie, die Vollzeitkräfte beschäftigen und deren Ergebnisse Open Source sind. Es liegt dann aber entweder an dem Willen der Beteiligten, Ergebnisse auch wieder in den main stream einzupflegen oder auch daran, dass in diesen Projekten einfach keine Zeit für diesen "Community Payback" eingeplant ist. Ausserdem verwenden diese Projekte alle eine ältere, stabile Version (in diesem Fall alle 3.8(.1) und können einfach nicht den Aufwand leisten, im Projektverlauf "ständig" auf neue Versionen zu portieren. Es ist aber andererseits auch verwunderlich, wie wenig von der Community aus diesen Projekten aufgegriffen wird. Man hat da schon den Eindruck, dass man die Community zum Jagen tragen muss ;-)
Wobei es aber auch garkeinen spass macht, wenn man nicht irgendwie das Gefuehl hat, das Anstrengungen in diese Richtung auch erwuenscht' sind... es fehlt einfach an Kommunikation.
Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
On Sun, 16 Sep 2007 17:37:57 +0200, Klaus D. Witzel wrote: [...]
Ich spekuliere jetzt einfach mal so, dass 3.9 noch eingestampft wird weil es bereits schuldig gesprochen wurde. Aber auch dazu bräuchte es starke Führung ;-)
Hoppla, es werden nun auch schon mögliche Gründe angeführt, "we would have to re-do 3.9 (and 3.10)", drüben in squeak-dev :|
Cheers Klaus
On Sep 23, 2007, at 14:17 , Klaus D. Witzel wrote:
On Sun, 16 Sep 2007 17:37:57 +0200, Klaus D. Witzel wrote: [...]
Ich spekuliere jetzt einfach mal so, dass 3.9 noch eingestampft wird weil es bereits schuldig gesprochen wurde. Aber auch dazu bräuchte es starke Führung ;-)
Hoppla, es werden nun auch schon mögliche Gründe angeführt, "we would have to re-do 3.9 (and 3.10)", drüben in squeak-dev :|
Quatsch. Es geht nur darum, die Historie der Methodenquelltexte wiederherzustellen.
- Bert -
Hallo Bert,
selbstverständlich respektiere ich Deine Meinung :)
Cheers Klaus
On Sun, 23 Sep 2007 14:27:16 +0200, Bert Freudenberg wrote:
On Sep 23, 2007, at 14:17 , Klaus D. Witzel wrote:
On Sun, 16 Sep 2007 17:37:57 +0200, Klaus D. Witzel wrote: [...]
Ich spekuliere jetzt einfach mal so, dass 3.9 noch eingestampft wird weil es bereits schuldig gesprochen wurde. Aber auch dazu bräuchte es starke Führung ;-)
Hoppla, es werden nun auch schon mögliche Gründe angeführt, "we would have to re-do 3.9 (and 3.10)", drüben in squeak-dev :|
Quatsch. Es geht nur darum, die Historie der Methodenquelltexte wiederherzustellen.
- Bert -
squeak-ev@lists.squeakfoundation.org
-
Adrian Kuhn -
Andreas Wacknitz -
Bert Freudenberg -
Klaus D. Witzel -
Lukas Renggli -
Marcus Denker -
Markus Gaelli -
Michael Haupt -
Michael Rueger -
Philippe Marschall -
Stefan Schmiedl