Groups > ger.ct > #323417 > unrolled thread

Programm stoppen/einfrieren wenn nicht im Fokus

Started by	Gert Bass <me@privacy.net>
First post	2017-09-26 17:50 -0700
Last post	2017-09-30 15:52 -0700
Articles	20 on this page of 132 — 24 participants

Back to article view | Back to ger.ct

  Programm stoppen/einfrieren wenn nicht im Fokus Gert Bass <me@privacy.net> - 2017-09-26 17:50 -0700
    Re: Programm stoppen/einfrieren wenn nicht im Fokus Dr. Joachim Neudert <neudert@5sl.org> - 2017-09-27 05:38 +0000
      Re: Programm stoppen/einfrieren wenn nicht im Fokus Shinji Ikari <shinji@gmx.net> - 2017-09-27 09:22 +0200
        Re: Programm stoppen/einfrieren wenn nicht im Fokus "Dr. Joachim Neudert" <neudert@5sl.org> - 2017-09-27 09:39 +0200
          Re: Programm stoppen/einfrieren wenn nicht im Fokus "Dr. Joachim Neudert" <neudert@5sl.org> - 2017-09-27 09:56 +0200
            Re: Programm stoppen/einfrieren wenn nicht im Fokus spamfalle2@arcor.de (Marc Stibane) - 2017-09-27 13:16 +0200
              Re: Programm stoppen/einfrieren wenn nicht im Fokus Dr. Joachim Neudert <neudert@5sl.org> - 2017-09-27 12:04 +0000
                Re: Programm stoppen/einfrieren wenn nicht im Fokus Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-09-27 14:13 +0200
                  Re: Programm stoppen/einfrieren wenn nicht im Fokus Shinji Ikari <shinji@gmx.net> - 2017-09-27 15:39 +0200
                    Re: Programm stoppen/einfrieren wenn nicht im Fokus Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-09-27 15:45 +0200
                    Re: Programm stoppen/einfrieren wenn nicht im Fokus Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2017-09-27 13:53 +0000
                      Re: Programm stoppen/einfrieren wenn nicht im Fokus Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-09-27 16:13 +0200
                        Re: Programm stoppen/einfrieren wenn nicht im Fokus Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2017-09-27 14:25 +0000
                          Re: Programm stoppen/einfrieren wenn nicht im Fokus Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-09-27 16:35 +0200
                            Re: Programm stoppen/einfrieren wenn nicht im Fokus Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2017-09-27 16:11 +0000
                              Re: Programm stoppen/einfrieren wenn nicht im Fokus Daniel Pache <daniel.pache@gmx.net> - 2017-09-28 17:22 +0200
                        Re: Programm stoppen/einfrieren wenn nicht im Fokus Ruediger Lahl <ruediger.lahl@gmx.de> - 2017-09-27 16:46 +0200
                        Re: Programm stoppen/einfrieren wenn nicht im Fokus Gert Bass <me@privacy.net> - 2017-09-28 14:31 -0700
                          Re: Programm stoppen/einfrieren wenn nicht im Fokus Dr. Joachim Neudert <neudert@5sl.org> - 2017-09-29 04:40 +0000
                          Re: Programm stoppen/einfrieren wenn nicht im Fokus Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-09-29 08:25 +0200
                            Re: Programm stoppen/einfrieren wenn nicht im Fokus "Dr. Joachim Neudert" <neudert@5sl.org> - 2017-09-29 08:42 +0200
                              Re: Programm stoppen/einfrieren wenn nicht im Fokus Gert Bass <me@privacy.net> - 2017-09-29 19:33 -0700
                            Re: Programm stoppen/einfrieren wenn nicht im Fokus Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2017-09-29 07:40 +0000
                            Re: Programm stoppen/einfrieren wenn nicht im Fokus Gert Bass <me@privacy.net> - 2017-09-29 19:27 -0700
                          Re: Programm stoppen/einfrieren wenn nicht im Fokus Ruediger Lahl <ruediger.lahl@gmx.de> - 2017-09-29 17:36 +0200
                          Re: Programm stoppen/einfrieren wenn nicht im Fokus Wolfgang Kynast <wky@gmx.de> - 2017-09-29 18:11 +0200
                            Re: Programm stoppen/einfrieren wenn nicht im Fokus Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2017-09-29 18:50 +0000
                              Re: Programm stoppen/einfrieren wenn nicht im Fokus Wolfgang Kynast <wky@gmx.de> - 2017-09-29 22:12 +0200
                              Re: Programm stoppen/einfrieren wenn nicht im Fokus Michael Bode <m.g.bode@web.de> - 2017-09-30 00:18 +0200
                                Re: Programm stoppen/einfrieren wenn nicht im Fokus "Joachim Dr. Neudert" <neudert@5sl.org> - 2017-09-30 07:44 +0200
                                  Re: Programm stoppen/einfrieren wenn nicht im Fokus Ruediger Lahl <ruediger.lahl@gmx.de> - 2017-09-30 12:34 +0200
                                    Re: Programm stoppen/einfrieren wenn nicht im Fokus Mike Grantz <rotfl@invalid.hahahahahahahahh.com> - 2017-09-30 12:52 +0200
                                    Re: Programm stoppen/einfrieren wenn nicht im Fokus Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2017-09-30 11:33 +0000
                                      Re: Programm stoppen/einfrieren wenn nicht im Fokus Mike Grantz <rotfl@invalid.hahahahahahahahh.com> - 2017-09-30 13:50 +0200
                                        Re: Programm stoppen/einfrieren wenn nicht im Fokus Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2017-09-30 15:18 +0000
                            Re: Programm stoppen/einfrieren wenn nicht im Fokus Gert Bass <me@privacy.net> - 2017-09-29 19:21 -0700
                              Re: Programm stoppen/einfrieren wenn nicht im Fokus Mike Grantz <rotfl@invalid.hahahahahahahahh.com> - 2017-09-30 12:57 +0200
                                Re: Programm stoppen/einfrieren wenn nicht im Fokus Gert Bass <me@privacy.net> - 2017-09-30 15:05 -0700
                                  Re: Programm stoppen/einfrieren wenn nicht im Fokus Mike Grantz <rotfl@invalid.hahahahahahahahh.com> - 2017-10-01 04:09 +0200
                                    Re: Programm stoppen/einfrieren wenn nicht im Fokus Gert Bass <me@privacy.net> - 2017-10-01 00:33 -0700
                                      Re: Programm stoppen/einfrieren wenn nicht im Fokus Mike Grantz <rotfl@invalid.hahahahahahahahh.com> - 2017-10-01 09:47 +0200
                                        Re: Programm stoppen/einfrieren wenn nicht im Fokus Gert Bass <me@privacy.net> - 2017-10-01 19:22 -0700
                              Re: Programm stoppen/einfrieren wenn nicht im Fokus Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de> - 2017-09-30 13:00 +0200
                      Re: Programm stoppen/einfrieren wenn nicht im Fokus Shinji Ikari <shinji@gmx.net> - 2017-09-28 16:04 +0200
                        Re: Programm stoppen/einfrieren wenn nicht im Fokus "Dr. Joachim Neudert" <neudert@5sl.org> - 2017-09-28 16:51 +0200
                          Re: Programm stoppen/einfrieren wenn nicht im Fokus Dietz Proepper <dietz-news@rotfl.franken.de> - 2017-09-29 08:34 +0200
                        Re: Programm stoppen/einfrieren wenn nicht im Fokus Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2017-09-28 16:52 +0000
                          Re: Programm stoppen/einfrieren wenn nicht im Fokus Shinji Ikari <shinji@gmx.net> - 2017-09-28 21:40 +0200
                            Re: Programm stoppen/einfrieren wenn nicht im Fokus Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2017-09-28 21:27 +0000
                              Re: Programm stoppen/einfrieren wenn nicht im Fokus Shinji Ikari <shinji@gmx.net> - 2017-09-28 23:58 +0200
                                Re: Programm stoppen/einfrieren wenn nicht im Fokus Gert Bass <me@privacy.net> - 2017-09-28 16:33 -0700
                                  Re: Programm stoppen/einfrieren wenn nicht im Fokus Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2017-09-29 06:27 +0000
                                  Re: Programm stoppen/einfrieren wenn nicht im Fokus Shinji Ikari <shinji@gmx.net> - 2017-09-29 08:58 +0200
                                    Re: Programm stoppen/einfrieren wenn nicht im Fokus Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2017-09-29 07:38 +0000
                                      Re: Programm stoppen/einfrieren wenn nicht im Fokus Shinji Ikari <shinji@gmx.net> - 2017-09-29 11:09 +0200
                                        Re: Programm stoppen/einfrieren wenn nicht im Fokus "Dr. Joachim Neudert" <neudert@5sl.org> - 2017-09-29 11:14 +0200
                                          Re: Programm stoppen/einfrieren wenn nicht im Fokus "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2017-09-29 12:24 +0200
                                          Re: Programm stoppen/einfrieren wenn nicht im Fokus Gert Bass <me@privacy.net> - 2017-09-29 19:56 -0700
                                            Re: Programm stoppen/einfrieren wenn nicht im Fokus "Joachim Dr. Neudert" <neudert@5sl.org> - 2017-09-30 07:52 +0200
                                            Re: Programm stoppen/einfrieren wenn nicht im Fokus Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-09-30 09:15 +0200
                                              Re: Programm stoppen/einfrieren wenn nicht im Fokus Ruediger Lahl <ruediger.lahl@gmx.de> - 2017-09-30 12:40 +0200
                                                Re: Programm stoppen/einfrieren wenn nicht im Fokus Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-09-30 14:22 +0200
                                                  Re: Programm stoppen/einfrieren wenn nicht im Fokus Mike Grantz <rotfl@invalid.hahahahahahahahh.com> - 2017-09-30 14:24 +0200
                                                    Re: Programm stoppen/einfrieren wenn nicht im Fokus Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-09-30 14:28 +0200
                                              Re: Programm stoppen/einfrieren wenn nicht im Fokus Mike Grantz <rotfl@invalid.hahahahahahahahh.com> - 2017-09-30 13:30 +0200
                                                Re: Programm stoppen/einfrieren wenn nicht im Fokus Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-09-30 14:23 +0200
                                                  Re: Programm stoppen/einfrieren wenn nicht im Fokus Mike Grantz <rotfl@invalid.hahahahahahahahh.com> - 2017-09-30 14:25 +0200
                                        Re: Programm stoppen/einfrieren wenn nicht im Fokus Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2017-09-29 15:46 +0000
                                          Re: Programm stoppen/einfrieren wenn nicht im Fokus Shinji Ikari <shinji@gmx.net> - 2017-09-30 03:55 +0200
                                  Re: Programm stoppen/einfrieren wenn nicht im Fokus Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de> - 2017-09-29 12:26 +0200
                                    Re: Programm stoppen/einfrieren wenn nicht im Fokus Lothar Frings <Lothar.Frings@gmx.de> - 2017-09-29 03:32 -0700
                                    Re: Programm stoppen/einfrieren wenn nicht im Fokus Frank Klingenhoefer <frank.private@t-online.de> - 2017-09-29 13:15 +0200
                                    Re: Programm stoppen/einfrieren wenn nicht im Fokus Gert Bass <me@privacy.net> - 2017-09-29 20:07 -0700
                                      Re: Programm stoppen/einfrieren wenn nicht im Fokus Ruediger Lahl <ruediger.lahl@gmx.de> - 2017-09-30 12:43 +0200
                                      Re: Programm stoppen/einfrieren wenn nicht im Fokus Wolfgang Kynast <wky@gmx.de> - 2017-09-30 13:10 +0200
                                      Re: Programm stoppen/einfrieren wenn nicht im Fokus Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de> - 2017-09-30 13:21 +0200
                                        Re: Programm stoppen/einfrieren wenn nicht im Fokus Gert Bass <me@privacy.net> - 2017-09-30 15:12 -0700
                                Re: Programm stoppen/einfrieren wenn nicht im Fokus Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2017-09-29 06:23 +0000
                                  Re: Programm stoppen/einfrieren wenn nicht im Fokus Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2017-09-29 21:19 +0200
                                    Re: Programm stoppen/einfrieren wenn nicht im Fokus Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-09-29 21:35 +0200
                                      Re: Programm stoppen/einfrieren wenn nicht im Fokus Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2017-09-29 22:13 +0200
                                        Re: Programm stoppen/einfrieren wenn nicht im Fokus Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-09-29 23:07 +0200
                                          Re: Programm stoppen/einfrieren wenn nicht im Fokus Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2017-09-30 00:30 +0200
                                        Re: Programm stoppen/einfrieren wenn nicht im Fokus spamfalle2@arcor.de (Marc Stibane) - 2017-10-01 14:29 +0200
                                          Re: Programm stoppen/einfrieren wenn nicht im Fokus Dietz Proepper <dietz-news@rotfl.franken.de> - 2017-10-01 16:21 +0200
                                          Re: Programm stoppen/einfrieren wenn nicht im Fokus Hermann Riemann <nospam.ng@hermann-riemann.de> - 2017-10-02 04:41 +0200
                                            Re: Programm stoppen/einfrieren wenn nicht im Fokus Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de> - 2017-10-02 13:26 +0200
                                              Re: Programm stoppen/einfrieren wenn nicht im Fokus Andreas Karrer <ak-7a@gmx.ch> - 2017-10-02 13:59 +0000
                                      Re: Programm stoppen/einfrieren wenn nicht im Fokus Wolfgang Kynast <wky@gmx.de> - 2017-09-29 22:16 +0200
                                      Re: Programm stoppen/einfrieren wenn nicht im Fokus Hermann Riemann <nospam.ng@hermann-riemann.de> - 2017-10-01 16:11 +0200
                                Re: Programm stoppen/einfrieren wenn nicht im Fokus Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-09-29 08:28 +0200
                                Re: Programm stoppen/einfrieren wenn nicht im Fokus Dietz Proepper <dietz-news@rotfl.franken.de> - 2017-09-29 08:42 +0200
                              Re: Programm stoppen/einfrieren wenn nicht im Fokus Dietz Proepper <dietz-news@rotfl.franken.de> - 2017-09-29 08:37 +0200
                                Re: Programm stoppen/einfrieren wenn nicht im Fokus Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2017-09-29 10:28 +0000
                    Re: Programm stoppen/einfrieren wenn nicht im Fokus "Dr. Joachim Neudert" <neudert@5sl.org> - 2017-09-27 15:53 +0200
                  Re: Programm stoppen/einfrieren wenn nicht im Fokus "Dr. Joachim Neudert" <neudert@5sl.org> - 2017-09-27 15:48 +0200
          Re: Programm stoppen/einfrieren wenn nicht im Fokus Shinji Ikari <shinji@gmx.net> - 2017-09-27 10:05 +0200
            Re: Programm stoppen/einfrieren wenn nicht im Fokus "Dr. Joachim Neudert" <neudert@5sl.org> - 2017-09-27 10:24 +0200
          Re: Programm stoppen/einfrieren wenn nicht im Fokus Wolfgang Kynast <wky@gmx.de> - 2017-09-27 12:43 +0200
        Re: Programm stoppen/einfrieren wenn nicht im Fokus spamfalle2@arcor.de (Marc Stibane) - 2017-09-27 13:16 +0200
          Re: Programm stoppen/einfrieren wenn nicht im Fokus Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-09-27 13:35 +0200
            Re: Programm stoppen/einfrieren wenn nicht im Fokus Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de> - 2017-09-27 17:06 +0200
            Re: Programm stoppen/einfrieren wenn nicht im Fokus spamfalle2@arcor.de (Marc Stibane) - 2017-09-27 22:57 +0200
      Re: Programm stoppen/einfrieren wenn nicht im Fokus Jörg Tewes <jogi1964@gmx.net> - 2017-09-27 21:26 +0200
        Re: Programm stoppen/einfrieren wenn nicht im Fokus "M. Schmidt" <nntp@nurfuerspam.de> - 2017-09-28 16:30 +0000
    Re: Programm stoppen/einfrieren wenn nicht im Fokus Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2017-09-27 09:43 +0200
      Re: Programm stoppen/einfrieren wenn nicht im Fokus Herwig AQSR <herwig.huener@t-online.de> - 2017-09-27 03:38 -0700
      Re: Programm stoppen/einfrieren wenn nicht im Fokus Gert Bass <me@privacy.net> - 2017-09-28 14:01 -0700
    Re: Programm stoppen/einfrieren wenn nicht im Fokus Daniel Pache <daniel.pache@gmx.net> - 2017-09-27 11:01 +0200
      Re: Programm stoppen/einfrieren wenn nicht im Fokus Gert Bass <me@privacy.net> - 2017-09-28 14:03 -0700
    Re: Programm stoppen/einfrieren wenn nicht im Fokus Shinji Ikari <shinji@gmx.net> - 2017-09-27 11:09 +0200
    Re: Programm stoppen/einfrieren wenn nicht im Fokus Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de> - 2017-09-27 11:20 +0200
    Re: Programm stoppen/einfrieren wenn nicht im Fokus Shinji Ikari <shinji@gmx.net> - 2017-09-27 11:34 +0200
      Re: Programm stoppen/einfrieren wenn nicht im Fokus "Dr. Joachim Neudert" <neudert@5sl.org> - 2017-09-27 11:50 +0200
        Re: Programm stoppen/einfrieren wenn nicht im Fokus Shinji Ikari <shinji@gmx.net> - 2017-09-27 12:25 +0200
        Re: Programm stoppen/einfrieren wenn nicht im Fokus "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2017-09-28 08:57 +0200
          Re: Programm stoppen/einfrieren wenn nicht im Fokus Michael Bode <m.g.bode@web.de> - 2017-09-28 19:21 +0200
        Re: Programm stoppen/einfrieren wenn nicht im Fokus Gert Bass <me@privacy.net> - 2017-09-28 14:20 -0700
          Re: Programm stoppen/einfrieren wenn nicht im Fokus Dr. Joachim Neudert <neudert@5sl.org> - 2017-09-29 04:37 +0000
          Re: Programm stoppen/einfrieren wenn nicht im Fokus Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-09-29 08:23 +0200
            Re: Programm stoppen/einfrieren wenn nicht im Fokus "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2017-09-29 10:21 +0200
              Re: Programm stoppen/einfrieren wenn nicht im Fokus Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-09-29 10:43 +0200
                Re: Programm stoppen/einfrieren wenn nicht im Fokus "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2017-09-29 12:29 +0200
            Re: Programm stoppen/einfrieren wenn nicht im Fokus Michael Bode <m.g.bode@web.de> - 2017-09-30 00:06 +0200
              Re: Programm stoppen/einfrieren wenn nicht im Fokus Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-09-30 00:14 +0200
              Re: Programm stoppen/einfrieren wenn nicht im Fokus "Joachim Dr. Neudert" <neudert@5sl.org> - 2017-09-30 07:41 +0200
      Re: Programm stoppen/einfrieren wenn nicht im Fokus Gert Bass <me@privacy.net> - 2017-09-28 14:37 -0700
        Re: Programm stoppen/einfrieren wenn nicht im Fokus Shinji Ikari <shinji@gmx.net> - 2017-09-29 00:02 +0200
          Re: Programm stoppen/einfrieren wenn nicht im Fokus Gert Bass <me@privacy.net> - 2017-09-28 16:13 -0700
    Re: Programm stoppen/einfrieren wenn nicht im Fokus "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2017-09-28 08:55 +0200
      Re: Programm stoppen/einfrieren wenn nicht im Fokus Gert Bass <me@privacy.net> - 2017-09-28 14:34 -0700
    Re: Programm stoppen/einfrieren wenn nicht im Fokus Gert Bass <me@privacy.net> - 2017-09-30 15:52 -0700

Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →

