stable/updates - debian

Re(13): stable/updates - debian

japh — Wed, 25 Apr 2012 13:03:00 GMT

Mir prinzipiell aber unklar wo da soviel Fehler entstehen können ehrlich gesagt. XML ist doch recht verständlich aufgebaut.

die haeufigsten probleme: encoding, entities, falsche interpretation davon was wie in CDATA stehen darf. well-formed schaffen die meisten, mehr aber nicht mehr.

man muss sich halt vor augen halten dass wir hier das ergebnis von zig (wenn nicht hunderten) verschiedenen shopsystemen verarbeiten, die qualitativ und groessenordnungsmaessig von hersteller "enterprise" bis "minderjaehriger cousin eines bekannten" reichen. dementsprechend fluktuiert der output.

[..] SOAP-ähnlichen Messageprotokoll.

ja, dafuer ist XML auch recht gut geeignet.

CSV eh am liebsten

zum uebertragen einfacher preislisten ist es auch bestens geeignet. wenig overhead, gut und einfach parsbar ohne besonders viel resourcen zu brauchen, auch fuer grosse dateien, ausreichend fehlertolerant, parser sind einfach parametrisierbar, usw.

Re(12): stable/updates - debian

A national Acrobat — Wed, 25 Apr 2012 12:40:20 GMT

beruehmte letzte worte.

XML geht wenn alle beteiligten wissen was sie tun und dabei keine fehler
machen. schoenes konzept, aber ausgesprochen praxisfern.

hehe .

Mir prinzipiell aber unklar wo da soviel Fehler entstehen können ehrlich gesagt. XML ist doch recht verständlich aufgebaut.

man kann fuer vieles fehlertolerante parser schreiben. bei XML ist halt laut
spec fehlertoleranz ausgeschlossen, das macht es fuer sachen, bei denen es
nicht noetig ist dass immer alles fehlerfrei funktioniert nicht wirklich
brauchbar. in der praxis kann man bei den meisten XML parsern gewisse
toleranzen einschalten, dann stellt sich halt wieder die frage "warum dann
ueberhaupt XML"?

Warum XML ist prinzipiell eine gute Frage. Warum nicht Datenbankdumps durch die Gegend schicken, die würden ja prinzipiell immer stimmen, warum kein Excelfile parsen ? Das was ich jetzt aus der Praxis kenne - und da nutze ich XML sicher nicht so intensiv, bzw. sind die XML alle aus einer Quelle bzw. von einem Programm generiert, ist es einfach am praktischsten. Unsere Infrastruktur arbeitet sehr viel mit einem SOAP-ähnlichen Messageprotokoll. Da ist XML einfach unglaublich praktisch, egal was als Response daherkommt, ich kanns gut verpacken und weiterverarbeiten und auch nocht so, das wenn Fehler auftreten man den Fehler auch als Mensch sehen und untersuchen kann.

je nach phantasie bei markup kann die datei schon mal doppelt so gross werden.
DOM parser lesen die dateien vollstaendig ein und baun den parse tree draus,
RAM ohne ende (gegenueber kaum RAM bei z.b. CSV). das kann man mit SAX parsern
umgehen, die sind aber wieder umstaendlich zu handhaben

DOM nutze ich weder priv. noch beruflich, ist zwar sehr praktisch, aber nach etwas Übung mit einem SAX Parser bekommt man das auch gut hin.

Wie ich weiter oben schon schrieb: Von Sysadminseite aus ist mir CSV eh am liebsten, es ist einfach am praktischen auf unixoiden diese weiter zu verarbeiten.

lg.

Re(11): stable/updates - debian

japh — Wed, 25 Apr 2012 12:17:48 GMT

Weil "normal" - wenn das alles maschinell passiert - dürfts garkeine Fehler geben.

beruehmte letzte worte.

XML geht wenn alle beteiligten wissen was sie tun und dabei keine fehler machen. schoenes konzept, aber ausgesprochen praxisfern.

Aber das hättest ja ebenso bei anderen Formaten. Wenn (ich geh jetztmal von dem worst-case .ini Beispiel aus) dort eine Section falsch formattiert ist, stimmen ebensowenig die unteren Einträge und einen Parser wirds ebenso aufklatschen.

