043
06.01.2006, 11:13 Uhr
Pablo
Supertux (Operator)
|
Zitat von ao: |
Einige wissen es einfach nicht besser. Sie merken, dass ihre Setups irgendwie vermurkst sind, aber haben keine Idee, wieso. Irgendwann schmeißen sie alles weg und machen es neu, und damit ist das neue Setup technisch kein Nachfolger des alten mehr (dazu müsste man ein paar GUID-Nummern übernehmen), und die Sache wird noch viel schlimmer.
Andere haben zu wenig Zeit. Setups bauen muss man lernen, genau wie programmieren. Und auch dann macht ein Setup noch Arbeit und dauert seine Zeit. Mancher allzu kostenbewusste Entwicklungsleiter genehmigt diese Zeiten nicht: "Setup? Das geht doch auch schneller, oder? Gibts dafür keinen Wizard, dreimal klicken und fertig?" Klar gibts den, aber man darf ihm nicht blind vertrauen.
Damit sind wir beim Test. Wenn man es richtig machen will, müsste man testen: * auf allen Windows-Versionen, auf denen das Programm laufen soll (von 95 bis 2003 sind das inzwischen 7 Stück) * mit und ohne Service-Packs * in gängigen Sprachen (mindestens Deutsch und Englisch - wie oft erlebt man Überraschungen, wenn aufm Zielsystem plötzlich andere Ländereinstellungen - Datum- und Zeitformat oder Dezimaltrenner - gewählt sind als aufm Entwicklungssystem) * Erst-Installation und Update des Vorgängers * Wenn man noch andere Programme entwickelt, die mit dem zu testenden Programm Berührungspunkte haben (z.B. gemeinsam genutzte DLLs), dann muss man mit und ohne diese Programme testen.
Wenn man das alles auskreuzen will, kann man ein voll ausgebautes und automatisiertes Testlabor eine Woche lang beschäftigen. Kleinere oder mittlere Firmen haben sowas aber nicht, die testen von Hand. Also werden ein paar repräsentative Fälle ausgewählt, und dann wird gehofft, dass die anderen nicht wesentlich davon abweichen.
Und in den ganz kleinen Shareware-Buden, die außer dem Inhaber vielleicht noch einen Hiwi beschäftigen, macht nur der Entwickler selber ein paar vorsichtige Versuche.
Klar, das ist nicht überall so. Manche Firmen - große wie kleine - habens geschnallt und richten sich danach. Das sind dann die, deren Setups unauffällig sind.
|
Das ist es genau, was ich meinte. Windows an sich ist nicht das Problem, sondern das Konzept.
Zitat: |
Es rafft ja auch eine an sich gesunde Windows-Installation nicht gleich dahin, wenn mal ein krankes Setup seinen Dreck hinterlässt. Probleme kriegen die Leute, die jedes Tool, was sie finden, runterladen und installieren. Die kaputten Setups sammeln sich an, und irgendwann fängt das System an zu stottern und setzt aus.
|
was? Und wenn ich für meine Arbeit solche Software brauche? Da kann ich nichts machen.
Zitat: |
Nein, das denke ich nicht. Windows hat ein funktionierendes Konzept, und Microsoft muss nicht den Leuten hinterherprogrammieren, die - warum auch immer - die Regeln verletzen. Damit würden ja die gestraft, die sich an die Regeln gehalten haben.
|
Gut, dann sagen wir mal so, Microsoft muss dafür sorgen, dass es aufhört. Warum? Oben hast du Gründe genannt. Das Konzept ist aufwändig, kostet Zeit und Geld, man muss Testen und viele wollen es so schnell wie möglich hinter sich haben.
Ich wollte diesen Vergleich nicht machen, aber ich denke, dass GNU zum Beispiel, das prima hingekriegt hat. Klar, die GNU Autotools sind auch nicht die beste Variante, die können auch sehr aufwändig sein und nicht immer tun sie das, was sie tun müssten. Kein System ist perfekt eben. Aber mit autoconf, automake, libtoolize hat GNU eben geschafft, dass man mit wenig Zeilen Code ein Setup-System für die eigene Software entwickelt, wo man weiß, dass es überall läuft, wo POSIX stadarisiert ist. Bsp:
configure.ac: |
# -*- Autoconf -*- # Process this file with autoconf to produce a configure script.
AC_PREREQ(2.59) AC_INIT(src/main.c) AM_INIT_AUTOMAKE(aof-db,1.0.3) AC_CONFIG_SRCDIR([src/main.c]) AC_CONFIG_HEADER([config.h])
# Checks for programs. AC_PROG_INSTALL AC_PROG_LN_S AC_PROG_MAKE_SET
# Checks for header files. # Checks for typedefs, structures, and compiler characteristics. AC_HEADER_STDC AC_C_CONST AC_TYPE_SIZE_T
# Checks for library functions.
AC_CHECK_LIB(readline, readline) if test "$ac_cv_lib_readline_readline" != "yes"; then AC_MSG_ERROR([Library readline not found. Install it from http://directory.fsf.org/readline.html]) fi
AC_CHECK_LIB(sqlite3, sqlite3_open) if test "$ac_cv_lib_sqlite3_sqlite3_open" != "yes"; then AC_MSG_ERROR([Library SQLite3 not found. Install it from www.sqlite.org/]) fi
AC_CHECK_LIB(sstrings, addchar) if test "$ac_cv_lib_sstrings_addchar" != "yes"; then AC_MSG_ERROR([Library SStrings not found. Install it from http://pcpool.mathematik.uni-freiburg.de/~pabloy/projects/sstrings/]) fi
AC_OUTPUT(Makefile src/Makefile doc/Makefile)
|
Makefile.am, src/Makefile.am, doc/Makefile.am: |
#Makefile.am EXTRA_DIST=autogen.sh aof-db.conf SUBDIRS=src doc
confdir = /etc conf_DATA = aof-db.conf
#src/Makefile.am SOURCE_C=main.c arg_parse.c conf_parse.c utils.c install.c addcat.c showcat.c addimage.c showimage.c rmcat.c rmimage.c SOURCE_H=../config.h arg_parse.h conf_parse.h utils.h install.h addcat.h showcat.h addimage.h showimage.h rmcat.h rmimage.h SOURCECODE=$(SOURCE_C) $(SOURCE_H) bin_PROGRAMS=aof-db aof_db_SOURCES=$(SOURCECODE)
#doc/Makefile.am man_MANS = aof-db.1 EXTRA_DIST = $(man_MANS)
|
Mit dem Aufruf "aclocal && autoconf && autoheader && automake" habe ich mein Setup System gemacht, welches guckt, ob readline, sstrings und sqlite vorhanden sind und falls ja, die Sources kompiliert und installiert. Beim Deinstallieren räumt er alles auf, was er beim Installieren erstellt hat.
Ich hab mal dafür höchstens 20 Minuten gebraucht, und damit installiere ich mein Tool auf jedes System, das POSIX Standard ist.
Sieht du was ich meine? In den 80 Jahren standen unter Unix die Entwickler vor dem gleichen Problem, wie man am besten Software verbreitet. Und GNU hat diese Autotools dafür entwickelt, und die funktionieren prima. Natürlich sind die nicht perfekt und es gibt auch Fehler, aber welches System ist denn schon perfekt? Und ich denke, dass Microsoft anstatt dafür zu sorgen, dass Vista "geil" aussieht und die Fenster in 3D angezeigt werden, sollten sie lieber ein neues Setup Konzept entwickelt, der einfacher für die Entwickler ist es zu benutzen. Vielleicht ein eigenes Setup Tool, so dass die Entwickler nicht immer zu viel Zeit darin investieren müssen.
Zitat: |
Wenn auf einmal alle Leute anfingen, bei Rot über die Straße zu gehen, meinst du, irgendwer würde die Verkehrsregeln ändern?
|
nein, weil beim Rot an der Ampel halten ist keineswegs ein neues Konzept und ist allgemein bekannt. Aber als die ersten Ampel eingeführt sind, mit nur eine Farbe, gabe es auch solche Probleme. Und was haben die Städte gemacht? Die jetzige Ampel weiterentwickelt. -- A! Elbereth Gilthoniel! silivren penna míriel o menel aglar elenath, Gilthoniel, A! Elbereth! Dieser Post wurde am 06.01.2006 um 11:21 Uhr von Pablo editiert. |