#323907

From	Hergen Lehmann <hlehmann.expires.5-11@snafu.de>
Date	2017-09-29 22:13 +0200
Message-ID	<h3m2ae-q7q.ln1@hergen.dyndns.org>
In reply to	#323903

Am 29.09.2017 um 21:35 schrieb Gerrit Heitsch:

>> Es gibt ein Lastenheft und/oder Besprechungsnotizen, in denen das 
>> vorgesehene Benutzungsszenario skizziert ist, und wenn eine Software 
>> auf dieses Szenario zugeschnitten ist, ist sie nicht minderwertig.
> 
> Speicherlecks sind Bugs. Darüber braucht man nicht diskutieren.

Es geht nicht nur um Speicherlecks, sondern auch um Fragmentierung des 
Speichers.
Gibst du nicht mehr benötigten Speicher immer sofort frei, bilden sich 
auf Dauer riesige Mengen nicht zusammenhängender Speicherblöcke, die 
zwar als frei markiert aber zu klein sind, um noch einmal sinnvoll 
verwendet werden zu können. Gibst den Speicher verzögert frei, frisst 
das direkt Speicher. So oder so, das Programm wird im Speicher immer 
fetter und immer langsamer. Dort einen goldenen Mittelweg zu finden, 
erfordert viel Erfahrung und viel schrittweise Optimierung.

