Datensicherung, spanabhebend…

„Der Fileserver $name hat noch keine gespiegelte Systemplatte.. kannste das mal eben einrichten?“ – „Mach ich eben.“

Tja.. es haette so einfach sein koennen… ein kleiner Auftrag wie ich ihn ein oder zweimal die Woche bekomme. Also das uebliche Programm.. Swap um ein paar MB verkleinern, Meta-Partition hinbasteln, zweite Platte identisch partitionieren, Spiegeltabelle fuer die Slices schreiben und dann die Replikation anschubsen. Routine halt.

metadb, metainit, metattach, metasync… Resync in progress.. 1%… 5%… SCSI error on sd3.. Status: Retryable.. SCSI error on sd3.. Status: Retryable.. SCSI error on sd3.. Status: Fatal. Error for command: read (10)… Error for command: read (10).. SCSI error on sd3… *klack* *klack* *kriiiieeeeeetschschraddelschraddelschraddel*

Und dann habe ich das gemacht, was durch die Plattenspiegelung eigentlich zu verhindern vorgesehen war.. ich bin in den Keller getappt, habe zwei neue Platten geholt und die Kiste komplett neu installiert… *gnarf* Schon toll, wenn genau die verfuegbarkeitserhoehenden Massnahmen zum Todesstoss werden.

Bandbreite, exzessive

Heute sind endlich die lang ersehnten neuen Server gekommen… zwei schicke SunFire M5000.

Leider nur mit den langweiligen Fujitsu UltraSparc VI, aber immer noch besser als die Multicore-Celerons die sich Niagara schimpfen. Was Sun dazu bewegt hat, von 36 MB Cache beim UltraSparc IV auf 5 MB beim VI runterzugehen, wird sich mir nie erschliessen.. grade die Datenbankleute sind ueber diese Entwicklung seeehr begeistert. Die versuchen jetzt solangs noch geht die vorherigen SunFire 6900 etc abzustauben. Aber sowas bekommt man halt, wenn man mit Fujitsu kuschelt.. den CPU-Schrott den Siemens schon nicht verkauft bekommen hat.

An I/O-Power hat Chef beim Bestellen echt nicht gespart.. 54 GBit Ethernet, 32 GBit Fibrechannel – pro Maschine. Bin mal gespannt, ob die vier CPUs ausreichen um die Leitungen zu fuellen – meine Erfahrung sagt mir dass innerhalb ein paar Monaten da nochmal vier CPUs nachgelegt werden. Wenn es sowas wie „zuviel Bandbreite“ wirklich gibt, dann habe ich es jetzt erlebt.

Die Rechenleistung werd ich in den kommenden Tagen mal auf die Probe stellen.. immerhin soll die Kiste ne Reihe paralleler SFTP-Verbindungen betreiben, das Nearline-Bandarchiv managen und diverse andere Kleinigkeiten erledigen. Um die massive Netzanbindung zu testen, fehlt mir leider noch die Infrastruktur… mal schaun wann die IT uns die 10G-Leitungen zu den Coreswitches legt.

Heuschreckenalarm!

Ich wollts eigentlich am Mittwoch schon schreiben, aber man weiss ja nie wer dieses Blog hier liest, und ich will an nix schuld sein.. aber: Gestern waren die Heuschrecken im Haus.

Mal etwas zurueckgegriffen: EMI Music (ja, das gewichtige Major Label) wurde von einer Heuschrecke (Muentefering-Sprech fuer Private Equity Gesellschaft) gekauft, fuer die schlappe Summe von 5,8 Milliarden Euro. Heuschrecken deswegen, weil diese Gesellschaften ueblicherweise nur einen Bruchteil des Kaufpreises als Eigenkapital zahlen – der Rest wird als Kredit aufgenommen und nach dem Kauf an das Opfer uebertragen, und das so abgeschoepfte Kapital an die Anleger ausgezahlt. „Rekapitalisierung“ nennt sich sowas dann.. obwohl Dekapitalisierung eher passen wuerde. Wenn das Opfer dann unter der Schuldenlast zusammenbricht, werden erst Leute rausgeschmissen und spaeter Konkurs angemeldet. Befallen, aussagen, wegschmeissen. Mit der gleichen Masche hat „unsere“ Heuschrecke z.b. letztes Jahr die Tank&Rast Autobahnrestaurantkette fast in den Abgrund „optimiert“.

