Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.sci.electronics > #369166 > unrolled thread
| Started by | Helmut Schellong <var@schellong.biz> |
|---|---|
| First post | 2026-09-08 19:00 +0200 |
| Last post | 2026-09-12 15:31 +0200 |
| Articles | 20 on this page of 227 — 17 participants |
Back to article view | Back to de.sci.electronics
Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-08 19:00 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-08 22:34 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-09 07:38 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-09 13:17 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-09 16:22 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Stefan Wiens <s.wi@gmx.net> - 2026-09-09 16:48 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-09 17:00 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-09 22:22 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Stefan Wiens <s.wi@gmx.net> - 2026-09-10 07:52 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 14:03 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Stefan Wiens <s.wi@gmx.net> - 2026-09-10 16:47 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 18:12 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-09 17:20 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-09 18:20 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-09 22:21 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 01:28 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-10 07:49 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 13:53 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-10 15:28 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 17:41 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-10 20:15 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-11 00:54 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-11 15:01 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-11 18:40 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-11 21:30 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 12:11 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-12 18:01 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 22:06 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-13 15:23 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-13 20:58 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 08:11 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-12 09:49 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 14:14 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 15:39 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 16:01 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-12 18:19 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 23:40 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-13 15:52 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-13 22:00 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 23:38 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 23:49 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 13:26 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 15:40 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 16:09 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 23:40 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-13 00:03 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-13 15:26 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-13 21:26 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-13 22:30 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-13 23:28 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-14 11:14 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-14 11:56 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-14 16:49 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-14 17:31 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-14 19:09 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-14 22:33 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de.invalid> - 2026-09-15 23:49 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-16 12:59 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de.invalid> - 2026-09-17 00:53 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-17 11:33 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-14 19:28 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-14 22:52 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-15 09:54 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-15 15:39 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-14 10:11 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-14 11:38 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-15 08:25 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-15 15:17 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-16 08:44 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-16 13:58 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-16 18:15 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-16 23:38 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-17 08:41 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-17 15:07 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-18 09:02 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-18 11:03 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-18 12:26 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-18 11:07 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-18 11:41 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-18 22:12 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-19 01:19 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-19 09:52 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-19 14:24 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-19 20:08 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Ralph Aichinger <ra@h5.or.at> - 2026-09-14 16:25 +0000
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-13 15:32 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-13 21:43 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-14 11:15 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-14 12:00 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-14 13:54 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-14 16:43 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-14 19:11 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-14 22:46 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-15 09:53 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-15 15:32 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-17 13:43 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Axel Berger <Spam@Berger-Odenthal.De> - 2026-09-17 14:24 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-17 16:08 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-18 08:52 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-18 08:53 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-18 11:03 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Ralph Aichinger <ra@h5.or.at> - 2026-09-18 09:53 +0000
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-18 22:02 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-18 12:23 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-18 22:04 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Christian Weisgerber <naddy@mips.inka.de> - 2026-09-18 14:53 +0000
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-18 18:02 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-18 22:41 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-19 00:37 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-19 02:08 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-19 09:03 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-19 14:08 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-19 15:14 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-19 20:37 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-17 15:16 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-17 15:54 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-17 17:25 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-17 20:37 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-17 21:53 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Stefan Wiens <s.wi@gmx.net> - 2026-09-17 21:58 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-17 22:05 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-17 21:47 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-18 10:36 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-14 16:52 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-14 17:59 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Ralph Aichinger <ra@h5.or.at> - 2026-09-12 06:55 +0000
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 13:55 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 15:41 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 16:14 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-12 18:14 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 23:14 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Ralph Aichinger <ra@h5.or.at> - 2026-09-10 19:04 +0000
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-11 01:03 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-10 10:09 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-10 11:50 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-10 14:51 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Axel Berger <Spam@Berger-Odenthal.De> - 2026-09-10 15:35 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Hergen Lehmann <hlehmann-usenet26@snafu.de> - 2026-09-10 16:24 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Axel Berger <Spam@Berger-Odenthal.De> - 2026-09-10 21:32 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Andreas Bockelmann <xotzil@gmx.de> - 2026-09-16 06:32 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Volker Bartheld <news2026@bartheld.net> - 2026-09-10 22:20 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 16:09 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 15:45 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2026-09-11 18:13 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-11 20:17 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 08:13 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 13:41 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 15:48 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Volker Bartheld <news2026@bartheld.net> - 2026-09-12 15:57 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 16:40 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-12 18:10 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Volker Bartheld <news2026@bartheld.net> - 2026-09-09 18:33 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-09 18:50 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-09 22:18 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 00:42 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-10 07:52 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-10 09:55 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Volker Bartheld <news2026@bartheld.net> - 2026-09-10 22:15 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Stefan Wiens <s.wi@gmx.net> - 2026-09-11 00:43 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Volker Bartheld <news2026@bartheld.net> - 2026-09-12 08:48 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Stefan Wiens <s.wi@gmx.net> - 2026-09-12 09:14 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Volker Bartheld <news2026@bartheld.net> - 2026-09-12 09:31 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Stefan Wiens <s.wi@gmx.net> - 2026-09-12 13:54 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Volker Bartheld <news2026@bartheld.net> - 2026-09-12 15:46 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Stefan Wiens <s.wi@gmx.net> - 2026-09-12 15:56 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Stefan Wiens <s.wi@gmx.net> - 2026-09-24 18:43 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 15:52 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Volker Bartheld <news2026@bartheld.net> - 2026-09-12 16:29 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 23:44 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 14:13 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-09 14:41 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-09 16:51 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-09 22:14 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 00:22 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-10 09:52 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 14:50 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Heinz Schmitz <sch@example.invalid> - 2026-09-09 09:04 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2026-09-09 09:21 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-09 15:07 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-09 15:03 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-09 17:21 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-09 18:44 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-10 07:54 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 14:44 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2026-09-11 09:02 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Stefan Wiens <s.wi@gmx.net> - 2026-09-11 09:41 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-11 15:04 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Stefan Wiens <s.wi@gmx.net> - 2026-09-11 15:59 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-11 11:38 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-11 15:08 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-11 19:01 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-11 21:32 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 12:41 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 15:55 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-12 18:05 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de.invalid> - 2026-09-09 23:30 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 02:04 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-10 10:13 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-10 15:54 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-10 20:18 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-11 01:02 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-11 15:03 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de.invalid> - 2026-09-10 23:28 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Andreas Bockelmann <xotzil@gmx.de> - 2026-09-11 10:13 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Volker Bartheld <news2026@bartheld.net> - 2026-09-12 09:05 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Andreas Bockelmann <xotzil@gmx.de> - 2026-09-14 20:04 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Volker Bartheld <news2026@bartheld.net> - 2026-09-14 20:40 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Andreas Bockelmann <xotzil@gmx.de> - 2026-09-15 09:13 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Bernd Laengerich <Bernd.Laengerich@web.de> - 2026-09-15 09:09 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-15 15:23 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Heinz Schmitz <sch@example.invalid> - 2026-09-21 14:23 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Manuel Reimer <manuel.nulldevice@nurfuerspam.de> - 2026-09-11 18:17 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-11 20:26 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 08:15 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-12 09:50 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Volker Bartheld <news2026@bartheld.net> - 2026-09-12 10:45 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 14:59 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-09-12 15:58 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 16:48 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 14:19 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 13:51 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marcel Mueller <news.5.maazl@spamgourmet.org> - 2026-09-11 18:19 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-11 20:44 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-09-11 21:33 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 13:11 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Marcel Mueller <news.5.maazl@spamgourmet.org> - 2026-09-12 13:47 +0200
Re: Aus den Angeln hebender Reinfall bei Backup ins Internet Helmut Schellong <var@schellong.biz> - 2026-09-12 15:31 +0200
Page 1 of 12 [1] 2 3 … 12 Next page →
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-08 19:00 +0200 |
| Subject | Aus den Angeln hebender Reinfall bei Backup ins Internet |
| Message-ID | <117pev1$60lu$1@solani.org> |
Hallo, ich hatte immer mal wieder von meinem dreistufigen Backup-Konzept geredet. Ich mußte gerade in den letzten Tagen eine weitere Kategorie hinzufügen. Meine dritte Stufe - Backup ins Internet - hatte ich im Juli erfolgreich in Betrieb genommen. Vier große (je 3..7 GB) verschlüsselte tar-Archive sind hochgeladen. Geplant ist, daß das BAK dort einfach liegt und auf einen Bedarfsfall wartet. Ungefähr alle drei Monate könnte das BAK (teilweise) aktualisiert werden. Zu aktueller Zeit (Sept) wollte ich mal teilweise neu hochladen. Das funktionierte jedoch _diesmal_ nachhaltig nicht !!! Ich analysierte zwei Tage lang gründlich und fand heraus, daß beim Hochladen nach jeweils 20 bis 30 Minuten die Verbindungen absichtlich aus zeitlichen Gründen gekappt wurden! Gekappt wurde nach 47..86% der vollen Datenmenge. Diese jeweils zerbrochene Pipe hatte die Dateien am Zielort zerstört. Folglich habe ich eine Umgehung dieses Problems entwickelt. Nämlich ein Skript 'fsplit.bish', das eine Datei automatisch in mehrere kleinere Dateien zerlegt. Und ein Skript 'fcat.bish', das automatisch mehrere Teil-Dateien wieder zusammenführt. http://www.schellong.de/htm/fsplit.bish.html http://www.schellong.de/htm/fcat.bish.html Test-Ausgaben: ========================================================================================================= bish fsplit.bish /big/bak/u.tar.ehu 7600000001 |/big/bak|u.tar.ehu| |u|.tar.ehu| catv 0,2000000000,3 =4 4>/big/bak/u1.tar.ehu catv 2000000000,2000000000,3 =4 4>/big/bak/u2.tar.ehu catv 4000000000,1800000001,3 =4 4>/big/bak/u3.tar.ehu catv 5800000001,1800000000,3 =4 4>/big/bak/u4.tar.ehu Trockentest bish fsplit.bish J:/scan/scanf1.jpg 300000 |J:/scan|scanf1.jpg| |scanf1|.jpg| catv 0,300000,3 =4 4>J:/scan/scanf1#1.jpg fin=0 catv 300000,300000,3 =4 4>J:/scan/scanf1#2.jpg fin=0 catv 600000,300000,3 =4 4>J:/scan/scanf1#3.jpg fin=0 catv 900000,300000,3 =4 4>J:/scan/scanf1#4.jpg fin=0 catv 1200000,300000,3 =4 4>J:/scan/scanf1#5.jpg fin=0 catv 1500000,275858,3 =4 4>J:/scan/scanf1#6.jpg fin=1 catv 1775858,275857,3 =4 4>J:/scan/scanf1#7.jpg fin=2 offs=2051715 insz=2051715 bish fsplit.bish "D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1.VOB" 200000000 |D:/BAK/aufnahme1803/DVD VR/VIDEO_TS|VTS_01_1.VOB| |VTS_01_1|.VOB| catv 0,200000000,3 =4 4>D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#1.VOB fin=0 catv 200000000,200000000,3 =4 4>D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#2.VOB fin=0 catv 400000000,200000000,3 =4 4>D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#3.VOB fin=0 catv 600000000,200000000,3 =4 4>D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#4.VOB fin=0 catv 800000000,136838144,3 =4 4>D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#5.VOB fin=1 catv 936838144,136838144,3 =4 4>D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#6.VOB fin=2 offs=1073676288 insz=1073676288 bish fcat.bish "D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#1.VOB" |D:/BAK/aufnahme1803/DVD VR/VIDEO_TS|VTS_01_1#1.VOB| |VTS_01_1#1|.VOB| |D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1_cat.VOB|VTS_01_1| catv 3 =4 3<D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#1.VOB catv 3 =4 3<D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#2.VOB catv 3 =4 3<D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#3.VOB catv 3 =4 3<D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#4.VOB catv 3 =4 3<D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#5.VOB catv 3 =4 3<D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#6.VOB Datei-Test negativ: 'D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#7.VOB' SHA2-256 (D:\BAK\aufnahme1803\DVD VR\VIDEO_TS\VTS_01_1_cat.VOB) = 9d7182f64ed5fae0a84fdf772f292f020bebd155e2bf3839cb5520bf2cd2b6c3 SHA2-256 (D:\BAK\aufnahme1803\DVD VR\VIDEO_TS\VTS_01_1.VOB) = 9d7182f64ed5fae0a84fdf772f292f020bebd155e2bf3839cb5520bf2cd2b6c3 bish fsplit.bish J:/u.tar |J:|u.tar| |u|.tar| catv 0,2000000000,3 =4 4>J:/u1.tar fin=0 catv 2000000000,1802174464,3 =4 4>J:/u2.tar fin=1 bish: G:\tmp\Helmut\bish\fsplit.bish[60]: Fehler bei Systemfunktion: 'lseek()' ========================================================================================================= Die Skripte funktionieren bestens. Ich habe unter _Windows_ einen 32bit-Compiler 'bcc32x.exe' verwendet, der bewirkt, daß manche System-Funktionen bei sehr großen Dateien versagen. Die fehlgeschlagene Ermittlung der Dateigröße konnte ich mittels des Win-Kommandos DIR umgehen. Insgesamt nützt das (Fstat statt fstat) aber nichts, wie oben sichtbar ist (lseek). 2000000000 2000000000 2000000000 1 Ich habe so entwickelt, daß vorstehende Dateigrößen bei Zerlegung nicht vorkommen können. Die Dateigrößen sind fallend. Die Skripte sind automatisch, sicher und robust, durch besonders viel untersuchenden Code. Das Syntax-Highlighting zeigt, daß mit meinen Werkzeugen die Skripte übersichtlich und gut lesbar sind. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam2616@zugschl.us> |
|---|---|
| Date | 2026-09-08 22:34 +0200 |
| Message-ID | <117prg6$5oli$1@news1.tnib.de> |
| In reply to | #369166 |
Helmut Schellong <var@schellong.biz> wrote: >Hallo, ich hatte immer mal wieder von meinem dreistufigen Backup-Konzept geredet. >Ich mußte gerade in den letzten Tagen eine weitere Kategorie hinzufügen. > >Meine dritte Stufe - Backup ins Internet - hatte ich im Juli erfolgreich in Betrieb genommen. >Vier große (je 3..7 GB) verschlüsselte tar-Archive sind hochgeladen. >Geplant ist, daß das BAK dort einfach liegt und auf einen Bedarfsfall wartet. >Ungefähr alle drei Monate könnte das BAK (teilweise) aktualisiert werden. > >Zu aktueller Zeit (Sept) wollte ich mal teilweise neu hochladen. >Das funktionierte jedoch _diesmal_ nachhaltig nicht !!! > >Ich analysierte zwei Tage lang gründlich und fand heraus, daß beim Hochladen nach jeweils >20 bis 30 Minuten die Verbindungen absichtlich ... von wem ...? >aus zeitlichen Gründen ... mit welcher Methode ...? >gekappt wurden! >Gekappt wurde nach 47..86% der vollen Datenmenge. >Diese jeweils zerbrochene Pipe hatte die Dateien am Zielort zerstört. Logs or it didn't happen. >Folglich habe ich eine Umgehung dieses Problems entwickelt. >Nämlich ein Skript 'fsplit.bish', das eine Datei automatisch in mehrere kleinere Dateien zerlegt. >Und ein Skript 'fcat.bish', das automatisch mehrere Teil-Dateien wieder zusammenführt. Mach noch fünfzig Iterationen und Du hast sowas wie rsync. 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 | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-09 07:38 +0200 |
| Message-ID | <117qrcu$6vp1$1@solani.org> |
| In reply to | #369171 |
Marc Haber wrote on 08.09.2026 22:34: > Helmut Schellong <var@schellong.biz> wrote: >> Hallo, ich hatte immer mal wieder von meinem dreistufigen Backup-Konzept geredet. >> Ich mußte gerade in den letzten Tagen eine weitere Kategorie hinzufügen. >> >> Meine dritte Stufe - Backup ins Internet - hatte ich im Juli erfolgreich in Betrieb genommen. >> Vier große (je 3..7 GB) verschlüsselte tar-Archive sind hochgeladen. >> Geplant ist, daß das BAK dort einfach liegt und auf einen Bedarfsfall wartet. >> Ungefähr alle drei Monate könnte das BAK (teilweise) aktualisiert werden. >> >> Zu aktueller Zeit (Sept) wollte ich mal teilweise neu hochladen. >> Das funktionierte jedoch _diesmal_ nachhaltig nicht !!! >> >> Ich analysierte zwei Tage lang gründlich und fand heraus, daß beim Hochladen nach jeweils >> 20 bis 30 Minuten die Verbindungen absichtlich > > ... von wem ...? > >> aus zeitlichen Gründen > > ... mit welcher Methode ...? Ich verwendete unter FreeBSD die Kommandos 'sftp' und 'scp' (scp -pC). Mit scp kam ich jeweils etwas weiter als mit sftp, wegen Komprimierung. Meine Kommandos meldeten stets, daß die Übertragung durch den remote host abgebrochen wurde - broken pipe. 'scp -pC -i /home/.ssh/id_ecdsa \!:1 u1234567@home7654321.1and1-data.host:\!:2' Ich versuchte an den beiden Testtagen mindestens 6 Uploads, die alle abgebrochen wurden. Die Geschwindigkeit betrug 2..3 MB/s. Tage später lag 5,1 MB/s vor, und der Upload von >7 GB gelang ohne Abbruch in etwa 13 Minuten. Meine Testergebnisse sind halt eindeutig. >> gekappt wurden! >> Gekappt wurde nach 47..86% der vollen Datenmenge. >> Diese jeweils zerbrochene Pipe hatte die Dateien am Zielort zerstört. > > Logs or it didn't happen. Im Zielverzeichnis liegen die Zieldateien nun mit zu geringer Abbruch-Size. Sie werden zu Beginn des Uploads truncated... >> Folglich habe ich eine Umgehung dieses Problems entwickelt. >> Nämlich ein Skript 'fsplit.bish', das eine Datei automatisch in mehrere kleinere Dateien zerlegt. >> Und ein Skript 'fcat.bish', das automatisch mehrere Teil-Dateien wieder zusammenführt. > > Mach noch fünfzig Iterationen und Du hast sowas wie rsync. rsync verwende ich bei meinen ersten Backup-Methoden HDD und CARD in offenen Dateisystemen. 'rsync -aHAXivh --stats --progress --modify-window=5 --exclude-from=/u/sh/cmd/safe_excl' -- Mit freundlichen Grüßen Helmut Schellong var@schellong.biz http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam2616@zugschl.us> |
|---|---|
| Date | 2026-09-09 13:17 +0200 |
| Message-ID | <117rf8s$8ivn$1@news1.tnib.de> |
| In reply to | #369173 |
Helmut Schellong <var@schellong.biz> wrote: >Marc Haber wrote on 08.09.2026 22:34: >> Helmut Schellong <var@schellong.biz> wrote: >>> Hallo, ich hatte immer mal wieder von meinem dreistufigen Backup-Konzept geredet. >>> Ich mußte gerade in den letzten Tagen eine weitere Kategorie hinzufügen. >>> >>> Meine dritte Stufe - Backup ins Internet - hatte ich im Juli erfolgreich in Betrieb genommen. >>> Vier große (je 3..7 GB) verschlüsselte tar-Archive sind hochgeladen. >>> Geplant ist, daß das BAK dort einfach liegt und auf einen Bedarfsfall wartet. >>> Ungefähr alle drei Monate könnte das BAK (teilweise) aktualisiert werden. >>> >>> Zu aktueller Zeit (Sept) wollte ich mal teilweise neu hochladen. >>> Das funktionierte jedoch _diesmal_ nachhaltig nicht !!! >>> >>> Ich analysierte zwei Tage lang gründlich und fand heraus, daß beim Hochladen nach jeweils >>> 20 bis 30 Minuten die Verbindungen absichtlich >> >> ... von wem ...? >> >>> aus zeitlichen Gründen >> >> ... mit welcher Methode ...? > >Ich verwendete unter FreeBSD die Kommandos 'sftp' und 'scp' (scp -pC). >Mit scp kam ich jeweils etwas weiter als mit sftp, wegen Komprimierung. >Meine Kommandos meldeten stets, daß die Übertragung durch den remote host >abgebrochen wurde - broken pipe. >'scp -pC -i /home/.ssh/id_ecdsa \!:1 u1234567@home7654321.1and1-data.host:\!:2' > >Ich versuchte an den beiden Testtagen mindestens 6 Uploads, die alle abgebrochen wurden. >Die Geschwindigkeit betrug 2..3 MB/s. >Tage später lag 5,1 MB/s vor, und der Upload von >7 GB gelang ohne Abbruch in etwa 13 Minuten. >Meine Testergebnisse sind halt eindeutig. Logs or it didnt happen. >>> gekappt wurden! >>> Gekappt wurde nach 47..86% der vollen Datenmenge. >>> Diese jeweils zerbrochene Pipe hatte die Dateien am Zielort zerstört. >> >> Logs or it didn't happen. > >Im Zielverzeichnis liegen die Zieldateien nun mit zu geringer Abbruch-Size. >Sie werden zu Beginn des Uploads truncated... Ich möchte sehen was die Applikation auf der Konsole gesagt hat, was sie in ihre Logs geschrieben hat, und was gleichzeitig auf dem Netz los war. Du hast ja nichtmal gesagt, wo das Ziel der Kopieraktion ist, ob Firewall, Middlebox oder Zwangstrennung im Spiel ist, etc. So debuggen Zehnjährige. >>> Folglich habe ich eine Umgehung dieses Problems entwickelt. >>> Nämlich ein Skript 'fsplit.bish', das eine Datei automatisch in mehrere kleinere Dateien zerlegt. >>> Und ein Skript 'fcat.bish', das automatisch mehrere Teil-Dateien wieder zusammenführt. >> >> Mach noch fünfzig Iterationen und Du hast sowas wie rsync. > >rsync verwende ich bei meinen ersten Backup-Methoden HDD und CARD in offenen Dateisystemen. >'rsync -aHAXivh --stats --progress --modify-window=5 --exclude-from=/u/sh/cmd/safe_excl' Ja und warum nicht hier? -- ---------------------------------------------------------------------------- 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 | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-09 16:22 +0200 |
| Message-ID | <117rq31$7igm$1@solani.org> |
| In reply to | #369182 |
Marc Haber wrote on 09.09.2026 13:17: > Helmut Schellong <var@schellong.biz> wrote: >> Marc Haber wrote on 08.09.2026 22:34: >>> Helmut Schellong <var@schellong.biz> wrote: >>>> Hallo, ich hatte immer mal wieder von meinem dreistufigen Backup-Konzept geredet. >>>> Ich mußte gerade in den letzten Tagen eine weitere Kategorie hinzufügen. >>>> >>>> Meine dritte Stufe - Backup ins Internet - hatte ich im Juli erfolgreich in Betrieb genommen. >>>> Vier große (je 3..7 GB) verschlüsselte tar-Archive sind hochgeladen. >>>> Geplant ist, daß das BAK dort einfach liegt und auf einen Bedarfsfall wartet. >>>> Ungefähr alle drei Monate könnte das BAK (teilweise) aktualisiert werden. >>>> >>>> Zu aktueller Zeit (Sept) wollte ich mal teilweise neu hochladen. >>>> Das funktionierte jedoch _diesmal_ nachhaltig nicht !!! >>>> >>>> Ich analysierte zwei Tage lang gründlich und fand heraus, daß beim Hochladen nach jeweils >>>> 20 bis 30 Minuten die Verbindungen absichtlich >>> >>> ... von wem ...? >>> >>>> aus zeitlichen Gründen >>> >>> ... mit welcher Methode ...? >> >> Ich verwendete unter FreeBSD die Kommandos 'sftp' und 'scp' (scp -pC). >> Mit scp kam ich jeweils etwas weiter als mit sftp, wegen Komprimierung. >> Meine Kommandos meldeten stets, daß die Übertragung durch den remote host >> abgebrochen wurde - broken pipe. >> 'scp -pC -i /home/.ssh/id_ecdsa \!:1 u1234567@home7654321.1and1-data.host:\!:2' >> >> Ich versuchte an den beiden Testtagen mindestens 6 Uploads, die alle abgebrochen wurden. >> Die Geschwindigkeit betrug 2..3 MB/s. >> Tage später lag 5,1 MB/s vor, und der Upload von >7 GB gelang ohne Abbruch in etwa 13 Minuten. >> Meine Testergebnisse sind halt eindeutig. > > Logs or it didnt happen. Ich habe auf der Wurzel meines Webspace ein Verzeichnis /log. Daraus veröffentliche ich - nach Aufarbeitung - aber nichts. >>>> gekappt wurden! >>>> Gekappt wurde nach 47..86% der vollen Datenmenge. >>>> Diese jeweils zerbrochene Pipe hatte die Dateien am Zielort zerstört. >>> >>> Logs or it didn't happen. >> >> Im Zielverzeichnis liegen die Zieldateien nun mit zu geringer Abbruch-Size. >> Sie werden zu Beginn des Uploads truncated... > > Ich möchte sehen was die Applikation auf der Konsole gesagt hat, was > sie in ihre Logs geschrieben hat, und was gleichzeitig auf dem Netz > los war. > > Du hast ja nichtmal gesagt, wo das Ziel der Kopieraktion ist, ob > Firewall, Middlebox oder Zwangstrennung im Spiel ist, etc. > > So debuggen Zehnjährige. Ich habe kein Debugging betrieben, sondern die Fehlerausgaben zum Bildschirm allein reichen mir meistens voll aus. Wenn da mein Kommando meldet, die Verbindung sei vom remote Host unterbrochen worden, und ich sehe wieder das Prompt meiner aufrufenden Shell, nach der Progress-Anzeige, so reicht mir das völlig - es ist eindeutig, weitere Daten brauche ich nicht. Ich mache mir doch keine _unnötige_ zusätzliche Arbeit! Ich bin ein Profi mit großer Erfahrung. Genau deshalb komme ich ohne Zusatzarbeit aus. Ich hatte schon seit 2002 bei meinem letzten Arbeitgeber 'rsync ... user@server' remote (im Home-Arbeitszimmer) intensiv verwendet. Viele Kommunikations-Aliase für die 'csh' habe ich damals beruflich angelegt. Ich hatte hierzu beim ersten Mißerfolg nach wenigen Sekunden erkannt, daß die beiden Skripte, die ich nun entwickelt habe, unbedingt notwendig sein werden. Und genau dies bestimmte ausschließlich meinen weiteren Weg in dieser Angelegenheit! Ich werde große BAK-Dateien nur noch in gesplitteter Form erfolgreich hochladen. Die Notwendigkeit eines Downloads ist ja äußerst unwahrscheinlich. >>>> Folglich habe ich eine Umgehung dieses Problems entwickelt. >>>> Nämlich ein Skript 'fsplit.bish', das eine Datei automatisch in mehrere kleinere Dateien zerlegt. >>>> Und ein Skript 'fcat.bish', das automatisch mehrere Teil-Dateien wieder zusammenführt. >>> >>> Mach noch fünfzig Iterationen und Du hast sowas wie rsync. >> >> rsync verwende ich bei meinen ersten Backup-Methoden HDD und CARD in offenen Dateisystemen. >> 'rsync -aHAXivh --stats --progress --modify-window=5 --exclude-from=/u/sh/cmd/safe_excl' > > Ja und warum nicht hier? Das wäre mir nicht professionell genug - und unangenehm! Ich will jeden Schritt voll in meiner bestimmenden Hand und auf meiner Workstation haben. Der abschließende Schritt des _bloßen_ Transports liegt dann eben nicht mehr voll in meiner Hand. Diesen Schritt kann ich aber _beliebig_ ausgestaltet wiederholen. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Stefan Wiens <s.wi@gmx.net> |
|---|---|
| Date | 2026-09-09 16:48 +0200 |
| Message-ID | <87wlsu1nzu.fsf@s-bot.de> |
| In reply to | #369188 |
Helmut Schellong <var@schellong.biz> writes: > Marc Haber wrote on 09.09.2026 13:17: >> Helmut Schellong <var@schellong.biz> wrote: >>> Marc Haber wrote on 08.09.2026 22:34: >>>> Helmut Schellong <var@schellong.biz> wrote: >>>>> Hallo, ich hatte immer mal wieder von meinem dreistufigen Backup-Konzept geredet. >>>>> Ich mußte gerade in den letzten Tagen eine weitere Kategorie hinzufügen. >>>>> >>>>> Meine dritte Stufe - Backup ins Internet - hatte ich im Juli erfolgreich in Betrieb genommen. >>>>> Vier große (je 3..7 GB) verschlüsselte tar-Archive sind hochgeladen. >>>>> Geplant ist, daß das BAK dort einfach liegt und auf einen Bedarfsfall wartet. >>>>> Ungefähr alle drei Monate könnte das BAK (teilweise) aktualisiert werden. >>>>> >>>>> Zu aktueller Zeit (Sept) wollte ich mal teilweise neu hochladen. >>>>> Das funktionierte jedoch _diesmal_ nachhaltig nicht !!! >>>>> >>>>> Ich analysierte zwei Tage lang gründlich und fand heraus, daß beim Hochladen nach jeweils >>>>> 20 bis 30 Minuten die Verbindungen absichtlich >>>> >>>> ... von wem ...? >>>> >>>>> aus zeitlichen Gründen >>>> >>>> ... mit welcher Methode ...? >>> >>> Ich verwendete unter FreeBSD die Kommandos 'sftp' und 'scp' (scp -pC). >>> Mit scp kam ich jeweils etwas weiter als mit sftp, wegen Komprimierung. >>> Meine Kommandos meldeten stets, daß die Übertragung durch den remote host >>> abgebrochen wurde - broken pipe. >>> 'scp -pC -i /home/.ssh/id_ecdsa \!:1 u1234567@home7654321.1and1-data.host:\!:2' >>> >>> Ich versuchte an den beiden Testtagen mindestens 6 Uploads, die alle abgebrochen wurden. >>> Die Geschwindigkeit betrug 2..3 MB/s. >>> Tage später lag 5,1 MB/s vor, und der Upload von >7 GB gelang ohne Abbruch in etwa 13 Minuten. >>> Meine Testergebnisse sind halt eindeutig. >> Logs or it didnt happen. > > Ich habe auf der Wurzel meines Webspace ein Verzeichnis /log. > Daraus veröffentliche ich - nach Aufarbeitung - aber nichts. > >>>>> gekappt wurden! >>>>> Gekappt wurde nach 47..86% der vollen Datenmenge. >>>>> Diese jeweils zerbrochene Pipe hatte die Dateien am Zielort zerstört. >>>> >>>> Logs or it didn't happen. >>> >>> Im Zielverzeichnis liegen die Zieldateien nun mit zu geringer Abbruch-Size. >>> Sie werden zu Beginn des Uploads truncated... >> Ich möchte sehen was die Applikation auf der Konsole gesagt hat, was >> sie in ihre Logs geschrieben hat, und was gleichzeitig auf dem Netz >> los war. >> Du hast ja nichtmal gesagt, wo das Ziel der Kopieraktion ist, ob >> Firewall, Middlebox oder Zwangstrennung im Spiel ist, etc. >> So debuggen Zehnjährige. > > Ich habe kein Debugging betrieben, sondern die Fehlerausgaben zum Bildschirm allein > reichen mir meistens voll aus. > > Wenn da mein Kommando meldet, die Verbindung sei vom remote Host unterbrochen worden, > und ich sehe wieder das Prompt meiner aufrufenden Shell, nach der Progress-Anzeige, > so reicht mir das völlig - es ist eindeutig, weitere Daten brauche ich nicht. > Ich mache mir doch keine _unnötige_ zusätzliche Arbeit! > > Ich bin ein Profi mit großer Erfahrung. > Genau deshalb komme ich ohne Zusatzarbeit aus. [...] Als Aechter Profi verzichtest du sicherlich auf screen(1)? -- Stefan
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-09 17:00 +0200 |
| Message-ID | <117rsa5$7k8h$1@solani.org> |
| In reply to | #369189 |
Stefan Wiens wrote on 09.09.2026 16:48: > Helmut Schellong <var@schellong.biz> writes: > >> Marc Haber wrote on 09.09.2026 13:17: >>> Helmut Schellong <var@schellong.biz> wrote: >>>> Marc Haber wrote on 08.09.2026 22:34: >>>>> Helmut Schellong <var@schellong.biz> wrote: >>>>>> Hallo, ich hatte immer mal wieder von meinem dreistufigen Backup-Konzept geredet. >>>>>> Ich mußte gerade in den letzten Tagen eine weitere Kategorie hinzufügen. >>>>>>[...] >>> So debuggen Zehnjährige. >> >> Ich habe kein Debugging betrieben, sondern die Fehlerausgaben zum Bildschirm allein >> reichen mir meistens voll aus. >> >> Wenn da mein Kommando meldet, die Verbindung sei vom remote Host unterbrochen worden, >> und ich sehe wieder das Prompt meiner aufrufenden Shell, nach der Progress-Anzeige, >> so reicht mir das völlig - es ist eindeutig, weitere Daten brauche ich nicht. >> Ich mache mir doch keine _unnötige_ zusätzliche Arbeit! >> >> Ich bin ein Profi mit großer Erfahrung. >> Genau deshalb komme ich ohne Zusatzarbeit aus. > [...] > > Als Aechter Profi verzichtest du sicherlich auf screen(1)? Früher nicht, aber seit neuerer Zeit. Das ist ein Thema, das unterschiedlich zwischen verschiedenen OS ist. Selbst die man-Kategorie als Nummer gibt es nicht auf allen Systemen. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Alexander Schreiber <als@usenet.thangorodrim.de> |
|---|---|
| Date | 2026-09-09 22:22 +0200 |
| Message-ID | <slrn11a3g0o.28ctg.als@mordor.angband.thangorodrim.de> |
| In reply to | #369191 |
Helmut Schellong <var@schellong.biz> wrote:
> Stefan Wiens wrote on 09.09.2026 16:48:
>> Helmut Schellong <var@schellong.biz> writes:
>>
>>> Marc Haber wrote on 09.09.2026 13:17:
>>>> Helmut Schellong <var@schellong.biz> wrote:
>>>>> Marc Haber wrote on 08.09.2026 22:34:
>>>>>> Helmut Schellong <var@schellong.biz> wrote:
>>>>>>> Hallo, ich hatte immer mal wieder von meinem dreistufigen Backup-Konzept geredet.
>>>>>>> Ich mußte gerade in den letzten Tagen eine weitere Kategorie hinzufügen.
>>>>>>>[...]
>
>>>> So debuggen Zehnjährige.
>>>
>>> Ich habe kein Debugging betrieben, sondern die Fehlerausgaben zum Bildschirm allein
>>> reichen mir meistens voll aus.
>>>
>>> Wenn da mein Kommando meldet, die Verbindung sei vom remote Host unterbrochen worden,
>>> und ich sehe wieder das Prompt meiner aufrufenden Shell, nach der Progress-Anzeige,
>>> so reicht mir das völlig - es ist eindeutig, weitere Daten brauche ich nicht.
>>> Ich mache mir doch keine _unnötige_ zusätzliche Arbeit!
>>>
>>> Ich bin ein Profi mit großer Erfahrung.
>>> Genau deshalb komme ich ohne Zusatzarbeit aus.
>> [...]
>>
>> Als Aechter Profi verzichtest du sicherlich auf screen(1)?
>
> Früher nicht, aber seit neuerer Zeit.
> Das ist ein Thema, das unterschiedlich zwischen verschiedenen OS ist.
> Selbst die man-Kategorie als Nummer gibt es nicht auf allen Systemen.
Ja, manche Systeme sind kaputter als andere, da hast Du durchaus recht.
SCNR,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
[toc] | [prev] | [next] | [standalone]
| From | Stefan Wiens <s.wi@gmx.net> |
|---|---|
| Date | 2026-09-10 07:52 +0200 |
| Message-ID | <874ifx1wsm.fsf@s-bot.de> |
| In reply to | #369212 |
Alexander Schreiber <als@usenet.thangorodrim.de> writes: > Helmut Schellong <var@schellong.biz> wrote: >> Stefan Wiens wrote on 09.09.2026 16:48: >>> Helmut Schellong <var@schellong.biz> writes: >>> >>>> Marc Haber wrote on 09.09.2026 13:17: >>>>> Helmut Schellong <var@schellong.biz> wrote: >>>>>> Marc Haber wrote on 08.09.2026 22:34: >>>>>>> Helmut Schellong <var@schellong.biz> wrote: >>>>>>>> Hallo, ich hatte immer mal wieder von meinem dreistufigen Backup-Konzept geredet. >>>>>>>> Ich mußte gerade in den letzten Tagen eine weitere Kategorie hinzufügen. >>>>>>>>[...] >> >>>>> So debuggen Zehnjährige. >>>> >>>> Ich habe kein Debugging betrieben, sondern die Fehlerausgaben zum Bildschirm allein >>>> reichen mir meistens voll aus. >>>> >>>> Wenn da mein Kommando meldet, die Verbindung sei vom remote Host unterbrochen worden, >>>> und ich sehe wieder das Prompt meiner aufrufenden Shell, nach der Progress-Anzeige, >>>> so reicht mir das völlig - es ist eindeutig, weitere Daten brauche ich nicht. >>>> Ich mache mir doch keine _unnötige_ zusätzliche Arbeit! >>>> >>>> Ich bin ein Profi mit großer Erfahrung. >>>> Genau deshalb komme ich ohne Zusatzarbeit aus. >>> [...] >>> >>> Als Aechter Profi verzichtest du sicherlich auf screen(1)? >> >> Früher nicht, aber seit neuerer Zeit. >> Das ist ein Thema, das unterschiedlich zwischen verschiedenen OS ist. >> Selbst die man-Kategorie als Nummer gibt es nicht auf allen Systemen. > > Ja, manche Systeme sind kaputter als andere, da hast Du durchaus recht. Ich habe auch Richtung Tanzfläche geschossen, aber irgendwann muss gut sein. "Communication reset by foreign host" ist keine sinnvolle Fehlermeldung, da könnte auch der DSL-Router eine neue IP-Adresse bekommen haben. Aber anscheinend sind auch noch intransparente Verschlüsselungen im Einsatz, die nicht einmal die Dateigröße erhalten. -- Stefan
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-10 14:03 +0200 |
| Message-ID | <117u69j$sg8$1@solani.org> |
| In reply to | #369226 |
Stefan Wiens wrote on 10.09.2026 07:52: > Alexander Schreiber <als@usenet.thangorodrim.de> writes: > >> Helmut Schellong <var@schellong.biz> wrote: >>> Stefan Wiens wrote on 09.09.2026 16:48: >>>> Helmut Schellong <var@schellong.biz> writes: >>>> >>>>> Marc Haber wrote on 09.09.2026 13:17: >>>>>> Helmut Schellong <var@schellong.biz> wrote: >>>>>>> Marc Haber wrote on 08.09.2026 22:34: >>>>>>>> Helmut Schellong <var@schellong.biz> wrote: >>>>>>>>> Hallo, ich hatte immer mal wieder von meinem dreistufigen Backup-Konzept geredet. >>>>>>>>> Ich mußte gerade in den letzten Tagen eine weitere Kategorie hinzufügen. >>>>>>>>> [...] >>> >>>>>> So debuggen Zehnjährige. >>>>> >>>>> Ich habe kein Debugging betrieben, sondern die Fehlerausgaben zum Bildschirm allein >>>>> reichen mir meistens voll aus. >>>>> >>>>> Wenn da mein Kommando meldet, die Verbindung sei vom remote Host unterbrochen worden, >>>>> und ich sehe wieder das Prompt meiner aufrufenden Shell, nach der Progress-Anzeige, >>>>> so reicht mir das völlig - es ist eindeutig, weitere Daten brauche ich nicht. >>>>> Ich mache mir doch keine _unnötige_ zusätzliche Arbeit! >>>>> >>>>> Ich bin ein Profi mit großer Erfahrung. >>>>> Genau deshalb komme ich ohne Zusatzarbeit aus. >>>> [...] >>>> >>>> Als Aechter Profi verzichtest du sicherlich auf screen(1)? >>> >>> Früher nicht, aber seit neuerer Zeit. >>> Das ist ein Thema, das unterschiedlich zwischen verschiedenen OS ist. >>> Selbst die man-Kategorie als Nummer gibt es nicht auf allen Systemen. >> >> Ja, manche Systeme sind kaputter als andere, da hast Du durchaus recht. > > Ich habe auch Richtung Tanzfläche geschossen, > aber irgendwann muss gut sein. > > "Communication reset by foreign host" ist > keine sinnvolle Fehlermeldung, da könnte > auch der DSL-Router eine neue IP-Adresse > bekommen haben. Aber anscheinend sind > auch noch intransparente Verschlüsselungen > im Einsatz, die nicht einmal die Dateigröße > erhalten. Das geschieht _absichtlich_ durch die Verschlüsselung einer tar-Datei durch _einen_ meiner Algorithmen. Der sich anschließende Transportmechanismus zum Provider merkt nichts davon. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Stefan Wiens <s.wi@gmx.net> |
|---|---|
| Date | 2026-09-10 16:47 +0200 |
| Message-ID | <87h5jxyxno.fsf@s-bot.de> |
| In reply to | #369239 |
Helmut Schellong <var@schellong.biz> writes: > Stefan Wiens wrote on 10.09.2026 07:52: >> Alexander Schreiber <als@usenet.thangorodrim.de> writes: >> >>> Helmut Schellong <var@schellong.biz> wrote: >>>> Stefan Wiens wrote on 09.09.2026 16:48: >>>>> Helmut Schellong <var@schellong.biz> writes: >>>>> >>>>>> Marc Haber wrote on 09.09.2026 13:17: >>>>>>> Helmut Schellong <var@schellong.biz> wrote: >>>>>>>> Marc Haber wrote on 08.09.2026 22:34: >>>>>>>>> Helmut Schellong <var@schellong.biz> wrote: >>>>>>>>>> Hallo, ich hatte immer mal wieder von meinem dreistufigen Backup-Konzept geredet. >>>>>>>>>> Ich mußte gerade in den letzten Tagen eine weitere Kategorie hinzufügen. >>>>>>>>>> [...] >>>> >>>>>>> So debuggen Zehnjährige. >>>>>> >>>>>> Ich habe kein Debugging betrieben, sondern die Fehlerausgaben zum Bildschirm allein >>>>>> reichen mir meistens voll aus. >>>>>> >>>>>> Wenn da mein Kommando meldet, die Verbindung sei vom remote Host unterbrochen worden, >>>>>> und ich sehe wieder das Prompt meiner aufrufenden Shell, nach der Progress-Anzeige, >>>>>> so reicht mir das völlig - es ist eindeutig, weitere Daten brauche ich nicht. >>>>>> Ich mache mir doch keine _unnötige_ zusätzliche Arbeit! >>>>>> >>>>>> Ich bin ein Profi mit großer Erfahrung. >>>>>> Genau deshalb komme ich ohne Zusatzarbeit aus. >>>>> [...] >>>>> >>>>> Als Aechter Profi verzichtest du sicherlich auf screen(1)? >>>> >>>> Früher nicht, aber seit neuerer Zeit. >>>> Das ist ein Thema, das unterschiedlich zwischen verschiedenen OS ist. >>>> Selbst die man-Kategorie als Nummer gibt es nicht auf allen Systemen. >>> >>> Ja, manche Systeme sind kaputter als andere, da hast Du durchaus recht. >> Ich habe auch Richtung Tanzfläche geschossen, >> aber irgendwann muss gut sein. >> "Communication reset by foreign host" ist >> keine sinnvolle Fehlermeldung, da könnte >> auch der DSL-Router eine neue IP-Adresse >> bekommen haben. Aber anscheinend sind >> auch noch intransparente Verschlüsselungen >> im Einsatz, die nicht einmal die Dateigröße >> erhalten. > > Das geschieht _absichtlich_ durch die Verschlüsselung einer tar-Datei > durch _einen_ meiner Algorithmen. > Der sich anschließende Transportmechanismus zum Provider merkt nichts davon. Für deine Aufgabe, eine Datei in transportgerechte Schnipsel zu zerteilen, gibt es das Tool split (1) - split a file into pieces Das hättest du also nicht selbst programmieren müssen. -- Stefan
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-10 18:12 +0200 |
| Message-ID | <117uksd$18bi$1@solani.org> |
| In reply to | #369250 |
Stefan Wiens wrote on 10.09.2026 16:47: > Helmut Schellong <var@schellong.biz> writes: > >> Stefan Wiens wrote on 10.09.2026 07:52: >>> Alexander Schreiber <als@usenet.thangorodrim.de> writes: >>> >>>> Helmut Schellong <var@schellong.biz> wrote: >>>>> Stefan Wiens wrote on 09.09.2026 16:48: >>>>>> Helmut Schellong <var@schellong.biz> writes: >>>>>> >>>>>>> Marc Haber wrote on 09.09.2026 13:17: >>>>>>>> Helmut Schellong <var@schellong.biz> wrote: >>>>>>>>> Marc Haber wrote on 08.09.2026 22:34: >>>>>>>>>> Helmut Schellong <var@schellong.biz> wrote: >>>>>>>>>>> Hallo, ich hatte immer mal wieder von meinem dreistufigen Backup-Konzept geredet. [...] >>> Ich habe auch Richtung Tanzfläche geschossen, >>> aber irgendwann muss gut sein. >>> "Communication reset by foreign host" ist >>> keine sinnvolle Fehlermeldung, da könnte >>> auch der DSL-Router eine neue IP-Adresse >>> bekommen haben. Aber anscheinend sind >>> auch noch intransparente Verschlüsselungen >>> im Einsatz, die nicht einmal die Dateigröße >>> erhalten. >> >> Das geschieht _absichtlich_ durch die Verschlüsselung einer tar-Datei >> durch _einen_ meiner Algorithmen. >> Der sich anschließende Transportmechanismus zum Provider merkt nichts davon. > > Für deine Aufgabe, eine Datei in > transportgerechte Schnipsel zu > zerteilen, gibt es das Tool > > split (1) - split a file into pieces > > Das hättest du also nicht selbst programmieren > müssen. Doch. http://osr507doc.xinuos.com/cgi-bin/man?mansearchword=/usr/gnu/man2/cat.1/split.1.Z&mansection= Das Kommando ist offenbar Zeilen-basiert. Alle Eigenschaften, die ich wünsche, sind nicht vorhanden. fattmp.tar.ehu fattmp1.tar.ehu fattmp2.tar.ehu fattmp3.tar.ehu fattmp6.tar.ehu fattmp6#1.tar.ehu fattmp6#2.tar.ehu fattmp6#3.tar.ehu Mein Konzept ist vorstehend sichtbar. Das macht split nicht so. Nachfolgend ist sichtbar, daß meine Lösung eine ganz andere Hausnummer ist. ================================================================================================ bish fsplit.bish "D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1.VOB" 200000000 |D:/BAK/aufnahme1803/DVD VR/VIDEO_TS|VTS_01_1.VOB| |VTS_01_1|.VOB| catv 0,200000000,3 =4 4>D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#1.VOB fin=0 catv 200000000,200000000,3 =4 4>D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#2.VOB fin=0 catv 400000000,200000000,3 =4 4>D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#3.VOB fin=0 catv 600000000,200000000,3 =4 4>D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#4.VOB fin=0 catv 800000000,136838144,3 =4 4>D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#5.VOB fin=1 catv 936838144,136838144,3 =4 4>D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#6.VOB fin=2 offs=1073676288 insz=1073676288 bish fcat.bish "D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#1.VOB" |D:/BAK/aufnahme1803/DVD VR/VIDEO_TS|VTS_01_1#1.VOB| |VTS_01_1#1|.VOB| |D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1_cat.VOB|VTS_01_1| catv 3 =4 3<D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#1.VOB catv 3 =4 3<D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#2.VOB catv 3 =4 3<D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#3.VOB catv 3 =4 3<D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#4.VOB catv 3 =4 3<D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#5.VOB catv 3 =4 3<D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#6.VOB Datei-Test negativ: 'D:/BAK/aufnahme1803/DVD VR/VIDEO_TS/VTS_01_1#7.VOB' SHA2-256 (D:\BAK\aufnahme1803\DVD VR\VIDEO_TS\VTS_01_1_cat.VOB) = 9d7182f64ed5fae0a84fdf772f292f020bebd155e2bf3839cb5520bf2cd2b6c3 SHA2-256 (D:\BAK\aufnahme1803\DVD VR\VIDEO_TS\VTS_01_1.VOB) = 9d7182f64ed5fae0a84fdf772f292f020bebd155e2bf3839cb5520bf2cd2b6c3 -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam2616@zugschl.us> |
|---|---|
| Date | 2026-09-09 17:20 +0200 |
| Message-ID | <117rtf4$9b5p$1@news1.tnib.de> |
| In reply to | #369188 |
Helmut Schellong <var@schellong.biz> wrote: >Ich habe kein Debugging betrieben, sondern die Fehlerausgaben zum Bildschirm allein >reichen mir meistens voll aus. > >Wenn da mein Kommando meldet, die Verbindung sei vom remote Host unterbrochen worden, >und ich sehe wieder das Prompt meiner aufrufenden Shell, nach der Progress-Anzeige, >so reicht mir das völlig - es ist eindeutig, weitere Daten brauche ich nicht. >Ich mache mir doch keine _unnötige_ zusätzliche Arbeit! > >Ich bin ein Profi mit großer Erfahrung. >Genau deshalb komme ich ohne Zusatzarbeit aus. Wie man aus diesem Thread zweifelsfrei sieht, hast Du keine Ahnug was da wirklich passiert und warum es passieren könntest und hast deswegen wie ein erfahrungsloser Teenager einfach etwas ausprobiert. Das ist das Gegenteil von "Profi". >Ich hatte schon seit 2002 bei meinem letzten Arbeitgeber 'rsync ... user@server' >remote (im Home-Arbeitszimmer) intensiv verwendet. Und warum tust Du es jetzt nicht, wenn Du schon nicht herausfinden möchtest, warum scp/sftp abbricht? Mit rsync könntest Du nach so einem Abbruch wenigstens nahtlos weiter übertragen. >Viele Kommunikations-Aliase für die 'csh' habe ich damals beruflich angelegt. Gosh! Raketenwissenschaft! Wo hast Du das denn gelernt? -- ---------------------------------------------------------------------------- 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 | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-09 18:20 +0200 |
| Message-ID | <117s10c$7o02$1@solani.org> |
| In reply to | #369192 |
Marc Haber wrote on 09.09.2026 17:20: > Helmut Schellong <var@schellong.biz> wrote: >> Ich habe kein Debugging betrieben, sondern die Fehlerausgaben zum Bildschirm allein >> reichen mir meistens voll aus. >> >> Wenn da mein Kommando meldet, die Verbindung sei vom remote Host unterbrochen worden, >> und ich sehe wieder das Prompt meiner aufrufenden Shell, nach der Progress-Anzeige, >> so reicht mir das völlig - es ist eindeutig, weitere Daten brauche ich nicht. >> Ich mache mir doch keine _unnötige_ zusätzliche Arbeit! >> >> Ich bin ein Profi mit großer Erfahrung. >> Genau deshalb komme ich ohne Zusatzarbeit aus. > > Wie man aus diesem Thread zweifelsfrei sieht, hast Du keine Ahnug was > da wirklich passiert und warum es passieren könntest und hast deswegen > wie ein erfahrungsloser Teenager einfach etwas ausprobiert. > > Das ist das Gegenteil von "Profi". So willst Du mich (krampfhaft) sehen. Du ignorierst jedoch einfach entscheidende Absätze von mir und verdrehst einfach behauptend, damit Dein Ziel erreicht wird. >> Ich hatte schon seit 2002 bei meinem letzten Arbeitgeber 'rsync ... user@server' >> remote (im Home-Arbeitszimmer) intensiv verwendet. > > Und warum tust Du es jetzt nicht, wenn Du schon nicht herausfinden > möchtest, warum scp/sftp abbricht? Mit rsync könntest Du nach so einem > Abbruch wenigstens nahtlos weiter übertragen. 'rsync' wird bei meiner Webseite nicht unterstützt, sondern 'nur' die ssh-Werkzeuge! Ich weiß genau, warum scp/sftp abbrechen, denn ich habe das einige Tage analysiert. Genannt habe den Abbruch-Grund ebenso, was ebenso von Dir ignoriert wird. >> Viele Kommunikations-Aliase für die 'csh' habe ich damals beruflich angelegt. > > Gosh! Raketenwissenschaft! Wo hast Du das denn gelernt? Was soll denn diese blödsinnige Aussage? Ich habe sehr oft verschiedenste Kommunikation mit mehreren Servern meines Arbeitgebers aufnehmen müssen. Deshalb die Aliase, um unnötige Arbeit zu vermeiden. Auf allen diesen Servern lief ein rsync-Dämon. Aussagen wie die vorstehende scheinst Du jedoch nicht zu begreifen zu wollen... -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Alexander Schreiber <als@usenet.thangorodrim.de> |
|---|---|
| Date | 2026-09-09 22:21 +0200 |
| Message-ID | <slrn11a3fu0.28ctg.als@mordor.angband.thangorodrim.de> |
| In reply to | #369201 |
Helmut Schellong <var@schellong.biz> wrote:
> Marc Haber wrote on 09.09.2026 17:20:
>> Helmut Schellong <var@schellong.biz> wrote:
>>> Ich habe kein Debugging betrieben, sondern die Fehlerausgaben zum Bildschirm allein
>>> reichen mir meistens voll aus.
>>>
>>> Wenn da mein Kommando meldet, die Verbindung sei vom remote Host unterbrochen worden,
>>> und ich sehe wieder das Prompt meiner aufrufenden Shell, nach der Progress-Anzeige,
>>> so reicht mir das völlig - es ist eindeutig, weitere Daten brauche ich nicht.
>>> Ich mache mir doch keine _unnötige_ zusätzliche Arbeit!
>>>
>>> Ich bin ein Profi mit großer Erfahrung.
>>> Genau deshalb komme ich ohne Zusatzarbeit aus.
>>
>> Wie man aus diesem Thread zweifelsfrei sieht, hast Du keine Ahnug was
>> da wirklich passiert und warum es passieren könntest und hast deswegen
>> wie ein erfahrungsloser Teenager einfach etwas ausprobiert.
>>
>> Das ist das Gegenteil von "Profi".
>
> So willst Du mich (krampfhaft) sehen.
Och, Marc ist da mit seiner Ansicht alles andere als alleine.
>>> Ich hatte schon seit 2002 bei meinem letzten Arbeitgeber 'rsync ... user@server'
>>> remote (im Home-Arbeitszimmer) intensiv verwendet.
>>
>> Und warum tust Du es jetzt nicht, wenn Du schon nicht herausfinden
>> möchtest, warum scp/sftp abbricht? Mit rsync könntest Du nach so einem
>> Abbruch wenigstens nahtlos weiter übertragen.
>
> 'rsync' wird bei meiner Webseite nicht unterstützt, sondern 'nur' die ssh-Werkzeuge!
Dem ist mit einem rsync-Binary am anderen Ende trivial abhelfbar. Zumal
rsync & ssh sich nicht eben gegenseitig ausschliessen.
> Ich weiß genau, warum scp/sftp abbrechen, denn ich habe das einige Tage analysiert.
> Genannt habe den Abbruch-Grund ebenso, was ebenso von Dir ignoriert wird.
>
>>> Viele Kommunikations-Aliase für die 'csh' habe ich damals beruflich angelegt.
>>
>> Gosh! Raketenwissenschaft! Wo hast Du das denn gelernt?
>
> Was soll denn diese blödsinnige Aussage?
> Ich habe sehr oft verschiedenste Kommunikation mit mehreren Servern meines
> Arbeitgebers aufnehmen müssen.
Doch mehrere Server, wow. Wir sind beeindruckt.
SCNR,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-10 01:28 +0200 |
| Message-ID | <117sq1n$896h$1@solani.org> |
| In reply to | #369214 |
Alexander Schreiber wrote on 09.09.2026 22:21: > Helmut Schellong <var@schellong.biz> wrote: >> Marc Haber wrote on 09.09.2026 17:20: >>> Helmut Schellong <var@schellong.biz> wrote: >>>> Ich habe kein Debugging betrieben, sondern die Fehlerausgaben zum Bildschirm allein >>>> reichen mir meistens voll aus. >>>> >>>> Wenn da mein Kommando meldet, die Verbindung sei vom remote Host unterbrochen worden, >>>> und ich sehe wieder das Prompt meiner aufrufenden Shell, nach der Progress-Anzeige, >>>> so reicht mir das völlig - es ist eindeutig, weitere Daten brauche ich nicht. >>>> Ich mache mir doch keine _unnötige_ zusätzliche Arbeit! >>>> >>>> Ich bin ein Profi mit großer Erfahrung. >>>> Genau deshalb komme ich ohne Zusatzarbeit aus. >>> >>> Wie man aus diesem Thread zweifelsfrei sieht, hast Du keine Ahnug was >>> da wirklich passiert und warum es passieren könntest und hast deswegen >>> wie ein erfahrungsloser Teenager einfach etwas ausprobiert. >>> >>> Das ist das Gegenteil von "Profi". >> >> So willst Du mich (krampfhaft) sehen. > > Och, Marc ist da mit seiner Ansicht alles andere als alleine. Nenne einen Fakt, der diese Einschätzung gerechtfertigt. Es gibt den behauptenden Marc - und seine blinden Mitläufer. >>>> Ich hatte schon seit 2002 bei meinem letzten Arbeitgeber 'rsync ... user@server' >>>> remote (im Home-Arbeitszimmer) intensiv verwendet. >>> >>> Und warum tust Du es jetzt nicht, wenn Du schon nicht herausfinden >>> möchtest, warum scp/sftp abbricht? Mit rsync könntest Du nach so einem >>> Abbruch wenigstens nahtlos weiter übertragen. >> >> 'rsync' wird bei meiner Webseite nicht unterstützt, sondern 'nur' die ssh-Werkzeuge! > > Dem ist mit einem rsync-Binary am anderen Ende trivial abhelfbar. Zumal > rsync & ssh sich nicht eben gegenseitig ausschliessen. Der Provider wird den Betrieb eines user-rsync-Daemons nicht zulassen. Er unterläßt die Werbung dafür nicht ohne Grund. Dann erkläre doch mal, wie der Betrieb mit offenen Verzeichnissen mittels rsync konkret gestaltet werden kann. Und unverschlüsselte Daten von mir dürfen nirgendwo zugreifbar sein. Und es müssen mehrere Verschlüsselungen hintereinander erfolgen, mit von mir ausgewählten Algorithmen. Ich frage mich, wie rsync da die Dateilisten vergleichen will, wenn meine Systeme keine verschlüsselten Dateien haben, am Ziel aber alles permanent verschlüsselt sein muß. Wobei ein Algorithmus von mir die Size ändert. >> Ich weiß genau, warum scp/sftp abbrechen, denn ich habe das einige Tage analysiert. >> Genannt habe den Abbruch-Grund ebenso, was ebenso von Dir ignoriert wird. >> >>>> Viele Kommunikations-Aliase für die 'csh' habe ich damals beruflich angelegt. >>> >>> Gosh! Raketenwissenschaft! Wo hast Du das denn gelernt? >> >> Was soll denn diese blödsinnige Aussage? >> Ich habe sehr oft verschiedenste Kommunikation mit mehreren Servern meines >> Arbeitgebers aufnehmen müssen. > > Doch mehrere Server, wow. Wir sind beeindruckt. Was soll dieses blöde Gelabere? Man muß da nicht beeindruckt sein. Ich war damals allerdings neben einem Entwicklungsingenieur auch ein halber Admin und hatte das Management des Tape-Servers übernommen, wozu ich Skripte schrieb, was dort niemand außer mir konnte. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam2616@zugschl.us> |
|---|---|
| Date | 2026-09-10 07:49 +0200 |
| Message-ID | <117tgcv$c4d7$1@news1.tnib.de> |
| In reply to | #369222 |
Helmut Schellong <var@schellong.biz> wrote: >Nenne einen Fakt, der diese Einschätzung gerechtfertigt. Dein Auftreten hier reicht völlig. >Es gibt den behauptenden Marc - und seine blinden Mitläufer. Oh, das ist aber ein Kompliment, das ich leider nicht annehmen kann. Alexander hat vermutlich fünfmal so viel Erfahrung im Betrieb großer Umgebungen als ich. Ich schätze ihn als einen anspruchsvollen und kompetenten Gesprächspartner. >> Dem ist mit einem rsync-Binary am anderen Ende trivial abhelfbar. Zumal >> rsync & ssh sich nicht eben gegenseitig ausschliessen. > >Der Provider wird den Betrieb eines user-rsync-Daemons nicht zulassen. Von einem rsync-Daemon sprach niemand. >Dann erkläre doch mal, wie der Betrieb mit offenen Verzeichnissen mittels rsync >konkret gestaltet werden kann. Was ist ein offenes Verzeichnis? >Und unverschlüsselte Daten von mir dürfen nirgendwo zugreifbar sein. Warum sind sie unverschlüsselt und warum liegen sie dann auf einem Webspace? >Und es müssen mehrere Verschlüsselungen hintereinander erfolgen, mit von mir >ausgewählten Algorithmen. Warum? Kennst Du eine Schwachstelle in AES256, von der wir noch nicht wissen? Und warum bist Du dann noch hier und nicht im Debriefing bei den Geheimdiensten? Und wie schützt Du die Schlüssel dieser "mehrfachen" Verschlüsselung? >Ich frage mich, wie rsync da die Dateilisten vergleichen will, wenn meine >Systeme keine verschlüsselten Dateien haben, am Ziel aber alles permanent >verschlüsselt sein muß. Wobei ein Algorithmus von mir die Size ändert. Du redest wirr. >>> Ich weiß genau, warum scp/sftp abbrechen, denn ich habe das einige Tage analysiert. >>> Genannt habe den Abbruch-Grund ebenso, was ebenso von Dir ignoriert wird. >>> >>>>> Viele Kommunikations-Aliase für die 'csh' habe ich damals beruflich angelegt. >>>> >>>> Gosh! Raketenwissenschaft! Wo hast Du das denn gelernt? >>> >>> Was soll denn diese blödsinnige Aussage? >>> Ich habe sehr oft verschiedenste Kommunikation mit mehreren Servern meines >>> Arbeitgebers aufnehmen müssen. >> >> Doch mehrere Server, wow. Wir sind beeindruckt. > >Was soll dieses blöde Gelabere? Du hältst Dich für Chuck Norris und brüstest Dich mit Dingen, über die Schüler lachen. >Ich war damals allerdings neben einem Entwicklungsingenieur auch ein halber Admin >und hatte das Management des Tape-Servers übernommen, wozu ich Skripte schrieb, >was dort niemand außer mir konnte. HIER kann das JEDER, und jeder weiß, dass Dein NIH¹ schon fast krankhaft ist. Grüße Marc ¹ Eigene Krypto ist ja schon ein zuverlässiger Deppendetektor, aber sich einen eigenen SHELL zu schreiben ist wirklich ein ganz eigener Level an Hybris. -- ---------------------------------------------------------------------------- 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 | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-10 13:53 +0200 |
| Message-ID | <117u5mn$s1p$1@solani.org> |
| In reply to | #369225 |
Marc Haber wrote on 10.09.2026 07:49: > Helmut Schellong <var@schellong.biz> wrote: >> Nenne einen Fakt, der diese Einschätzung gerechtfertigt. > > Dein Auftreten hier reicht völlig. Das ist wieder eine bloße Behauptung ohne irgendwas Konkretes. >> Es gibt den behauptenden Marc - und seine blinden Mitläufer. > > Oh, das ist aber ein Kompliment, das ich leider nicht annehmen kann. > Alexander hat vermutlich fünfmal so viel Erfahrung im Betrieb großer > Umgebungen als ich. Ich schätze ihn als einen anspruchsvollen und > kompetenten Gesprächspartner. > >>> Dem ist mit einem rsync-Binary am anderen Ende trivial abhelfbar. Zumal >>> rsync & ssh sich nicht eben gegenseitig ausschliessen. >> >> Der Provider wird den Betrieb eines user-rsync-Daemons nicht zulassen. > > Von einem rsync-Daemon sprach niemand. Ich kommunizierte 2002 mit Linux-Systemen, die alle einen aktiven Daemon hatten. Das ist die normale Verfahrensweise. Auch den Betrieb des Kommandos rsync durch einen einfachen Kunden wird der Provider wohl nicht zulassen. Ich betreibe meine Shell 'bish' zwar auf dem System des Providers. Jedoch im vordefinierten Verzeichnis ./cgi. Dort wird diese Exe vom Webserver des Providers für jede HTTP-Aktion indirekt gestartet. Das ist seit Jahrzehnten so, ohne explizite Erlaubnis. >> Dann erkläre doch mal, wie der Betrieb mit offenen Verzeichnissen mittels rsync >> konkret gestaltet werden kann. > > Was ist ein offenes Verzeichnis? Das hatte ich bereits zuvor erwähnt, ohne daß nachgefragt wurde. Meine Backups HDD und CARD auf meiner Workstation arbeiten beidseitig mit offenen Dateisystemen, nicht mit tar-Archiven wie für meine Webseite. Ich kann also direkt 'ls -lR /u' und 'ls -lR /card/u' aufrufen und erhalte jeweils eine Dateiliste. Das ist für mich ein offenes Verzeichnis. >> Und unverschlüsselte Daten von mir dürfen nirgendwo zugreifbar sein. > > Warum sind sie unverschlüsselt und warum liegen sie dann auf einem > Webspace? Es existieren keinerlei Inhalte lokaler Dateisysteme in direkter Form auf meiner Webseite. Sondern es existieren dedizierte Inhalte aus meinem Verzeichnis /u/hp auf meiner Webseite. >> Und es müssen mehrere Verschlüsselungen hintereinander erfolgen, mit von mir >> ausgewählten Algorithmen. > > Warum? Kennst Du eine Schwachstelle in AES256, von der wir noch nicht > wissen? Und warum bist Du dann noch hier und nicht im Debriefing bei > den Geheimdiensten? Und wie schützt Du die Schlüssel dieser > "mehrfachen" Verschlüsselung? Ich kenne keine Schwachstelle in AES256, das ist eine makellose Block-Chiffre (Belgien). Ich bevorzuge allerdings Strom-Chiffren! In meiner Shell sind mehrere kryptographische Algorithmen implementiert. Überwiegend moderne Algorithmen mit bis zu 256 Bit beim Key. Zugang zu meinen Schlüsseln ist nur durch mich möglich - ganz sicher, mehrere Barrieren. Es wäre unprofessionell, hier Details zu erzählen. Jeder, der versucht, Zugang zu erlangen, wird auf eine undurchdringliche Wand treffen. Die stärkste Sicherheitsmaßnahme ist, daß meine privaten Daten völlig uninteressant für Gewinn suchende Personen sind. >> Ich frage mich, wie rsync da die Dateilisten vergleichen will, wenn meine >> Systeme keine verschlüsselten Dateien haben, am Ziel aber alles permanent >> verschlüsselt sein muß. Wobei ein Algorithmus von mir die Size ändert. > > Du redest wirr. Nein, ich weiß, daß ein Bestreben, hier eine Verwendung von rsync vorzunehmen, unsinnig ist. >>>> Ich weiß genau, warum scp/sftp abbrechen, denn ich habe das einige Tage analysiert. >>>> Genannt habe den Abbruch-Grund ebenso, was ebenso von Dir ignoriert wird. >>>> >>>>>> Viele Kommunikations-Aliase für die 'csh' habe ich damals beruflich angelegt. >>>>> >>>>> Gosh! Raketenwissenschaft! Wo hast Du das denn gelernt? >>>> >>>> Was soll denn diese blödsinnige Aussage? >>>> Ich habe sehr oft verschiedenste Kommunikation mit mehreren Servern meines >>>> Arbeitgebers aufnehmen müssen. >>> >>> Doch mehrere Server, wow. Wir sind beeindruckt. >> >> Was soll dieses blöde Gelabere? > > Du hältst Dich für Chuck Norris und brüstest Dich mit Dingen, über die > Schüler lachen. Ich halte mich überhaupt nicht für Chuck Norris. Das ist eine bloße Erfindung, um mich herabzusetzen. Mit welchen Dingen, über die Schüler lachen, brüstete ich mich hier - konkret? >> Ich war damals allerdings neben einem Entwicklungsingenieur auch ein halber Admin >> und hatte das Management des Tape-Servers übernommen, wozu ich Skripte schrieb, >> was dort niemand außer mir konnte. > > HIER kann das JEDER, und jeder weiß, dass Dein NIH¹ schon fast > krankhaft ist. Komischerweise sagen fast alle, die Teile meiner Skripte lesen: "Ich versteh' das alles nicht!" Überall, wo ich arbeitete, hatte niemand auch nur die leiseste Ahnung von Shell-Skripten. Falls jemand Scripting kennt, ist es fast immer Python. Python bietet mir jedoch viel zu wenig Programmierstärke. > ¹ Eigene Krypto ist ja schon ein zuverlässiger Deppendetektor, aber > sich einen eigenen SHELL zu schreiben ist wirklich ein ganz eigener > Level an Hybris. Deine vorstehenden Meinungen wird niemand aus einem 'seriösen' Bereich teilen. Es ist auch nicht klar, was 'Eigene Krypto' genau bedeuten soll. Wer sich also mit eigener Krypto beschäftigt, ist folglich ein Depp?! In den Bereichen, die ich kenne, wird man für solch ein Interesse gelobt! Und die eigene Shell war eine Projektarbeit am b.i.b. Paderborn, wo ich in den 1990ern 9 Monate lernte, im Wert von über 30000 DM. Damals gab es die heute bekannten Interpreter noch nicht, weshalb es mich dürstete, einen bedeutend stärkeren Interpreter als die damals vorhandenen für mich zu entwickeln, was mir glänzend gelungen ist. Und dies soll ein ganz eigener Level an Hybris sein? Welch ein Stuß! Es ist ganz einfach eine hochleistungsfähige Shell entstanden - außerordentlich nützlich. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
| From | Alexander Schreiber <als@usenet.thangorodrim.de> |
|---|---|
| Date | 2026-09-10 15:28 +0200 |
| Message-ID | <slrn11a5c4i.2jppk.als@mordor.angband.thangorodrim.de> |
| In reply to | #369238 |
Helmut Schellong <var@schellong.biz> wrote:
> Marc Haber wrote on 10.09.2026 07:49:
>> Helmut Schellong <var@schellong.biz> wrote:
>>> Nenne einen Fakt, der diese Einschätzung gerechtfertigt.
>>
>> Dein Auftreten hier reicht völlig.
>
> Das ist wieder eine bloße Behauptung ohne irgendwas Konkretes.
>
>>> Es gibt den behauptenden Marc - und seine blinden Mitläufer.
>>
>> Oh, das ist aber ein Kompliment, das ich leider nicht annehmen kann.
>> Alexander hat vermutlich fünfmal so viel Erfahrung im Betrieb großer
>> Umgebungen als ich. Ich schätze ihn als einen anspruchsvollen und
>> kompetenten Gesprächspartner.
>>
>>>> Dem ist mit einem rsync-Binary am anderen Ende trivial abhelfbar. Zumal
>>>> rsync & ssh sich nicht eben gegenseitig ausschliessen.
>>>
>>> Der Provider wird den Betrieb eines user-rsync-Daemons nicht zulassen.
>>
>> Von einem rsync-Daemon sprach niemand.
>
> Ich kommunizierte 2002 mit Linux-Systemen, die alle einen aktiven Daemon hatten.
> Das ist die normale Verfahrensweise.
Naja, kontextsensitiv. Für öffentliche Archive gibt es oft rsync-Server
damit Spiegel effizienter aktualisiert werden können. Ansonsten sehe
ich eher rsync-over-ssh (aus offensichtlichen Gründen) als üblicherweise
im Einsatz.
> Auch den Betrieb des Kommandos rsync durch einen einfachen Kunden
> wird der Provider wohl nicht zulassen.
Warum? Und: Kann man ja erfragen. Und im bedarfsweise den Anbieter
wechseln.
> Ich betreibe meine Shell 'bish' zwar auf dem System des Providers.
> Jedoch im vordefinierten Verzeichnis ./cgi.
Bitte was?
> Dort wird diese Exe vom Webserver des Providers für jede HTTP-Aktion indirekt gestartet.
> Das ist seit Jahrzehnten so, ohne explizite Erlaubnis.
Aha. Kein Kommentar.
>>> Dann erkläre doch mal, wie der Betrieb mit offenen Verzeichnissen mittels rsync
>>> konkret gestaltet werden kann.
>>
>> Was ist ein offenes Verzeichnis?
>
> Das hatte ich bereits zuvor erwähnt, ohne daß nachgefragt wurde.
>
> Meine Backups HDD und CARD auf meiner Workstation arbeiten beidseitig
> mit offenen Dateisystemen, nicht mit tar-Archiven wie für meine Webseite.
> Ich kann also direkt 'ls -lR /u' und 'ls -lR /card/u' aufrufen
> und erhalte jeweils eine Dateiliste.
> Das ist für mich ein offenes Verzeichnis.
Der Meister erfindet Neue Fachbegriffe der Technik und erklärt sie auf
Anfrage auch, famos.
>>> Und es müssen mehrere Verschlüsselungen hintereinander erfolgen, mit von mir
>>> ausgewählten Algorithmen.
>>
>> Warum? Kennst Du eine Schwachstelle in AES256, von der wir noch nicht
>> wissen? Und warum bist Du dann noch hier und nicht im Debriefing bei
>> den Geheimdiensten? Und wie schützt Du die Schlüssel dieser
>> "mehrfachen" Verschlüsselung?
>
> Ich kenne keine Schwachstelle in AES256, das ist eine makellose Block-Chiffre (Belgien).
> Ich bevorzuge allerdings Strom-Chiffren!
Warum?
> In meiner Shell sind mehrere kryptographische Algorithmen implementiert.
Eigene Krypto-Implementation geschrieben, hmm? Ok, das passt zum Profil.
> Überwiegend moderne Algorithmen mit bis zu 256 Bit beim Key.
>
> Zugang zu meinen Schlüsseln ist nur durch mich möglich - ganz sicher, mehrere Barrieren.
> Es wäre unprofessionell, hier Details zu erzählen.
> Jeder, der versucht, Zugang zu erlangen, wird auf eine undurchdringliche Wand treffen.
Der ist gut. Siehe xkcd/538.
> Die stärkste Sicherheitsmaßnahme ist, daß meine privaten Daten völlig uninteressant
> für Gewinn suchende Personen sind.
Verbleiben noch Interessenten ohne Gewinnerzielungsabsicht, auch bekannt als
Organisationen mit berechtigtem Interesse.
>>> Ich frage mich, wie rsync da die Dateilisten vergleichen will, wenn meine
>>> Systeme keine verschlüsselten Dateien haben, am Ziel aber alles permanent
>>> verschlüsselt sein muß. Wobei ein Algorithmus von mir die Size ändert.
>>
>> Du redest wirr.
>
> Nein, ich weiß, daß ein Bestreben, hier eine Verwendung von rsync vorzunehmen, unsinnig ist.
>
>>>>> Ich weiß genau, warum scp/sftp abbrechen, denn ich habe das einige Tage analysiert.
>>>>> Genannt habe den Abbruch-Grund ebenso, was ebenso von Dir ignoriert wird.
>>>>>
>>>>>>> Viele Kommunikations-Aliase für die 'csh' habe ich damals beruflich angelegt.
>>>>>>
>>>>>> Gosh! Raketenwissenschaft! Wo hast Du das denn gelernt?
>>>>>
>>>>> Was soll denn diese blödsinnige Aussage?
>>>>> Ich habe sehr oft verschiedenste Kommunikation mit mehreren Servern meines
>>>>> Arbeitgebers aufnehmen müssen.
>>>>
>>>> Doch mehrere Server, wow. Wir sind beeindruckt.
>>>
>>> Was soll dieses blöde Gelabere?
>>
>> Du hältst Dich für Chuck Norris und brüstest Dich mit Dingen, über die
>> Schüler lachen.
>
> Ich halte mich überhaupt nicht für Chuck Norris.
> Das ist eine bloße Erfindung, um mich herabzusetzen.
> Mit welchen Dingen, über die Schüler lachen, brüstete ich mich hier - konkret?
>
>>> Ich war damals allerdings neben einem Entwicklungsingenieur auch ein halber Admin
>>> und hatte das Management des Tape-Servers übernommen, wozu ich Skripte schrieb,
>>> was dort niemand außer mir konnte.
>>
>> HIER kann das JEDER, und jeder weiß, dass Dein NIH¹ schon fast
>> krankhaft ist.
>
> Komischerweise sagen fast alle, die Teile meiner Skripte lesen: "Ich versteh' das alles nicht!"
Tja, warum wohl? Nur mal so am Rande: Wer im professionellen Umfeld Code
schreibt, den keiner versteht, dessen Bleiben ist nicht lang.
> Überall, wo ich arbeitete, hatte niemand auch nur die leiseste Ahnung von Shell-Skripten.
> Falls jemand Scripting kennt, ist es fast immer Python.
> Python bietet mir jedoch viel zu wenig Programmierstärke.
Wie misst man eigentlich diese "Programmierstärke"? Und was ist die Einheit?
Schellongs/Datei?
>> ¹ Eigene Krypto ist ja schon ein zuverlässiger Deppendetektor, aber
>> sich einen eigenen SHELL zu schreiben ist wirklich ein ganz eigener
>> Level an Hybris.
>
> Deine vorstehenden Meinungen wird niemand aus einem 'seriösen' Bereich teilen.
Och, mindestens einer: meld!.
> Es ist auch nicht klar, was 'Eigene Krypto' genau bedeuten soll.
> Wer sich also mit eigener Krypto beschäftigt, ist folglich ein Depp?!
> In den Bereichen, die ich kenne, wird man für solch ein Interesse gelobt!
Sich mit Kryptographie zu beschäftigen, Fachwissen und Erfahrung aufzu-
bauen: ja. Eigene Kryptographie-Implementationen hingegen sind generell
grosse rote Fahnen[0], aus guten Gründen.
> Und die eigene Shell war eine Projektarbeit am b.i.b. Paderborn, wo ich
> in den 1990ern 9 Monate lernte, im Wert von über 30000 DM.
DM 30000 für 9 Monate? Wow. Ich vermute, jetzt ist es zu spät, Dein Schul-
geld zurückzuverlangen?
> Damals gab es die heute bekannten Interpreter noch nicht, weshalb es mich
Sag mal, war dieses Bildungszentrum unter einem sehr grossen Stein?
Denn Interpreter für Programmiersprachen waren damals schon eine alte
und wohlbekannte Idee.
> dürstete, einen bedeutend stärkeren Interpreter als die damals vorhandenen
> für mich zu entwickeln, was mir glänzend gelungen ist.
> Und dies soll ein ganz eigener Level an Hybris sein? Welch ein Stuß!
> Es ist ganz einfach eine hochleistungsfähige Shell entstanden - außerordentlich nützlich.
Hehe, sehr lustig, dass Du mir mit Deinen eigenen Worten die Argumentation
ersparst.
Man liest sich,
Alex.
[0] Ausnahme: Bekannte kryptographische Algorithmen als Verständnisübung
zu Lernzwecken implementieren. Dann den Code aber in der "Übungs-
material"-Schublade liegenlassen.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <var@schellong.biz> |
|---|---|
| Date | 2026-09-10 17:41 +0200 |
| Message-ID | <117uj25$16oh$1@solani.org> |
| In reply to | #369247 |
Alexander Schreiber wrote on 10.09.2026 15:28: > Helmut Schellong <var@schellong.biz> wrote: >> Marc Haber wrote on 10.09.2026 07:49: >>> Helmut Schellong <var@schellong.biz> wrote: >>>> Nenne einen Fakt, der diese Einschätzung gerechtfertigt. >>> >>> Dein Auftreten hier reicht völlig. >> >> Das ist wieder eine bloße Behauptung ohne irgendwas Konkretes. >> >>>> Es gibt den behauptenden Marc - und seine blinden Mitläufer. >>> >>> Oh, das ist aber ein Kompliment, das ich leider nicht annehmen kann. >>> Alexander hat vermutlich fünfmal so viel Erfahrung im Betrieb großer >>> Umgebungen als ich. Ich schätze ihn als einen anspruchsvollen und >>> kompetenten Gesprächspartner. >>> >>>>> Dem ist mit einem rsync-Binary am anderen Ende trivial abhelfbar. Zumal >>>>> rsync & ssh sich nicht eben gegenseitig ausschliessen. >>>> >>>> Der Provider wird den Betrieb eines user-rsync-Daemons nicht zulassen. >>> >>> Von einem rsync-Daemon sprach niemand. >> >> Ich kommunizierte 2002 mit Linux-Systemen, die alle einen aktiven Daemon hatten. >> Das ist die normale Verfahrensweise. > > Naja, kontextsensitiv. Für öffentliche Archive gibt es oft rsync-Server > damit Spiegel effizienter aktualisiert werden können. Ansonsten sehe > ich eher rsync-over-ssh (aus offensichtlichen Gründen) als üblicherweise > im Einsatz. Wenn ich unter FreeBSD rsync installiere, ist dadurch automatisch ein Daemon vorhanden. >> Auch den Betrieb des Kommandos rsync durch einen einfachen Kunden >> wird der Provider wohl nicht zulassen. > > Warum? Und: Kann man ja erfragen. Und im bedarfsweise den Anbieter > wechseln. Warum sollte ich nun ein Konzept mit rsync beginnen? Ich habe doch sftp, scp, ssh zur Verfügung, seit bald 25 Jahren. Vom Provider vorgesehen. Meine neuen Skripte wären dann dadurch erheblich weniger sinnvoll geworden. Und meine hohen Sicherheitsansprüche wären nicht erfüllt. >> Ich betreibe meine Shell 'bish' zwar auf dem System des Providers. >> Jedoch im vordefinierten Verzeichnis ./cgi. > > Bitte was? > >> Dort wird diese Exe vom Webserver des Providers für jede HTTP-Aktion indirekt gestartet. >> Das ist seit Jahrzehnten so, ohne explizite Erlaubnis. > > Aha. Kein Kommentar. Das ist Standard bei IONOS, von Schlund&Partner übernommen. IONOS hatte mich auch mal per eMail informiert, daß meine Exe (32 Bit) alsbald eine 64Bit-Linux-Exe sein muß. Diese Exe wird von den vielen bish-Skripten dort per Shebang-Zeile aufgerufen. >>>> Dann erkläre doch mal, wie der Betrieb mit offenen Verzeichnissen mittels rsync >>>> konkret gestaltet werden kann. >>> >>> Was ist ein offenes Verzeichnis? >> >> Das hatte ich bereits zuvor erwähnt, ohne daß nachgefragt wurde. >> >> Meine Backups HDD und CARD auf meiner Workstation arbeiten beidseitig >> mit offenen Dateisystemen, nicht mit tar-Archiven wie für meine Webseite. >> Ich kann also direkt 'ls -lR /u' und 'ls -lR /card/u' aufrufen >> und erhalte jeweils eine Dateiliste. >> Das ist für mich ein offenes Verzeichnis. > > Der Meister erfindet Neue Fachbegriffe der Technik und erklärt sie auf > Anfrage auch, famos. > >>>> Und es müssen mehrere Verschlüsselungen hintereinander erfolgen, mit von mir >>>> ausgewählten Algorithmen. >>> >>> Warum? Kennst Du eine Schwachstelle in AES256, von der wir noch nicht >>> wissen? Und warum bist Du dann noch hier und nicht im Debriefing bei >>> den Geheimdiensten? Und wie schützt Du die Schlüssel dieser >>> "mehrfachen" Verschlüsselung? >> >> Ich kenne keine Schwachstelle in AES256, das ist eine makellose Block-Chiffre (Belgien). >> Ich bevorzuge allerdings Strom-Chiffren! > > Warum? Der Umgang (in C) damit ist einfacher; man muß sich nicht um einen Blockrest kümmern. Und mir sind anfangs zwei gute Strom-Chiffren zufällig zugeflogen. >> In meiner Shell sind mehrere kryptographische Algorithmen implementiert. > > Eigene Krypto-Implementation geschrieben, hmm? Ok, das passt zum Profil. > >> Überwiegend moderne Algorithmen mit bis zu 256 Bit beim Key. >> >> Zugang zu meinen Schlüsseln ist nur durch mich möglich - ganz sicher, mehrere Barrieren. >> Es wäre unprofessionell, hier Details zu erzählen. >> Jeder, der versucht, Zugang zu erlangen, wird auf eine undurchdringliche Wand treffen. > > Der ist gut. Siehe xkcd/538. > >> Die stärkste Sicherheitsmaßnahme ist, daß meine privaten Daten völlig uninteressant >> für Gewinn suchende Personen sind. > > Verbleiben noch Interessenten ohne Gewinnerzielungsabsicht, auch bekannt als > Organisationen mit berechtigtem Interesse. Ich bezweifle auch dort ein wirkliches Interesse. Niemand weiß doch, was er durch seine Bemühungen bekommen wird. Was ist bei mir Rentner zu erwarten? >>>> Ich frage mich, wie rsync da die Dateilisten vergleichen will, wenn meine >>>> Systeme keine verschlüsselten Dateien haben, am Ziel aber alles permanent >>>> verschlüsselt sein muß. Wobei ein Algorithmus von mir die Size ändert. >>> >>> Du redest wirr. >> >> Nein, ich weiß, daß ein Bestreben, hier eine Verwendung von rsync vorzunehmen, unsinnig ist. >> >>>>>> Ich weiß genau, warum scp/sftp abbrechen, denn ich habe das einige Tage analysiert. >>>>>> Genannt habe den Abbruch-Grund ebenso, was ebenso von Dir ignoriert wird. >>>>>> >>>>>>>> Viele Kommunikations-Aliase für die 'csh' habe ich damals beruflich angelegt. >>>>>>> >>>>>>> Gosh! Raketenwissenschaft! Wo hast Du das denn gelernt? >>>>>> >>>>>> Was soll denn diese blödsinnige Aussage? >>>>>> Ich habe sehr oft verschiedenste Kommunikation mit mehreren Servern meines >>>>>> Arbeitgebers aufnehmen müssen. >>>>> >>>>> Doch mehrere Server, wow. Wir sind beeindruckt. >>>> >>>> Was soll dieses blöde Gelabere? >>> >>> Du hältst Dich für Chuck Norris und brüstest Dich mit Dingen, über die >>> Schüler lachen. >> >> Ich halte mich überhaupt nicht für Chuck Norris. >> Das ist eine bloße Erfindung, um mich herabzusetzen. >> Mit welchen Dingen, über die Schüler lachen, brüstete ich mich hier - konkret? >> >>>> Ich war damals allerdings neben einem Entwicklungsingenieur auch ein halber Admin >>>> und hatte das Management des Tape-Servers übernommen, wozu ich Skripte schrieb, >>>> was dort niemand außer mir konnte. >>> >>> HIER kann das JEDER, und jeder weiß, dass Dein NIH¹ schon fast >>> krankhaft ist. >> >> Komischerweise sagen fast alle, die Teile meiner Skripte lesen: "Ich versteh' das alles nicht!" > > Tja, warum wohl? Nur mal so am Rande: Wer im professionellen Umfeld Code > schreibt, den keiner versteht, dessen Bleiben ist nicht lang. Bei meinem letzten Arbeitgeber war ich 15 Jahre lang. Ich habe da genau solch einen Stil realisiert, wie aktuell. Mein Kollege hatte meinen Code ohne Probleme gelesen und verstanden. Der Kollege ist allerdings ein Profi wie ich. >> Überall, wo ich arbeitete, hatte niemand auch nur die leiseste Ahnung von Shell-Skripten. >> Falls jemand Scripting kennt, ist es fast immer Python. >> Python bietet mir jedoch viel zu wenig Programmierstärke. > > Wie misst man eigentlich diese "Programmierstärke"? Und was ist die Einheit? > Schellongs/Datei? Ich habe halt einen Tag lang zu Python recherchiert und gelesen. Lesen ist eine Stärke von mir. Nach meiner Informationssammlung war mir klar, daß ich Python nicht verwenden werde, weil mein Interpreter beträchtlich stärker und universeller ist. Das ist kein Wunder, denn ich entwickelte meine Shell gemäß meiner Wünsche (ab 1995). >>> ¹ Eigene Krypto ist ja schon ein zuverlässiger Deppendetektor, aber >>> sich einen eigenen SHELL zu schreiben ist wirklich ein ganz eigener >>> Level an Hybris. >> >> Deine vorstehenden Meinungen wird niemand aus einem 'seriösen' Bereich teilen. > > Och, mindestens einer: meld!. Newsgroups waren mal seriös. Heute sind sie zu heterogen, so daß sie kaum als seriöses Medium nennbar sind. >> Es ist auch nicht klar, was 'Eigene Krypto' genau bedeuten soll. >> Wer sich also mit eigener Krypto beschäftigt, ist folglich ein Depp?! >> In den Bereichen, die ich kenne, wird man für solch ein Interesse gelobt! > > Sich mit Kryptographie zu beschäftigen, Fachwissen und Erfahrung aufzu- > bauen: ja. Eigene Kryptographie-Implementationen hingegen sind generell > grosse rote Fahnen[0], aus guten Gründen. Na ja - ich meine _selbst_ entwickelte Algorithmen: nur für mich! Von anderen entwickelte Solche habe ich 'lediglich' in meine Shell eingebaut. Das hat nicht wenig Arbeit gemacht, bis ein Kommando 'rund' ist. >> Und die eigene Shell war eine Projektarbeit am b.i.b. Paderborn, wo ich >> in den 1990ern 9 Monate lernte, im Wert von über 30000 DM. > > DM 30000 für 9 Monate? Wow. Ich vermute, jetzt ist es zu spät, Dein Schul- > geld zurückzuverlangen? Das Arbeitsamt Bielefeld hatte das Geld losgeeist. Ein Lehrgang für Maschinenbau- und Elektrotechnik-Ingenieure. >> Damals gab es die heute bekannten Interpreter noch nicht, weshalb es mich > > Sag mal, war dieses Bildungszentrum unter einem sehr grossen Stein? > > Denn Interpreter für Programmiersprachen waren damals schon eine alte > und wohlbekannte Idee. Das hatte ich nur unter Windows3.1 1985 in Form von Basic kennengelernt. Pascal, C, Cobol, Algol, FORTRAN, PEARL, Ada, etc. sind alles Compiler-Sprachen. Alle heute gängigen Interpreter gab es 1995 nicht. >> dürstete, einen bedeutend stärkeren Interpreter als die damals vorhandenen >> für mich zu entwickeln, was mir glänzend gelungen ist. >> Und dies soll ein ganz eigener Level an Hybris sein? Welch ein Stuß! >> Es ist ganz einfach eine hochleistungsfähige Shell entstanden - außerordentlich nützlich. > > Hehe, sehr lustig, dass Du mir mit Deinen eigenen Worten die Argumentation > ersparst. Ich verwende nur noch 'bish' (selten sh/bash/tcsh) und C, selten C++. -- Mit freundlichen Grüßen Helmut Schellong
[toc] | [prev] | [next] | [standalone]
Page 1 of 12 [1] 2 3 … 12 Next page →
Back to top | Article view | de.sci.electronics
csiph-web