Und dann sind da auch jene Speicherlöcher, die dem Entwickler wohl 
bekannt sind, aber nicht behoben werden können, weil sie in 
zugelieferten Libraries oder gar im Betriebssystem selbst stecken...

>> Software für 24/7-Betrieb zu schreiben, ist ein nicht unerheblicher 
>> Mehraufwand. Insbesondere in die Speicherverwaltung muss sehr viel 
>> mehr Aufmerksamkeit und manuelle Optimierung investiert werden.
> 
> Ja, zu jedem malloc() braucht man ein free(). Das sollte aber 
> selbstverständlich sein und keiner weiteren Erwähnung bedürfen.

Keine moderne Programmiersprache verwendet noch handkodiertes malloc/free.

Je nach Sprache hast du heute wahlweise Garbage Collection (z.B. Java) 
oder Reference Counting (z.B. C++). Das ist wunderbar komfortabel und 
vermeidet viele klassische Fehlerquellen, wird bei langer Laufzeit aber 
zunehmend nicht-deterministisch.

Hergen

[toc] | [prev] | [next] | [standalone]

#323910

From	Gerrit Heitsch <gerrit@laosinh.s.bawue.de>
Date	2017-09-29 23:07 +0200
Message-ID	<oqmcmd$iul$1@news.bawue.net>
In reply to	#323907