Nun hat sich also am Montag eben diese Heuschrecke angekuendigt, die diversen Vertragspartner der EMI begutachten zu wollen, und damit auch uns. Wir haben ja von EMI einiges an Servern gestellt bekommen.. die laufen also bei uns, werden bei uns betreut, aber gehoeren nicht uns. Und damit wir einen moeglichst guten Eindruck hinterlassen, wurden eiligst Konferenzen einberufen und die halbe Firma umgekrempelt und aufgeraeumt etc.. sogar der seit Monaten inaktive Kartenleser an unserer Buerotuere wurde aktiviert, wie ich dann am Donnerstag Morgen schmerzhaft feststellen durfte. Unter Zeitdruck eben ein paar Statistiken optimiert und ein paar wichtig aussehende Diagramme gebaut und aufgehaengt, das haette der alte Potemkin nicht besser hinbekommen.  Sogar die Fensterscheiben an den Serverracks wurden nach Jahrzehnten mal wieder poliert – die waren immer noch ganz grau von dem Brand. Ich war fast auch ein bisschen beeindruckt wie wir uns doch verstellen koennen.

Nun waren die also Donnerstag Nachmittag da, das illustre Dreigespann, und haben sich auf der geplanten Route herumfuehren lassen.. mal hier ein kleines Schwaetzchen mit einem Angestellten, mal dort einen Blick auf die Statistikdrucke, und unser Chef hat irgendwie die Aura eines verstaubten Museumsfuehrers an sich gehabt.  Dementsprechend hatten wir heute genug zu tun, die Abteilungen wieder in einen benutzbaren Zustand zu versetzen.. Teilekisten wieder aus den Schraenken reissen, Unterlagen neu auf den Tischen ausbreiten, die Statistikbildschirme auf die realen Werte zuruecktrimmen etc.. und das alles nur, um vor ein paar gierigen Heuschrecken gut dazustehen.

Sonntag? nee, SunDay!

Heute war ein etwas ungewoehnlicher Tag.. ein Sonntag mitten in der Woche. Oder eher ein SunDay. Soll heissen, wir hatten heute eine kleine Delegation von Sun-Marketingschergen und unseren direkten Servicepartnern von Bacher Systems im Haus, um eine ganztaegige Informationsveranstaltung zu den neuen Serversystem und Technologien naechstes Jahr abzuhalten.

Eigentlich haette ich schon hellhoerig werden sollen als mein Chef gemeint hat „Geh du da vormittag schon hin, ich komm so gegen Eins nach.“ Ein Blick auf die Agenda verriet mir den Grund: „Green IT – Umweltschonende Rechenzentren“. Dementsprechend spannend wars dann auch… zwei Stunden Frontalunterricht ueber Energiesparkonzepte, und an den Haaren herbeigezogene Vergleiche zwischen den unterschiedlich effizienten Prozessorarchitekturen, bei denen – natuerlich – Sun UltraSparc T2 am besten dagestanden waren. Wie auch sonst.

Das Sushi-Buffet (oder was auch immer diese rohkostbelegten Brotscheiben darstellen haetten sollen) habe ich mir dann erspart und mich lieber in die Kantine abgesetzt, wo ich meinen Kollegen eine Kurzfassung des Vormittagsprogramms verabreicht habe, bis sie fast vor Muedigkeit in den Teller gefallen sind.

