LANG-Wechsel von 9.0 auf 9.1
Hallo, habe heute mein AcerTravelmate-Notebook neu mit 9.1 installiert. Ich muss sagen, die Installation lief inkl. NVidia-Treiber ohne Probleme. Ich habe nur jetzt folgendes Problem. Unter 9.0 war die LANG-Variable auf LANG=de_DE@euro gestellt, unter 9.1 ist es jetzt per default LANG=de_DE.utf8 Dadurch werden Verzeichnisse/Dateien die Umlaute haben nicht mehr richtig angezeigt. Auch Umlaute in Textdateien (TeX, ...) nicht. Wie und wo kann man entweder a) LANG umstellen und/oder eine Konvertierung durchführen. Umstellen wäre mir lieber, da ich noch zwi Systeme mit 9.0 habe, und ich befürchte sonst weitere Probleme. Danke für eure Hilfe Holger
Hallo, On Wednesday 28 April 2004 19:32, Holger Biber wrote:
Ich habe nur jetzt folgendes Problem. Unter 9.0 war die LANG-Variable auf LANG=de_DE@euro gestellt, unter 9.1 ist es jetzt per default LANG=de_DE.utf8
Dadurch werden Verzeichnisse/Dateien die Umlaute haben nicht mehr richtig angezeigt. Auch Umlaute in Textdateien (TeX, ...) nicht. Wie und wo kann man entweder a) LANG umstellen und/oder eine Konvertierung durchführen.
Ich weiß nicht ob es alle deine Probleme löst, aber in den Release Notes, die dir nach Abschluss der Installation angezeigt werden(!) findest du unter anderem folgendes: --- schnipp ----- UTF-8-Kodierung als Standard Siehe http://www.suse.de/~mfabian/suse-cjk/locales.html [...] Nicht-UTF-8-Dateinamen Dateien in Dateisystemen, erstellt unter 9.0 und älteren Distributionen, verwenden (sofern nicht anders angegeben) nicht-UTF-8-Kodierung für die Dateinamen. Sollten diese Dateien andere als ASCII-Zeichen enthalten, werden sie unter SUSE LINUX 9.1 und späteren Versionen 'zerstümmelt'. Als Lösung kann das convmv-Skript verwendet werden, welches die Kodierung der Dateien nach UTF-8 umwandelt. --- schnapp ----- Nachzulesen in: file:/work/usr/share/doc/release-notes/RELEASE-NOTES.de.html Schöne Grüße aus Bremen harmut
Hi, habe die 9.1 noch nicht, plane sie mir jedoch demnächst zu erwerben. Warum sind sie von euro (@euro?) auf utf8 umgestiegen? Scheint ja damit Probleme zu geben. Was sind die Unterschiede? Das macht mir etwas Sorgen, was ich da lese. Ich habe einige Dateien mit Umlauten auch auf vfat-Partitionen. In wie weit beeinträchtigen eigtl. solche Kodierungen die Zusammenarbeit mit Windoof? Schliesslich möchte ich auch nach dem Update noch von Windows aus auf meine Datein mit Umlauten zugreifen können. Und was geschieht, wenn ich solche Dateien unter Windoof anlege? Dann kommt wiederum Linux nicht damit zurecht?? Jetzt (habe die SuSE 8.2) funktioniert das alles noch, soviel ich weiss... Danke für die Infos. Gruss Florian Am Mittwoch, 28. April 2004 20.50 schrieb Hartmut Meyer:
Hallo,
On Wednesday 28 April 2004 19:32, Holger Biber wrote:
Ich habe nur jetzt folgendes Problem. Unter 9.0 war die LANG-Variable auf LANG=de_DE@euro gestellt, unter 9.1 ist es jetzt per default LANG=de_DE.utf8
Dadurch werden Verzeichnisse/Dateien die Umlaute haben nicht mehr richtig angezeigt. Auch Umlaute in Textdateien (TeX, ...) nicht. Wie und wo kann man entweder a) LANG umstellen und/oder eine Konvertierung durchführen.
Ich weiß nicht ob es alle deine Probleme löst, aber in den Release Notes, die dir nach Abschluss der Installation angezeigt werden(!) findest du unter anderem folgendes:
--- schnipp ----- UTF-8-Kodierung als Standard
Siehe http://www.suse.de/~mfabian/suse-cjk/locales.html
[...]
Nicht-UTF-8-Dateinamen
Dateien in Dateisystemen, erstellt unter 9.0 und älteren Distributionen, verwenden (sofern nicht anders angegeben) nicht-UTF-8-Kodierung für die Dateinamen. Sollten diese Dateien andere als ASCII-Zeichen enthalten, werden sie unter SUSE LINUX 9.1 und späteren Versionen 'zerstümmelt'. Als Lösung kann das convmv-Skript verwendet werden, welches die Kodierung der Dateien nach UTF-8 umwandelt. --- schnapp -----
Nachzulesen in:
file:/work/usr/share/doc/release-notes/RELEASE-NOTES.de.html
Schöne Grüße aus Bremen harmut
Hi Hartmut,
Das macht mir etwas Sorgen, was ich da lese.
Die Sorgen machst Du Dir wohl zurecht. Zumindest scheint der Umgang mit den Dateien erheblich verkompliziert zu werden: Vor dem Entdecken der Probleme mit dem Indianer (siehe Threads oben) wunderte ich mich beim Lesen meiner aus einer 9.0-Umgebung portierten DB-Dumps in KWrite über die Lücken(!) im Text. Offenbar werden Umlaute nicht nur verstümmelt, sondern teilweise sogar mit ihrem 'Umfeld' nicht dargestellt. Bsp.: ein Name ähnlich 'Rübezahl' stellte sich als 'R zahl' dar.
Schliesslich möchte ich auch nach dem Update noch von Windows aus auf meine Datein mit Umlauten zugreifen können. Und was geschieht, wenn ich solche Dateien unter Windoof anlege? Dann kommt wiederum Linux nicht damit zurecht?? Jetzt (habe die SuSE 8.2) funktioniert das alles noch, soviel ich weiss...
Bleib' zunächst bloß bei Deinem laufenden System. Die 9.1 scheint unausgereifter als es auf den ersten Blick aussieht. Gruß Jörg
Hallo,el von 9.0 auf 9.1
Hi Hartmut,
Das macht mir etwas Sorgen, was ich da lese.
[...] Jetzt (habe die
SuSE 8.2) funktioniert das alles noch, soviel ich weiss...
Bleib' zunächst bloß bei Deinem laufenden System. Die 9.1 scheint unausgereifter als es auf den ersten Blick aussieht.
Gibt es eine Möglichkeit, sich den ganzen UTF8-Mist zu ersparen und so weiter zu machen wie bisher (meine mit ISO)? -Peter
Florian Brunner <fbrunnerlist@bluewin.ch> writes:
Hi, habe die 9.1 noch nicht, plane sie mir jedoch demnächst zu erwerben.
Warum sind sie von euro (@euro?) auf utf8 umgestiegen? Scheint ja damit Probleme zu geben. Was sind die Unterschiede?
Das macht mir etwas Sorgen, was ich da lese. Ich habe einige Dateien mit Umlauten auch auf vfat-Partitionen. In wie weit beeinträchtigen eigtl. solche Kodierungen die Zusammenarbeit mit Windoof? Schliesslich möchte ich auch nach dem Update noch von Windows aus auf meine Datein mit Umlauten zugreifen können. Und was geschieht, wenn ich solche Dateien unter Windoof anlege? Dann kommt wiederum Linux nicht damit zurecht?? Jetzt (habe die SuSE 8.2) funktioniert das alles noch, soviel ich weiss...
UTF-8 steht für UCS Transformation Format, und UCS steht für Universal Character Set. UTF-8 transformiert den universellen Zeichensatz für UNIX-Dateisysteme. Der Gedanke ist, multilingualen Text darstellen zu können. Das ganze ist in ISO 10646 und im Unicode Standard 3.0 beschrieben. Die Darstellungsprobleme bei Umlauten entstehen daraus, daß ein Teilsatz des UCS Codes, nämlich die Codes U+0000 bis U+007F als Byte 0x00 bis 0x7F kodiert werden, das entspricht dem ASCII-Zeichensatz. Alle über U+007F hinausgehenden UCS Zeichen werden als Sequenz mehrer Bytes kodiert, das sind dann z.B. Umlaute, die dann nicht mehr mit dem auf ASCII aufbauenden Zeichensatz iso8859-1 kompatibel sind. Auch Microsoft spricht UCS. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Hallo Dieter, danke für den theoretischen Hintergrund, aber wie gehe ich im alltäglichen Geschäft damit um? Ich kann doch nicht jedes Mal wenn ich auf eine Datei aus Zeiten vor 9.1 zugreife erst irgendwelche Scripte drüber laufen lassen. Das mag demjenigen Spaß machen, der Zeit dazu hat, ist doch aber völlig praxisfremd. Oder verstehe ich hier etwas falsch? Gruß Jörg
Czeschla@t-online.de (Jörg Czeschla) writes:
Hallo Dieter,
danke für den theoretischen Hintergrund, aber wie gehe ich im alltäglichen Geschäft damit um? Ich kann doch nicht jedes Mal wenn ich auf eine Datei aus Zeiten vor 9.1 zugreife erst irgendwelche Scripte drüber laufen lassen. Das mag demjenigen Spaß machen, der Zeit dazu hat, ist doch aber völlig praxisfremd. Oder verstehe ich hier etwas falsch?
Leider muß jede iso8859-x kodierte Datei nach UTF-8 gewandelt werden. Mit einem bischen Scripting ist das relativ einfach. Es gibt, als Bestandteil der C libraries, das Tool 'iconv' das läßt sich gut in Shellscripte einbauen, oder auch nur auf der Kommandozeile bedienen. Siehe dazu man iconv(1) man iconv(3). Ein vernünftiger Editor konvertiert problemlos, auch vi beherrscht UTF-8. Wenn du mehr wissen möchtest http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8 -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Am Donnerstag April 29 2004 09:47 schrieb Dieter Kluenter:
Czeschla@t-online.de (Jörg Czeschla) writes:
Ich kann doch nicht jedes Mal wenn ich auf eine Datei aus Zeiten vor 9.1 zugreife erst irgendwelche Scripte drüber laufen lassen.
Leider muß jede iso8859-x kodierte Datei nach UTF-8 gewandelt werden. Mit einem bischen Scripting ist das relativ einfach.
Ich hätte dann ein paar Gigabyte zu verarzten. Da hört vermutlich der Spaß auf, oder? Im Angebot wäre meine überaus große Mailbox, Websites, Dokus und sonstige textliche Downloads? Krieg' ich das auf einer neuen SuSE tatsächlich alles ohne Umlaute und sonstigen Sonderzeichen? Meine Backups sind natürlich auch noch da... Und wie wäre das bei Datenbankinhalten? (*Puh* , ich hab' keine, aber hier den Umlautstress in einer Produktivumgebung? *hups*). Sehe ich das mit der UTF-Umstellung jetzt zu schwarz? Helga -- ## Content Developer OpenOffice.org: lang/DE ## Office-Suite für Linux, Mac, Windows -- http://de.openoffice.org/ ## Werkstatt & Information zu OpenSource -- http://www.eschkitai.de/ ## Etikette, nein Danke? -- http://www.suse-etikette.de.vu/
Am Donnerstag, 29. April 2004 11:25 schrieb Helga Fischer:
Am Donnerstag April 29 2004 09:47 schrieb Dieter Kluenter:
Czeschla@t-online.de (Jörg Czeschla) writes:
Ich kann doch nicht jedes Mal wenn ich auf eine Datei aus Zeiten vor 9.1 zugreife erst irgendwelche Scripte drüber laufen lassen.
Leider muß jede iso8859-x kodierte Datei nach UTF-8 gewandelt werden. Mit einem bischen Scripting ist das relativ einfach.
Ich hätte dann ein paar Gigabyte zu verarzten. Da hört vermutlich der Spaß auf, oder? Im Angebot wäre meine überaus große Mailbox, Websites, Dokus und sonstige textliche Downloads? Krieg' ich das auf einer neuen SuSE tatsächlich alles ohne Umlaute und sonstigen Sonderzeichen? Meine Backups sind natürlich auch noch da...
Also ich habe bei gerade die Konvertierung laufen lassen. Funzte gut. Jetzt kann ich wieder auf meine Textfiles Zugriff nehmen. Mit der Mailbox habe ich keine Erfahrung gemacht, da ich diese ausgespart habe.
Und wie wäre das bei Datenbankinhalten? (*Puh* , ich hab' keine, aber hier den Umlautstress in einer Produktivumgebung? *hups*).
Sorry keine Ahnung. Bei einer Produktivumgebung, würde ich nie sowas machen. Da gilt für mich das erste Gesetz von Murphy: Never change a running system. Dies aus eigener leidvoller Erfahung berichtend. CU at the trails Boris
Hallo, das kann doch nicht sein, oder? Ich nehme an bzw. hoffe stark und erwarte, dass dazu schleunigst ein SDB-Eintrag erscheint. Es handelt sich ja tatsächlich sowohl um die Dateinamen als auch (Text-)Dateiinhalte (die man via mvconv bzw. iconv konvertieren kann). Aber es dürfte genügend Beispiele geben, bei denen diese Tools nicht hinreichen, z. B. Binärdateien mit teilweise Klartextinhalt. Ich habe z. B. einen SuSE 8.2 Samba-Dateiserver, auf den u. A. mit einer SuSE 9.1 zugegriffen werden soll. Das wird wohl einige Aufmerksamkeit in Anspruch nehmen, bis klar ist, welche Codepage(?) und Sprachkodierung Samba-Server-seitig und Samba-Client-seitig einzustellen ist und wie die Dateinamen- und Inhaltekonvertierung vorgenommen werden soll. Außerdem bleibt die Frage der Binärdateien (ich nenn sie jetzt so). Irgendwie kann das doch nicht so schwer sein - oder man wird die SuSE 9.1 eher ungern einsetzen wollen. Diese ganze Lokalisierungsproblematik ist denke ich heute eines der Hauptprobleme, deswegen ist es eigentlich ganz sinnvoll, mal richtig umzustellen. Im Deutschen u. ä. Sprachen betrifft das ja "nur" die Umlaute und "ß", aber das geht im Fall von anderen Sprachen bestimmt noch doller... Grüße, René
Am Donnerstag, 29. April 2004 21:08 schrieb René Matthäi:
Hallo,
das kann doch nicht sein, oder? Ich nehme an bzw. hoffe stark und erwarte, dass dazu schleunigst ein SDB-Eintrag erscheint.
Nicht nur dazu. Zum Kernelproblem bzgl. XFS gibt es auch noch immer keinen Artikel. Ich verwende nun SuSE schon seit ca. 6.1 und es gab immer Probleme bei einer neuen Distri. IMO gab es so gravierende Probleme aber noch nie. Merkt man da vielleicht Umstrukturierungsmaßnahmen durch Novell? Ich möchte am Wochenende einige Clients von 8.2 auf 9.1 umstellen, bin mir aber noch total unsicher, ob das eine gute Idee ist, wenn die Server nicht auch auf 9.1 umgestellt werden. Ich habe 9.1 noch nicht, sie ist aber für morgen angekündigt. Muss ich nun alle persönlichen Dokumente, Datenbanken, etc. auf den 9.1 Clients konvertieren und auf den 8.2-Servern nicht? Mit rsync sind wohl auch Probleme vorprogrammiert. Al
Helga Fischer schrieb:
Ich hätte dann ein paar Gigabyte zu verarzten. Da hört vermutlich der Spaß auf, oder? Im Angebot wäre meine überaus große Mailbox, Websites, Dokus und sonstige textliche Downloads? Krieg' ich das auf einer neuen SuSE tatsächlich alles ohne Umlaute und sonstigen Sonderzeichen? Meine Backups sind natürlich auch noch da...
Und wie wäre das bei Datenbankinhalten? (*Puh* , ich hab' keine, aber hier den Umlautstress in einer Produktivumgebung? *hups*).
Sehe ich das mit der UTF-Umstellung jetzt zu schwarz?
Gilt das wirklich auch für die Inhalte oder bezieht es sich nur auf Dateinamen?? Gruß Günther
* Am Don, 29 Apr 2004 schrieb Günther Zinsberger:
Helga Fischer schrieb:
Ich hätte dann ein paar Gigabyte zu verarzten. Da hört vermutlich der Spaß auf, oder? Im Angebot wäre meine überaus große Mailbox, Websites, Dokus und sonstige textliche Downloads? Krieg' ich das auf einer neuen SuSE tatsächlich alles ohne Umlaute und sonstigen Sonderzeichen? Meine Backups sind natürlich auch noch da...
Und wie wäre das bei Datenbankinhalten? (*Puh* , ich hab' keine, aber hier den Umlautstress in einer Produktivumgebung? *hups*).
Sehe ich das mit der UTF-Umstellung jetzt zu schwarz?
Gilt das wirklich auch für die Inhalte oder bezieht es sich nur auf Dateinamen??
Nein, das gilt auch für die Inhalte... Gruß Christoph
Hallo Liste. Kann man bei der 9.1 nicht mehr selber die LANG Variable einstellen? Bei der 9.0 geht es unter /etc/sysconfig/language ______________________________________________________________ ## Path: System/Environment/Language ## Description: ## Type: string(POSIX,ca_ES.ISO-8859-1,ca_ES.UTF-8,cs_CZ.ISO-8859-2, cs_CZ.UTF-8,da_DE@euro,da_DK.ISO-8859-1,da_DK.UTF-8,de_DE@euro, de_DE.ISO-8859-1,de_DE.UTF-8,el_GR.ISO-8859-7,el_GR.UTF-8, en_GB.ISO-8859-1,en_GB.UTF-8,en_IE@euro,en_IE.ISO-8859-1, en_US.ISO-8859-1,es_ES@euro,es_ES.ISO-8859-1,es_ES.UTF-8, fr_FR@euro,fr_FR.ISO-8859-1,fr_FR.UTF-8,gl_ES@euro,gl_ES.ISO-8859-1 gl_ES.utf-8,hr_HR.ISO-8859-2,hu_HU.ISO-8859-2,hu_HU.UTF-8,it_IT@euro, it_IT.ISO-8859-1,it_IT.UTF-8,ja_JP.eucJP,ja_JP.UTF-8,lt_LT.ISO-8859-13, lt_LT.UTF-8,nl_NL@euro,nl_NL.ISO-8859-1,nl_NL.UTF-8,ru_RU.ISO-8859-5, ru_RU.KOI8R,ru_RU.UTF-8,sk_SK.ISO-8859-2,sk_SK.UTF-8,tr_TR.ISO-8859-9, tr_TR.UTF-8,ko_KR.eucKR,ko_KR.UTF-8,zh_TW.Big5,zh_TW.UTF-8, zh_CN.GB2312,zh_CN.UTF-8) ## Default: "" ## Config: OpenOffice.org,groff,ispell,kde,kdm3,profiles,susehelp,susewm,tetex,wdm # # # Local users will get RC_LANG as their default language, i.e. the # environment variable $LANG . $LANG is the default of all $LC_*-variables, # as long as $LC_ALL is not set, which overrides all $LC_-variables. # Root uses this variable only if ROOT_USES_LANG is set to "yes". # RC_LANG="de_DE@euro" __________________________________________________________ oder ist die "de_DE@euro" Variable gar nicht mehr vorhanden und man kann diese auch gar nicht einstellen unter der 9.1 Distribution? Grüße Rafael.
Rafael <xeonitlinux@yahoo.de> writes:
Hallo Liste. Kann man bei der 9.1 nicht mehr selber die LANG Variable einstellen? Bei der 9.0 geht es unter /etc/sysconfig/language [...] # Local users will get RC_LANG as their default language, i.e. the # environment variable $LANG . $LANG is the default of all $LC_*-variables, # as long as $LC_ALL is not set, which overrides all $LC_-variables. # Root uses this variable only if ROOT_USES_LANG is set to "yes". # RC_LANG="de_DE@euro" __________________________________________________________
oder ist die "de_DE@euro" Variable gar nicht mehr vorhanden und man kann diese auch gar nicht einstellen unter der 9.1 Distribution? Grüße Rafael.
Das kannst du selbst prüfen, locale -m gibt dir alle verfügbaren Zeichensätze aus. Wenn du auf de_DE@euro zurückstellst, kannst du mit dem Befehl 'locale charmap' prüfen, welche Kodierung genutzt wird. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Am Donnerstag, 29. April 2004 11:46 schrieb Christoph Maurer:
* Am Don, 29 Apr 2004 schrieb Günther Zinsberger:
Gilt das wirklich auch für die Inhalte oder bezieht es sich nur auf Dateinamen??
Nein, das gilt auch für die Inhalte...
Einen Moment mal, wenn es nach der Umstellung nicht mehr möglich wäre "normalen" ASCII Text zu erstellen wäre das ja gelinde gesagt eine Katastrophe. Sourcecode, Webseiten, Mails und dergleichen kann ja nicht einfach beliegig in UTF erstellt werden, nur weil das System intern mit UTF arbeitet. Nebenbei bemerkt kann z.B. KWrite/Kate eingerichtet werden, wie es Dateien behandelt, auch wenn das System noch auf ISO-8859-1 oder -15 läuft. Weshalb das dann nicht mehr funktionieren sollte, wäre mir ein Rätsel. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Manfred Tremmel <Manfred.Tremmel@iiv.de> writes:
Am Donnerstag, 29. April 2004 11:46 schrieb Christoph Maurer:
* Am Don, 29 Apr 2004 schrieb Günther Zinsberger:
Gilt das wirklich auch für die Inhalte oder bezieht es sich nur auf Dateinamen??
Nein, das gilt auch für die Inhalte...
Einen Moment mal, wenn es nach der Umstellung nicht mehr möglich wäre "normalen" ASCII Text zu erstellen wäre das ja gelinde gesagt eine Katastrophe. Sourcecode, Webseiten, Mails und dergleichen kann ja nicht einfach beliegig in UTF erstellt werden, nur weil das System intern mit UTF arbeitet. Nebenbei bemerkt kann z.B. KWrite/Kate eingerichtet werden, wie es Dateien behandelt, auch wenn das System noch auf ISO-8859-1 oder -15 läuft. Weshalb das dann nicht mehr funktionieren sollte, wäre mir ein Rätsel.
Bei ASCII brauchst du keine Befürchtungen zu haben. Wie ich schon zu Beginn dieses Threads schrieb, sind die Bytewerte der ASCII-Zeichen itentisch, also von 0x00 bis 0x7F. -Dieter - -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Manfred Tremmel <Manfred.Tremmel@iiv.de> writes:
Am Donnerstag, 29. April 2004 11:46 schrieb Christoph Maurer:
* Am Don, 29 Apr 2004 schrieb Günther Zinsberger:
Gilt das wirklich auch für die Inhalte oder bezieht es sich nur auf Dateinamen??
Nein, das gilt auch für die Inhalte...
Einen Moment mal, wenn es nach der Umstellung nicht mehr möglich wäre "normalen" ASCII Text zu erstellen wäre das ja gelinde gesagt eine Katastrophe. Sourcecode, Webseiten, Mails und dergleichen kann ja nicht einfach beliegig in UTF erstellt werden, nur weil das System intern mit UTF arbeitet. Nebenbei bemerkt kann z.B. KWrite/Kate eingerichtet werden, wie es Dateien behandelt, auch wenn das System noch auf ISO-8859-1 oder -15 läuft. Weshalb das dann nicht mehr funktionieren sollte, wäre mir ein Rätsel.
Bei Quellcode kann zukünftig ein anderes Problem auftreten, da UTF-8 Zeichen aus 2 und mehr bit bestehen kann. Da kann es dann Probleme mit den Spaltenbreiten geben, wenn nationaler Code mit 1 bit Code kombiniert wird. Ich habe aber irgendwo mal gelesen, daß Editoren und Compiler damit umgehen können sollen, Quelle weiß ich aber nicht. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Helga Fischer <Azula@gmx.de> writes:
Am Donnerstag April 29 2004 09:47 schrieb Dieter Kluenter:
Czeschla@t-online.de (Jörg Czeschla) writes:
Ich kann doch nicht jedes Mal wenn ich auf eine Datei aus Zeiten vor 9.1 zugreife erst irgendwelche Scripte drüber laufen lassen.
Leider muß jede iso8859-x kodierte Datei nach UTF-8 gewandelt werden. Mit einem bischen Scripting ist das relativ einfach.
Ich hätte dann ein paar Gigabyte zu verarzten. Da hört vermutlich der Spaß auf, oder? Im Angebot wäre meine überaus große Mailbox, Websites, Dokus und sonstige textliche Downloads? Krieg' ich das auf einer neuen SuSE tatsächlich alles ohne Umlaute und sonstigen Sonderzeichen? Meine Backups sind natürlich auch noch da...
Und wie wäre das bei Datenbankinhalten? (*Puh* , ich hab' keine, aber hier den Umlautstress in einer Produktivumgebung? *hups*).
Sehe ich das mit der UTF-Umstellung jetzt zu schwarz?
Früher oder später solltest du mit der Umstellung beginnen, denn in absehbarer Zeit wird es keine iso8859-x mehr geben, nur noch iso-10646, aber mache dich erst einmal schlau, vielleicht wird es ja in naher Zukunft Clientanwendungen geben, die selbsttätig konvertieren können. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Hallo Helga,
Und wie wäre das bei Datenbankinhalten? (*Puh* , ich hab' keine, aber hier den Umlautstress in einer Produktivumgebung? *hups*).
So bin ich ja drauf gekommen: wollte meine lokale mysql-DBs (unter 9.0) als *.sql-Dump per Speicherstick auf das 9.1-System übertragen und sah, dass plötzlich keine Umlaute mehr vorhanden waren. Erübrigt hat sich's nur, weil Apache sowieso nicht zur Arbeit überredet werden kann... Jörg
Am Donnerstag, 29. April 2004 11:25 schrieb Helga Fischer:
Am Donnerstag April 29 2004 09:47 schrieb Dieter Kluenter:
Czeschla@t-online.de (Jörg Czeschla) writes:
Ich kann doch nicht jedes Mal wenn ich auf eine Datei aus Zeiten vor 9.1 zugreife erst irgendwelche Scripte drüber laufen lassen.
Leider muß jede iso8859-x kodierte Datei nach UTF-8 gewandelt werden. Mit einem bischen Scripting ist das relativ einfach.
was ist denn jetzt der Vorteil von UTF-8 ??? wiso nicht die bisherigen iso geschichtle?
Ich hätte dann ein paar Gigabyte zu verarzten. Da hört vermutlich der Spaß auf, oder? Im Angebot wäre meine überaus große Mailbox, Websites, Dokus und sonstige textliche Downloads? Krieg' ich das auf einer neuen SuSE tatsächlich alles ohne Umlaute und sonstigen Sonderzeichen? Meine Backups sind natürlich auch noch da...
? Sol.l das heisen dass jetzt mit Umlauten Sparsam umzugehen ist? GiGabyte habe ich zwar nicht, aber auch wenns nur ein Textdokument währe, möchte ich das nicht einsehen (wenns keinen Vortel gibt)
Sehe ich das mit der UTF-Umstellung jetzt zu schwarz?
Die Zeiten von Helmut Kohl sind doch vorbei oder? MfG TB -- http://www.gasthof-linde.de http://www.chef-de-cuisine.de
Thilo Alfred Bätzig <suse@chef-de-cuisine.de> writes:
Am Donnerstag, 29. April 2004 11:25 schrieb Helga Fischer:
Am Donnerstag April 29 2004 09:47 schrieb Dieter Kluenter:
Czeschla@t-online.de (Jörg Czeschla) writes:
Ich kann doch nicht jedes Mal wenn ich auf eine Datei aus Zeiten vor 9.1 zugreife erst irgendwelche Scripte drüber laufen lassen.
Leider muß jede iso8859-x kodierte Datei nach UTF-8 gewandelt werden. Mit einem bischen Scripting ist das relativ einfach.
was ist denn jetzt der Vorteil von UTF-8 ??? wiso nicht die bisherigen iso geschichtle?
Mit iso8859-x muß für jede Sprache ein eigener Font installiert werden, und wenn dann noch Chinesisch, Japanisch, Farsi und weiß der Geier was noch an fremden Zeichen benötigt werden, müssen die auch ausdrücklich installiert sein und vor allen Dingen auch sichtbar gemacht werden können. Mit UTF-8 brauchst du das nicht. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Am Donnerstag, 29. April 2004 21:15 schrieb Dieter Kluenter:
Thilo Alfred Bätzig <suse@chef-de-cuisine.de> writes:
Am Donnerstag, 29. April 2004 11:25 schrieb Helga Fischer:
Am Donnerstag April 29 2004 09:47 schrieb Dieter Kluenter:
Czeschla@t-online.de (Jörg Czeschla) writes:
Ich kann doch nicht jedes Mal wenn ich auf eine Datei aus Zeiten vor 9.1 zugreife erst irgendwelche Scripte drüber laufen lassen.
Leider muß jede iso8859-x kodierte Datei nach UTF-8 gewandelt werden. Mit einem bischen Scripting ist das relativ einfach.
was ist denn jetzt der Vorteil von UTF-8 ??? wiso nicht die bisherigen iso geschichtle?
Mit iso8859-x muß für jede Sprache ein eigener Font installiert werden, und wenn dann noch Chinesisch, Japanisch, Farsi und weiß der Geier
JA ich weiß was der Geier weiß ;-))
was noch an fremden Zeichen benötigt werden, müssen die auch ausdrücklich installiert sein und vor allen Dingen auch sichtbar gemacht werden können. Mit UTF-8 brauchst du das nicht.
Ist UTF-8 dann auch Zukunftsicher? und vor allem wie komliziert gestaltet sich dann eine Umstellung (in diesem meinem fall z.B. von SuSE<9.0 auf diese UTF-8/SuSE=9.1 oder größer) in die richtige Codierung, und was mich dann auch noch Interessieren würde wie Zukunftsicher ist die sache denn? MfG TB -- http://www.gasthof-linde.de http://www.chef-de-cuisine.de
Thilo Alfred Bätzig <suse@chef-de-cuisine.de> writes:
Am Donnerstag, 29. April 2004 21:15 schrieb Dieter Kluenter:
Thilo Alfred Bätzig <suse@chef-de-cuisine.de> writes:
Am Donnerstag, 29. April 2004 11:25 schrieb Helga Fischer:
Am Donnerstag April 29 2004 09:47 schrieb Dieter Kluenter:
Czeschla@t-online.de (Jörg Czeschla) writes: [...] Ist UTF-8 dann auch Zukunftsicher? und vor allem wie komliziert gestaltet sich dann eine Umstellung (in diesem meinem fall z.B. von SuSE<9.0 auf diese UTF-8/SuSE=9.1 oder größer)
Ja Unicode, und UTF-8 ist eine Teilmenge von Unicode, gehört die Zukunft und so groß ist die Umstellung für uns Westeuropaer nicht. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Am Freitag, 30. April 2004 07:15 schrieb Dieter Kluenter:
Thilo Alfred Bätzig <suse@chef-de-cuisine.de> writes:
Am Donnerstag, 29. April 2004 21:15 schrieb Dieter Kluenter:
Thilo Alfred Bätzig <suse@chef-de-cuisine.de> writes:
Am Donnerstag, 29. April 2004 11:25 schrieb Helga Fischer:
Am Donnerstag April 29 2004 09:47 schrieb Dieter Kluenter:
Czeschla@t-online.de (Jörg Czeschla) writes:
[...]
Ist UTF-8 dann auch Zukunftsicher? und vor allem wie komliziert gestaltet sich dann eine Umstellung (in diesem meinem fall z.B. von SuSE<9.0 auf diese UTF-8/SuSE=9.1 oder größer)
Ja Unicode, und UTF-8 ist eine Teilmenge von Unicode, gehört die Zukunft und so groß ist die Umstellung für uns Westeuropaer nicht.
HE Ich bin Alamanne....oder Schwabe auf neudeutsch ;-) Aber lassen wir das sonst wird es OT MfG TB -- http://www.gasthof-linde.de http://www.chef-de-cuisine.de
Helga Fischer <Azula@gmx.de> [29 Apr 2004 11:25:35 +0200]:
Im Angebot wäre meine überaus große Mailbox, Websites, Dokus und sonstige textliche Downloads?
Zumindest die Mailbox solltest du nicht anfassen müssen, denn Mails haben ja in der Regel über das "charset=" eine Angabe, in welcher Zeichenkodierung sie geschrieben wurden und damit kann der MUA sie weiterhin korrekt anzeigen. Bei Websites wird in der Regel auch die Kodierung angegeben, sollten also ebenfalls kein Problem machen. Philipp
Hallo, Am Thu, 29 Apr 2004, Philipp Thomas schrieb:
Zumindest die Mailbox solltest du nicht anfassen müssen, denn Mails haben ja in der Regel über das "charset=" eine Angabe, in welcher Zeichenkodierung sie geschrieben wurden und damit kann der MUA sie weiterhin korrekt anzeigen. Bei Websites wird in der Regel auch die Kodierung angegeben, sollten also ebenfalls kein Problem machen.
Wo bekomm ich das Zeug das du rauchst? Muss verdammt gut sein, der Stoff. Oder wie komm ich in dein Paralleluniversum? Hier ist zwar erfreulicherweise die Quote der Mails mit korrektem Content-Type inkl. charset-Angabe relativ hoch[1], aber "da draussen", da wo nicht kmail und mutt wie hier, sondern AutschGuck und OhJeh und andere Virenschleudern (sieh sig) dominieren, da sieht's anders aus. Und dann ist da noch die Krankheit namens Lokus Bloates, das zwar angeblich korrekt konfiguriert werden koennte, es in der Praxis aber praktisch nie ist (und dann z.B. keine References erzeugt). Und Webseiten... Da ist die Masse defekt. Genrell und speziell auch bzgl. '<meta http-equiv="Content-Type" ...>'. -dnh PS: Deine Msg-Id... Du verwendest zwar Forte, und die Verwendung mag ja von "Forte Internet Software, Inc." abgewinkt sein, aber "wollen" tut man das nicht. [1] hier trudelt (grad z.Z. wieder) immer noch mehr als genug Defektes ein, mit defektem Content-Type, fehlenden References/In-Reply-To, defekten Subjects usw. usf. Von defekten Msg-Ids ganz zu schweigen. -- "If you are using an Macintosh e-mail program that is not from Microsoft, we recommend checking with that particular company. But most likely other e-mail programs like Eudora are not designed to enable virus replication" -- http://www.microsoft.com/mac/products/office/2001/virus_alert.asp
Hi David, Am Freitag April 30 2004 05:12 schrieb David Haller:
Am Thu, 29 Apr 2004, Philipp Thomas schrieb:
Zumindest die Mailbox solltest du nicht anfassen müssen, denn Mails haben ja in der Regel über das "charset=" eine Angabe, in welcher Zeichenkodierung sie geschrieben wurden und damit kann der MUA sie weiterhin korrekt anzeigen. Bei Websites wird in der Regel auch die Kodierung angegeben, sollten also ebenfalls kein Problem machen.
Wo bekomm ich das Zeug das du rauchst? Muss verdammt gut sein, der Stoff. Oder wie komm ich in dein Paralleluniversum? [...] Und Webseiten... Da ist die Masse defekt. Genrell und speziell auch bzgl. '<meta http-equiv="Content-Type" ...>'.
Ich hab' inzwischen eine ganz einfache Lösung: Meine SuSE 8.2 bleibt mein Produktivsystem. Zum Experimentieren und fürs allerneueste KDE-Geraffel nehme ich mir SuSE 9.0 her. Da läuft XFS; neuen 2.6er-Kernel und den integrierten IPsec-Kram kriege ich vielleicht auch so hin (Das waren nämlich _die_ zwei Punkte, um mir mal wieder eine Box zuzulegen; und natürlich KDE 3.2.2, der bei mir einfach nicht installiert werden wollte). Vielleicht lerne ich bei der Gelegenheit auch noch, wie man 'richtige' rpms baut. Und dann lasse ich doch einfach mal ein paar Monate ins Land gehen und schau mir die Entwicklung in aller Ruhe an. Wirklich schade, daß das so doof gelaufen ist und eine Installation von SuSE 9.1 in Nacharbeit ohne Ende ausartet. Gerade das wollte ich nämlich vermeiden. Helga -- ## Content Developer OpenOffice.org: lang/DE ## Office-Suite für Linux, Mac, Windows -- http://de.openoffice.org/ ## Werkstatt & Information zu OpenSource -- http://www.eschkitai.de/ ## Etikette, nein Danke? -- http://www.suse-etikette.de.vu/
0David Haller <david@dhaller.de> [Fr, 30 Apr 2004 05:12:29 +0200]:
PS: Deine Msg-Id... Du verwendest zwar Forte, und die Verwendung mag ja von "Forte Internet Software, Inc." abgewinkt sein, aber "wollen" tut man das nicht.
Meine Msg-ID: Message-ID: <1vl290tf1at1098oav3un3hdkjl4fpa8c7@4ax.com> Deine Msg-ID: Message-ID: <20040430031229.GB10115@feersum.endjinn.de> Und ??? Aber vielleicht bin ich ja nur begriffsstutzig :)
ein, mit defektem Content-Type,
Da gebe ich dir Recht.
fehlenden References/In-Reply-To, defekten Subjects usw. usf. Von defekten Msg-Ids ganz zu schweigen.
Davon war hier aber überhaupt nicht die Rede, du schweifst ab :)) Philipp
Hallo, Am Fri, 30 Apr 2004, Philipp Thomas schrieb:
0David Haller <david@dhaller.de> [Fr, 30 Apr 2004 05:12:29 +0200]:
PS: Deine Msg-Id... Du verwendest zwar Forte, und die Verwendung mag ja von "Forte Internet Software, Inc." abgewinkt sein, aber "wollen" tut man das nicht.
Meine Msg-ID: Message-ID: <1vl290tf1at1098oav3un3hdkjl4fpa8c7@4ax.com> Deine Msg-ID: Message-ID: <20040430031229.GB10115@feersum.endjinn.de>
Und ??? Aber vielleicht bin ich ja nur begriffsstutzig :)
Ja. *eg* Ich bezog mich auf den Domain-Part. Ich habe nicht nachgeschaut, aber selbst wenn Forte a) explizit zusichert, dass man diesen domain-part verwenden darf und b) explizit zusichert, dass trotz der $vielen Forte Installationen, die wegen a) identische domain parts verwenden, dennoch immer eindeutige IDs erzeugt werden (was ich fuer unmoeglich halte, es sei denn, der local-part enthaelt z.B. die Registrierungs-Nr. o.ae., was wiederum anderweitig bedenklich waere) dann will man das eigentlich dennoch nicht. Zumal wenn man z.B. sowieso ueber eine ISP versendet, der ein Schema fuer IDs anbietet. Ich wollte jedenfalls keine Msg-IDs nach dem Muster *@*mutt.org verwenden. Obwohl ich mutt.org mehr vertraue als 4ax.com. Immerhin, deine Msg-IDs sind wohl valide, aber ich habe schon erstmal gestutzt (und die domain und deinen Header genauer angeschaut), da man es eben einfach zu haeufig sieht, dass flasche domain-parts in IDs verwendet werden. Noch haeufiger sind aber leider defekte domain-parts. (linux.local anyone? *PATSCH*) Und wenn dann noch defekte MUAs wie Evolution daherkommen, bei denen man die generierung der ID nichtmal ausschalten kann, "da koennt' i narrisch wern".
ein, mit defektem Content-Type,
Da gebe ich dir Recht.
fehlenden References/In-Reply-To, defekten Subjects usw. usf. Von defekten Msg-Ids ganz zu schweigen.
Davon war hier aber überhaupt nicht die Rede, du schweifst ab :))
*huch* Na sowas aber auch! Tu ich das oefter? -dnh -- If you haven't got time to RTFM, you haven't got time to whine on this mailing list.
Hallo, Am Sun, 02 May 2004, Philipp Thomas schrieb:
David Haller <david@dhaller.de> [Sa, 1 Mai 2004 04:51:33 +0200]:
Davon war hier aber überhaupt nicht die Rede, du schweifst ab :))
*huch* Na sowas aber auch! Tu ich das oefter?
Och ja, aber das ist ja einer deiner netten Züge :)
Oh, danke :)) -dnh -- If you haven't got time to RTFM, you haven't got time to whine on this mailing list.
Hallo, On Saturday 01 May 2004 04:51, David Haller wrote:
Ich bezog mich auf den Domain-Part. Ich habe nicht nachgeschaut, aber selbst wenn Forte
a) explizit zusichert, dass man diesen domain-part verwenden darf und
b) explizit zusichert, dass trotz der $vielen Forte Installationen, die wegen a) identische domain parts verwenden, dennoch immer eindeutige IDs erzeugt werden (was ich fuer unmoeglich halte, es sei denn, der local-part enthaelt z.B. die Registrierungs-Nr. o.ae., was wiederum anderweitig bedenklich waere)
Ist die absolute/garantierte Eindeutigkeit bei einer so erzeugten Message-ID nicht eher ein akademisches Problem? Es fällt mir schwer mir ein realistisches Szenario vorzustellen, wo dieses "Problem" auch zu einem tatsächlichen wird. Schöne Grüße aus Bremen hartmut
Hallo, Am Sun, 02 May 2004, Hartmut Meyer schrieb:
On Saturday 01 May 2004 04:51, David Haller wrote:
Ich bezog mich auf den Domain-Part. Ich habe nicht nachgeschaut, aber selbst wenn Forte
a) explizit zusichert, dass man diesen domain-part verwenden darf und
b) explizit zusichert, dass trotz der $vielen Forte Installationen, die wegen a) identische domain parts verwenden, dennoch immer eindeutige IDs erzeugt werden (was ich fuer unmoeglich halte, es sei denn, der local-part enthaelt z.B. die Registrierungs-Nr. o.ae., was wiederum anderweitig bedenklich waere)
Ist die absolute/garantierte Eindeutigkeit bei einer so erzeugten Message-ID nicht eher ein akademisches Problem?
Kommt drauf an wie die ID generiert wird. Bei tausenden Usern kann es mit einer schlechten Methode durchaus zu einer Kollision kommen. Ausserdem geht's nicht darum, ob es praktisch nicht zu Kollisionen kommt. Die RfCs sind recht explizit darin, dass gefordert ist, dass derjenige, der die ID generiert bzw. generieren laesst, die Kollisions- freiheit garantieren kann. Und das geht nur, wenn man die Kontrolle ueber den verwendeten Namensraum hat, z.B. @ID-XXXXX.user.uni-berlin.de. -dnh -- If you haven't got time to RTFM, you haven't got time to whine on this mailing list.
Hallo Hartmut, hallo Leute, Am Sonntag, 2. Mai 2004 07:33 schrieb Hartmut Meyer:
On Saturday 01 May 2004 04:51, David Haller wrote: [...] Ist die absolute/garantierte Eindeutigkeit bei einer so erzeugten Message-ID nicht eher ein akademisches Problem?
Es fällt mir schwer mir ein realistisches Szenario vorzustellen, wo dieses "Problem" auch zu einem tatsächlichen wird.
Denk nochmal nach ;-) - grepmail -u (arbeitet laut Doku anhand der Message-ID) - "Doppelte Nachrichten löschen" in KMail (wobei ich nicht genau weiß, nach welchen Kriterien das arbeitet, ich tippe spontan auf die Message-ID) - einige Mailserver werfen eingehende Mails weg, wenn sie sie laut Message-ID bereits kennen - bei News werden AFAIK doppelte Message-IDs noch öfter aussortiert (Du denkst an mail2news-Gateways?) - generell: falsches Threading im MUA, da Antworten unter der falschen Mail eingereiht werden (dieses Problem ist vor einiger Zeit bei mir tatsächlich mal bei einigen Mails in suse-linux aufgetreten!) - ... Die Eindeutigkeit der Message-IDs ist also auch in der Praxis wichtig. Gruß Christian Boltz (mit selbstgenerierten Message-IDs @tux.boltz.de.vu) --
vorweg: Hier war gerade Stromausfall. Da hat der Sturm wohl irgendwo einen Baum auf die Leitung geworfen... ext3 hat mich zwar anscheinend vor größeren Schäden bewahrt. Mit reiserfs stände der Baum noch. :-) [> Christian Boltz und Ratti in fontlinge-devel]
Hallo, On Sunday 02 May 2004 20:09, Christian Boltz wrote:
Am Sonntag, 2. Mai 2004 07:33 schrieb Hartmut Meyer:
On Saturday 01 May 2004 04:51, David Haller wrote:
Ist die absolute/garantierte Eindeutigkeit bei einer so erzeugten Message-ID nicht eher ein akademisches Problem?
Es fällt mir schwer mir ein realistisches Szenario vorzustellen, wo dieses "Problem" auch zu einem tatsächlichen wird.
Denk nochmal nach ;-)
- grepmail -u (arbeitet laut Doku anhand der Message-ID) - "Doppelte Nachrichten löschen" in KMail (wobei ich nicht genau weiß, nach welchen Kriterien das arbeitet, ich tippe spontan auf die Message-ID) - einige Mailserver werfen eingehende Mails weg, wenn sie sie laut Message-ID bereits kennen - bei News werden AFAIK doppelte Message-IDs noch öfter aussortiert (Du denkst an mail2news-Gateways?) - generell: falsches Threading im MUA, da Antworten unter der falschen Mail eingereiht werden (dieses Problem ist vor einiger Zeit bei mir tatsächlich mal bei einigen Mails in suse-linux aufgetreten!)
Wegen nicht-eindeutiger Message-IDs? Wenn ja, dann handelte es sich aber sicher um Message-IDs, deren Eindeutigkeit viel gründlicher sabotiert wurde als in dem Beispiel über das wir hier reden.
- ...
Die Eindeutigkeit der Message-IDs ist also auch in der Praxis wichtig.
Ich denke du hast mich falsch verstanden. Das was du beschreibst sind die theoretischen Gefahren die sich aus nicht-eindeutigen Message-IDs ergeben. Ich habe - und zwar konkret in Bezug auf die als Beispiel genannte Message-ID von Philipp Thomas - bezweifelt, dass aus der theoretischen Uneindeutigkeit auch in der Praxis einmal eine Uneindeutigkeit entstehen könnte. Davids Argument, dass die Befolgung von RFCs schon ein Wert an sich ist, kann ich wiederum nachvollziehen. Allerdings würde ich dann auch damit argumentieren und nicht mit theoretisch (aber im konkreten Beispiel praktisch vermutlich unrelevanten) drohenden Gefahren. Schöne Grüße aus Bremen hartmut
Hallo, Am Sun, 02 May 2004, Hartmut Meyer schrieb: [..]
Wegen nicht-eindeutiger Message-IDs? Wenn ja, dann handelte es sich aber sicher um Message-IDs, deren Eindeutigkeit viel gründlicher sabotiert wurde als in dem Beispiel über das wir hier reden.
Wie gut die IDs von Forte sind weiss ich nicht. Wenn da aber kein "lokaler" Part enthalten ist, dann ist die Eindeutigkeit nicht gewaehrleistet. Selbst wenn gute Zufallszahlen in die ID eingehen sollten kann man es eben nicht gewaehrleisten.
Die Eindeutigkeit der Message-IDs ist also auch in der Praxis wichtig.
Jep.
Das was du beschreibst sind die theoretischen Gefahren die sich aus nicht-eindeutigen Message-IDs ergeben.
Die Gefahren sind durchaus praxisrelevant. Es reicht ja, wenn es ein doppelte ID gibt um das Verfahren zu disqualifizieren.
Ich habe - und zwar konkret in Bezug auf die als Beispiel genannte Message-ID von Philipp Thomas - bezweifelt, dass aus der theoretischen Uneindeutigkeit auch in der Praxis einmal eine Uneindeutigkeit entstehen könnte.
Bei Philipp's ID meinte ich den domain-part und o.g. bzgl. der Gewaehrleistung (und bin dann etwas ins Allgemeine abgeschweift). Bei Philipp hab ich mich nur gewundert, warum er keinen "besseren" domain-part verwendet, z.B. das Schema das t-link.de fuer seine Nutzer definiert (AFAIK) analog zu dem von web.de, das du verwendest, irgendwas mit suse.de, und von mir kann er auch gerne einen Namespace unter meiner domain (siehe meine) fuer seine Msg-IDs bekommen.
Davids Argument, dass die Befolgung von RFCs schon ein Wert an sich ist, kann ich wiederum nachvollziehen. Allerdings würde ich dann auch damit argumentieren und nicht mit theoretisch (aber im konkreten Beispiel praktisch vermutlich unrelevanten) drohenden Gefahren.
s.o. und meine anderen Mails. Es reicht nicht, wenn die IDs in der Praxis scheinbar[1] eindeutig sind. Ich kann _garantieren_, dass die von mir generierten Msg-IDs weitweit eindeutig sind solange niemand mutwillig meine Domain missbraucht. Und selbst dann reduziert sich die Kollisionsgefahr nur auf das Niveau der IDs mit "@linux.local" als domain-part. Und gegen einen Missbrauch wuerde ich vorgehen, wenn ich davon erfahre. -dnh PS: ja, das mag alles als Pedanterie erscheinen, aber wie gesagt, bei Philipp hat mich nur der domain-part irritiert, und bin dann zu den allgemeinen Problemen mit Message-IDs abgeschweift. Eindeutige Message-IDs gehoeren nunmal zu E-Mail und News wie DNS und IPs. [1] weil die Kollisionen wohl normal nicht auffallen -- If you haven't got time to RTFM, you haven't got time to whine on this mailing list.
Hallo, On Monday 03 May 2004 02:17, David Haller wrote:
Am Sun, 02 May 2004, Hartmut Meyer schrieb: [..]
Wegen nicht-eindeutiger Message-IDs? Wenn ja, dann handelte es sich aber sicher um Message-IDs, deren Eindeutigkeit viel gründlicher sabotiert wurde als in dem Beispiel über das wir hier reden.
Wie gut die IDs von Forte sind weiss ich nicht. Wenn da aber kein "lokaler" Part enthalten ist, dann ist die Eindeutigkeit nicht gewaehrleistet. Selbst wenn gute Zufallszahlen in die ID eingehen sollten kann man es eben nicht gewaehrleisten.
Das was du beschreibst sind die theoretischen Gefahren die sich aus nicht-eindeutigen Message-IDs ergeben.
Die Gefahren sind durchaus praxisrelevant. Es reicht ja, wenn es ein doppelte ID gibt um das Verfahren zu disqualifizieren.
Schon. Die Frage ist doch nur - einen guten Zufallsgenerator für den lokalen Teil der Message-ID vorausgesetzt - wie wahrscheinlich es ist, dass eine Message-ID tatsächlich doppelt auftritt *und* auch bei mindestens einer Person zwei oder mehrere unterschiedliche Mails mit solch einer gleichen Message-IDs in der Inbox landen. Denn das irgendwo auf der Welt bei irgendeinem anderen Menschen auch noch eine identische Message-ID verwendete wurde stört mich ja nicht (außer vom Prinzip her). Schöne Grüße aus Bremen hartmut
Hartmut Meyer wrote:
On Monday 03 May 2004 02:17, David Haller wrote:
Am Sun, 02 May 2004, Hartmut Meyer schrieb: Wie gut die IDs von Forte sind weiss ich nicht. Wenn da aber kein "lokaler" Part enthalten ist, dann ist die Eindeutigkeit nicht gewaehrleistet. Selbst wenn gute Zufallszahlen in die ID eingehen sollten kann man es eben nicht gewaehrleisten.
[...] Schon. Die Frage ist doch nur - einen guten Zufallsgenerator für den lokalen Teil der Message-ID vorausgesetzt - wie wahrscheinlich es ist, dass eine Message-ID tatsächlich doppelt auftritt *und* auch bei mindestens einer Person zwei oder mehrere unterschiedliche Mails mit solch einer gleichen Message-IDs in der Inbox landen. Denn das irgendwo auf der Welt bei irgendeinem anderen Menschen auch noch eine identische Message-ID verwendete wurde stört mich ja nicht (außer vom Prinzip her).
hier kommt aber zusätzlich noch die Installationsbasis hinzu :) ich sollte Forte nur wenige Programme verkauft haben dürfte sich die Wahrscheinlichkeit zu unseren Gunsten auswirken, aber nehmen wir M$ Outlook-Express, wenn hier alle MIDs mit dem gleichen Algorithmus und der gleichen Domain generiert würden (also <[RANDOMNUMBER]@ms.com>) dann müsste der Zahlbereich für den Zufallsgenerator _sehr_ groß sein ;) Andreas
Hallo Hartmut, hallo David, hallo Leute, Am Montag, 3. Mai 2004 08:41 schrieb Hartmut Meyer:
On Monday 03 May 2004 02:17, David Haller wrote:
Am Sun, 02 May 2004, Hartmut Meyer schrieb:
Wegen nicht-eindeutiger Message-IDs? Wenn ja, dann handelte es sich aber sicher um Message-IDs, deren Eindeutigkeit viel gründlicher sabotiert wurde als in dem Beispiel über das wir hier reden. [...] Das was du beschreibst sind die theoretischen Gefahren die sich aus nicht-eindeutigen Message-IDs ergeben.
Die Gefahren sind durchaus praxisrelevant. Es reicht ja, wenn es ein doppelte ID gibt um das Verfahren zu disqualifizieren.
Schon. Die Frage ist doch nur - einen guten Zufallsgenerator für den lokalen Teil der Message-ID vorausgesetzt - wie wahrscheinlich es ist, dass eine Message-ID tatsächlich doppelt auftritt *und* auch bei mindestens einer Person zwei oder mehrere unterschiedliche Mails mit solch einer gleichen Message-IDs in der Inbox landen.
Wie bereits gesagt: Diesen Fall gab es in dieser Liste vor einiger Zeit schonmal - und die beiden Mails mit identischer ID kamen sogar am selben Tag IIRC. Jedenfalls so zeitnah, dass es aufgefallen ist. Geäußert hat sich das Problem darin, dass KMail (und vermutlich auch andere MUAs) die Antworten unter die falsche Frage geheftet hatten. Der Verursacher war IIRC ein Outlook oder Outlook Express - ein händisches Eingreifen des Mailautors würde ich also ausschließen[1] ;-)
Denn das irgendwo auf der Welt bei irgendeinem anderen Menschen auch noch eine identische Message-ID verwendete wurde stört mich ja nicht
Mich schon. Vor allem, wenn die @tux.boltz.de.vu sein sollte...
(außer vom Prinzip her).
Reicht das nicht? ;-) Gruß Christian Boltz [1] Ich habe damals nachgehakt - er war sich keiner Schuld bewusst. -- Yast ist gut, damit man als wechselnder Windowsler überhaupt erstmal ein Linux auf die Platte bekommt. Und dann, huschhusch, wir gelernt, wie das funktioniert, und dann fällt einem auch wieder ein, warum man damals von Windows wegwollte (Stichwort: Konfigurier ich dich? Oder konfigurierst du dich selbst, und zwar schlecht?), und dann was ordentliches drauf und statt Yast lieber "$EDITOR /etc/$CONFIGFILE". [Ratti in fontlinge-devel]
David Haller <david@dhaller.de> [Mo, 3 Mai 2004 02:17:12 +0200]:
Bei Philipp hab ich mich nur gewundert, warum er keinen "besseren" domain-part verwendet, z.B. das Schema das t-link.de fuer seine Nutzer definiert (AFAIK) analog zu dem von web.de, das du verwendest, irgendwas mit suse.de, und von mir kann er auch gerne einen Namespace unter meiner domain (siehe meine) fuer seine Msg-IDs bekommen.
Würde alles nichts bringen, weil sich der Forté Agent da gar nicht konfigurieren lässt, sprich keinerlei Eingriff an der Stelle zulässt. Philipp
Hallo, Am Mon, 03 May 2004, Philipp Thomas schrieb:
David Haller <david@dhaller.de> [Mo, 3 Mai 2004 02:17:12 +0200]:
Bei Philipp hab ich mich nur gewundert, warum er keinen "besseren" domain-part verwendet, z.B. das Schema das t-link.de fuer seine Nutzer definiert (AFAIK) analog zu dem von web.de, das du verwendest, irgendwas mit suse.de, und von mir kann er auch gerne einen Namespace unter meiner domain (siehe meine) fuer seine Msg-IDs bekommen.
Würde alles nichts bringen, weil sich der Forté Agent da gar nicht konfigurieren lässt, sprich keinerlei Eingriff an der Stelle zulässt.
Ach so. Das ist natuerlich doof. -dnh -- If you haven't got time to RTFM, you haven't got time to whine on this mailing list.
On Thursday 29 April 2004 07:40, Jörg Czeschla wrote:
danke für den theoretischen Hintergrund, aber wie gehe ich im alltäglichen Geschäft damit um? Ich kann doch nicht jedes Mal wenn ich auf eine Datei aus Zeiten vor 9.1 zugreife erst irgendwelche Scripte drüber laufen lassen. Das mag demjenigen Spaß machen, der Zeit dazu hat, ist doch aber völlig praxisfremd. Oder verstehe ich hier etwas falsch?
ich habe in /etc/sysconfig/language RC_LANG="de_DE.UTF-8" in RC_LANG="de_DE@euro" geändert. Gruss Robert
Hallo Robert
ich habe in /etc/sysconfig/language
RC_LANG="de_DE.UTF-8" in
RC_LANG="de_DE@euro" geändert.
komisch, das bringt bei mir nichts: im Einzelnen stellt sich das Problem folgendermaßen dar: Ich habe eine Test-Textdatei mit Umlauten unter 9.0 geschrieben und öffne sie unter 9.1 Ergebnis: Konqueror und KWrite stellen die Umlaute immer noch nicht dar. Emacs und XEmacs stellen sie dar. Das machen sie allerdings auch ohne Änderung in /etc/sysconfig/language. Hat das wohl etwas mit KDE zu tun? Gruß Jörg
Hallo, habe gar nicht gedacht, dass meine Frage so einen Auflauf verursacht. Aber schön zu wissen, dass ich nicht alleine darstehe. Am Donnerstag, 29. April 2004 20:38 schrieb Robert Seemann:
On Thursday 29 April 2004 07:40, Jörg Czeschla wrote: ich habe in /etc/sysconfig/language
RC_LANG="de_DE.UTF-8" in
RC_LANG="de_DE@euro" geändert.
Das hilft bei mir nicht. Als "normaler" User bekomme ich nachwievor LANG=de_DE.utf8 Wie sieht es denn aus, wenn ich jetzt per Skript die Dateien/Inhalte wandele. Kann ich die dann unter Suse<9.1 (oder jedem anderen *nix oder auch Windoff) so ohne weiteres Lesen/Schreiben. Oder wird da immer wieder ein Konvertierung notwendig? Bevor ich das mit meinen Dateien mache, würde ich das schon ganz gerne wissen. Suse hält sich ja auch "wunderbar" bedeckt zu diesem Thema. Mal sehen, ob sich Suse auf meine Supportanfrage diesbzgl. noch vor dem Wochenende meldet. So long Holger
Holger Biber sagte:
Hallo,
habe gar nicht gedacht, dass meine Frage so einen Auflauf verursacht. Aber schön zu wissen, dass ich nicht alleine darstehe.
Am Donnerstag, 29. April 2004 20:38 schrieb Robert Seemann:
On Thursday 29 April 2004 07:40, Jörg Czeschla wrote: ich habe in /etc/sysconfig/language
RC_LANG="de_DE.UTF-8" in
RC_LANG="de_DE@euro" geändert.
Das hilft bei mir nicht. Als "normaler" User bekomme ich nachwievor LANG=de_DE.utf8
rufst du hinterher suseconfig auf damit die /etc/profile.d/ dateien neu generiert werden, kriegst du auch wieder LANG=de_DE@euro als user. bye, MH
Hi,
rufst du hinterher suseconfig auf damit die /etc/profile.d/ dateien neu generiert werden, kriegst du auch wieder LANG=de_DE@euro als user.
nee, nee, bei mir klappts auch nicht: /etc/sysconfig/language in RC_LANG="de_DE@euro" geändert und SuSEconfig laufen lassen ergibt als user und als root echo $LANG de_DE.UTF-8 Seltsam, siehe auch Holgers Beitrag im gleichen Thread Gruß Jörg
Holger Biber <Holger.Biber@Teleos-web.de> writes:
Hallo,
habe gar nicht gedacht, dass meine Frage so einen Auflauf verursacht. Aber schön zu wissen, dass ich nicht alleine darstehe.
Am Donnerstag, 29. April 2004 20:38 schrieb Robert Seemann:
On Thursday 29 April 2004 07:40, Jörg Czeschla wrote: ich habe in /etc/sysconfig/language
RC_LANG="de_DE.UTF-8" in
RC_LANG="de_DE@euro" geändert.
Das hilft bei mir nicht. Als "normaler" User bekomme ich nachwievor LANG=de_DE.utf8
Was steht denn in den anderen RC_LC* Angaben? Vielleicht steht noch in ~/.profile export LANG=de_DE.utf-8
Wie sieht es denn aus, wenn ich jetzt per Skript die Dateien/Inhalte wandele. Kann ich die dann unter Suse<9.1 (oder jedem anderen *nix oder auch Windoff) so ohne weiteres Lesen/Schreiben. Oder wird da immer wieder ein Konvertierung notwendig?
Einmal konvertieren genügt. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Am Freitag, 30. April 2004 11:31 schrieb Dieter Kluenter:
Holger Biber <Holger.Biber@Teleos-web.de> writes:
Hallo,
Wie sieht es denn aus, wenn ich jetzt per Skript die Dateien/Inhalte wandele. Kann ich die dann unter Suse<9.1 (oder jedem anderen *nix oder auch Windoff) so ohne weiteres Lesen/Schreiben. Oder wird da immer wieder ein Konvertierung notwendig?
Einmal konvertieren genügt.
Mehr ist auch nicht so gut. Siehe Manpage. Ich habe jetzt in /etc/sysconfig/language auf "de_DE@euro" umgestellt, und anschließend "SuSEconfig" laufen lassen. OK, nun sehe ich wenigstens die Dateinamen wieder richtig. OHNE Konvertierung mit "convmv". Nur die Inhalte sind (scheinbar) immer noch UTF-8. Habe 'kile' mit einer TeX-Datei mit Umlauten aufgerufen und musste erst die Kodierung auf "UTF-8" einstellen. Komisch, denn 'echo $LANG' gibt mir korrekt "de_DE@euro" aus. Auf den ttys werden aber selbst die Dateien nicht mit Umlauten angezeigt. Bei Zugang von remote (ssh) aber wieder doch. Also da ist irgendetwas im Argen. Ich wollte eigentlich die 9.1 in meiner Schule auf gut 60 PCs installieren, so aber nicht. Tschau Holger
participants (21)
-
Al Bogner -
Andreas Loesch -
Boris -
Christian Boltz -
Christoph Maurer -
Czeschla＠t-online.de -
David Haller -
Dieter Kluenter -
Florian Brunner -
Günther Zinsberger -
Hartmut Meyer -
Helga Fischer -
Holger Biber -
Manfred Tremmel -
Mathias Homann -
peter grotz -
Philipp Thomas -
Rafael -
René Matthäi -
Robert Seemann -
Thilo Alfred Bätzig