On 09/29/2017 10:13 PM, Hergen Lehmann wrote:
> Am 29.09.2017 um 21:35 schrieb Gerrit Heitsch:
> 
>>> Es gibt ein Lastenheft und/oder Besprechungsnotizen, in denen das 
>>> vorgesehene Benutzungsszenario skizziert ist, und wenn eine Software 
>>> auf dieses Szenario zugeschnitten ist, ist sie nicht minderwertig.
>>
>> Speicherlecks sind Bugs. Darüber braucht man nicht diskutieren.
> 
> Es geht nicht nur um Speicherlecks, sondern auch um Fragmentierung des 
> Speichers.
> Gibst du nicht mehr benötigten Speicher immer sofort frei, bilden sich 
> auf Dauer riesige Mengen nicht zusammenhängender Speicherblöcke, die 
> zwar als frei markiert aber zu klein sind, um noch einmal sinnvoll 
> verwendet werden zu können.

Ein gutes OS ist in der Lage den Speicher nebenher zu defragmentieren. 
Das wird erst zum Problem wenn du Speicher schneller anforderst als er 
defragmentiert werden kann. Kommt bei einem Desktop eher nicht vor.


> Und dann sind da auch jene Speicherlöcher, die dem Entwickler wohl 
> bekannt sind, aber nicht behoben werden können, weil sie in 
> zugelieferten Libraries oder gar im Betriebssystem selbst stecken...

Hier wird ein Bugreport dringend empfohlen. Zumindest beim OS sollte 
sich da schnell was tun.


> 
>>> Software für 24/7-Betrieb zu schreiben, ist ein nicht unerheblicher 
>>> Mehraufwand. Insbesondere in die Speicherverwaltung muss sehr viel 
>>> mehr Aufmerksamkeit und manuelle Optimierung investiert werden.
>>
>> Ja, zu jedem malloc() braucht man ein free(). Das sollte aber 
>> selbstverständlich sein und keiner weiteren Erwähnung bedürfen.
> 
> Keine moderne Programmiersprache verwendet noch handkodiertes malloc/free.
> 
> Je nach Sprache hast du heute wahlweise Garbage Collection (z.B. Java) 
> oder Reference Counting (z.B. C++). Das ist wunderbar komfortabel und 
> vermeidet viele klassische Fehlerquellen, wird bei langer Laufzeit aber 
> zunehmend nicht-deterministisch.

Ist also fehlerhaft implementiert.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#323919

From	Hergen Lehmann <hlehmann.expires.5-11@snafu.de>
Date	2017-09-30 00:30 +0200
Message-ID	<55u2ae-iau.ln1@hergen.dyndns.org>
In reply to	#323910

Am 29.09.2017 um 23:07 schrieb Gerrit Heitsch:

>> Es geht nicht nur um Speicherlecks, sondern auch um Fragmentierung des 
>> Speichers.
> 
> Ein gutes OS ist in der Lage den Speicher nebenher zu defragmentieren. 

Dies geschieht aber nur auf Ebene von ganzen MMU-Pages (4kByte bei x86).

Die nicht mehr nutzbaren Fragmente, die innerhalb der Anwendung 
entstehen, sind sehr viel kleiner und lassen sich auch kaum sinnvoll 
defragmentieren, da beim Verschieben von Daten im virtuellen Adressraum 
wahlweise a) Zeiger auf die Daten ungültig werden oder b) die Anwendung 
für längere Zeit komplett angehalten werden muss, während sämtliche 
Zeiger-Verkettungen geprüft und ggf. korrigiert werden.

Beides ist nicht wirklich tauglich.

In der Praxis realisiert man daher meist Sub-Allokatoren, welche 
Speicher in größeren Brocken vom OS anfordern und dann mit einer 
geeigneten Strategie an ungefähr gleich große Objekte weitergeben. Sowas 
kann man mit viel empirischer Handarbeit auf die Anwendung abgestimmt 
selbst stricken, oder man kann sich auf eine Automagie verlassen, die 
sich dann aber wieder nicht deterministisch verhält...

>> Und dann sind da auch jene Speicherlöcher, die dem Entwickler wohl 
>> bekannt sind, aber nicht behoben werden können, weil sie in 
>> zugelieferten Libraries oder gar im Betriebssystem selbst stecken...
> 
> Hier wird ein Bugreport dringend empfohlen. Zumindest beim OS sollte 
> sich da schnell was tun.

