Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.alt.folklore.computer > #55820 > unrolled thread
| Started by | R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) |
|---|---|
| First post | 2026-07-11 17:11 +0200 |
| Last post | 2026-07-27 06:57 +0200 |
| Articles | 20 on this page of 270 — 26 participants |
Back to article view | Back to de.alt.folklore.computer
[aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2026-07-11 17:11 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Marco Moock <mm@dorfdsl.de> - 2026-07-11 17:32 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Ralph Aichinger <ra@h5.or.at> - 2026-07-11 17:07 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-07-11 22:54 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-07-12 14:46 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Marco Moock <mm@dorfdsl.de> - 2026-07-14 06:17 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-07-14 10:14 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. michaelnoeusenet@mac.com (Michael Noe) - 2026-07-14 18:52 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Marco Moock <mm@dorfdsl.de> - 2026-07-14 20:48 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Christian Weisgerber <naddy@mips.inka.de> - 2026-07-14 19:51 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Arno Welzel <usenet@arnowelzel.de> - 2026-07-15 08:19 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Başar Alabay <alabay@gmx.net> - 2026-07-15 06:43 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Arno Welzel <usenet@arnowelzel.de> - 2026-07-15 12:08 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Başar Alabay <alabay@gmx.net> - 2026-07-15 13:42 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Kay Martinen <usenet@martinen.de> - 2026-07-15 22:05 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. michaelnoeusenet@mac.com (Michael Noe) - 2026-07-16 18:23 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Kay Martinen <usenet@martinen.de> - 2026-07-17 12:12 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. michaelnoeusenet@mac.com (Michael Noe) - 2026-07-17 17:00 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Başar Alabay <alabay@gmx.net> - 2026-07-17 15:43 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. michaelnoeusenet@mac.com (Michael Noe) - 2026-07-17 18:54 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Başar Alabay <alabay@gmx.net> - 2026-07-17 18:57 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. michaelnoeusenet@mac.com (Michael Noe) - 2026-07-18 08:43 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Başar Alabay <alabay@gmx.net> - 2026-07-18 11:02 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. michaelnoeusenet@mac.com (Michael Noe) - 2026-07-18 16:16 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Başar Alabay <alabay@gmx.net> - 2026-07-18 15:11 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. michaelnoeusenet@mac.com (Michael Noe) - 2026-07-19 14:29 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-07-19 16:56 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. michaelnoeusenet@mac.com (Michael Noe) - 2026-07-19 19:07 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Başar Alabay <alabay@gmx.net> - 2026-07-19 20:12 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Arno Welzel <usenet@arnowelzel.de> - 2026-07-21 16:41 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Arno Welzel <usenet@arnowelzel.de> - 2026-07-21 17:41 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Başar Alabay <alabay@gmx.net> - 2026-07-21 19:27 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Arno Welzel <usenet@arnowelzel.de> - 2026-07-21 16:39 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Sebastian Barthel <naitsabes@freenet.de> - 2026-07-21 20:39 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2026-07-21 21:20 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Arno Welzel <usenet@arnowelzel.de> - 2026-07-22 12:15 +0200
Feenstaub gegen echte Geldstücke auch für Minderjährige? (was: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä.) michaelnoeusenet@mac.com (Michael Noe) - 2026-07-22 19:06 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Kay Martinen <usenet@martinen.de> - 2026-07-25 19:15 +0200
Free-to-play (was: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä.) michaelnoeusenet@mac.com (Michael Noe) - 2026-07-26 08:16 +0200
Not free to spend (was: Free-to-play) Martin Gerdes <martin.gerdes@gmx.de> - 2026-07-26 12:01 +0200
Re: Not free to spend Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-07-26 10:18 +0000
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-07-26 22:05 +0200
Re: Not free to spend Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-07-27 07:37 +0200
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-07-27 09:27 +0200
Re: Not free to spend Sebastian Barthel <naitsabes@freenet.de> - 2026-07-27 14:21 +0000
Re: Not free to spend Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-07-27 06:21 +0000
Re: Not free to spend michaelnoeusenet@mac.com (Michael Noe) - 2026-07-26 17:42 +0200
Re: Not free to spend Martin Gerdes <martin.gerdes@gmx.de> - 2026-07-27 10:43 +0200
Re: Not free to spend michaelnoeusenet@mac.com (Michael Noe) - 2026-07-27 18:00 +0200
Re: Not free to spend Martin Gerdes <martin.gerdes@gmx.de> - 2026-07-27 18:54 +0200
BNPL (was: Not free to spend) michaelnoeusenet@mac.com (Michael Noe) - 2026-07-27 20:17 +0200
Re: BNPL Kay Martinen <usenet@martinen.de> - 2026-07-27 20:52 +0200
Re: BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-07-27 23:04 +0200
Re: BNPL (was: Not free to spend) Martin Gerdes <martin.gerdes@gmx.de> - 2026-07-27 22:42 +0200
Re: BNPL (was: Not free to spend) Thomas Koenig <tkoenig@netcologne.de> - 2026-07-28 05:12 +0000
Re: BNPL (was: Not free to spend) Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-07-28 08:55 +0200
Re: BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-07-28 17:38 +0200
Re: BNPL (was: Not free to spend) Michael Noe <michaelnoeusenet@mac.com> - 2026-07-28 07:07 +0000
Re: Not free to spend Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-07-27 21:35 +0200
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-07-28 23:35 +0200
Re: Not free to spend Martin Gerdes <martin.gerdes@gmx.de> - 2026-07-29 02:00 +0200
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-07-29 13:25 +0200
BNPL (was: Not free to spend) michaelnoeusenet@mac.com (Michael Noe) - 2026-07-30 16:29 +0200
Re: BNPL Kay Martinen <usenet@martinen.de> - 2026-07-30 21:59 +0200
Re: BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-07-31 09:23 +0200
Re: Not free to spend michaelnoeusenet@mac.com (Michael Noe) - 2026-07-29 18:21 +0200
Re: Not free to spend Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-07-30 13:27 +0200
Überschuldung von jungen Leute auch durch BNPL (was: Not free to spend) michaelnoeusenet@mac.com (Michael Noe) - 2026-07-30 14:57 +0200
Re: Überschuldung von jungen Leute auch durch BNPL Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 10:21 +0200
Re: Überschuldung von jungen Leute auch durch BNPL Kay Martinen <usenet@martinen.de> - 2026-07-31 12:32 +0200
Re: Überschuldung von jungen Leute auch durch BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-07-31 13:59 +0200
Re: Überschuldung von jungen Leute auch durch BNPL Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-07-31 12:10 +0000
Re: Überschuldung von jungen Leute auch durch BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-07-31 16:21 +0200
Re: Überschuldung von jungen Leute auch durch BNPL Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 15:35 +0200
Re: Überschuldung von jungen Leute auch durch BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-07-31 17:24 +0200
Re: Überschuldung von jungen Leute auch durch BNPL Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-07-31 15:33 +0000
Re: Überschuldung von jungen Leute auch durch BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-07-31 18:54 +0200
Re: Überschuldung von jungen Leute auch durch BNPL Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 15:26 +0200
Re: Überschuldung von jungen Leute auch durch BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-07-31 17:59 +0200
Re: Überschuldung von jungen Leute auch durch BNPL Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-07-31 16:06 +0000
Re: Überschuldung von jungen Leute auch durch BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-07-31 19:03 +0200
Re: Überschuldung von jungen Leute auch durch BNPL Arno Welzel <usenet@arnowelzel.de> - 2026-08-03 10:09 +0200
Re: Not free to spend Martin Gerdes <martin.gerdes@gmx.de> - 2026-07-30 17:13 +0200
BNPL (was: Not free to spend) michaelnoeusenet@mac.com (Michael Noe) - 2026-07-30 17:25 +0200
Re: BNPL Guido Grohmann <guido.grohmann@gmx.de> - 2026-07-30 22:51 +0200
Re: BNPL Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-01 07:00 +0200
Re: BNPL Thomas Koenig <tkoenig@netcologne.de> - 2026-08-04 16:48 +0000
Seltsame Namensableitungen (was: BNPL) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-04 20:33 +0200
Re: Seltsame Namensableitungen (was: BNPL) Thomas Koenig <tkoenig@netcologne.de> - 2026-08-04 19:21 +0000
Re: Seltsame Namensableitungen Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-08-04 21:39 +0200
Re: Seltsame Namensableitungen Kay Martinen <usenet@martinen.de> - 2026-08-05 11:08 +0200
Re: Seltsame Namensableitungen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-05 12:03 +0200
Re: Seltsame Namensableitungen Arno Welzel <usenet@arnowelzel.de> - 2026-08-05 20:25 +0200
Re: Seltsame Namensableitungen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-06 01:59 +0200
Re: Seltsame Namensableitungen Arno Welzel <usenet@arnowelzel.de> - 2026-08-07 16:18 +0200
Re: Seltsame Namensableitungen Arno Welzel <usenet@arnowelzel.de> - 2026-08-07 16:19 +0200
Re: Seltsame Namensableitungen Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-08-05 16:29 +0200
Re: Seltsame Namensableitungen Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-08-05 16:29 +0200
Re: Seltsame Namensableitungen Thomas Koenig <tkoenig@netcologne.de> - 2026-08-05 18:15 +0000
Re: Seltsame Namensableitungen Kay Martinen <usenet@martinen.de> - 2026-08-05 20:44 +0200
Re: Seltsame Namensableitungen Thomas Koenig <tkoenig@netcologne.de> - 2026-08-06 06:17 +0000
Re: Seltsame Namensableitungen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-06 12:23 +0200
Re: Seltsame Namensableitungen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-06 02:10 +0200
Re: Seltsame Namensableitungen Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-08-06 21:35 +0200
Re: Seltsame Namensableitungen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-08 09:04 +0200
Re: Seltsame Namensableitungen Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-08-08 12:55 +0200
Re: Seltsame Namensableitungen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-08 15:11 +0200
Re: Seltsame Namensableitungen Sebastian Barthel <naitsabes@freenet.de> - 2026-08-08 20:30 +0000
Zeichenkodierungen (was: Seltsame Namensableitungen) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-09 11:57 +0200
Re: Zeichenkodierungen (was: Seltsame Namensableitungen) Sebastian Barthel <naitsabes@freenet.de> - 2026-08-09 14:24 +0000
Re: Zeichenkodierungen (was: Seltsame Namensableitungen) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-09 18:09 +0200
Re: Zeichenkodierungen Kay Martinen <usenet@martinen.de> - 2026-08-09 22:27 +0200
Re: Zeichenkodierungen Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-08-10 18:50 +0200
Re: Zeichenkodierungen michaelnoeusenet@mac.com (Michael Noe) - 2026-08-10 19:36 +0200
Re: Zeichenkodierungen (was: Seltsame Namensableitungen) Sebastian Barthel <naitsabes@freenet.de> - 2026-08-09 23:46 +0000
Re: Zeichenkodierungen michaelnoeusenet@mac.com (Michael Noe) - 2026-08-10 08:01 +0200
Re: Zeichenkodierungen (was: Seltsame Namensableitungen) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-10 08:25 +0200
Apple ][ (was: Zeichenkodierungen) michaelnoeusenet@mac.com (Michael Noe) - 2026-08-10 09:36 +0200
Re: Apple ][ (was: Zeichenkodierungen) Sebastian Barthel <naitsabes@freenet.de> - 2026-08-10 12:19 +0000
Re: Apple ][ michaelnoeusenet@mac.com (Michael Noe) - 2026-08-10 15:11 +0200
Re: Apple ][ (was: Zeichenkodierungen) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-10 20:35 +0200
Re: Zeichenkodierungen (was: Seltsame Namensableitungen) Sebastian Barthel <naitsabes@freenet.de> - 2026-08-10 11:52 +0000
Re: Zeichenkodierungen Christian Corti <use@reply.to> - 2026-08-10 17:07 +0200
Re: Zeichenkodierungen Sebastian Barthel <naitsabes@freenet.de> - 2026-08-10 16:58 +0000
Wortgrößen (was: Zeichenkodierungen) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-10 20:15 +0200
Re: Zeichenkodierungen (was: Seltsame Namensableitungen) Thomas Koenig <tkoenig@netcologne.de> - 2026-08-09 17:22 +0000
36 Bit (was: Zeichenkodierungen) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-09 21:02 +0200
Re: 36 Bit (was: Zeichenkodierungen) Thomas Koenig <tkoenig@netcologne.de> - 2026-08-10 05:53 +0000
Re: 36 Bit (was: Zeichenkodierungen) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-10 19:15 +0200
Re: Seltsame Namensableitungen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-10 10:18 +0200
Re: Seltsame Namensableitungen Sebastian Barthel <naitsabes@freenet.de> - 2026-08-10 13:00 +0000
Re: Seltsame Namensableitungen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-10 18:03 +0200
Re: Seltsame Namensableitungen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-10 20:23 +0200
Re: Seltsame Namensableitungen Christian Corti <use@reply.to> - 2026-08-09 20:45 +0200
Re: Seltsame Namensableitungen Kay Martinen <usenet@martinen.de> - 2026-08-09 22:38 +0200
Re: Seltsame Namensableitungen Christian Corti <use@reply.to> - 2026-08-10 11:18 +0200
Re: Seltsame Namensableitungen Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-08-06 21:26 +0200
Re: Seltsame Namensableitungen Kay Martinen <usenet@martinen.de> - 2026-08-08 00:14 +0200
Re: Seltsame Namensableitungen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-08 09:05 +0200
Re: Seltsame Namensableitungen Kay Martinen <usenet@martinen.de> - 2026-08-08 15:23 +0200
Re: Seltsame Namensableitungen Sebastian Barthel <naitsabes@freenet.de> - 2026-08-08 20:34 +0000
Re: Seltsame Namensableitungen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-09 12:16 +0200
Re: Seltsame Namensableitungen Kay Martinen <usenet@martinen.de> - 2026-08-09 12:45 +0200
Re: Seltsame Namensableitungen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-09 13:51 +0200
Re: Seltsame Namensableitungen Kay Martinen <usenet@martinen.de> - 2026-08-09 17:34 +0200
Re: Seltsame Namensableitungen Kay Martinen <usenet@martinen.de> - 2026-08-09 12:31 +0200
Re: Seltsame Namensableitungen tom nossen <news@nossen.org> - 2026-08-09 16:07 +0200
Re: Seltsame Namensableitungen Kay Martinen <usenet@martinen.de> - 2026-08-09 17:43 +0200
Re: Seltsame Namensableitungen Sebastian Barthel <naitsabes@freenet.de> - 2026-08-09 17:15 +0000
Tastaturen (Re: Seltsame Namensableitungen) michaelnoeusenet@mac.com (Michael Noe) - 2026-08-09 20:43 +0200
Re: Tastaturen (Re: Seltsame Namensableitungen) Sebastian Barthel <naitsabes@freenet.de> - 2026-08-09 20:53 +0000
Re: Tastaturen (Re: Seltsame Namensableitungen) Kay Martinen <usenet@martinen.de> - 2026-08-10 00:51 +0200
Re: Tastaturen (Re: Seltsame Namensableitungen) Sebastian Barthel <naitsabes@freenet.de> - 2026-08-10 00:04 +0000
Re: Tastaturen michaelnoeusenet@mac.com (Michael Noe) - 2026-08-10 08:45 +0200
Re: Tastaturen michaelnoeusenet@mac.com (Michael Noe) - 2026-08-10 08:04 +0200
Re: Tastaturen michaelnoeusenet@mac.com (Michael Noe) - 2026-08-10 08:37 +0200
Tastaturen (was: Seltsame Namensableitungen) michaelnoeusenet@mac.com (Michael Noe) - 2026-08-09 09:37 +0200
Re: Tastaturen (was: Seltsame Namensableitungen) Thomas Koenig <tkoenig@netcologne.de> - 2026-08-09 08:45 +0000
Re: Tastaturen michaelnoeusenet@mac.com (Michael Noe) - 2026-08-09 12:12 +0200
Re: Tastaturen (was: Seltsame Namensableitungen) Christian Weisgerber <naddy@mips.inka.de> - 2026-08-09 10:40 +0000
Re: Tastaturen michaelnoeusenet@mac.com (Michael Noe) - 2026-08-09 19:43 +0200
Re: Seltsame Namensableitungen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-10 10:29 +0200
Re: Seltsame Namensableitungen Thomas Koenig <tkoenig@netcologne.de> - 2026-08-08 07:13 +0000
Re: Seltsame Namensableitungen Andreas Eder <a_eder_muc@web.de> - 2026-08-08 15:45 +0200
Re: Seltsame Namensableitungen (was: BNPL) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-04 21:45 +0200
Re: BNPL Arno Welzel <usenet@arnowelzel.de> - 2026-08-04 22:38 +0200
Re: BNPL Kay Martinen <usenet@martinen.de> - 2026-08-10 01:03 +0200
Re: BNPL Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-10 10:31 +0200
Re: Not free to spend Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-07-30 16:04 +0000
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-07-30 22:11 +0200
Re: Not free to spend Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-07-31 09:08 +0200
Re: Not free to spend Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-07-31 08:39 +0000
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-07-31 11:45 +0200
Re: Not free to spend Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-07-31 14:59 +0200
OS or !OS (was: Not free to spend) Kay Martinen <usenet@martinen.de> - 2026-08-01 14:17 +0200
Re: Not free to spend Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 10:14 +0200
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-07-31 11:48 +0200
Re: Not free to spend Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-07-31 10:21 +0000
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-08-01 14:30 +0200
BNPL (was: Not free to spend) michaelnoeusenet@mac.com (Michael Noe) - 2026-08-01 15:26 +0200
Re: BNPL Kay Martinen <usenet@martinen.de> - 2026-08-02 22:08 +0200
Re: BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-08-03 14:36 +0200
Re: BNPL Ralph Aichinger <ra@h5.or.at> - 2026-08-03 13:04 +0000
Re: BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-08-03 15:38 +0200
Re: BNPL Ralph Aichinger <ra@h5.or.at> - 2026-08-03 13:50 +0000
Re: BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-08-03 17:47 +0200
Re: BNPL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-03 17:58 +0200
Re: BNPL michaelnoeusenet@mac.com (Michael Noe) - 2026-08-04 14:14 +0200
Re: BNPL "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-04 19:07 +0200
Re: BNPL Ignatios Souvatzis <u502sou@bnhb484.de> - 2026-08-06 09:45 +0000
Re: BNPL Ignatios Souvatzis <u502sou@bnhb484.de> - 2026-08-07 09:38 +0000
Re: Not free to spend Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-07-31 15:12 +0200
Re: Not free to spend Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-07-31 13:24 +0000
Re: Not free to spend Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 15:38 +0200
Re: Not free to spend Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-07-31 16:26 +0200
BNPL (was: Not free to spend) michaelnoeusenet@mac.com (Michael Noe) - 2026-07-31 16:21 +0200
Re: Not free to spend Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-06 12:42 +0200
Re: Not free to spend Christian Corti <use@reply.to> - 2026-07-30 13:07 +0200
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-07-30 22:03 +0200
Re: Not free to spend Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 10:12 +0200
Re: Not free to spend Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-07-31 08:44 +0000
Re: Not free to spend Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 10:55 +0200
Re: Not free to spend Thomas Koenig <tkoenig@netcologne.de> - 2026-08-04 16:49 +0000
Re: Not free to spend Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-08-05 11:35 +0000
Re: Not free to spend Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-06 12:30 +0200
Re: Not free to spend Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-06 12:27 +0200
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-07-27 20:06 +0200
Re: Not free to spend michaelnoeusenet@mac.com (Michael Noe) - 2026-07-27 20:47 +0200
Re: Not free to spend "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2026-07-28 07:31 +0000
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-07-28 23:39 +0200
Re: Not free to spend Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-07-27 07:49 +0200
Re: Not free to spend Arno Welzel <usenet@arnowelzel.de> - 2026-07-27 11:57 +0200
Re: Not free to spend Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-07-27 14:54 +0200
Re: Not free to spend Sebastian Barthel <naitsabes@freenet.de> - 2026-07-27 14:26 +0000
Re: Not free to spend Sebastian Barthel <naitsabes@freenet.de> - 2026-07-27 14:38 +0000
Re: Not free to spend Kay Martinen <usenet@martinen.de> - 2026-07-27 20:53 +0200
Re: Not free to spend Thomas Koenig <tkoenig@netcologne.de> - 2026-07-28 05:11 +0000
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Frank Wißmann <frank_wissmann@web.de> - 2026-07-14 20:09 +0200
VzEkC (was: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä.) R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2026-07-26 23:17 +0200
Re: VzEkC (was: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä.) Sebastian Barthel <naitsabes@freenet.de> - 2026-07-27 14:18 +0000
Re: VzEkC (was: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä.) Martin Gerdes <martin.gerdes@gmx.de> - 2026-07-27 18:50 +0200
Znesur (was: Re: VzEkC) Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-07-27 21:42 +0200
Re: Zensur (was: Re: VzEkC) Martin Gerdes <martin.gerdes@gmx.de> - 2026-07-27 22:43 +0200
Re: Zensur Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-07-28 08:59 +0200
Re: Zensur Martin Gerdes <martin.gerdes@gmx.de> - 2026-07-28 15:54 +0200
Re: Zensur Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-07-28 16:34 +0200
Re: Zensur Martin Gerdes <martin.gerdes@gmx.de> - 2026-07-29 02:00 +0200
Re: Zensur Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-07-29 08:50 +0200
Re: Zensur Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2026-07-29 07:13 +0000
Re: Zensur Marco Moock <mm@dorfdsl.de> - 2026-07-29 12:41 +0200
Re: Zensur Martin Gerdes <martin.gerdes@gmx.de> - 2026-07-30 00:21 +0200
Re: Zensur R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2026-07-30 01:38 +0200
Re: Zensur Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 10:32 +0200
Re: Zensur Marco Moock <mm@dorfdsl.de> - 2026-07-31 15:09 +0200
Re: Zensur Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-07-31 15:37 +0200
Re: Zensur R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2026-08-02 19:33 +0200
Re: Zensur "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-08-02 20:11 +0200
Re: Zensur Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-08-03 08:35 +0000
Re: Zensur R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2026-08-04 00:45 +0200
Re: Zensur Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-06 12:49 +0200
Re: Zensur Marco Moock <mm@dorfdsl.de> - 2026-08-06 15:48 +0200
Re: Zensur Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-08-06 12:45 +0200
Re: Zensur R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2026-07-28 17:00 +0200
Re: Zensur Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-07-28 21:05 +0200
Re: Zensur Marco Moock <mm@dorfdsl.de> - 2026-07-28 21:26 +0200
Re: Zensur Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-07-29 08:50 +0200
Re: Zensur Marco Moock <mm@dorfdsl.de> - 2026-07-28 21:24 +0200
Re: Zensur Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-07-29 08:53 +0200
Re: Zensur Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 10:29 +0200
Re: Zensur Marco Moock <mm@dorfdsl.de> - 2026-07-31 14:58 +0200
Re: Zensur Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 15:18 +0200
Re: Zensur Marco Moock <mm@dorfdsl.de> - 2026-07-31 17:32 +0200
Re: Zensur Arno Welzel <usenet@arnowelzel.de> - 2026-08-03 10:17 +0200
Re: Zensur Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-08-03 12:53 +0200
Re: Zensur Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2026-08-03 16:24 +0200
Re: VzEkC Kay Martinen <usenet@martinen.de> - 2026-07-30 22:31 +0200
Re: VzEkC Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 10:24 +0200
Re: VzEkC Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2026-07-31 08:47 +0000
Re: VzEkC Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 10:56 +0200
Re: VzEkC Kay Martinen <usenet@martinen.de> - 2026-07-31 12:50 +0200
Re: VzEkC Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 14:05 +0200
Re: VzEkC R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2026-07-28 17:00 +0200
Re: VzEkC Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2026-07-30 23:21 +0000
Re: VzEkC Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 10:42 +0200
Re: VzEkC Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2026-07-31 11:46 +0000
Re: VzEkC Arno Welzel <usenet@arnowelzel.de> - 2026-07-31 15:23 +0200
Re: VzEkC Kay Martinen <usenet@martinen.de> - 2026-08-04 01:31 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Kay Martinen <usenet@martinen.de> - 2026-07-26 02:37 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2026-07-26 23:17 +0200
Re: [aus Pietätsgründen] Angebot von ISDN-Zeuch u.ä. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2026-07-27 06:57 +0200
Page 6 of 14 — ← Prev page 1 … 4 5 [6] 7 8 … 14 Next page →
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-08-06 06:17 +0000 |
| Subject | Re: Seltsame Namensableitungen |
| Message-ID | <11518t2$3j4nj$4@dont-email.me> |
| In reply to | #56062 |
Kay Martinen <usenet@martinen.de> schrieb: > Am 05.08.26 um 20:15 schrieb Thomas Koenig: >> Diedrich Ehlerding <diedrich.ehlerding@t-online.de> schrieb: >>> Thomas Koenig meinte: >>>> >>>> Aber Echte Programmierer arbeiten ja sowieso mit dem Untermenü 2 >>>> von ISPF :-) >>>> >>> Æchte Programmierer™ verwenden einen IBM 029 Kartenlocher! >> ^ >> >> HERESY DETECTED! > > Wie "exkommuniziert" man denn einen Æchten Programmierer? https://www.youtube.com/watch?v=lXhU9zacjzw > >> Das ist kein EBCDIC-Zeichen. > > Na und? Dann sind's auch keine Echten Programmierer (TM)! > > 1. Schreib doch ein Konvertierungs-tool. > 2. Ändere das System. > 3. "Umschreibe" es. > 4. Es gibt keine Æchten Programmierer mehr! Wegen dem Æ gab es die vermutlich sowieso nie :-) -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2026-08-06 12:23 +0200 |
| Subject | Re: Seltsame Namensableitungen |
| Message-ID | <ndj5loFb3tjU1@mid.individual.net> |
| In reply to | #56062 |
Am 05.08.26 um 20:44 schrieb Kay Martinen: > Wie "exkommuniziert" man denn einen Æchten Programmierer? Mit Pascal. ( Oder Ada oder COBOL .. ) -- <https://www.hermann-riemann.de> bzw.: <https://www.hermann-riemann.eu/de>
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2026-08-06 02:10 +0200 |
| Subject | Re: Seltsame Namensableitungen |
| Message-ID | <ndi1nmF5scnU1@mid.individual.net> |
| In reply to | #56059 |
Am 05.08.26 um 20:15 schrieb Thomas Koenig: > Diedrich Ehlerding <diedrich.ehlerding@t-online.de> schrieb: >> Thomas Koenig meinte: >>> >>> Aber Echte Programmierer arbeiten ja sowieso mit dem Untermenü 2 >>> von ISPF :-) >>> >> Æchte Programmierer™ verwenden einen IBM 029 Kartenlocher! > ^ > > HERESY DETECTED! Das ist kein EBCDIC-Zeichen. EBCDIC-UTF Bei Kartenlocher und Kartenleser gibt es Schwierigkeiten. Ich wollte Lochkarten besser ausnutzen und habe über Programme derartige Lochkarten stanzen lassen. Der Lochkartenleser hat diese allerdings nicht angenommen. -- <https://www.hermann-riemann.de> bzw.: <https://www.hermann-riemann.eu/de>
[toc] | [prev] | [next] | [standalone]
| From | Diedrich Ehlerding <diedrich.ehlerding@t-online.de> |
|---|---|
| Date | 2026-08-06 21:35 +0200 |
| Subject | Re: Seltsame Namensableitungen |
| Message-ID | <094fkmxibf.ln2@diedrich.ddnssec.de> |
| In reply to | #56064 |
Hermann Riemann meinte: >>>Æchte Programmierer™ verwenden einen IBM 029 Kartenlocher! >> ^ >> >> HERESY DETECTED! Das ist kein EBCDIC-Zeichen. > > EBCDIC-UTF > > Bei Kartenlocher und Kartenleser gibt es Schwierigkeiten. > Ich wollte Lochkarten besser ausnutzen und habe über Programme > derartige Lochkarten stanzen lassen. Wo hast du denn noch einen Lochkartenstanzer gefunden? Hast du Zugriff aufs Hein-Nixdorf-Museum oder so? > Der Lochkartenleser hat diese allerdings nicht angenommen. Komisch - im Prinzip konnte man doch die /360 und Verwandte von Lochkarte IPLen (als ich noch jung und schön war, habe ich das tatsächlich mal gesehen).. Also müssen die Kartenleser in dder Lage gewesen sein, beliebige Bytes einzulesen. Natürlich hätten Æ usw. dann 2- oder 3-Byte-Sequenzen werden müssen. -- gpg-Key (DSA 1024) D36AD663E6DB91A4 fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4 HTML-Mail wird ungeleſen entſorgt.
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2026-08-08 09:04 +0200 |
| Subject | Re: Seltsame Namensableitungen |
| Message-ID | <ndo2nnF47i0U1@mid.individual.net> |
| In reply to | #56075 |
Am 06.08.26 um 21:35 schrieb Diedrich Ehlerding: > Hermann Riemann meinte: >>>> Æchte Programmierer™ verwenden einen IBM 029 Kartenlocher! >>> ^ >>> >>> HERESY DETECTED! Das ist kein EBCDIC-Zeichen. >> >> EBCDIC-UTF >> >> Bei Kartenlocher und Kartenleser gibt es Schwierigkeiten. > >> Ich wollte Lochkarten besser ausnutzen und habe über Programme >> derartige Lochkarten stanzen lassen. > > Wo hast du denn noch einen Lochkartenstanzer gefunden? Hast du Zugriff aufs Hein-Nixdorf-Museum oder so? > >> Der Lochkartenleser hat diese allerdings nicht angenommen. > > Komisch - im Prinzip konnte man doch die /360 und Verwandte von Lochkarte > IPLen (als ich noch jung und schön war, habe ich das tatsächlich mal > gesehen).. Also müssen die Kartenleser in dder Lage gewesen sein, beliebige > Bytes einzulesen. Natürlich hätten Æ usw. dann 2- oder 3-Byte-Sequenzen werden > müssen. Passen in einer Lochkartenspalte mehr als 8 Bit ( als mehr Loch Zeilen?) Der Kartenleser beinhaltet nicht nur Photozellen, sonder auch etwas was Lochkombinationen weiterverarbeitete Ganz grob vergleichbar war meine Erfahrung mit dezimal. Dezimalbefehle ( von mainframes?) verarbeiten 4 BitWerte zwischen 0 und 9 und vielleicht noch Deziamlpunkt. In Assembler habe ich da irgendwie auch Werte zwischen A und F eingetragen. Das Assemblerlisting hat die Zeilen nicht wiedergegeben. Und die Testhilfe bei dump diese Zeilen nicht angezeigt. Ich wollte damals Fehlermeldungen schreiben mit * versumpft Befehle.. -- <https://www.hermann-riemann.de> bzw.: <https://www.hermann-riemann.eu/de>
[toc] | [prev] | [next] | [standalone]
| From | Diedrich Ehlerding <diedrich.ehlerding@t-online.de> |
|---|---|
| Date | 2026-08-08 12:55 +0200 |
| Subject | Re: Seltsame Namensableitungen |
| Message-ID | <1iejkmxhr4.ln2@diedrich.ddnssec.de> |
| In reply to | #56080 |
Hermann Riemann meinte: >> Bytes einzulesen. Natürlich hätten Æ usw. dann 2- oder 3-Byte-Sequenzen >> werden müssen. > > Passen in einer Lochkartenspalte mehr als 8 Bit ( als mehr Loch Zeilen?) Meiner Erinnerung sind das 12 Zeilen, also 12 bits. <nachgugel> Ja, meine Erinnerung ist korrekt, Wikipedia sagt :"In die Lochkarte können in 80 Spalten und in 12 Zeilen Löcher gestanzt werden". </> Für Unicode reicht das nicht, es müssten mehrere Spalten für solche Zeichen genutzt werden (wie ja auch in UTF-8 mehrere Bytes benutzt werden). Ob es tatsächlich Hardware gab, die tatsächlich 12 bits aus einer Lochkartenspalte auslesen konnte, weiß ich nicht; denkbar wäre das an Maschinen mit entsprechender Wortlänge gewesen; die Lochkartenleser,mit denen ich vor einem halben Jahrhundert zu tun hatte, haben Zeichen von 8 bit erzeugt. > Ganz grob vergleichbar war meine Erfahrung mit dezimal.Dezimalbefehle ( von > mainframes?) verarbeiten 4 BitWerte zwischen 0 und 9 und vielleicht noch > Deziamlpunkt. Ich kenne Dezimalbefehle von der /360 und Verwandten. Die verarbeiteten (bzw. ihre Nachfolger tun das bis heute) mit Dezimalbefehlen Zahlen von bis zu 15 Dezimalstellen, die je in 4 Bits, also Halbbytes, kodiert sind, wobei nur 0000 bis 1001 gültige Bitkombinationen sind; außerdem entweder ein Halbbyte pro Dezimalzahl für das Vorzeichen (1100 bzw 1101 für + und -); Dezimalzahlen können also 8 Bytes lang sein. Es gibt die 4 Grundrechenarten, außerdem eine Art Shift nach links (Multiplikation mit 10, das ist/war deutlich schneller als tatsächlich zu multiplizieren), und es gibt Befehle für die Konvertierung dezimal→dual und dual→dezimal. Es handelt sich um reine Festkommaarithmetik; wenn man mit Kommastellen rechnet, muss man im Resultat wissen, wo das Komma hingehört. Was es außerdem gibt, sind Hardwarebefehle, die so eine Festkommazahl druckaufbereiten, wobei die Hardware zB schon führende Nullen durch Leerzeichen ersetzt, Füllzeichen (etwa Leerzeichen als Tausender-Trennzeichen oder eben Dezimalkommas) einfügt und druckbare Vorzeichen erzeugt. (Das sind halt wirklich CISC-Maschinen). -- gpg-Key (DSA 1024) D36AD663E6DB91A4 fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4 HTML-Mail wird ungeleſen entſorgt.
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2026-08-08 15:11 +0200 |
| Subject | Re: Seltsame Namensableitungen |
| Message-ID | <slrn117eaok.30itl.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #56083 |
On 2026-08-08 12:55, Diedrich Ehlerding <diedrich.ehlerding@t-online.de> wrote:
> Hermann Riemann meinte:
>> Passen in einer Lochkartenspalte mehr als 8 Bit ( als mehr Loch Zeilen?)
>
> Meiner Erinnerung sind das 12 Zeilen, also 12 bits. <nachgugel> Ja,
> meine Erinnerung ist korrekt, Wikipedia sagt :"In die Lochkarte können
> in 80 Spalten und in 12 Zeilen Löcher gestanzt werden". </>
Yup. Ich habe noch ein paar (ungestanzte) auf meinem Schreibtisch
liegen.
> Für Unicode reicht das nicht, es müssten mehrere Spalten für solche
> Zeichen genutzt werden (wie ja auch in UTF-8 mehrere Bytes benutzt
> werden).
Vor ein paar Jahren ist in der Python-Newsgroup ein Kook aufgeschlagen,
der eine 12-Bit-Kodierung von Zeichen einführen wollte. Wozu das gut
sein sollte, konnte er nicht erklären. Vielleicht hatte er ja Lochkarten
im Sinn?
hjp
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Barthel <naitsabes@freenet.de> |
|---|---|
| Date | 2026-08-08 20:30 +0000 |
| Subject | Re: Seltsame Namensableitungen |
| Message-ID | <11583lo$4qdt$1@solani.org> |
| In reply to | #56084 |
Am Sat, 08 Aug 2026 15:11:48 +0200 schrieb der Meister Peter J. Holzer folgendes: > On 2026-08-08 12:55, Diedrich Ehlerding <diedrich.ehlerding@t-online.de> > wrote: >> Hermann Riemann meinte: >>> Passen in einer Lochkartenspalte mehr als 8 Bit ( als mehr Loch >>> Zeilen?) >> >> Meiner Erinnerung sind das 12 Zeilen, also 12 bits. <nachgugel> Ja, >> meine Erinnerung ist korrekt, Wikipedia sagt :"In die Lochkarte können >> in 80 Spalten und in 12 Zeilen Löcher gestanzt werden". </> > > Yup. Ich habe noch ein paar (ungestanzte) auf meinem Schreibtisch > liegen. > >> Für Unicode reicht das nicht, es müssten mehrere Spalten für solche >> Zeichen genutzt werden (wie ja auch in UTF-8 mehrere Bytes benutzt >> werden). > > Vor ein paar Jahren ist in der Python-Newsgroup ein Kook aufgeschlagen, > der eine 12-Bit-Kodierung von Zeichen einführen wollte. Wozu das gut > sein sollte, konnte er nicht erklären. Vielleicht hatte er ja Lochkarten > im Sinn? Macht auf einer PDP zum Beispiel Sinn - das sind dann dort 3 Zeichen pro Wort. Und 2^12 ist auch eine schöne Zahl ... vielleicht reicht das ja um alle japanischen Schriftzeichen zu codieren. 6 Bit war ja wohl ein bißchen wenig. Dann hat man 7 Bit probiert. Das ging eine Weile gut, aber ist auch nicht das Wahre gewesen. Mit 8 Bit konnte man zwar ein Sprache mit Sonderzeichen und ein paar Grafiksymbolen schön codieren, aber letztlich ist auch zuwenig, sonst bräuchte es keine Codepages und solche "Tricks". UTF ist durch diese seltsame Erweiterung nach hinten (mehr Bytes, wenn nötig) auch auf eine Art unschön. Bleibt also immer noch die Frage, wieviel Bits denn geeignet wären zur generellen Zeichencodierung. Evtl sogar mit bißchen Puffer - also etwa als 10Bit + 2Bit zum Umschalten (auf Grafiksymbole, Smileys ...). Was auch ein interessantes Ding sein könnte, wenn man alle möglichen Bitkombinationen in einem Grafikzeichensatz ablegen will. Normal sind das für 8 x 8 Pixel dann ja auch 8 x 8 Bit - vielleicht kommt man mit Redundanzen und gespiegelten Zeichen und evtl freiem Rand irgendwie in die Nähe von 12Bit. Vielleicht war es auch überhaupt gar nicht für Textzeichen gedacht, sondern rein für Grafik, um damit Animationen zu machen - gibt da so ein paar nette C64 Demos, die das benutzen. Wird dann sehr schön schnell, weil es der Videocontroller direkt als "Text" schreiben kann.
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2026-08-09 11:57 +0200 |
| Subject | Zeichenkodierungen (was: Seltsame Namensableitungen) |
| Message-ID | <slrn117gjo6.3tv63.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #56087 |
On 2026-08-08 22:30, Sebastian Barthel <naitsabes@freenet.de> wrote:
> Am Sat, 08 Aug 2026 15:11:48 +0200 schrieb der Meister Peter J. Holzer
> folgendes:
>> On 2026-08-08 12:55, Diedrich Ehlerding <diedrich.ehlerding@t-online.de>
>> wrote:
>>> Für Unicode reicht das nicht, es müssten mehrere Spalten für solche
>>> Zeichen genutzt werden (wie ja auch in UTF-8 mehrere Bytes benutzt
>>> werden).
>>
>> Vor ein paar Jahren ist in der Python-Newsgroup ein Kook aufgeschlagen,
>> der eine 12-Bit-Kodierung von Zeichen einführen wollte. Wozu das gut
>> sein sollte, konnte er nicht erklären. Vielleicht hatte er ja Lochkarten
>> im Sinn?
>
> Macht auf einer PDP zum Beispiel Sinn - das sind dann dort 3 Zeichen pro
> Wort.
Auf einer PDP-11 nicht ;-).
Ernsthaft: Ich hatte damals an die PDP-8 gedacht. Die hatte
12-Bit-Worte.
PDP-6 und PDP-10 hatten 36 Bit-Worte, vermutlich meinst Du eine von den
beiden.
Aber anyway: Computer mit einer Wortlänge, die ein Vielfaches von 12
beträgt, sind ähnlich veraltet wie Lochkarten (aber hier natürlich
on-topic, aber in der Python-Gruppe nicht).
Und anyway: Soweit ich mich erinnere, wollte er den ganzen Unicode-
Zeichensatz kodieren, das wäre also eine variable-length-Kodierung wie
UTF-8 oder UTF-16 geworden (UTF-12?). Aber die Erklärungen waren sehr
wirr und es ist 2 Jahre her, also kann ich mich täuschen.
> Und 2^12 ist auch eine schöne Zahl ... vielleicht reicht das ja um alle
> japanischen Schriftzeichen zu codieren.
Es reicht für das, was man in der Schule lernt (Hiragana, Katakana,
Romanji plus ca. 2000 Kanji), aber möglicherweise nicht für den Alltag:
Namen werden mit Kanji geschrieben, und da können natürlich auch seltene
Zeichen vorkommen. Und da ist es dann halt blöd, wenn man seinen Namen
nicht schreiben kann, weil man dafür ein Zeichen bräuchte, das nicht zu
den 3000 häufigsten Kanji gehört.
> 6 Bit war ja wohl ein bißchen wenig. Dann hat man 7 Bit probiert. Das
> ging eine Weile gut, aber ist auch nicht das Wahre gewesen. Mit 8 Bit
> konnte man zwar ein Sprache mit Sonderzeichen und ein paar Grafiksymbolen
> schön codieren, aber letztlich ist auch zuwenig, sonst bräuchte es keine
> Codepages und solche "Tricks".
"Codepages" hatte man auch bei 7 Bit schon. ISO-646 hatte nationale
Varianten: ISO-646-US kennt man unter dem Namen ASCII immer noch, aber
es gab auch eine deutsche (ISO-646-DE bzw. DIN 66003 mit §ÄÖÜäöüß statt
@[\]{|}~). Wir hatten in der Schule Apple ][, bei denen man den
Zeichensatz und die Tastatur mit einem Kippschalter auf der Unterseite
umschalten konnte. Wenn man die auf deutsch umschaltete, meldeten sie
sich als "Apple ÜÄ".
> UTF ist durch diese seltsame Erweiterung nach hinten (mehr Bytes, wenn
> nötig) auch auf eine Art unschön.
32 Bit pro Zeichen (oder auch nur 16) wären Anfang der 90er-Jahre wohl
etwas zu viel Platzverschwendung gewesen. Außerdem hat UTF-8 die
angenehme Eigenschaft, dass alle ASCII-Zeichen (und damit alle für
Filesysteme wichtigen Zeichen wie '.', '/', '\0' unverändert blieben -
der Arbeitstitel von UTF-8 war UTF-FSS (file system safe), es gab damals
schon einen anderen Entwurf für UTF-8, bei dem das nicht der Fall war).
> Bleibt also immer noch die Frage, wieviel Bits denn geeignet wären zur
> generellen Zeichencodierung.
Unicode ist derzeit defacto technisch auf etwas über 20 Bit beschränkt.
Tatsächlich definiert sind in Unicode Version 17 159'801 Codepoints,
dafür würden 18 Bit reichen.
> Evtl sogar mit bißchen Puffer - also etwa als 10Bit + 2Bit zum
> Umschalten (auf Grafiksymbole, Smileys ...).
Kodierungen mit Umschalten gab es auch schon, z.B. Shift-JIS für
Japanisch (das ist leicht zu merken, weil da das "Umschalten" schon im
Namen vorkommt). Aber das hat den großen Nachteil, dass man sich merken
muss, in welchem Zustand man gerade ist. Wenn man z.B. einen Teil eines
Texts kopiert, muss man beim Einfügen die entsprechenden Steuercodes
einfügen, um diesen Zustand wiederherzustellen. UTF-8 und UTF-16 haben
den großen Vorteil, selbstsynchronisierend zu sein. Schlimmstenfalls ist
ein Glyph kaputt, wenn man ohe Rücksicht auf Codepoint- oder
Glyphgrenzen schneidet.
> Was auch ein interessantes Ding sein könnte, wenn man alle möglichen
> Bitkombinationen in einem Grafikzeichensatz ablegen will. Normal sind das
> für 8 x 8 Pixel dann ja auch 8 x 8 Bit
Die Idee hatte ich mit 16 auch schon ;-).
Und als dann Computer endlich genug Speicher hatten, dass 64 Bit pro
Zeichen nicht mehr der totale Wahnsinn wären, hatte ich gelernt, dass es
Sprachen gibt, deren Zeichen sich in 8x8 Pixel absolut nicht darstellen
lassen. Probier mal Biangbiang (𰻝𰻝) in 8x8 Pixeln abzubilden. Selbst
16x16 reicht nicht, nach meiner oberflächlichen Zählung braucht man
23x21 Pixel - runden wir der Einfachheit halber auf 24x24 auf. Dann
braucht man aber 576 Bit (72 Byte) pro Zeichen.
Und umgekehrt hätte das gleiche Zeichen in verschiedenen Fonts (z.B.
Times Roman vs. Arial) eine komplett andere Kodierung.
Nope. Keine gute Idee.
Unicode hat viele Schwächen (wenn man das heute mit 30 Jahren Erfahrung
noch mal designen würde, würde man sicher einige Sachen anders machen),
aber ich halte das schon für einen recht guten Kompromiss.
> - vielleicht kommt man mit Redundanzen und gespiegelten Zeichen und
> evtl freiem Rand irgendwie in die Nähe von 12Bit.
Sicher nicht mit einer Kodierung fixer Länge. Vielleicht als
Durchschnitt bei einer Huffman-Kodierung oder ähnlichem. Aber dann sind
wir wieder bei Kodierungen mit variabler Länge, und das gefällt Dir ja
an UTF-8 nicht.
hjp
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Barthel <naitsabes@freenet.de> |
|---|---|
| Date | 2026-08-09 14:24 +0000 |
| Subject | Re: Zeichenkodierungen (was: Seltsame Namensableitungen) |
| Message-ID | <115a2ic$6064$1@solani.org> |
| In reply to | #56092 |
Am Sun, 09 Aug 2026 11:57:24 +0200 schrieb der Meister Peter J. Holzer
folgendes:
> On 2026-08-08 22:30, Sebastian Barthel <naitsabes@freenet.de> wrote:
>> Am Sat, 08 Aug 2026 15:11:48 +0200 schrieb der Meister Peter J. Holzer
>> folgendes:
>>> On 2026-08-08 12:55, Diedrich Ehlerding
>>> <diedrich.ehlerding@t-online.de> wrote:
>>>> Für Unicode reicht das nicht, es müssten mehrere Spalten für solche
>>>> Zeichen genutzt werden (wie ja auch in UTF-8 mehrere Bytes benutzt
>>>> werden).
>>>
>>> Vor ein paar Jahren ist in der Python-Newsgroup ein Kook
>>> aufgeschlagen, der eine 12-Bit-Kodierung von Zeichen einführen wollte.
>>> Wozu das gut sein sollte, konnte er nicht erklären. Vielleicht hatte
>>> er ja Lochkarten im Sinn?
>>
>> Macht auf einer PDP zum Beispiel Sinn - das sind dann dort 3 Zeichen
>> pro Wort.
>
> Auf einer PDP-11 nicht ;-).
>
> Ernsthaft: Ich hatte damals an die PDP-8 gedacht. Die hatte
> 12-Bit-Worte.
>
> PDP-6 und PDP-10 hatten 36 Bit-Worte, vermutlich meinst Du eine von den
> beiden.
Genau sowas. Wegen 12 x 3 = 36.
Macht in dem eigentlichen Kontext evtl dann wieder keinen Sinn, wenn es
auf einem "normalen" System mit Basis 8Bit=1Byte benutzt werden soll(te).
Da geht es dann nicht mehr gut auf.
> Aber anyway: Computer mit einer Wortlänge, die ein Vielfaches von 12
> beträgt, sind ähnlich veraltet wie Lochkarten (aber hier natürlich
> on-topic, aber in der Python-Gruppe nicht).
Och - da wäre ich vorsichtig. Evtl wird das je demnächst mal
wiederentdeckt. 12 Bit hat auch als "Byte" so seine Vorteile - auch
abseits der Textcodierung.
> Und anyway: Soweit ich mich erinnere, wollte er den ganzen Unicode-
> Zeichensatz kodieren, das wäre also eine variable-length-Kodierung wie
> UTF-8 oder UTF-16 geworden (UTF-12?). Aber die Erklärungen waren sehr
> wirr und es ist 2 Jahre her, also kann ich mich täuschen.
Na ja, wird wohl auch nicht so wichtig gewesen sein, wenn es dann nicht
weiterverfolgt worden ist oder niemals was davon zu hören war.
>> Und 2^12 ist auch eine schöne Zahl ... vielleicht reicht das ja um alle
>> japanischen Schriftzeichen zu codieren.
>
> Es reicht für das, was man in der Schule lernt (Hiragana, Katakana,
> Romanji plus ca. 2000 Kanji), aber möglicherweise nicht für den Alltag:
> Namen werden mit Kanji geschrieben, und da können natürlich auch seltene
> Zeichen vorkommen. Und da ist es dann halt blöd, wenn man seinen Namen
> nicht schreiben kann, weil man dafür ein Zeichen bräuchte, das nicht zu
> den 3000 häufigsten Kanji gehört.
Im Deutschen könnte man etwa den gesamten Wortschatz einen
"Normalbürgers" darin codieren. Dann kann man sich das mit den Buchstaben
gleich ganz schenken. :)
In Japan könnte man dann ja die generische Bürger-ID an der Stelle
einsetzen, wo der Namen auftaucht. Dann ist auch klar, wer das sein soll.
Und irgendwo hinterlegt man den Schriftzug als Grafik, dann braucht man
den nicht da mit reincodieren (in den anderen Text) = Problem gelöst. :)
>> 6 Bit war ja wohl ein bißchen wenig. Dann hat man 7 Bit probiert. Das
>> ging eine Weile gut, aber ist auch nicht das Wahre gewesen. Mit 8 Bit
>> ... mit Sonderzeichen und ... Grafiksymbolen schön codieren, aber
>> ..., sonst bräuchte es keine Codepages und solche "Tricks".
>
> "Codepages" hatte man auch bei 7 Bit schon. ISO-646 hatte nationale
> Varianten: ISO-646-US kennt man unter dem Namen ASCII immer noch, aber
> es gab auch eine deutsche (ISO-646-DE bzw. DIN 66003 mit §ÄÖÜäöüß statt
> @[\]{|}~).
Interessant. Ich habe das erst bei den DOS PCs kennengelernt. Woanders
gab es sowas entweder gar nicht oder es wurde anders gelöst. Teilweise
rein auf Programmebene.
> Wir hatten in der Schule Apple ][, bei denen man den
> Zeichensatz und die Tastatur mit einem Kippschalter auf der Unterseite
> umschalten konnte. Wenn man die auf deutsch umschaltete, meldeten sie
> sich als "Apple ÜÄ".
Und das bei einer Firma, die immer soviel Wert auf das äußere
Erscheinungsbild legt.
>> UTF ist durch diese seltsame Erweiterung nach hinten (mehr Bytes, wenn
>> nötig) auch auf eine Art unschön.
>
> 32 Bit pro Zeichen (oder auch nur 16) wären Anfang der 90er-Jahre wohl
> etwas zu viel Platzverschwendung gewesen. Außerdem hat UTF-8 die
> angenehme Eigenschaft, dass alle ASCII-Zeichen (und damit alle für
> Filesysteme wichtigen Zeichen wie '.', '/', '\0' unverändert blieben -
> der Arbeitstitel von UTF-8 war UTF-FSS (file system safe), es gab damals
> schon einen anderen Entwurf für UTF-8, bei dem das nicht der Fall war).
Ohne diese Eigenschaft hätte es sich vmtl auch gar nicht durchgesetzt.
Dann hätte evtl jedes Land / Sprachraum was Eigenes gebaut.
>> Bleibt also immer noch die Frage, wieviel Bits denn geeignet wären zur
>> generellen Zeichencodierung.
>
> Unicode ist derzeit defacto technisch auf etwas über 20 Bit beschränkt.
> Tatsächlich definiert sind in Unicode Version 17 159'801 Codepoints,
> dafür würden 18 Bit reichen.
>
>> Evtl sogar mit bißchen Puffer - also etwa als 10Bit + 2Bit zum
>> Umschalten (auf Grafiksymbole, Smileys ...).
>
> Kodierungen mit Umschalten gab es auch schon, z.B. Shift-JIS für
> Japanisch (das ist leicht zu merken, weil da das "Umschalten" schon im
> Namen vorkommt). Aber das hat den großen Nachteil, dass man sich merken
> muss, in welchem Zustand man gerade ist. Wenn man z.B. einen Teil eines
> Texts kopiert, muss man beim Einfügen die entsprechenden Steuercodes
> einfügen, um diesen Zustand wiederherzustellen.
Am Ende ist es wie bei Grafik, wo man den Farbwert fix setzt und dann das
Zeichenkommando schickt vs. Zeichenbefehl mit Farbwertangabe.
Letztlich funktioniert beides gut.
Bei den Texten ist es vmtl eher der Entwicklungsgeschichte zu verdanken,
daß es so ist, wie es ist. Hätte es gleich zu Beginn sehr viel mehr RAM
gegeben, würde manches heute evtl anders funktionieren. Für Text könnte
es z.B. Attribute-Bitplanes geben - sähnlich wie bei Pixelgrafik oder wie
es bei den Textcolors oft gemacht worden ist, daß man parallel einen
kompletten zweiten Speicher mitlaufen läßt, worin diese Werte (fett,
kursiv, sub, underlined) notiert sind. Je nach Menge der Attribute
verdoppelt sowas den Text dann aber gleich mal (mindestens).
> einfügen, um diesen Zustand wiederherzustellen. UTF-8 und UTF-16 haben
> den großen Vorteil, selbstsynchronisierend zu sein. Schlimmstenfalls ist
> ein Glyph kaputt, wenn man ohe Rücksicht auf Codepoint- oder
> Glyphgrenzen schneidet.
Stimmt - ein Punkt für UTF .
>> Was auch ein interessantes Ding sein könnte, wenn man alle möglichen
>> Bitkombinationen in einem Grafikzeichensatz ablegen will. Normal sind
>> das für 8 x 8 Pixel dann ja auch 8 x 8 Bit
>
> Die Idee hatte ich mit 16 auch schon ;-).
>
> Und als dann Computer endlich genug Speicher hatten, dass 64 Bit pro
> Zeichen nicht mehr der totale Wahnsinn wären, hatte ich gelernt, dass es
> Sprachen gibt, deren Zeichen sich in 8x8 Pixel absolut nicht darstellen
> lassen. Probier mal Biangbiang (𰻝𰻝) in 8x8 Pixeln abzubilden. Selbst
> 16x16 reicht nicht, nach meiner oberflächlichen Zählung braucht man
> 23x21 Pixel - runden wir der Einfachheit halber auf 24x24 auf. Dann
> braucht man aber 576 Bit (72 Byte) pro Zeichen.
>
> Und umgekehrt hätte das gleiche Zeichen in verschiedenen Fonts (z.B.
> Times Roman vs. Arial) eine komplett andere Kodierung.
>
> Nope. Keine gute Idee.
Ich find das immer noch charmant. Würde aber natürlich dann Zeichen auf
eine fixe Größe (8x8 o.ä.) beschränken.
Es ging dabei auch nicht so sehr um "Textsymbole", eher um Wellen und evtl
Winkel etc.
Evtl ist es aber sogar mal eine interessante Sache drüber nachzudenken,
was passiert, wenn man die 576 Bit als Standard nimmt - also das größte
sinnvoll denkbare Zeichen zum Standard erklärt. Die Auflösung der anderen
Symbole gewinnt dadurch und mit einem Hardware-Blitter, der auch
skaliert, ist das allemal schnell genug.
> Unicode hat viele Schwächen (wenn man das heute mit 30 Jahren Erfahrung
> noch mal designen würde, würde man sicher einige Sachen anders machen),
> aber ich halte das schon für einen recht guten Kompromiss.
Muß es wohl sein, sonst wäre es nicht überall in Benutzung. Aber es hat
eben auch so seine Eigenheiten. Und es erfordert deutlichen Aufwand im
Vergleich zu einem definierten ASCII Zeichensatz.
>> - vielleicht kommt man mit Redundanzen und gespiegelten Zeichen und
>> evtl freiem Rand irgendwie in die Nähe von 12Bit.
>
> Sicher nicht mit einer Kodierung fixer Länge. Vielleicht als
> Durchschnitt bei einer Huffman-Kodierung oder ähnlichem. Aber dann sind
> wir wieder bei Kodierungen mit variabler Länge, und das gefällt Dir ja
> an UTF-8 nicht.
Ich habe ja nicht gemeint, daß mir das UTF gar nicht gefällt. Es hat ja
anscheinend durchaus Vorteile, gerade was Internationalisierung angeht.
Bin mit dieser Bit-Verteilungs-Überlegung bei 8x8 aber wohl noch nicht
ganz durch ... auch wenns momentan eher nicht nach einem Geistesblitz
aussieht, wie man das kleiner bekommt. Letztlich ist der Fehler einfach
der, daß man versucht eigentlich nötige Information "wegzureduzieren",
was einem dann immer nur mit irgendwelchen seltsamen Konstrukten gelingt,
aber in den seltensten Fällen die (notwenige) Information reduziert. 1
Bit bleibt eben dann oft doch 1 Bit.
VG,
SBn
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2026-08-09 18:09 +0200 |
| Subject | Re: Zeichenkodierungen (was: Seltsame Namensableitungen) |
| Message-ID | <slrn117h9i0.7nnt.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #56101 |
On 2026-08-09 16:24, Sebastian Barthel <naitsabes@freenet.de> wrote:
> Am Sun, 09 Aug 2026 11:57:24 +0200 schrieb der Meister Peter J. Holzer
> folgendes:
>
>> On 2026-08-08 22:30, Sebastian Barthel <naitsabes@freenet.de> wrote:
>>> Am Sat, 08 Aug 2026 15:11:48 +0200 schrieb der Meister Peter J. Holzer
>>> folgendes:
>>>> Vor ein paar Jahren ist in der Python-Newsgroup ein Kook
>>>> aufgeschlagen, der eine 12-Bit-Kodierung von Zeichen einführen wollte.
[...]
>> Aber anyway: Computer mit einer Wortlänge, die ein Vielfaches von 12
>> beträgt, sind ähnlich veraltet wie Lochkarten (aber hier natürlich
>> on-topic, aber in der Python-Gruppe nicht).
>
> Och - da wäre ich vorsichtig. Evtl wird das je demnächst mal
> wiederentdeckt.
Unwahrscheinlich.
> 12 Bit hat auch als "Byte" so seine Vorteile - auch abseits der
> Textcodierung.
Welche denn?
Für eine einzelne Anwendung mögen 12 Bit ideal sein. Aber dafür gibt es
dann sicher eine andere Anwendung, für die 13 Bit besser wären.
Zweier-Potenzen haben den Vorteil, dass sie sich binär effizient
darstellen lassen. Ich denke, es hat schon seinen Grund, warum ab den
70er-Jahren alle auf 8/16/32/64-Bit konvergiert sind.
>> Und anyway: Soweit ich mich erinnere, wollte er den ganzen Unicode-
>> Zeichensatz kodieren, das wäre also eine variable-length-Kodierung wie
>> UTF-8 oder UTF-16 geworden (UTF-12?). Aber die Erklärungen waren sehr
>> wirr und es ist 2 Jahre her, also kann ich mich täuschen.
>
> Na ja, wird wohl auch nicht so wichtig gewesen sein, wenn es dann nicht
> weiterverfolgt worden ist oder niemals was davon zu hören war.
Typischer Kook halt. Wobei zum typischen Kook-Verhalten auch ein
gewisses Durchhaltevermögen gehört. Wahrscheinlich taucht er in zwei
Jahren mit derselben Idee wieder auf.
>>> Und 2^12 ist auch eine schöne Zahl ... vielleicht reicht das ja um alle
>>> japanischen Schriftzeichen zu codieren.
>>
>> Es reicht für das, was man in der Schule lernt (Hiragana, Katakana,
>> Romanji plus ca. 2000 Kanji), aber möglicherweise nicht für den Alltag:
>> Namen werden mit Kanji geschrieben, und da können natürlich auch seltene
>> Zeichen vorkommen. Und da ist es dann halt blöd, wenn man seinen Namen
>> nicht schreiben kann, weil man dafür ein Zeichen bräuchte, das nicht zu
>> den 3000 häufigsten Kanji gehört.
>
> Im Deutschen könnte man etwa den gesamten Wortschatz einen
> "Normalbürgers" darin codieren. Dann kann man sich das mit den Buchstaben
> gleich ganz schenken. :)
Der (aktive) Wortschatz des Normalbürgers reicht halt nicht. Es hat
schon seinen Grund, dass Unicode über 100'000 chinesische Zeichen
enthält. Es gibt sicher niemanden, der die alle lesen kann, aber es gibt
ebenso sicher für jedes dieser Zeichen ein paar Leute, die genau dieses
Zeichen unbedingt brauchen.
> In Japan könnte man dann ja die generische Bürger-ID an der Stelle
> einsetzen, wo der Namen auftaucht.
| A Mensch mecht i bleibm
| und ned zur Nummer mecht i wern
hat Wolfgang Ambros vor etwas über 50 Jahren gesungen.
Möchtest Du, dass wir Dich hier mit Deiner Sozialversicherungsnummer
ansprechen?
>>> 6 Bit war ja wohl ein bißchen wenig. Dann hat man 7 Bit probiert. Das
>>> ging eine Weile gut, aber ist auch nicht das Wahre gewesen. Mit 8 Bit
>>> ... mit Sonderzeichen und ... Grafiksymbolen schön codieren, aber
>>> ..., sonst bräuchte es keine Codepages und solche "Tricks".
>>
>> "Codepages" hatte man auch bei 7 Bit schon. ISO-646 hatte nationale
>> Varianten: ISO-646-US kennt man unter dem Namen ASCII immer noch, aber
>> es gab auch eine deutsche (ISO-646-DE bzw. DIN 66003 mit §ÄÖÜäöüß statt
>> @[\]{|}~).
>
> Interessant. Ich habe das erst bei den DOS PCs kennengelernt.
Den Ausdruck "Codepage" hat vermutlich IBM geprägt. Die hatten das nicht
nur bei PCs, sondern auch bei den Mainframes (dort natürlich EBCDIC).
Aber verschiedene Zeichensätze gab es natürlich auch vorher, bzw. noch
schlimmer, weil jeder Hersteller sein eigenes Süppchen gekocht hat.
Die ISO-646-Familie ab 1968 war da schon mal ein Fortschritt, auch wenn
sich nicht immer alle einig waren, welche Variante sie verwenden wollen.
Ich erinnere mich da an die Rechnungen von Ikea, auf denen die Umlaute
nie gestimmt haben (und glaube ich nicht mal konsistent gleich falsch
waren - vermutlich war ein Drucker auf amerikanisch eingestellt, der
andere auf schwedisch, und die Software hat versucht, deutsch zu
drucken). IBM und MS haben dann mit den Codepages 437 und 850 ein
bisschen einen Pseudo-Standard geschaffen und dann kam ISO-8859. Aber
auch da gab es wieder verschiedene Varianten.
>> Wir hatten in der Schule Apple ][, bei denen man den Zeichensatz und
>> die Tastatur mit einem Kippschalter auf der Unterseite umschalten
>> konnte. Wenn man die auf deutsch umschaltete, meldeten sie sich als
>> "Apple ÜÄ".
>
> Und das bei einer Firma, die immer soviel Wert auf das äußere
> Erscheinungsbild legt.
Apple II war 1970er-Jahre-Technologie. Als unsere Schule die Ende 1983
bekam, waren die eigentlich schon veraltet: Ein Monat später kam dann
der MacIntosh heraus.
>>> UTF ist durch diese seltsame Erweiterung nach hinten (mehr Bytes, wenn
>>> nötig) auch auf eine Art unschön.
>>
>> 32 Bit pro Zeichen (oder auch nur 16) wären Anfang der 90er-Jahre wohl
>> etwas zu viel Platzverschwendung gewesen. Außerdem hat UTF-8 die
>> angenehme Eigenschaft, dass alle ASCII-Zeichen (und damit alle für
>> Filesysteme wichtigen Zeichen wie '.', '/', '\0' unverändert blieben -
>> der Arbeitstitel von UTF-8 war UTF-FSS (file system safe), es gab damals
>> schon einen anderen Entwurf für UTF-8, bei dem das nicht der Fall war).
>
> Ohne diese Eigenschaft hätte es sich vmtl auch gar nicht durchgesetzt.
Ja, die ASCII-Kompatibilität von UTF-8 war sicher ein wichtiger Faktor.
Aber das erste Mainstream-OS, das Unicode verwendet hat (Nein, Plan-9
ist nicht Mainstream), war Windows-NT, und das hat *nicht* UTF-8
verwendet, sondern UTF-16 (bzw. am Anfang UCS-2).
> Dann hätte evtl jedes Land / Sprachraum was Eigenes gebaut.
Das hatten sie schon vorher. Genau dieses babylonische Wirrwarr wollte
Unicode ja beheben (und hat es auch geschafft).
>>> Was auch ein interessantes Ding sein könnte, wenn man alle möglichen
>>> Bitkombinationen in einem Grafikzeichensatz ablegen will. Normal sind
>>> das für 8 x 8 Pixel dann ja auch 8 x 8 Bit
>>
>> Die Idee hatte ich mit 16 auch schon ;-).
>>
>> Und als dann Computer endlich genug Speicher hatten, dass 64 Bit pro
>> Zeichen nicht mehr der totale Wahnsinn wären, hatte ich gelernt, dass es
>> Sprachen gibt, deren Zeichen sich in 8x8 Pixel absolut nicht darstellen
>> lassen. Probier mal Biangbiang (𰻝𰻝) in 8x8 Pixeln abzubilden. Selbst
>> 16x16 reicht nicht, nach meiner oberflächlichen Zählung braucht man
>> 23x21 Pixel - runden wir der Einfachheit halber auf 24x24 auf. Dann
>> braucht man aber 576 Bit (72 Byte) pro Zeichen.
>>
>> Und umgekehrt hätte das gleiche Zeichen in verschiedenen Fonts (z.B.
>> Times Roman vs. Arial) eine komplett andere Kodierung.
>>
>> Nope. Keine gute Idee.
>
> Ich find das immer noch charmant. Würde aber natürlich dann Zeichen auf
> eine fixe Größe (8x8 o.ä.) beschränken.
Du siehst das durch die "ich bin als Deutscher 1983 mit
8x8-Pixel-Zeichen ausgekommen, also muss das für die ganze Welt
reichen"-Brille.
> Evtl ist es aber sogar mal eine interessante Sache drüber nachzudenken,
> was passiert, wenn man die 576 Bit als Standard nimmt - also das größte
> sinnvoll denkbare Zeichen zum Standard erklärt. Die Auflösung der anderen
> Symbole gewinnt dadurch und mit einem Hardware-Blitter, der auch
> skaliert, ist das allemal schnell genug.
Performance ist nicht das Problem (ok, es *auch* ein Problem, aber nicht
das größte). Semantik ist das Problem. Wenn jedes 24x24-Bit-Muster, das
als "A" erkennbar ist, als A gelten soll, brauchst Du OCR. Und die OCR
muss wieder irgendwas definiertes produzieren, also brauchst Du einen
definierten Code für ein A. Und damit bist Du wieder bei Coded Character
Sets wie ASCII oder Unicode oder EBCDIC. Oder alternativ ein Embedding
für ein LLM: Aber ob ein 3000-dimensionaler Vektor besser ist?
>> Unicode hat viele Schwächen (wenn man das heute mit 30 Jahren Erfahrung
>> noch mal designen würde, würde man sicher einige Sachen anders machen),
>> aber ich halte das schon für einen recht guten Kompromiss.
>
> Muß es wohl sein, sonst wäre es nicht überall in Benutzung. Aber es hat
> eben auch so seine Eigenheiten. Und es erfordert deutlichen Aufwand im
> Vergleich zu einem definierten ASCII Zeichensatz.
Ja, die Welt ist ein bisschen komplizierter, als sich das westliche
Ingenieure in den 60er-Jahren vorgestellt haben. Daher ist auch Unicode
komplizierter als ASCII. Unicode definiert auch nicht nur eine Menge von
Zeichen, sondern auch Regeln wie man die kombiniert, was passieren muss,
wenn verschiedene Schreibrichtungen zusammenkommen, wie man sortiert,
Kleinbuchstaben in Großbuchstaben umwandelt und noch viel mehr.
hjp
[toc] | [prev] | [next] | [standalone]
| From | Kay Martinen <usenet@martinen.de> |
|---|---|
| Date | 2026-08-09 22:27 +0200 |
| Subject | Re: Zeichenkodierungen |
| Message-ID | <0i4nkm-btq.ln1@news.martinen.de> |
| In reply to | #56104 |
Am 09.08.26 um 18:09 schrieb Peter J. Holzer: > On 2026-08-09 16:24, Sebastian Barthel <naitsabes@freenet.de> wrote: >> Am Sun, 09 Aug 2026 11:57:24 +0200 schrieb der Meister Peter J. Holzer >> folgendes: >> >>> On 2026-08-08 22:30, Sebastian Barthel <naitsabes@freenet.de> wrote: >>>> Am Sat, 08 Aug 2026 15:11:48 +0200 schrieb der Meister Peter J. Holzer >>>> folgendes: >>>>> Vor ein paar Jahren ist in der Python-Newsgroup ein Kook >>>>> aufgeschlagen, der eine 12-Bit-Kodierung von Zeichen einführen wollte. >> Na ja, wird wohl auch nicht so wichtig gewesen sein, wenn es dann nicht >> weiterverfolgt worden ist oder niemals was davon zu hören war. > > Typischer Kook halt. Wobei zum typischen Kook-Verhalten auch ein > gewisses Durchhaltevermögen gehört. Wahrscheinlich taucht er in zwei > Jahren mit derselben Idee wieder auf. Jetzt lese ich "Kook" schon zum Zweiten mal und muß einfach fragen: WAS soll's Bedeuten? Ich kenne ONU, DAU, TWIT aber Kook hab ich nie gehört. Zeichenkonversions-Problem oder Backronym a'la "GNU"? Bye/ /Kay -- Posted via Leafnode
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam2616@zugschl.us> |
|---|---|
| Date | 2026-08-10 18:50 +0200 |
| Subject | Re: Zeichenkodierungen |
| Message-ID | <115cvh1$5m2b$1@news1.tnib.de> |
| In reply to | #56111 |
Kay Martinen <usenet@martinen.de> wrote: >Jetzt lese ich "Kook" schon zum Zweiten mal und muß einfach fragen: WAS >soll's Bedeuten? Ich kenne Kook aus den 1990ern aus den englischen Newsgroups. ChatGPT erweiterte meinen Horizont eben hiermit: --- begin AI slop --- Ein Kook ist ursprünglich ein Begriff aus der Surf- und Boardsport-Szene. Gemeint ist jemand, der sich für Surfen hält bzw. sich entsprechend verhält, aber wenig Erfahrung oder Können hat und dabei typische Anfängerfehler macht. Oft schwingt auch die Bedeutung mit, dass die Person die Surfkultur oder deren ungeschriebene Regeln nicht versteht. Beispielsweise: jemand fährt als Anfänger eine gefährliche Welle und bringt andere in Gefahr, paddelt anderen in die Welle, verhält sich am Spot rücksichtslos, oder trägt demonstrativ die komplette Profi-Surfausrüstung, obwohl er kaum surfen kann. Der Begriff ist abwertend, aber häufig auch humorvoll gemeint. Im weiteren englischen Sprachgebrauch kann kook auch einfach einen Spinner, Sonderling oder weltfremden Typen bezeichnen. Verwandt ist kooky („schrullig“, „exzentrisch“). Interessant: Kook ist nicht dasselbe wie „Noob“. Ein Noob ist schlicht ein Anfänger; ein Kook ist eher jemand, dessen Verhalten zusätzlich als peinlich, ahnungslos oder regelwidrig wahrgenommen wird. --- end AI slop --- Grüße Marc -- ---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
[toc] | [prev] | [next] | [standalone]
| From | michaelnoeusenet@mac.com (Michael Noe) |
|---|---|
| Date | 2026-08-10 19:36 +0200 |
| Subject | Re: Zeichenkodierungen |
| Message-ID | <1rzn3qs.1bkoons19dcktqN@ID-7682.user.dfncis.de> |
| In reply to | #56137 |
Marc Haber <mh+usenetspam2616@zugschl.us> wrote: > > Jetzt lese ich "Kook" schon zum Zweiten mal und muß einfach fragen: WAS > > soll's Bedeuten? > > Ich kenne Kook aus den 1990ern aus den englischen Newsgroups. ChatGPT > erweiterte meinen Horizont eben hiermit: Bei mir war's tatsächlich Gemini. ;-) Wieder was bei Akronymen gelernt. Denn ich kenne so einige Leute, wo das wunderbar passt. Weit mehr als bei Nerds|früher Freaks. Auch gerade außerhalb des ja meist eher recht schmalen IT-Tunnelblicks. -- Gruß Michael
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Barthel <naitsabes@freenet.de> |
|---|---|
| Date | 2026-08-09 23:46 +0000 |
| Subject | Re: Zeichenkodierungen (was: Seltsame Namensableitungen) |
| Message-ID | <115b3gs$6hq9$2@solani.org> |
| In reply to | #56104 |
Am Sun, 09 Aug 2026 18:09:35 +0200 schrieb der Meister Peter J. Holzer
folgendes:
> On 2026-08-09 16:24, Sebastian Barthel <naitsabes@freenet.de> wrote:
>> Am Sun, 09 Aug 2026 11:57:24 +0200 schrieb der Meister Peter J. Holzer
>> folgendes:
>>
>>> On 2026-08-08 22:30, Sebastian Barthel <naitsabes@freenet.de> wrote:
>>>> Am Sat, 08 Aug 2026 15:11:48 +0200 schrieb der Meister Peter J.
>>>> Holzer folgendes:
>>>>> Vor ein paar Jahren ist in der Python-Newsgroup ein Kook
>>>>> aufgeschlagen, der eine 12-Bit-Kodierung von Zeichen einführen
>>>>> wollte.
> [...]
>>> Aber anyway: Computer mit einer Wortlänge, die ein Vielfaches von 12
>>> beträgt, sind ähnlich veraltet wie Lochkarten (aber hier natürlich
>>> on-topic, aber in der Python-Gruppe nicht).
>>
>> Och - da wäre ich vorsichtig. Evtl wird das je demnächst mal
>> wiederentdeckt.
>
> Unwahrscheinlich.
Mag sein ... :)
>> 12 Bit hat auch als "Byte" so seine Vorteile - auch abseits der
>> Textcodierung.
>
> Welche denn?
> Für eine einzelne Anwendung mögen 12 Bit ideal sein. Aber dafür gibt es
> dann sicher eine andere Anwendung, für die 13 Bit besser wären.
Ich dachte eher daran, daß es als Integer mit 0..4095 schon ein paar
schöne Anwendungen geben könnte. Daß man die dann mit 13, 14, ..., 32 Bit
auch hinbekommt ist ja wieder was anderes. Aber 8 Bit ist oft eher zu
wenig.
Beispiele wären etwa übliche Bildschirmauflösungen. Relativiert sich auch
gerade (8K), aber bisher - und wahrscheinlich noch eine ganze Zeit lang -
wären <= 4096 Pixel dann ein Wort.
Wo es auch schön paßt, sind Farbwerte für einen Farbkanal. Da sind die
Anzeigen üblicherweise intern 10Bit je Kanal (etwa in Monitoren). 12Bit
deckt das schön ab. Für Profianwendungen mit 48Bit (3*12 für RGB +
1*alpha) paßt es sogar auch noch gut.
>>>> 6 Bit war ja wohl ein bißchen wenig. Dann hat man 7 Bit probiert. Das
>>>> ging eine Weile gut, aber ist auch nicht das Wahre gewesen. Mit 8 Bit
>>>> ... mit Sonderzeichen und ... Grafiksymbolen schön codieren, aber
>>>> ..., sonst bräuchte es keine Codepages und solche "Tricks".
>>>
>>> "Codepages" hatte man auch bei 7 Bit schon. ISO-646 hatte nationale
>>> Varianten: ISO-646-US kennt man unter dem Namen ASCII immer noch, aber
>>> es gab auch eine deutsche (ISO-646-DE bzw. DIN 66003 mit §ÄÖÜäöüß
>>> statt @[\]{|}~).
>>
>> Interessant. Ich habe das erst bei den DOS PCs kennengelernt.
>
> Den Ausdruck "Codepage" hat vermutlich IBM geprägt. Die hatten das nicht
> nur bei PCs, sondern auch bei den Mainframes (dort natürlich EBCDIC).
> Aber verschiedene Zeichensätze gab es natürlich auch vorher, bzw. noch
> schlimmer, weil jeder Hersteller sein eigenes Süppchen gekocht hat.
> Die ISO-646-Familie ab 1968 war da schon mal ein Fortschritt, auch wenn
> sich nicht immer alle einig waren, welche Variante sie verwenden wollen.
> Ich erinnere mich da an die Rechnungen von Ikea, auf denen die Umlaute
> nie gestimmt haben (und glaube ich nicht mal konsistent gleich falsch
> waren - vermutlich war ein Drucker auf amerikanisch eingestellt, der
> andere auf schwedisch, und die Software hat versucht, deutsch zu
> drucken). IBM und MS haben dann mit den Codepages 437 und 850 ein
> bisschen einen Pseudo-Standard geschaffen und dann kam ISO-8859. Aber
> auch da gab es wieder verschiedene Varianten.
Hatte da immer 8859-Lat, das hat alles nötige gekonnt.
>>> Wir hatten in der Schule Apple ][, bei denen man den Zeichensatz und
>>> die Tastatur mit einem Kippschalter auf der Unterseite umschalten
>>> konnte.
> Apple II war 1970er-Jahre-Technologie. Als unsere Schule die Ende 1983
> bekam, waren die eigentlich schon veraltet: Ein Monat später kam dann
> der MacIntosh heraus.
Na ja, eine deutsche Schule wird wohl kaum einen Macintosh gleich bei
Erscheinen hingestellt haben. Daher blieb dann der ganze andere 8Bit Zoo
und evtl, wenns richtig gut sein sollte, CP/M als echte Optionen übrig.
Die anderen Homecomputer waren aber so anders nun auch wieder nicht -
zumindest nicht so, daß man das hätte tauschen müssen.
Es gibt da erst um 1985 herum diese neueren Maschinen, die dann irgendwie
als Ablösung infrage gekommen wären. Und es gibt wenige, die wirklich für
ein Schulsetting gedacht waren. Die, die es dafür gab, waren oft unnötig
komplex.
Apple II hat v.a. ja auch optisch so eine 70er Jahre Anmutung. C64, VC20
sehen aber auch noch so aus. Stylisch hingegen sind ZX Spektrum oder
Atari (neue Optik). Für die Kurse dürfte das alles aber so gar keine
Rolle gespielt haben ... .
>>>> Was auch ein interessantes Ding sein könnte, wenn man alle möglichen
>>>> Bitkombinationen in einem Grafikzeichensatz ablegen will. Normal sind
>>>> das für 8 x 8 Pixel dann ja auch 8 x 8 Bit
>>>
>>> Die Idee hatte ich mit 16 auch schon ;-).
>>>
>>> Und als dann Computer endlich genug Speicher hatten, dass 64 Bit pro
>>> Zeichen nicht mehr der totale Wahnsinn wären, hatte ich gelernt, dass
>>> es Sprachen gibt, deren Zeichen sich in 8x8 Pixel absolut nicht
>>> darstellen lassen. Probier mal Biangbiang (𰻝𰻝) in 8x8 Pixeln
>>> abzubilden. Selbst 16x16 reicht nicht, nach meiner oberflächlichen
>>> Zählung braucht man 23x21 Pixel - runden wir der Einfachheit halber
>>> auf 24x24 auf. Dann braucht man aber 576 Bit (72 Byte) pro Zeichen.
>>>
>>> Und umgekehrt hätte das gleiche Zeichen in verschiedenen Fonts (z.B.
>>> Times Roman vs. Arial) eine komplett andere Kodierung.
>>>
>>> Nope. Keine gute Idee.
>>
>> Ich find das immer noch charmant. Würde aber natürlich dann Zeichen auf
>> eine fixe Größe (8x8 o.ä.) beschränken.
>
> Du siehst das durch die "ich bin als Deutscher 1983 mit
> 8x8-Pixel-Zeichen ausgekommen, also muss das für die ganze Welt
> reichen"-Brille.
Mag sein. Aber es reicht halt in dem Bereich und Umgebung doch für
erstaunlich viele Sprachen auch gut aus.
Und es hat (hätte) dann auch alle sinnvollen Grafiksymbole gleich mit
dabei (sowas wie Ecken, Linien, Winkel).
>> Evtl ist es aber sogar mal eine interessante Sache drüber nachzudenken,
>> was passiert, wenn man die 576 Bit als Standard nimmt - also das größte
>> sinnvoll denkbare Zeichen zum Standard erklärt. Die Auflösung der
>> anderen Symbole gewinnt dadurch und mit einem Hardware-Blitter, der
>> auch skaliert, ist das allemal schnell genug.
>
> Performance ist nicht das Problem (ok, es *auch* ein Problem, aber nicht
> das größte). Semantik ist das Problem. Wenn jedes 24x24-Bit-Muster, das
> als "A" erkennbar ist, als A gelten soll, brauchst Du OCR. Und die OCR
> muss wieder irgendwas definiertes produzieren, also brauchst Du einen
> definierten Code für ein A. Und damit bist Du wieder bei Coded Character
> Sets wie ASCII oder Unicode oder EBCDIC. Oder alternativ ein Embedding
> für ein LLM: Aber ob ein 3000-dimensionaler Vektor besser ist?
Schon. Beim reinen Ausgeben mit "Coded Character Set" hat man dann eben
auch die Möglichkeit sehr komplexe Zeichen darzustellen.
Leider sind 2^576 auch ein paar dezimale Ziffern ... es wird also
potentiell eine große Codetabelle.
(OCR in der Art hatte ich auch mal probehalber gebaut. Das funktioniert
nicht wirklich gut. Die Idee dabei war, daß man aus bestimmten Maßzahlen
der Einzel-Bits (also sowas wie Verhältnis der Schwärzungsgrade der
oberen zu unteren Iconhälfte, und ähnliches) evtl die Buchstaben
ermitteln könne.)
Trotzdem ist es eigentlich als Idee ganz charmant, wenn man sich aufs
Ausgeben beschränkt. 24x24 könnten dann ja gleich auch mal 32x32 sein,
dann ist Puffer da und man bekommt es vmtl., für die einfachen
Buchstaben, auch schön auf 8x8 runterskaliert, wenn z.B. die Auflösung es
nicht anders her gibt.
> Ja, die Welt ist ein bisschen komplizierter, als sich das westliche
> Ingenieure in den 60er-Jahren vorgestellt haben. Daher ist auch Unicode
> komplizierter als ASCII. Unicode definiert auch nicht nur eine Menge von
> Zeichen, sondern auch Regeln wie man die kombiniert, was passieren muss,
> wenn verschiedene Schreibrichtungen zusammenkommen, wie man sortiert,
> Kleinbuchstaben in Großbuchstaben umwandelt und noch viel mehr.
Spricht ja immerhin auch dafür, daß es zumindest in dem Bereich echten
Fortschritt gegeben hat.
Für den, der einfach nur einen englischen (ISO-Latin) Text ausgeben will,
wird es aber ungleich schwieriger, als es so schon war. Ich sag mal nur
JSR $FFD2 ... , aber das macht heut' eh keiner mehr.
VG,
SBn
[toc] | [prev] | [next] | [standalone]
| From | michaelnoeusenet@mac.com (Michael Noe) |
|---|---|
| Date | 2026-08-10 08:01 +0200 |
| Subject | Re: Zeichenkodierungen |
| Message-ID | <1rzm8wb.1bpnpx61swwf3tN@ID-7682.user.dfncis.de> |
| In reply to | #56116 |
Sebastian Barthel <naitsabes@freenet.de> wrote: > > Apple II war 1970er-Jahre-Technologie. Als unsere Schule die Ende 1983 > > bekam, waren die eigentlich schon veraltet: Ein Monat später kam dann > > der MacIntosh heraus. > > Na ja, eine deutsche Schule wird wohl kaum einen Macintosh gleich bei > Erscheinen hingestellt haben. Eher nicht. ;-) Ein einfacher Commodore PC-10 kostete 1985 knapp 5000 Mark. Selbst bei Vobis. Ohne Festplatte freilich. Und mit 1970er-Jahre-Technologie, weil halt nur ein IBM-PC-Klon. Galt jedoch als Preisbrecher. Das konnte NEC mit seinem PC-98 da bereits sehr viel besser. Später auch Fujitsu mit dem FM Towns. Der Vorteil des Apple II war damals halt das riesige Angebot an Bildungssoftware generell. Und beileibe nicht nur wegen Apple Pascal. Was auch der Hauptgrund dafür war, noch 1991 wohlgemerkt: <https://en.wikipedia.org/wiki/Apple_IIe_Card> > Apple II hat v.a. ja auch optisch so eine 70er Jahre Anmutung. Welcher denn? ;-) > C64, VC20 sehen aber auch noch so aus. Stylisch hingegen sind ZX Spektrum > oder Atari (neue Optik). Für die Kurse dürfte das alles aber so gar keine > Rolle gespielt haben ... . Ich dachte bisher immer, dass gerade der beige Commodore 64 - "Brotkasten" - ein wunderbares Beispiel für das typische Design der 1980er ist. Und der hatte gegenüber dem "deutschen" IIe übrigens nicht mal einen umschaltbaren deutschen Zeichensatz. "APPLE ÜÄ": weil Umbelegung von ][. Auch beige Rauhfasertapeten waren damals arg modern. So richtig stylish wurde es ab dem Apple IIc. Wobei auch der Amiga 1000 ein schönes Beispiel für gutes Industriedesign ist. Der 65|130XE samt ST ebenso. Bei IBM IMHO erst ab den PS/1|2. Den PC JX mal ausgenommen. Genau das Modell steht hier im Büro - schon wegen der damals für UK typischen Optik: :-) <https://upload.wikimedia.org/wikipedia/commons/9/91/Amstrad_CPC464.jpg?utm_source=de.wikipedia.org&utm_campaign=index&utm_content=original> Exakt mit diesem Monitor. Und optisch und technisch praktisch neu. :-) Auch den Sinclair ZX Spectrum fand ich damals optisch weit hübscher als ein C64. -- Gruß Michael
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2026-08-10 08:25 +0200 |
| Subject | Re: Zeichenkodierungen (was: Seltsame Namensableitungen) |
| Message-ID | <slrn117irnm.sk3c.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #56116 |
On 2026-08-10 01:46, Sebastian Barthel <naitsabes@freenet.de> wrote:
> Am Sun, 09 Aug 2026 18:09:35 +0200 schrieb der Meister Peter J. Holzer
> folgendes:
>
>> On 2026-08-09 16:24, Sebastian Barthel <naitsabes@freenet.de> wrote:
>>> Am Sun, 09 Aug 2026 11:57:24 +0200 schrieb der Meister Peter J. Holzer
>>> folgendes:
>>>
>>>> On 2026-08-08 22:30, Sebastian Barthel <naitsabes@freenet.de> wrote:
>>>>> Am Sat, 08 Aug 2026 15:11:48 +0200 schrieb der Meister Peter J.
>>>>> Holzer folgendes:
>>>>>> Vor ein paar Jahren ist in der Python-Newsgroup ein Kook
>>>>>> aufgeschlagen, der eine 12-Bit-Kodierung von Zeichen einführen
>>>>>> wollte.
>> [...]
>>>> Aber anyway: Computer mit einer Wortlänge, die ein Vielfaches von 12
>>>> beträgt, sind ähnlich veraltet wie Lochkarten (aber hier natürlich
>>>> on-topic, aber in der Python-Gruppe nicht).
>>>
>>> Och - da wäre ich vorsichtig. Evtl wird das je demnächst mal
>>> wiederentdeckt.
>>
>> Unwahrscheinlich.
>
> Mag sein ... :)
>
>>> 12 Bit hat auch als "Byte" so seine Vorteile - auch abseits der
>>> Textcodierung.
>>
>> Welche denn?
>> Für eine einzelne Anwendung mögen 12 Bit ideal sein. Aber dafür gibt es
>> dann sicher eine andere Anwendung, für die 13 Bit besser wären.
>
> Ich dachte eher daran, daß es als Integer mit 0..4095 schon ein paar
> schöne Anwendungen geben könnte. Daß man die dann mit 13, 14, ..., 32 Bit
> auch hinbekommt ist ja wieder was anderes. Aber 8 Bit ist oft eher zu
> wenig.
Dann nimmst Du halt 16 Bit. Dass 8 Bit die kleinste adressierbare
Einheit ist, heißt ja nicht, dass man auf 8-Bit-Zahlen beschränkt ist.
Aktuelle Prozessoren können typischerweise mit 8-, 16-. 32- und 64-Bit-
Zahlen umgehen.
Gut, wenn Du nur 12 Bit bräuchtest und 16 Bit nehmen musst,
verschwendest Du 4 Bits. Aber wenn Du 13 Bit bräuchtest, müsstest Du bei
Deinem 12-Bit-Prozessor auf 24 Bit gehen und würdest 11 Bit
verschwenden. Für die Speicher-Ökonomie wäre eine möglichst kleine
Einheit sinnvoll, nicht eine möglichst große. Nicht umsonst können
manche GPUs mittlerweile mit 4-Bit-Floating-Point-Zahlen(!) umgehen.
> Beispiele wären etwa übliche Bildschirmauflösungen. Relativiert sich auch
> gerade (8K), aber bisher - und wahrscheinlich noch eine ganze Zeit lang -
> wären <= 4096 Pixel dann ein Wort.
Und davor noch deutlich länger <= 2048, da hätte man nach Deiner Logik
11-Bit-CPUs haben müssen. Aber auch da hat es Multi-Monitor-Setups
gegeben und für Koordinatenberechnungen wollte man sowieso noch Reserve
haben. Eine Wortgröße, die genau die Breite eines physischen Displays
aufnehmen kann, macht vermutlich nicht mal für eine Graphikkarte Sinn,
geschweige denn für ein Computersystem als Ganzes.
> Wo es auch schön paßt, sind Farbwerte für einen Farbkanal. Da sind die
> Anzeigen üblicherweise intern 10Bit je Kanal (etwa in Monitoren).
Und RGB hat dann schön in 32 Bit Platz.
>>>> Wir hatten in der Schule Apple ][, bei denen man den Zeichensatz und
>>>> die Tastatur mit einem Kippschalter auf der Unterseite umschalten
>>>> konnte.
>
>> Apple II war 1970er-Jahre-Technologie. Als unsere Schule die Ende 1983
>> bekam, waren die eigentlich schon veraltet: Ein Monat später kam dann
>> der MacIntosh heraus.
>
> Na ja, eine deutsche Schule wird wohl kaum einen Macintosh gleich bei
> Erscheinen hingestellt haben.
Klar. Aber ich habe auf Deinen Einwurf, dass Apple doch so viel Wert auf
Design gelegt hätte, geantwortet. Das begann aber eben erst mit dem Mac
(1984) oder vielleicht der Lisa (kurz vorher). Der Apple II stammt aber
aus dem Jahr 1977. Da hat Apple hauptsächlich Wert darauf gelegt, einen
brauchbaren Computer zu bezahlbaren Preisen anzubieten. Und den
europäischen Markt hatten sie vermutlich noch gar nicht im Blick.
> Apple II hat v.a. ja auch optisch so eine 70er Jahre Anmutung.
Was bei einem Rechner aus den 70er-Jahren jetzt nicht wirklich
verwunderlich ist.
> C64, VC20 sehen aber auch noch so aus. Stylisch hingegen sind ZX
> Spektrum
Naja. Schwarzer Schokoriegel mit grauen Gummitasten. Stylisch ist was
anderes. Der Sinclair QL ein paar Jahre später war stylisch.
> oder Atari (neue Optik).
800XL? Ja, da stimme ich zu.
hjp
[toc] | [prev] | [next] | [standalone]
| From | michaelnoeusenet@mac.com (Michael Noe) |
|---|---|
| Date | 2026-08-10 09:36 +0200 |
| Subject | Apple ][ (was: Zeichenkodierungen) |
| Message-ID | <1rzmda4.13lya5c1al0lhaN@ID-7682.user.dfncis.de> |
| In reply to | #56123 |
Peter J. Holzer <hjp-usenet4@hjp.at> wrote: > > > Apple II war 1970er-Jahre-Technologie. Als unsere Schule die Ende 1983 > > > bekam, waren die eigentlich schon veraltet: Ein Monat später kam dann > > > der MacIntosh heraus. > > > > Na ja, eine deutsche Schule wird wohl kaum einen Macintosh gleich bei > > Erscheinen hingestellt haben. > > Klar. Aber ich habe auf Deinen Einwurf, dass Apple doch so viel Wert auf > Design gelegt hätte, geantwortet. Das begann aber eben erst mit dem Mac > (1984) oder vielleicht der Lisa (kurz vorher). Der Apple II stammt aber > aus dem Jahr 1977. Da hat Apple hauptsächlich Wert darauf gelegt, einen > brauchbaren Computer zu bezahlbaren Preisen anzubieten. Und den > europäischen Markt hatten sie vermutlich noch gar nicht im Blick. 1977 sicherlich noch nicht, aber bereits 1979 mit dem Apple ][ Europlus. Die Arbeit hat sich damals kaum ein nicht bundesdeutscher Hersteller gemacht. Welche eh kaum PCs|Heimcomputer selbst entwickelt und hergestellt haben. (TA wollte etwa mehr Geld als selbst Apple. Mit Spielecomputern wollten die damals in Nürnberg erst gar nicht konkurrieren.) Commodore damals und "Design"? Der IBM PC samt 1970er-Technologie? Ersteres nein, letzteres ja. Immerhin sah der Atari 400|800 so aus, als hätte kurz zuvor gerade Commander Adama davor gesessen. Beim PET von 1977 sowieso. Beim IBM PC immerhin Bill Gates samt BASICA: LOAD "CAS1:PROGRAMM" > > Apple II hat v.a. ja auch optisch so eine 70er Jahre Anmutung. > > Was bei einem Rechner aus den 70er-Jahren jetzt nicht wirklich > verwunderlich ist. Und welcher denn? ;-) Ansonsten ist *der* IBM PC freilich immerzu der von 1981. Mit Kassettenport und Microsoft BASIC in der Firmware. Technisch schon damals komplett veraltet, dafür aber immerhin teuer und vor allem von IBM. Nicht mal optisch für damals "modern". > > C64, VC20 sehen aber auch noch so aus. Stylisch hingegen sind ZX > > Spektrum > > Naja. Schwarzer Schokoriegel mit grauen Gummitasten. Stylisch ist was > anderes. Der Sinclair QL ein paar Jahre später war stylisch. Der QL kam gerade mal 1,5 Jahre nach dem Spectrum auf den Markt. Insbesondere die QL-Tastatur hatte auch nicht unbedingt den besten Ruf. ;-) Immerhin hatte der gegenüber Microsoft BASIC V2 wie schon der Spectrum ein sehr brauchbares BASIC. Auch Assembler machte damit Spaß - "Just for Fun" -, da schon mal kein eher seltsamer Intel 8088. Wenn man auch 68k haben konnte. > > oder Atari (neue Optik). > > 800XL? Ja, da stimme ich zu. Der war eher noch alte Optik. ;-) Wobei mir persönlich der 600|800XL besser gefällt als die Optik des VIC 20. 65XE|ST und aufwärts. Und dann kam Frog Design. Samt dem IIc. -- Gruß Michael
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Barthel <naitsabes@freenet.de> |
|---|---|
| Date | 2026-08-10 12:19 +0000 |
| Subject | Re: Apple ][ (was: Zeichenkodierungen) |
| Message-ID | <115cfkm$7jdt$2@solani.org> |
| In reply to | #56126 |
Am Mon, 10 Aug 2026 09:36:45 +0200 schrieb der Meister Michael Noe
folgendes:
> Peter J. Holzer <hjp-usenet4@hjp.at> wrote:
>
>> > > Apple II war 1970er-Jahre-Technologie. Als unsere Schule die Ende
>> > > 1983 bekam, waren die eigentlich schon veraltet: Ein Monat später
>> > > kam dann der MacIntosh heraus.
>> >
>> > Na ja, eine deutsche Schule wird wohl kaum einen Macintosh gleich bei
>> > Erscheinen hingestellt haben.
>>
>> Klar. Aber ich habe auf Deinen Einwurf, dass Apple doch so viel Wert
>> auf Design gelegt hätte, geantwortet. Das begann aber eben erst mit dem
>> Mac (1984) oder vielleicht der Lisa (kurz vorher). Der Apple II stammt
>> aber aus dem Jahr 1977. Da hat Apple hauptsächlich Wert darauf gelegt,
>> einen brauchbaren Computer zu bezahlbaren Preisen anzubieten. Und den
>> europäischen Markt hatten sie vermutlich noch gar nicht im Blick.
Wahrscheinlich hattest Du ja ursprünglich das "technische Design" gemeint
("Apple II war 1970er-Jahre-Technologie"). Wobei auch das so schlecht
nicht gewesen ist; was man so liest.
//Design// hatte der Apple ][ schon auch. Aber eben nicht so ein
"modernes". 1969 wäre das evtl. sogar überaus futuristisch gewesen.
Die Kunst am "80'er Jahre Design" besteht ja v.a. am Weglassen. Weglassen
von Knöpfen, Drehreglern, Maustasten, Farben und dem Hinzufügen von
"ikonischen" Linien oder einfachen und doch markanten Figuren
(angeschnittene Kreise bei den späteren Spektrum Tastaturen etwa).
> 1977 sicherlich noch nicht, aber bereits 1979 mit dem Apple ][ Europlus.
> Die Arbeit hat sich damals kaum ein nicht bundesdeutscher Hersteller
> gemacht. Welche eh kaum PCs|Heimcomputer selbst entwickelt und
> hergestellt haben. (TA wollte etwa mehr Geld als selbst Apple. Mit
> Spielecomputern wollten die damals in Nürnberg erst gar nicht
> konkurrieren.)
Aber die (TA) hatten ziemlich sicher einen (Industrie)Designer. Sonst
würde das nicht so aussehen. Und das meiste sieht gut aus.
Daß man in DLand den großen Markt der kleinen Rechner nicht gesehen hat -
nun ja, das ist wohl der trägen Biederkeit hierzulande zuzuschreiben.
Dafür kann man schöne und hochwertige Gartenscheren bekommen. :)
> Commodore damals und "Design"? Der IBM PC samt 1970er-Technologie?
> Ersteres nein, letzteres ja.
Bei den PETs würd ich ja auch denken, daß die so aussehen, weil einfach
irgendeine Metallbox gefunden werden mußte, die a. einen Monitor trägt
und b. in die man die vorhandenen Minikeyboards einbauen konnte, bis sie
alle sind.
> Immerhin sah der Atari 400|800 so aus, als hätte kurz zuvor gerade
> Commander Adama davor gesessen. Beim PET von 1977 sowieso.
>
> Beim IBM PC immerhin Bill Gates samt BASICA:
>
> LOAD "CAS1:PROGRAMM"
Hat aber funktioniert ... und ist Weltmarktführer geworden.
>> > Apple II hat v.a. ja auch optisch so eine 70er Jahre Anmutung.
>>
>> Was bei einem Rechner aus den 70er-Jahren jetzt nicht wirklich
>> verwunderlich ist.
Schon. Aber es ist eben kein "neues" / "frisches" Design. Hätte es aber
ja durchaus schon sein können.
70er Jahre ist z.B. die Farbgebung - sowohl der Keyboardtasten als auch
der Gehäusefarbe.
Hätte ja auch ein Mint-Pastell-Grün und weiße Tasten sein können ... war
aber passend zur hölzernen Einbauschrankwand gemacht.
> Und welcher denn? ;-)
Na der erste halt ... .
> Ansonsten ist *der* IBM PC freilich immerzu der von 1981. Mit
> Kassettenport und Microsoft BASIC in der Firmware. Technisch schon
> damals komplett veraltet, dafür aber immerhin teuer und vor allem von
> IBM. Nicht mal optisch für damals "modern".
>
>> > C64, VC20 sehen aber auch noch so aus. Stylisch hingegen sind ZX
>> > Spektrum
>>
>> Naja. Schwarzer Schokoriegel mit grauen Gummitasten. Stylisch ist was
>> anderes. Der Sinclair QL ein paar Jahre später war stylisch.
Stimmt. QL sieht echt schick aus.
Würde man heute evtl sogar noch gut finden, wenns neu käme.
> Der QL kam gerade mal 1,5 Jahre nach dem Spectrum auf den Markt.
>
> Insbesondere die QL-Tastatur hatte auch nicht unbedingt den besten Ruf.
> ;-)
Bißchen was zum Mäkeln muß an allen Geräten sein - sonst wäre es ja
langweilig. :)
> Immerhin hatte der gegenüber Microsoft BASIC V2 wie schon der Spectrum
> ein sehr brauchbares BASIC. Auch Assembler machte damit Spaß - "Just for
> Fun" -, da schon mal kein eher seltsamer Intel 8088. Wenn man auch 68k
> haben konnte.
>
>> > oder Atari (neue Optik).
>>
>> 800XL? Ja, da stimme ich zu.
>
> Der war eher noch alte Optik. ;-)
>
> Wobei mir persönlich der 600|800XL besser gefällt als die Optik des VIC
> 20.
>
> 65XE|ST und aufwärts.
Ich hätte sowas wie 130XE gemeint. Dagegen ist VC20 (C64 Brotkasten) eben
schon noch "staubig".
> Und dann kam Frog Design. Samt dem IIc.
Na, das war auch eine Ausnahme. Der IIGS sammelt das dann wieder ein und
ist letztlich auch wieder nur "Büchse".
Oft steht und fällt das gute Aussehen in dem Bereich ja mit dem Nicht-/
Vorhandensein von Erweiterungssteckplätzen. Eigentlch sogar bis heute.
Die aktuellen PCs mit Seitenfenster können richtig schick aussehen, wenn
kleine Boards mit 4 Slots verbaut sind und das Case diese Größe hat. Die
allermeisten wollen aber dann doch die sieben Slots haben; man weiß ja
nie. Dementsprechend sind das dann immer noch ziemlich boxige Tower/
Minitower und es sieht letztlich - trotz Regenbogenbeleuchtung und
optisch leichten weißen Lüftern - irgendwie klobig aus.
VG.
[toc] | [prev] | [next] | [standalone]
| From | michaelnoeusenet@mac.com (Michael Noe) |
|---|---|
| Date | 2026-08-10 15:11 +0200 |
| Subject | Re: Apple ][ |
| Message-ID | <1rzmqqy.rb1yh0fvvf34N@ID-7682.user.dfncis.de> |
| In reply to | #56132 |
Sebastian Barthel <naitsabes@freenet.de> wrote:
> Wahrscheinlich hattest Du ja ursprünglich das "technische Design" gemeint
> ("Apple II war 1970er-Jahre-Technologie").
Technisch ist das der IBM PC freilich sowieso.
> Wobei auch das so schlecht nicht gewesen ist; was man so liest.
Daran soll wohl Woz schuld gewesen sein. ;-)
> //Design// hatte der Apple ][ schon auch. Aber eben nicht so ein
> "modernes". 1969 wäre das evtl. sogar überaus futuristisch gewesen.
So wie der PET, als wäre er damals gerade Kampfstern Galactica
entsprungen? ;-)
Bei 1969 denke ich eher an sowas wie einen Robotron 300. Und vor allem
an riesige Bandlaufwerke.
> Die Kunst am "80'er Jahre Design" besteht ja v.a. am Weglassen. Weglassen
> von Knöpfen, Drehreglern, Maustasten, Farben und dem Hinzufügen von
> "ikonischen" Linien oder einfachen und doch markanten Figuren
> (angeschnittene Kreise bei den späteren Spektrum Tastaturen etwa).
Ich denke dabei eher an Hartmut Esslinger. ;-)
> Aber die (TA) hatten ziemlich sicher einen (Industrie)Designer. Sonst
> würde das nicht so aussehen. Und das meiste sieht gut aus.
>
> Daß man in DLand den großen Markt der kleinen Rechner nicht gesehen hat -
> nun ja, das ist wohl der trägen Biederkeit hierzulande zuzuschreiben.
Was dann massiv zum schnellen Ende der Nixdorf Computer AG beigetragen
hat.
Weltweit relevante Hersteller von Micros gab es schon damals nicht in
Deutschland.
> > Commodore damals und "Design"? Der IBM PC samt 1970er-Technologie?
> > Ersteres nein, letzteres ja.
>
> Bei den PETs würd ich ja auch denken, daß die so aussehen, weil einfach
> irgendeine Metallbox gefunden werden mußte, die a. einen Monitor trägt
> und b. in die man die vorhandenen Minikeyboards einbauen konnte, bis sie
> alle sind.
Hätte durchaus auch schon gut ins Setting von 2001: A Space Odyssey
gepasst. ;-)
> > Immerhin sah der Atari 400|800 so aus, als hätte kurz zuvor gerade
> > Commander Adama davor gesessen. Beim PET von 1977 sowieso.
> >
> > Beim IBM PC immerhin Bill Gates samt BASICA:
> >
> > LOAD "CAS1:PROGRAMM"
>
> Hat aber funktioniert ... und ist Weltmarktführer geworden.
Bis Compaq ihnen diese abnahm, was PCs angeht. ;-)
Gibt es auch nicht mehr.
> > > > Apple II hat v.a. ja auch optisch so eine 70er Jahre Anmutung.
> > >
> > > Was bei einem Rechner aus den 70er-Jahren jetzt nicht wirklich
> > > verwunderlich ist.
>
> Schon. Aber es ist eben kein "neues" / "frisches" Design. Hätte es aber
> ja durchaus schon sein können.
>
> 70er Jahre ist z.B. die Farbgebung - sowohl der Keyboardtasten als auch
> der Gehäusefarbe.
Beim originören II von 1977: ja. Beige Gehäuse waren aber bis weit in
die 1980er noch in. Da hatte Apple längst auf die
Snow-White-Designsprache umgestellt, auch bei den neueren
Apple-II-Modellen wie dem c und GS. Selbst späte Modelle des e gab es
damit.
Dazu 1977 eine dunkelbraune Tastatur. Kommt mir alles irgendwie sehr
bekannt vor, denn da fällt mir eigentlich zuerst der Commodore 64 ein.
;-)
Und natürlich die braunen Laufwerke des cremefarbenen IBM PC|XT. Typisch
für die erste Hälfte der 1980er. Da fand ich sogar den C64 hübscher.
> Hätte ja auch ein Mint-Pastell-Grün und weiße Tasten sein können ... war
> aber passend zur hölzernen Einbauschrankwand gemacht.
Gut, dass es anders kam. ;-)
Ikonisches 70er-Jahre-Design ist für mich viel eher das Atari VCS 2600:
<https://de.wikipedia.org/wiki/Atari_2600#/media/Datei:Atari-2600-Light-Sixer-FL.jpg>
Samt damals typischer Holzoptik. :-)
> > > > oder Atari (neue Optik).
> > >
> > > 800XL? Ja, da stimme ich zu.
> >
> > Der war eher noch alte Optik. ;-)
> >
> > Wobei mir persönlich der 600|800XL besser gefällt als die Optik des VIC
> > 20.
> >
> > 65XE|ST und aufwärts.
>
> Ich hätte sowas wie 130XE gemeint. Dagegen ist VC20 (C64 Brotkasten) eben
> schon noch "staubig".
Der war beim 65XE bereits "inkludiert". ;-)
Kam jedoch samt ST erst 1985 auf den Markt.
> > Und dann kam Frog Design. Samt dem IIc.
>
> Na, das war auch eine Ausnahme. Der IIGS sammelt das dann wieder ein und
> ist letztlich auch wieder nur "Büchse".
Bitte? Der wurde auch von Frog Design gestaltet.
Ich finde den ganz schick. :-)
<https://www.apple2history.org/history/ah10/>
> Oft steht und fällt das gute Aussehen in dem Bereich ja mit dem Nicht-/
> Vorhandensein von Erweiterungssteckplätzen. Eigentlch sogar bis heute.
> Die aktuellen PCs mit Seitenfenster
Wozu ist das gut?
> können richtig schick aussehen, wenn kleine Boards mit 4 Slots verbaut
> sind und das Case diese Größe hat.
Tower-PCs sind abseits von Hardcore-Gamern im Privatbereich praktisch
seit vielen Jahren weitgehend verschwunden und nur noch eine kleine
Nische. Notebooks haben Desktop-Computer beim Absatz generell bereits
vor knapp 20 Jahren überholt.
> Die allermeisten wollen aber dann doch die sieben Slots haben; man weiß ja
> nie. Dementsprechend sind das dann immer noch ziemlich boxige Tower/
> Minitower und es sieht letztlich - trotz Regenbogenbeleuchtung und optisch
> leichten weißen Lüftern - irgendwie klobig aus.
Kirmes-PCs sind nicht so meins. ;-)
--
Gruß
Michael
[toc] | [prev] | [next] | [standalone]
Page 6 of 14 — ← Prev page 1 … 4 5 [6] 7 8 … 14 Next page →
Back to top | Article view | de.alt.folklore.computer
csiph-web