Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.alt.folklore.computer > #27248 > unrolled thread
| Started by | Josef Moellers <josef.moellers@invalid.invalid> |
|---|---|
| First post | 2020-02-12 08:28 +0100 |
| Last post | 2020-03-09 10:37 +0000 |
| Articles | 20 on this page of 275 — 23 participants |
Back to article view | Back to de.alt.folklore.computer
unix5 auf PiDP11 Josef Moellers <josef.moellers@invalid.invalid> - 2020-02-12 08:28 +0100
Re: unix5 auf PiDP11 mlelstv@serpens.de (Michael van Elst) - 2020-02-12 08:18 +0000
Re: unix5 auf PiDP11 Kay Martinen <kay@martinen.de> - 2020-02-12 09:54 +0100
Re: unix5 auf PiDP11 Josef Moellers <josef.moellers@invalid.invalid> - 2020-02-13 10:30 +0100
Re: unix5 auf PiDP11 Guido Grohmann <guido.grohmann@gmx.de> - 2020-02-12 09:54 +0100
Re: unix5 auf PiDP11 Kay Martinen <kay@martinen.de> - 2020-02-12 10:11 +0100
Re: unix5 auf PiDP11 Andreas Kohlbach <ank@spamfence.net> - 2020-02-12 09:28 -0500
Re: unix5 auf PiDP11 Josef Moellers <josef.moellers@invalid.invalid> - 2020-02-13 10:25 +0100
Re: unix5 auf PiDP11 Holm Tiffe <holm@freibergnet.de> - 2020-02-15 10:52 +0100
Re: unix5 auf PiDP11 Josef Moellers <josef.moellers@invalid.invalid> - 2020-03-03 08:24 +0100
Re: unix5 auf PiDP11 Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2020-03-06 23:36 +0000
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-07 08:30 +0100
Re: unix5 auf PiDP11 olaf <olaf@criseis.ruhr.de> - 2020-03-07 10:55 +0100
Installation von Abhängigkeiten neuer Software (was: unix5 auf PiDP11) Michael Bäuerle <michael.baeuerle@gmx.net> - 2020-03-07 10:50 +0000
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-07 12:01 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-07 18:07 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-07 18:24 +0100
Re: unix5 auf PiDP11 Bernd Laengerich <bernd.laengerich@web.de> - 2020-03-07 22:21 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-07 22:39 +0100
Re: unix5 auf PiDP11 Ulf Volmer <u.volmer@u-v.de> - 2020-03-07 23:01 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-07 23:22 +0100
Re: unix5 auf PiDP11 Ulf Volmer <u.volmer@u-v.de> - 2020-03-07 23:31 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-07 23:51 +0100
Re: unix5 auf PiDP11 Ulf Volmer <u.volmer@u-v.de> - 2020-03-08 00:23 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-08 07:41 +0100
Re: unix5 auf PiDP11 Ulf Volmer <u.volmer@u-v.de> - 2020-03-08 20:20 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-08 20:40 +0100
Re: unix5 auf PiDP11 Ulf Volmer <u.volmer@u-v.de> - 2020-03-08 20:54 +0100
Re: unix5 auf PiDP11 Stefan Reuther <stefan.news@arcor.de> - 2020-03-09 17:44 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-09 18:34 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-09 10:54 +0000
Re: unix5 auf PiDP11 Bernd Laengerich <bernd.laengerich@web.de> - 2020-03-08 18:09 +0100
Re: unix5 auf PiDP11 Stefan Reuther <stefan.news@arcor.de> - 2020-03-08 10:25 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-08 13:18 +0100
Re: unix5 auf PiDP11 Stefan Reuther <stefan.news@arcor.de> - 2020-03-09 17:52 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-09 18:28 +0100
Re: unix5 auf PiDP11 Bernd Laengerich <bernd.laengerich@web.de> - 2020-03-09 20:16 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-09 20:23 +0100
Re: unix5 auf PiDP11 Bernd Laengerich <bernd.laengerich@web.de> - 2020-03-09 22:11 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-10 18:06 +0100
Re: unix5 auf PiDP11 Bernd Laengerich <Bernd.Laengerich@web.de> - 2020-03-11 17:02 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-11 17:09 +0100
Re: unix5 auf PiDP11 Bernd Laengerich <bernd.laengerich@web.de> - 2020-03-11 21:17 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-11 21:20 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-13 08:02 +0100
Re: unix5 auf PiDP11 Stefan Reuther <stefan.news@arcor.de> - 2020-03-11 17:49 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-11 18:40 +0100
Re: unix5 auf PiDP11 Ulf Volmer <u.volmer@u-v.de> - 2020-03-11 19:03 +0100
Re: unix5 auf PiDP11 Stefan Reuther <stefan.news@arcor.de> - 2020-03-12 18:46 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-12 19:15 +0100
Re: unix5 auf PiDP11 Stefan Reuther <stefan.news@arcor.de> - 2020-03-13 18:20 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-13 08:07 +0100
Re: unix5 auf PiDP11 Stefan Reuther <stefan.news@arcor.de> - 2020-03-10 18:00 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-10 18:24 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-10 18:56 +0100
Re: unix5 auf PiDP11 Stefan Reuther <stefan.news@arcor.de> - 2020-03-11 17:59 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-08 22:03 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-08 21:59 +0100
Re: unix5 auf PiDP11 Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2020-03-07 19:19 +0000
systemd (was: unix5 auf PiDP11) Michael Bäuerle <michael.baeuerle@gmx.net> - 2020-03-08 08:48 +0000
Re: systemd Arno Welzel <usenet@arnowelzel.de> - 2020-03-08 15:03 +0100
Re: systemd poc@pocnet.net - 2020-03-09 11:30 +0000
Re: systemd Arno Welzel <usenet@arnowelzel.de> - 2020-03-11 02:45 +0100
Re: systemd Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-11 06:53 +0100
Re: systemd Arno Welzel <usenet@arnowelzel.de> - 2020-03-11 11:43 +0100
Re: systemd Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-11 11:53 +0100
Re: systemd Arno Welzel <usenet@arnowelzel.de> - 2020-03-12 02:28 +0100
Re: systemd Hanno Foest <hurga-news2@tigress.com> - 2020-03-11 12:05 +0100
Re: systemd Michael Bäuerle <michael.baeuerle@stz-e.de> - 2020-03-11 13:32 +0100
Re: systemd Arno Welzel <usenet@arnowelzel.de> - 2020-03-12 02:33 +0100
Re: systemd Kay Martinen <usenet@martinen.de> - 2020-03-14 23:20 +0100
Re: systemd Arno Welzel <usenet@arnowelzel.de> - 2020-03-15 14:36 +0100
Re: systemd Josef Moellers <josef.moellers@invalid.invalid> - 2020-03-16 08:46 +0100
Re: systemd Arno Welzel <usenet@arnowelzel.de> - 2020-03-16 10:22 +0100
Re: systemd poc@pocnet.net - 2020-03-14 17:58 +0000
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-08 21:57 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-09 10:50 +0000
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-09 16:49 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-10 00:57 +0000
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-10 10:56 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-10 18:15 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-11 03:01 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-14 18:12 +0000
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-14 20:16 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-14 20:47 +0100
Re: unix5 auf PiDP11 Ulf Volmer <u.volmer@u-v.de> - 2020-03-14 21:00 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-14 21:05 +0100
Re: unix5 auf PiDP11 Sven Hartge <sh-203@svenhartge.de> - 2020-03-15 19:28 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-15 19:49 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-15 20:20 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-15 21:58 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-16 00:55 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-14 20:03 +0000
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-14 21:06 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-14 20:11 +0000
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-14 21:18 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-15 16:01 +0000
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-15 18:23 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-16 18:53 +0000
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-16 20:05 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-14 22:30 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-14 23:13 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-14 23:28 +0100
Re: unix5 auf PiDP11 Stefan Weimar <usenet2019@meinhop3.de> - 2020-03-15 09:21 +0000
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-15 11:55 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-15 14:56 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-15 15:17 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-15 16:07 +0000
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-15 20:26 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-15 21:59 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-16 00:59 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-11 02:59 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-11 12:07 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-12 02:35 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-12 14:20 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-13 08:10 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-13 11:44 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-13 14:34 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-13 14:42 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-13 16:28 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-14 01:12 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-14 13:27 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-14 14:42 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-14 15:45 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-14 16:16 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-14 20:19 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-14 21:21 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-14 18:52 +0000
Re: unix5 auf PiDP11 Nils M Holm <nmh@ananda.local> - 2020-03-07 11:24 +0000
Re: unix5 auf PiDP11 Dennis Grevenstein <dennis.grevenstein@gmail.com> - 2020-03-07 11:50 +0000
Re: unix5 auf PiDP11 Nils M Holm <nmh@ananda.local> - 2020-03-07 12:19 +0000
Re: unix5 auf PiDP11 olaf <olaf@criseis.ruhr.de> - 2020-03-07 14:09 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-07 16:12 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-07 18:11 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-07 18:26 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-07 19:26 +0100
Re: unix5 auf PiDP11 olaf <olaf@criseis.ruhr.de> - 2020-03-07 20:28 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-07 20:34 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-09 10:48 +0000
Re: unix5 auf PiDP11 olaf <olaf@criseis.ruhr.de> - 2020-03-09 12:54 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-10 01:06 +0000
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-09 17:39 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-11 03:14 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-11 06:39 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-11 11:49 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-11 11:57 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-12 02:37 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-12 06:31 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-13 07:34 +0100
Re: unix5 auf PiDP11 Stefan Reuther <stefan.news@arcor.de> - 2020-03-11 18:09 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-11 12:19 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-12 02:40 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-12 06:36 +0100
Re: unix5 auf PiDP11 Stefan Reuther <stefan.news@arcor.de> - 2020-03-12 18:53 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-12 19:01 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-13 07:47 +0100
Re: unix5 auf PiDP11 Stefan Reuther <stefan.news@arcor.de> - 2020-03-13 18:24 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-14 01:19 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-14 13:29 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-14 14:33 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-14 15:48 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-14 15:54 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-14 16:27 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-14 19:14 +0000
Re: unix5 auf PiDP11 Stefan Reuther <stefan.news@arcor.de> - 2020-03-15 11:37 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-15 12:33 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-15 14:59 +0100
Re: unix5 auf PiDP11 Stefan Reuther <stefan.news@arcor.de> - 2020-03-16 09:45 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-16 10:04 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-16 10:29 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-16 10:38 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-16 14:09 +0100
Re: unix5 auf PiDP11 Stefan Reuther <stefan.news@arcor.de> - 2020-03-16 16:43 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-16 18:24 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-16 18:27 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-16 18:58 +0100
Re: unix5 auf PiDP11 Bernd Laengerich <bernd.laengerich@web.de> - 2020-03-16 22:05 +0100
Re: unix5 auf PiDP11 Stefan Reuther <stefan.news@arcor.de> - 2020-03-17 12:43 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-16 10:28 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-14 16:21 +0100
Re: unix5 auf PiDP11 Stefan Reuther <stefan.news@arcor.de> - 2020-03-15 11:49 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-12 22:31 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-13 07:48 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-13 11:28 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-13 07:42 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-12 14:37 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-13 07:55 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-13 12:05 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-13 16:18 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-13 17:15 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-14 01:02 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-14 13:42 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-14 15:52 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-14 15:57 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-14 20:38 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-14 22:19 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-14 22:43 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-14 23:29 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-15 20:33 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-15 23:18 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-14 19:32 +0000
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-14 20:47 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-14 20:06 +0000
Re: unix5 auf PiDP11 Guido Grohmann <guido.grohmann@gmx.de> - 2020-03-13 15:46 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-13 16:18 +0100
Re: unix5 auf PiDP11 Guido Grohmann <guido.grohmann@gmx.de> - 2020-03-13 19:35 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-14 13:47 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-14 19:09 +0000
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-14 20:45 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-14 19:55 +0000
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-14 22:52 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-15 16:26 +0000
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-15 20:37 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-16 19:07 +0000
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-16 22:54 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-17 13:21 +0000
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-18 01:18 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-18 13:56 +0000
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-18 23:23 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-22 23:28 +0000
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-24 00:14 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-11 03:12 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-14 19:46 +0000
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-14 22:59 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-15 16:29 +0000
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-15 20:40 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-15 20:40 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-16 19:09 +0000
Re: unix5 auf PiDP11 Stefan Reuther <stefan.news@arcor.de> - 2020-03-08 10:14 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-09 10:44 +0000
Re: unix5 auf PiDP11 "Andreas Schwarz" <Andreas.Schwarz@usenet2.schwarzes.net> - 2020-03-07 18:18 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-09 10:41 +0000
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-11 03:20 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-11 06:45 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-11 11:53 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-11 12:01 +0100
Re: unix5 auf PiDP11 Ulf Volmer <u.volmer@u-v.de> - 2020-03-11 16:17 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-11 17:07 +0100
Re: unix5 auf PiDP11 Ulf Volmer <u.volmer@u-v.de> - 2020-03-11 17:31 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-11 18:24 +0100
Re: unix5 auf PiDP11 Ulf Volmer <u.volmer@u-v.de> - 2020-03-11 19:00 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-11 19:14 +0100
Re: unix5 auf PiDP11 Ulf Volmer <u.volmer@u-v.de> - 2020-03-11 19:22 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-11 19:28 +0100
Re: unix5 auf PiDP11 Ulf Volmer <u.volmer@u-v.de> - 2020-03-11 19:37 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-11 19:39 +0100
Re: unix5 auf PiDP11 Ulf Volmer <u.volmer@u-v.de> - 2020-03-11 19:48 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-11 19:53 +0100
Re: unix5 auf PiDP11 Ulf Volmer <u.volmer@u-v.de> - 2020-03-11 19:59 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-11 20:27 +0100
Re: unix5 auf PiDP11 Ulf Volmer <u.volmer@u-v.de> - 2020-03-11 20:38 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-11 21:37 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-11 21:42 +0100
Re: unix5 auf PiDP11 Ulf Volmer <u.volmer@u-v.de> - 2020-03-11 21:51 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-11 22:05 +0100
Re: unix5 auf PiDP11 Ulf Volmer <u.volmer@u-v.de> - 2020-03-11 22:17 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-11 22:25 +0100
Re: unix5 auf PiDP11 Ulf Volmer <u.volmer@u-v.de> - 2020-03-11 22:42 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-11 23:27 +0100
Re: unix5 auf PiDP11 Ulf Volmer <u.volmer@u-v.de> - 2020-03-11 23:39 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-12 14:41 +0100
Re: unix5 auf PiDP11 Ulf Volmer <u.volmer@u-v.de> - 2020-03-12 15:08 +0100
Re: unix5 auf PiDP11 Hanno Foest <hurga-news2@tigress.com> - 2020-03-12 15:29 +0100
Re: unix5 auf PiDP11 Ulf Volmer <u.volmer@u-v.de> - 2020-03-12 15:33 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-12 06:27 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-11 20:35 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-11 20:40 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-13 07:59 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-12 02:48 +0100
Re: unix5 auf PiDP11 Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-03-12 06:39 +0100
Re: unix5 auf PiDP11 Bernd Laengerich <Bernd.Laengerich@web.de> - 2020-03-12 10:06 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-13 08:00 +0100
Re: unix5 auf PiDP11 Arno Welzel <usenet@arnowelzel.de> - 2020-03-12 02:47 +0100
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-14 19:01 +0000
Re: unix5 auf PiDP11 poc@pocnet.net - 2020-03-09 10:37 +0000
Page 3 of 14 — ← Prev page 1 2 [3] 4 5 … 14 Next page →
| From | Bernd Laengerich <Bernd.Laengerich@web.de> |
|---|---|
| Date | 2020-03-11 17:02 +0100 |
| Message-ID | <hcsgc9Foud6U1@mid.individual.net> |
| In reply to | #27385 |
Am 10.03.2020 um 18:06 schrieb Gerrit Heitsch: > Nur solange du noch an die Dateien kommst, die du dafür brauchst. Sollten die Sicher, aber die erzeugten Images werden hier lokal gespeichert. > Problem. Wenn du es wirklich reproduzierbar willst, solltest du eine komplette > VM nehmen die passend aufgesetzt ist. Die dann für die nötige Arbeit clonen. Das ist ja noch viel mehr Overhead und Komplexität als ein Container. > Solange du die Datei, die die VM darstellt, hast geht das und du bist von > keinem anderen abhängig. Solange ich das Docker-Image, das den Container darstellt, habe geht das und ich bin von keinem anderen abhängig. Bernd
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2020-03-11 17:09 +0100 |
| Message-ID | <r4b2f5$q72$2@news.bawue.net> |
| In reply to | #27414 |
On 3/11/20 5:02 PM, Bernd Laengerich wrote: > Am 10.03.2020 um 18:06 schrieb Gerrit Heitsch: > >> Nur solange du noch an die Dateien kommst, die du dafür brauchst. >> Sollten die > > Sicher, aber die erzeugten Images werden hier lokal gespeichert. > >> Problem. Wenn du es wirklich reproduzierbar willst, solltest du eine >> komplette VM nehmen die passend aufgesetzt ist. Die dann für die >> nötige Arbeit clonen. > > Das ist ja noch viel mehr Overhead und Komplexität als ein Container. Wieso? Die VM ist eine Datei. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Bernd Laengerich <bernd.laengerich@web.de> |
|---|---|
| Date | 2020-03-11 21:17 +0100 |
| Message-ID | <hcsva5Fs1orU1@mid.individual.net> |
| In reply to | #27416 |
Am 11.03.2020 um 17:09 schrieb Gerrit Heitsch: >> Das ist ja noch viel mehr Overhead und Komplexität als ein Container. > > Wieso? Die VM ist eine Datei. ??? Du hast gerade noch gemeckert, daß schon eine Netzwerkabstraktionsschicht für einen Container Overkill wäre (man könnte sich natürlich die hunderten möglichen Kombinationen aus Ports aller möglichen Dienste irgendwie scripten, aber auch die hunderterste muß dann extra behandelt werden). Jetzt meinst Du, einen wirklich kompletten Rechner in einer VM zu emulieren wäre weniger Overhead? Da dauert ja schon das Booten des OS länger als ggf. der Job der darin ausgeführt werden soll. Mal zum Vergleich: Das Image des Ubuntu-Containers ist 87MB groß, aktuell kann man Versionen ab 14.04 nutzen. Der Start der darin auszuführenden Aktionen dauert weniger als 1s. Ich wüsste jetzt ad hoc nicht wie ich das ganze mit kompletten VMs automatisieren könnte, das geht bestimmt, ich habe aber auch keinen Zugriff auf den ESXI-Server und mich daher nie darum gekümmert. Bernd
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2020-03-11 21:20 +0100 |
| Message-ID | <r4bh6g$iu$1@news.bawue.net> |
| In reply to | #27437 |
On 3/11/20 9:17 PM, Bernd Laengerich wrote: > Am 11.03.2020 um 17:09 schrieb Gerrit Heitsch: > >>> Das ist ja noch viel mehr Overhead und Komplexität als ein Container. >> >> Wieso? Die VM ist eine Datei. > > ??? Du hast gerade noch gemeckert, daß schon eine > Netzwerkabstraktionsschicht für einen Container Overkill wäre (man > könnte sich natürlich die hunderten möglichen Kombinationen aus Ports > aller möglichen Dienste irgendwie scripten, aber auch die hunderterste > muß dann extra behandelt werden). Jetzt meinst Du, einen wirklich > kompletten Rechner in einer VM zu emulieren wäre weniger Overhead? Da > dauert ja schon das Booten des OS länger als ggf. der Job der darin > ausgeführt werden soll. > > Mal zum Vergleich: Das Image des Ubuntu-Containers ist 87MB groß, > aktuell kann man Versionen ab 14.04 nutzen. Der Start der darin > auszuführenden Aktionen dauert weniger als 1s. Bei einem lang laufenden Dienst ist die Bootzeit doch egal? Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2020-03-13 08:02 +0100 |
| Message-ID | <hd0pfrFlqqcU4@mid.individual.net> |
| In reply to | #27416 |
Gerrit Heitsch: > On 3/11/20 5:02 PM, Bernd Laengerich wrote: >> Am 10.03.2020 um 18:06 schrieb Gerrit Heitsch: >> >>> Nur solange du noch an die Dateien kommst, die du dafür brauchst. >>> Sollten die >> >> Sicher, aber die erzeugten Images werden hier lokal gespeichert. >> >>> Problem. Wenn du es wirklich reproduzierbar willst, solltest du eine >>> komplette VM nehmen die passend aufgesetzt ist. Die dann für die >>> nötige Arbeit clonen. >> >> Das ist ja noch viel mehr Overhead und Komplexität als ein Container. > > Wieso? Die VM ist eine Datei. Nein, ist sie nicht. Die VM ist ein komplettes Betriebssystem. Nur weil das am Ende als Image in einer Datei gesichert werden kann, ist es nicht "nur eine Datei". -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2020-03-11 17:49 +0100 |
| Message-ID | <r4b8b0.4qo.1@stefan.msgid.phost.de> |
| In reply to | #27385 |
Am 10.03.2020 um 18:06 schrieb Gerrit Heitsch:
> On 3/9/20 10:11 PM, Bernd Laengerich wrote:
>> Am 09.03.2020 um 20:23 schrieb Gerrit Heitsch:
>>> Entwicklungssystem als Container? Wieso? Da schreibst du doch nur
>>> deinen Code.
>>
>> Wenn der Code auf 5 Plattformen mit 5 verschiedenen Compilern laufen
>> soll, binde ich mir nicht für jeden Entwickler 5 physische Rechner
>> dafür ans Bein. Dazu die verschiedenen Releasezweige mit
>> unterschiedlichen Bibliotheksständen. Das liegt alles als
>> Containerdefinition vor und hat den Vorteil, immer reproduzierbar
>> gleich zu sein.
>
> Nur solange du noch an die Dateien kommst, die du dafür brauchst.
> Sollten die mal aus dem Repository fliegen aus dem sie dein
> Containersetup laut der Definition zieht ('den alten Schrott braucht
> keiner mehr') bekommst du ein Problem.
Das Problem hast du bei allen externen Dependencies, und bei allem, was
du tust. Ein Debian 3 bekommst du aus offiziellen Paketquellen weder
aufgesetzt noch geupdated, und da ist egal, ob du aus den Paketen einen
Container, eine VM oder ein richtiges Eisen bestückst.
Ergo: externe Dependencies einsammeln und selbst archivieren.
> Wenn du es wirklich
> reproduzierbar willst, solltest du eine komplette VM nehmen die passend
> aufgesetzt ist. Die dann für die nötige Arbeit clonen.
Eine händisch zusammengeklickte VM ist nicht reproduzierbar im Sinne von
"dokumentiert, was drin ist", nur reproduzierbar im Sinne von "nimm halt
dieses handverlesene *.vdi, das tut meistens".
Es gibt Tools zum skriptgesteuerten Aufsetzen von VMs. Ich meine,
Vagrant wäre sowas. Aber da ist ein Docker-Container oder eine andere
Sandbox eben deutlich leichtgewichtiger. Mein Buildsystem braucht keinen
Kernel, keinen init, keinen sendmail, keinen cron.
> Solange du die Datei, die die VM darstellt, hast geht das und du bist
> von keinem anderen abhängig.
Das ist halt das Äquivalent zu "ich schmeiß das *.tex weg und hebe nur
das *.pdf auf". Manchmal ist das angebracht. Ich finde: meistens nicht.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2020-03-11 18:40 +0100 |
| Message-ID | <r4b7q6$sd5$1@news.bawue.net> |
| In reply to | #27420 |
On 3/11/20 5:49 PM, Stefan Reuther wrote:
> Am 10.03.2020 um 18:06 schrieb Gerrit Heitsch:
>> On 3/9/20 10:11 PM, Bernd Laengerich wrote:
>>> Am 09.03.2020 um 20:23 schrieb Gerrit Heitsch:
>>>> Entwicklungssystem als Container? Wieso? Da schreibst du doch nur
>>>> deinen Code.
>>>
>>> Wenn der Code auf 5 Plattformen mit 5 verschiedenen Compilern laufen
>>> soll, binde ich mir nicht für jeden Entwickler 5 physische Rechner
>>> dafür ans Bein. Dazu die verschiedenen Releasezweige mit
>>> unterschiedlichen Bibliotheksständen. Das liegt alles als
>>> Containerdefinition vor und hat den Vorteil, immer reproduzierbar
>>> gleich zu sein.
>>
>> Nur solange du noch an die Dateien kommst, die du dafür brauchst.
>> Sollten die mal aus dem Repository fliegen aus dem sie dein
>> Containersetup laut der Definition zieht ('den alten Schrott braucht
>> keiner mehr') bekommst du ein Problem.
>
> Das Problem hast du bei allen externen Dependencies, und bei allem, was
> du tust. Ein Debian 3 bekommst du aus offiziellen Paketquellen weder
> aufgesetzt noch geupdated, und da ist egal, ob du aus den Paketen einen
> Container, eine VM oder ein richtiges Eisen bestückst.
>
> Ergo: externe Dependencies einsammeln und selbst archivieren.
Muss man nur drank denken... Ich hab etwas gesucht aber nichts finden
können. Wie erstelle ich eigene base images für Docker? Wenn, dann will
ich für meine Container nicht von einem externen Server abhängig sein
von dem das von mir preferierte Image ohne Warnung verschwinden kann.
>> Wenn du es wirklich
>> reproduzierbar willst, solltest du eine komplette VM nehmen die passend
>> aufgesetzt ist. Die dann für die nötige Arbeit clonen.
>
> Eine händisch zusammengeklickte VM ist nicht reproduzierbar im Sinne von
> "dokumentiert, was drin ist", nur reproduzierbar im Sinne von "nimm halt
> dieses handverlesene *.vdi, das tut meistens".
Nun, bei Docker hast du deine Base Images, die du dann via Dockerfile
anpasst. Das ist nicht viel anders. 'Nimmst du Base image <X> und
änderst noch folgendes, dann geht das'. Hast du genau dokumentiert was
im Base Image drin ist?
> Es gibt Tools zum skriptgesteuerten Aufsetzen von VMs. Ich meine,
> Vagrant wäre sowas. Aber da ist ein Docker-Container oder eine andere
> Sandbox eben deutlich leichtgewichtiger. Mein Buildsystem braucht keinen
> Kernel, keinen init, keinen sendmail, keinen cron.
Den Kernel leiht es sich vom Hauptsystem. Was ist wenn der sich zu stark
ändert, z.B. durch ein Neuaufsetzen des Hostsystems?
Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Ulf Volmer <u.volmer@u-v.de> |
|---|---|
| Date | 2020-03-11 19:03 +0100 |
| Message-ID | <slrnr6ia0e.2p9.u.volmer@x2-5.u-v.de> |
| In reply to | #27422 |
Gerrit Heitsch <gerrit@laosinh.s.bawue.de> schrieb: > Muss man nur drank denken... Ich hab etwas gesucht aber nichts finden > können. Wie erstelle ich eigene base images für Docker? Wenn, dann will > ich für meine Container nicht von einem externen Server abhängig sein > von dem das von mir preferierte Image ohne Warnung verschwinden kann. Du erstellt Dir ein tar.gz mit dem passenden Inhalt (debootstrap und Co.) und wirfst das 'docker load' vor. Viele Grüße Ulf
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2020-03-12 18:46 +0100 |
| Message-ID | <r4e02e.430.1@stefan.msgid.phost.de> |
| In reply to | #27422 |
Am 11.03.2020 um 18:40 schrieb Gerrit Heitsch:
> On 3/11/20 5:49 PM, Stefan Reuther wrote:
>> Am 10.03.2020 um 18:06 schrieb Gerrit Heitsch:
>>> Nur solange du noch an die Dateien kommst, die du dafür brauchst.
>>> Sollten die mal aus dem Repository fliegen aus dem sie dein
>>> Containersetup laut der Definition zieht ('den alten Schrott braucht
>>> keiner mehr') bekommst du ein Problem.
>>
>> Das Problem hast du bei allen externen Dependencies, und bei allem, was
>> du tust. Ein Debian 3 bekommst du aus offiziellen Paketquellen weder
>> aufgesetzt noch geupdated, und da ist egal, ob du aus den Paketen einen
>> Container, eine VM oder ein richtiges Eisen bestückst.
>>
>> Ergo: externe Dependencies einsammeln und selbst archivieren.
>
> Muss man nur drank denken... Ich hab etwas gesucht aber nichts finden
> können. Wie erstelle ich eigene base images für Docker? Wenn, dann will
> ich für meine Container nicht von einem externen Server abhängig sein
> von dem das von mir preferierte Image ohne Warnung verschwinden kann.
Ich komme da mit relativ eingängigen Suchbegriffen zu
<https://docs.docker.com/develop/develop-images/baseimages/>.
>>> Wenn du es wirklich
>>> reproduzierbar willst, solltest du eine komplette VM nehmen die passend
>>> aufgesetzt ist. Die dann für die nötige Arbeit clonen.
>>
>> Eine händisch zusammengeklickte VM ist nicht reproduzierbar im Sinne von
>> "dokumentiert, was drin ist", nur reproduzierbar im Sinne von "nimm halt
>> dieses handverlesene *.vdi, das tut meistens".
>
> Nun, bei Docker hast du deine Base Images, die du dann via Dockerfile
> anpasst. Das ist nicht viel anders. 'Nimmst du Base image <X> und
> änderst noch folgendes, dann geht das'. Hast du genau dokumentiert was
> im Base Image drin ist?
Wenn man das richtig macht, stehen genau die Instruktionen zum Bauen des
Images im Dockerfile, also auch die oben genannten Änderungsanweisungen.
Man kann natürlich auch hinterher per Shell in das Image reingehen und
da Dateien editieren, so ist Docker aber nicht gedacht.
>> Es gibt Tools zum skriptgesteuerten Aufsetzen von VMs. Ich meine,
>> Vagrant wäre sowas. Aber da ist ein Docker-Container oder eine andere
>> Sandbox eben deutlich leichtgewichtiger. Mein Buildsystem braucht keinen
>> Kernel, keinen init, keinen sendmail, keinen cron.
>
> Den Kernel leiht es sich vom Hauptsystem. Was ist wenn der sich zu stark
> ändert, z.B. durch ein Neuaufsetzen des Hostsystems?
Der Linux-Kernel hat eine "don't break userspace" Policy, 20 Jahre alte
Binaries laufen normalerweise noch. Deswegen gibt es sowas wie 'stat'
und 'oldstat'. Das halte ich für ein kleineres Problem.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2020-03-12 19:15 +0100 |
| Message-ID | <r4du8d$se$1@news.bawue.net> |
| In reply to | #27466 |
On 3/12/20 6:46 PM, Stefan Reuther wrote:
> Am 11.03.2020 um 18:40 schrieb Gerrit Heitsch:
>> On 3/11/20 5:49 PM, Stefan Reuther wrote:
>>> Am 10.03.2020 um 18:06 schrieb Gerrit Heitsch:
>>>> Nur solange du noch an die Dateien kommst, die du dafür brauchst.
>>>> Sollten die mal aus dem Repository fliegen aus dem sie dein
>>>> Containersetup laut der Definition zieht ('den alten Schrott braucht
>>>> keiner mehr') bekommst du ein Problem.
>>>
>>> Das Problem hast du bei allen externen Dependencies, und bei allem, was
>>> du tust. Ein Debian 3 bekommst du aus offiziellen Paketquellen weder
>>> aufgesetzt noch geupdated, und da ist egal, ob du aus den Paketen einen
>>> Container, eine VM oder ein richtiges Eisen bestückst.
>>>
>>> Ergo: externe Dependencies einsammeln und selbst archivieren.
>>
>> Muss man nur drank denken... Ich hab etwas gesucht aber nichts finden
>> können. Wie erstelle ich eigene base images für Docker? Wenn, dann will
>> ich für meine Container nicht von einem externen Server abhängig sein
>> von dem das von mir preferierte Image ohne Warnung verschwinden kann.
>
> Ich komme da mit relativ eingängigen Suchbegriffen zu
> <https://docs.docker.com/develop/develop-images/baseimages/>.
Komisch, sonst finde ich bei Google alles mögliche, diesmal hat es nicht
geklappt. Danke.
>>>> Wenn du es wirklich
>>>> reproduzierbar willst, solltest du eine komplette VM nehmen die passend
>>>> aufgesetzt ist. Die dann für die nötige Arbeit clonen.
>>>
>>> Eine händisch zusammengeklickte VM ist nicht reproduzierbar im Sinne von
>>> "dokumentiert, was drin ist", nur reproduzierbar im Sinne von "nimm halt
>>> dieses handverlesene *.vdi, das tut meistens".
>>
>> Nun, bei Docker hast du deine Base Images, die du dann via Dockerfile
>> anpasst. Das ist nicht viel anders. 'Nimmst du Base image <X> und
>> änderst noch folgendes, dann geht das'. Hast du genau dokumentiert was
>> im Base Image drin ist?
>
> Wenn man das richtig macht, stehen genau die Instruktionen zum Bauen des
> Images im Dockerfile, also auch die oben genannten Änderungsanweisungen.
Ich meine damit, wenn man durchgehend Kontrolle haben will, dann muss
man auch genau kontrollieren was im Image ist welches rechts vom 'FROM'
im Dockerfile steht. Einfach eine laufende Maschine in ein Image
konvertieren ist so ca. dasselbe wie mein Vorschlag eine VM zu sichern
und immer zu klonen.
> Man kann natürlich auch hinterher per Shell in das Image reingehen und
> da Dateien editieren, so ist Docker aber nicht gedacht.
Wenn da drin was sinnvolles passieren soll musst du den Kram im
Container aber irgendwie konfigurieren. Wirklich für jede Configdatei
die Datei von extern reinmappen?
> Der Linux-Kernel hat eine "don't break userspace" Policy, 20 Jahre alte
> Binaries laufen normalerweise noch. Deswegen gibt es sowas wie 'stat'
> und 'oldstat'. Das halte ich für ein kleineres Problem.
Das kommt hin. Ich hab hier noch ein 'xv' Binary was, meiner Erinnerung
nach, von einer RedHat 5.x stammt, also Ende der 90er. Bisher habe ich
das immer noch zum Laufen bekommen, auch nach dem Wechsel auf 64 Bit.
Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2020-03-13 18:20 +0100 |
| Message-ID | <r4giu9.1og.1@stefan.msgid.phost.de> |
| In reply to | #27469 |
Am 12.03.2020 um 19:15 schrieb Gerrit Heitsch: > On 3/12/20 6:46 PM, Stefan Reuther wrote: >> Wenn man das richtig macht, stehen genau die Instruktionen zum Bauen des >> Images im Dockerfile, also auch die oben genannten Änderungsanweisungen. > > Ich meine damit, wenn man durchgehend Kontrolle haben will, dann muss > man auch genau kontrollieren was im Image ist welches rechts vom 'FROM' > im Dockerfile steht. Einfach eine laufende Maschine in ein Image > konvertieren ist so ca. dasselbe wie mein Vorschlag eine VM zu sichern > und immer zu klonen. > >> Man kann natürlich auch hinterher per Shell in das Image reingehen und >> da Dateien editieren, so ist Docker aber nicht gedacht. > > Wenn da drin was sinnvolles passieren soll musst du den Kram im > Container aber irgendwie konfigurieren. Wirklich für jede Configdatei > die Datei von extern reinmappen? Ja, genau so. Am Ende geht es darum, alle Dinge, die nötig sind, um den Dienst gängig zu machen, zu skripten, so dass kein Eingriff eines denkenden Wesens mehr nötig ist. Und das hat mein Entwicklerleben unglaublich erleichtert. Dass man die Kommandozeilen zum Übersetzen eines Programms in ein Makefile schreibt, ist ein alter Hut. Aber die Kommandozeile für das vorgeschaltete configure oder cmake, überhaupt die Installation des Compilers und der Dependencies davor, war halt lange Handarbeit. Beim Umzug auf ein neues System dann die Unsicherheit, ob der noch gegen die richtigen Library-Versionen linkt usw. Seit meine Buildprozesse in ein Sandbox-Tool verpackt sind, ist das alles ganz einfach: ein kurzes Kommando baut mir das Service-Image zusammen, das ich nur noch auf das Zielsystem schieben muss. Und wenn ich so ein Skript habe, kann ich auch Experimente machen: was wäre, wenn ich das mit einem brandneuen gcc, libc, openssl compiliere? Wenn's klappt, behalt ich's, sonst verwerf ich's, und ich riskiere dabei nicht, mit einem vergessenen --prefix o.ä. mein Hostsystem zu zerschießen. Stefan
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2020-03-13 08:07 +0100 |
| Message-ID | <hd0pqdFluvlU1@mid.individual.net> |
| In reply to | #27422 |
Gerrit Heitsch: > On 3/11/20 5:49 PM, Stefan Reuther wrote: [...] >> Ergo: externe Dependencies einsammeln und selbst archivieren. > > Muss man nur drank denken... Ich hab etwas gesucht aber nichts finden > können. Wie erstelle ich eigene base images für Docker? Wenn, dann will > ich für meine Container nicht von einem externen Server abhängig sein > von dem das von mir preferierte Image ohne Warnung verschwinden kann. <https://docs.docker.com/develop/develop-images/baseimages/> [...] >> Eine händisch zusammengeklickte VM ist nicht reproduzierbar im Sinne von >> "dokumentiert, was drin ist", nur reproduzierbar im Sinne von "nimm halt >> dieses handverlesene *.vdi, das tut meistens". > > Nun, bei Docker hast du deine Base Images, die du dann via Dockerfile > anpasst. Das ist nicht viel anders. 'Nimmst du Base image <X> und > änderst noch folgendes, dann geht das'. Hast du genau dokumentiert was > im Base Image drin ist? Ja, sowas geht. Siehe auch <https://github.com/docker-library/hello-world/> -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2020-03-10 18:00 +0100 |
| Message-ID | <r48kjv.4uc.1@stefan.msgid.phost.de> |
| In reply to | #27366 |
Am 09.03.2020 um 18:28 schrieb Gerrit Heitsch: > On 3/9/20 5:52 PM, Stefan Reuther wrote: >> Am 08.03.2020 um 13:18 schrieb Gerrit Heitsch: >>> On 3/8/20 10:25 AM, Stefan Reuther wrote: >>>> Und dann haben wir festgestellt, dass das mit den *.so ganz schön >>>> kompliziert ist und manche Programme eben auf einer alten *.so >>>> bestehen. >>> >>> Solche Programme sind schlecht programmiert und sollten ersetzt bzw. >>> debugged werden. Warum? Sicherheitslücken in den Libraries z.B. Auch in >>> einem Container willst du keinen von aussen erreichbaren Service haben >>> der eine veraltete .so benutzt, also musst du da sowieso ran. >> >> Nicht jede Software ist automatisch ein "von außen erreichbarer Service". > > Dazu werden Container aber typischweise benutzt. Dein Einsatz als > Buildsystem ist da eher eine Ausnahme. Definiere "typischerweise". In meinem Umfeld ist der Einsatz als Buildsystem die Regel. Die ganzen fancy tools (Jira usw.) außenrum sind allerdings soweit ich weiß auch containert. >>> Weil Spectre, Meltdown usw. auf demselben Eisen sehr gut funktionieren, >>> aber nicht mehr wenn es zwei (oder mehr) sind. Und das setzt voraus, daß >>> deine Trennschicht keine weiteren Löcher hat. >> >> Wenn mir alle Partitionen des Eisens gehören, ist das nicht so relevant. > > Dir ja. Aber wie sieht es bei der großen Mehrheit aus? Auch hier gehören uns die kompletten Eisen. >>> Man könnte auch fragen warum man Prozesse voneinander abschotten muss >>> und eine MMU braucht wenn Multitasking auch ohne geht (Beispiel: >>> AmigaOS). >> >> Richtig. Man muss doch einfach nur fehlerfreie Programme schreiben. >> >> (Das ist der Grund, warum ich das einsetze, was man heute Microservices >> nennt: ich trau auch meinem selbstgebauten Code nicht.) > > Ah, Microservices... Also nochmal mehr Komplexität. Was kann dabei schon > schiefgehen? Man kann es "Microservices" nennen und verdammen, so wie man alles Neue verdammt. Oder man nennt es "Unix-way of programming": "do one thing and do it well". Ein Zoo aus Microservices ist auch nichts viel anders als ein Zoo aus vielen kleinen Utilities in einer Pipeline. Oder eine Handvoll FastCGI-Prozesse hinter einem Webserver. Oder ein Postfix, das u.a. aus Sicherheitsgründen in ein halbes Dutzend Daemons zerlegt wurde - und das hat nun bei weitem keinen schlechten Ruf. Microservices sind nur ein neuer Name für ein altes Konzept. Und allemal besser, als einen fetten monolithischen Servlet-Container hinzustellen, den man einmal täglich wegen out-of-memory rebooten muss. Stefan
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2020-03-10 18:24 +0100 |
| Message-ID | <r48ifh$oou$1@news.bawue.net> |
| In reply to | #27384 |
On 3/10/20 6:00 PM, Stefan Reuther wrote: > Am 09.03.2020 um 18:28 schrieb Gerrit Heitsch: >> On 3/9/20 5:52 PM, Stefan Reuther wrote: >>> Am 08.03.2020 um 13:18 schrieb Gerrit Heitsch: >>>> On 3/8/20 10:25 AM, Stefan Reuther wrote: >>>>> Und dann haben wir festgestellt, dass das mit den *.so ganz schön >>>>> kompliziert ist und manche Programme eben auf einer alten *.so >>>>> bestehen. >>>> >>>> Solche Programme sind schlecht programmiert und sollten ersetzt bzw. >>>> debugged werden. Warum? Sicherheitslücken in den Libraries z.B. Auch in >>>> einem Container willst du keinen von aussen erreichbaren Service haben >>>> der eine veraltete .so benutzt, also musst du da sowieso ran. >>> >>> Nicht jede Software ist automatisch ein "von außen erreichbarer Service". >> >> Dazu werden Container aber typischweise benutzt. Dein Einsatz als >> Buildsystem ist da eher eine Ausnahme. > > Definiere "typischerweise". In meinem Umfeld ist der Einsatz als > Buildsystem die Regel. Die ganzen fancy tools (Jira usw.) außenrum sind > allerdings soweit ich weiß auch containert. Taugt Jira was? Deren Webseite enthält mir zuviele Buzzwords und ist damit verdächtig. Und ein Repository 'Bitbucket' zu nennen... Der Bitbucket ist immer noch /dev/null und dem vertraue ich nur Zeug an was weg kann. > Microservices sind nur ein neuer Name für ein altes Konzept. Und allemal > besser, als einen fetten monolithischen Servlet-Container hinzustellen, > den man einmal täglich wegen out-of-memory rebooten muss. Wenn man das muss, dann muss man auch den Programmierer mit Bugreports zuwerfen bis er den Fehler findet. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2020-03-10 18:56 +0100 |
| Message-ID | <hcq2n6F9cm2U1@mid.individual.net> |
| In reply to | #27387 |
Am 10.03.20 um 18:24 schrieb Gerrit Heitsch: > Taugt Jira was? Deren Webseite enthält mir zuviele Buzzwords und ist > damit verdächtig. Es ist grauenhaft. Alles andere mit der gleichen Funktion allerdings auch. Eher mehr. Hanno -- Nie irgendwas von Ulf Kutzner glauben, insbesondere Zitate immer im Original und Kontext nachlesen. Er versucht, durch Zitatefälschung Strohmann-Argumente zu konstruieren.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2020-03-11 17:59 +0100 |
| Message-ID | <r4b8u9.44o.1@stefan.msgid.phost.de> |
| In reply to | #27387 |
Am 10.03.2020 um 18:24 schrieb Gerrit Heitsch: > On 3/10/20 6:00 PM, Stefan Reuther wrote: >> Am 09.03.2020 um 18:28 schrieb Gerrit Heitsch: >>> On 3/9/20 5:52 PM, Stefan Reuther wrote: >>>> Nicht jede Software ist automatisch ein "von außen erreichbarer >>>> Service". >>> >>> Dazu werden Container aber typischweise benutzt. Dein Einsatz als >>> Buildsystem ist da eher eine Ausnahme. >> >> Definiere "typischerweise". In meinem Umfeld ist der Einsatz als >> Buildsystem die Regel. Die ganzen fancy tools (Jira usw.) außenrum sind >> allerdings soweit ich weiß auch containert. > > Taugt Jira was? Deren Webseite enthält mir zuviele Buzzwords und ist > damit verdächtig. Jira führt an unserer Dreckstool-Liste mit mehreren Größenordnungen Vorsprung (vor Outlook, SAP, Word, Apple-Produkten, ...). Man sagt ihm nach, dass es viel kann. Das führt dann dazu, dass Leute mit Schulterklappen Anweisungen erteilen, es so einzurichten, dass es ihre Workflows abbildet (weil: das muss es ja können), und die zahlenmäßig überlegene Schar von Leuten ohne Schulterklappen drölfzig sinnlose Felder ausfüllen müssen, aber für ihre eigenen Workflows Keywords recyceln müssen. Ich durfte mich auch schon belehren lassen, dass es sich nicht geziemt, seitenlange Kommentare mit Logzitaten und Analysen an Fehlertickets zu schreiben, das wird so unübersichtlich. Ach so, und niemand verkackt Rich-Text-Editoren so gut wie Atlassian. Immerhin hat's eine dokumentierte API. Mantis war irgendwie einfacher. Hatte aber auch keinen Rich-Text-Editor. Und generiert keine 500-Zeilen-Exception-Dumps. >> Microservices sind nur ein neuer Name für ein altes Konzept. Und allemal >> besser, als einen fetten monolithischen Servlet-Container hinzustellen, >> den man einmal täglich wegen out-of-memory rebooten muss. > > Wenn man das muss, dann muss man auch den Programmierer mit Bugreports > zuwerfen bis er den Fehler findet. Tja, in einer idealen Welt... In einer realen Welt ist es manchmal kosteneffizienter, zu rebooten. Es gab da mal die Story von High-Frequency-Trading-Systemen in Java. Die bekommen ausreichend RAM, um über einen Börsentag zu kommen, und werden dann rebootet. Garbage Collection würde die Latenz versauen. Stefan
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2020-03-08 22:03 +0100 |
| Message-ID | <hcl4siF88qaU1@mid.individual.net> |
| In reply to | #27323 |
Am 08.03.20 um 10:25 schrieb Stefan Reuther: [...] > Dann wurde uns zu aufwändig, immer die selben *.o angeben zu müssen und > haben die Libraries erfunden und die *.o in *.a und später *.so gepackt. > > Da sind wir ein paar Jahre geblieben. > > Und dann haben wir festgestellt, dass das mit den *.so ganz schön > kompliziert ist und manche Programme eben auf einer alten *.so bestehen. > Oder dass es unter Debian 10 immer noch nicht möglich ist, ein Binary zu > bauen, das unter Debian 7 läuft, andersherum aber schon (während das > unter Windows 10 vs. Windows 7 ein eher kleineres Problem ist). Also > wurden Container erfunden. https://blog.fefe.de/?ts=a0d07bd8 Hanno -- Nie irgendwas von Ulf Kutzner glauben, insbesondere Zitate immer im Original und Kontext nachlesen. Er versucht, durch Zitatefälschung Strohmann-Argumente zu konstruieren.
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2020-03-08 21:59 +0100 |
| Message-ID | <hcl4lcF86ksU2@mid.individual.net> |
| In reply to | #27316 |
Am 07.03.20 um 23:01 schrieb Ulf Volmer: >> Ein Docker-Container benutzt aber denselben Kernel wie der Rest des >> Systems. Es ist also kein OS im OS. Du benutzt nur ein paar Features im >> Kernel den Kram von einander zu isolieren (und hoffst, daß das auch >> wirklich zu 100% funktioniert). > > Der Kernel bietet also verschiedene Möglichkeiten (Namespaces), um > Prozesse voneinander zu isolieren. Warum möchtest Du das Feature > gerade für's Netzwerk nicht benutzen? Wenn ich ein Feature nutzen möchte, werde ich das so konfigurieren. Wenn ich es nicht nutzen möchte, aber das dennoch so reingewürgt bekomme, finde ich das etwas doof. Hanno -- Nie irgendwas von Ulf Kutzner glauben, insbesondere Zitate immer im Original und Kontext nachlesen. Er versucht, durch Zitatefälschung Strohmann-Argumente zu konstruieren.
[toc] | [prev] | [next] | [standalone]
| From | Dennis Grevenstein <dennis.grevenstein@gmail.com> |
|---|---|
| Date | 2020-03-07 19:19 +0000 |
| Message-ID | <r40s4v$kri$1@akk3-dmz.akk.uni-karlsruhe.de> |
| In reply to | #27305 |
Arno Welzel <usenet@arnowelzel.de> wrote: > > Aber für manche Leute ist ja auch die Nutzung von cgroups in systemd > böse, weil das nicht die reine Lehre eines BSD-kompatiblen Init-Systems > entspricht Ähm... Ich habe bisher gedacht systemd ist böse, weil es kein SystemV init mehr ist. Bin ich jetzt schon solange aus dem Geschäft raus, dass ich da was esentielles nicht verstanden habe? gruss, Dennis -- "I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser gate. All those moments will be lost in time, like tears in rain."
[toc] | [prev] | [next] | [standalone]
| From | Michael Bäuerle <michael.baeuerle@gmx.net> |
|---|---|
| Date | 2020-03-08 08:48 +0000 |
| Subject | systemd (was: unix5 auf PiDP11) |
| Message-ID | <AABeZLFbu5QAAAt7.A1.flnews@Server4.micha.freeshell.org> |
| In reply to | #27311 |
Dennis Grevenstein wrote: > Arno Welzel <usenet@arnowelzel.de> wrote: > > > > Aber für manche Leute ist ja auch die Nutzung von cgroups in systemd > > böse, weil das nicht die reine Lehre eines BSD-kompatiblen Init-Systems > > entspricht > > Ähm... Ich habe bisher gedacht systemd ist böse, weil es kein SystemV > init mehr ist. Bin ich jetzt schon solange aus dem Geschäft raus, dass > ich da was esentielles nicht verstanden habe? Das Problem hat wenig bis nichts mit dem Teil von systemd zu tun, der das init ersetzt (egal welches). Das Problem an systemd ist, dass da noch viele andere Komponenten angedockt sind, die alleine (bzw. mit einem anderen init) nicht lauffähig sind. Diese gesamte Konstruktion bietet diverse APIs an, mit denen Programme darauf zugreifen können. Auf diese Weise ist es möglich, dass Abhängigkeiten im System entstehen, die vom init bis zum GUI reichen.
[toc] | [prev] | [next] | [standalone]
Page 3 of 14 — ← Prev page 1 2 [3] 4 5 … 14 Next page →
Back to top | Article view | de.alt.folklore.computer
csiph-web