Wenn eine durchschnittliche, mittelständische Softwarebude bei einem 
Giganten wie Microsoft anfragt und das Problem dort nicht als gravierend 
eingestuft wird? Ohne Auftrag, mehrjährige Wartezeit und saftige 
Rechnung wohl kaum.

Und auch die Open-Source-Community kann sehr, sehr schwerhörig sein, 
wenn es sich um ein Problem handelt, das von den entscheidenden Personen 
als unwichtig oder exotisch wahrgenommen wird.

>> Je nach Sprache hast du heute wahlweise Garbage Collection (z.B. Java) 
>> oder Reference Counting (z.B. C++). Das ist wunderbar komfortabel und 
>> vermeidet viele klassische Fehlerquellen, wird bei langer Laufzeit 
>> aber zunehmend nicht-deterministisch.
> 
> Ist also fehlerhaft implementiert.

Wenn du einen besseren Lösungsansatz für das Problem der automagischen 
Speicherverwaltung hast, solltest du ein Paper darüber veröffentlichen. 
Du würdest über Nacht berühmt. ^_-

Hergen

[toc] | [prev] | [next] | [standalone]

#324128

From	spamfalle2@arcor.de (Marc Stibane)
Date	2017-10-01 14:29 +0200
Message-ID	<1nd801a.1rgylufxoos0iN@marc.my-fqdn.de>
In reply to	#323907

Hergen Lehmann <hlehmann.expires.5-11@snafu.de> wrote:

> Je nach Sprache hast du heute wahlweise Garbage Collection (z.B. Java)
> oder Reference Counting (z.B. C++). Das ist wunderbar komfortabel und
> vermeidet viele klassische Fehlerquellen, wird bei langer Laufzeit aber
> zunehmend nicht-deterministisch.

Apple ist vor 'ner Weile umgestiegen auf ARC (automated reference
counting) - da macht das der Compiler. Nur noch in Ausnahmefällen muss
man selber im Code was tun. Funktioniert ziemlich gut...

-- 
In a world without walls and fences,
   who needs windows and gates?

[toc] | [prev] | [next] | [standalone]

#324131

From	Dietz Proepper <dietz-news@rotfl.franken.de>
Date	2017-10-01 16:21 +0200
Message-ID	<1747094.usQuhbGJ8B@rotfl.franken.de>
In reply to	#324128

Marc Stibane wrote:

> Hergen Lehmann <hlehmann.expires.5-11@snafu.de> wrote:
> 
>> Je nach Sprache hast du heute wahlweise Garbage Collection (z.B. Java)
>> oder Reference Counting (z.B. C++). Das ist wunderbar komfortabel und
>> vermeidet viele klassische Fehlerquellen, wird bei langer Laufzeit aber
>> zunehmend nicht-deterministisch.
> 
> Apple ist vor 'ner Weile umgestiegen auf ARC (automated reference
> counting) - da macht das der Compiler. Nur noch in Ausnahmefällen muss
> man selber im Code was tun. Funktioniert ziemlich gut...

One day a student came to Moon and said: "I understand how to make a better 
garbage collector. We must keep a reference count of the pointers to each 
cons."
Moon patiently told the student the following story:
    "One day a student came to Moon and said: 'I understand how to make a 
better garbage collector...'"

;-)

[toc] | [prev] | [next] | [standalone]

#324145

From	Hermann Riemann <nospam.ng@hermann-riemann.de>
Date	2017-10-02 04:41 +0200
Message-ID	<f3dna0Fn47oU1@mid.individual.net>
In reply to	#324128

Am 01.10.2017 um 14:29 schrieb Marc Stibane:

> Apple ist vor 'ner Weile umgestiegen auf ARC (automated reference
> counting) - da macht das der Compiler. Nur noch in Ausnahmefällen muss
> man selber im Code was tun. Funktioniert ziemlich gut...

Erinnert mich an Überprüfung von array Grenzen.

Wenn es schnell gehen soll,
kostet das zuviel Zeit.

Beim Anlegen und Beenden einer Klasse (Strukturspeicher)
jedes mal alle pointer verwalten ..

Hermann
    der C so schnell nicht los wird.

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]

#324165

From	Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de>
Date	2017-10-02 13:26 +0200
Message-ID	<oqt7os$gib$1@dont-email.me>
In reply to	#324145

Salve allerseits,

Hermann Riemann schrieb:
> Am 01.10.2017 um 14:29 schrieb Marc Stibane:
> 
>> Apple ist vor 'ner Weile umgestiegen auf ARC (automated reference
>> counting) - da macht das der Compiler. Nur noch in Ausnahmefällen muss
>> man selber im Code was tun. Funktioniert ziemlich gut...
> 
> Erinnert mich an Überprüfung von array Grenzen.
> 
„Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen
Nagel.“ – Paul Watzlawick (1921 – 2007)

	M.f.G.

-- 
Diese E-Mail-Adresse wird nur aus nostalgischen Gründen verwendet. Sie
wird praktisch nie gelesen.  Das MausNet ist nicht tot – es riecht nur
etwas komisch... ;-)

[toc] | [prev] | [next] | [standalone]

#324183

From	Andreas Karrer <ak-7a@gmx.ch>
Date	2017-10-02 13:59 +0000
Message-ID	<slrnot4hh7.rkm.ak-7a@chimborazo.ee.ethz.ch>
In reply to	#324165

* Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de>:

> „Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen
> Nagel.“ – Paul Watzlawick (1921 – 2007)

Kaum. Sicher, er hat sich durchaus mit dem Gedanken befasst, aber wenn
er das gesagt hat, war er sicher nicht der erste. Abraham Maslow hat
das 1966 ziemlich konzis formuliert, aber der Gedanke ist sicher
schon älter.
https://en.wikipedia.org/wiki/Law_of_the_instrument

Die Hammer-Geschichte bei Watzlawick ist eine andere, "Behalten Sie
Ihren Hammer, Sie Rüpel!"

 - Andi

[toc] | [prev] | [next] | [standalone]

#323908

From	Wolfgang Kynast <wky@gmx.de>
Date	2017-09-29 22:16 +0200
Message-ID	<f37o1uFc0klU1@mid.individual.net>
In reply to	#323903

On Fri, 29 Sep 2017 21:35:50 +0200, "Gerrit Heitsch" posted:

>On 09/29/2017 09:19 PM, Hergen Lehmann wrote:
>> Am 29.09.2017 um 08:23 schrieb Stefan Froehlich:
>> 
>>> Es ist keineswegs so, dass die Browser nicht dazu *gedacht* sind,
>>> sondern sie sind schlichtweg minderwertig programmiert. Abgesehen
>>> vielleicht von Programmen mit determiniertem Ende ist jede Software
>>> (prinzipiell) für Dauerbetrieb gedacht.
>> 
>> Sorry, aber das ist Unfug.
>> Es gibt ein Lastenheft und/oder Besprechungsnotizen, in denen das 
>> vorgesehene Benutzungsszenario skizziert ist, und wenn eine Software auf 
>> dieses Szenario zugeschnitten ist, ist sie nicht minderwertig.
>
>Speicherlecks sind Bugs. Darüber braucht man nicht diskutieren.
>
>
>> Software für 24/7-Betrieb zu schreiben, ist ein nicht unerheblicher 
>> Mehraufwand. Insbesondere in die Speicherverwaltung muss sehr viel mehr 
>> Aufmerksamkeit und manuelle Optimierung investiert werden.
>
>Ja, zu jedem malloc() braucht man ein free(). Das sollte aber 
>selbstverständlich sein und keiner weiteren Erwähnung bedürfen.

Mit malloc und free wird man das Problem kaum lösen können, wenn die
SW hinreichend komplex ist. Da bedarf es dann schon einer darüber-
liegenden eigenen Speicherverwaltung.

-- 
Schöne Grüße,
Wolfgang

[toc] | [prev] | [next] | [standalone]

#324129

From	Hermann Riemann <nospam.ng@hermann-riemann.de>
Date	2017-10-01 16:11 +0200
Message-ID	<f3cbbpFdcqqU1@mid.individual.net>
In reply to	#323903

Am 29.09.2017 um 21:35 schrieb Gerrit Heitsch:

> Ja, zu jedem malloc() braucht man ein free(). Das sollte aber 
> selbstverständlich sein und keiner weiteren Erwähnung bedürfen.

Nein.

Beispiel, alle meine abänderbaren strings sind so wenig,
dass sich eine Freigabe nicht lohnt.

Ich habe da meine eigene Speicherverwaltung

static size_t  buf_len; static char *buf_p, *buf_end_p;

static void expand_buf(size_t l, size_t init_l){
    if (buf_len==0) buf_len =init_l;
    buf_len +=l; buf_len *=2;
    buf_p = malloc(buf_len); buf_end_p = buf_p + buf_len;
    if (buf_p==NULL) error("get_?_p malloc returns zero",NULL,buf_len);
    memset(buf_p, 0,buf_len); }

void *get_text_p(char *name){
    char *p; size_t cp_len,l;
    cp_len=strlen(name)+1;l=cp_len +4;   l&=-4; /* '\0' */
    if ( buf_p + l >= buf_end_p) expand_buf(l,60000);
    if (name!=NULL) memcpy(buf_p,name,cp_len);
    p= buf_p; p[cp_len]='\0';  buf_p+=l;
    return (void *)p;}

Hermann
    der damit seit einigen Jahrzehnten
    gute Erfahrung gemacht hat.


-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]

#323750

From	Gerrit Heitsch <gerrit@laosinh.s.bawue.de>
Date	2017-09-29 08:28 +0200
Message-ID	<oqkp7a$tku$1@news.bawue.net>
In reply to	#323736

On 09/28/2017 11:58 PM, Shinji Ikari wrote:
> 
> Wo in der Bescheibung oder Entwicklung von Browsern seht, dass sie
> dafuer gedacht sein ueber Wochen (oder wie hier zu lesen war noch
> weitaus laenger) konstant durchzulaufen?
> Selbst Desktop-OS sind dafuer nicht vorgesehen. Dafuer gibt es
> Server-OS.

Ein OS welches nicht zu beliebig langer Uptime fähig ist ist fehlerhaft 
und braucht Patches. Es macht hier keinen Unterschied ob es ein 
Server-OS oder ein Desktop-OS ist.

Auch wenn es vielleicht in Vergessenheit geraten ist, Speicherlecks sind 
Bugs.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#323767

From	Dietz Proepper <dietz-news@rotfl.franken.de>
Date	2017-09-29 08:42 +0200
Message-ID	<2896510.44csPzL39Z@rotfl.franken.de>
In reply to	#323736

Shinji Ikari wrote:

> Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) schrieb
>> - und wenn qualtiativ minderwertige Software
>>(Ressourcen-Lecks fallen definitiv darunter) das verhindert, dann
>>ist nicht die Software schuld, sondern ich?
> 
> Wenn man eine Software, die nicht fuer etwas gedacht ist (=Dauerlauf
> mit vielen offenen Tabs) so nutzt, wie sie nicht vorgesehen war
> (=Dauerlauf mit sehr vielen offenen Tabs), ist nicht unbedingt die
> Software schuld, sondern die Person, die die Software dazu benutzt.

Hey, ist irgendwo für Deinen Dateimanager spezifiziert dass er nur und genau 
nur die Datei, welche Du selektiert hast löscht?

> Wo in der Bescheibung oder Entwicklung von Browsern seht, dass sie
> dafuer gedacht sein ueber Wochen (oder wie hier zu lesen war noch
> weitaus laenger) konstant durchzulaufen?

Wo ist spezifiziert, dass sie Ressourcen leaken?

> Selbst Desktop-OS sind dafuer nicht vorgesehen. Dafuer gibt es
> Server-OS.

Die Unterscheidung ist - mit Verlaub - Quatsch.

[toc] | [prev] | [next] | [standalone]

#323765

From	Dietz Proepper <dietz-news@rotfl.franken.de>
Date	2017-09-29 08:37 +0200
Message-ID	<2890970.aeNJFYEL58@rotfl.franken.de>
In reply to	#323732

Stefan Froehlich wrote:

> Insgesamt finde ich Deine Argumentation befremdlich: Ich würde mir
> mein Leben am Rechner durch Software gerne so komfortabel wie
> möglich gestalten - und wenn qualtiativ minderwertige Software
> (Ressourcen-Lecks fallen definitiv darunter) das verhindert, dann
> ist nicht die Software schuld, sondern ich?

Man muss natürlich zugestehen, dass ein Browser, der mit moderner 
Webtechnologie kompatibel ist ohne massiven Einsatz von Heuristiken kaum 
implementierbar ist.

Sachen wie "nicht-aktive Fenster anhalten" sind auch eher Krücken aus 
Strohhalmen als eine richtige Hilfe.

[toc] | [prev] | [next] | [standalone]

#323819

From	Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich)
Date	2017-09-29 10:28 +0000
Message-ID	<3t59ce1fb0i2399n3e8%sfroehli@Froehlich.Priv.at>
In reply to	#323765

On Fri, 29 Sep 2017 08:37:09 Dietz Proepper wrote:
> Stefan Froehlich wrote:
> > Insgesamt finde ich Deine Argumentation befremdlich: Ich würde mir
> > mein Leben am Rechner durch Software gerne so komfortabel wie
> > möglich gestalten - und wenn qualtiativ minderwertige Software
> > (Ressourcen-Lecks fallen definitiv darunter) das verhindert, dann
> > ist nicht die Software schuld, sondern ich?