Der Nachmittag war dann wesentlich interessanter, wenn auch die Themen etwas wenig zu unseren Anforderungen gepasst haben. Eine Stunde Vortrag ueber Sun StorageTek Bandarchive, obwohl wir da seit Jahren fester IBM-Kunde sind und wohl so schnell auch nichts anderes ins Haus kommen wird. Eine weitere Stunde Vortrag ueber die neuen SunRay Thin Clients, die wohl fuer unsere Firma auch relativ uninteressant sind – abgesehen von vielleicht ein paar Bueroarbeitsplaetzen die man damit ersetzen koennte, aber jenseits aller Rentabilitaet. Ich habs ja damals bei SZ gesehen wie ungemein performant das SunRay-Netz ist wenn man dafuer kein dediziertes VLAN einrichtet – und wenn man die neu zu schaffende Netzinfrastruktur zu den Preisen der SunRays und der dazugehoerigen Server einrechnet, kommt man mit guenstigen Buero-PCs um einiges billiger weg. Bleibt eigentlich nur noch der eine Vortrag ueber die neuen CPU-Generationen, der mich halbwegs interessiert hat – aber hier hat sich alles um die Vorzuege der neuen T2-Prozessoren (Niagara, Victoria Falls) gedreht, die fuer unsere Lastanforderungen eher schlecht geeignet sind (wenige Threads, hohe Rechenleistung pro Thread, viel Crypto-Mathematik fuer SCP/SFTP – die Niagaras sind hauptsaechlich fuer viele leichtgewichtige Threads ausgelegt), und im Sparc64-Bereich gibts nichts neues was man haben wollen wuerde. Sun hat ja tatsaechlich die grauenhaft verstuemmelten Fujitsu-Siemens-Prozessoren uebernommen als Nachfolger zum UltraSparc IV+.. echt toll. Von 1450 MHz mit 36MB Cache (US4+) auf 1900 MHz mit 5MB Cache (US6) – wer will raten welcher davon mehr Datendurchsatz bringt?

Zum Schluss gabs noch ein paar T-Shirts und Taschenlampen abzustauben.. so ist wenigstens ein bisschen was von dem Tag bei mir haengen geblieben

SFU? WTF!

Nein, mit SFU meine ich nicht die beliebte Totengraeberserie, sondern das Microsoft-Toolset „Windows Services for UNIX“.

Eigenlich faengt alles ganz harmlos an… „Kannst du mal schaun ob du einen Weg findest, von nem Solaris-Server aus per Script ein Programm auf einer Windows-Muehle zu starten?“ – Klar, ganz einfach.. gibt doch rsh und rexec. Tja, knapp daneben, ist beides nach Win2k nicht mehr bei Windows enthalten. Gut, ich hab ja vor Jahren mal mit SFU 2.0 gearbeitet, da sind die Daemons dabei, nimmste halt das. Praktischerweise gibts die aktuelle und letzte Version 3.5 sogar kostenlos zum Runterladen. Ein kleiner Blick auf die Wikipedia-Seite zu dem Programm verraet mir, dass Microsoft da irgendwie _alles_ umgekrempelt hat dran. WTF?!

Die SFU 2.0 die ich hier zu Hause installiert habe, ist prinzipiell nur eine umgelabelte Version des Mortice-Kern-Systems MKS Toolkit, ein Paket aus Win32-Kompilaten der meisten Unix Tools, also ein auf Windows angepasstes GNU Toolset und die gaengigsten Netzwerkdaemons etc

Nicht so die aktuelle SFU 3.5, bei der mittels dem MS-eigenen Unix-Derivaten Interix eine komplette Ausfuehrungsschicht gebastelt wurde, die beim Windows-Start quasi im Hintergrund mitbootet. Nur leider ist Interix von Grund auf so richtig schoen microsoftig kaputt, dass man aus dem Schreien nicht mehr rauskommt. Der Umgang mit Unix-ueblichen Pfadangaben wie /usr/bin wurde offenbar nur zur Haelfte fertiggecodet, einige Tools aus dem Paket wollen lieber mit c:\sfu\common\usr\bin angesprochen werden, einige Daemons erwarten ihre Konfigurationsdateien in /etc (welches durch Interix nach c:\sfu\etc gemappt wird), andere suchen in %windir%\system32\drivers\etc, bei einigen Daemons wurde der Punkt vor den privaten Dateien weggemacht, bei anderen wurde er beibehalten – und Windows, bzw. der Explorer, weigert sich eh, Dateien mit fuehrendem Punkt zu erstellen. Also ohne Punkt erstellen, dann von der Befehlszeile aus umbenennen.. *grr*

