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 2 of 14 — ← Prev page 1 [2] 3 4 … 14 Next page →
| From | Sebastian Barthel <naitsabes@freenet.de> |
|---|---|
| Date | 2024-04-30 13:11 +0000 |
| Message-ID | <v0qql6$6voh$1@solani.org> |
| In reply to | #44419 |
Am Tue, 30 Apr 2024 13:33:47 +0200 schrieb F. W.: > Am 24.04.2024 um 22:53 schrieb poc@pocnet.net: > >>> Gefährdet waren die Mehrplatzsysteme wie die IBM/36 bzw. später die >>> AS/400. >> >> Warum? >> >> > In den Markt zielten Novell bzw. Microsoft. Und es gilt der Spruch aus > "Jurassic Park", dass man doch ganz viele Computer mit ganz wenig > Personal fahren kann. Das war das Versprechen. Das wird auch mal irgendwann passieren. Irgendwann wird man solche Komplett-Blobs ala Container aufspielen und spätestens wenn sich das irgendwie im "BIOS" breit macht, daß die Maschine sich sowas selbsttätig runterlädt (nicht das BIOS Update sondern das OS inkl Anwendungen), werden die Leute es auch einfach einschalten und nutzen. Strenggenommen gibt es das ja schon, nur eben nicht vollatuomatisch und Consumerfreundlich. Dann braucht es nur noch ein kleines Team von "Administratoren", nämlich die, diese dicken Pakete zusammenstellen. >>> Und die hat ja auch gelitten. >> >> Was genau meinst Du damit? >> >> > Der AS/400-Markt ging stark zurück. Obwohl man sie zuletzt als Server > nutzen konnte und Linux drauf lief. Es galt der Billigheimer mit > Klickibunti. > > Eine Verwaltung, die ich damals betreute und der ich riet, bei der > AS/400 zu bleiben, hat heute lauter Windows-Terminals. Grund: > Administration von vielen Einplatzsystemen wurde viel zu teuer. Das spricht ja noch nichtmal gegen die AS/400 - nur gegen deren Verwaltungstools. Hätten ja mal bei Sun einkaufen gehen könne, dort ging sowas (soweit ich weiß). Und wahrscheinlich hätte das sogar klappen können, weil dies Gerät und der Sun Markt sich eher nicht direkt im Wege standen und Sun eigentlich (irgendwann) schon daran interessiert war, seine Software überall hin zu drücken, was leider nicht wirklich geklappt hat, trotz verschenktem (sehr guten) OS und Office und Intel Lauffähigkeit. Gruß SBn
[toc] | [prev] | [next] | [standalone]
| From | poc@pocnet.net |
|---|---|
| Date | 2024-05-01 11:15 +0000 |
| Message-ID | <l9emi5F9q93U2@mid.individual.net> |
| In reply to | #44420 |
Sebastian Barthel <naitsabes@freenet.de> wrote: >> In den Markt zielten Novell bzw. Microsoft. Und es gilt der Spruch aus >> "Jurassic Park", dass man doch ganz viele Computer mit ganz wenig >> Personal fahren kann. Das war das Versprechen. > > Das wird auch mal irgendwann passieren. Eher nicht. > Irgendwann wird man solche Komplett-Blobs ala Container aufspielen und > spätestens wenn sich das irgendwie im "BIOS" breit macht, daß die Maschine > sich sowas selbsttätig runterlädt (nicht das BIOS Update sondern das OS inkl > Anwendungen), werden die Leute es auch einfach einschalten und nutzen. > > Strenggenommen gibt es das ja schon, nur eben nicht vollatuomatisch und > Consumerfreundlich. > > Dann braucht es nur noch ein kleines Team von "Administratoren", nämlich > die, diese dicken Pakete zusammenstellen. Und wer kümmert sich um die vielen Fehler, die in den Einzelteilen der "Pakete" stecken? Wenn ich mir so angucke, in welche Richtung der Softwaretrend geht, dann stimme ich Deiner Einschätzung absolut nicht zu. Alles wird immer größer, komplexer, undsurchsichtiger, mit immer noch mehr Abstraktionsschichten, mit "agile", um die neuen Bugs noch schneller zum Kunden zu kriegen. Das Ganze hinreichend einzuhegen und so hinzubiegen dass die Anwender damit auch abseits der theoretisch tollen Ideen der Antwickler arbeiten können wird immer eine gewisse Menge an Personal erfordern. Und mit zunehmender Komplexität auch welches was mehr als nur "müssen wir neu installieren" kann. -- :wq! PoC
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Barthel <naitsabes@freenet.de> |
|---|---|
| Date | 2024-05-02 18:49 +0000 |
| Message-ID | <v10n7i$a01k$2@solani.org> |
| In reply to | #44439 |
Am Wed, 01 May 2024 11:15:17 +0000 schrieb poc: > Sebastian Barthel <naitsabes@freenet.de> wrote: > >>> In den Markt zielten Novell bzw. Microsoft. Und es gilt der Spruch aus >>> "Jurassic Park", dass man doch ganz viele Computer mit ganz wenig >>> Personal fahren kann. Das war das Versprechen. >> >> Das wird auch mal irgendwann passieren. > > Eher nicht. > >> Irgendwann wird man solche Komplett-Blobs ala Container aufspielen und >> spätestens wenn sich das irgendwie im "BIOS" breit macht, daß die >> Maschine sich sowas selbsttätig runterlädt (nicht das BIOS Update >> sondern das OS inkl Anwendungen), werden die Leute es auch einfach >> einschalten und nutzen. >> >> Strenggenommen gibt es das ja schon, nur eben nicht vollatuomatisch und >> Consumerfreundlich. >> >> Dann braucht es nur noch ein kleines Team von "Administratoren", >> nämlich die, diese dicken Pakete zusammenstellen. > > Und wer kümmert sich um die vielen Fehler, die in den Einzelteilen der > "Pakete" > stecken? Die sind dann vielleicht immer noch da, aber das Ganze hat immerhin den Charme, daß man erstmal getestet lauffähige Systeme ausliefert. > Wenn ich mir so angucke, in welche Richtung der Softwaretrend geht, dann > stimme ich Deiner Einschätzung absolut nicht zu. Alles wird immer > größer, komplexer, undsurchsichtiger, mit immer noch mehr > Abstraktionsschichten, mit "agile", um die neuen Bugs noch schneller zum > Kunden zu kriegen. > > Das Ganze hinreichend einzuhegen und so hinzubiegen dass die Anwender > damit auch abseits der theoretisch tollen Ideen der Antwickler arbeiten > können wird immer eine gewisse Menge an Personal erfordern. Und mit > zunehmender Komplexität auch welches was mehr als nur "müssen wir neu > installieren" kann. Ich stimme ja voll zu, daß es eigenartig ist, daß da immer noch ein Layer draufgepackt wird und man so immer mehr "Zeug" anhäuft. Letztlich wird das aber nicht endlos so gehen können. Vielleicht wird sowas ja auch mal automatisiert (KI (?)) bereinigt und wieder auch eine Basis zurückgeschrieben. Wahrscheinlicher ist aber wohl wirklich, daß es erstmal noch eine Weile so weitergeht, denn RAM und Rechenleistung sind ja da.
[toc] | [prev] | [next] | [standalone]
| From | poc@pocnet.net |
|---|---|
| Date | 2024-05-02 21:14 +0000 |
| Message-ID | <l9ie2gFqlffU1@mid.individual.net> |
| In reply to | #44457 |
Sebastian Barthel <naitsabes@freenet.de> wrote:
>> Und wer kümmert sich um die vielen Fehler, die in den Einzelteilen der
>> "Pakete" stecken?
>
> Die sind dann vielleicht immer noch da, aber das Ganze hat immerhin den
> Charme, daß man erstmal getestet lauffähige Systeme ausliefert.
Die Frage ist dann, an wem die Tests dann hängen bleiben. Ich habe ein ganz
ganz schlechtes Bild von der modernen Art Software zu entwickeln, von der
massiven Updatefrequenz die den Anwendern zugemutet wird und der Qualität
dessen was die Anwender an Fehlern und UI-Grausamkeiten erdulden müssen.
>> Das Ganze hinreichend einzuhegen und so hinzubiegen dass die Anwender
>> damit auch abseits der theoretisch tollen Ideen der Antwickler arbeiten
>> können wird immer eine gewisse Menge an Personal erfordern. Und mit
>> zunehmender Komplexität auch welches was mehr als nur "müssen wir neu
>> installieren" kann.
>
> Ich stimme ja voll zu, daß es eigenartig ist, daß da immer noch ein Layer
> draufgepackt wird und man so immer mehr "Zeug" anhäuft.
Das ist nicht eigenartig, das ist ein "hammer schon immer so gemacht".
Komplexität wird immer nur weiter versteckt. Das geht so lange gut, wie alles
Hand in Hand zusammenarbeitet und tut...
> Letztlich wird das aber nicht endlos so gehen können.
Tja, die Frage ist: Was wird passieren?
Ich hoffe dass wenn es passiert, ich eines hoffentlich natürlichen Todes
gestorben sein werde. Wir machen uns immer abhängiger von Hard- und Software
und seit einigen Jahren zunehmend von Infrastruktur ("Cloud"), deren
Wackeligkeit und Anfälligkeit gegen Angriffe mehrfach bewiesen wurde.
> Vielleicht wird sowas ja auch mal automatisiert (KI (?)) bereinigt und
> wieder auch eine Basis zurückgeschrieben.
KI, die Zaubertechnologie, die in Zukunft alle Probleme lösen könnte. Ich bin
froh, dass an der Tech-Front hier endlich mal ganz langsam gesunde
Ernüchterung zu Tage tritt. Aber bis dahin werden noch viele Unternehmen
versuchen auf den Zug aufzuspringen um sich ihr Stück vom Kuchen zu sichern.
> Wahrscheinlicher ist aber wohl wirklich, daß es erstmal noch eine Weile so
> weitergeht, denn RAM und Rechenleistung sind ja da.
Ja, definitiv. Aber gleichzeitig erhöht sich die Angriffsfläche durch mehr
Code. Es bleibt spannend.
--
:wq! PoC
[toc] | [prev] | [next] | [standalone]
| From | poc@pocnet.net |
|---|---|
| Date | 2024-05-02 21:16 +0000 |
| Message-ID | <l9ie4kFqlffU2@mid.individual.net> |
| In reply to | #44457 |
Stefan Ram <ram@zedat.fu-berlin.de> wrote: > Ich halte C und C++ für großartige und unverzichtbare Sprachen > (man muß sehen, inwiefern Rust oder Go ein Ersatz sein können), > aber für sie muß man richtig ausgebildet und ausgewählt worden sein! > > Dann wird C++ damit beworben, daß gleichwertige Software in C++ in > der Regel weniger Energie verbraucht als in höheren Sprachen (weniger > Schichten). Ja, das ist ein starkes Argument für C++ bei immer mehr > exergiehungrigen Rechenzentren. Aber man muß C++ eben auch können. Danke. Du sprichst mir aus der Seele. -- :wq! PoC
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2024-05-03 07:46 +0000 |
| Message-ID | <v124ok$duum$1@dont-email.me> |
| In reply to | #44457 |
Stefan Ram <ram@zedat.fu-berlin.de> schrieb:
> Sebastian Barthel <naitsabes@freenet.de> wrote or quoted:
>>Ich stimme ja voll zu, daß es eigenartig ist, daß da immer noch ein Layer
>>draufgepackt wird und man so immer mehr "Zeug" anhäuft.
>
> Ein Beispiel wäre die Speicherverwaltung.
>
> C hat eine Speicherverwaltung, bei welcher der Programmierer
> viel arbeiten muß und viel falsch machen kann.
So isses.
> Nun wurde ja neulich eine Warnung aus der Regierung der
> Vereinigten Staaten vor solchen Sprachen wie C bekannt.
> Sie seien fehlerträchtig und daher riskant.
Und recht haben sie...
> Python hat eine Speicherverwaltung, die auf der von C aufbaut,
> aber vieles automatisiert. Sie ist für Programmierer einfacher
> und weniger fehlerträchtig. Also eine Art von "Schicht".
Python als interpretierte Sprache ist allerdings extrem langsam, wenn
nicht gerade compilierter C-Code aufgerufen wird - da ist mal schnell
ein Faktor von 100 drin.
> Für mich paßt es nicht ganz, wenn eine Regierung, sich "per
> Mikromanagement" in die Wahl von Programmiersprachen einmischt.
Sie schreiben es ja auch nicht vor (könnten sie gar nicht, außer
für Regierungsaufträge, und wie gut da funktioniert hat, hat man
ja bei Ada gesehen...)
> Aber man könnte auch sagen, daß die EDV-Abteilungen eine Menge
> falsch machen müssen, bevor eine Regierung sich so weit herabläßt!
Machen sie.
> Zwei Fehler, die ich sehe:
>
> 1.) (Besonders früher) C und C++ wurden für Anfängerkurse
> eingesetzt, wodurch der falsche Eindruck entstand,
> daß es einfach beherrschbare Sprachen seien.
>
> 2.) In der Folge wurden vielleicht Programmierer an C-Projekte
> gelassen, die dafür nicht richtig ausgebildet waren.
>
> Heute werden solche Fehler etwas korrigiert, indem mehr Python
> eingesetzt wird.
Python ist aus Effizienzgründen keine vernünftige Lösung, einfach
zu langsam. Es gibt genügend andere Sprachen, die Fehler in der
Speicherverwaltung und Buffer overruns durch Features in der Sprache
zbw. Compilerflags vermeiden können und trotzdem als kompilierte
Sprachen (entweder von Anfang an oder JIT) effizienter sind.
Vielleicht ein weniger bekanntes Beispiel: Fortran hat allocatable
arrays, die automatisch deallkokiert werden, wenn sie out of
scope gehen. Außerdem können da Arraygrenzen automatisch übergeben
werden. Beispiel:
subroutine foo()
integer :: n
real, allocatable, dimension(:) :: b
read (*,*) n
allocate b(n)
! ... do stuff
write (*,*) b
end subroutine foo
Dabei wird b vom Compiler automatisch deallokiert.
Damit ist "use after free" vermeidbar.
>
> Ich halte C und C++ für großartige und unverzichtbare Sprachen
C++ ist sehr mächtig, leidet aber unter feature stampede. Die ganze
Sprache zu verstehen, ist für Normalmenschen praktisch unmöglich.
> (man muß sehen, inwiefern Rust oder Go ein Ersatz sein können),
> aber für sie muß man richtig ausgebildet und ausgewählt worden sein!
Naja, jedes Projekt sollte sich vernünftigerweise auf eine Untermenge
von C++ beschränken, sonst wird es uferlos. Und jeder nimmt eine
andere Untermenge...
Und sichere Speicherverwaltung, mehrdimensionale Arrays o.ä. wird dann
wieder über Klassen definiert, die im Zweifelsfall schlecht gewartet
und inkompatibel sind.
> Dann wird C++ damit beworben, daß gleichwertige Software in C++ in
> der Regel weniger Energie verbraucht als in höheren Sprachen (weniger
> Schichten). Ja, das ist ein starkes Argument für C++ bei immer mehr
> exergiehungrigen Rechenzentren. Aber man muß C++ eben auch können.
Die Klassen erzeugen über den vptr erst mal zusäztlichen Aufwand.
Aber wenn du C++ in der neuesten Version vollumfänglich
beherrschst, dann bist du einer der ganz Wenigen auf dieser Welt,
vermutlich an zwei Händen abzählbar (evtl. im Binärsystem).
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2024-05-03 20:21 +0200 |
| Message-ID | <slrnv3aaog.vote.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #44465 |
On 2024-05-03 07:46, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Python ist aus Effizienzgründen keine vernünftige Lösung, einfach
> zu langsam.
Kommt darauf an, was man macht. Fast alle meinen Python-Programme
verbringen 90+% der Zeit damit, zu warten - auf den Benutzer, auf das
Netzwerk, auf die Datenbank ... Wenn ich die in C neu schreiben würde,
würden sie um maximal 10 % schneller werden (Amdahls Law).
hp
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2024-05-03 22:03 +0200 |
| Message-ID | <l9ku8lF7n2pU4@mid.individual.net> |
| In reply to | #44457 |
Stefan Ram, 2024-05-02 21:11: > Sebastian Barthel <naitsabes@freenet.de> wrote or quoted: >> Ich stimme ja voll zu, daß es eigenartig ist, daß da immer noch ein >> Layer draufgepackt wird und man so immer mehr "Zeug" anhäuft. > > Ein Beispiel wäre die Speicherverwaltung. > > C hat eine Speicherverwaltung, bei welcher der Programmierer viel > arbeiten muß und viel falsch machen kann. Genau genommen hat C *keine* Speicherverwaltung. Genau das ist ja das Problem. malloc() und free() sind keine Sprachkonstrukte von C sondern nur Aufrufe an das Betriebssystem, für die Prozess eine Speicherblock mit einer bestimmten Größe zu reservieren. Die Größe des Blockes zu beachten, wenn man z.B. Daten dort hin schreiben lässt, obliegt allein dem Programmierer. C selbst ist völlig egal, ob der Programmierer in einen 10 KB großen Block versucht, 20 KB Daten aus einer Datei abzulegen. Ebenso gibt es in C keine echten Strings, sondern nur Pointer auf Speicheradressen. Ein String ist nur durch ein 0-Byte terminiert - aber es keinerlei Information darüber, wie lang der String maximal werden darf und Funktionen wie strcpy() kopieren einfach so lange wie es geht, egal ob der Zielbuffer groß genug ist oder nicht. Im günstigsten Fall hindert das Betriebssystem Zugriff auf Speicherbereiche, die er Prozess nicht hat (unter Windows ist das dann die berüchtigte "Allgemeine Schutzverletzung"). Im ungünstigsten Fall überschreibt das Programm dann seine eigenen Daten oder Code, der sich den Speicher mit Daten teilt - das wiederum ist ein klassischer Angriff, weil ein Angreifer mit Pufferüberlauf auch eigenen Code einschleusen kann. > Nun wurde ja neulich eine Warnung aus der Regierung der Vereinigten > Staaten vor solchen Sprachen wie C bekannt. Sie seien fehlerträchtig > und daher riskant. Ja, zurecht. > Python hat eine Speicherverwaltung, die auf der von C aufbaut, aber > vieles automatisiert. Sie ist für Programmierer einfacher und weniger > fehlerträchtig. Also eine Art von "Schicht". Zumindest *weiß* Python wie groß Speicherblöcke sind und kennt auch Garbage Collection. Das ist um Größenordnungen zuverlässiger als C. Zudem wurde Python ursprünglich nicht dafür entwickelt, compiliert, sondern interpretiert zu werden. Die Standardimplementierung ist CPython - ein Interpreter, der Aufrufe von C-Bibliotheksfunktionen aus Python heraus erlaubt. > Für mich paßt es nicht ganz, wenn eine Regierung, sich "per > Mikromanagement" in die Wahl von Programmiersprachen einmischt. Aber > man könnte auch sagen, daß die EDV-Abteilungen eine Menge falsch > machen müssen, bevor eine Regierung sich so weit herabläßt! Solange etwas nicht per Gesetz reguliert wird, wird vieles falsch gemacht, weil es eben billiger ist. Sicherheitsgurte und Zulassungen für den Straßenverkehr waren vor vielen Jahrzehnten auch nicht vorgeschrieben. Die Zahl der Verkehrstoten hat dann aber doch dazu geführt, dass man Standards vorgegeben hat - das hätten die Autohersteller auch selber machen können, aber niemand hätte für ein Auto mehr Geld bezahlt, nur weil es "sicherer" ist oder einen Sicherheitsgurt verlangt, weil er gehört hat, dass das im Falle eines Unfalls mutmaßlich Leben retten könnte. > Zwei Fehler, die ich sehe: > > 1.) (Besonders früher) C und C++ wurden für Anfängerkurse eingesetzt, > wodurch der falsche Eindruck entstand, daß es einfach beherrschbare > Sprachen seien. An welchen "Anfängerkurse" denkst Du hier? BASIC wurde bereits 1964 entwickelt und wesentlich häufiger gerade im Bereich von Schule und Ausbildung für "Anfänger" genutzt. Wenn es etwas anspruchsvoller sein sollte, dann Pascal, was auch schon 1972 explizit als Lehrsprache entwickelt wurde. Heutzutage ist es eher Java oder Kotlin. Aber das C oder C++ in "Anfängerkursen" vorkommt, habe ich selten erlebt. > 2.) In der Folge wurden vielleicht Programmierer an C-Projekte > gelassen, die dafür nicht richtig ausgebildet waren. > > Heute werden solche Fehler etwas korrigiert, indem mehr Python > eingesetzt wird. > > Ich halte C und C++ für großartige und unverzichtbare Sprachen (man > muß sehen, inwiefern Rust oder Go ein Ersatz sein können), aber für > sie muß man richtig ausgebildet und ausgewählt worden sein! C ist ein etwas besserer Makroassembler (Makros hat C ja auch von Assemblern übernommen) und C++ baut im Kern auf C auf und erbt damit auch alle "Schweinereien" von C. Einzig durch Code-Analyse von Compilern hofft man, die größten Löcher schon vor dem Einsatz des Programms finden zu können. Aber die ganzen Schichten mit Templates und STL sind nichts anderes als eine Verschönerung der Syntax ohne echten Sicherheitsgewinn der Sprasche. > Dann wird C++ damit beworben, daß gleichwertige Software in C++ in > der Regel weniger Energie verbraucht als in höheren Sprachen > (weniger Schichten). Ja, das ist ein starkes Argument für C++ bei > immer mehr exergiehungrigen Rechenzentren. Aber man muß C++ eben auch > können. Viele der einst als "langsam" und "ineffizent" betrachtete Sprachen arbeiten mittlerweile mit Compilern, und wenn es auch nur Just-in-time-Compiler sind. Das holt *sehr* viel raus. Node.js oder Kotlin sind durchaus ernstzunehmende Umgebungen. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2024-05-04 07:14 +0000 |
| Message-ID | <v14n7p$135q0$1@dont-email.me> |
| In reply to | #44469 |
Arno Welzel <usenet@arnowelzel.de> schrieb: > Stefan Ram, 2024-05-02 21:11: > >> Sebastian Barthel <naitsabes@freenet.de> wrote or quoted: >>> Ich stimme ja voll zu, daß es eigenartig ist, daß da immer noch ein >>> Layer draufgepackt wird und man so immer mehr "Zeug" anhäuft. >> >> Ein Beispiel wäre die Speicherverwaltung. >> >> C hat eine Speicherverwaltung, bei welcher der Programmierer viel >> arbeiten muß und viel falsch machen kann. > > Genau genommen hat C *keine* Speicherverwaltung. Genau das ist ja das > Problem. Stimmt so nach der C-Norm nicht... > malloc() und free() sind keine Sprachkonstrukte von C sondern nur > Aufrufe an das Betriebssystem, für die Prozess eine Speicherblock mit > einer bestimmten Größe zu reservieren. Die Größe des Blockes zu > beachten, wenn man z.B. Daten dort hin schreiben lässt, obliegt allein > dem Programmierer. Das ist so nicht korrekt. Die Funktionen malloc() und Freunde sind in der C-Norm definiert. Ihr Verhalten ist genauso durch die Norm festgelegt wie das von anderen Sprachkonstrukten (solange sie "external linkage" haben). Die Trennung von Sprache und Library hat für freestanding implementations noch einen Sinn, weil da sehr viel weniger festgelegt ist, u.a. laufen Programme nicht unbedingt mit main() los, und die ganzen Library-Funktionen müssen nicht vorhanden sein. Für hosted implementations hingegen ist der Unterschied zwischen Sprache und Library faktisch bedeutungslos und nur historisch bedingt. > C selbst ist völlig egal, ob der Programmierer in einen 10 KB großen > Block versucht, 20 KB Daten aus einer Datei abzulegen. Das ist "undefined behavior", damit ist es (vereinfacht :-) verboten, insofern ist es nicht egal. > Ebenso gibt es in > C keine echten Strings, sondern nur Pointer auf Speicheradressen. Ein > String ist nur durch ein 0-Byte terminiert - aber es keinerlei > Information darüber, wie lang der String maximal werden darf und > Funktionen wie strcpy() kopieren einfach so lange wie es geht, egal ob > der Zielbuffer groß genug ist oder nicht. Das ist richtig. > > Im günstigsten Fall hindert das Betriebssystem Zugriff auf > Speicherbereiche, die er Prozess nicht hat (unter Windows ist das dann > die berüchtigte "Allgemeine Schutzverletzung"). Im ungünstigsten Fall > überschreibt das Programm dann seine eigenen Daten oder Code, der sich > den Speicher mit Daten teilt - das wiederum ist ein klassischer Angriff, > weil ein Angreifer mit Pufferüberlauf auch eigenen Code einschleusen kann. Leider ist es so. [...] > C ist ein etwas besserer Makroassembler (Makros hat C ja auch von > Assemblern übernommen) und C++ baut im Kern auf C auf und erbt damit > auch alle "Schweinereien" von C. Einzig durch Code-Analyse von Compilern > hofft man, die größten Löcher schon vor dem Einsatz des Programms finden > zu können. Aber die ganzen Schichten mit Templates und STL sind nichts > anderes als eine Verschönerung der Syntax ohne echten Sicherheitsgewinn > der Sprasche. Zustimmung, mit der Einschränkung, dass ich Templates nicht für eine Verschönerung im eigentlichen Sinne halte :-)
[toc] | [prev] | [next] | [standalone]
| From | Michael Kraemer <m.kraemer@gsi.de> |
|---|---|
| Date | 2024-05-04 09:37 +0200 |
| Message-ID | <l9m6unFdq3kU1@mid.individual.net> |
| In reply to | #44477 |
On 04.05.2024 09:14, Thomas Koenig wrote: > > Die Trennung von Sprache und Library hat für freestanding > implementations noch einen Sinn, weil da sehr viel weniger > festgelegt ist, u.a. laufen Programme nicht unbedingt mit main() los, > und die ganzen Library-Funktionen müssen nicht vorhanden sein. > > Für hosted implementations hingegen ist der Unterschied zwischen > Sprache und Library faktisch bedeutungslos und nur historisch > bedingt. Nun sind wir hier ja in einer historischen Gruppe und für historische Systeme gilt nunmal, dass C so gut wie die einzige (oder letztverfügbare) Sprache ist, mit der man noch Software erstellen kann. Die Wahrscheinlichkeit, dass für Ultrix oder auch nur AmigaOS ein aktueller Rust-Compiler (oder ähnlich modernistischer Kram) erscheint, ist ziemlich gering. C hat eben den unschlagbaren Vorteil, dass es für so ziemlich alles verfügbar ist, was Nullen und Einsen verdaut. Da wird man doch nicht wg strcpy() & Co herummeckern. In diesem Zusammenhang ist übrigens sizeof() hilfreich.
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2024-05-04 11:23 +0200 |
| Subject | C (was: Triumph of the Nerds) |
| Message-ID | <slrnv3bvl2.127n3.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #44479 |
On 2024-05-04 07:37, Michael Kraemer <m.kraemer@gsi.de> wrote:
> Nun sind wir hier ja in einer historischen Gruppe und für historische
> Systeme gilt nunmal, dass C so gut wie die einzige (oder
> letztverfügbare) Sprache ist, mit der man noch Software erstellen
> kann.
> Die Wahrscheinlichkeit, dass für Ultrix oder auch nur AmigaOS
> ein aktueller Rust-Compiler (oder ähnlich modernistischer Kram)
> erscheint, ist ziemlich gering.
> C hat eben den unschlagbaren Vorteil, dass es für so ziemlich alles
> verfügbar ist, was Nullen und Einsen verdaut.
ACK.
> Da wird man doch nicht wg strcpy() & Co herummeckern.
> In diesem Zusammenhang ist übrigens sizeof() hilfreich.
Aber nur, wenn die Variable als Array definiert ist. Wenn sie als
Pointer definiert ist, hilft dir sizeof eher wenig.
hp
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-05-04 13:17 +0200 |
| Subject | Re: C |
| Message-ID | <l9mjqgFfjm4U1@mid.individual.net> |
| In reply to | #44481 |
Am 04.05.24 um 11:23 schrieb Peter J. Holzer: >> Da wird man doch nicht wg strcpy() & Co herummeckern. >> In diesem Zusammenhang ist übrigens sizeof() hilfreich. > > Aber nur, wenn die Variable als Array definiert ist. Wenn sie als > Pointer definiert ist, hilft dir sizeof eher wenig. sizeof(*pointer)
[toc] | [prev] | [next] | [standalone]
| From | Michael Kraemer <m.kraemer@gsi.de> |
|---|---|
| Date | 2024-05-04 14:47 +0200 |
| Subject | Re: C |
| Message-ID | <l9mp3lFgddlU1@mid.individual.net> |
| In reply to | #44487 |
On 04.05.2024 13:17, Hermann Riemann wrote: > Am 04.05.24 um 11:23 schrieb Peter J. Holzer: > >>> Da wird man doch nicht wg strcpy() & Co herummeckern. >>> In diesem Zusammenhang ist übrigens sizeof() hilfreich. >> >> Aber nur, wenn die Variable als Array definiert ist. Wenn sie als >> Pointer definiert ist, hilft dir sizeof eher wenig. > > sizeof(*pointer) > ebend. Eins meiner Lieblingskonstrukte: pointer = calloc( nn+1, sizeof(*pointer) ); funzt unabhängig vom Datentyp und nullt auch gleich den Arbeitsbereich. Könnte man auch in ein macro packen.
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2024-05-05 16:43 +0200 |
| Subject | Re: C |
| Message-ID | <l9pk8iFsmkrU13@mid.individual.net> |
| In reply to | #44489 |
Michael Kraemer, 2024-05-04 14:47: > On 04.05.2024 13:17, Hermann Riemann wrote: >> Am 04.05.24 um 11:23 schrieb Peter J. Holzer: >> >>>> Da wird man doch nicht wg strcpy() & Co herummeckern. >>>> In diesem Zusammenhang ist übrigens sizeof() hilfreich. >>> >>> Aber nur, wenn die Variable als Array definiert ist. Wenn sie als >>> Pointer definiert ist, hilft dir sizeof eher wenig. >> >> sizeof(*pointer) >> > > ebend. Eins meiner Lieblingskonstrukte: > > pointer = calloc( nn+1, sizeof(*pointer) ); Und wozu soll das nun besonders hilfreich sein? sizeof(*pointer) wird halt je nach Architektur wahrhscheinlich 2, 4 oder 8 sein. > funzt unabhängig vom Datentyp und nullt auch gleich den Arbeitsbereich. > Könnte man auch in ein macro packen. Wie groß der Speicherbereich ist, auf den pointer zeigt, weiß man trotzdem nur durch nn. Der pointer selbst weiß das nicht und auch sizeof() nicht. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-05-06 09:41 +0200 |
| Subject | Re: C |
| Message-ID | <l9rftjF7fusU1@mid.individual.net> |
| In reply to | #44503 |
Am 05.05.24 um 16:43 schrieb Arno Welzel: > Michael Kraemer, 2024-05-04 14:47: > >> On 04.05.2024 13:17, Hermann Riemann wrote: >>> Am 04.05.24 um 11:23 schrieb Peter J. Holzer: >>> >>>>> Da wird man doch nicht wg strcpy() & Co herummeckern. >>>>> In diesem Zusammenhang ist übrigens sizeof() hilfreich. >>>> >>>> Aber nur, wenn die Variable als Array definiert ist. Wenn sie als >>>> Pointer definiert ist, hilft dir sizeof eher wenig. >>> >>> sizeof(*pointer) >>> >> >> ebend. Eins meiner Lieblingskonstrukte: >> >> pointer = calloc( nn+1, sizeof(*pointer) ); > > Und wozu soll das nun besonders hilfreich sein? sizeof(*pointer) wird > halt je nach Architektur wahrscheinlich 2, 4 oder 8 sein. Bei pointer auf Struktur hat es oft andere Werte. #define init_null(pointer) memset((void *)pointer,0,sizeof(*pointer))
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2024-05-05 02:08 +0200 |
| Subject | Re: C |
| Message-ID | <slrnv3djfa.14mcq.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #44487 |
On 2024-05-04 11:17, Hermann Riemann <nospam.ng@hermann-riemann.de> wrote:
> Am 04.05.24 um 11:23 schrieb Peter J. Holzer:
>>> Da wird man doch nicht wg strcpy() & Co herummeckern.
>>> In diesem Zusammenhang ist übrigens sizeof() hilfreich.
>>
>> Aber nur, wenn die Variable als Array definiert ist. Wenn sie als
>> Pointer definiert ist, hilft dir sizeof eher wenig.
>
> sizeof(*pointer)
>
Thema verfehlt. Fünf. Setzen.
hp
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2024-05-05 16:41 +0200 |
| Subject | Re: C |
| Message-ID | <l9pk4hFsmkrU12@mid.individual.net> |
| In reply to | #44487 |
Hermann Riemann, 2024-05-04 13:17: > Am 04.05.24 um 11:23 schrieb Peter J. Holzer: > >>> Da wird man doch nicht wg strcpy() & Co herummeckern. >>> In diesem Zusammenhang ist übrigens sizeof() hilfreich. >> >> Aber nur, wenn die Variable als Array definiert ist. Wenn sie als >> Pointer definiert ist, hilft dir sizeof eher wenig. > > sizeof(*pointer) Nein. Das liefert die Größe des Speichers ab, die nötig ist, um die Adresse des Pointers zu speichern - abhängig vom System, mit dem Du arbeitest, wird dann hier z.B. 4 oder 8 rauskommen. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Ralf Damaschke <rwspam@gmx.de> |
|---|---|
| Date | 2024-05-05 16:02 +0000 |
| Subject | Re: C |
| Message-ID | <pan$e1b80$c7bd7815$fb2b2ba3$cac4dcb@y2plugh.fqdn.th-h.de> |
| In reply to | #44502 |
Arno Welzel schrieb: > Hermann Riemann, 2024-05-04 13:17: >> >> sizeof(*pointer) > > Nein. > > Das liefert die Größe des Speichers ab, die nötig ist, um die Adresse > des Pointers zu speichern - abhängig vom System, mit dem Du arbeitest, > wird dann hier z.B. 4 oder 8 rauskommen. Für "char *pointer" ist das Ergebnis immer 1.
[toc] | [prev] | [next] | [standalone]
| From | Ralf Damaschke <rwspam@gmx.de> |
|---|---|
| Date | 2024-05-05 23:47 +0000 |
| Subject | Re: C |
| Message-ID | <pan$d4318$5b9f25e3$436cc8dd$e6f72b2d@y2plugh.fqdn.th-h.de> |
| In reply to | #44505 |
Stefan Ram schrieb:
> Ralf Damaschke <rwspam@gmx.de> schrieb oder zitierte:
>>Für "char *pointer" ist das Ergebnis immer 1.
>
> Ich kann auch schreiben:
>
[...]
> #define SZ 17
[...]
> int main( void )
> { char( *p )[ SZ ]= f();
> printf( "%lld\n", sizeof( *p )); }
[....]
> 17
Fein, dann ist der Typ aber "char (*)[17]" und eben nicht "char *".
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2024-05-05 19:55 +0200 |
| Subject | Re: C |
| Message-ID | <slrnv3fi0a.17hrh.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #44502 |
On 2024-05-05 14:41, Arno Welzel <usenet@arnowelzel.de> wrote:
> Hermann Riemann, 2024-05-04 13:17:
>> Am 04.05.24 um 11:23 schrieb Peter J. Holzer:
>>
>>>> Da wird man doch nicht wg strcpy() & Co herummeckern.
>>>> In diesem Zusammenhang ist übrigens sizeof() hilfreich.
>>>
>>> Aber nur, wenn die Variable als Array definiert ist. Wenn sie als
>>> Pointer definiert ist, hilft dir sizeof eher wenig.
>>
>> sizeof(*pointer)
>
> Nein.
>
> Das liefert die Größe des Speichers ab, die nötig ist, um die Adresse
> des Pointers zu speichern - abhängig vom System, mit dem Du arbeitest,
> wird dann hier z.B. 4 oder 8 rauskommen.
Nein, es liefert die Größe des Objekts, auf das der Pointer zeigt.
Bei
char *pointer
also 1,
Bei
struct foo *pointer
entspreched sizeof(struct foo).
Das nützt aber nichts, wenn pointer in ein Array zeigt (was im Kontext
"strcpy() & Co" der Fall war), Denn da will man nicht die Größe eines
Elements wissen, sondern die des gesamten Arrays.
hp
[toc] | [prev] | [next] | [standalone]
Page 2 of 14 — ← Prev page 1 [2] 3 4 … 14 Next page →
Back to top | Article view | de.alt.folklore.computer
csiph-web