> Man muss natürlich zugestehen, dass ein Browser, der mit moderner
> Webtechnologie kompatibel ist ohne massiven Einsatz von
> Heuristiken kaum implementierbar ist.

Das ist sicherlich ein Problem, ja.

Trotzdem: Wenn das Ding einmal massiv Ressourcen verbraucht und ich
schließe alle Tabs bis auf ein einziges, das irgendeine triviale
Textdatei anzeigt - spätestens *dann* würde ich erwarten, dass der
Ressourcenverbrauch wieder nahezu dort ist, wo er beim Programmstart
war. Ist er aber nicht einmal annähernd, und das kann mir keiner
mehr mit Heuristiken bei der Darstellung erklären.

> Sachen wie "nicht-aktive Fenster anhalten" sind auch eher Krücken
> aus Strohhalmen als eine richtige Hilfe.

Stimmt, das wäre jetzt auch nicht gerade das, was mir vorschwebt
(mich stört der Speicherverbrauch tatsächlich auch deutlich mehr,
als die CPU-Belastung).

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan. Für besengte Eumel in verschränkten Universen!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#323493

From	"Dr. Joachim Neudert" <neudert@5sl.org>
Date	2017-09-27 15:53 +0200
Message-ID	<oqgahe$kgq$1@news.albasani.net>
In reply to	#323487

Am 27.09.17 um 15:39 schrieb Shinji Ikari:
> Guten Tag
> 
> Gerrit Heitsch <gerrit@laosinh.s.bawue.de> schrieb
> 
>>> Ein Web Browser ist ein dafür prädestiniertes Programm, das nicht aktiv
>>> sein sollte wenn keiner hinschaut.
>> Wäre aber schön wenn die Downloads weiterlaufen und auch das 
>> Youtube-Video was nebenher laufen soll während ich mit einem anderen 
>> Programm was arbeite.
> 
> Und der HTTPs.Tunnel zum VPN-Server weiter offen bleibt, die
> gestarteten Webseiten weiter laden, damit man sie dann bei Bedarf
> schnell sehen kann und nicht auf Nachladen warten muss,
> und...und..und...
> Wenn man eine Anwendung nicht braucht: nicht starten.
> Wenn man sie startet, will man auch meist, dass sie laeuft.
> Oder sollte der Touchpadtreiber auch seinen Dienst einstellen, wnen
> das Einstellungsfenster dafuer nicht im Vordergrund ist? Und die
> Tastatur? Virenscanner, VNC Zugriff, Drucker, etc...
> Wenn imme rnur das laeuft, was im Vordergrund ist, wird es schwierig
> einen PC so zu benutzen, wie man es heute gewohnt ist. Vielleicht
> sollte man dann wieder zurueck zu DOS? 8)
> 


Auf selber Hardware läuft Windows 10-12  Stunden, und OSX 22 Stunden.
Nativ gebootetes Bootcamp-Windows an einem MacBook pro.

Man kann es offenbar besser machen als Microsoft, denn dein etwas
abstruses Szenario das Touchpad jeweils an- und auszuschalten ist am
MacBook auch nicht erforderlich.

[toc] | [prev] | [next] | [standalone]

#323490

From	"Dr. Joachim Neudert" <neudert@5sl.org>
Date	2017-09-27 15:48 +0200
Message-ID	<oqga7j$mce$1@news.albasani.net>
In reply to	#323482

Am 27.09.17 um 14:13 schrieb Gerrit Heitsch:
> On 09/27/2017 02:04 PM, Dr. Joachim Neudert wrote:
>> Marc Stibane <spamfalle2@arcor.de> wrote:
>>> Dr. Joachim Neudert <neudert@5sl.org> wrote:
>>>
>>>> Safari-Einstellungen-Erweitert-Internet-Plug-Ins
>>>> [x]  Plug-Ins zum Stromsparen stoppen
>>>
>>> und auch gleich per default an - ich weiß nicht seit wann Safari das hat
>>> aber ich habe es nicht explizit eingeschaltet.
>>>
>>> Richtig so.
>>>
>>
>> Ein Web Browser ist ein dafür prädestiniertes Programm, das nicht aktiv
>> sein sollte wenn keiner hinschaut.
> 
> Wäre aber schön wenn die Downloads weiterlaufen und auch das
> Youtube-Video was nebenher laufen soll während ich mit einem anderen
> Programm was arbeite.

Dafür hat Safari auf dem iPad und dem Mac doch sogar eine eigene
Funktion, laufende Videos laufen klein weiter, mit Kontrollelementen.
Auf Pause hält es oder x ist es dann ganz aus.
> 
> Ich hoffe dafür muss man nicht jedesmal obige Option ein- und
> ausschalten. 

s.o. Ist gelöst.

> Wäre nett wenn man das für jeden Tab einstellen könnte.
> 
> [ ] Diesen Tab nicht anhalten
> 
>  Gerrit
>

[toc] | [prev] | [next] | [standalone]

#323433

From	Shinji Ikari <shinji@gmx.net>
Date	2017-09-27 10:05 +0200
Message-ID	<7lmmsctlo7jkjks3p1hacgt50rjled5p7l@4ax.com>
In reply to	#323429

Guten Tag

"Dr. Joachim Neudert" <neudert@5sl.org> schrieb

>>>> Wie könnte ich unter Windows einen Browser oder fast jede Anwendung -
>>>> wenn ich so drüber nachdenke - davon abhalten, die CPU zu beanspruchen
>>>> wenn das Fenster nicht im Fokus ist?
>>> Es hilft dir jetzt nicht wirklich weiter, aber wenn du mal über den Zaun
>>> schauen willst: bei Mac OS X schaltet der Browser Plug– ins und
>>> Ressourcenverbrauch aus wenn er nicht im Vordergrund läuft. Seit einiger
>>> Zeit schon.
>> Wenn das auch (wie angefragt) mit den anderen Anwendungen klappt,
>> scheint man dahingehend dem OS die Multitaskingfaehigkeit weitgehend
>> abgewoehnt zu haben.
>> Das ist irgendwie in Zeiten von MultiCore-CPU nicht der meist
>> zuangestrebte Weg.
>Der OP wünscht das aber so.

Das hatte ich vernommen.

> Gib ihm doch besser Tipps,