Logdateien werden von den mitgelieferten Daemons so gut wie keine erstellt, weil syslogd hamse nicht mitportiert und selber schreiben koennen die wenigsten Dienste. Die paar Daemons die selbst welche erstellen, suelzen so kryptische Meldungen die zur Fehlersuche wertlos sind. „in.rshd: Login mstn: Failure“ – kein Warum oder wo. Dass es fehlschlaegt seh ich selber.. der Grund geht mich offenbar nichts an. Praktischerweise passt auch die Online-Dokumentation nicht zum Produkt – da werden Pfade genannt die nicht existieren, Bilder von Konfigurationsdialogen gezeigt mit Optionen die da schlicht nicht vorhanden sind, und Einstellungen teilweise an so vielen Orten gesucht dass selbst Debug-Versuche mit Regmon und Filemon zur Odyssee im Dateisystem werden.

Unterm Strich wurde aus dem „Ich installier mal eben SFU und richte den rexecd ein.“ eine mehrstuendige Bastlerei, die in einem hochfrustrierten Klick auf den Uninstall-Knopf geendet hat.  Die eigentliche Aufgabenstellung habe ich dann mit dem (kostenpflichtigen aber preiswerten) rexecd/nt von denicomp.com innerhalb 5 Minuten geloest. Mal wieder ein typischer Fall von Untauglichkeit von Microsoft-Produkten. Danke Redmond!

What shell’s..

Mal wieder nen interessanten Bastelauftrag bekommen: Ein Scriptpaket zum Herumschaufeln von Mediendaten zwischen zwei Bandarchiven und Live-Storage mit Oracle-Anbindung, komplett in ksh und seit 2001 organisch gewachsen (oder eher gewuchert) ueberarbeiten und um ein paar Funktionen ergaenzen – mit der Option, das in absehbarer Zeit eh komplett neu entwerfen zu duerfen weils asynchron werden soll. Da sitz ich jetzt schon fast zwei Tage dran und weiss immer noch nicht vollstaendig, was die insgesamt fuenfzehn sich gegenseitig aufrufenden Scripte genau machen. Mich wunderts immer wieder aufs neue, dass das ueberhaupt so funktioniert wie’s das momentan tut. Ich werd wohl am ehesten die neu gewuenschte Funktion in aehnlicher Manier irgendwo reinfrickeln, und mich dann auf den Neuentwurf naechstes Jahr konzentrieren.

Konzeptuell hab ich mir schon einiges zurechtgelegt.. wenn das ganze asynchron parallel laufen koennen soll, wirds wohl auf eine Art Dispatcher-Modell rauslaufen: ein grosses Verwaltungsscript in Form einer Finite State Machine, die in Schleife den Eingang von Anforderungen erfasst, die Eingangsdaten zerpflueckt und sich aus Oracle die Dateiinformationen holt, und dann den Bandabruf-/Kopiervorgang anstoesst. Dann wird wieder der Anforderungseingang geprueft, so lange bis eines der Unterscripte meldet dass die Daten vom Band da sind und weitergeschoben werden koennen an den naechsten Prozess.

Spannender Auftrag.. ich hoffe nur, dass meine Kollegen mir genug last-arme Zeit lassen um mich da durchzubeissen.  Was mich am meisten wurmt ist, dass ich das ganze vermutlich in ksh schreiben muss wie alle unsere „offiziellen“ Scripte.. und ich hasse diese Shell wie sonstnochwas. Wenn man zehn Jahre nur Bourne programmiert hat, stolpert man da ueber so viele kleine Unterschiede – und allzuviel testen kann ich ja nicht, die Kollegen wuerden mich steinigen wenn ich das halbe Bandarchiv mit meinen Experimenten in Beschlag nehmen wuerde.

Minimal ueberlastet

Quizfrage: Was passiert, wenn man irgendeinen antiken Buero-PC mit XP Home drauf mit Fibrechannel und vier bis sechs USB/Firewire-Platten vollsteckt und dann tage- bzw wochenlang Daten rumschaufeln laesst?

Richtig. Windoofs macht irgendwann die Graetsche und faengt an, herumzuspinnen.  Erst warens nur ein paar USB-Platten die nicht mehr als solche erkannt wurden, dann warens zerschriebene Dateisysteme, dann ein immer wieder crashender Explorer, und schliesslich hat das gute Stueck mal garkeine und mal 64 Fibrechannel-Platten gesehen wo eigentlich nur zwei sein sollten.