man kann fuer vieles fehlertolerante parser schreiben. bei XML ist halt laut spec fehlertoleranz ausgeschlossen, das macht es fuer sachen, bei denen es nicht noetig ist dass immer alles fehlerfrei funktioniert nicht wirklich brauchbar. in der praxis kann man bei den meisten XML parsern gewisse toleranzen einschalten, dann stellt sich halt wieder die frage "warum dann ueberhaupt XML"?

Gut Overhead.. naja ist sicherlich ebenso zu berücksichtigen, da hab ich aber ned wirklich viele Beispiele oder Daten im Kopf wie sehr der Overhead zum "Kropf" hier wird.

je nach phantasie bei markup kann die datei schon mal doppelt so gross werden. DOM parser lesen die dateien vollstaendig ein und baun den parse tree draus, RAM ohne ende (gegenueber kaum RAM bei z.b. CSV). das kann man mit SAX parsern umgehen, die sind aber wieder umstaendlich zu handhaben.

Re(10): stable/updates - debian

A national Acrobat — Wed, 25 Apr 2012 11:53:30 GMT

XML ist fuer sowas grundsaetzlich einfaches wie preislisten kein sinnvolles
format.

Dazu kenn ich zuwenig die Specs die ihr da übermittelts (oder übermittelt bekommts).

streng nach spec gibt's keine fehlertoleranz, z.b. kaputtes encoding. ein
falsches zeichen und es duerfte nach spec komplett nicht geparst werden. das
ist praktisch total egal, eine zeichenkraxn in ein paar 1.000 (oder hier auch
in ein paar millionen) eintraegen ist belanglos, und jedenfalls weit weniger
schlimm als veraltete information weil die aktuelle liste nicht geparst werden
kann.

Da frag ich mich aber wie die Listen generiert werden. Weil "normal" - wenn das alles maschinell passiert - dürfts garkeine Fehler geben. Aus vielen DBs kann man AFAIK schon direkt in XML die Ausgabe erstellen etc. Wie gesagt für euren Fall weiß ich nicht wirklich was ihr da übermittelts bzw. wie das auszusehen hat.

Aber das hättest ja ebenso bei anderen Formaten. Wenn (ich geh jetztmal von dem worst-case .ini Beispiel aus) dort eine Section falsch formattiert ist, stimmen ebensowenig die unteren Einträge und einen Parser wirds ebenso aufklatschen.

dazu kommt unnoetiger overhead durch das markup (MOAR BYTES!) und das
aufwaendigere parsen (RAM, CPU, fehleranfaelligere software).

Gut Overhead.. naja ist sicherlich ebenso zu berücksichtigen, da hab ich aber ned wirklich viele Beispiele oder Daten im Kopf wie sehr der Overhead zum "Kropf" hier wird.

Re(9): stable/updates - debian

japh — Wed, 25 Apr 2012 11:02:26 GMT

XML wirklich ein Format das so ziemlich alle Daten speichern kann.

if all you have is a hammer ...

XML ist fuer sowas grundsaetzlich einfaches wie preislisten kein sinnvolles format.

streng nach spec gibt's keine fehlertoleranz, z.b. kaputtes encoding. ein falsches zeichen und es duerfte nach spec komplett nicht geparst werden. das ist praktisch total egal, eine zeichenkraxn in ein paar 1.000 (oder hier auch in ein paar millionen) eintraegen ist belanglos, und jedenfalls weit weniger schlimm als veraltete information weil die aktuelle liste nicht geparst werden kann.

dazu kommt unnoetiger overhead durch das markup (MOAR BYTES!) und das aufwaendigere parsen (RAM, CPU, fehleranfaelligere software).

Re(10): stable/updates - debian

User64693 — Tue, 24 Apr 2012 19:34:24 GMT

echt super support hier im forum

danke nochmals...

Re(9): stable/updates - debian

colossus — Tue, 24 Apr 2012 19:14:54 GMT

Achtung, tw. unverifiziertes Halbwissen folgt:

"security" hat afaik eine eigene Mirror-Policy (kuerzere Zyklen) und deshalb einen eigenen Hostnamen bzw. DNS-RR. Das muessen deshalb (auf IP-Ebene) nicht zwingend andere Server sein als jene, auf denen auch die "main"-Repos und Konsorten liegen - via HTTP (dank VHost-Support) ist das ja ohne Probleme moeglich. Nur im Falle des Bezugs der Archivdaten ueber FTP (soll ja immer noch Leute geben, die diesen verkrusteten Schund verwenden...) kann es zum vorhin beschriebenen Problem kommen, da du ueber dieses Protokoll immer im selben "Namespace" landest.

Re(8): stable/updates - debian

User64693 — Tue, 24 Apr 2012 19:04:50 GMT

ok - ich glaub jetzt hab ichs verstanden...

dank dir für die Erklärung!

derzeit wird stable/updates aber nur auf dem http://security.debian.org Server gehostet - oder?

Re(10): stable/updates - debian

A national Acrobat — Tue, 24 Apr 2012 18:57:04 GMT

Stimmt schon, aber bei XML kannst halt durch Parser schon paar Fehler abfangen, aber ich glaub GH bräuchte mehr als 2 Parser wenn die Dateien in .ini Style kommen würden .

Re(7): stable/updates - debian

colossus — Tue, 24 Apr 2012 18:52:13 GMT

Ich hab eigentlich versucht, genau diese Frage mit meinem vorletzten Posting in diesem Subthread zu beantworten Die einzig rationale Begruendung ist die, dass man somit auf dem selben FTP-Server _sowohl_ das Debian stable "main" repository, _als auch_ das Debian stable security repository hosten kann. Wuerde man das top-level-dir fuer letzteres nicht in stable/updates verlegen, wuerde es da zu Ueberschneidungen der Verzeichnisnamen und damit auch -inhalte zwischen den Repositories kommen.

Re(9): stable/updates - debian

colossus — Tue, 24 Apr 2012 18:47:06 GMT

Beides kann man allerdings ueber jedes beliebige Dateiformat sagen, gell?

Re(8): stable/updates - debian

A national Acrobat — Tue, 24 Apr 2012 18:43:22 GMT

Ein generischer (wenn auch validierender) Parser ist da imho so gut wie
wertlos. Mag ja sein, dass ich damit meine Config bequem auf syntaktische
Korrektheit und passende Typen pruefen kann - aber das macht das Syntax
Highlightning meines Editors eigentlich genau so gut.

Es geht in meinem Anwendungsfall auch um mitgelieferte Konfigurationsdateien, und bei Hot-Deployment hat man da schon üble Überraschungen erlebt. Deshalb wird das Zeugs jetzt zumindestens soweit gecheckt als das man sagt "ok, XML Syntax passt, auch wenn Müll drinsteht".

Klar ist sowas wie apachectl optimal, aber Apache ist ja auch für den HA Einsatz ausgelegt da darf einfach kein grober Fehler sein. Ich seh da immer den bei uns oft eingesetzten JBoss, das ist für uns Admins nicht zu kontrollieren was da reinkommt oder was draußen bleiben muß - wir gehen stur nach dem mitgelieferten Dokument und da sind generische Parser schon eine Hilfe - sowas wie apachectl natürlich explizit gut, da er ja auch sowas wie doppelt vergebene vhost-Namen checkt.

Also ich bin mit XML immer ganz gut gefahren (auch wenn ich jetzt bei meinem privaten Projekt ein XML-Problem hab ), es ist halt sehr generisch, da liegt sein großer Vorteil aber auch sein großer Nachteil drin.

Von Admin-Seite aus sind mir persönlich CSV ähnliche Configfiles wie passwd z.b. am liebsten, das kannst mit einem einfachen awk schnell parsen und mußt ned viel nachdenken .

lg.

Re(8): stable/updates - debian

A national Acrobat — Tue, 24 Apr 2012 18:34:12 GMT

Das glaub ich Dir schon das es übelst formatierte XML Dateien gibt, liegt aber nicht unbedingt am XML Format itself, sondern an denen die die Datei erstellen .

Wenn man halbwegs sauber arbeitet ist XML wirklich ein Format das so ziemlich alle Daten speichern kann.

Re(6): stable/updates - debian

User64693 — Tue, 24 Apr 2012 18:23:14 GMT

