Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.alt.folklore.computer > #44345 > unrolled thread
| Started by | Joerg Walther <joerg.walther@magenta.de> |
|---|---|
| First post | 2024-04-06 09:37 +0200 |
| Last post | 2024-05-15 15:32 +0200 |
| Articles | 20 on this page of 262 — 28 participants |
Back to article view | Back to de.alt.folklore.computer
Triumph of the Nerds Joerg Walther <joerg.walther@magenta.de> - 2024-04-06 09:37 +0200
Re: Triumph of the Nerds Michael Pachta <mipani@gmx.de> - 2024-04-06 10:06 +0200
Re: Triumph of the Nerds Joerg Walther <joerg.walther@magenta.de> - 2024-04-06 11:37 +0200
Re: Triumph of the Nerds Kay Martinen <usenet@martinen.de> - 2024-04-06 11:14 +0200
Re: Triumph of the Nerds Joerg Walther <joerg.walther@magenta.de> - 2024-04-06 11:39 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-04-08 12:27 +0200
Re: Triumph of the Nerds Joerg Walther <joerg.walther@magenta.de> - 2024-04-08 13:33 +0200
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-04-17 17:33 +0000
Re: Triumph of the Nerds Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-04-18 08:46 +0200
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-04-18 19:41 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-04-19 18:44 +0200
Re: Triumph of the Nerds Kay Martinen <usenet@martinen.de> - 2024-04-20 22:34 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-04-21 17:18 +0200
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-04-24 07:41 +0200
Re: Triumph of the Nerds Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-04-24 08:49 +0000
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-04-24 11:38 +0200
Re: Triumph of the Nerds Michael Kraemer <m.kraemer@gsi.de> - 2024-04-24 16:28 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-04-24 18:55 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-04-24 20:53 +0000
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-04-30 13:33 +0200
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-04-30 13:11 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-01 11:15 +0000
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-05-02 18:49 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-02 21:14 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-02 21:16 +0000
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-03 07:46 +0000
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-03 20:21 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-03 22:03 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-04 07:14 +0000
Re: Triumph of the Nerds Michael Kraemer <m.kraemer@gsi.de> - 2024-05-04 09:37 +0200
C (was: Triumph of the Nerds) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-04 11:23 +0200
Re: C Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-04 13:17 +0200
Re: C Michael Kraemer <m.kraemer@gsi.de> - 2024-05-04 14:47 +0200
Re: C Arno Welzel <usenet@arnowelzel.de> - 2024-05-05 16:43 +0200
Re: C Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-06 09:41 +0200
Re: C "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-05 02:08 +0200
Re: C Arno Welzel <usenet@arnowelzel.de> - 2024-05-05 16:41 +0200
Re: C Ralf Damaschke <rwspam@gmx.de> - 2024-05-05 16:02 +0000
Re: C Ralf Damaschke <rwspam@gmx.de> - 2024-05-05 23:47 +0000
Re: C "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-05 19:55 +0200
Re: C Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-06 09:50 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-04 11:26 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-04 10:01 +0000
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-04 12:19 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-05 16:47 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-04 13:20 +0200
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-04 09:09 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-04 11:23 +0200
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-05 10:16 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-05 16:18 +0200
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-06 18:41 +0200
Pascal (was: Triumph of the Nerds) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-06 19:55 +0200
Re: Pascal Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-07 06:40 +0200
Re: Pascal "F. W." <me@home.invalid> - 2024-05-07 07:48 +0200
Re: Pascal Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-07 08:26 +0200
Re: Pascal Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-07 13:04 +0200
Re: Pascal Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-07 14:57 +0200
Re: Pascal Thomas Koenig <tkoenig@netcologne.de> - 2024-05-07 13:11 +0000
Re: Pascal Thomas Koenig <tkoenig@netcologne.de> - 2024-05-07 13:55 +0000
Re: Pascal "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-08 21:33 +0200
Re: Pascal Thomas Koenig <tkoenig@netcologne.de> - 2024-05-09 07:42 +0000
Re: Pascal Arno Welzel <usenet@arnowelzel.de> - 2024-05-09 12:09 +0200
Re: Pascal Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-09 12:37 +0200
Re: Pascal Arno Welzel <usenet@arnowelzel.de> - 2024-05-09 12:42 +0200
Re: Pascal Andreas Bockelmann <xotzil@gmx.de> - 2024-05-12 11:36 +0200
Re: Pascal Thomas Koenig <tkoenig@netcologne.de> - 2024-05-12 13:42 +0000
Re: Pascal Andreas Bockelmann <xotzil@gmx.de> - 2024-05-12 19:19 +0200
Re: Pascal Andreas Karrer <ak-4a@gmx.ch> - 2024-05-12 21:39 +0000
Re: Pascal "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-09 16:09 +0200
Re: Pascal Arno Welzel <usenet@arnowelzel.de> - 2024-05-09 17:49 +0200
Re: Pascal Stefan Reuther <stefan.news@arcor.de> - 2024-05-12 20:56 +0200
Re: Pascal Thomas Koenig <tkoenig@netcologne.de> - 2024-05-12 19:46 +0000
Re: Pascal Peter Müller <invalid@invalid.invalid> - 2024-05-12 22:00 +0200
Re: Pascal Stefan Reuther <stefan.news@arcor.de> - 2024-05-07 18:16 +0200
Re: Pascal "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-08 20:20 +0200
Re: Pascal Stefan Reuther <stefan.news@arcor.de> - 2024-05-12 21:13 +0200
Re: Pascal Stefan Reuther <stefan.news@arcor.de> - 2024-05-13 10:39 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-07 09:20 +0200
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-07 18:03 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-08 04:13 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-08 12:01 +0200
Re: Triumph of the Nerds Kay Martinen <usenet@martinen.de> - 2024-05-13 01:54 +0200
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-13 10:51 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-13 13:45 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-13 14:04 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-13 17:23 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-05 11:22 +0000
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-05 15:57 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-05 18:30 +0000
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-05 21:54 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-06 13:04 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-06 11:45 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-06 20:53 +0000
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-07 08:42 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-07 21:56 +0000
Accidental Complexity von Programmiersprachen (was: Triumph of the Nerds) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-08 21:06 +0200
Re: Accidental Complexity von Programmiersprachen (was: Triumph of the Nerds) Thomas Koenig <tkoenig@netcologne.de> - 2024-05-09 07:31 +0000
Re: Accidental Complexity von Programmiersprachen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-09 10:12 +0200
Re: Accidental Complexity von Programmiersprachen Thomas Koenig <tkoenig@netcologne.de> - 2024-05-09 13:03 +0000
Re: Accidental Complexity von Programmiersprachen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-09 16:03 +0200
Re: Accidental Complexity von Programmiersprachen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-09 16:57 +0200
Re: Accidental Complexity von Programmiersprachen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-09 17:36 +0200
Re: Accidental Complexity von Programmiersprachen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-09 18:52 +0200
Re: Accidental Complexity von Programmiersprachen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-10 03:49 +0200
Re: Accidental Complexity von Programmiersprachen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-09 19:22 +0200
Re: Accidental Complexity von Programmiersprachen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-10 04:07 +0200
Re: Accidental Complexity von Programmiersprachen Thomas Koenig <tkoenig@netcologne.de> - 2024-05-09 17:00 +0000
Re: Accidental Complexity von Programmiersprachen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-09 20:25 +0200
Re: Accidental Complexity von Programmiersprachen Thomas Koenig <tkoenig@netcologne.de> - 2024-05-09 20:55 +0000
Re: Accidental Complexity von Programmiersprachen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-09 23:53 +0200
Re: Accidental Complexity von Programmiersprachen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-10 04:26 +0200
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-08 20:53 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-08 20:09 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-06 12:50 +0200
Yoda expressions (was: Triumph of the Nerds) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-06 19:39 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-06 14:16 +0200
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-06 19:04 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-05 16:28 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-05 18:33 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-06 13:09 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-06 21:01 +0000
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-08 20:01 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-08 20:15 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-09 12:18 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-09 16:36 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-05 16:37 +0200
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-05 19:51 +0200
Re: Triumph of the Nerds "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2024-05-06 07:41 +0000
C (was: Triumph of the Nerds) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-06 19:13 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-06 09:58 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-06 10:34 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-06 14:00 +0200
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-05 19:57 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-06 12:06 +0000
C (was: Triumph of the Nerds) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-06 19:29 +0200
Re: C Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-07 06:49 +0200
Re: C Thomas Koenig <tkoenig@netcologne.de> - 2024-05-07 06:30 +0000
Re: C Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-07 09:42 +0200
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-06 18:55 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-06 21:03 +0000
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-07 06:32 +0000
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-07 09:44 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-07 08:26 +0000
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-07 18:13 +0200
Re: Triumph of the Nerds Thomas Klix <wotokl@web.de> - 2024-05-07 21:50 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-07 21:49 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-07 22:16 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-07 22:10 +0000
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-08 08:40 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-08 14:19 +0000
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-08 15:14 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-08 18:16 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-08 17:30 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-09 12:20 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-09 12:19 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-09 17:52 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-09 16:43 +0000
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-09 16:48 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-09 16:40 +0000
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-09 14:26 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-09 16:38 +0000
Re: Triumph of the Nerds Stefan Reuther <stefan.news@arcor.de> - 2024-05-12 21:09 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-02 19:46 +0200
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-05-02 18:44 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-03 22:09 +0200
Re: Triumph of the Nerds Christian Corti <use@reply.to> - 2024-05-06 12:58 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-06 15:07 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-06 21:06 +0000
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-04-30 17:40 +0000
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-01 07:17 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-01 09:10 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-01 11:40 +0000
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-01 12:18 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-01 20:44 +0000
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-05-02 07:31 +0200
Re: Triumph of the Nerds Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-05-02 05:54 +0000
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-05-03 09:25 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-03 08:35 +0000
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-05-03 11:20 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-03 22:13 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-03 21:14 +0000
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-05-06 07:48 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-03 22:12 +0200
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-05-06 07:49 +0200
Re: Triumph of the Nerds Markus Elsken <markus.elsken@ewetel.net> - 2024-05-06 23:53 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-07 06:34 +0000
Re: Triumph of the Nerds Markus Elsken <markus.elsken@ewetel.net> - 2024-05-07 22:48 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-05-08 06:35 +0000
Re: Triumph of the Nerds Markus Elsken <markus.elsken@ewetel.net> - 2024-05-09 15:37 +0200
Re: Triumph of the Nerds Andreas Eder <a_eder_muc@web.de> - 2024-05-09 22:53 +0200
Re: Triumph of the Nerds Markus Elsken <markus.elsken@ewetel.net> - 2024-05-10 01:05 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-07 16:09 +0200
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-02 19:31 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-02 19:50 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-01 11:07 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-04-24 09:08 +0000
Re: Triumph of the Nerds "F. W." <me@home.invalid> - 2024-04-24 11:40 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-04-24 17:31 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-04-24 20:57 +0000
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-04-25 10:04 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-04-25 08:59 +0000
Re: Triumph of the Nerds Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-04-25 11:52 +0000
Re: Triumph of the Nerds Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2024-04-25 14:47 +0000
Re: Triumph of the Nerds Joerg Walther <joerg.walther@magenta.de> - 2024-04-25 18:59 +0200
Re: Triumph of the Nerds Joerg Walther <joerg.walther@magenta.de> - 2024-04-26 15:38 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-07 07:13 +0200
Re: Triumph of the Nerds Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2024-04-26 13:04 +0000
Re: Triumph of the Nerds Kay Martinen <usenet@martinen.de> - 2024-05-15 19:45 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-04-27 10:42 +0000
Re: Triumph of the Nerds Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-04-27 13:18 +0000
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-04-30 13:25 +0000
Re: Triumph of the Nerds Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-04-30 14:40 +0000
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-05-02 19:01 +0000
Re: Triumph of the Nerds Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-05-02 20:18 +0000
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-05-03 22:46 +0000
Re: Triumph of the Nerds Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2024-05-04 02:02 +0000
Re: Triumph of the Nerds Kay Martinen <usenet@martinen.de> - 2024-04-28 01:40 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-04-29 06:26 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-04-29 16:11 +0000
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-04-30 11:32 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-04-30 11:13 +0000
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-04-30 13:33 +0000
Re: Triumph of the Nerds Thomas Klix <wotokl@web.de> - 2024-04-30 16:30 +0200
Re: Triumph of the Nerds Thomas Klix <wotokl@web.de> - 2024-04-30 16:46 +0200
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-05-02 19:16 +0000
Re: Triumph of the Nerds Christian Corti <use@reply.to> - 2024-05-06 13:07 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-06 16:03 +0200
Re: Triumph of the Nerds Christian Corti <use@reply.to> - 2024-05-06 18:10 +0200
Re: Triumph of the Nerds Thomas Klix <wotokl@web.de> - 2024-05-06 21:53 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-06 21:08 +0000
Re: Triumph of the Nerds Guido Grohmann <guido.grohmann@gmx.de> - 2024-05-07 06:59 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-07 08:28 +0000
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-07 16:10 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-07 22:15 +0000
Re: Triumph of the Nerds Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-05-08 08:42 +0200
Re: Triumph of the Nerds Guido Grohmann <guido.grohmann@gmx.de> - 2024-05-07 16:51 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-05-07 17:42 +0200
Re: Triumph of the Nerds Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-04-30 15:10 +0000
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-04-30 19:08 +0200
Re: Triumph of the Nerds Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-05-01 08:15 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-01 11:49 +0000
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-01 11:46 +0000
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-04-30 13:34 +0000
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-04-30 18:34 +0200
Re: Triumph of the Nerds poc@pocnet.net - 2024-05-01 11:50 +0000
Re: Triumph of the Nerds Joerg Walther <joerg.walther@magenta.de> - 2024-04-24 16:59 +0200
Re: Triumph of the Nerds "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2024-04-28 19:35 +0200
Re: Triumph of the Nerds Thomas Koenig <tkoenig@netcologne.de> - 2024-04-28 20:24 +0000
Re: Triumph of the Nerds "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2024-04-28 23:26 +0200
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-04-30 13:43 +0000
Re: Triumph of the Nerds "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2024-05-02 20:07 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-02 20:48 +0200
Re: Triumph of the Nerds "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2024-05-03 23:15 +0200
Re: Triumph of the Nerds Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-05-04 10:00 +0200
Re: Triumph of the Nerds "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-05-04 11:33 +0200
Re: Triumph of the Nerds Kay Martinen <usenet@martinen.de> - 2024-05-15 15:14 +0200
Re: Triumph of the Nerds Arno Welzel <usenet@arnowelzel.de> - 2024-04-29 13:21 +0200
Re: Triumph of the Nerds Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-04-30 07:33 +0200
Re: Triumph of the Nerds Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-04-30 17:55 +0200
Re: Triumph of the Nerds Sebastian Barthel <naitsabes@freenet.de> - 2024-04-30 13:54 +0000
Re: Triumph of the Nerds Andreas Eder <a_eder_muc@web.de> - 2024-04-30 22:57 +0200
Re: Triumph of the Nerds Kay Martinen <usenet@martinen.de> - 2024-05-15 15:32 +0200
Page 7 of 14 — ← Prev page 1 … 5 6 [7] 8 9 … 14 Next page →
| From | poc@pocnet.net |
|---|---|
| Date | 2024-05-06 21:01 +0000 |
| Message-ID | <l9suodFe83jU2@mid.individual.net> |
| In reply to | #44524 |
Arno Welzel <usenet@arnowelzel.de> wrote: >> Kann ich nicht nachvollziehen. Auch meine Perl-Lösung benutzt ODBC, die >> gleichen Definitionen wie zuvor für Node. > > Mag sein, dass die ODBC-Integration von Node nicht gut ist. Dazu kann ich nichts sagen. > Ich versuche ODBC in der Praxis aber generell zu vermeiden, wann immer > es möglich ist. Es bildet halt generell nochmal eine Zwischenschicht, > die je nach Datenbank das SQL-Statement nochmal selber bearbeitet, bevor > es in der Datenbank landet. Meine Erfahrungen, die ich erst vor wenigen Jahren begonnen habe zu machen sind hier durchweg positiv. > Das letzte Mal, dass ich ODBC noch regelmäßiger genutzt habe, war irgendwann > Mitte bis Ende der 1990er Jahre, als es für Umgebungen wie Windows mit MFC > kaum andere Optionen gab, um mit einem Oracle-Server zu sprechen Das war ja auch gefühlt die Hoch-Zeit von ODBC. > jedenfalls keine, die nicht erhblich viel mehr Aufwand gemacht hätte. Heute > ist ODBC aber vielfach schlicht nicht mehr notwendig, weil die > Client-Bibliotheken für Datenbanken in etlichen Programmiersprachen mit > geringem Aufwand nutzbar sind. Mir ist keine Bibiothek unter Linux bekannt, die nativ mit DB2/UDB (IBM i) über's Netzwerk spricht. Möglich dass es Bibliotheken unter Linux für MS SQL gibt. ODBC ist für mich eine passende Lösung, weil genau dafür definiert: Eine lokale API zum "genormten" (im Rahmen der SQL-Dialekte) Ansprechen von verschiedenen Datenbanken, lokal oder über's Netzwerk, wobei das Protokoll über's Netzwerk wiederum datenbankabhängig ist und nicht Bestandteil der ODBC-Definition. Das ist das Einzige was mich an ODBC ein kleines bisschen stört. -- :wq! PoC
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2024-05-08 20:01 +0200 |
| Message-ID | <slrnv3nfgk.1fdo8.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #44545 |
On 2024-05-06 21:01, poc@pocnet.net <poc@pocnet.net> wrote:
> Arno Welzel <usenet@arnowelzel.de> wrote:
>> jedenfalls keine, die nicht erhblich viel mehr Aufwand gemacht hätte. Heute
>> ist ODBC aber vielfach schlicht nicht mehr notwendig, weil die
>> Client-Bibliotheken für Datenbanken in etlichen Programmiersprachen mit
>> geringem Aufwand nutzbar sind.
>
> Mir ist keine Bibiothek unter Linux bekannt, die nativ mit DB2/UDB (IBM i)
> über's Netzwerk spricht. Möglich dass es Bibliotheken unter Linux für MS SQL
> gibt. ODBC ist für mich eine passende Lösung, weil genau dafür definiert: Eine
> lokale API zum "genormten" (im Rahmen der SQL-Dialekte) Ansprechen von
> verschiedenen Datenbanken,
Aber es ist eben nur einen genormte Zwischenschicht. Ohne nativen
Treiber nützt Dir ODBC nichts, weil ODBC eben nicht mit der Datenbank
spricht, sondern nur mit dem Treiber.
> lokal oder über's Netzwerk, wobei das Protokoll über's Netzwerk
> wiederum datenbankabhängig ist und nicht Bestandteil der
> ODBC-Definition. Das ist das Einzige was mich an ODBC ein kleines
> bisschen stört.
Daran kann ODBC nichts ändern. Dazu müsste jemand (Die ISO
SQL-Working-Group?) ein entsprechendes Netzwerkprotokoll definieren und
alle Datenbankhersteller dazu überreden, dass sie das auch
implementieren).
hp
[toc] | [prev] | [next] | [standalone]
| From | poc@pocnet.net |
|---|---|
| Date | 2024-05-08 20:15 +0000 |
| Message-ID | <la24qkF7el7U2@mid.individual.net> |
| In reply to | #44604 |
Peter J. Holzer <hjp-usenet4@hjp.at> wrote: > On 2024-05-06 21:01, poc@pocnet.net <poc@pocnet.net> wrote: >> Arno Welzel <usenet@arnowelzel.de> wrote: >>> jedenfalls keine, die nicht erhblich viel mehr Aufwand gemacht hätte. Heute >>> ist ODBC aber vielfach schlicht nicht mehr notwendig, weil die >>> Client-Bibliotheken für Datenbanken in etlichen Programmiersprachen mit >>> geringem Aufwand nutzbar sind. >> >> Mir ist keine Bibiothek unter Linux bekannt, die nativ mit DB2/UDB (IBM i) >> über's Netzwerk spricht. Möglich dass es Bibliotheken unter Linux für MS SQL >> gibt. ODBC ist für mich eine passende Lösung, weil genau dafür definiert: Eine >> lokale API zum "genormten" (im Rahmen der SQL-Dialekte) Ansprechen von >> verschiedenen Datenbanken, > > Aber es ist eben nur einen genormte Zwischenschicht. Ohne nativen > Treiber nützt Dir ODBC nichts, weil ODBC eben nicht mit der Datenbank > spricht, sondern nur mit dem Treiber. > >> lokal oder über's Netzwerk, wobei das Protokoll über's Netzwerk >> wiederum datenbankabhängig ist und nicht Bestandteil der >> ODBC-Definition. Das ist das Einzige was mich an ODBC ein kleines >> bisschen stört. > > Daran kann ODBC nichts ändern. Dazu müsste jemand (Die ISO > SQL-Working-Group?) ein entsprechendes Netzwerkprotokoll definieren und > alle Datenbankhersteller dazu überreden, dass sie das auch > implementieren). > > hp -- :wq! PoC
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2024-05-09 12:18 +0200 |
| Message-ID | <la3m7qFek12U2@mid.individual.net> |
| In reply to | #44545 |
poc@pocnet.net, 2024-05-06 23:01: > Arno Welzel <usenet@arnowelzel.de> wrote: [...] >> jedenfalls keine, die nicht erhblich viel mehr Aufwand gemacht hätte. Heute >> ist ODBC aber vielfach schlicht nicht mehr notwendig, weil die >> Client-Bibliotheken für Datenbanken in etlichen Programmiersprachen mit >> geringem Aufwand nutzbar sind. > > Mir ist keine Bibiothek unter Linux bekannt, die nativ mit DB2/UDB (IBM i) > über's Netzwerk spricht. Möglich dass es Bibliotheken unter Linux für MS SQL Wenn es die nicht gibt, dann gibt es auch kein ODBC dafür. Denn ODBC spricht nicht selbst mit DB2 sondern nur mit der dafür vorgesehenen Bibliothek. Siehe hier ab Seite 11, da wird die Installation der Client-Bibliotheken beschrieben, wo die Nutzung mit ODBC nur eine von mehreren Optionen ist: <https://public.dhe.ibm.com/ps/products/db2/info/vr105/pdf/en_US/DB2InstallingClients-db2ite1051.pdf> > gibt. ODBC ist für mich eine passende Lösung, weil genau dafür definiert: Eine > lokale API zum "genormten" (im Rahmen der SQL-Dialekte) Ansprechen von > verschiedenen Datenbanken, lokal oder über's Netzwerk, wobei das Protokoll > über's Netzwerk wiederum datenbankabhängig ist und nicht Bestandteil der > ODBC-Definition. Das ist das Einzige was mich an ODBC ein kleines bisschen > stört. Das Protokoll über's Netzwerk ist bei jeder Datenbank anders. Daran ändert auch ODBC nichts. Die Struktur ist immer so: Anwendunge ---> ODBC ---> DB-Client ---> Netzwerk ---> Datenbank Und "DB-Client" ist immer vorhanden, egal, ob die Anwendung ODBC nutzt, um mit dem DB-Client zu reden oder nicht. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | poc@pocnet.net |
|---|---|
| Date | 2024-05-09 16:36 +0000 |
| Message-ID | <la4cbkFhoeaU1@mid.individual.net> |
| In reply to | #44617 |
Arno Welzel <usenet@arnowelzel.de> wrote: >> Mir ist keine Bibiothek unter Linux bekannt, die nativ mit DB2/UDB (IBM i) >> über's Netzwerk spricht. Möglich dass es Bibliotheken unter Linux für MS SQL > > Wenn es die nicht gibt, dann gibt es auch kein ODBC dafür. Okay, das war vielleicht etwas missverständlich ausgedrückt. > Denn ODBC spricht nicht selbst mit DB2 sondern nur mit der dafür > vorgesehenen Bibliothek. Ja. Und wenn für diese Bibliothek keine Doku vorhanden ist, sondern diese als reines "Plugin" für die ODBC-Infrastruktur gedacht ist, dann ist das genauso gut wie "gibt keine". > Siehe hier ab Seite 11, da wird die Installation der Client-Bibliotheken > beschrieben, wo die Nutzung mit ODBC nur eine von mehreren Optionen ist: > > <https://public.dhe.ibm.com/ps/products/db2/info/vr105/pdf/en_US/DB2InstallingClients-db2ite1051.pdf> Danke, aber: "IBM DB2 10.5 for Linux, UNIX, and Windows". Das ist DB2 "LUW". Ich habe immer mehr den Eindruck, dass es DB2 nur als Marketingberiff gibt, aber nicht als einigermaßen koheräntes Produkt. Und natürlich unterscheiden sich alle Varianten mehr oder weniger subtil in der Administration, im Funktionsumfang und in der Integration ins OS. Ich kenne: - DB2 LUW - DB2 für z/OS - DB2/UDB für IBM i Und jede Variante hat ihre eigenen ODBC-Treiber und AFAIK ein eigenes Protokoll über's Netzwerk. Die IBM i Variante spricht höchstwahrscheinlich DRDA, das gilt möglicherweise auch für die z/OS Variante. <https://en.wikipedia.org/wiki/DRDA> Ich kenne keine native Library, die *nicht* als ODBC-Plugin gedacht ist für DB2/UDB. -- :wq! PoC
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2024-05-05 16:37 +0200 |
| Message-ID | <l9pjsiFsmkrU11@mid.individual.net> |
| In reply to | #44495 |
Stefan Ram, 2024-05-05 13:41:
> poc@pocnet.net schrieb oder zitierte:
>> Vielleicht ist das blauäugug von mir, aber ich bin mir sicher, dass man auch
>> in C sauber und sicher programmieren kann.
>
> Diese Meinung sollte jeder teilen, der eine Sprache wie Python
> empfiehlt, denn Python /ist/ ja in C geschrieben. Wenn es nicht
> möglich wäre, sicher in C zu programmieren, dann wäre Python
> also auch nicht sicher. Zudem sind viele Python-Bibliotheken
> ganz oder teilweise in C geschrieben.
Man kann in jeder Sprache "sauber und sicher programmieren".
Die Frage ist nur, wie aufwendig ist es und wie hoch die
Wahrscheinlichkeit, dass sicherheitsrelevante Fehler unbemerkt bleiben.
#include <stdio.h>
char buf[10000];
FILE *fp;
fp = fopen("foobar", "r");
fread(buf, 100000, 1, fp);
fclose(fp);
Einfach nur an einer Stelle eine 0 zuviel angegeben. Dem Compiler ist
das egal, der Entwickler sieht es vielleicht nicht.
Ja, sowas soll man auch nicht machen, sondern wenn schon, dann eine
Konstante für die Buffergröße angeben oder sizeof() etc. nutzen. Aber es
ist halt nirgends vorgeschrieben und deshalb gab es in der Vergangenheit
so viele Probleme mit Buffer Overflow.
--
Arno Welzel
https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2024-05-05 19:51 +0200 |
| Message-ID | <slrnv3fho6.17hrh.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #44501 |
On 2024-05-05 14:37, Arno Welzel <usenet@arnowelzel.de> wrote:
> Stefan Ram, 2024-05-05 13:41:
>> poc@pocnet.net schrieb oder zitierte:
>>> Vielleicht ist das blauäugug von mir, aber ich bin mir sicher, dass
>>> man auch in C sauber und sicher programmieren kann.
>>
>> Diese Meinung sollte jeder teilen, der eine Sprache wie Python
>> empfiehlt, denn Python /ist/ ja in C geschrieben. Wenn es nicht
>> möglich wäre, sicher in C zu programmieren, dann wäre Python
>> also auch nicht sicher. Zudem sind viele Python-Bibliotheken
>> ganz oder teilweise in C geschrieben.
>
> Man kann in jeder Sprache "sauber und sicher programmieren".
>
> Die Frage ist nur, wie aufwendig ist es und wie hoch die
> Wahrscheinlichkeit, dass sicherheitsrelevante Fehler unbemerkt bleiben.
>
> #include <stdio.h>
>
> char buf[10000];
> FILE *fp;
>
> fp = fopen("foobar", "r");
> fread(buf, 100000, 1, fp);
> fclose(fp);
>
> Einfach nur an einer Stelle eine 0 zuviel angegeben. Dem Compiler ist
> das egal,
Kommt auf den Compiler an:
#v+
% gcc -Wall -O foo.c
foo.c: In function ‘main’:
foo.c:8:5: warning: ignoring return value of ‘fread’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
8 | fread(buf, 100000, 1, fp);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/stdio.h:894,
from foo.c:1:
In function ‘fread’,
inlined from ‘main’ at foo.c:8:5:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:295:12: warning: call to ‘__fread_chk_warn’ declared with attribute warning: fread called with bigger size * nmemb than length of destination buffer [-Wattribute-warning]
295 | return __fread_chk_warn (__ptr, sz, __size, __n, __stream);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#v-
Aber darauf kann man sich nicht verlassen, denn in echten Programmen ist
buf oft nicht statisch alloziert (oder wenn, dann woanders) und der
Compiler kann gar nicht wissen, wie groß das ist.
> der Entwickler sieht es vielleicht nicht.
Und die Testcases enthalten nur Files < 10000 Bytes.
> Ja, sowas soll man auch nicht machen, sondern wenn schon, dann eine
> Konstante für die Buffergröße angeben oder sizeof() etc. nutzen. Aber es
> ist halt nirgends vorgeschrieben und deshalb gab es in der Vergangenheit
> so viele Probleme mit Buffer Overflow.
Plus natürlich diverse Funktionen, die gar keine Möglichkeit vorsehen,
die Größe des Zielbuffers anzugeben (strcpy, gets, scanf, ...). Da muss
man dann als Programmierer wissen, wann man die einsetzen kann und wann
nicht. Und bei deren Geschwistern mit einem entsprechenden
Limit-Parameter muss man wieder wissen, was passiert, wenn dieser
überschritten wird.
hp
[toc] | [prev] | [next] | [standalone]
| From | "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> |
|---|---|
| Date | 2024-05-06 07:41 +0000 |
| Message-ID | <l9rfseF7b08U1@mid.individual.net> |
| In reply to | #44501 |
Arno Welzel <usenet@arnowelzel.de> wrote:
>Stefan Ram, 2024-05-05 13:41:
>> poc@pocnet.net schrieb oder zitierte:
>>> Vielleicht ist das blauäugug von mir, aber ich bin mir sicher, dass man auch
>>> in C sauber und sicher programmieren kann.
>>
>> Diese Meinung sollte jeder teilen, der eine Sprache wie Python
>> empfiehlt, denn Python /ist/ ja in C geschrieben. Wenn es nicht
>> möglich wäre, sicher in C zu programmieren, dann wäre Python
>> also auch nicht sicher. Zudem sind viele Python-Bibliotheken
>> ganz oder teilweise in C geschrieben.
>Man kann in jeder Sprache "sauber und sicher programmieren".
>Die Frage ist nur, wie aufwendig ist es und wie hoch die
>Wahrscheinlichkeit, dass sicherheitsrelevante Fehler unbemerkt bleiben.
>#include <stdio.h>
>char buf[10000];
>FILE *fp;
>fp = fopen("foobar", "r");
>fread(buf, 100000, 1, fp);
>fclose(fp);
>Einfach nur an einer Stelle eine 0 zuviel angegeben. Dem Compiler ist
>das egal, der Entwickler sieht es vielleicht nicht.
Müsste das nicht mit lint o.Ä. auffallen? Schliesslich ist die Anzahl der
einzulesenden Bytes schon zur Compiletime bekannt.
--
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2024-05-06 19:13 +0200 |
| Subject | C (was: Triumph of the Nerds) |
| Message-ID | <slrnv3i3ti.1b1lf.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #44517 |
On 2024-05-06 07:41, Peter Heitzer <peter.heitzer@rz.uni-regensburg.de> wrote:
> Arno Welzel <usenet@arnowelzel.de> wrote:
>>#include <stdio.h>
>
>>char buf[10000];
>>FILE *fp;
>
>>fp = fopen("foobar", "r");
>>fread(buf, 100000, 1, fp);
>>fclose(fp);
>
>>Einfach nur an einer Stelle eine 0 zuviel angegeben. Dem Compiler ist
>>das egal, der Entwickler sieht es vielleicht nicht.
> Müsste das nicht mit lint o.Ä. auffallen? Schliesslich ist die Anzahl der
> einzulesenden Bytes schon zur Compiletime bekannt.
Siehe mein anderes Posting. Es gibt Compiler (z.B. gcc), die so einfache
Fälle tatsächlich erkennen.
Aber in der Praxis sieht das halt oft eher so aus:
void f(char *buf, size_t n) {
fp = fopen("foobar", "r");
fread(buf, n, 1, fp);
fclose(fp);
}
void g() {
char *buf = malloc(10000);
/* viel code dazwischen */
f(buf, 100000);
}
Theoretisch könnte das ein Compiler immer noch per Datenfluss-Analyse
erkennen. Aber das ist schon deutlich komplexer. Auch könnten die
Funktionen f und g in zwei verschiedenen Files definiert sein und der
Compiler hat nur Zugriff auf eines davon. Und schlussendlich ist das
natürlich auch immer noch ein triviales Beispiel. Im allgemeinen Fall
ist das ziemlich sicher nicht mehr per statischer Analyse möglich[1],
sondern muss zur Laufzeit getestet werden. Und dafür bringen typische
C-Implementationen nicht genug Informationen mit.
hp
[1] Den Beweis, dass das äquivalent zum Halteproblem ist, mag jemand
anderer führen ;-)
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-05-06 09:58 +0200 |
| Message-ID | <l9rgspF7k65U1@mid.individual.net> |
| In reply to | #44501 |
Am 05.05.24 um 16:37 schrieb Arno Welzel:
> Stefan Ram, 2024-05-05 13:41:
>
>> poc@pocnet.net schrieb oder zitierte:
>>> Vielleicht ist das blauäugug von mir, aber ich bin mir sicher, dass man auch
>>> in C sauber und sicher programmieren kann.
>>
>> Diese Meinung sollte jeder teilen, der eine Sprache wie Python
>> empfiehlt, denn Python /ist/ ja in C geschrieben. Wenn es nicht
>> möglich wäre, sicher in C zu programmieren, dann wäre Python
>> also auch nicht sicher. Zudem sind viele Python-Bibliotheken
>> ganz oder teilweise in C geschrieben.
>
> Man kann in jeder Sprache "sauber und sicher programmieren".
>
> Die Frage ist nur, wie aufwendig ist es und wie hoch die
> Wahrscheinlichkeit, dass sicherheitsrelevante Fehler unbemerkt bleiben.
>
> #include <stdio.h>
>
> char buf[10000];
> FILE *fp;
>
> fp = fopen("foobar", "r");
> fread(buf, 100000, 1, fp);
> fclose(fp);
>
> Einfach nur an einer Stelle eine 0 zuviel angegeben. Dem Compiler ist
> das egal, der Entwickler sieht es vielleicht nicht.
Wenn ich eine Datei einlese,
frage ich erst mal die Dateigröße ab.
Bei einer Textdatei nehme ich p=malloc(len_+8)
memset(p,0,4); memset(p+len_+4,0,4);
und read(p+4,len_);
Um beim scannen etwas vor und zurückschauen zu können.
--
<http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2024-05-06 10:34 +0200 |
| Message-ID | <l9rj0cF7d7iU7@mid.individual.net> |
| In reply to | #44520 |
Hermann Riemann, 2024-05-06 09:58:
> Am 05.05.24 um 16:37 schrieb Arno Welzel:
>> Stefan Ram, 2024-05-05 13:41:
>>
>>> poc@pocnet.net schrieb oder zitierte:
>>>> Vielleicht ist das blauäugug von mir, aber ich bin mir sicher, dass man auch
>>>> in C sauber und sicher programmieren kann.
>>>
>>> Diese Meinung sollte jeder teilen, der eine Sprache wie Python
>>> empfiehlt, denn Python /ist/ ja in C geschrieben. Wenn es nicht
>>> möglich wäre, sicher in C zu programmieren, dann wäre Python
>>> also auch nicht sicher. Zudem sind viele Python-Bibliotheken
>>> ganz oder teilweise in C geschrieben.
>>
>> Man kann in jeder Sprache "sauber und sicher programmieren".
>>
>> Die Frage ist nur, wie aufwendig ist es und wie hoch die
>> Wahrscheinlichkeit, dass sicherheitsrelevante Fehler unbemerkt bleiben.
>>
>> #include <stdio.h>
>>
>> char buf[10000];
>> FILE *fp;
>>
>> fp = fopen("foobar", "r");
>> fread(buf, 100000, 1, fp);
>> fclose(fp);
>>
>> Einfach nur an einer Stelle eine 0 zuviel angegeben. Dem Compiler ist
>> das egal, der Entwickler sieht es vielleicht nicht.
>
> Wenn ich eine Datei einlese,
> frage ich erst mal die Dateigröße ab.
> Bei einer Textdatei nehme ich p=malloc(len_+8)
> memset(p,0,4); memset(p+len_+4,0,4);
> und read(p+4,len_);
> Um beim scannen etwas vor und zurückschauen zu können.
Ja, dass man es besser machen *kann*, habe ich ja nicht verneint. Es
ging ja bewusst um ein Beispiel, was Probleme aufzeigen soll.
Ein anderes Beispiel sind Rekursionen, wo jede rekursiv aufgerufene
Funktion durch lokale Variablen Platz auf dem Stack belegt und der Stack
irgendwann überläuft, weil die Rekursion zu tief wird. Selbst wenn die
Rekursion eine Abbruchbedingung hat, die auch irgendwan eintritt, kann
der Stack dennoch zu klein sein.
--
Arno Welzel
https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-05-06 14:00 +0200 |
| Message-ID | <l9rv2hF9loqU1@mid.individual.net> |
| In reply to | #44521 |
Am 06.05.24 um 10:34 schrieb Arno Welzel: > Ein anderes Beispiel sind Rekursionen, wo jede rekursiv aufgerufene > Funktion durch lokale Variablen Platz auf dem Stack belegt und der Stack > irgendwann überläuft, weil die Rekursion zu tief wird. Selbst wenn die > Rekursion eine Abbruchbedingung hat, die auch irgendwann eintritt, kann > der Stack dennoch zu klein sein. Eigener virtueller stack. stack_anfang=malloc (halber_RAM Speicher + swap space ); Wenn dann ein 20 TB HD-Platte als swap verwendet wird, könnte es bis zum Überlauf etwas dauern. -- <http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2024-05-05 19:57 +0200 |
| Message-ID | <slrnv3fi4g.17hrh.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #44495 |
On 2024-05-05 14:34, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) schrieb oder zitierte:
>>poc@pocnet.net schrieb oder zitierte:
>>>Vielleicht ist das blauäugug von mir, aber ich bin mir sicher, dass
>>>man auch in C sauber und sicher programmieren kann.
>>Diese Meinung sollte jeder teilen, der eine Sprache wie Python
>>empfiehlt, denn Python /ist/ ja in C geschrieben. Wenn es nicht
>
> Aber ich meine, daß es zum Beispiel in Standard-C nicht gesagt
> wird, wieviel Stapel überhaupt zur Verfügung steht [1].
> Dadurch hat man schon ein ernsthaftes Problem.
>
> Und Python hat dieses Problem in gewissem Sinne von C geerbt [2].
>
> Damit sind diese Sprachen nicht /per se/ "sicher",
Definiere "sicher".
hp
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2024-05-06 12:06 +0000 |
| Message-ID | <v1ah3g$2i1pa$1@dont-email.me> |
| In reply to | #44495 |
Stefan Ram <ram@zedat.fu-berlin.de> schrieb:
> ram@zedat.fu-berlin.de (Stefan Ram) schrieb oder zitierte:
>>poc@pocnet.net schrieb oder zitierte:
>>>Vielleicht ist das blauäugug von mir, aber ich bin mir sicher, dass man auch
>>>in C sauber und sicher programmieren kann.
>>Diese Meinung sollte jeder teilen, der eine Sprache wie Python
>>empfiehlt, denn Python /ist/ ja in C geschrieben. Wenn es nicht
>
> Aber ich meine, daß es zum Beispiel in Standard-C nicht gesagt
> wird, wieviel Stapel überhaupt zur Verfügung steht [1].
> Dadurch hat man schon ein ernsthaftes Problem.
Und das nervt durchaus. Irgendjemand war anscheinend mal der
Meinung, Stack sei eine knappe Ressource, und man müsste Programme
auf höchst unangenehme Art und Weise abbrechen, wenn er (wie du
sagt) an irgendeiner, spezifizierten und kaum zu kontrolliernde
Grenze abbricht. Wer große Variablen hat, soll sie gefälligst
auf dem Heap ablegen.
Nun sind Variablen auf dem Stack deutlich Cache-freundlicher.
Ein Stack ist das ein linearer Adressraum, bei dem weniger Cache-
Kollisionen stattfinden sollten als auf einem Heap, bei dem man
viel weniger Informationen hat und bei dem Variablen verschiedener
Größen aus verschiedenen Blöcken kommen - d.h. bei
foo()
{
bar();
baz();
}
bar()
{
p = malloc(900);
... tue was mit dem Block
free(p);
}
baz()
{
p = malloc(450);
q = malloc(450);
... tue was mit den Blöcken
free(q);
free(p);
}
werden bar() und baz() vermutlich auf unterschiedliche Teile des
Heaps zugreifen. Die arme CPU weiß aber nichts davon, dass die
Daten, die von bar() reingeschrieben wurden, nicht mehr verwendet
werden und hält sie immer noch in der Cache-Hierarchie vor.
Dafür wirft dann der Aufruf von baz() Daten raus, die man später
mit einer ziemlichen Wahrscheinlichkeit brauche kann. Alles
außer den L1-Caches sind mittlerweile laaaangsam, und die L1-Caches
werden aus physikalischen Gründen kaum größer.
Würde ein Konstrukt wie alloca() verwendet (GNU extension), was den
Speicher auf dem Stack allokiert, dann würde die CPU glücklich mit
den Werten in baz() die von bar() verwenden, und die Sache wäre
deutlich performanter.
Aber alloca() oder Vergleichbares kann man nur sehr eingeschränkt benutzen,
weil es böse ist, und es ist böse, weil Stacks ja bekanntlich klein
sind,
Irgendjemand mal der Meinung war, große Stacks würde sowieso
niemand brauchen und zu viel Stackgebrauch könnte nur von falschen
Programmen kommen, weil ja keiner alloca() verwendet, weil die Stacks
so klein sind, weil ja keiner alloca() verwendet, weil ja keiner
alloca() verwendet, weil Speicherzugriffsfehler (Speicherabzug geschrieben)
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2024-05-06 19:29 +0200 |
| Subject | C (was: Triumph of the Nerds) |
| Message-ID | <slrnv3i4rn.1b1lf.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #44529 |
On 2024-05-06 12:06, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Stefan Ram <ram@zedat.fu-berlin.de> schrieb:
>> Aber ich meine, daß es zum Beispiel in Standard-C nicht gesagt
>> wird, wieviel Stapel überhaupt zur Verfügung steht [1].
>> Dadurch hat man schon ein ernsthaftes Problem.
>
> Und das nervt durchaus. Irgendjemand war anscheinend mal der
> Meinung, Stack sei eine knappe Ressource,
ACK. Und ich verstehe nicht, warum. In der klassischen
Unix-Implementation wächst der Heap von unten nach oben und der Stack
von oben nach unten. Irgendwann treffen sie sich dann in der Mitte. Aus
meiner Sicht ist das total symmetrisch und ich sehe keinen Grund, warum
man den Stack künstlich in der Größe beschränken sollte. Hat aber meiner
Erinnerung nach fast jede Unix-Implementation, mit der ich gearbeitet
habe, gemacht.
Bei Threads ist das unvermeidlich: Sobald ein zweiter Thread dazukommt,
braucht der einen eigenen Stack und den muss man irgendwo platzieren und
damit schränkt man die Größe mindestens eines der beiden Threads ein.
Aber Threads sind kein Ur-Unix-Feature, die sind erst später
dazugekommen.
> Würde ein Konstrukt wie alloca() verwendet (GNU extension), was den
> Speicher auf dem Stack allokiert, dann würde die CPU glücklich mit
> den Werten in baz() die von bar() verwenden, und die Sache wäre
> deutlich performanter.
In Standard C gibt es stattdessen Variable Length Arrays (VLAs).
Haben aber natürlich genau das gleiche Problem, weil das eigentlich kein
C-Problem ist, sondern ein Unix-Problem.
hp
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-05-07 06:49 +0200 |
| Subject | Re: C |
| Message-ID | <l9tq7dFi63aU1@mid.individual.net> |
| In reply to | #44540 |
Am 06.05.24 um 19:29 schrieb Peter J. Holzer:
> On 2024-05-06 12:06, Thomas Koenig <tkoenig@netcologne.de> wrote:
>> Stefan Ram <ram@zedat.fu-berlin.de> schrieb:
>>> Aber ich meine, daß es zum Beispiel in Standard-C nicht gesagt
>>> wird, wieviel Stapel überhaupt zur Verfügung steht [1].
>>> Dadurch hat man schon ein ernsthaftes Problem.
>>
>> Und das nervt durchaus. Irgendjemand war anscheinend mal der
>> Meinung, Stack sei eine knappe Ressource,
>
> ACK. Und ich verstehe nicht, warum. In der klassischen
> Unix-Implementation wächst der Heap von unten nach oben und der Stack
> von oben nach unten. Irgendwann treffen sie sich dann in der Mitte.
Vor swap?
heap und stack haben virtuellen Adressraum
Ich vermute der maximale stack-Platz ( nicht Unterprogramm Tiefe)
durch Speicherplatz Verletzung abgefangen wurde.
Einfach aus Geschwindigkeitsgründen um weiter Abfrage zu vermeiden.
> Aus meiner Sicht ist das total symmetrisch und ich sehe keinen Grund, warum
> man den Stack künstlich in der Größe beschränken sollte.
Wegen Programme vom Typ:
void mist() {mist();};
--
<http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2024-05-07 06:30 +0000 |
| Subject | Re: C |
| Message-ID | <v1chqe$33nou$2@dont-email.me> |
| In reply to | #44552 |
Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb:
> Am 06.05.24 um 19:29 schrieb Peter J. Holzer:
>> Aus meiner Sicht ist das total symmetrisch und ich sehe keinen Grund, warum
>> man den Stack künstlich in der Größe beschränken sollte.
>
> Wegen Programme vom Typ:
>
> void mist() {mist();};
Mehr oder weniger schädlich als
while (1)
{
p = malloc(1024);
/* Do stuff with p, but do not free it */
}
?
(Wie upthread geschrieben, können große Stacks sehr sinnvoll sein.
Endlosschleifen, die Speicher allokieren, sind genauso problematisch
wie Endlos-Rekursionen. Solange der Stack nicht so groß wird, dass
das ganze System in die Knie geht, ist ein großer Stack auch nicht
schlimmer als ein großer Heap.)
Und noch ein anderer Punkt - der Stack wird automatisch
aufgeräumt, da braucht man kein free(). Das ist natürlich
nur für Programmiersprachen relevant, die solche Features nicht
automatisch haben und wo die Runtime das übernimmt.
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-05-07 09:42 +0200 |
| Subject | Re: C |
| Message-ID | <l9u4biFjkjcU1@mid.individual.net> |
| In reply to | #44557 |
Am 07.05.24 um 08:30 schrieb Thomas Koenig:
> Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb:
>> Am 06.05.24 um 19:29 schrieb Peter J. Holzer:
>
>>> Aus meiner Sicht ist das total symmetrisch und ich sehe keinen Grund, warum
>>> man den Stack künstlich in der Größe beschränken sollte.
>>
>> Wegen Programme vom Typ:
>>
>> void mist() {mist();};
>
> Mehr oder weniger schädlich als
>
> while (1)
> {
> p = malloc(1024);
> /* Do stuff with p, but do not free it */
> }
>
Schädlich?
void *p;
size_t l:
p=(void *)&l
l=1024;
while(p){
l*=2;
p=malloc(l);
free (p);
printf("%llX\n",l);
Mit derartigen habe ich früher nachgeschaut,
wie viel Speicher ich verwenden kann.
Bei OS/2 war es nur halb so viel wie bei Linux oder windows.
( Beim ersten Versuch unter OS/2 hat das System kapituliert.
Von Firmen wie IBM .. )
Eine Zeit lang ging das unter Linux sehr schnell.
Bis ich zwischen malloc und free noch memset(p,0,l); einfügte.
Das dauerte dann mit großen swap Bereichen sehr lange.
Hermann
gelegentlich unanständiger Experimental Hobbyinformatiker.
--
<http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2024-05-06 18:55 +0200 |
| Message-ID | <v1b93o.5l4.1@stefan.msgid.phost.de> |
| In reply to | #44495 |
Am 05.05.2024 um 13:22 schrieb poc@pocnet.net: > Stefan Reuther <stefan.news@arcor.de> wrote: >> Ja, Python weiß das, weil jemand ein C-Programm geschrieben hat, dass >> diese Informationen mitführt und überprüft. Deswegen ist "verbietet C" >> weder möglich noch sinnvoll. > > Philiosophisch gesehen ist in diesem Beispiel Python die Abstraktionsschicht, > die durch ihr Vorhandensein und die ihr programmierten Aufgaben wiederum > Ressourcen (RAM, CPU) braucht und damit mehr oder weniger "schlimm" das > verursacht, was ein Teil der Gruppenmitglieder hier als "Bloat" verteufelt. > > Dazu kommt, dass jeglicher Code, der vorhanden ist, potentiell Bugs hat und > damit eine zusätzliche Angriffsfläche bietet. > > Vielleicht ist das blauäugug von mir, aber ich bin mir sicher, dass man auch > in C sauber und sicher programmieren kann. Dazu braucht es IMHO Disziplin, > Umsicht und Kenntnisse, und man könnte sich den Bloat durch "wir nehmen dem > Programmierer einmalig beim Programmieren das Denken ab und führen den > zusätzlichen Bloat dann beim Kunden tausendfach aus" deutlich reduzieren. CPU-Zeit ist halt billiger als Entwicklerzeit. Und der Entwickler, der C sauber und sicher programmieren kann, ist noch mal deutlich teurer als der Java-, C#- oder Python-Entwickler, der von seiner Runtime an die Hand genommen wird. http://altlasten.lutz.donnerhacke.de/mitarb/lutz/usenet/Fachbegriffe.der.Informatik.html#348 >> Auch wenn ich dem letzten Satz zustimme, ist das aber kein Gewinn bezüglich >> Sicherheit oder Komplexität. > > Aus Komplexitätssicht definitiv nicht, und aus Sicht von Bloat ist Node von > dem bisschen was ich mitbekommen habe eine mittlere Katastrophe. > > Ein Beispiel: Webentwickler hat in Node ein Programm geschrieben, was per ODBC > auf einen MSSQL-Server zugreift, den Kundenstamm ausliest und per ODBC in eine > DB2-Datenbank schiebt. Mit vorherigem Löschen der Tabelleninhalte auf > DB2-Seite. Das Node-Script lief ca. 10 Minuten und brauchte etliche 100MB an > RAM. [...] > Ich habe mich einen Nachmittag hingesetzt und das in Perl neu geschrieben. Node ist erstmal nur ein JavaScript-Interpreter, und ein ziemlich flinker noch dazu. Zur Erinnerung: sogar ein JavaScript-Interpreter im Browser ist inzwischen schnell genug, eine CPU zu emulieren, die ein Windows 2000 bootet, das einen Browser startet, in dem JavaScript ausgeführt wird (https://bellard.org/jslinux/). Gerade bei Node ist aber das Einbauen von Dependencies eskaliert. Ich weiß nicht, ob das Performance-Kunst oder Resume-Padding ist, aber: es gibt ein Modul 'is-even' (https://www.npmjs.com/package/is-even), das dependet auf 'is-odd' (https://www.npmjs.com/package/is-odd), das wiederum dependet auf 'is-number' (https://www.npmjs.com/package/is-number). 'is-even' hat 146k wöchentliche Downloads und 12 Commits, 'is-number' hat 64M wöchentliche Downloads, 62 Commits und steht auf Version 7.0.0. Also ist es Stand der Technik, sich bei Stackoverflow die passenden Module zusammenzuklicken. Bei Perl ist das einfach nie so eskaliert. Selbst mit CPAN nicht, und meistens komme ich ohne aus. Stefan
[toc] | [prev] | [next] | [standalone]
| From | poc@pocnet.net |
|---|---|
| Date | 2024-05-06 21:03 +0000 |
| Message-ID | <l9suslFe83jU3@mid.individual.net> |
| In reply to | #44539 |
Stefan Reuther <stefan.news@arcor.de> wrote: >> Vielleicht ist das blauäugug von mir, aber ich bin mir sicher, dass man auch >> in C sauber und sicher programmieren kann. Dazu braucht es IMHO Disziplin, >> Umsicht und Kenntnisse, und man könnte sich den Bloat durch "wir nehmen dem >> Programmierer einmalig beim Programmieren das Denken ab und führen den >> zusätzlichen Bloat dann beim Kunden tausendfach aus" deutlich reduzieren. > > CPU-Zeit ist halt billiger als Entwicklerzeit. So scheint es. IMHO nur wenn man mal wieder die Augen vor den realen "Kosten" verschließt. -- :wq! PoC
[toc] | [prev] | [next] | [standalone]
Page 7 of 14 — ← Prev page 1 … 5 6 [7] 8 9 … 14 Next page →
Back to top | Article view | de.alt.folklore.computer
csiph-web