LinuxWorld Conference & Expo 2003

[Marc++us]

Also, will mal kurz die Eindrücke zusammenfassen - war heute auf der LinuxWorld Expo.

Im Vorfeld war schon klar, zu diesem Event muß man einfach hin - lockte doch vorab schon eine Meldung mit den Schlagzeilen Plattformwechsel lohnt sich - Linux als Alternative im fleischverarbeitenden Betrieb. Klar, daß man sich das nicht entgehen lassen darf.

Aussteller sind die üblichen kommerziellen Kandidaten, also Oracle, HP, Suse, RedHat, Sun, sgi, einige Verlage. Auch Novell - nach dem fortdauernden Einbruch der Marktanteile nun ein klares Bekanntnis "Eine Welt ohne Grenzen für Informationen". Anscheinend müssen die Geschäftszahlen wirklich schauderhaft sein, wenn man diese Aussage vor dem Hintergrund der alten Firmenpolitik sieht. Auch einige Verlage sind anwesend, aber nur die Namen der 2. Reihe. Keiner der größeren Anbieter (z.B. Pearson, M+T, mitp, Addison, Galileo).

Interessant die nicht-kommerziellen Aussteller im ".org-Pavillon", anwesend z.B. die Freesoftware-Foundation, KDE e.V., OpenOffice.org, preSQL, einige andere Linux-Initiativen.

Unter dem Strich war die Besucherzahl eher mäßig, es war nur schwach besucht. In etwa 2 Stunden war ich überall durch und ging wieder.

Als Trends kann man bei den Ausstellern folgende Themen erkennen:

Internetserver und zugehörige Software, also speziell VPN, Firewalls, Anti-Viruslösungen, aber das sind eher bekannte Themen und Domänen von Linux. Für uns Softwerker ohnehin nicht so interessant.

Groupware-Lösungen. Die Linux-Anbieter sind eindeutig auf der Suche nach einem Ersatz für den Exchange-Server von Microsoft, aber tun sich wohl noch schwer. Einige Anbieter (Suse, RedHat, Sun) haben hier Lösungen, die eine OS-Alternative zur Kombination Exchange+Outlook darstellen sollen. Vor allem gibt es hier ein Trend zu gemischten Kombinationen, also Linux-OpenExchange als Backend und auch mal ein Outlook als Frontend. Das ist ein etwas neuerer Trend. Aber insgesamt sieht das noch sehr neu und frisch aus, wird aber sicherlich eines der Linux-Themen in 2004 werden, ist auch klar, zur Zeit noch eine eindeutige Lücke.

Netzwerkverwaltung ist ein ähnliches Thema, hier bieten vor allem Sun, Oracle, RedHat und Suse Lösungen an, es geht letztlich um zentrale Verwaltung von Clients von Remote-Stationen aus, sowie um zentrale Verteilung/Updates von Software. Bei RedHat war dazu gerade ein Vortrag, Inhalt war, daß es zwar schon viele unterschiedliche Managementtools gibt, aber diese nicht einheitlich sind und auch keine übergreifende Strategie haben. Alle genannten Anbieter wollen hier wohl Lösungen im nächsten Jahr auf den Markt bringen.

Hardware gibt's auch, z.B. HP oder sgi treten hier an, natürlich auch mit den Flagschiffen, den Cluster-Servern. Ist aber für mich weniger interessant, sieht natürlich eindrucksvoll aus und hat auch einen warmen Luftstrom wie ein Düsenflugzeug. Peinlich übrigens (der einzige) Mainboard-Anbieter msi, der ungefähr mit dem Motto "Mainboards für Linux" antrat. Und natürlich die üblichen Standard-Komponenten ausstellte. Wen wollen die eigentlich veräppeln?

Bei den Tool-Anbietern (vor allem aber auch Sun) eine Tendenz, die auch bei den letzten .NET-Veranstaltungen von Microsoft deutlich wurde - größere Softwareprojekte basieren immer seltener nur auf einer Programmiersprache, sondern verschiedene Module sind in unterschiedlichen Sprachen realisiert. Das Verteilen der Komponente tritt in den Vordergrund vor der eigentlichen Sprachwahl. Sun trat hier z.B. mit Java-Tools an, die automatisch Java-Wrapper für C++ und C-APIs erzeugen. Interaktion lautet das Stichwort.