Mir haengt die Plattenschlepperei eh langsam zum Hals raus.. wird Zeit dass wir da ne andere Loesung finden. Und wenn ich selber das Fibrekabel quer durch die Firma verlegen muss. Meine Knie zahlt mir die Firma ja nicht wennse hin sind.

Datenschaufleritis

Meine Arbeit im Bereich Digital Content Services bringt es mit sich, dass wir immense Datenmengen bewegen muessen. Anlieferung der Rohdaten von den Ton-/Filmstudios, Aufbereitung fuers Mastering, Weiterverarbeitung zum Cutting der Pressvorlagen, Formatkonvertierungen fuer die Internet-Musikshops usw. usf. – derzeit summiert sich unser Datenvorrat auf rund 600TB online in diversen SAN-Schraenken, und rund 4PB standby als Bandkapazitaeten. Diese Daten wollen natuerlich irgendwie von einem Rechner zum anderen kommen – und genau da manifestiert sich das Problem, dessen Beseitigung ich mir heute in die Todo-Liste setzen lassen habe.

Bisher laeuft das meiste davon intern ueber gescriptete FTP-Transfers, mit entsprechendem Verwaltungs-Overhead. Die Konverter-Maschinen holen die Daten per FTP auf ihre lokale Platte, verarbeiten den Kram, und liefern ihn wieder per FTP beim naechsten Server ab. Bei 50 Konvertern muss so ein Server also mindestens 50 gleichzeitige Verbindungen abkoennen, plus die Datenlieferungen die parallel dazu von aussen ankommen. Diese ungewoehnlich hohen Anforderungen sind dementsprechend schwer zu planen. (Fuer alle die jetzt denken „langweilig, mein PC mit $FTPserver-Freeware packt das auch – ich rede hier nicht von DSL-Geschwindigkeiten sondern weit im GBit-Bereich).

Irgendwann damals beim SCNA-Kurs habe ich mal gelernt, dass man pro MBit zu saettigende Netzwerkleistung rund 3 MHz CPU-Geschwindigkeit braucht. Dies wuerde bedeuten, dass ich eine der GBit-Karten mit 3GHz CPU-Power ausgereizt bekomme. Nur: diese Faustregel skaliert leider offenbar nicht unbegrenzt. Zumindest bekomme ich mit vier einigermassen belasteten 1GBit-Leitungen eine voll ausgebaute SunFire V880 (8x 1,25 GHz) leicht zum Schreien.

Momentan sieht’s so aus wie wenn das Problem am Protokoll haengt. Leider scheint nur FTP immer noch das performanteste der bisher getesteten zu sein.. damit bekomme ich durch eine 1GBit-Leitung immerhin rund 45 MB/sek durch. Irgendwie ein bescheidener Wirkungsgrad, und ich kann mir nicht vorstellen dass wirklich 2/3 der Leitung an Overhead verloren gehen. Mit NFS bin ich knapp darunter auf 40 MB/sek gekommen, SMB hat weit unten bei 25MB/sek rumgeduempelt. Bei einem Einzeltransfer auf unbelastetem Rechner, wohlgemerkt. Bei zwei parallelen Transfers hats schon anders ausgesehen.. FTP ist auf 40MB/sek Gesamtdurchsatz runter, NFS auf 50MB/sek rauf, SMB weit abgeschlagen bei nur noch 4MB/sek – jeweils getestet mit 1GB grossen Random-Dateien. Bei dem extremen Leistungseinbruch bei SMB bin ich noch nicht ganz sicher ob das an Samba liegt, oder ob der verwendete Windows-Client so beschissenes Paketscheduling betreibt. Ich wills aber glaubich garnicht wissen. Bei drei parallelen Transfers haben sich NFS und FTP wieder bei 45MB/sek getroffen.. SMB erwaehne ich aus Scham nicht mehr.

