Hallo,
der Thread über Dead Ends kam hier nicht besonders gut an.
Ich will nun eine ander Perspektive einnehmen.
Living Ends. Also was wird die Zukunft aus eurer Sicht für
schöne Dinge bringen?
Vor kurzem bin ich zB über dieses coole open source Tool gestoßen. Damit
kann man gemeinsam Zeichnungen erstellen:
Was wird die Zukunft aus eurer Sicht für
schöne Dinge bringen?
Hallo Thomas,
On 27.05.20 09:25, Thomas Güttler Lists wrote:
Was wird die Zukunft aus eurer Sicht für
schöne Dinge bringen?
Ein schönes Thema bringst Du da auf den Tisch. Ich denke die Zukunft verdient und bringt eine Trendwende im Energieverbrauch (und damit der Systemanforderungen) insbesondere für Clients. Und etwas mehr Wertschätzung für nachhaltige Lösungen, welche die Souveränität ihrer Nutzer bewahren.
Zum Energieverbrauch:
In letzter Zeit ging alles Richtung Web. Dort dominiert auf Client-Seite Javascript mit seinen bekannten Eigenschaften. Selbst von den Herstellern angebotene "Standalone-Apps" sind in Wirklichkeit meist nur Web-Apps mit Electron-Umverpackung. Man gewinnt also ökologisch außer einer besseren Integration zum Host-OS nichts. Die alte Gleichung – CPU und RAM ist billiger als der „kostbare“ Entwickler geht meiner Meinung nach schon lange nicht mehr auf und vernachlässigt den Fakt, dass zumindest die laufenden CPU-Kosten direkt an den Energieverbrauch gekoppelt sind. Niemand sollte mehr so tun, als stünden Ressourcen unbegrenzt zur Verfügung. Die Strompreise steigen steigen steiler als die Stundensätze der Offshore-Entwickler, und nur der Wegwerfmentalität der meisten Benutzer ist es zu „verdanken“, dass dieses Problem kaum wahrgenommen wird.
Zur Bewertung eines Clients würde ich deshalb auch die erwartete Häufigkeit und Dauer der Nutzung in die Gleichung einbringen. Beispiele: (a) ein System zum Bestellen bei einem Menüservice darf gern eine Web-App sein. Die Nutzung erfolgt pro Client höchstens einmal täglich. Dafür lohnt sich kein nativer Client und die Vorteile der zentralen Bereitstellung überwiegen. (b) eine Kommunikationsanwendung (vgl. Microsoft Teams) sollte keine Web-App sein. Die Nutzung erfolgt aktiv mehrmals täglich für mehrere Stunden, und passiv im Prinzip den ganzen Tag (die App muss offen bleiben, damit man angerufen werden kann). Der Overhead, der durch die verwendete Technologie entsteht, ist enorm. Hier sollte alternativ ein nativer Client zur Verfügung stehen, der vorhandene Client-Ressourcen effizient nutzt. Schade, dass der Blaue Engel[1] bisher nur auf den Rechenzentrumsbetrieb abzielt und die gefühlt mindestens genauso große Komponente – die vielen Millionen Smartphone- und Laptop-Akkus, die täglich geladen werden – außer Acht lässt.
Zur Souveränität:
Beim Thema Souveränität tangiert mich nicht der Fakt, dass die Daten außerhalb der eigenen physikalischen Reichweite liegen, sondern eher der Umstand, dass im Bereich der SaaS-Provider in teilweise großem Umfang Vendor-Locks hingenommen werden müssen. Als geschäftsschädigend könnte man das übertrieben betrachtet im Bereich Office-Anwendungen (Textverarbeitung, Spreadsheet, Dokumentenmanagement, Projektmanagement) bezeichnen; als katastrophal in den Bereichen Kommunikation (E-Mail, Instant Messaging, Videotelefonie) und Automatisierung (Smart Home).
Ich persönlich freue mich deshalb zukünftig in loser Folge auf:
* Einen kritischen Umgang mit Web-Apps und einen Konsens darüber, wann diese Sinn ergeben und wann nicht (Häufigkeit und Dauer der Nutzung * Anzahl der Nutzer?)
* Eine Wiederbelebung der Ideen von vergessenen Cross Platform-Technologien zur Umsetzung von nativen, energieeffizienten Client-Anwendung (z.B. Lazarus – kennt das noch jemand?)
* Energieersparnisse durch Vereinfachung der Server-Architekturen – etwa durch Abbau von organisatorisch motivierten technischen Abstraktionsebenen
* Mehr Nutzung von modernen, effizienten compilierten Sprachen auf Serverseite (z.B. Golang, produziert effiziente Standalone-Binaries und hat das Potential, in vielen Fällen die Notwendigkeit von Containern in Frage zu stellen...)
* Eine große Vielfalt an verfügbarer energiesparender Hardware zur Umsetzung von Edge Computing-Projekten (ARM & Co.?)
* Eine genauso große Vielfalt an noch energiesparender Hardware zur Umsetzung von intelligenten Sensoren und Steuerungen (NodeMCU & Co?)
* Ein Upgrade von geschäftskritischen, geschlossenen SaaS-Cloud-Plattformen mit Vendor-Lock, hin zu interoperablen Edge-Plattformen mit offenen Protokollen und Standards
* Ganz allgemein: ein gesund wachsendes Ökosystem aus „true“ OpenSource-Komponenten als Basis für eigene Projekte (NetBSD, PostgreSQL, Golang, Python, Lua…)
* ReactOS als vollwertiger Windows-Ersatz ;-)
Viele Grüße Matthias
Am 27.05.20 um 12:13 schrieb Matthias Petermann:
Hallo Thomas,
On 27.05.20 09:25, Thomas Güttler Lists wrote:
Was wird die Zukunft aus eurer Sicht für
schöne Dinge bringen?
Ein schönes Thema bringst Du da auf den Tisch. Ich denke die Zukunft verdient und bringt eine Trendwende im Energieverbrauch (und damit der Systemanforderungen) insbesondere für Clients. Und etwas mehr Wertschätzung für nachhaltige Lösungen, welche die Souveränität ihrer Nutzer bewahren.
Zum Energieverbrauch:
...
Sehr interessantes Thema. Um effizient Optimieren zu können müsste man erstmal wissen wo wieviel
Energie verschwendet wird. Dann könnte man überlegen mit welchen Maßnahmen am meisten
Energie gespart werden kann.
Oder ist der Effizientsgedanke hier nicht so angebracht, und es geht eher "um die Gute Tat"?
In letzter Zeit ging alles Richtung Web. Dort dominiert auf Client-Seite Javascript mit seinen bekannten Eigenschaften. Selbst von den Herstellern angebotene "Standalone-Apps" sind in Wirklichkeit meist nur Web-Apps mit Electron-Umverpackung. Man gewinnt also ökologisch außer einer besseren Integration zum Host-OS nichts. Die alte Gleichung – CPU und RAM ist billiger als der „kostbare“ Entwickler geht meiner Meinung nach schon lange nicht mehr auf und vernachlässigt den Fakt, dass zumindest die laufenden CPU-Kosten direkt an den Energieverbrauch gekoppelt sind. Niemand sollte mehr so tun, als stünden Ressourcen unbegrenzt zur Verfügung. Die Strompreise steigen steigen steiler als die Stundensätze der Offshore-Entwickler, und nur der Wegwerfmentalität der meisten Benutzer ist es zu „verdanken“, dass dieses Problem kaum wahrgenommen wird.
Zur Bewertung eines Clients würde ich deshalb auch die erwartete Häufigkeit und Dauer der Nutzung in die Gleichung einbringen. Beispiele: (a) ein System zum Bestellen bei einem Menüservice darf gern eine Web-App sein. Die Nutzung erfolgt pro Client höchstens einmal täglich. Dafür lohnt sich kein nativer Client und die Vorteile der zentralen Bereitstellung überwiegen. (b) eine Kommunikationsanwendung (vgl. Microsoft Teams) sollte keine Web-App sein. Die Nutzung erfolgt aktiv mehrmals täglich für mehrere Stunden, und passiv im Prinzip den ganzen Tag (die App muss offen bleiben, damit man angerufen werden kann). Der Overhead, der durch die verwendete Technologie entsteht, ist enorm. Hier sollte alternativ ein nativer Client zur Verfügung stehen, der vorhandene Client-Ressourcen effizient nutzt. Schade, dass der Blaue Engel[1] bisher nur auf den Rechenzentrumsbetrieb abzielt und die gefühlt mindestens genauso große Komponente – die vielen Millionen Smartphone- und Laptop-Akkus, die täglich geladen werden – außer Acht lässt.
Ich persönlich finde es super, dass ich bei einem Web-basiertem Office einfach den Browser schließen kann, und dann
eine halbe Stunde (wenn ich zB unterwegs bin), das Dokument mit meinem Smartphone öffnen kann, und schnell noch
einen Gedanken hinzufüge.
Ich finde es auch super, dass ich nicht mehr strg-s zum Speichern drücken muss. Noch besser ist, das ich kein Backup
machen muss.
Die Bequemlichkeit ist magisch.
Wieviel Strom könnte durch Verwendung eines offline-Office anstatt eines online-Office gespart werden?
Zur Souveränität:
Beim Thema Souveränität tangiert mich nicht der Fakt, dass die Daten außerhalb der eigenen physikalischen Reichweite liegen, sondern eher der Umstand, dass im Bereich der SaaS-Provider in teilweise großem Umfang Vendor-Locks hingenommen werden müssen. Als geschäftsschädigend könnte man das übertrieben betrachtet im Bereich Office-Anwendungen (Textverarbeitung, Spreadsheet, Dokumentenmanagement, Projektmanagement) bezeichnen; als katastrophal in den Bereichen Kommunikation (E-Mail, Instant Messaging, Videotelefonie) und Automatisierung (Smart Home).
Ich persönlich freue mich deshalb zukünftig in loser Folge auf:
- Einen kritischen Umgang mit Web-Apps und einen Konsens darüber, wann
diese Sinn ergeben und wann nicht (Häufigkeit und Dauer der Nutzung * Anzahl der Nutzer?)
- Eine Wiederbelebung der Ideen von vergessenen Cross
Platform-Technologien zur Umsetzung von nativen, energieeffizienten Client-Anwendung (z.B. Lazarus – kennt das noch jemand?)
- Energieersparnisse durch Vereinfachung der Server-Architekturen –
etwa durch Abbau von organisatorisch motivierten technischen Abstraktionsebenen
- Mehr Nutzung von modernen, effizienten compilierten Sprachen auf
Serverseite (z.B. Golang, produziert effiziente Standalone-Binaries und hat das Potential, in vielen Fällen die Notwendigkeit von Containern in Frage zu stellen...)
- Eine große Vielfalt an verfügbarer energiesparender Hardware zur
Umsetzung von Edge Computing-Projekten (ARM & Co.?)
- Eine genauso große Vielfalt an noch energiesparender Hardware zur
Umsetzung von intelligenten Sensoren und Steuerungen (NodeMCU & Co?)
- Ein Upgrade von geschäftskritischen, geschlossenen
SaaS-Cloud-Plattformen mit Vendor-Lock, hin zu interoperablen Edge-Plattformen mit offenen Protokollen und Standards
- Ganz allgemein: ein gesund wachsendes Ökosystem aus „true“
OpenSource-Komponenten als Basis für eigene Projekte (NetBSD, PostgreSQL, Golang, Python, Lua…)
- ReactOS als vollwertiger Windows-Ersatz ;-)
Viele Grüße Matthias
Da stimme ich dir voll zu. Und für den Punkt Souveränität gibt es aus meiner Sicht
auch gute Nachrichten: Nextcloud. Obwohl das aktuell sich eher
in Richtung online-Office entwickelt (was ich gut finde).
Danke für deine Idee!
Gruß,
Thomas
Hi,
On 2020-06-01 09:35, Thomas Güttler Lists wrote:
Am 27.05.20 um 12:13 schrieb Matthias Petermann:
On 27.05.20 09:25, Thomas Güttler Lists wrote:
Was wird die Zukunft aus eurer Sicht für
schöne Dinge bringen?
Ein schönes Thema bringst Du da auf den Tisch. Ich denke die Zukunft verdient und bringt eine Trendwende im Energieverbrauch (und damit der Systemanforderungen) insbesondere für Clients.
Das sehe ich etwas pessimistischer: auf dem Client gibt es niemanden der mitzählt und dann die Optimierung bezahlt. Solange es nicht normal ist dass das Betriebssystem den Fensterbalken rot einfärbt wenn die Applikation Energie verbraucht wird es niemanden interessieren. Beim Browser müssten entsprechend die Tabs eingefärbt werden. Problem in beiden Fällen: wie zählt man den Verbrauch der indirekt verursacht wird (Applikation beauftragt einen Service etwas zu tun).
Selbst auf dem Smartphone zeigt mir das System den App-Verbrauch nur wenn ich tief in den Settings grabe und für Web-Apps nur den Gesamtverbrauch meines Browsers.
Ganz anders sieht das auf der Server-Seite oder in Fabriken aus: "Green IT" ist ein Thema, denn Energieverbrauch findet sich als erheblicher Posten in der Bilanz wieder. Es gibt ganze Ausgaben von IT-Zeitschriften die dieses Thema beackern, in jeder zweiten iX ist eine Anzeige zu diesem Thema. Oder z.B. in der Halbleiterindustrie gibt es einen ganzen Standard der sich mit nix anderem als Energiesparen beschäftigt (hier allerdings auf Maschinenebene - die eingebauten Server verbrauchen nur einen winzigen Bruchteil der Energie).
Und etwas mehr Wertschätzung für nachhaltige Lösungen, welche die Souveränität ihrer Nutzer bewahren.
Auch hier bin ich skeptisch: solange Facebook und Co. Erfolg haben weißt das darauf hin dass die Menschheit keine Lust auf ihre Grundrechte hat...
...schade eigentlich.
Zum Energieverbrauch:
...
Sehr interessantes Thema. Um effizient Optimieren zu können müsste man erstmal wissen wo wieviel Energie verschwendet wird. Dann könnte man überlegen mit welchen Maßnahmen am meisten Energie gespart werden kann.
Oder ist der Effizientsgedanke hier nicht so angebracht, und es geht eher "um die Gute Tat"?
Client-Seite, Systeme für privat: wenn Du ein grünes Label draufkleben kannst wird es gekauft. Was das Label aussagt wird nicht hinterfragt (weil es kaum jemand einschätzen kann). Deine Applikation müsste schon extrem verschwenderisch sein damit man es sofort am Handyakku oder am aufheulenden Lüfter merkt. Da Features verkaufbar sind sollte klar sein wofür die Entwickler Zeit und Budget bekommen.
Industrielösungen: je größer die Fabrik, umso größer der Druck den Dein Kunde ausüben wird damit es tatsächlich Energie (-Kosten) spart. Irgendwann kommt die IT-Abteilung angemeckert und zeigt Dir den CPU-/Energieverbrauch Deiner Lösung im Vergleich zu anderen VMWare-Instanzen und wird Dir eine Standpauke halten weil Du die Performance des ganzen Hosts runterziehst. Etwa gleichzeitig wird das mittlere Management sich beschweren dass sie andauernd neue teure (virtuelle) Server von IT kaufen müssen und das obwohl gerade gespart werden muss! Die Techniker/Admins werden sich beschweren dass Deine Applikation ständig Speicher einsammelt und aller naselang neu gestartet werden muss damit der Server nicht crasht. Die Ingenieure werden sich beschweren "dass das alles zu lange dauert bis man hier ein Ergebnis auf dem Bildschirm sieht". Sprich: irgendwann wirst Du mehrere Monate Budget bekommen um zu Optimieren. (Alles schon im Real Life[tm] erlebt.)
Die Optimierung an sich geht mit Standard-Tools (Methode des scharfen Hinsehens, Profiler, Call-Tree-Analyse, erfahrene Kollegen fragen, ...), sie ist nur extrem zeitaufwändig und erfordert wesentlich mehr Expertise als normales "Features rausfeuern" ohne ein direkt sichtbares Ergebnis zu bringen. Du kannst Dir denken wo im Allgemeinen die Priorität gesetzt wird.
Ich persönlich finde es super, dass ich bei einem Web-basiertem Office einfach den Browser schließen kann, und dann eine halbe Stunde (wenn ich zB unterwegs bin), das Dokument mit meinem Smartphone öffnen kann, und schnell noch einen Gedanken hinzufüge.
Ich finde es auch super, dass ich nicht mehr strg-s zum Speichern drücken muss. Noch besser ist, das ich kein Backup machen muss.
Strg-S ist eine keine Eigenschaft des Web- vs. Offline-Modells, sondern wie die Applikation programmiert wird. Bei einem Office macht Buffering+Save durchaus Sinn, weil ich mich ab und zu komplett vertun werde und das falsche Kapitel lösche. Bei Web-Apps ist es nur extrem sinnlos alle Daten erstmal nur im Browser abzulegen und potentiell zu verlieren, deswegen werden sie sofort an den Server übermittelt und dort live in die Datei gepatcht.
Expertenapplikationen benutzen auch auf dem Desktop gerne mal das Live-Storage Paradigma ohne Strg-S, da entweder die gehandhabten Datenmengen zu groß sind um sie im Speicher zu halten oder weil live mit einer Datenbank, einer Maschine oder einem Server kommuniziert wird.
Die Bequemlichkeit ist magisch.
Ich benutze Web-Office gerne mal wenn ich gemeinsam mit anderen Kollegen eine große Tabelle pflegen muss auf die alle gleichzeitig Zugriff brauchen, aber um z.B. eine Spec zu schreiben ist es meiner Meinung nach einfach mal zu unbequem. Selbst in Telefonkonferenzen benutze ich lieber Screen-Sharing.
Wieviel Strom könnte durch Verwendung eines offline-Office anstatt eines online-Office gespart werden?
Ich habe keine konkreten Zahlen, aber wenn ich top beobachte während online/offline Applikationen laufen würde ich sagen dass Web-Apps gefühlt um Faktor 4-10 mehr CPU verbraten, plus was auch immer der Server in der selben Zeit verbrät. Eine tatsächliche Statistik wäre mal interessant... falls jemand Langeweile hat!?
Konrad
Hallo Konrad,
Am 01.06.2020 um 12:52 schrieb Konrad Rosenbaum:
Das sehe ich etwas pessimistischer: auf dem Client gibt es niemanden der mitzählt und dann die Optimierung bezahlt. Solange es nicht normal ist dass das Betriebssystem den Fensterbalken rot einfärbt wenn die Applikation Energie verbraucht wird es niemanden interessieren. Beim Browser müssten entsprechend die Tabs eingefärbt werden. Problem in beiden Fällen: wie zählt man den Verbrauch der indirekt verursacht wird (Applikation beauftragt einen Service etwas zu tun).
die Idee finde ich sehr gut! Im Task-Manager des aktuellen Windows 10 2004 ist mir zufälligerweise vergangenes Wochenende zum ersten Mal aufgefallen, dass die Ressourceninanspruchnahme (CPU, RAM, IO, Netzwerk) jetzt als Heatmap visualisiert, und um je eine Spalte für den aktuellen und den mittleren Stromverbrauch ergänzt wurde. Einen solchen Indikator für die Titelleiste der Fenster zu haben wäre ein guter Anfang.
Viele Grüße Matthias
Hallo alle;
Am 01.06.20 um 09:35 schrieb Thomas Güttler Lists:
Sehr interessantes Thema. Um effizient Optimieren zu können müsste man erstmal wissen wo wieviel Energie verschwendet wird. Dann könnte man überlegen mit welchen Maßnahmen am meisten Energie gespart werden kann. Oder ist der Effizientsgedanke hier nicht so angebracht, und es geht eher "um die Gute Tat"?
Diese Frage treibt mich auch schon seit längerem um. Dann schaue ich mir an, was etwa konkret Google im Blick auf Energie-Effizienz und "Green IT" tun, und was ich (mit KMU-Brille) dort realistisch umsetzen kann. Auch im Blick auf Datenhoheit, digitale Autonomie und Selfhosting: Gibt es belastbare Studien zur Frage, wie Energie-Effizienz in diesem oder jenem Szenario aussieht? Ist ein System mit einigen wenigen Anbietern, die optimiert große Infrastruktur betreiben, wirtschaftlicher als eines mit sehr vielen kleinen?
Wieviel Strom könnte durch Verwendung eines offline-Office anstatt eines online-Office gespart werden?
Deine Ideen zu Usability und Komfort teile ich hier. Meine Frage ginge hier eher in eine andere Richtung: Eigentlich will ich "mobil" arbeiten können. Ich möchte meine Daten halbwegs elegant stets auf allen relevanten Geräten finden. Ist das zwingend gleichbedeutend mit "online"?
Simples Beispiel: Wenn ich die Bilder von der Smartphone-Kamera einfach auf den Linux-Laptop bekommen will (der 10cm daneben steht), dann führen nahezu alle "Standardwege" vom Smartphone über irgendein Fernverkehrsnetz zu irgendeinem Server und von dort zurück zum Laptop. Warum muss das so sein? Manchmal glaube ich, bei allen guten Ideen, die es in den letzten Jahr(zehnt)en gab, ist an vielen Stellen hier unsere Fantasie auf Client/Server-Lösungen beschränkt. Warum haben wir noch nicht so etwas wie "syncthing-in-gut/-schnell", das die 10cm zwischen den beiden Geräten im Beispiel überbrücken kann ohne Server? Warum kann ich nicht selbiges für Office-Dokumente, Musik, ... tun - Geräte nebeneinanderlegen und mit zwei Taps oder Knopfdrücken lokal *schnell* synchronisieren? Als Nerd bekomme ich das mit etwas Frickelei hin, aber das funktioniert weder bequem noch schnell. Als End-User schaffe ich das vermutlich nicht. Was könnte man hier an Energie sparen für Netzwerk-Traffic, der mit besserer Implementation, mehr echter Dezentralität, mehr P2P vermeidbar wäre?
Viele Grüße, Kristian
On Tue, Jun 2, 2020 at 7:54 AM Kristian Rink mail@zimmer428.net wrote:
Deine Ideen zu Usability und Komfort teile ich hier. Meine Frage ginge hier eher in eine andere Richtung: Eigentlich will ich "mobil" arbeiten können. Ich möchte meine Daten halbwegs elegant stets auf allen relevanten Geräten finden. Ist das zwingend gleichbedeutend mit "online"?
Seit Erfindung verteilter Versionskontrolle, vulgo Git, nicht mehr. Wenn, so wie ich es im Beruf erlebe, es aber immer noch Absolventen von Informatikstudiengängen gibt, die noch nie etwas von Versionskontrolle gehört haben, ist wohl Hopfen und Bier tatsächlich verloren.
Simples Beispiel: Wenn ich die Bilder von der Smartphone-Kamera einfach auf den Linux-Laptop bekommen will (der 10cm daneben steht), dann führen nahezu alle "Standardwege" vom Smartphone über irgendein Fernverkehrsnetz zu irgendeinem Server und von dort zurück zum Laptop. Warum muss das so sein?
Ist nicht gewollt, weil Google, Apple & Co. ihre Ware gerne genau kennen wollen.
(Merke: Wenn ein Dienst kostenlos ist, dann ist man da nicht Kunde, sondern Ware.)
Manchmal glaube ich, bei allen guten Ideen, die es in den letzten Jahr(zehnt)en gab, ist an vielen Stellen hier unsere Fantasie auf Client/Server-Lösungen beschränkt. Warum haben wir noch nicht so etwas wie "syncthing-in-gut/-schnell", das die 10cm zwischen den beiden Geräten im Beispiel überbrücken kann ohne Server? Warum kann ich nicht selbiges für Office-Dokumente, Musik, ... tun - Geräte nebeneinanderlegen und mit zwei Taps oder Knopfdrücken lokal *schnell* synchronisieren?
Das gab es mal - bei Symbian: (Nokia)-Geräte wurden per Bluetooth gekoppelt - die Richtung des Syncs festgelegt - etwas gewartet - fertig. Alternativ: Speichern/Wiederherstellen des Telefon-Inhalts (inkl Kalender ,Kontakte, Einstellungen) auf/von Speicherkarte. Einziger Nachteil: Diese Sicherungsdateien waren proprietäre Binärklumpen. Das war die erste Funktion, die, welche ich nach Umstieg auf Android vermißt habe. Da ging die Bastelei mit Funabol & Co. los, bis Stand heute Open/Nextcloud das Mittel der Wahl dafür ist.
Moin;
Am 02.06.20 um 15:03 schrieb William Epler:
Ist das zwingend gleichbedeutend mit "online"?
Seit Erfindung verteilter Versionskontrolle, vulgo Git, nicht mehr. Wenn, so wie ich es im Beruf erlebe, es aber immer noch Absolventen von Informatikstudiengängen gibt, die noch nie etwas von Versionskontrolle gehört haben, ist wohl Hopfen und Bier tatsächlich verloren.
Naja. Das - und das (aus meiner Wahrnehmung) Missverständnis, dass "mobiles" Arbeiten eben immer irgendwie Client/Server mit App ist. Das ist schade, weil dort andere gute Ideen verlorengehen oder nicht so vorankommen, wie sie es könnten. Siehe auch Ansätze wie GNUNet, ipfs, dat oder ssb - sehr viele gute Ideen, teilweise auch brauchbare Prototypen, aber letztlich nichts, was in irgendeiner Form "alltagstauglich" wäre. Fehlt hier das grundlegende Verständnis und Interesse?
Warum muss das so sein?
Ist nicht gewollt, weil Google, Apple & Co. ihre Ware gerne genau kennen wollen.
(Merke: Wenn ein Dienst kostenlos ist, dann ist man da nicht Kunde, sondern Ware.)
Durchaus. Von Google und Apple erwarte ich diesbezüglich insofern auch nichts. Aber die Lösungen der FLOSS-Communities gehen ja mehrheitlich in diesselbe Richtung, auch in der fehlenden Differenzierung von Use Cases: Etwa für ein volles Backup meines Mobilgerätes halte ich eine Cloud, in die das transparent passiert, durchaus für vorteilhaft (nur möchte ich das nicht unverschlüsselt und nicht bei Google/Apple haben). Aber für den Transfer etwa von großen Mengen an Bilddateien oder Musik (die ich nur für die Wiedergabe dorthin tue und ohnehin nochmal irgendwo anders gesichert habe) ist der "Umweg" über die Cloud in jeder Hinsicht suboptimal.
(Anekdote am Rand: Wir waren im vorigen Herbst mit Freunden in einer FeWo an der Nordsee, kurz hinter dem Deich. Edge-Hölle. WLAN gab es, aber so konfiguriert, dass die Geräte untereinander nicht kommunizieren durften, und der Weg vom WLAN nach "draußen" war auch merklich < 1MB/s. Und dann kommen dort die Jugendlichen mit Xiaomi- und Apple-Smartphones auf die Idee, Bilder und Videos zwischen den Geräten tauschen zu wollen. Das wäre eine gute Lehrstunde über "Zentralisierung" gewesen, hätte jemand Muße gehabt, zuzuhören..... )
Viele Grüße, Kristian
Hallo Kristian,
Am 02.06.2020 um 07:54 schrieb Kristian Rink:
Diese Frage treibt mich auch schon seit längerem um. Dann schaue ich mir an, was etwa konkret Google im Blick auf Energie-Effizienz und "Green IT" tun, und was ich (mit KMU-Brille) dort realistisch umsetzen kann. Auch im Blick auf Datenhoheit, digitale Autonomie und Selfhosting: Gibt es belastbare Studien zur Frage, wie Energie-Effizienz in diesem oder jenem Szenario aussieht? Ist ein System mit einigen wenigen Anbietern, die optimiert große Infrastruktur betreiben, wirtschaftlicher als eines mit sehr vielen kleinen?
Vermutlich funktioniert die "Optimierung" noch am besten bei Anbietern, die feingranulare Services anbieten (vgl. Amazon Lambda), welche die Infrastruktur dazu komplett unter eigener Kontrolle haben und damit gewisse Zeit nicht abgerufene Ressourcen tatsächlich herunterskalieren. Natürlich auch für die MS/Office365 Welt und Mitbewerber, die dem Tenant keine dedizierten Ressourcen garantieren müssen.
Anders sieht es aus, wenn Unternehmen ihre Bestands-IT ohne grundlegende Architekturänderung in die "Cloud" migrieren, d.h. der VMWare-Host nur vom lokalen Serverschrank in einen Cage im Rechenzentrum wandert. Hier sind meist vertraglich Ressourcen zugesichert - ob die dann auch tatsächlich abgerufen werden oder nicht, ist dann ein anderes Thema. Ich denke in diesem Bereich wird nach wie vor unter dem Label "Cloud" viel Energie verbrannt.
Das ist aber nur mein Gedanke und Beobachtung aus dem letzten Projekt dazu, mit echten Zahlen die Du berechtigterweise gern sehen würdest, kann ich leider nicht aufwarten. Interesse habe ich daran auch, ebenso ob meine Einschätzung in etwa zutrifft oder völlig daneben liegt.
Simples Beispiel: Wenn ich die Bilder von der Smartphone-Kamera einfach auf den Linux-Laptop bekommen will (der 10cm daneben steht), dann führen nahezu alle "Standardwege" vom Smartphone über irgendein Fernverkehrsnetz zu irgendeinem Server und von dort zurück zum Laptop. Warum muss das so sein? Manchmal glaube ich, bei allen guten Ideen, die es in den letzten Jahr(zehnt)en gab, ist an vielen Stellen hier unsere Fantasie auf Client/Server-Lösungen beschränkt. Warum haben wir noch nicht so etwas wie "syncthing-in-gut/-schnell", das die 10cm zwischen den beiden Geräten im Beispiel überbrücken kann ohne Server? Warum kann ich nicht selbiges für Office-Dokumente, Musik, ... tun - Geräte nebeneinanderlegen und mit zwei Taps oder Knopfdrücken lokal *schnell* synchronisieren? Als Nerd bekomme ich das mit etwas Frickelei hin, aber das funktioniert weder bequem noch schnell. Als End-User schaffe ich das vermutlich nicht. Was könnte man hier an Energie sparen für Netzwerk-Traffic, der mit besserer Implementation, mehr echter Dezentralität, mehr P2P vermeidbar wäre?
Danke dass Du Syncthing erwähnst. Konzeptionell finde ich das richtig gut. Funktionell ist es zuweilen mit entsprechender Vorkonfiguration und Einweisung meiner Erfahrung nach auch für Endanwender schon ganz brauchbar. Ein Standalone-Binary, sinnvolle Defaults... meine Eltern gleichen darüber im LAN ihren Bilderordner auf zwei verschiedenen Laptops ab. Gestartet wird es per Desktop-Verknüpfung bei Bedarf. Dadurch konnte ich dort die Einrichtung und Betrieb eines Fileservers bzw. Cloud-Dienstes sparen. Die Einrichtung des auf einem Windows-System naheliegenden OneDrive (oder respektive Nextcloud / Seafile / ...) ist für Endanwender ohne IT-Hintergrund ebenfalls nicht immer intuitiv. Ich teile allerdings deine Grundkritik an Syncthing: schnell ist es nicht gerade und gefühlt sehr ressourcenhungrig. Auf Linux bzw. BSD-Systemen werden schnell die ulimits (maxfiles) zum Problem. Das ist für Anfänger schon die erste Hürde. Zusätzlich steht das Web-UI als primäre Konfigurationsoberfläche dem Endanwender eher im Wege und passt für mich nicht so recht ins Konzept einer Desktop-orientierten Infrastrukturkomponente. Klar, das ist der Tribut an die Plattformunabhängigkeit und die Tatsache, dass sich für Golang noch kein de-facto-Standard native GUI-Toolkit herausgebildet hat, dass auf allen Plattformen gleichermaßen einfach übersetzt werden kann. Die meisten Projekte, die sich der nativen Desktop-Integration von Syncthing widmen, setzen nicht auf Golang sondern auf .NET und Python.
Die Verbesserungsvorschläge zur Usability gehen allerdings in die richtige Richtung[1], leider nicht plattformübergreifend...
Viele Grüße Matthias
Moin Matthias;
Am 02.06.20 um 15:19 schrieb Matthias Petermann:
Vermutlich funktioniert die "Optimierung" noch am besten bei Anbietern, die feingranulare Services anbieten (vgl. Amazon Lambda), welche die Infrastruktur dazu komplett unter eigener Kontrolle haben und damit gewisse Zeit nicht abgerufene Ressourcen tatsächlich herunterskalieren. Natürlich auch für die MS/Office365 Welt und Mitbewerber, die dem Tenant keine dedizierten Ressourcen garantieren müssen.
Jupp, das sehe ich auch, aber ich war noch weiter unten unterwegs. Wenn ich mir den Kram von Google oder anderen "Hyperscalern" so anschaue, dann sehe ich dort Dinge wie: Racks und Kabelführung optimiert auf Luftzirkulation. Teilweise Netzteile von Geräten im Rack, nicht in den Servern. Nutzung der Abwärme für Heizung. Und so weiter und so fort. Als kleineres KMU kann man auf diesem Level nicht optimieren, weil: Abgesehen vom fehlenden Budget für diese Art von Ausrüstung scheitern wir im Allgemeinen schon deutlich früher - dort, wo es überhaupt darum geht, solche Effekte auch nur verläßlich und systematisch messbar und damit auf Prozess-Ebene optimierbar zu bekommen...
[Synchronisation]
Danke dass Du Syncthing erwähnst. Konzeptionell finde ich das richtig gut. Funktionell ist es zuweilen mit entsprechender Vorkonfiguration und Einweisung meiner Erfahrung nach auch für Endanwender schon ganz brauchbar. Ein Standalone-Binary, sinnvolle Defaults... meine Eltern gleichen darüber im LAN ihren Bilderordner auf zwei verschiedenen Laptops ab. Gestartet wird es per Desktop-Verknüpfung bei Bedarf. Dadurch konnte ich dort die Einrichtung und Betrieb eines Fileservers > bzw. Cloud-Dienstes sparen.
Ja, in einem ähnlichen Setup (vorinstalliert/-konfiguriert, Desktop-PCs) betreibe ichg Syncthing auch, so bin ich damals überhaupt erst auf das Tool gekommen. Aber die nächste Idee, auch Smartphone und Tablet dort anzuhängen, sind an mannigfaltigen Hürden gescheitert: Geschwindigkeit, Energie-Verbrauch, die Unfähigkeit von Syncthing (zumindest auf einigen Android-Varianten), auf SD-Karten zu schreiben, ... . Das ist beliebig ärgerlich. Resilio Sync, die "kommerzielle" Variante, ist dort nicht merklich besser. Für Mobile-Synchronisation greif ich in letzter Zeit tatsächlich wieder zum USB-Kabel, das scheint momentan immer noch die robusteste und zügigste Lösung zu sein.
Viele Grüße, Kristian
Am Dienstag, 2. Juni 2020, 07:54:18 CEST schrieb Kristian Rink:
Hallo alle;
...
Simples Beispiel: Wenn ich die Bilder von der Smartphone-Kamera einfach auf den Linux-Laptop bekommen will (der 10cm daneben steht), dann führen nahezu alle "Standardwege" vom Smartphone über irgendein Fernverkehrsnetz zu irgendeinem Server und von dort zurück zum Laptop.
Antwort auf User und Nerd-Niveau: Nein Bild machen, teilen über kdeconnect, fertig. (Kdeconnect oder Gnomeconnect(?), Verbindung zum PC muss vorher einmal aufgenbaut werden, geht nur im gleichen (IPV4?) Netzwerk, für beliebige Dateien so möglich, bequem und schnell, mal probieren, Installation auch über Fdroid möglich)
USB-Kabel anschließen, Datein per USB übertragen, Gerät im Dateimanager finden & Datei von Interesse übernhmen, geht auch
Von Bluetooth halte ich (meistens) icht viel. Ist in den älteren Versionen schlicht zu langsam für Bilder (80 kByte/s).
Grüße! Bernhard
Hallo alle;
Am 02.06.20 um 16:19 schrieb Bernhard Schiffner:
Antwort auf User und Nerd-Niveau: Nein Bild machen, teilen über kdeconnect, fertig. (Kdeconnect oder Gnomeconnect(?), Verbindung zum PC muss vorher einmal aufgenbaut werden, geht nur im gleichen (IPV4?) Netzwerk, für beliebige Dateien so möglich, bequem und schnell, mal probieren, Installation auch über Fdroid möglich)
Ja, kdeconnect kommt dem, was ich mir vorstelle, hier tatsächlich am nächsten. Für einzelne Dateien funktioniert das auch recht gut, dto. das Spiegeln von Benachrichtigungen. Drawbacks: Synchronisation größerer Ordner ("alle Fotos aus dem Urlaub" oder Abgleich der Musiksammlung) ist hier *extrem* langsam, und außerhalb von KDE (bzw. GNOME im Falle von gsconnect) ist es nur eingeschränkt sinnvoll verwendbar.
USB-Kabel anschließen, Datein per USB übertragen, Gerät im Dateimanager finden & Datei von Interesse übernhmen, geht auch
Tatsächlich ist das, in Verbindung mit (g)rsync, dieser Tage immer noch mein Weg der Wahl. Funktioniert gut, ist aber irgendwie anachronistisch und auch noch eher "nerdig" als endnutzertauglich. Von einer Synchronisation zwischen zwei Mobilgeräten reden wir dort noch gar nicht - etwa für das Kopieren von Fotos auf das Tablet. Dann fängt man doch wieder an, mit Bluetooth 'rumzuschrauben, oder mit mobilem WiFi-Hotspot oder solchem Zauber. Alles "irgendwie" lösbar, aber fernab davon, schön, elegant oder leicht zu erklären zu sein... ;)
Viele Grüße, Kristian
(Das Folgende ist nur zu lesen, wenn man alte-Herren-Rants verträgt.)
Die Zukunft wird bringen, was sie mag, was irgendwer tut und in Umlauf bringt. Bezüglich Software bin ich eigentlich auch ohne Zukunft glücklich ...
Vor nunmehr 22 Jahren war die erste Programmiersprache, die ich (etwas ernsthafter) auf einem Linux-Rechner verwendete, Perl. Später folgte Bash und QT für GUI-Programmierung. Sind diese Sprachen Turing vollständig? Ich glaube, ja. Es ist also kein Problem, sich mit irgendeiner davon in den Fuß oder das Knie zu schießen. Mit Python müßte ich mal was machen (Blender / Openoffice bieten sich an), aber das hat schon viel warten können, und wird es vermutlich auch weiterhin tun. G++ (oder war's D+/E+/F+ ?) wird wohl bei mir nichts. Gehen und rosten fällt wohl auch aus ... (Ich bin froh, etwas von Lambdas zu ahnen. Aber C++20 .. wartet schon auf sein Opfer ...)
Also zu gut Deutsch: was soll mir der ganze moderne Sch...?
Kurz nachdem ich gelernt hatte, mit QWidgets klar zu kommen, wurde QML das Mittel der Wahl. (Natürlich 1 Jahr später dann QML2, deutlich inkompatibel. Und die Schnittstelle zwischen "normalem" QT-Code und QML ist (für mich) immer noch nicht zu debuggen.) Also warte ich auf QT6, die Lösung aller Probleme. (Deutet sich da aber was mit Lizenzen o.ä. an?) Gut Ding will Weile haben, also warte ich seit 1998 darauf, dass die realtime-extensions endlich mal in den Mainline-Kernel kommen. Vielleicht wird es ja dieses Jahr noch ... LWN (J. Corbet) hatte in der Vergangenheit immer Voraussagen dazu gemacht, das aber vor vielleicht 5 Jahren aufgegeben ...
Du siehst: ziemliche Desillusionierung meinerseits.
(Bezüglich der alten Anfrage an die Liste: bestimmt gibt es noch Leute, die ed als Editor benutzen (können), aber mit Sicherheit ist das nicht mehr Mainstream. Ich habe mich mit meiner Präferenz (kate) nie im VIM/EMACS Duell zu Wort gemeldet. Konrads Unterscheidung zwischen "gegenwärtig im Gespräch" und "in der Anwendung" als orthogonale Ebene zu (nur linear) "dead end", fand ich toll.)
Interessant wird m.M. Zukunft durch Dinge, die "um die Ecke" liegen, also (meistens) nicht das eigentliche Entwicklungsziel waren. Am Beispiel der Realtime-Extensions des Linux-Kernels: - HR timers sind (länger schon) Mainline, - treaded Interrupts, - priority inheritance (von der Linus T. meinte, dass diese unter Freunden nicht gehandelt werden sollte ;-) ), - NoHz, - lockdebug, - CPU-hotplug / sleeping, - und ... wurden daraus abgeleitet und schon in Mainline übernommen, so dass "fast nur noch" die Hauptsache, die Übertragung per Compiler-Magie von Spin-Locks in sleeping Spin-Locks, als eigentlicher Patch übrig ist. Vielleicht wird's ja dieses Jahr...
Also tragt herzu, was an Ideen greifbar ist. Die meisten werden ihr unvermutetes und lang benutztes Anwendungsfeld finden. Aber Voraussagen, was die Zukunft bringen wird, sind schwer (Karl Valentin?).
Kopf hoch! Zukunft kommt, ob wir wollen oder nicht. Aber erstens anders und zweitens als man denkt. Solange der eigene Beitrag <>0 ist, wirkt die Infinitesimalrechnung: das größte Ergebnis kann aus kleinsten Größen abgeleitet werden.
Viele Grüße! Bernhard
Am Mittwoch, 27. Mai 2020, 09:25:02 CEST schrieb Thomas Güttler Lists:
Hallo,
..
Living Ends. Also was wird die Zukunft aus eurer Sicht für schöne Dinge bringen?
Hi,
ich find ja schonmal den Titel "Living Ends" (deutsch: Das Leben endet) hinreichend depressiv für eine Diskussion der Zukunft... ;-)
(Eine Diskussion der Ähnlichkeit zwischen Gerundien und spezifischen Adjektiven, Plural von Nomen und der 3. Person von Verben in der englischen Sprache erspare ich Euch mal...)
On 2020-05-27 20:44, Bernhard Schiffner wrote:
Kurz nachdem ich gelernt hatte, mit QWidgets klar zu kommen, wurde QML das Mittel der Wahl. (Natürlich 1 Jahr später dann QML2, deutlich inkompatibel. Und die Schnittstelle zwischen "normalem" QT-Code und QML ist (für mich) immer noch nicht zu debuggen.)
Mach Dir nix draus - ich bin auch einer von denen die sich QML verweigern. Schon weil ich das verwendete Javascript nicht als Sprache, sondern als Folter bezeichne...
Also warte ich auf QT6, die Lösung aller Probleme. (Deutet sich da aber was mit Lizenzen o.ä. an?)
Bitte Qt6 (kleines "t", sonst gibt es Leute die es mit QuickTime verwechseln).
Qt6 wird aus Nutzersicht keine Revolution werden - im Wesentlichen ist es eine Antwort auf den BC-Stau (BC=binary compatibility) - über die ca. 10 Jahre Qt5 haben sich sehr viele Probleme angehäuft die nicht binärkompatibel gelöst werden können oder die Umbauten in der API brauchen. Qt verspricht aber innerhalb eines Major-Release BC und SC (source comp.) zu bleiben.
Der Plan ist ein Release zu bauen welches weitestgehend (aber nicht komplett) SC ist und sich haufenweise BC-Brüche in Kernkomponenten erlaubt (z.B. QString). Ein paar Komponenten stehen auf der Abschussliste (z.B. QList soll durch QVector ersetzt werden). Ein paar APIs werden in andere Module umsortiert oder in neue Module ausgelagert.
Die allermeisten Qt5-Programme werden also mit sehr wenig Aufwand (Ziel ist weniger als bei Qt4 -> Qt5) auf Qt6 portierbar sein.
Die Innovationen mit neuen APIs, neuen Modulen etc. sind schon in den späteren Versionen von Qt5 passiert (Qt5.15 bringt z.B. einen PDF Viewer).
Du siehst: ziemliche Desillusionierung meinerseits.
...passt ja zum Subject der Mail... ;-P
Konrad
Am 29.05.20 um 11:02 schrieb Konrad Rosenbaum:
Hi,
ich find ja schonmal den Titel "Living Ends" (deutsch: Das Leben endet) hinreichend depressiv für eine Diskussion der Zukunft... ;-)
Früher oder später stürzt die Erde in die Sonne.
Ja, das Subject war von mir ungeschickt gewählt worden.
Es sollte eben das Gegenteil von "Dead Ends" sein.
Also die Frage nach den offenen Straßen, in denen
die Technik der Zukunft entwickelt wird.
Entsprechend wurde das Subject zu "Future" geändert.
Trotzdem kamen schon sehr interessante Gedanken.
Schön, danke!
Gruß,
Thomas
Hallo,
On Wed, May 27, 2020 at 09:25:02AM +0200, Thomas Güttler Lists wrote:
Also was wird die Zukunft aus eurer Sicht für schöne Dinge bringen?
ich muss ehrlich sagen, dass ich da was Software angeht sehr pessimistisch bin. Ich sehe "We can solve any problem by introducing an extra level of indirection." überall. Was an "neuen" Konzepten kommt ist aufgewärmtes Zeugs aus den siebzigern...
Echte bahnbrechende neue Wege sehe ich keine. Aber vll. ist das auch nur ein Zeichen dafür, dass wir endlich eine "erwachsene" Industrie sind.
Meine letzte "echte" Neuerung war git, und das ist auch bloss applied science also nicht wirklich Innovation im wissenschaftlichen Sinne.
Der ganze Docker - Container - Cloud Kram... Ja. Von der Umsetzung her neu, aber interlektuell nix bahnbrechendes. Client - Server - nen Layer hier, nen Layer da. Das ist wie "Drei Liter Verbrenner" schick, aber keine Wende.
Grüsse Andreas
-- The three chief virtues of a programmer are: Laziness, Impatience and Hubris. -- Larry Wall
Moin;
weil das gerade passt und ich am Wochenende dazu längere Diskussionen hatte:
Am 06.06.20 um 23:56 schrieb Andreas Fett:
ich muss ehrlich sagen, dass ich da was Software angeht sehr pessimistisch bin. Ich sehe "We can solve any problem by introducing an extra level of indirection." überall. Was an "neuen" Konzepten kommt ist aufgewärmtes Zeugs aus den siebzigern...
Siehe kurz dies hier:
https://signal.org/blog/the-ecosystem-is-moving/
"In some circles, this has not been a popular opinion. When someone recently asked me about federating an unrelated communication platform into the Signal network, I told them that I thought we’d be unlikely to ever federate with clients and servers we don’t control. Their retort was “that’s dumb, how far would the internet have gotten without interoperable protocols defined by 3rd parties?”
I thought about it. We got to the first production version of IP, and have been trying for the past 20 years to switch to a second production version of IP with limited success. We got to HTTP version 1.1 in 1997, and have been stuck there until now. Likewise, SMTP, IRC, DNS, XMPP, are all similarly frozen in time circa the late 1990s. To answer his question, that’s how far the internet got. It got to the late 90s."
=> Ist der Drang zur Abwärtskompatibilität und dem Verharren in "Bekanntem", Bewährtem ein Problem? Schaffen wir es nicht, grundsätzlich neue Ideen zu denken, weil wir letztlich immer wieder darauf zurückfallen, Bekanntes nutzen zu wollen, sei es konkret technologisch (IP, E-Mail, XMPP) als auch konzeptuell (Client-Server-Architekturen)? Oder sind wir nur zu ungeduldig angesichts des Umstands, immer noch in einer relativ jungen und schnellen Branche unterwegs zu sein, während andere Industrien noch bedeutend langsamer mit bedeutend längeren Lebens- und Entwicklungszyklen arbeiten...?
Viele Grüße, Kristian
lug-dd@mailman.schlittermann.de
-
Andreas Fett -
Bernhard Schiffner -
Konrad Rosenbaum -
Kristian Rink -
Matthias Petermann -
Thomas Güttler Lists -
William Epler