dass stable derzeit das gleiche ist wie squeeze ist mir klar...

was ich nicht ganz verstehe ist warum einerseits stable/updates verwendet wird:

"deb _http://security.debian.org/ stable/updates main contrib non-free"

und andererseits nur stable:

"deb _http://ftp.de.debian.org/debian/ stable" main contrib non-free"

Re(6): stable/updates - debian

User64693 — Tue, 24 Apr 2012 18:23:14 GMT

Re(5): stable/updates - debian

colossus — Tue, 24 Apr 2012 17:57:52 GMT

Ich fuerchte, ich verstehe die Frage nicht...

"stable" ist nur ein Alias fuer die aktuell "stabile" Suite - momentan eben squeeze. Es klingt nicht so, als ob man dir erklaeren muesste, dass man einfach "stable" eintragen kann, und dann halt den "Vorteil" genieszt, beim dist-upgrade automatisch wheezy-Pakete installiert zu bekommen. Wenn man das nicht will, bleibt man eben beim Codename der Suite.

Inwiefern ergibt sich daraus in deinen Augen ein Widerspruch zur bzw. ein Problem mit der de-facto-Benamsung der security-Verzeichnisstrukturen?

Re(7): stable/updates - debian

mjy@geizhals.at — Tue, 24 Apr 2012 17:57:48 GMT

Was ist an XML nicht wirklich lesbar ?

Also wir verwenden hier 2 verschiedene XML-Parser nur um die Chancen zu erhöhen, dass wir mit den kaputten XML-Formaten, die in der Branche verwendet werden (Preislisten), klar zu kommen.

Re(7): stable/updates - debian

colossus — Tue, 24 Apr 2012 17:53:21 GMT

Ein generischer (wenn auch validierender) Parser ist da imho so gut wie wertlos. Mag ja sein, dass ich damit meine Config bequem auf syntaktische Korrektheit und passende Typen pruefen kann - aber das macht das Syntax Highlightning meines Editors eigentlich genau so gut.

In Wahrheit ist es doch so, dass die Konfiguration eines komplexen Dienstes viel subtiler falsch sein kann, als mir eine DTD (oder halt ein Relax-NG Schema oder was immer es heute gibt - XML ist schon eine Weile nicht mehr so hip, dass ich da auf Stand zu sein behaupte ) das zu pruefen oder zu formulieren ermoeglicht. Insofern sind fall- und anwendungsspezifische Tools wie z. B. `apachectl -S`, die die Konfiguration des Dienstes, mit dem sie mitgeliefert werden, in gewissem Masze auch "verstehen", bewerten und deren Auswirkungen verstaendlich darstellen bzw. aufbereiten koennen, einem einfachen lint-Programm (auch wenn ein XML-Parser klarerweise technisch nicht gar so einfach ist ) die viel sinnvollere Loesung.

Klar KOENNTE man das auch mit irgendeiner XML-Serialisierung der Konfigurationsdaten machen, und man wuerde sich ein bisschen Aufwand sparen, den Lexer/Parser/Validator/Interpreter fuer das "eigene" Dateiformat zu implementieren, aber einen wirklich substantiellen Vorteil hat das alles aus meiner Sicht nicht. Ich bin jedenfalls jedes Mal heilfroh, wenn mir beim Oeffnen einer Konfigurationsdatei in vim kein XML entgegenkrabbelt - pfui!

Re(6): stable/updates - debian

A national Acrobat — Tue, 24 Apr 2012 16:10:42 GMT

Es ist zwar nicht optimal, dass fast jedes kleine Programm und Utility seine
eigene Aufruf- und Konfigurationssyntax und -grammatik mitbringt, aber das ist
mir immer noch WESENTLICH lieber als irgendein win32 Registry Hive.

Nicht nur Registry - die ich persönlich für einen absoluten Designfehler halte - es gibt ja auch auf properitären Unixen nicht lesbare Datenbanken, wo man dann den Hersteller bitten darf einem den Key zu sagen, weil sonst diverse virtualisierte Gschichtln ned gehn.