Sun versucht auch noch sein StarOffice ("based on OpenOffice") als Alternative zu MS Office zu lancieren, unter anderem zum Beispiel auch durch Integration in SAPs R/3. Zog einige Leute an, die anscheinend mit OpenOffice noch nicht gearbeitet hatten.

Der nicht-kommerzielle .org-Pavillon war natürlich wesentlich dürftiger ausgestattet, da hier die Initiativen und Organisationen antraten. Das brachte mich auf die Idee, daß wir da nächstes Jahr auch mal hinsollten. Warum eigentlich nicht. Für nicht-kommerzielle Anbieter geht das. An den Ständen ging es mehr um Gespräche, weniger um das Schauen. Sehr interessant eine Diskussion, die ich am KDE-Stand aufschnappte, dort diskutierten zwei Besucher mit einem Aussteller über die starke Kommerzialisierung der LinuxWorld, vor 2 Jahren wäre "der Geist" noch stärker zu spüren gewesen, heute herrsche eine starke Kommerzialisierung vor und die anderen Anbieter im anderen Messebereich wollen nur eines: "verkaufen, verkaufen, verkaufen". Wie eklig.

Dermaßen ideologisch angeschossen und geschockt von der bösen Welt - abgesehen davon war der Rundgang sowieso beendet - ging ich als echter Vertreter der Kapitalisten-Fraktion erst Mal im Bankenviertel Sushi essen.

[TDKBacke]

Marc++us schrieb:

Das brachte mich auf die Idee, daß wir da nächstes Jahr auch mal hinsollten.

Definiere "wir".

[Marc++us]

C++.de

[AndreasW]

hm,

was macht denn die 64 bit- Front ? Kann da was auf der Messe ?

[Marc++us]

Nicht wirklich.

Die fetten Server laufen zum Teil darunter, auch die Cluster-Maschinen. Aber da habe ich mich nicht so umgesehen.

Sun hat natürlich dazu was geboten, klar oder? Java auf 64 Bit. Aber war jetzt kein sichtbares Thema.

[AndreasW]

Marc++us schrieb:

Sun hat natürlich dazu was geboten, klar oder? Java auf 64 Bit.

*aufschrei*

Ich frag mich wann die Sache endlich ins Rollen kommt...

[rüdiger]

naja, Linux läuft doch auf 64 Bit Maschinen, sogar auf AMD x86-64 und Itanium und der GCC optimiert auch schon dafür.

Wenn was ins rollen kommen soll, dann doch eher die Hardware zum Kunden. Softwaretechnisch seh ich kein Problem

[Marc++us]

kingruedi schrieb:

naja, Linux läuft doch auf 64 Bit Maschinen, sogar auf AMD x86-64 und Itanium und der GCC optimiert auch schon dafür.

Wenn was ins rollen kommen soll, dann doch eher die Hardware zum Kunden. Softwaretechnisch seh ich kein Problem

Naja, das ist aber sehr optimistisch. Wahrscheinlich rollt dann erst Mal die große Portierungswelle los... bis das 32Bit-Zeugs wieder unter 64Bit läuft...

Mir ist dieser Tage - auch nach einem Gespräch mit ein paar Leuten - in dieser Hinsicht etwas bezüglich .NET aufgefallen - MS spricht doch immer von Plattformunabhängigkeit, nur welche Basis-Plattformen sollen das sein? Es gibt doch nur .NET für Windows. Ich könnte mir aber denken, daß Win64 von MS als eigene Plattform betrachtet wird - d.h. daß .NET dann auf den beiden Plattformen Win32 und Win64 läuft. Das würde irgendwie Sinn machen.

[Gerard]

.NET programme auf ein .NET64 portieren, ne das glaube ich auch nicht aber können die programme dan wirklich von den 64 bit profietieren?
was hatt man den überhaupt von den 64bit auf den desktop (.NET ist doch für den desktop programme)? super ich kamm mir mehr als 4 giga byte speicher zulegen

[Marc++us]

Es gibt kein .NET64 - es gibt nur .NET. Identische API, identische Datentypen - egal ob Win32 oder Win64.

Die Voraussetzungen dafür sind in .NET vorhanden (z.B. die Festlegung der Datentypbreite, etc).

[Korbinian]

hinfahren und nen stand machen, oder hinfahren und spass+information haben? letzteres macht mehr sinn, wär auch ne tolle sache!
auch mal systems oder sowas in betracht ziehen