Bleibt im Endergebnis die Frage, woran kann ich noch rumtunen um mehr Daten durchzukriegen. Die CPUs langweilen sich, da liegt der Engpass also nicht. Bei 50MB/sek, also 400 MBit, duerfte die Netzwerkkarte auch noch Kapazitaeten frei haben. Beim Switch (Cisco Catalysts) gehe ich mal davon aus, dass er den Durchsatz schafft. Mit Paketgroessen werde ich am Montag mal bissl experimentieren.. im Gigabit-Ethernet sind ja Frames bis 8k moeglich.. mal schaun ob das was bringt. Dann ein bisschen am Kernel rumschrauben, Paket-ACK-Fenster vergroessern etc.. nur darf die Leistung halt nicht auf Kosten der Zuverlaessigkeit gehen. Wie schlimm ist eigentlich der Overhead bei HTTP?
Wenn jemand spontan eine Idee hat, bewerft mich damit

„Portable Software“

Meine Laune gegenueber diversen Open-Source-Programmierern verschlechtert sich irgendwie taeglich in letzter Zeit. Wer auf seiner toll herausgeputzten SF-Webseite was von „written to be as portable as possible“ faselt, sollte nicht auf der anderen Seite die Ansicht vertreten „es compiliert auf Linux und Cygwin, das ist doch Portabilitaet pur“. Leider greift diese Einstellung in letzter Zeit immer mehr um sich – muss wohl am steigenden Marktanteil von Linux liegen.

Meines Erachtens nach bedeutet Portabilitaet mehr als dass das Programm auf verschiedenen Linux-Distros baubar ist.. erst recht wenn man sein Projekt in der Unix/Posix-Kategorie eintraegt. Daher hier mal ein paar der mir am haeufigsten begegnenden Problempunkte (berufsbedingt natuerlich aus Solaris-Sicht):

• Die Linux-/bin/sh ist keine Bourne-sh sondern eine bash. Wenn ihr schon irgendwelche Zusatzroutinen in die (eigentlich hochportablen) configure-Scripte oder autoconf-Vorlagen etc einbaut, oder selbstgebaute Build-Scripts verwendet, dann probiert das ganze doch mal mit ner echten Bourne-sh aus. Unter anderem so wichtige Konstrukte wie `test` haben in der bash unkompatibel verbogene Parameter (dazu-)bekommen, die auf Nicht-Linuxen Fehler produzieren und teilweise kacke zu debuggen sind.
• Ihr seid nicht der alleinseligmachende Softwareanbieter. Es ist ja ein toller Service, wenn ihr ein paar Bibliotheken von denen euer Programm abhaengt im Sourcenpaket mitliefert – aber verlangt bitte nicht, dass man unbedingt eure Version benutzt. Buildscripts die z.B. sowas verbreitetes wie die zlib ausschliesslich in ihrem Sourcetree erwarten, sind broken by design. Es gibt genug portable Methoden, die Existenz von Bibliotheken zu pruefen – sei es durch Compilieren eines Dreizeilers der diese einbindet, oder durch Durchsuchen der durch LD_LIBRARY_PATH referenzierten Verzeichnisse. Alternativ kann man auch mal nach gelaeufigen lib-Pfaden googeln.. gibt genug Programmierguides die diese auflisten. Tip fuer Solaris: /opt/csw/lib, /opt/sfw/lib, /usr/sfw/lib sind immer einen Blick wert – hier installieren die sehr beliebten Paketanbieter sunfreeware.com und blastwave.org sowie die Solaris Companion-CDs massenweise OSS-Bibliotheken.
• Wenn ihr fremde Bibliotheken mitliefert (siehe Punkt 2), prueft bitte doppelt genau ob diese auf dem Zielsystem schon vorhanden sind. Nichts ist nerviger als wenn Programme ploetzlich nicht mehr laufen, nur weil ein wohlmeinender Entwickler beim letzten make install ohne Rueckfrage Bibliotheken durch aeltere Versionen ersetzt hat. Diese Unsitte ueberlasst ihr bitte den Windows-Programmierern, die sind sowas gewoehnt
• Versucht bitte, die Optionen die euer Konsolenprogramm akzeptiert, einigermassen an gaengige Standards anzupassen. Dies heisst, -x fuer Kurzoptionen, –bla-fasel fuer Langoptionen. Mit Konstrukten der Art –CamelCaseOption=Wert steigert ihr nur die Chance, dass der Anwender sich verschreibt. getopt ist hierbei eine recht hilfreiche Bibliothek – man muss das Rad nicht case-sensitiv neu erfinden.
• Bedenkt, dass OpenSource bedeutet, dass andere Leute euren Code lesen koennen, bzw. unter Umstaenden zwecks Korrekturen lesen muessen. Macht es ihnen nicht unnoetig schwer, und pflegt einen einigermassen lesbaren Programmierstil. Einrueckungen helfen viel. Kommentare auch. Sprechende Funktionsnamen noch viel mehr.
• (bezugnehmend auf den letzten Punkt) Bitte haltet Texte und Funktionsnamen schmerzfrei lesbar. Englisch ist so eine tolle Sprache.. wieso mir dann augenkrebserzeugende Sachen wie „This Function Will Read An Input From The Command Line“ in einer Read_Input_Value_From_User_Function begegnen muessen, ist mir unverstaendlich. Entweder CamelCase _oder_ Unterstriche machen das ganze viel lesbarer – und im Englischen darf eh fast alles klein geschrieben werden. Binary-Namen sollten unbedingt komplett klein geschrieben und moeglichst kurz sein. Ein /usr/bin/megatollesallzweckprogramm nervt spaetestens beim naechsten ls.
• Baut eure Source-Tarballs bitte inklusive dem euren Kram beinhaltenden Verzeichnis. Es nervt ziemlich, wenn ein tar xivf mir eure Sourcefiles quer ueber mein /home verteilt.
• Kreuzt bei Sourceforge bitte nur die OS-Kategorien an, mit denen ihr eure Programm getestet habt (ggf. unter Zuhilfenahme der SF Compile Farm). „Wird schon laufen“ ist keine Grundlage.
• Bedenkt, dass Linux teilweise Funktionen in anderen Bibliotheken untergebracht hat als andere Unices, und dass einige Funktionen garnicht vorhanden sind. Am haeufigsten begegnete Probleme: Linux hat fabsf, fpowf und andere float-to-float-Rechenfunktionen, Solaris bis 8 und HP-UX bis heute haben diese nicht. Hier kann man problemlos die Versionen ohne -f verwenden, diese liefern halt einen double  zurueck, was kein Verlust ist. Linux hat diverse Netzwerkfunktionen wie inet_aton/ntoa, gethostbyname etc in der libc, bei den meisten „echten“ Unices sind diese in Bibliotheken ausgelagert, die dem gcc mit -lnsl -lresolv bekanntgemacht werden muessen. Aehnliches gilt fuer „seltenere“ Rechenfunktionen und die mathlib -lm