Was ich persönlich an Windows garned mag ist das es teilweise sehr sehr unsauber mit Pfaden umgeht (im gröberen Sinne). Dieses jedes Programm bringt seine eigenen Libs mit, die wiederrum in "irgendwelchen" Verzeichnissen rumkugeln ärgert mich gewaltig. Grad bei einem properitären System kann ich die Drittanbieter zwingen in die Verzeichnisse zu installieren die ich will.

Plaintextkonfiguration ist Koenig, koennte man sagen.

Es ist lustigerweise das was sich bis jetzt am längsten hält (obwohls wie mjy schon sagte eine Sauwirtschaft ist ).

Re(6): stable/updates - debian

A national Acrobat — Tue, 24 Apr 2012 16:06:46 GMT

Grad deshalb XML . xmlint z.B. ist ein hervorragendes Teil zum Checken von Configs (nutze ich bei unseren JBOSS-App-Servern).

Was ist an XML nicht wirklich lesbar ?

Re(4): stable/updates - debian

User64693 — Tue, 24 Apr 2012 16:05:15 GMT

ja, aber warum heißt das nur im security-archiv stable/updates und nicht auch hier deb http://ftp.de.debian.org/debian/ stable main contrib non-free ?

Re(3): stable/updates - debian

colossus — Tue, 24 Apr 2012 15:39:09 GMT

Das ist einfach nur der Pfadname im Security-Archiv. Der liegt offenbar darin begruendet, dass es, wuerde das Repo einfach nur "squeeze" heiszen, es Probleme bei der Verzeichnisstruktur geben wuerde, wenn ein FTP-Mirror (FTP kann kein Name-based Virtual Hosting) sowohl das Squeeze-Repo als auch das Squeeze-Security-Repo vorhalten soll.

Re(5): stable/updates - debian

colossus — Tue, 24 Apr 2012 15:27:22 GMT

Gab es doch schon alles - Stichwort "Elektra"; das Projekt war iirc sogar von Oesterreichern initiiert. Hat sich aber nicht durchgesetzt, u. a. wohl deshalb, weil die Idee stark behaemmert ist.

Es ist zwar nicht optimal, dass fast jedes kleine Programm und Utility seine eigene Aufruf- und Konfigurationssyntax und -grammatik mitbringt, aber das ist mir immer noch WESENTLICH lieber als irgendein win32 Registry Hive. Plaintextkonfiguration ist Koenig, koennte man sagen. Sprechende Bezeichner gibt es ja auch hier. Und nichts hindert dich daran, fuer ein solches Backend ein brauchbares GUI- oder TUI-Konfigurationstool zu entwerfen; KDE z. B. macht das sehr schoen vor.

Re(5): stable/updates - debian

mjy@geizhals.at — Tue, 24 Apr 2012 15:10:34 GMT

wenn sich die Leute mal XML als Config anschaun bzw. umbasteln würden.

wuaaah... geh weg mit dem Dreck. XML ist jetzt ca. 16 Jahre alt und noch immer gibt es haufenweise kaputte Parser.

Es gibt bereits außerordentlich gute und lesbare Alternativen wie YAML oder gar JSON(!).

Re(4): stable/updates - debian

A national Acrobat — Tue, 24 Apr 2012 14:12:05 GMT

Kennst Du auch die anderen Möglichkeiten ? Die sind nämlich noch g*PIEP*er.

Ob's jetzt Registry, ODM oder sonstirgendwie heißt, alles was ich nur mit Drittprogramme lesen kann suckt.

Einzig was praktisch wäre, wäre wenn sich die Leute mal XML als Config anschaun bzw. umbasteln würden.

Re(2): stable/updates - debian

User64693 — Tue, 24 Apr 2012 11:18:03 GMT

ich meinte nicht stable-updates sondern stable/updates im security-Pfad...

Re: stable/updates - debian

colossus — Tue, 24 Apr 2012 10:10:59 GMT

http://wiki.debian.org/StableUpdates

Re(4): stable/updates - debian

user96106 — Tue, 24 Apr 2012 09:36:37 GMT

damit lieferst du schon einen hauptgrund, warum man das nicht einsetzen will

mein alltime-favorite ist immer noch samba. deren dokumentation bestand bei vielen parametern einfach darin auf den sourcecode zu verweisen. als ob man nichts besseres zu tun hätte als c code zu lesen.