Naja, besser als "Es hilft dir jetzt nicht wirklich weiter" waere,
alle Anwendungen auf ein und den selben Core zu buendeln. (Windows
Taskmanager kann man die zu verwendenen Cores angeben).
Damit laufen die Anwendungen zwar weiter, aber beispielsweise bei
einem Quadcore wrd maximal etwas mehr als 1/4 der elektrischen
Leistung verwendet um dann dem eigentlichen Wunsch der kuehleren CPU =
leiseren Lueftung zu entsprechen.
Zitat OP: "...eine gewisse Grundlast erzeugt, die den ansonsten
vollkommen lautlosen und kühlen Laptop in eine Heizung mit Dauerlüfter
verwandelt..."
Das das die fluessige Benutzung beeinflusst ist klar.

[toc] | [prev] | [next] | [standalone]

#323434

From	"Dr. Joachim Neudert" <neudert@5sl.org>
Date	2017-09-27 10:24 +0200
Message-ID	<oqfn76$4tp$1@solani.org>
In reply to	#323433

Am 27.09.17 um 10:05 schrieb Shinji Ikari:
> Guten Tag
> 

>> Der OP wünscht das aber so.
> 
> Das hatte ich vernommen.
> 
>> Gib ihm doch besser Tipps,
> 
> Naja, besser als "Es hilft dir jetzt nicht wirklich weiter" waere,

Na ja, ist halt ein sehr langfristiger Tipp. Wenn man laufend hört daß
es auch anders geht, soll der eine oder andere schon mal dem Mac eine
Chance gegeben haben.

Und ich halte ja neuerdings paar Aktien von Apple, daher ist mein Tipp
durchaus rational begründet und nicht etwa missionarisch...


> alle Anwendungen auf ein und den selben Core zu buendeln. (Windows
> Taskmanager kann man die zu verwendenen Cores angeben).
> Damit laufen die Anwendungen zwar weiter, aber beispielsweise bei
> einem Quadcore wrd maximal etwas mehr als 1/4 der elektrischen
> Leistung verwendet um dann dem eigentlichen Wunsch der kuehleren CPU =
> leiseren Lueftung zu entsprechen.
> Zitat OP: "...eine gewisse Grundlast erzeugt, die den ansonsten
> vollkommen lautlosen und kühlen Laptop in eine Heizung mit Dauerlüfter
> verwandelt..."
> Das das die fluessige Benutzung beeinflusst ist klar.
> 

Gruß

Joachim

[toc] | [prev] | [next] | [standalone]

#323465

From	Wolfgang Kynast <wky@gmx.de>
Date	2017-09-27 12:43 +0200
Message-ID	<f31dm1Fpf06U1@mid.individual.net>
In reply to	#323429

On Wed, 27 Sep 2017 09:39:47 +0200, "Dr. Joachim Neudert" posted:

>Am 27.09.17 um 09:22 schrieb Shinji Ikari:
>> Guten Tag
>> 
>> Dr. Joachim Neudert <neudert@5sl.org> schrieb
>> 
>>>> Wie könnte ich unter Windows einen Browser oder fast jede Anwendung -
>>>> wenn ich so drüber nachdenke - davon abhalten, die CPU zu beanspruchen
>>>> wenn das Fenster nicht im Fokus ist?
>>> Es hilft dir jetzt nicht wirklich weiter, aber wenn du mal über den Zaun
>>> schauen willst: bei Mac OS X schaltet der Browser Plug– ins und
>>> Ressourcenverbrauch aus wenn er nicht im Vordergrund läuft. Seit einiger
>>> Zeit schon.
>> 
>> Wenn das auch (wie angefragt) mit den anderen Anwendungen klappt,
>> scheint man dahingehend dem OS die Multitaskingfaehigkeit weitgehend
>> abgewoehnt zu haben.
>> Das ist irgendwie in Zeiten von MultiCore-CPU nicht der meist
>> zuangestrebte Weg.
>> 
>> 
>
>
>Der OP wünscht das aber so. Gib ihm doch besser Tipps, wie er es auch in
>Windows erreicht, daß Browser-Fenster im Hintergrund solche Plugins wie
>Flash, Silverlight 

wer die benutzt ist selber schuld

>usw. temporär suspendieren. Ist gut für die
>Akku-Laufzeit, die jetzt 22 Stunden beim MBP beträgt.

ok, bei usw. geb ich Dir Recht ;-)


-- 
Schöne Grüße,
Wolfgang

[toc] | [prev] | [next] | [standalone]

#323475

From	spamfalle2@arcor.de (Marc Stibane)
Date	2017-09-27 13:16 +0200
Message-ID	<1nd0hbq.ctvz3xan8tvoN@marc.my-fqdn.de>
In reply to	#323428

Shinji Ikari <shinji@gmx.net> wrote:

> Wenn das auch (wie angefragt) mit den anderen Anwendungen klappt,
> scheint man dahingehend dem OS die Multitaskingfaehigkeit weitgehend
> abgewoehnt zu haben.

Sowas sollte natürlich vom User einstellbar sein. Apps X, Y und Z dürfen
im Hintergrund laufen, alle anderen werden lahmgelegt.
Hätte ich auch gerne. MacOS kann das nicht (abgesehen von Safari-
PlugIns), iOS aber schon.

> Das ist irgendwie in Zeiten von MultiCore-CPU nicht der meist
> zuangestrebte Weg.

Bei mobilen Devices schon, weil Stromsparen da wichtiger ist als
Leistung. Unter iOS z.B. gibt es nur wenige Arten von Apps die
*konstant* im Hintergrund was machen dürfen:
  -  Tonausgabe (z.B. Musikplayer)
  -  Mikrofon-Input (Aufnahme)
  -  VoIP (Telefon)
  -  Ortungsdienste (Navigation)
  -  ext. Hardware
  -  Bluetooth (Kontroller, Fernbedienung)

alle anderen Apps dürfen nur begrenzt im Hintergrund was machen, z.B.
Downloads fertig stellen, Reagieren auf Push-Notifications, etc.

Nun könnte man ja einfach eine der o.g. Möglichkeiten deklarieren und
dann unbegrenzt im Hintergrund laufen - oder? Nö, erstens überprüft
Apple die Sinnhaftigkeit für jede App bevor es die im Store zulässt, und
zweitens kann der User auch die Berechtigung für jede App einzeln
ausschalten (auch nachträglich), womit dann auch die
Hintergrundfähigkeit perdu ist.
Ich vermute mal bei Android ist das ähnlich.

Mobile Betriebssystem sind hier Vorreiter, aber ich kann mir gut
vorstellen dass sowas auch in Desktop-OSse integriert wird.

-- 
In a world without walls and fences,
   who needs windows and gates?

[toc] | [prev] | [next] | [standalone]

Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →

csiph-web

Programm stoppen/einfrieren wenn nicht im Fokus

Contents

#323907

#323910

#323919

#324128

#324131

#324145

#324165

#324183

#323908

#324129

#323750

#323767

#323765

#323819

#323493

#323490

#323433

#323434

#323465

#323475