Wer auch nur ein paar dieser Vorschlaege beherzigt und seinen Code mal auf derartige Schwachstellen durchsucht, wird bald einen grossen Schritt von „Laeuft auf allen Linuxen“ hin zu „Laeuft auf fast allem Unix-artigen“ machen koennen. Auch wenn ihr’s nicht fuer moeglich haltet, es finden die ungewoehnlichsten Programme manchmal den Weg auf meine Server. Unterschaetzt den Umfang eurer Zielgruppe nicht!

Antiquitaetensammlung

An einem der ersten Tage bei Sony hatte ich beim Umgraben in unserem Hardwarefriedhof eine alte Sun Ultra 5 entdeckt. Heute habe ich mir endlich mal eine Stunde Zeit genommen und das gute Stueck vom Dachboden geholt. Nach einem mittleren Asthmaanfall aufgrund des massiven Staubbefalls habe ich nach Oeffnen des Deckels begeistert festgestellt, dass der Rechner offenbar vollstaendig ist. Ab aufn Schreibtisch damit, angekabelt.. laeuft an. Und dann der Schock… 32 MB RAM. Solaris 8 hat zwar trotzdem angenehm schnell gebootet, aber als Arbeitsrechner ist die Workstation so natuerlich nicht zu gebrauchen. Gleich mal einen Hilferuf in Richtung IT-Abteilung abgesetzt.. vielleicht haben die noch ein paar passende Speicherriegel herumliegen. Aber die Sorte wurde nur in U5 und U10 verbaut.. ich rechne mir keine grossen Chancen aus.

Irgendwie wurmt es mich jetzt, dass Sun bis vor wenigen Jahren nur eigenkonstruierte Speicherriegel verbaut hat. 50ns EDO-Chips mit ECC auf DIMM-Riegeln.. *seufz*