Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.os.unix.linux.misc > #119750 > unrolled thread
| Started by | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| First post | 2021-12-11 16:27 -0500 |
| Last post | 2021-12-24 11:02 +0000 |
| Articles | 20 on this page of 396 — 37 participants |
Back to article view | Back to de.comp.os.unix.linux.misc
Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-11 16:27 -0500
Re: Crash nachverfolgen Joerg Lorenz <hugybear@gmx.ch> - 2021-12-12 03:12 +0100
Re: Crash nachverfolgen Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-12 09:34 +0000
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-12 04:47 -0500
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-12 15:39 +0100
Re: Crash nachverfolgen Christoph 'Mehdorn' Weber <spam-fuer@das-mehdorn.de> - 2021-12-12 17:50 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-12 19:42 -0500
Re: Crash nachverfolgen Joerg Lorenz <hugybear@gmx.ch> - 2021-12-13 03:22 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-13 07:44 -0500
Re: Crash nachverfolgen Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-12-12 10:27 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-12 05:25 -0500
Re: Crash nachverfolgen Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-12-12 15:55 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-12 19:36 -0500
Re: Crash nachverfolgen Thomas Hochstein <thh@thh.name> - 2021-12-12 15:51 +0100
Re: Crash nachverfolgen Markus Franzke <opa-krempel@web.de> - 2021-12-12 17:16 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-12 18:48 -0500
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-12 15:53 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-12 19:32 -0500
Re: Crash nachverfolgen Martin Schnitkemper <news.trash.5.mschnitk@spamgourmet.com> - 2021-12-13 11:28 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-13 07:40 -0500
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-19 15:02 -0500
Re: Crash nachverfolgen Juergen Ilse <news@usenet-verwaltung.de> - 2021-12-23 16:16 +0000
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-23 18:11 -0500
Re: Crash nachverfolgen Bernd Mayer <beam.bam.boom@knuut.de> - 2021-12-12 20:08 +0100
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-12 23:23 +0100
Re: Crash nachverfolgen Bernd Mayer <beam.bam.boom@knuut.de> - 2021-12-13 00:22 +0100
Re: Crash nachverfolgen Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-12-14 00:08 +0100
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-14 00:40 +0100
Re: Crash nachverfolgen Marcus Jodorf <trap@killfile.de> - 2021-12-14 21:58 +0100
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-15 02:19 +0100
Re: Crash nachverfolgen Marcus Jodorf <trap@killfile.de> - 2021-12-15 23:35 +0100
verwaiste Server (was: Crash nachverfolgen) Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-12-20 18:53 +0100
Re: verwaiste Server (was: Crash nachverfolgen) Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-21 07:25 +0100
Re: verwaiste Server Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-21 07:38 +0000
Re: verwaiste Server Joerg Lorenz <hugybear@gmx.ch> - 2021-12-21 09:13 +0100
Re: verwaiste Server Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-21 09:20 +0100
Re: verwaiste Server Paul Muster <exp-311222@news.muster.net> - 2021-12-21 10:55 +0100
Re: verwaiste Server Joerg Lorenz <hugybear@gmx.ch> - 2021-12-21 11:15 +0100
Re: verwaiste Server Laurenz Trossel <me@example.invalid> - 2021-12-21 10:27 +0000
Re: verwaiste Server Joerg Lorenz <hugybear@gmx.ch> - 2021-12-21 11:56 +0100
Re: verwaiste Server markus philippi <markusphi.news@solinetcafe.org> - 2021-12-23 19:07 +0100
Re: verwaiste Server Kay Martinen <usenet@martinen.de> - 2021-12-21 21:23 +0100
Re: verwaiste Server Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2021-12-21 21:55 +0100
Re: verwaiste Server Kay Martinen <usenet@martinen.de> - 2021-12-21 22:31 +0100
Re: verwaiste Server Marcus Jodorf <trap@killfile.de> - 2021-12-22 19:29 +0100
Re: verwaiste Server markus philippi <markusphi.news@solinetcafe.org> - 2021-12-23 19:07 +0100
Re: verwaiste Server Kay Martinen <usenet@martinen.de> - 2021-12-24 01:38 +0100
Re: verwaiste Server markus philippi <markusphi.news@solinetcafe.org> - 2021-12-24 20:16 +0100
Re: verwaiste Server Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-24 19:25 +0000
Re: verwaiste Server Paul Muster <exp-311222@news.muster.net> - 2021-12-24 21:56 +0100
Re: verwaiste Server Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-25 09:37 +0100
Re: verwaiste Server Thomas Hochstein <thh@thh.name> - 2021-12-25 09:58 +0100
Re: verwaiste Server Joerg Lorenz <hugybear@gmx.ch> - 2021-12-25 10:14 +0100
Re: verwaiste Server Thomas Hochstein <thh@thh.name> - 2021-12-25 10:30 +0100
Re: verwaiste Server Joerg Lorenz <hugybear@gmx.ch> - 2021-12-25 11:24 +0100
Re: verwaiste Server Beate Goebel <boerps@spamfence.net> - 2021-12-25 12:32 +0100
Re: verwaiste Server Joerg Lorenz <hugybear@gmx.ch> - 2021-12-25 17:52 +0100
Re: verwaiste Server Wolfgang Kynast <wky@gmx.de> - 2021-12-25 18:03 +0100
Re: verwaiste Server Joerg Lorenz <hugybear@gmx.ch> - 2021-12-25 18:12 +0100
Re: verwaiste Server Beate Goebel <boerps@spamfence.net> - 2021-12-25 18:59 +0100
Re: verwaiste Server Joerg Lorenz <hugybear@gmx.ch> - 2021-12-25 19:18 +0100
Re: verwaiste Server Beate Goebel <boerps@spamfence.net> - 2021-12-25 21:14 +0100
Re: verwaiste Server Wolfgang Kynast <wky@gmx.de> - 2021-12-26 00:02 +0100
Re: verwaiste Server Kay Martinen <usenet@martinen.de> - 2021-12-25 18:12 +0100
Re: verwaiste Server Joerg Lorenz <hugybear@gmx.ch> - 2021-12-25 19:02 +0100
Re: verwaiste Server Kay Martinen <usenet@martinen.de> - 2021-12-25 19:19 +0100
Re: verwaiste Server Joerg Lorenz <hugybear@gmx.ch> - 2021-12-25 19:26 +0100
[(E)OT] Re: verwaiste Server Kay Martinen <usenet@martinen.de> - 2021-12-25 19:46 +0100
Re: verwaiste Server Andreas Kohlbach <ank@spamfence.net> - 2021-12-25 16:49 -0500
Re: verwaiste Server "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-12-26 19:23 +0000
Re: verwaiste Server Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-26 19:49 +0000
Re: verwaiste Server Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2021-12-27 10:20 +0000
Re: verwaiste Server Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2021-12-21 10:35 +0000
Re: verwaiste Server Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-21 10:43 +0000
Re: verwaiste Server (was: Crash nachverfolgen) Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-12-22 18:36 +0100
Re: verwaiste Server Sebastian Suchanek <sebastian.suchanek@gmx.de> - 2021-12-20 20:30 +0100
Re: verwaiste Server Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-12-22 18:33 +0100
syslog-server? (was: verwaiste Server) Kay Martinen <usenet@martinen.de> - 2021-12-22 20:25 +0100
Re: syslog-server? (was: verwaiste Server) Laurenz Trossel <me@example.invalid> - 2021-12-22 23:36 +0000
Re: syslog-server? (was: verwaiste Server) Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2021-12-23 09:37 +0100
Re: syslog-server? Juergen Ilse <news@usenet-verwaltung.de> - 2021-12-23 16:27 +0000
Re: syslog-server? (was: verwaiste Server) Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2021-12-23 09:17 +0100
Re: verwaiste Server Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2021-12-23 09:05 +0100
Re: verwaiste Server Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-12-23 12:46 +0100
Re: verwaiste Server Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2021-12-23 21:30 +0100
Make or buy (was: verwaiste Server) Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-12-23 23:18 +0100
Re: Crash nachverfolgen Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-12-15 00:42 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-14 18:43 -0500
Re: Crash nachverfolgen Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-12-20 18:41 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-20 17:40 -0500
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-21 14:19 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-21 10:53 -0500
Re: Crash nachverfolgen Arno Welzel <usenet@arnowelzel.de> - 2021-12-21 17:31 +0100
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-21 18:39 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-21 13:07 -0500
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-21 20:44 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-21 20:06 -0500
Re: Crash nachverfolgen Karl Davis <me@privacy.org> - 2021-12-22 08:15 +0000
Re: Crash nachverfolgen Arno Welzel <usenet@arnowelzel.de> - 2021-12-22 11:36 +0100
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-22 17:18 +0100
Re: Crash nachverfolgen Arno Welzel <usenet@arnowelzel.de> - 2021-12-22 18:04 +0100
Re: Crash nachverfolgen Arno Welzel <usenet@arnowelzel.de> - 2021-12-21 17:26 +0100
Re: Crash nachverfolgen Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-12-22 19:18 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-22 17:03 -0500
Re: Crash nachverfolgen Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-23 09:07 +0000
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-23 08:51 -0500
Re: Crash nachverfolgen Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-23 16:42 +0000
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-23 18:08 -0500
Re: Crash nachverfolgen Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-24 12:01 +0000
Re: Crash nachverfolgen Thomas Hochstein <thh@thh.name> - 2021-12-24 13:31 +0100
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-26 15:18 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-24 09:05 -0500
Re: Crash nachverfolgen Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-24 14:35 +0000
Re: Crash nachverfolgen Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-24 14:53 +0000
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-24 16:34 -0500
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-24 16:35 -0500
Re: Crash nachverfolgen Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-24 21:41 +0000
Re: Crash nachverfolgen Arno Welzel <usenet@arnowelzel.de> - 2021-12-29 02:04 +0100
Re: Crash nachverfolgen Arno Welzel <usenet@arnowelzel.de> - 2021-12-29 02:03 +0100
Re: Crash nachverfolgen Arno Welzel <usenet@arnowelzel.de> - 2021-12-29 02:00 +0100
Re: Crash nachverfolgen Michael Brand <brandm@gmx.net> - 2021-12-23 10:42 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-23 08:25 -0500
Re: Crash nachverfolgen Bernd Mayer <beam.bam.boom@knuut.de> - 2021-12-23 14:46 +0100
Re: Crash nachverfolgen Bernd Mayer <beam.bam.boom@knuut.de> - 2021-12-23 14:49 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-23 18:06 -0500
Re: Crash nachverfolgen Bernd Mayer <beam.bam.boom@knuut.de> - 2021-12-24 01:46 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-23 20:23 -0500
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-26 17:08 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-26 12:21 -0500
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-26 16:58 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-26 12:20 -0500
Re: Crash nachverfolgen Michael Brand <brandm@gmx.net> - 2021-12-26 19:44 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-26 15:36 -0500
Re: Crash nachverfolgen Bernd Mayer <beam.bam.boom@knuut.de> - 2021-12-23 14:25 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-23 20:11 -0500
Re: Crash nachverfolgen Bernd Mayer <beam.bam.boom@knuut.de> - 2021-12-24 05:48 +0100
Re: Crash nachverfolgen Bernd Mayer <beam.bam.boom@knuut.de> - 2021-12-24 05:54 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-24 00:48 -0500
Re: Crash nachverfolgen Bernd Mayer <beam.bam.boom@knuut.de> - 2021-12-24 08:38 +0100
Re: Crash nachverfolgen "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-12-24 11:20 +0000
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-24 09:00 -0500
Re: Crash nachverfolgen Bernd Mayer <beam.bam.boom@knuut.de> - 2021-12-24 15:32 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-24 16:32 -0500
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-26 17:22 +0100
Re: Crash nachverfolgen Bernd Mayer <beam.bam.boom@knuut.de> - 2021-12-26 17:55 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-26 12:51 -0500
Re: Crash nachverfolgen Bernd Mayer <beam.bam.boom@knuut.de> - 2021-12-26 19:41 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-26 15:44 -0500
Re: Crash nachverfolgen Bernd Mayer <beam.bam.boom@knuut.de> - 2021-12-26 23:22 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-27 16:03 -0500
Re: Crash nachverfolgen Bernd Mayer <beam.bam.boom@knuut.de> - 2021-12-27 22:30 +0100
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-27 23:08 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-28 04:04 -0500
Re: Crash nachverfolgen Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-28 09:54 +0000
Re: Crash nachverfolgen Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-28 11:05 +0100
Re: Crash nachverfolgen Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-28 10:47 +0000
Re: Crash nachverfolgen Arno Welzel <usenet@arnowelzel.de> - 2021-12-29 02:37 +0100
Re: Crash nachverfolgen Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-29 08:45 +0000
Re: Crash nachverfolgen Arno Welzel <usenet@arnowelzel.de> - 2021-12-29 13:15 +0100
Re: Crash nachverfolgen Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-29 13:17 +0000
Re: Crash nachverfolgen Arno Welzel <usenet@arnowelzel.de> - 2021-12-29 19:03 +0100
Re: Crash nachverfolgen Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-29 18:47 +0000
Re: Crash nachverfolgen Arno Welzel <usenet@arnowelzel.de> - 2021-12-31 15:59 +0100
Re: Crash nachverfolgen Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-01-02 18:00 +0000
Re: Crash nachverfolgen Arno Welzel <usenet@arnowelzel.de> - 2022-01-02 19:37 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2022-01-02 22:14 -0500
Re: Crash nachverfolgen Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-01-03 07:43 +0000
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2022-01-03 12:00 -0500
Re: Crash nachverfolgen Marcus Jodorf <trap@killfile.de> - 2022-01-03 18:59 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2022-01-03 18:09 -0500
Re: Crash nachverfolgen Arno Welzel <usenet@arnowelzel.de> - 2022-01-03 18:34 +0100
Re: Crash nachverfolgen Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-01-03 18:45 +0000
MT/MU (was: Crash nachverfolgen) Kay Martinen <usenet@martinen.de> - 2022-01-03 22:40 +0100
Re: MT/MU Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-01-04 09:17 +0000
Re: MT/MU Arno Welzel <usenet@arnowelzel.de> - 2022-01-04 16:36 +0100
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-30 00:55 +0100
Re: Crash nachverfolgen Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-29 19:18 +0100
"Dramatische Umwälzungen in den 1980ern (was: Crash nachverfolgen) Andreas Kohlbach <ank@spamfence.net> - 2021-12-29 11:35 -0500
Ressourcenverbrauch (was: Crash nachverfolgen) Michael Bäuerle <michael.baeuerle@gmx.net> - 2021-12-28 12:02 +0000
Re: Ressourcenverbrauch Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-28 16:46 +0000
Re: Ressourcenverbrauch Kay Martinen <usenet@martinen.de> - 2021-12-28 18:38 +0100
Re: Ressourcenverbrauch Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-28 18:45 +0000
Re: Ressourcenverbrauch Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-28 18:51 +0000
Re: Ressourcenverbrauch Kay Martinen <usenet@martinen.de> - 2021-12-28 21:16 +0100
Re: Ressourcenverbrauch Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-28 20:33 +0000
Re: Ressourcenverbrauch Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-28 21:09 +0000
Re: Ressourcenverbrauch Kay Martinen <usenet@martinen.de> - 2021-12-28 21:13 +0100
Re: Ressourcenverbrauch Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-28 20:38 +0000
Re: Ressourcenverbrauch Arno Welzel <usenet@arnowelzel.de> - 2021-12-29 02:41 +0100
Re: Ressourcenverbrauch Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2021-12-28 17:46 +0000
Re: Ressourcenverbrauch Kay Martinen <usenet@martinen.de> - 2021-12-28 19:19 +0100
Re: Ressourcenverbrauch Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2021-12-28 21:34 +0000
Re: Ressourcenverbrauch Bernd Mayer <beam.bam.boom@knuut.de> - 2021-12-28 22:38 +0100
Re: Ressourcenverbrauch Arno Welzel <usenet@arnowelzel.de> - 2021-12-29 02:38 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-28 13:36 -0500
Re: Crash nachverfolgen Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-28 21:44 +0100
xHD (was: Crash nachverfolgen) Kay Martinen <usenet@martinen.de> - 2021-12-28 23:27 +0100
Re: xHD Arno Welzel <usenet@arnowelzel.de> - 2021-12-29 02:46 +0100
Re: xHD (was: Crash nachverfolgen) Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-29 14:54 +0100
Re: xHD (was: Crash nachverfolgen) Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2021-12-29 16:00 +0000
Re: xHD Bernd Mayer <beam.bam.boom@knuut.de> - 2021-12-29 18:55 +0100
Re: xHD Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-30 12:47 +0100
Re: xHD Arno Welzel <usenet@arnowelzel.de> - 2021-12-29 19:06 +0100
Re: xHD (was: Crash nachverfolgen) Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-29 19:39 +0100
Re: xHD Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2021-12-29 19:37 +0000
Re: xHD Marcus Jodorf <trap@killfile.de> - 2021-12-30 00:10 +0100
Re: xHD Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-30 12:56 +0100
Re: xHD Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2021-12-30 13:33 +0000
Re: xHD Michael Bäuerle <michael.baeuerle@gmx.net> - 2021-12-30 15:36 +0100
Re: xHD Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-30 15:44 +0100
Re: xHD Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2021-12-30 17:52 +0000
Re: xHD Kay Martinen <usenet@martinen.de> - 2021-12-30 20:49 +0100
Re: xHD Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2021-12-30 20:08 +0000
Re: xHD Kay Martinen <usenet@martinen.de> - 2021-12-30 21:29 +0100
Re: xHD Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2021-12-30 21:06 +0000
Re: xHD Detlef Sax <sax@noart.de> - 2021-12-30 17:32 +0000
Re: xHD Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2021-12-30 22:14 +0000
Re: xHD Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-30 23:16 +0000
Re: xHD Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2021-12-31 15:11 +0000
Re: xHD Hermann Riemann <nospam.ng@hermann-riemann.de> - 2021-12-31 16:26 +0100
Re: xHD Bernd Mayer <beam.bam.boom@knuut.de> - 2021-12-31 16:52 +0100
Re: xHD Hermann Riemann <nospam.ng@hermann-riemann.de> - 2021-12-31 17:18 +0100
Re: xHD Juergen Ilse <news@usenet-verwaltung.de> - 2021-12-31 20:05 +0000
Re: xHD Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-31 20:23 +0000
Re: xHD Hermann Riemann <nospam.ng@hermann-riemann.de> - 2022-01-01 06:47 +0100
Re: xHD Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2022-01-01 14:26 +0000
Re: xHD Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-01-01 19:43 +0100
Re: xHD Arno Welzel <usenet@arnowelzel.de> - 2022-01-02 04:55 +0100
Re: xHD Arno Welzel <usenet@arnowelzel.de> - 2022-01-02 04:54 +0100
Re: xHD Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-31 15:39 +0000
Re: xHD Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2021-12-31 15:59 +0000
Re: xHD Arno Welzel <usenet@arnowelzel.de> - 2022-01-02 04:55 +0100
Re: xHD Kay Martinen <usenet@martinen.de> - 2022-01-03 21:02 +0100
Re: xHD Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-31 02:03 +0100
Re: xHD Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2021-12-31 12:01 +0100
Re: xHD Andreas Kohlbach <ank@spamfence.net> - 2021-12-31 06:53 -0500
Re: xHD Herrand Petrowitsch <herrands@t-online.de> - 2021-12-31 13:58 +0100
Re: xHD Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2021-12-31 15:42 +0000
Re: xHD Herrand Petrowitsch <herrands@t-online.de> - 2021-12-31 16:53 +0100
Re: xHD Jens Schüßler <j.schuess@nurfuerspam.de> - 2022-01-01 00:31 +0100
Re: xHD Kay Martinen <usenet@martinen.de> - 2022-01-01 15:22 +0100
Re: xHD Detlef Sax <sax@noart.de> - 2022-01-01 16:41 +0000
Re: xHD Kay Martinen <usenet@martinen.de> - 2022-01-01 23:03 +0100
Re: xHD Detlef Sax <sax@noart.de> - 2022-01-02 09:52 +0000
Re: xHD Andreas Kohlbach <ank@spamfence.net> - 2022-01-01 15:31 -0500
Re: xHD Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-31 15:41 +0000
Re: xHD Andreas Kohlbach <ank@spamfence.net> - 2021-12-31 16:04 -0500
Re: xHD Arno Welzel <usenet@arnowelzel.de> - 2022-01-02 05:01 +0100
Re: xHD Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-12-31 20:11 +0100
Re: xHD Detlef Sax <sax@noart.de> - 2021-12-31 20:33 +0000
Re: xHD Hermann Riemann <nospam.ng@hermann-riemann.de> - 2022-01-01 06:51 +0100
Re: xHD Thomas Noll <-_tn_-@web.de> - 2022-01-01 23:59 +0000
Re: xHD Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2022-01-02 08:24 +0000
Re: xHD Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-01-02 11:25 +0100
Re: xHD Hermann Riemann <nospam.ng@hermann-riemann.de> - 2021-12-30 16:14 +0100
Re: xHD Kay Martinen <usenet@martinen.de> - 2021-12-30 20:54 +0100
Re: xHD Christian Garbs <mitch@cgarbs.de> - 2022-01-08 19:08 +0000
Re: xHD Hermann Riemann <nospam.ng@hermann-riemann.de> - 2021-12-30 16:08 +0100
Re: xHD Marcus Jodorf <trap@killfile.de> - 2021-12-31 00:40 +0100
Re: xHD Hermann Riemann <nospam.ng@hermann-riemann.de> - 2021-12-31 16:05 +0100
Re: xHD Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2021-12-30 17:45 +0000
Re: xHD Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-30 19:13 +0100
Re: xHD Sebastian Suchanek <sebastian.suchanek@gmx.de> - 2021-12-30 19:54 +0100
Re: xHD Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2021-12-30 20:07 +0000
Re: xHD Hermann Riemann <nospam.ng@hermann-riemann.de> - 2021-12-30 21:37 +0100
Re: xHD Kay Martinen <usenet@martinen.de> - 2021-12-30 21:01 +0100
Re: xHD Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-30 12:49 +0100
Re: xHD Hermann Riemann <nospam.ng@hermann-riemann.de> - 2021-12-31 16:20 +0100
Re: xHD (was: Crash nachverfolgen) Joerg Lorenz <hugybear@gmx.ch> - 2022-01-01 17:16 +0100
Re: xHD (was: Crash nachverfolgen) Laurenz Trossel <me@example.invalid> - 2022-01-02 04:44 +0000
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-28 18:24 -0500
Re: Crash nachverfolgen Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2021-12-29 00:49 +0100
Re: Crash nachverfolgen Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-29 12:27 +0100
Re: Crash nachverfolgen Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-29 11:41 +0000
Re: Crash nachverfolgen Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-29 19:32 +0100
Re: Crash nachverfolgen Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-29 18:53 +0000
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-29 22:57 +0100
Re: Crash nachverfolgen Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-29 22:24 +0000
Re: Crash nachverfolgen Arno Welzel <usenet@arnowelzel.de> - 2021-12-29 13:18 +0100
Re: Crash nachverfolgen Marcus Jodorf <trap@killfile.de> - 2021-12-29 23:03 +0100
Re: Monitore (was: Crash nachverfolgen) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2021-12-30 15:59 +0100
Re: Monitore (was: Crash nachverfolgen) Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-30 19:15 +0100
Re: Monitore (was: Crash nachverfolgen) Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2021-12-30 18:32 +0000
Re: Monitore (was: Crash nachverfolgen) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2021-12-30 20:50 +0100
Re: Monitore (was: Crash nachverfolgen) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2021-12-30 20:43 +0100
Re: Monitore Andreas Kohlbach <ank@spamfence.net> - 2021-12-30 18:08 -0500
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-28 13:18 +0100
Re: Crash nachverfolgen Bernd Mayer <beam.bam.boom@knuut.de> - 2021-12-28 14:30 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-28 14:01 -0500
Re: Crash nachverfolgen Michael Brand <brandm@gmx.net> - 2021-12-28 23:52 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-28 18:27 -0500
Re: Crash nachverfolgen Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-29 12:30 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-29 11:39 -0500
Deb'IT (was: Crash nachverfolgen) Kay Martinen <usenet@martinen.de> - 2021-12-29 22:48 +0100
Re: Deb'IT Andreas Kohlbach <ank@spamfence.net> - 2021-12-29 19:25 -0500
Re: Deb'IT (was: Crash nachverfolgen) Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-30 12:59 +0100
Re: Deb'IT (was: Crash nachverfolgen) Kay Martinen <usenet@martinen.de> - 2021-12-30 21:10 +0100
Re: Deb'IT (was: Crash nachverfolgen) Paul Muster <exp-311222@news.muster.net> - 2021-12-30 22:06 +0100
Re: Deb'IT (was: Crash nachverfolgen) Hans CraueI <crauel_usenet@freenet.de> - 2021-12-31 00:17 +0000
Re: Deb'IT (was: Crash nachverfolgen) Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-31 02:05 +0100
Re: Deb'IT Michael Brand <brandm@gmx.net> - 2022-01-01 10:34 +0100
Re: Deb'IT (was: Crash nachverfolgen) Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-31 02:05 +0100
Re: Deb'IT Andreas Kohlbach <ank@spamfence.net> - 2021-12-31 07:38 -0500
Re: Deb'IT Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-31 14:58 +0100
Re: Deb'IT Hermann Riemann <nospam.ng@hermann-riemann.de> - 2021-12-31 16:33 +0100
Re: Deb'IT Andreas Kohlbach <ank@spamfence.net> - 2021-12-31 16:35 -0500
Re: Deb'IT Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-01-01 11:04 +0100
Re: Deb'IT Andreas Kohlbach <ank@spamfence.net> - 2021-12-31 16:33 -0500
Re: Deb'IT Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-01-01 11:04 +0100
Re: Deb'IT Andreas Kohlbach <ank@spamfence.net> - 2022-01-01 08:41 -0500
Re: Deb'IT Thomas Hochstein <thh@thh.name> - 2022-01-01 15:00 +0100
Re: Deb'IT Andreas Kohlbach <ank@spamfence.net> - 2022-01-01 15:14 -0500
Re: Deb'IT Kay Martinen <usenet@martinen.de> - 2022-01-01 22:24 +0100
Re: Deb'IT Andreas Kohlbach <ank@spamfence.net> - 2022-01-01 23:22 -0500
Re: Deb'IT Thomas Hochstein <thh@thh.name> - 2022-01-01 23:04 +0100
Re: Deb'IT Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-01-02 11:30 +0100
Re: Deb'IT Kay Martinen <usenet@martinen.de> - 2022-01-03 21:43 +0100
Re: Deb'IT Thomas Hochstein <thh@thh.name> - 2022-01-03 22:19 +0100
Re: Deb'IT Kay Martinen <usenet@martinen.de> - 2022-01-03 23:18 +0100
Re: Deb'IT Thomas Hochstein <thh@thh.name> - 2022-01-04 07:54 +0100
Re: Deb'IT Kay Martinen <usenet@martinen.de> - 2022-01-05 00:48 +0100
Re: Deb'IT Thomas Hochstein <thh@thh.name> - 2022-01-05 08:18 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-28 13:53 -0500
Re: Crash nachverfolgen "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-12-26 19:17 +0000
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-26 16:57 -0500
Re: Crash nachverfolgen Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2021-12-27 11:59 +0000
Re: Crash nachverfolgen Detlef Sax <sax@noart.de> - 2021-12-27 15:22 +0000
Re: Crash nachverfolgen Detlef Sax <sax@noart.de> - 2021-12-27 15:33 +0000
Re: Crash nachverfolgen Bernd Mayer <beam.bam.boom@knuut.de> - 2021-12-27 17:18 +0100
Re: Crash nachverfolgen Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2021-12-27 18:12 +0000
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-27 17:17 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-27 16:16 -0500
Re: Crash nachverfolgen Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2021-12-27 18:18 +0000
Re: Crash nachverfolgen Detlef Sax <sax@noart.de> - 2021-12-27 18:41 +0000
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-27 16:13 -0500
Re: Crash nachverfolgen Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2021-12-27 22:01 +0000
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-28 00:27 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-28 04:30 -0500
Re: Crash nachverfolgen Bernd Mayer <beam.bam.boom@knuut.de> - 2021-12-28 12:01 +0100
Re: Crash nachverfolgen Detlef Sax <sax@noart.de> - 2021-12-28 11:19 +0000
Re: Crash nachverfolgen Marcus Jodorf <trap@killfile.de> - 2021-12-30 01:02 +0100
Re: Crash nachverfolgen Bernd Mayer <beam.bam.boom@knuut.de> - 2021-12-30 01:53 +0100
Re: Crash nachverfolgen Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2021-12-30 17:39 +0000
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-30 13:29 -0500
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-30 21:16 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-30 18:24 -0500
Re: Crash nachverfolgen Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2021-12-28 12:32 +0000
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-28 14:37 -0500
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-28 21:36 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-28 18:46 -0500
Re: Crash nachverfolgen Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2021-12-29 00:03 +0000
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-28 23:01 -0500
Re: Crash nachverfolgen Arno Welzel <usenet@arnowelzel.de> - 2021-12-29 02:53 +0100
Re: Crash nachverfolgen Marcus Jodorf <trap@killfile.de> - 2021-12-30 01:20 +0100
Re: Crash nachverfolgen Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2021-12-30 17:35 +0000
Re: Crash nachverfolgen Paul Muster <exp-311222@news.muster.net> - 2021-12-28 23:00 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-28 19:10 -0500
Re: Crash nachverfolgen Bernd Mayer <beam.bam.boom@knuut.de> - 2021-12-28 11:41 +0100
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-27 23:04 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-28 04:39 -0500
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-28 12:55 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-28 15:04 -0500
Re: Crash nachverfolgen Bernd Mayer <beam.bam.boom@knuut.de> - 2021-12-28 21:37 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-28 19:06 -0500
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-28 21:42 +0100
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-28 19:07 -0500
Re: Crash nachverfolgen Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2021-12-28 23:53 +0000
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-28 23:07 -0500
Re: Crash nachverfolgen Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2021-12-29 15:48 +0000
Re: Crash nachverfolgen Andreas Kohlbach <ank@spamfence.net> - 2021-12-29 11:46 -0500
Re: Crash nachverfolgen Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2021-12-29 17:37 +0000
Re: Crash nachverfolgen Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-29 19:34 +0100
release? (was: Crash nachverfolgen) Kay Martinen <usenet@martinen.de> - 2021-12-29 22:24 +0100
Re: release? (was: Crash nachverfolgen) Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-30 19:14 +0100
Re: Crash nachverfolgen wolfgang sch <see@sig.nature> - 2021-12-28 10:23 +0000
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-28 12:39 +0100
Re: Crash nachverfolgen Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-28 21:47 +0100
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-28 23:31 +0100
Re: Crash nachverfolgen Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2021-12-28 23:47 +0000
Re: Crash nachverfolgen Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-29 08:50 +0000
Re: Crash nachverfolgen Sebastian Suchanek <sebastian.suchanek@gmx.de> - 2021-12-29 14:34 +0100
Re: Crash nachverfolgen Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-29 18:25 +0000
Re: Crash nachverfolgen Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-29 14:47 +0100
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-29 16:46 +0100
Re: Crash nachverfolgen Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2021-12-29 17:32 +0000
Re: Crash nachverfolgen Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2021-12-29 18:30 +0000
Re: Crash nachverfolgen Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2021-12-29 19:24 +0000
Re: Crash nachverfolgen Kay Martinen <usenet@martinen.de> - 2021-12-29 22:40 +0100
Re: Crash nachverfolgen markus philippi <markusphi.news@solinetcafe.org> - 2022-01-02 11:26 +0100
Re: Crash nachverfolgen markus philippi <markusphi.news@solinetcafe.org> - 2022-01-02 11:26 +0100
Re: Crash nachverfolgen Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-29 19:37 +0100
Re: Crash nachverfolgen Marcus Jodorf <trap@killfile.de> - 2021-12-30 00:50 +0100
Re: Crash nachverfolgen markus philippi <markusphi.news@solinetcafe.org> - 2022-01-02 11:26 +0100
Re: Crash nachverfolgen Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-12-29 14:46 +0100
Re: Crash nachverfolgen markus philippi <markusphi.news@solinetcafe.org> - 2022-01-02 11:26 +0100
Re: Crash nachverfolgen "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2021-12-24 11:02 +0000
Page 5 of 20 — ← Prev page 1 … 3 4 [5] 6 7 … 20 Next page →
| From | Juergen Ilse <news@usenet-verwaltung.de> |
|---|---|
| Date | 2021-12-23 16:27 +0000 |
| Subject | Re: syslog-server? |
| Message-ID | <61c4a36b$0$32756$7b62cf90@news1.net.de> |
| In reply to | #120002 |
HAllo, Laurenz Trossel <me@example.invalid> wrote: > On 2021-12-22, Kay Martinen <usenet@martinen.de> wrote: >> Warum benutzt eigentlich niemand mehr einen syslog-server? > > Wer parsed dann die Daten? > > Logging im hier verwendeten Sinne ist mehr als nur eine Zeile in eine Datei > zu schreiben, die niemand liest. Je nach verwendetem sslog-daemon kann man syslog auch in eine Datenbank loggen lassen ... > Da gibt es Crash-Reporting, Performance-Tracking, Skalierung der > (Cloud-)Infrastruktur, Warenbestandsaufnahme. Und natürlich das Reporting > für die da Oben. Die Daten über syslog zu übertragen und wieder sinnvoll > zusamenzuführen, würde einen nicht unerheblichen Aufwand und weiteren Code > mit Bugs bedeuten. Genuegen dir die Log-Facilities nicht, um die Daten auseinander zu halten? Wie viele "Kathegorien" wuerdest du denn benoetigen? Tschuess, Juergen Ilse (juergen@usenet-verwaltung.de)
[toc] | [prev] | [next] | [standalone]
| From | Dietz Proepper <dietz-usenet@rotfl.franken.de> |
|---|---|
| Date | 2021-12-23 09:17 +0100 |
| Subject | Re: syslog-server? (was: verwaiste Server) |
| Message-ID | <20211223091707.60bf71c2.dietz-usenet@rotfl.franken.de> |
| In reply to | #119997 |
Kay Martinen <usenet@martinen.de> wrote:
> Am 22.12.21 um 18:33 schrieb Marcel Mueller:
> > Tatsächlich sogar nicht, obwohl ich nur wenige Java
> > Serveranwendungen ohne log4j kenne.
>
> Logging in java zu machen finde ich ja als solches schon eine
> Verrückte idee.
Nun, wie sonst soll eine Javasoftware sonst über
längerfristig interessante Ereignisse berichten?
[Eigene Logginglibrary]
> Nicht persönlich gemeint, aber mal allgemein gefragt:
>
> Warum benutzt eigentlich niemand mehr einen syslog-server?
Einen Grund gäbe es in Marcels (vermutetem) Setup - der syslogd auf
Windoze heißt anders und schreibt ein anderes Format.
Aber auch da - wenn man's anders braucht, dann schreibt ("kopiert") man
sich halt einen eigenen logwrited.
> So kommt's
> mir jedenfalls vor. Die meisten linux tools, systeme und daemonen
> können das doch sowieso von haus aus. Und wenn nicht kann man den
> lokalen syslog einfach umleiten. IMHO gibt's sogar eine möglichkeit
> eventlog in syslog ein zu tüten.
Ist halt "externe" Infra. Aber z.B. einen (separat gestarteten)
syslog-ng als "applikationsspezifischen" logd zu verwenden müsste schon
machbar sein.
> Aber nein. Java ist Hipp, Java ist Geil, alle Salesdroiden schwören
> drauf, das ahnungslose Management will was es will und nun ist die
> kacke wieder am dampfen. [Mein Gesamteindruck]
Nun, wenn "unser" Produkt, in Java geschrieben, nach syslog loggen soll
dann sind das zwei Zeilen in der Logging-Config.
[toc] | [prev] | [next] | [standalone]
| From | Dietz Proepper <dietz-usenet@rotfl.franken.de> |
|---|---|
| Date | 2021-12-23 09:05 +0100 |
| Subject | Re: verwaiste Server |
| Message-ID | <20211223090507.734ce8ec.dietz-usenet@rotfl.franken.de> |
| In reply to | #119993 |
Marcel Mueller <news.5.maazl@spamgourmet.org> wrote: > Am 20.12.21 um 20:30 schrieb Sebastian Suchanek: > > Thus spoke Marcel Mueller: > > > >> [...] > >> Wir hatten mittlerweile ein schlauere > >> Überwachungssoftware in Java. > >> [...] > > > > Inklusive Log4j will ich doch hoffen? > > Tatsächlich sogar nicht, obwohl ich nur wenige Java Serveranwendungen > ohne log4j kenne. Du kennst offenbar wenige ;-). Log4j ist schon sehr "klassisch". Heutzutage verwendet man eher Sachen wie logback. That being said, bei $kunde[$current-1] werden sie wohl über Weihnachten schaffet müsse' ... Und die haben vieel enterprisy Zeug. Du musst zudem zwischen slf4j (dem "API") und konkreten Implementierungen wie log4j oder logback unterscheiden. Wir hatten letzte Woche auch die Anforderung, log4j und slf4j zu entfernen. Ersteres ist schon seit mehreren Jahren nicht mehr in Verwendung, die Entfernung von letzterem konnte mittels einer kurzen Erklärung vermieden werden. > Wir hatten unsere eigene Logging-Library. Die war plattform- /und/ > sprachübergreifend, also .NET, Java, C++, VB6 (über C-DLL). Perfekt. Sowas passt dann in aller Regel nirgendwo richtig. Und meist eine Neuerfindung des Rades, aber mit 12-Eck-Rädern, einer leicht gekrümmten Achse und nur fünf Leute auf der Welt können Änderungen daran vornehmen. > Und sie war noch multitasking-safe, also mehrere Prozesse konnten ins > selbe Logfile schreiben, ohne Hackfleisch zu produzieren. Sexy. D.h. Schreiben bei einem Producer war wegen (an der Stelle vergeblicher) Synchronisation schnarchlahm um einen, wie soll man sagen, bei Anwendung elementarer best practices nicht auftretenden Fall zu mitigieren? Ich nehme mal an, das Standardrezept in dem Fall, ein separater (Sys-)logd wäre keine Option gewesen? > Das > benötigt man für bestimmte Server-Dienste, die bei Neustarts > schneller die neue Instanz hoch ziehen, als die alte sich beendet Du willst aber nicht sagen, dass Ihr eine eigene Logginglösung gebaut habt weil Inhouse-Anwendungen nicht sauber terminieren bzw. neustarten können? ;-) Made my day. > oder die auf NUMA-Server in mehreren Instanzen laufen. Nun, man schiebt die Synchonisationsentscheidung an die eine Stelle, wo sie wirklich weh tut und nennt das "Architektur(optimiert)". BTST.
[toc] | [prev] | [next] | [standalone]
| From | Marcel Mueller <news.5.maazl@spamgourmet.org> |
|---|---|
| Date | 2021-12-23 12:46 +0100 |
| Subject | Re: verwaiste Server |
| Message-ID | <sq1nj5$12irs$1@gwaiyur.mb-net.net> |
| In reply to | #120003 |
Am 23.12.21 um 09:05 schrieb Dietz Proepper: >>> Inklusive Log4j will ich doch hoffen? >> >> Tatsächlich sogar nicht, obwohl ich nur wenige Java Serveranwendungen >> ohne log4j kenne. > > Du kennst offenbar wenige ;-). Log4j ist schon sehr "klassisch". > Heutzutage verwendet man eher Sachen wie logback. That being said, bei > $kunde[$current-1] werden sie wohl über Weihnachten schaffet müsse' ... > Und die haben vieel enterprisy Zeug. Es ist schon etliche Jahre her, dass ich das letzte mal größer mit Java herum gemacht habe. >> Wir hatten unsere eigene Logging-Library. Die war plattform- /und/ >> sprachübergreifend, also .NET, Java, C++, VB6 (über C-DLL). > > Perfekt. Sowas passt dann in aller Regel nirgendwo richtig. Es passte genau auf die Anforderung. > Und > meist eine Neuerfindung des Rades, aber mit 12-Eck-Rädern, einer > leicht gekrümmten Achse und nur fünf Leute auf der Welt können > Änderungen daran vornehmen. Fakt ist, dass diese 20 Jahre alte Lösung aufgrund ihrer extremen Zuverlässigkeit der hohen Performance und des einfachen Dateiformats (CSV, tabsepariert, menschenlesbar, maschinenlesbar, Excel-kompatibel und sogar binärsicher) meines Wissens noch heute gute Dienste bei der Systemübergreifenden Überwachung hochverügbarer Prozesse und Schnittstellen tut. Vor wenigen Monaten war es jedenfalls noch so. (Ich arbeite schon länger nicht mehr dort.) Mit irgendwelchen Bibliotheken, die nur hier und da funktionieren, oder gar die Wirtsanwendung wegen irgendwelcher Fehler mit ins Grab reißen, hätten wir nichts anfangen können; mit Profilösungen für $100000 nebst nochmal so viel an Beraterkosten für die Integration auch nicht. SAP/ABAP hatte ich in der Sprach- und Platformliste übrigens vergessen. Das kam aber erst ein paar Jahre später dazu. Ich kenne nicht viele Programme, die über 20 Jahre im harten Business-Einsatz nahezu unverändert trotz sich ändernder Umgebung (Betriebssystem, Java-Versionen, .NET-Versionen etc.) klaglos ihren Dienst verrichten. Der mir bekannte Rekord lag bei 25 Jahren. Das war ein Belieferungsplan für Filialen. Ein altes Cobol-Programm, das unter Tandem NonStop lief. Das hat sogar den Wechsel auf eine komplett andere CPU-Architektur (HP) im Binärzustand (und ohne VM) überstanden. >> Und sie war noch multitasking-safe, also mehrere Prozesse konnten ins >> selbe Logfile schreiben, ohne Hackfleisch zu produzieren. > > Sexy. D.h. Schreiben bei einem Producer war wegen (an der > Stelle vergeblicher) Synchronisation schnarchlahm um einen, wie soll > man sagen, bei Anwendung elementarer best practices nicht auftretenden > Fall zu mitigieren? Logfiles sind *immer* lokal. Alles andere wäre nur ein vorprogrammierter Ausfall. Da ist ein kurzes File lock nahezu kostenlos, verglichen mit dem ohnehin erforderlichen I/O. Wenn die Daten weiter zu zentralen Servern übertragen werden sollten, dann ging das per TCP, aber immer mit lokalem File-Cache, falls die Verbindung mal hustet. Es ergibt aber nur begrenzt Sinn, Abermillionen von Ereignissen in eine Zentrale DB zu klatschen. Da kommt nur das Wichtigste rein (immer noch Millionen). Und das wird dann gemäß einem Regelwerk gefiltert, und ggf. in den Service eskaliert oder was auch immer. Bei dem Regelwerk muss jedes Ereignis gegen jede Regel geprüft werden. Das ist ein Java Programm, dass selbige Prüfung mit linearer Skalierung durchführt. Dieses Programm war von Anfang an dabei und ist nahezu unverändert. > Ich nehme mal an, das Standardrezept in dem Fall, ein separater > (Sys-)logd wäre keine Option gewesen? Nein, single point of failure war keine Option. Und Unixoide Lösungen war in dem Unternehmen seinerzeit nicht gerne gesehen. Außederm sind die syslog Files nicht zuverlässig und schnell maschinenlesbar. Und sie sind in keinster Weise differentiell lesbar, also exactly once in order, weil man nie weiß wann logrotate genau zugeschlagen hat. Das lokale Dateisystem ist halt eine Ressource mit einer bedingten Verfügbarkeit von 100%. Arbeitshypothese: wenn es nicht verfügbar ist, läuft das Programm dessen Ereignisse es zu protokollieren gilt, auch nicht. Aber bereits ein eigener Dienst könnte abstürzen, nicht erreichbar sein oder was auch immer. Was macht man dann mit den Timeouts, die man nicht sinnvoll behandeln kann? >> Das >> benötigt man für bestimmte Server-Dienste, die bei Neustarts >> schneller die neue Instanz hoch ziehen, als die alte sich beendet > > Du willst aber nicht sagen, dass Ihr eine eigene Logginglösung gebaut > habt weil Inhouse-Anwendungen nicht sauber terminieren bzw. neustarten > können? ;-) Die Anwendung nennt sie Microsoft IIS. Der macht komische Dinge. Das war natürlich kein hochverfügbarer Teil. Aber wir haben überall dieselben Bibliotheken genutzt. >> oder die auf NUMA-Server in mehreren Instanzen laufen. > > Nun, man schiebt die Synchonisationsentscheidung an die eine Stelle, wo > sie wirklich weh tut und nennt das "Architektur(optimiert)". BTST. So viel loggt eine IIS Anwendung nun auch nicht. Selbstverständlich waren die multitasking-sicheren Logfiles ein optionales Feature, was man nicht wahllos aktiviert hat. Einen wahrnehmbaren Performanceunterschied gab es allerdings auch nicht. Messen hätte man ihn wahrscheinlich können, aber wen interessiert das? Marcel
[toc] | [prev] | [next] | [standalone]
| From | Dietz Proepper <dietz-usenet@rotfl.franken.de> |
|---|---|
| Date | 2021-12-23 21:30 +0100 |
| Subject | Re: verwaiste Server |
| Message-ID | <20211223213032.6b777083.dietz-usenet@rotfl.franken.de> |
| In reply to | #120008 |
Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:
> Am 23.12.21 um 09:05 schrieb Dietz Proepper:
> >>> Inklusive Log4j will ich doch hoffen?
> >>
> >> Tatsächlich sogar nicht, obwohl ich nur wenige Java
> >> Serveranwendungen ohne log4j kenne.
> >
> > Du kennst offenbar wenige ;-). Log4j ist schon sehr "klassisch".
> > Heutzutage verwendet man eher Sachen wie logback. That being said,
> > bei $kunde[$current-1] werden sie wohl über Weihnachten schaffet
> > müsse' ... Und die haben vieel enterprisy Zeug.
>
> Es ist schon etliche Jahre her, dass ich das letzte mal größer mit
> Java herum gemacht habe.
Dacht' ichs mir.
> >> Wir hatten unsere eigene Logging-Library. Die war plattform- /und/
> >> sprachübergreifend, also .NET, Java, C++, VB6 (über C-DLL).
> >
> > Perfekt. Sowas passt dann in aller Regel nirgendwo richtig.
>
> Es passte genau auf die Anforderung.
Siehe unten.
> > Und
> > meist eine Neuerfindung des Rades, aber mit 12-Eck-Rädern, einer
> > leicht gekrümmten Achse und nur fünf Leute auf der Welt können
> > Änderungen daran vornehmen.
>
> Fakt ist, dass diese 20 Jahre alte Lösung aufgrund ihrer extremen
> Zuverlässigkeit
Ich wüsste nicht, wann die üblichen Loggingframeworks in Java, Python,
php, c/c++ etc irgendwann mal wirklich unzuverlässig gewesen wären.
> der hohen Performance
To sync or not to sync, that's the question here. Logschreiben ist
jetzt wirklich nichts, was besondere Anforderungen an Performance
stellt. Bzw. die Fehler passieren üblicherweise anwenderseitig.
("Diiietz, warum ruft der bei 'log.debug(teureGenerierung())' die
Generierung?")
> und des einfachen Dateiformats
> (CSV, tabsepariert,
Ja, kann man machen. Aber /warum/ sollte man Logs als CSV generieren ...
> menschenlesbar,
... das ist *nicht* lesbar, sorry.
> maschinenlesbar, Excel-kompatibel
Umm, die meisten Logs die ich kenne sind trivial regexp-parsebar. Dort,
wo man CSV sinnbringend einsetzen kann geht es eher um Monitoring
("Performance-Logging").
> und sogar binärsicher)
D.h. 7bit-ASCII ... Ja, schei? Umlaute ;-).
> meines Wissens noch heute gute Dienste bei der
> Systemübergreifenden Überwachung hochverügbarer Prozesse und
> Schnittstellen tut. Vor wenigen Monaten war es jedenfalls noch so.
Klar. Ich habe auch schon viele exotische Lösungen gemacht, gesehen und
verflucht. Aber seit deutlich über 10a - nimm' eine OTS-(idealerweise
OS-)Lösung und schreib' Dir ein wenig glue. Das ist auf jeden Fall um
Faktor 5+ günstiger als alles selbergebaute. Und *wenn* es wirklich
nicht performt oder unzuverlässig ist, dann kann man zwei von fünf
Kostenfaktoren ans (OS-)Originalprojekt zurück spenden. Dann performt
das auch und alle haben was von der gewonnenen Zuverlässigkeit ...
> Mit irgendwelchen Bibliotheken, die nur hier und da funktionieren,
Komisch. Sowas erlebe ich in aller Regel bei selber neu erfundenen
Rädern.
> oder gar die Wirtsanwendung wegen irgendwelcher Fehler mit ins Grab
> reißen, hätten wir nichts anfangen können;
Ihr habt lieber NIH gespielt. Klar. Aber Frage - war das vor 2005?
> mit Profilösungen für
> $100000 nebst nochmal so viel an Beraterkosten für die Integration
> auch nicht.
Oh, die sind nur dann interessant wenn man sie selber verkauft.
> SAP/ABAP hatte ich in der Sprach- und Platformliste übrigens
> vergessen. Das kam aber erst ein paar Jahre später dazu.
Ui. Auch für z/OS? (Ich kann auch Buzzwords.)
> Ich kenne nicht viele Programme, die über 20 Jahre im harten
> Business-Einsatz nahezu unverändert trotz sich ändernder Umgebung
> (Betriebssystem, Java-Versionen, .NET-Versionen etc.) klaglos ihren
> Dienst verrichten.
Kein Bug in der Zeit? Keine Updates?
> Der mir bekannte Rekord lag bei 25 Jahren. Das war
> ein Belieferungsplan für Filialen. Ein altes Cobol-Programm, das
> unter Tandem NonStop lief. Das hat sogar den Wechsel auf eine
> komplett andere CPU-Architektur (HP) im Binärzustand (und ohne VM)
> überstanden.
Oh, mein persönlicher Rekord liegt bei ca. 18a. 1996 habe ich bei der
DATEV mal eine View für (iirc) eine Suche geschrieben. Dynamische
Parameter, mit dynamischer Anpassung des Layouts, unter Windoze. Das
war damals noch höhere Magie ;-). Der Algorithmus für die Anpassung der
Elemente im View hatte einen kleinen Bug, alle 28 Pixel Größe nach
rechts ist er um vier gesprungen, zurück nicht. Meine Steuerfrau hatte
die entsprechende Software in Verwendung und der Bug war erst 2015 (da
ward die Software in Web migriert) nicht mehr da (jährliches
Zeremoniell, "Herr Pröpper, die Felder springen noch").
> >> Und sie war noch multitasking-safe, also mehrere Prozesse konnten
> >> ins selbe Logfile schreiben, ohne Hackfleisch zu produzieren.
> >
> > Sexy. D.h. Schreiben bei einem Producer war wegen (an der
> > Stelle vergeblicher) Synchronisation schnarchlahm um einen, wie soll
> > man sagen, bei Anwendung elementarer best practices nicht
> > auftretenden Fall zu mitigieren?
>
> Logfiles sind *immer* lokal.
Was hat das mit meiner Ansage zu tun?
> Alles andere wäre nur ein vorprogrammierter Ausfall.
Du schwätzt.
> Da ist ein kurzes File lock nahezu kostenlos,
Schon klar. Wenn man zwei oder drei Producer hat. Sonst löst man das
*innerhalb* der Software. File Locks sind scheißteuer und höchst
unportabel.
> verglichen mit dem ohnehin erforderlichen I/O.
Is' klar. Logging-IO ist der klassische Lasterzeuger ...
> > Ich nehme mal an, das Standardrezept in dem Fall, ein separater
> > (Sys-)logd wäre keine Option gewesen?
>
> Nein, single point of failure war keine Option.
Those who do not understand logging ...
> > Du willst aber nicht sagen, dass Ihr eine eigene Logginglösung
> > gebaut habt weil Inhouse-Anwendungen nicht sauber terminieren bzw.
> > neustarten können? ;-)
>
> Die Anwendung nennt sie Microsoft IIS. Der macht komische Dinge.
> Das war natürlich kein hochverfügbarer Teil. Aber wir haben überall
> dieselben Bibliotheken genutzt.
Is' klar. Und dafür habt ihr damals Logging für alles und jeden gebaut.
Aber lassen wir das. Es wird langweilig.
[toc] | [prev] | [next] | [standalone]
| From | Marcel Mueller <news.5.maazl@spamgourmet.org> |
|---|---|
| Date | 2021-12-23 23:18 +0100 |
| Subject | Make or buy (was: verwaiste Server) |
| Message-ID | <sq2skf$14mor$1@gwaiyur.mb-net.net> |
| In reply to | #120022 |
Am 23.12.21 um 21:30 schrieb Dietz Proepper:
>>> Und
>>> meist eine Neuerfindung des Rades, aber mit 12-Eck-Rädern, einer
>>> leicht gekrümmten Achse und nur fünf Leute auf der Welt können
>>> Änderungen daran vornehmen.
>>
>> Fakt ist, dass diese 20 Jahre alte Lösung aufgrund ihrer extremen
>> Zuverlässigkeit
>
> Ich wüsste nicht, wann die üblichen Loggingframeworks in Java, Python,
> php, c/c++ etc irgendwann mal wirklich unzuverlässig gewesen wären.
Sie sind halt nicht übergreifend kompatibel.
>> und des einfachen Dateiformats
>> (CSV, tabsepariert,
>
> Ja, kann man machen. Aber /warum/ sollte man Logs als CSV generieren ...
>
>> menschenlesbar,
>
> ... das ist *nicht* lesbar, sorry.
Viele Programme können mit Tab als Trennzeichen ganz gut umgehen. Und
wenn die Freitextspalte ganz hinten ist, umso besser.
>> maschinenlesbar, Excel-kompatibel
>
> Umm, die meisten Logs die ich kenne sind trivial regexp-parsebar. Dort,
> wo man CSV sinnbringend einsetzen kann geht es eher um Monitoring
> ("Performance-Logging").
Das war bei uns alles in einem, wobei Performance eher nachgelagert
statistisch relevant war. Also wie lange hat Vorgang X im letzten
viertel Jahr im Mittel gebraucht und wie breit ist die Lognormalverteilung.
>> und sogar binärsicher)
>
> D.h. 7bit-ASCII ... Ja, schei? Umlaute ;-).
Nein, binärsicher. Der Test waren Executables in der Freitext-Spalte.
Die mussten danach noch binär identisch sein. - Natürlich keine
Anforderung, nur ein harter Testfall. Escaped wurden CSV-üblich nur
Gänsefüßchen.
>> meines Wissens noch heute gute Dienste bei der
>> Systemübergreifenden Überwachung hochverügbarer Prozesse und
>> Schnittstellen tut. Vor wenigen Monaten war es jedenfalls noch so.
>
> Klar. Ich habe auch schon viele exotische Lösungen gemacht, gesehen und
> verflucht.
Verfluchen geht immer schnell. Am Ende geht es nur darum, dass man es
nicht kennt.
Das wiederum ist eine organisatorische Aufgabe des Unternehmens. Wenn
man selber gestricktes Zeug einsetzt, noch dazu im Bereich von
Hochverfügbarkeit, muss man geeignete Maßnahmen ergreifen, um das
Know-How im Haus zu sichern. Die berühmte Regel ist: einer ist krank,
einer in Urlaub und der dritte macht's.
Ob das ökonomisch ist, hängt primär davon ab, wie oft man das Wissen
braucht, also indirekt davon, wie groß der Laden ist.
> Aber seit deutlich über 10a - nimm' eine OTS-(idealerweise
> OS-)Lösung und schreib' Dir ein wenig glue. Das ist auf jeden Fall um
> Faktor 5+ günstiger als alles selbergebaute.
Nein. Auf diese Frage gibt es keine pauschale Antwort.
Nach meiner Erfahrung steigt der Projektaufwand für "Glue" seit vielen
Jahren stetig an. Das hat eine rein statistische Ursache.
Für Standardprobleme gibt es Standardlösungen. Da man die nicht für
jeden Kunden entwickeln muss, sondern nur einen festen Overhead von
vielleicht Faktor 3 hat, können sich Kunden und Anbieter den
Synergieeffekt teilen.
Allerdings setzt Kunde A das Tool X in Kombination mit Y ein, wohingegen
Kunde B X mit Z kombiniert. Deshalb hängt der "Glue" an der
Paarkorrelation, und der Aufwand dafür wächst in Summe quadratisch mit
der Zahl der existierenden Lösungen. Dabei gibt es nur für sehr häufige
Kombinationen noch Synergieeffekte. Und selbst das funktioniert oft
nicht, da die Prozesse und deren Abbildung auf die Möglichkeiten der
Einzellösungen kundenindividuell sind. Das würde nur gehen, wenn die
Kunden die Prozesse an den Produkten ausrichten - wer hat das wirklich
schon einmal erlebt? Also mehr als nur als Lippenbekenntnis. Das nimmt
einem zudem die Möglichkeit sich noch vom Wettbewerb zu differenzieren.
Natürlich muss nicht jeder die Rechnungsprüfung individuell durchführen.
Aber in einigen Bereichen will man schon eigene (idealerweise bessere)
Wege gehen. Auch davon hängt also Make or buy ab. Bei buy bekommt man
Neuerungen immer erst 2 Jahre nachdem die großen Konkurrenten, die den
Anbieter treiben, sie im Einsatz haben.
Alternativ zu Individualschnittstellen hat man nur die Chance, alles aus
einer Hand zu kaufen. Das wiederum bedeutet aber, dass man nur im
Bereich der Kernkompetenz des Anbieters eine gute Lösung hat. Abseits
davon muss man sich oft mit drittklassigen Lösungen herum schlagen, die
oft sogar noch schlecht integriert sind, weil der Anbieter sie selbst
nur zugekauft und sein Bapperl drauf geklebt hat. Die
Entscheidungsträger tun sich oft schwer, das zu differenzieren oder
lassen sich da gar um den Finger wickeln.
> Und *wenn* es wirklich
> nicht performt oder unzuverlässig ist, dann kann man zwei von fünf
> Kostenfaktoren ans (OS-)Originalprojekt zurück spenden. Dann performt
> das auch und alle haben was von der gewonnenen Zuverlässigkeit ...
Manche Anbieter spielen da gut mit, andere nicht.
Faustformel: wenn der Anbieter kleiner ist, als man selbst, klappt es
gut. Aber Ausnahmen bestätigen definitiv die Regel.
>> Mit irgendwelchen Bibliotheken, die nur hier und da funktionieren,
>
> Komisch. Sowas erlebe ich in aller Regel bei selber neu erfundenen
> Rädern.
Auch das gilt nicht pauschal. Es kommt vor allem darauf an, wer die
Konzepte macht, und vor allem wie sein Auftrag war. Wenn da nur
"schnell, schnell" auf der Liste steht, kann man es gleich vergessen.
Bei Unternehmen, die langfristig nachhaltig wirtschaften, gibt es aber
eben auch gute Rahmenbedingungen.
>> oder gar die Wirtsanwendung wegen irgendwelcher Fehler mit ins Grab
>> reißen, hätten wir nichts anfangen können;
>
> Ihr habt lieber NIH gespielt. Klar. Aber Frage - war das vor 2005?
Ja, definitiv. Aber warum?
>> mit Profilösungen für
>> $100000 nebst nochmal so viel an Beraterkosten für die Integration
>> auch nicht.
>
> Oh, die sind nur dann interessant wenn man sie selber verkauft.
:-)
>> SAP/ABAP hatte ich in der Sprach- und Platformliste übrigens
>> vergessen. Das kam aber erst ein paar Jahre später dazu.
>
> Ui. Auch für z/OS? (Ich kann auch Buzzwords.)
Nein, von IBM war nur WebSphere MQ alias MQSeries beteiligt. :-)
Aber ich habe noch eine Sprache vergessen. Für Perl haben wir später
auch nochmal eine Integration geschrieben. Das wurde für irgendeine
Nagios-Skriptlösung gebraucht. Zu der Zeit war Linux nicht mehr so böse. ;-)
>> Ich kenne nicht viele Programme, die über 20 Jahre im harten
>> Business-Einsatz nahezu unverändert trotz sich ändernder Umgebung
>> (Betriebssystem, Java-Versionen, .NET-Versionen etc.) klaglos ihren
>> Dienst verrichten.
>
> Kein Bug in der Zeit? Keine Updates?
Es gab einen (relevanten) Bug. Die Implementierung für die
Schaltjahresberechnung hat die Ausnahme im Jahr 2000 irrtümlich im Jahr
2004 angewendet. Dadurch gab es eine kritische Störung am 29.02.2004.
Das war tatsächlich ein dummer Fehler beim selber machen. Aber aufgrund
der sehr Plattformen war es eben auch schwierig, die jeweiligen
Systembibliotheken für solche Sachen einzubinden.
Eine andere Störung war nicht ursächlich in der Software. Die
allermeisten Komponenten für das Zusammenführen der Informationen waren
redundant ausgelegt. (Auch die Java-Anwendung) Irgendwann ist auf einem
Server eine Instanz ausgefallen. Dummerweise war dafür keinerlei
Überwachung eingerichtet worden. Deshalb lief erst mal alles weiter. Der
Fehler ist erst 4 oder 5 Jahre später aufgefallen, als auch das zweite
System in denselben Fehler lief, was zu einem Ausfall führte.
Auslöser war ein Fehler im SQL-Server Treiber, der bei bestimmten
Zugriffsszenarien unter anhaltend hoher Last extreme
Performanceeinbrüche zur Folge hatte, wenn auf der Zieltabelle Trigger
eingerichtet waren. Dabei ist der Durchsatz um mehrere Zehnerpotenzen
gefallen wodurch über Jahre mehr Daten an die Instanz rein gelaufen
sind, als sie abfertigen konnte. Alle Ereignisse wurden in lokalen
Dateien gepuffert. Da das aber noch eher in der Anfangszeit war, hat es
nicht gereicht, um die reichlich bemessenen Volumes zum Überlaufen zu
bringen.
Als Work-around wurde der DB-Trigger durch einen Batch-Prozess ersetzt.
Damit waren die Daten zwar nicht mehr 100% aktuell, aber das war an der
Stelle nicht kritisch.
Irgendwann nach vielleicht 12 Jahren gab es mal ein Feature-Update. Aber
nichts, was das Konzept größer in Frage gestellt hätte.
>> Da ist ein kurzes File lock nahezu kostenlos,
>
> Schon klar. Wenn man zwei oder drei Producer hat. Sonst löst man das
> *innerhalb* der Software. File Locks sind scheißteuer und höchst
> unportabel.
Naja, da das einzelne File immer nur auf /einer/ Plattform liegen kann,
ist die Portabilität nur bedingt relevant. Aber in der Tat erforderte
dieser Teil ein paar Anpassungen, weil nicht jede
Sprache/Laufzeitbibliothek alle Kernel-Features offeriert.
>>> Du willst aber nicht sagen, dass Ihr eine eigene Logginglösung
>>> gebaut habt weil Inhouse-Anwendungen nicht sauber terminieren bzw.
>>> neustarten können? ;-)
>>
>> Die Anwendung nennt sie Microsoft IIS. Der macht komische Dinge.
>> Das war natürlich kein hochverfügbarer Teil. Aber wir haben überall
>> dieselben Bibliotheken genutzt.
>
> Is' klar. Und dafür habt ihr damals Logging für alles und jeden gebaut.
Nein. Primäres Ziel war die Ende zu Ende Überwachung hochverfügbarer
Schnittstellen zwischen Systemen ganz verschiedener Anbieter und
Architekturen. Im besonderen NonsStop-Kernel mit Pathway war schon
ziemlich ab von anderen Architekturen.
Aber man hat schon beim Konzept dafür gemerkt, dass sich die Lösung für
viel mehr eignet. Und deshalb wurde recht schnell auch die Überwachung
von Server-Diensten und auch diversen Anwendungen integriert.
> Aber lassen wir das. Es wird langweilig.
Na denn.
Marcel
[toc] | [prev] | [next] | [standalone]
| From | Marcel Mueller <news.5.maazl@spamgourmet.org> |
|---|---|
| Date | 2021-12-15 00:42 +0100 |
| Message-ID | <spba4c$1ge88$1@gwaiyur.mb-net.net> |
| In reply to | #119845 |
Am 14.12.21 um 00:40 schrieb Kay Martinen: >> Das ist bei meinem NB genauso. Der überlebt hunderte Suspends am Stück >> (mehrfach pro Tag). > > Hier Dito. Auf mindestens zwei Systemen. Uptime-zähler von 20d sind > keine Seltenheit - wenn nicht ein Kernel-update dazwischenfährt. Mit Live-Patch gehen auch 400. > Ich denke man kann schon sagen das übliche Notebooks nicht für > Dauerbetrieb gebaut sind. Business-Geräte mögen da anders/Besser > optimiert sein aber 24/7 wie ein Server erfordert m.E. doch noch mehr > einsatz. Und ob Suspend das aufwiegt mag ich nicht recht glauben weil > das wieder Wechselbelastung mit sich bringt. Da gibt es wenig systematische Korrelationen, auch nicht mit Business-Class. Manche packen es, andere nicht. Die ersten Raspis waren auch für alles andere als Dauerbetrieb ausgelegt und überstehen bekanntermaßen Jahre ohne Reboot. Marcel
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| Date | 2021-12-14 18:43 -0500 |
| Message-ID | <87tufa3g7s.fsf@usenet.ankman.de> |
| In reply to | #119845 |
On Tue, 14 Dec 2021 00:40:35 +0100, Kay Martinen wrote: > > Ich denke man kann schon sagen das übliche Notebooks nicht für > Dauerbetrieb gebaut sind. Ich meine, dass ein 24/7 Betrieb der Elektronik über Jahr weniger, als zweimaliges An- und Ausschalten am Tag schadet. -- Andreas
[toc] | [prev] | [next] | [standalone]
| From | Marcel Mueller <news.5.maazl@spamgourmet.org> |
|---|---|
| Date | 2021-12-20 18:41 +0100 |
| Message-ID | <spqf7r$9sc5$1@gwaiyur.mb-net.net> |
| In reply to | #119868 |
Am 15.12.21 um 00:43 schrieb Andreas Kohlbach: > On Tue, 14 Dec 2021 00:40:35 +0100, Kay Martinen wrote: >> >> Ich denke man kann schon sagen das übliche Notebooks nicht für >> Dauerbetrieb gebaut sind. > > Ich meine, dass ein 24/7 Betrieb der Elektronik über Jahr weniger, als > zweimaliges An- und Ausschalten am Tag schadet. Kommt sehr darauf an. Bei Flexing könnte es passen. Bei Elkoinsuffizienz sicher nicht. Da zählt die nackte Betriebsdauer unter Last. Marcel
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| Date | 2021-12-20 17:40 -0500 |
| Message-ID | <874k72j3wy.fsf@usenet.ankman.de> |
| In reply to | #119955 |
On Mon, 20 Dec 2021 18:41:16 +0100, Marcel Mueller wrote: > > Am 15.12.21 um 00:43 schrieb Andreas Kohlbach: >> On Tue, 14 Dec 2021 00:40:35 +0100, Kay Martinen wrote: >>> >>> Ich denke man kann schon sagen das übliche Notebooks nicht für >>> Dauerbetrieb gebaut sind. >> Ich meine, dass ein 24/7 Betrieb der Elektronik über Jahr weniger, >> als >> zweimaliges An- und Ausschalten am Tag schadet. > > Kommt sehr darauf an. Bei Flexing könnte es passen. Ich hätte den Computer wohl (fälschlicherweise) mit einer (alten) Glühbirne verglichen, der häufiges Ein- und Ausschalten sehr schadet (AFAIK). Scheint für LED nicht mehr zu gelten. Aber meinen Computer habe ich länger im Einsatz, als der Zeitpunkt, an dem sich LEDs durchsetzten. ;-) > Bei Elkoinsuffizienz sicher nicht. Da zählt die nackte Betriebsdauer > unter Last. Zu Elkoinsuffizienz finde ich nicht viel bei Oma Google, vermute aber, dass der Verschleiß von Elektrolytkondensatoren gemeint ist. Meiner wird in sieben Tagen neun Jahre alt. Seit drei oder vier Jahren habe ich ihn wegen der Annahme oben 24/7 laufen. Hoffentlich macht er noch wenigsten bis dahin, wenn ich Ersatz beschaffen kann. -- Andreas
[toc] | [prev] | [next] | [standalone]
| From | Kay Martinen <usenet@martinen.de> |
|---|---|
| Date | 2021-12-21 14:19 +0100 |
| Message-ID | <5r099i-dfo.ln1@news.martinen.de> |
| In reply to | #119958 |
Am 20.12.21 um 23:40 schrieb Andreas Kohlbach: > On Mon, 20 Dec 2021 18:41:16 +0100, Marcel Mueller wrote: >> >> Am 15.12.21 um 00:43 schrieb Andreas Kohlbach: >>> On Tue, 14 Dec 2021 00:40:35 +0100, Kay Martinen wrote: >>>> >>>> Ich denke man kann schon sagen das übliche Notebooks nicht für >>>> Dauerbetrieb gebaut sind. >>> Ich meine, dass ein 24/7 Betrieb der Elektronik über Jahr weniger, >>> als >>> zweimaliges An- und Ausschalten am Tag schadet. >> >> Kommt sehr darauf an. Bei Flexing könnte es passen. > > Ich hätte den Computer wohl (fälschlicherweise) mit einer (alten) > Glühbirne verglichen, der häufiges Ein- und Ausschalten sehr schadet > (AFAIK). Scheint für LED nicht mehr zu gelten. Hat m.E. für LEDs *nie* gegolten! Glühlampen (Birnen gibt's im Obstladen) haben einen Wolfram-Doppelwendel als Leuchtdraht. Dessen ca. 3000°C im Betrieb sind der Hauptstressfaktor durch Temperatur-ausdehnung des Materials. Anzeige-LEDs werden nicht warm und es gibt nur sehr wenig was sich dort ausdehnen könnte da es außerdem im Kunststoffgehäuse vergossen ist. > Aber meinen Computer habe ich länger im Einsatz, als der Zeitpunkt, an > dem sich LEDs durchsetzten. ;-) Stattlich. Die ersten LEDs in Massenproduktion soll es 1962 von Monsanto gegeben haben. Und wenn die sich nicht rasch durchgesetzt hätten dann wären Taschenrechner und Digitaluhren damit wohl kaum zu meiner Schulzeit kaufbar gewesen. Folglich must du deinen Computer seit über 40 Jahren im Einsatz haben... ... du bist hier falsch. Bitte komm nach d.a.f.c. da sind solche Dampfbetriebenen Oldtimer an der Tagesordnung. :-) >> Bei Elkoinsuffizienz sicher nicht. Da zählt die nackte Betriebsdauer >> unter Last. > > Zu Elkoinsuffizienz finde ich nicht viel bei Oma Google, vermute aber, > dass der Verschleiß von Elektrolytkondensatoren gemeint ist. Der Faktor ist die Temperatur die das Elektrolyt im Elektrolyt-Kondensator über die Zeit schwinden lässt. Das führt zu schwindender Kapazität und anderen Effekten die eigentlich alle von Übel sind. Wenn die kreuzförmigen Kerben am Deckel des Elkobechers schon aufgebeult sind ist es Zeit die zu wechseln. Danach... PENG! Totalausfall! > Meiner wird in sieben Tagen neun Jahre alt. Seit drei oder vier Jahren > habe ich ihn wegen der Annahme oben 24/7 laufen. Hoffentlich macht er > noch wenigsten bis dahin, wenn ich Ersatz beschaffen kann. Der annahme ein Komplexes Digitales Gerät verhielte sich wie eine Glühlampe...??? Ich hab grad einen Stack-overflow im Kann-dir-nicht-folgen-Sektor. :-) Ｂｙｅ／ ／Ｋａｙ -- 🅟🅞🅢🅣🅔🅓 🅥🅘🅐 🅛🅔🅐🅕🅝🅞🅓🅔
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| Date | 2021-12-21 10:53 -0500 |
| Message-ID | <87y24egdiz.fsf@usenet.ankman.de> |
| In reply to | #119972 |
On Tue, 21 Dec 2021 14:19:01 +0100, Kay Martinen wrote: > > Am 20.12.21 um 23:40 schrieb Andreas Kohlbach: >> >> Ich hätte den Computer wohl (fälschlicherweise) mit einer (alten) >> Glühbirne verglichen, der häufiges Ein- und Ausschalten sehr schadet >> (AFAIK). Scheint für LED nicht mehr zu gelten. > > Hat m.E. für LEDs *nie* gegolten! Das wollte ich mit der Aussage nicht ausschließen. > Glühlampen (Birnen gibt's im Obstladen) haben einen Wolfram-Doppelwendel > als Leuchtdraht. Die gibt es in D noch zu kaufen? War eben in der Drogerie (wo sonst wollte man Leuchtkörper kaufen? ;-), da gab es nur LED und andere "Stromsparer". Keine mehr mit Leuchtdraht. Interessant hier die Wohnung, wo ich seit sieben Jahren wohne. Im Badezimmer zwei Birnen. Die eine brannte vor fünf Jahren durch; habe ich durch eine dieser "Spiralen" ersetzt. Die andere ist noch mit Glühfaden (wer weiß, wie lange die vor mir drin war). Beide gehen immer noch, trotz drei bis viermaligem Ein- und Ausschalten am Tag. > Dessen ca. 3000°C im Betrieb sind der Hauptstressfaktor durch > Temperatur-ausdehnung des Materials. Anzeige-LEDs werden nicht warm und > es gibt nur sehr wenig was sich dort ausdehnen könnte da es außerdem im > Kunststoffgehäuse vergossen ist. Meine Vermutung war, auch Kondensatoren sind dafür empfänglich. Und erledigen wenig später ihre eigentliche Aufgabe, aus der sie ihren Namen haben. Sie kondensieren stinkend. ;-) >> Aber meinen Computer habe ich länger im Einsatz, als der Zeitpunkt, an >> dem sich LEDs durchsetzten. ;-) > > Stattlich. Die ersten LEDs in Massenproduktion soll es 1962 von Monsanto > gegeben haben. Und wenn die sich nicht rasch durchgesetzt hätten dann > wären Taschenrechner und Digitaluhren damit wohl kaum zu meiner > Schulzeit kaufbar gewesen. > > Folglich must du deinen Computer seit über 40 Jahren im Einsatz haben... Ich schrieb "durchsetzten". Das dürfte <7 Jahre sein, seitdem man sie en Masse in den Regalen (von Drogerien und Obstläden) findet. > ... du bist hier falsch. Bitte komm nach d.a.f.c. da sind solche > Dampfbetriebenen Oldtimer an der Tagesordnung. :-) Ich mag keine alte Hardware, außer sie ist von vor 1988. Dass ich meine Dampfmaschine noch benutzen muss, liegt ziemlich außer meiner Kontrolle. :-( [...] >> Meiner wird in sieben Tagen neun Jahre alt. Seit drei oder vier Jahren >> habe ich ihn wegen der Annahme oben 24/7 laufen. Hoffentlich macht er >> noch wenigsten bis dahin, wenn ich Ersatz beschaffen kann. > > Der annahme ein Komplexes Digitales Gerät verhielte sich wie eine > Glühlampe...??? Ich hab grad einen Stack-overflow im > Kann-dir-nicht-folgen-Sektor. :-) Als Nicht-Techniker ging ich davon aus, dass jedes elektrische Gerät kein Einschalten mag, war auf einmal (Huch!) Strom fließt. Zuerst viel (falls der Impuls nicht abgefangen wird), und dann kommen thermische Probleme dazu. -- Andreas
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2021-12-21 17:31 +0100 |
| Message-ID | <j2edraFqd4sU1@mid.individual.net> |
| In reply to | #119974 |
Andreas Kohlbach: > On Tue, 21 Dec 2021 14:19:01 +0100, Kay Martinen wrote: [...] >> Glühlampen (Birnen gibt's im Obstladen) haben einen Wolfram-Doppelwendel >> als Leuchtdraht. > > Die gibt es in D noch zu kaufen? Ja. <https://www.gluehbirne.de/gluehbirnen> > War eben in der Drogerie (wo sonst wollte man Leuchtkörper kaufen? ;-), > da gab es nur LED und andere "Stromsparer". Keine mehr mit Leuchtdraht. Selbst im Baumarkt gibt es noch Glühlampen, wenn auch meist nur in Form von Halogen-Lampen und/oder niedrigen Leistungen: <https://www.bauhaus.info/halogenlampen/c/10000274> <https://www.globus-baumarkt.de/osram-halogen-gluehlampe-classic-20?fs=4080967733&c=30751> -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Kay Martinen <usenet@martinen.de> |
|---|---|
| Date | 2021-12-21 18:39 +0100 |
| Message-ID | <34g99i-2af.ln1@news.martinen.de> |
| In reply to | #119974 |
Am 21.12.21 um 16:53 schrieb Andreas Kohlbach: > On Tue, 21 Dec 2021 14:19:01 +0100, Kay Martinen wrote: >> >> Am 20.12.21 um 23:40 schrieb Andreas Kohlbach: >>> Aber meinen Computer habe ich länger im Einsatz, als der Zeitpunkt, an >>> dem sich LEDs durchsetzten. ;-) >> >> Stattlich. Die ersten LEDs in Massenproduktion soll es 1962 von Monsanto >> gegeben haben. Und wenn die sich nicht rasch durchgesetzt hätten dann >> wären Taschenrechner und Digitaluhren damit wohl kaum zu meiner >> Schulzeit kaufbar gewesen. >> >> Folglich must du deinen Computer seit über 40 Jahren im Einsatz haben... > > Ich schrieb "durchsetzten". Das dürfte <7 Jahre sein, seitdem man sie en > Masse in den Regalen (von Drogerien und Obstläden) findet. Du grenzt das auf LED-Leuchtmittel ein - was ich nicht tat. Ich meine die LEDs die es schon jahrzehnte als Anzeige-elemente für Elektronische Geräte einsetzt. Erst nur in Rot, dann in Grün und Gelb und schließlich auch in Blau. So haben wir wohl beide recht, aber einen anderen Bezugspunkt. Liegt vielleicht auch daran das ich gelernter Elektriker und schon früh Elektronik-Bastel-interessiert war. Ｂｙｅ／ ／Ｋａｙ -- 🅟🅞🅢🅣🅔🅓 🅥🅘🅐 🅛🅔🅐🅕🅝🅞🅓🅔
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| Date | 2021-12-21 13:07 -0500 |
| Message-ID | <87sfulhlwd.fsf@usenet.ankman.de> |
| In reply to | #119978 |
On Tue, 21 Dec 2021 18:39:47 +0100, Kay Martinen wrote: > > Am 21.12.21 um 16:53 schrieb Andreas Kohlbach: >> On Tue, 21 Dec 2021 14:19:01 +0100, Kay Martinen wrote: >>> >>> Am 20.12.21 um 23:40 schrieb Andreas Kohlbach: > >>>> Aber meinen Computer habe ich länger im Einsatz, als der Zeitpunkt, an >>>> dem sich LEDs durchsetzten. ;-) >>> >>> Stattlich. Die ersten LEDs in Massenproduktion soll es 1962 von Monsanto >>> gegeben haben. Und wenn die sich nicht rasch durchgesetzt hätten dann >>> wären Taschenrechner und Digitaluhren damit wohl kaum zu meiner >>> Schulzeit kaufbar gewesen. >>> >>> Folglich must du deinen Computer seit über 40 Jahren im Einsatz haben... >> >> Ich schrieb "durchsetzten". Das dürfte <7 Jahre sein, seitdem man sie en >> Masse in den Regalen (von Drogerien und Obstläden) findet. > > Du grenzt das auf LED-Leuchtmittel ein - was ich nicht tat. Ich meine > die LEDs die es schon jahrzehnte als Anzeige-elemente für Elektronische > Geräte einsetzt. Erst nur in Rot, dann in Grün und Gelb und schließlich > auch in Blau. Wobei ein befreundeter Elektronik-Bastler so einen kleinen Plastikschrank mit vielen Schubladen aus fast transparentem Plastik hatte, in denen er Widerstände, Kondensatoren, LED (grün, rot und gelb, IIRC) und andere aufbewahrte in den 80ern meinte, es werde nie andere als rote, grüne oder gelbe geben, und gab auch einen Grund an, der mir als Nicht-Elektroniker einleuchtete. Er hat sich geirrt. > So haben wir wohl beide recht, aber einen anderen Bezugspunkt. Liegt > vielleicht auch daran das ich gelernter Elektriker und schon früh > Elektronik-Bastel-interessiert war. Oder daran, dass ich "durchsetzte" nicht auf weiße LEDs definierte, die heute als "Glühbirnen" daherkommen. Auch wenn ich meine, dass das aus dem Kontext hätte klar werden sollen. -- Andreas
[toc] | [prev] | [next] | [standalone]
| From | Kay Martinen <usenet@martinen.de> |
|---|---|
| Date | 2021-12-21 20:44 +0100 |
| Message-ID | <bdn99i-r5u.ln1@news.martinen.de> |
| In reply to | #119979 |
Am 21.12.21 um 19:07 schrieb Andreas Kohlbach:
> On Tue, 21 Dec 2021 18:39:47 +0100, Kay Martinen wrote:
>>
>> Am 21.12.21 um 16:53 schrieb Andreas Kohlbach:
>>> On Tue, 21 Dec 2021 14:19:01 +0100, Kay Martinen wrote:
>>>>
>>>> Am 20.12.21 um 23:40 schrieb Andreas Kohlbach:
>>
>>>>> Aber meinen Computer habe ich länger im Einsatz, als der Zeitpunkt, an
>>>>> dem sich LEDs durchsetzten. ;-)
^^^
(1)
>>>> Stattlich. Die ersten LEDs in Massenproduktion soll es 1962 von Monsanto
>>>> gegeben haben. Und wenn die sich nicht rasch durchgesetzt hätten dann
>>>> wären Taschenrechner und Digitaluhren damit wohl kaum zu meiner
>>>> Schulzeit kaufbar gewesen.
>>> Ich schrieb "durchsetzten". Das dürfte <7 Jahre sein, seitdem man sie en
>>> Masse in den Regalen (von Drogerien und Obstläden) findet.
LED-Leuchtmittel: Ja.
LED's als solche: Nein.
>> Du grenzt das auf LED-Leuchtmittel ein - was ich nicht tat. Ich meine
>> die LEDs die es schon jahrzehnte als Anzeige-elemente für Elektronische
>> Geräte einsetzt. Erst nur in Rot, dann in Grün und Gelb und schließlich
>> auch in Blau.
>
> Wobei ein befreundeter Elektronik-Bastler so einen kleinen Plastikschrank
> mit vielen Schubladen aus fast transparentem Plastik hatte, in denen er
> Widerstände, Kondensatoren, LED (grün, rot und gelb, IIRC) und andere
So einen Schrank habe ich auch. Nicht nur einen...
> aufbewahrte in den 80ern meinte, es werde nie andere als rote, grüne oder
> gelbe geben, und gab auch einen Grund an, der mir als Nicht-Elektroniker
> einleuchtete. Er hat sich geirrt.
In DE ist die Fernlicht-Kontrolle üblicherweise Blau. Bei einem VW
damals war das eine Glühlampe im Blauen Gehäuse. Weil Blaue LEDs damals
noch nicht (Massentauglich) herstellbar waren. Ist eine Frage der
Dotierung mit bestimmten Materialien die damals noch nicht klappte.
>> So haben wir wohl beide recht, aber einen anderen Bezugspunkt. Liegt
>> vielleicht auch daran das ich gelernter Elektriker und schon früh
>> Elektronik-Bastel-interessiert war.
>
> Oder daran, dass ich "durchsetzte" nicht auf weiße LEDs definierte, die
> heute als "Glühbirnen" daherkommen. Auch wenn ich meine, dass das aus dem
> Kontext hätte klar werden sollen.
Ja, mag sein das ich oben (1) nichts von Leuchtmitteln las und darum
meinte das du LEDs ansich meintest. Manchmal verliert sich der Kontext
ja auch etwas. Diesen "Crash" müssen wir jetzt auch nicht weiter
nachverfolgen. :-)
Ｂｙｅ／
／Ｋａｙ
--
🅟🅞🅢🅣🅔🅓 🅥🅘🅐 🅛🅔🅐🅕🅝🅞🅓🅔
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kohlbach <ank@spamfence.net> |
|---|---|
| Date | 2021-12-21 20:06 -0500 |
| Message-ID | <87zgotcut6.fsf@usenet.ankman.de> |
| In reply to | #119982 |
On Tue, 21 Dec 2021 20:44:11 +0100, Kay Martinen wrote: > > Am 21.12.21 um 19:07 schrieb Andreas Kohlbach: >> >> Wobei ein befreundeter Elektronik-Bastler so einen kleinen Plastikschrank >> mit vielen Schubladen aus fast transparentem Plastik hatte, in denen er >> Widerstände, Kondensatoren, LED (grün, rot und gelb, IIRC) und andere > > So einen Schrank habe ich auch. Nicht nur einen... Er hatte IIRC vier. :-) >> aufbewahrte in den 80ern meinte, es werde nie andere als rote, grüne oder >> gelbe geben, und gab auch einen Grund an, der mir als Nicht-Elektroniker >> einleuchtete. Er hat sich geirrt. > > In DE ist die Fernlicht-Kontrolle üblicherweise Blau. Bei einem VW > damals war das eine Glühlampe im Blauen Gehäuse. Weil Blaue LEDs damals > noch nicht (Massentauglich) herstellbar waren. Ist eine Frage der > Dotierung mit bestimmten Materialien die damals noch nicht klappte. Ich erinnere mich. Sogar bei meinem 1969er Käfer war sie blau. >>> So haben wir wohl beide recht, aber einen anderen Bezugspunkt. Liegt >>> vielleicht auch daran das ich gelernter Elektriker und schon früh >>> Elektronik-Bastel-interessiert war. >> >> Oder daran, dass ich "durchsetzte" nicht auf weiße LEDs definierte, die >> heute als "Glühbirnen" daherkommen. Auch wenn ich meine, dass das aus dem >> Kontext hätte klar werden sollen. > > Ja, mag sein das ich oben (1) nichts von Leuchtmitteln las und darum > meinte das du LEDs ansich meintest. Manchmal verliert sich der Kontext > ja auch etwas. Diesen "Crash" müssen wir jetzt auch nicht weiter > nachverfolgen. :-) Einverstanden. Auch wenn ich jetzt noch weitere Crashs hatte. Heute mountete er / gar read-only (daher steht auch nichts in den Logs; vermutlich stirbt nun auch noch die Festplatte :-( ). Aber das ist nicht Linux' Schuld. -> F'up2 poster. Frohes Weihnachten allen. -- Andreas
[toc] | [prev] | [next] | [standalone]
| From | Karl Davis <me@privacy.org> |
|---|---|
| Date | 2021-12-22 08:15 +0000 |
| Message-ID | <spumri$g24$1@dserver.fritz.box> |
| In reply to | #119988 |
Andreas Kohlbach <ank@spamfence.net> wrote: >> In DE ist die Fernlicht-Kontrolle üblicherweise Blau. Bei einem VW >> damals war das eine Glühlampe im Blauen Gehäuse. Weil Blaue LEDs damals >> noch nicht (Massentauglich) herstellbar waren. Ist eine Frage der >> Dotierung mit bestimmten Materialien die damals noch nicht klappte. Passat B2 (Typ 32B) und wahrscheinlich auch in Golf dieser Ära (Anfang der 80er) hatten entweder ausschließlich für Fernlicht eine blaue Glühlampe (ohne Vorwiderstand) oder eine gelbe LED (mit Vorwiderstand) im Kombiinstrument verbaut. Hier ist z.B. ein Foto: https://www.passat-kartei.de/forum/viewtopic.php?p=129613#p129613
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2021-12-22 11:36 +0100 |
| Message-ID | <j2gdckF7a17U3@mid.individual.net> |
| In reply to | #119978 |
Kay Martinen: > Am 21.12.21 um 16:53 schrieb Andreas Kohlbach: >> On Tue, 21 Dec 2021 14:19:01 +0100, Kay Martinen wrote: >>> >>> Am 20.12.21 um 23:40 schrieb Andreas Kohlbach: > >>>> Aber meinen Computer habe ich länger im Einsatz, als der Zeitpunkt, an >>>> dem sich LEDs durchsetzten. ;-) >>> >>> Stattlich. Die ersten LEDs in Massenproduktion soll es 1962 von Monsanto >>> gegeben haben. Und wenn die sich nicht rasch durchgesetzt hätten dann >>> wären Taschenrechner und Digitaluhren damit wohl kaum zu meiner >>> Schulzeit kaufbar gewesen. >>> >>> Folglich must du deinen Computer seit über 40 Jahren im Einsatz haben... >> >> Ich schrieb "durchsetzten". Das dürfte <7 Jahre sein, seitdem man sie en >> Masse in den Regalen (von Drogerien und Obstläden) findet. > > Du grenzt das auf LED-Leuchtmittel ein - was ich nicht tat. Ich meine > die LEDs die es schon jahrzehnte als Anzeige-elemente für Elektronische > Geräte einsetzt. Erst nur in Rot, dann in Grün und Gelb und schließlich > auch in Blau. Auch LED-Leuchtmittel selbst gibt es schon deutlich länger als 10 Jahre. Busch & Müller hat den ersten Scheinwerfer für Fahrräder mit LEDs in Form des "DLumotec" bereits Ende 2004 eingeführt: <http://www.enhydralutris.de/Fahrrad/Beleuchtung/node236.html> Weniger als 7 Jahre gilt höchstens für LED-Leuchtmittel für E27-Sockel, die als Ersatz für Glühlampen gedacht sind. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Kay Martinen <usenet@martinen.de> |
|---|---|
| Date | 2021-12-22 17:18 +0100 |
| Message-ID | <6nvb9i-p4i.ln1@news.martinen.de> |
| In reply to | #119990 |
Am 22.12.21 um 11:36 schrieb Arno Welzel: > Kay Martinen: > >> Am 21.12.21 um 16:53 schrieb Andreas Kohlbach: >>> On Tue, 21 Dec 2021 14:19:01 +0100, Kay Martinen wrote: >>>> >>>> Am 20.12.21 um 23:40 schrieb Andreas Kohlbach: >> >>>>> Aber meinen Computer habe ich länger im Einsatz, als der Zeitpunkt, an >>>>> dem sich LEDs durchsetzten. ;-) >>>> >>>> Stattlich. Die ersten LEDs in Massenproduktion soll es 1962 von Monsanto >>> Ich schrieb "durchsetzten". Das dürfte <7 Jahre sein, seitdem man sie en >>> Masse in den Regalen (von Drogerien und Obstläden) findet. >> >> Du grenzt das auf LED-Leuchtmittel ein - was ich nicht tat. Ich meine >> die LEDs die es schon jahrzehnte als Anzeige-elemente für Elektronische >> Geräte einsetzt. Erst nur in Rot, dann in Grün und Gelb und schließlich >> auch in Blau. > > Auch LED-Leuchtmittel selbst gibt es schon deutlich länger als 10 Jahre. > Busch & Müller hat den ersten Scheinwerfer für Fahrräder mit LEDs in > Form des "DLumotec" bereits Ende 2004 eingeführt: Ich erinnere mich. Ca. 2 Jahre Später arbeitete ich in der Fahrrad-reparatur, da waren die mit LED IMHO aber noch teurer als die Einfachst-Funzeln. Darum hat $Boss die auch nie angeschafft, nur bei Rücklichtern. Und dann zuerst welche mit AA-Akkuhaltern. Die flogen sofort auseinander, die Akkus raus und der Speichereffekt war futscht. Als nächstes kam Leiterplatten-oxydierung und dann kannst die gleich komplett wechseln. > Weniger als 7 Jahre gilt höchstens für LED-Leuchtmittel für E27-Sockel, > die als Ersatz für Glühlampen gedacht sind. Ich denke Andreas hat das genau auf diesen Eng begrenzten Sektor der Netzverbundenen Wohnraum-illumination bezogen genannt. Daher ja die kontroverse. Ich kenne LEDs länger, aber nicht dort. Wenn einen die immanenten Vorteile der LED (so $Produkt sie denn hat) nicht in den allerwertesten Beißen ist es dem ONU vermutlich reichlich egal "was" da konkret Leuchtet oder wie es das tut. Da gehts dann mehr um Helligkeit, Lichtfarbe, WAF, Haltbarkeit und Kosten. Ich hab auch 2 billigst Tischlampen mit SMD LEDs auf Leiterplatte die nach kurzer Zeit partielle ausfälle und aussetzer bekamen. Kenne ich von Anzeige-LEDs überhaupt nicht. Wenn $Hersteller den billigsten ausschuß noch verramscht dann kommt das wohl bei raus. Ｂｙｅ／ ／Ｋａｙ -- 🅟🅞🅢🅣🅔🅓 🅥🅘🅐 🅛🅔🅐🅕🅝🅞🅓🅔
[toc] | [prev] | [next] | [standalone]
Page 5 of 20 — ← Prev page 1 … 3 4 [5] 6 7 … 20 Next page →
Back to top | Article view | de.comp.os.unix.linux.misc
csiph-web