[Gerard]

Marc++us schrieb:

Es gibt kein .NET64 - es gibt nur .NET. Identische API, identische Datentypen - egal ob Win32 oder Win64.

Die Voraussetzungen dafür sind in .NET vorhanden (z.B. die Festlegung der Datentypbreite, etc).

jo ich meine auch das es kein .NET64 geben wird
zu den punkt datentypenbreite ist festgelgt, bedeutet dass, das ich von jeden .NET programm zwei versionen schreiben muss die für 64 bzw 32 bit optiemiert sind

[rüdiger]

Naja, das ist aber sehr optimistisch. Wahrscheinlich rollt dann erst Mal die große Portierungswelle los... bis das 32Bit-Zeugs wieder unter 64Bit läuft...

das unterscheidet eben auch Linux und Windows, weil Linux wird ja schon effektiv als 64Bit OS eingesetzt seit Jahren. Deswegen sollte die meiste Software auch keine Probleme mit 64Bit haben.

zu den punkt datentypenbreite ist festgelgt, bedeutet dass, das ich von jeden .NET programm zwei versionen schreiben muss die für 64 bzw 32 bit optiemiert sind

jo, wobei das idr. nicht der Flaschenhals sein dürfte

[Marc++us]

kingruedi schrieb:

das unterscheidet eben auch Linux und Windows, weil Linux wird ja schon effektiv als 64Bit OS eingesetzt seit Jahren. Deswegen sollte die meiste Software auch keine Probleme mit 64Bit haben.

Reine Theorie. Das betrifft nur die Serveranwendungen unter Linux.

Die Masse der Anwendungen wurde von den üblichen Softwareentwicklern geschrieben und wird daher unter 64 Bit neu compiliert und dann schön abschmieren, bis sie "hindebuggt" wurde. Die Entwickler werden doch nicht besser, nur weil sie in anderes OS haben.

[Marc++us]

Gerard schrieb:

Marc++us schrieb:

Es gibt kein .NET64 - es gibt nur .NET. Identische API, identische Datentypen - egal ob Win32 oder Win64.

Die Voraussetzungen dafür sind in .NET vorhanden (z.B. die Festlegung der Datentypbreite, etc).

jo ich meine auch das es kein .NET64 geben wird
zu den punkt datentypenbreite ist festgelgt, bedeutet dass, das ich von jeden .NET programm zwei versionen schreiben muss die für 64 bzw 32 bit optiemiert sind

Das verstehe ich nicht. Der Gag (wie auch bei Java) ist doch, daß ich KEINE 2 Programme unter .NET schreiben muß, sondern nur eines. Und wenn ich dort in meinem Quellcode einen 32Bit-Int verwende, so bleibt der in der MSIL als 32Bit-Int. Ich brauche nur eine neue VM für Win64, die den MSIL ausführt. Und wenn ich unter .NET einen long long 64Bit nehme, bleibt der im Code erhalten. Die Optimierung auf die Datentypbreite findet dann durch die VM statt - diese verwendet dann auf einem 64Bit-System z.B. auch für 32Bit-Int 64Bit, aber die Optimierung erfolgt doch ohnehin während der Laufzeit.

Das ist doch der Vorteil von JIT-Compilierung (wie auch Java besitzt) gegenüber klassischer "statischer" Compilierung - die Optimierung bei C++ muß während der Entwicklung "offline" gemacht werden und resultiert in unterschiedlichen Binarys. Bei einer JIT-Compilierung wird die Compilierung direkt auf dem Zielsystem vorgenommen und ganz genau an das Zielsystem angepasst, wodurch sie teilweise besser angepasst werden kann. Vor allem reicht es, eine einzige Applikation (mit MSIL-Code oder Java-Bytecode) auszuliefern.

[rüdiger]

@Marc++us
viele OpenSource Produkte wurden 64Bit fit gemacht, genau wie Endian Probleme gelöst wurden. Natürlich waren die Entwickler nicht schlauer, aber dadurch das es OpenSource ist, wurden eben Anpassungen von anderen vorgenommen.

Natürlich gibt es auch Software, die solche Probleme hat, auch wenn sie OpenSource ist. Aber die meisten (vorallem alle populären) Programme sollten für 64Bit vorhanden sein.