Re(3): stable/updates - debian

mjy@geizhals.at — Tue, 24 Apr 2012 06:40:19 GMT

Logik hat bei den ganzen permanenten Provisorien in der Linux-Welt schon lange nichts mehr verloren. Konfigurationsdateien, commandline-Optionen, sonstige Konventionen sind ein völlig inkonsistentes, benutzerunfreundliches Mischmasch, absolut hoffnungslos.

Re(2): stable/updates - debian

User64693 — Tue, 24 Apr 2012 06:18:03 GMT

danke - find die logik irgenwie verwirrend

Re: stable/updates - debian

mjy@geizhals.at — Mon, 23 Apr 2012 22:23:25 GMT

Das ist einfach der Pfad:

ftp://security.debian.org/debian-security/dists/stable
( deb ftp://security.debian.org/   stable/updates main contrib non-free )
vs.

ftp://ftp.de.debian.org/debian/dists/squeeze-updates/
( deb ftp://ftp.de.debian.org/debian  squeeze-updates main contrib non-free )

ftp://ftp.de.debian.org/debian/dists/squeeze/
( deb ftp://ftp.de.debian.org/debian  squeeze main contrib non-free )

oder

ftp://ftp.de.debian.org/debian-security/dists/stable
( deb ftp://ftp.de.debian.org/debian-security  stable/updates main contrib non-free )

Was es auf welchem Server für welches Archiv gibt, kann ich nicht so genau sagen. Ich schätze mal, dass häufig einfach viele Kombinationen zur Verfügung gestellt werden (mit Symlinks) damit man nicht so lange herumprobieren muss.

Re: stable/updates - debian

mjy@geizhals.at — Mon, 23 Apr 2012 22:23:25 GMT

Das ist einfach der Pfad:

ftp://security.debian.org/debian-security/dists/stable
( deb ftp://security.debian.org/  stable/updates main contrib non-free )
vs.

ftp://ftp.de.debian.org/debian/dists/squeeze-updates/
( deb ftp://ftp.de.debian.org/debian  squeeze-updates main contrib non-free )

ftp://ftp.de.debian.org/debian/dists/squeeze/
( deb ftp://ftp.de.debian.org/debian  squeeze main contrib non-free )

oder

ftp://ftp.de.debian.org/debian-security/dists/stable
( deb ftp://ftp.de.debian.org/debian-security  stable/updates main contrib non-free )

Was es auf welchem Server für welches Archiv gibt, kann ich nicht so genau sagen. Ich schätze mal, dass häufig einfach viele Kombinationen zur Verfügung gestellt werden (mit Symlinks) damit man nicht so lange herumprobieren muss.

stable/updates - debian

User64693 — Mon, 23 Apr 2012 18:27:02 GMT

Hi,

was bedeutet eigentlich das stable/updates in der sources.list?
deb http://security.debian.org/  stable/updates main contrib non-free

Was ist der Unterschied zu:
deb http://ftp.de.debian.org/debian/  stable main contrib non-free

könnte ich auch
deb http://ftp.de.debian.org/debian/  stable/updates main contrib non-free

angeben?

stable/updates - debian

User64693 — Mon, 23 Apr 2012 18:27:02 GMT

Hi,

was bedeutet eigentlich das stable/updates in der sources.list?
deb http://security.debian.org/ stable/updates main contrib non-free

Was ist der Unterschied zu:
deb http://ftp.de.debian.org/debian/ stable main contrib non-free

könnte ich auch
deb http://ftp.de.debian.org/debian/ stable/updates main contrib non-free

angeben?

gibts das stable/updates nur für den security Pfad?

stable/updates - debian

User64693 — Mon, 23 Apr 2012 18:27:02 GMT

Hi,

was bedeutet eigentlich das stable/updates in der sources.list?
deb http://security.debian.org/  stable/updates main contrib non-free

Was ist der Unterschied zu:
deb http://ftp.de.debian.org/debian/  stable main contrib non-free

könnte ich auch
deb http://ftp.de.debian.org/debian/  stable/updates main contrib non-free

angeben?

stable/updates - debian

User64693 — Mon, 23 Apr 2012 18:27:02 GMT