|
|
|
|
|
|
|
Japp. Autocrypt macht die Verschlüsselung verständlich und zugänglich. Ich erwarte dann oben unter den Mailadressen, Betreff usw. eine Toolbar bei der man draufklickt „Ab jetzt verschlüsselte Emails an Rufus“. Weil im Header steht, dass Rufus Mailclient die entschlüsseln kann und wir seine (vermeintlichen) Public-Key erhalten haben.
Und das ist genau der Schritt, der so schrecklich kompiliziert gemacht wird. Public-Key, Private-Key, Verschlüsselungsart, Stärke und dann den Public von anderen einsammeln und den eigenen Verteilen und Vertrauen zuweisen, aber irgend wer hat da alles mit Keyservern verseucht.
Wenn ich Autocrypt richtig verstehe, wird das hoffentlich so umgesetzt wie „Load Remote Images always from @mods.de“.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 24.04.2018 0:01]
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
IOW Es ist bald 2020 und die Gnome-Jungs fummeln sich da nen GC zusammen, der hinter dem Stand der 90er zurückbleibt.
| |
Kannst du das, wenn du magst, ein bisschen ausführen? 
Was ist an deren GC schlecht (ist GC generell in dem Fall schlecht?) und was würde man egtl anders machen?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Japp. Autocrypt macht die Verschlüsselung verständlich und zugänglich. Ich erwarte dann oben unter den Mailadressen, Betreff usw. eine Toolbar bei der man draufklickt „Ab jetzt verschlüsselte Emails an Rufus“. Weil im Header steht, dass Rufus Mailclient die entschlüsseln kann und wir seine (vermeintlichen) Public-Key erhalten haben.
Und das ist genau der Schritt, der so schrecklich kompiliziert gemacht wird. Public-Key, Private-Key, Verschlüsselungsart, Stärke und dann den Public von anderen einsammeln und den eigenen Verteilen und Vertrauen zuweisen, aber irgend wer hat da alles mit Keyservern verseucht.
Wenn ich Autocrypt richtig verstehe, wird das hoffentlich so umgesetzt wie „Load Remote Images always from @mods.de“.
| |
Mir ist letztens zufällig aufgefallen, dass ich mit jemandem, dessen Key ich in enigmail habe, plötzlich (wohl seit em 1.0.0) den Mailbody auch als Autocrypt-Schiffrat austausche wenn ich nicht aktiv pgp-verschlüsseln wähle. Hätte ich da nicht zufällig in den Mailsource geschaut wüsste ich gar nichts von autocrypt. Das ist schon sehr "Auto". 
Um so interessanter, dass unsere Clients dann wohl im Vorfeld "heimlich" die Nutzung ausgemacht haben..
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Rufus am 24.04.2018 11:57]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ist es am Ende wahrscheinlich, aber ich finde die Infobasis dazu haarsträubend.
Zufällig in den Source einer Mail schauen, wundern, Keyword googlen, These aufstellen dass das kürzliche Enigmail-Update damit zusammenhängt, die buzzword-verseuchte "Marketingseite" von autocrypt finden, ein github-Repo und einen oberflächlichen Heise-Artikel, mit hoschi besprechen, welche der bisherigen Vermutung wohl zutreffen.
Sorry, dagegen sind le-wildcards und ntpd gut dokumentiert. 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von MartiniMoe
| | Zitat von csde_rats
IOW Es ist bald 2020 und die Gnome-Jungs fummeln sich da nen GC zusammen, der hinter dem Stand der 90er zurückbleibt.
| |
Kannst du das, wenn du magst, ein bisschen ausführen?
Was ist an deren GC schlecht (ist GC generell in dem Fall schlecht?) und was würde man egtl anders machen?
| |
Anscheinend erfasst das System keine Referenzen zwischen Objekten, weswegen bei einem Löschen von A (mit A->B, A->C, B->D) zwar die Refcounts von B und C angepasst werden, aber B und C erst im nächsten Durchgang des GC erfasst werden (und der GC läuft das nächste mal vielleicht erst übermorgen). Wenn man ARC macht, erfasst man das normalerweise. Wenn ich dann A lösche, löscht der GC im gleichem Atemzug auch B, C und D (sofern keine anderen Referenzen existieren); und die meisten ARC-GCs können in der Praxis auch Dinge wie A->B->C->A in einem Durchgang entsorgen. So funktionieren die GCs der meisten Bytecode-Skriptsprachen wie Python, Ruby, PHP etc.
Die leistungsfähigere Art von GC läuft unter Tracing/Compacting GC, wo der GC quasi eine Liste von Objekten hat und es keine Refcounts gibt, weil er einfach alle Orte, wo Referenzen auf Objekte sein können, nach Referenzen absucht. Wenn ein Objekt X an keinem dieser Orte genannt wird, kann es gelöscht werden. Meistens können diese GCs auch Objekte im Addressraum verschieben, was Performance-Vorteile bringt/bringen kann (etwa wenn häufig verwendete Objekte zusammengeschoben werden). Das ist die Art von GC, wie du sie z.B. in einer Desktop/Server-JVM findest.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 24.04.2018 13:24]
|
|
|
|
|
|
|
|
|
Richtig. Wann und wie der GC läuft ist ebenso nicht garantiert. Damit einher gehen periodischen Lastspitzen (wechselnd Hauptspeicher, dann Prozessor). Hässlich wird es - mir schon passiert - wenn der GC stirbt. Mit ranzigem Code, den man mit viel Hardware bekämpft hat, passiert sowas schon mal.
Ich sollte besser klar stellen, dass ich bei Reference Counting an Automatic Reference Counting wie bei Objectiv-C (von 2007 bis 2012 GC) und SWIFT denke, da gibt es eben keine Garbage Collection. Ist mir schon beim Lesen des Blogs passiert, Reference Counting mit GC != Automatic Reference Counting. Und es gibt die klassische manuelle Speicherverwaltung, wie bei C und C++, oder RAII, etwa bei Rust oder zum Teil C++.
Ich kenne GObject von GNOME nicht wirklich. GObject sollte doch dafür verantwortlich sein, JavaScript mit dem restlichen System zu verbinden? Vermutlich fehlen hier die grundlegenden Informationen, damit der GC in GJS direkt im ersten Lauf jeglichen unnötigen Speicher wegräumt.
// edit
Mir war nicht klar, dass Go noch Garbage-Collection verwendet.
|
|
[Dieser Beitrag wurde 8 mal editiert; zum letzten Mal von hoschi am 24.04.2018 14:41]
|
|
|
|
|
|
|
|
|
|
Schlechter Code ist schlecht. No shit.
|
|
|
|
|
|
|
|
|
|
|
Wahrheit fühlt sich so hart an 
|
|
|
|
|
|
|
|
|
|
|
|
Ich habe halt wirklich noch kein Softwareprojekt gesehen, dass an der Sprache gescheitert ist. Auch wenn das wahrscheinlich gerne einige Leute behaupten würden. Verschissenes Systemdesign und noch verschissenere Implementierungen hingegen...
|
|
|
|
|
|
|
|
|
|
|
Dieses Forum läuft mit PHP und ist nicht tot zu kriegen 
|
|
|
|
|
|
|
|
|
|
|
|
Was ich von modernem PHP gesehen habe, sieht auch nicht schäbiger aus als vergleichbare Sprachen. Und Legacycode ist in keiner Sprache spassig, wobei ich da zum Beispiel Eiffel positiv hervorheben würde.
|
|
|
|
|
|
|
|
|
|
|
Sehe ich auch so.
Ich habe zu Anfang COBOL gelernt. Definiere Legacy-Code?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 24.04.2018 14:42]
|
|
|
|
|
|
|
|
|
Ich würde nichtmal unbedingt Code als legacy bezeichnen, sondern Projekte. Keine Automation, kein geregeltes Dependencymanagement, schlechtes Tooling, fehlende oder veraltete Dokumentation usw.. Projekte, die über die Jahre halt nicht gepflegt wurden (und oft daran halt trotzdem noch weiterentwickelt wurde). Für mich ausschlaggebend sind, wie schon oft erwähnt, nicht die Sprache, sondern die Peripherie und in gewisser Weise der Prozess drumrum. Das sind alles sprachagnostische Aspekte, welche eine viel grösser Auswirkung auf ein Projekt als ganzes haben, als in welcher Sprache man schlussendlich das ganze raushaut.
¤: Je nach dem kann natürlich auch der Code an sich einfach scheisse alt sein. Java vor 6, C vor C89, etc. Das macht dann je nach dem auch einfach keinen Spass mehr, weil einfach gängige moderne Sprachfeatures fehlen.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 24.04.2018 14:50]
|
|
|
|
|
|
|
|
|
Das neue (2 Jahre alt, 20% der Inhalte umgezogen) CMS der Uni (Plone) ist so langsam, dass es ca. 10 Sekunden pro Seitenaufbau braucht. Die meiste Zeit ist dabei der Server request, also bringt es nichts, irgendwelche JS/CSS Requests zu blocken.
Wie viel Spaß es macht, da Inhalte einzupflegen und Seitenbäume anzulegen könnt ihr euch denken. "Auftrag an die Agentur ist raus" bekomme ich gesagt, wenn cih die Performance bemängele. Ich will gar nicht wissen, wie viel Kohle irgendwer da für Selbstverständlichkeiten einsackt.
Ich sage es ungern und weiß, wie arrogant es klingt, aber ich glaube ich könnte es besser. Oder würde mich zumindest besser drum kümmern, wenn ich dürfte.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 24.04.2018 15:25]
|
|
|
|
|
|
|
|
|
|
Jo, der letzte Satz haut den Nagel auf den Kopf. Den Gedanken habe ich öfters.
|
|
|
|
|
|
|
|
|
|
|
Bin bei der Swiss.
Wenn ich dürfte hätte ich hier mit den Kollegen vor zwei Jahren einen kompletten Rewrite eingeleitet. Darf ich nicht, Kunden zahlen lieber für andere (unwichtige) Sachen. Jetzt ist nicht mal mehr Geld da, um abgeschlossene Projekte auszurollen. Der Endanwender darf es ertragen.
|
|
|
|
|
|
|
|
|
|
|
Willkommen zu Plone — Deutschsprachige Plone Community. Plone 5 ist die aktuelle Version des Open Source Content Management System Plone. Eine massiv verbesserte Performance ist eine der vielen neuen Funktionen, die das Release mit sich bringt.
|
|
|
|
|
|
|
|
|
|
|
|
Gibt es eigentlich ein schönes Open Source Dokumentenmanagement System?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ARC ist eigentlich auch GC, nur wenn man "GC" sagt, denken sich viele ein "wie in Java" dazu.
Und SBI ist ein weiser, weisser Mann.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 24.04.2018 18:10]
|
|
|
|
|
|
|
|
|
Ich würde das nicht als GC bezeichnen, Apple tut das auch nicht.
| | Is GC (Garbage Collection) deprecated on the Mac?
Garbage collection is deprecated in OS X Mountain Lion v10.8, and will be removed in a future version of OS X. Automatic Reference Counting is the recommended replacement technology. To aid in migrating existing applications, the ARC migration tool in Xcode 4.3 and later supports migration of garbage collected OS X applications to ARC. | |
Quelle: Apple
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 24.04.2018 18:13]
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
ARC ist eigentlich auch GC, nur wenn man "GC" sagt, denken sich viele ein "wie in Java" dazu.
| |
Wobei es ja auch bei Java nicht nur den Oracle/OpenJDK GC gibt, sondern auch proprietäre Realtime GCs und so ein Kram. Wobei man dann halt wirklich etwas anderes nutzen sollte.
| | Zitat von csde_rats
Und SBI ist ein weiser, weisser Mann.
| |
Schön wärs. Die eine oder andere Lektion ist einfach gelernt oder beobachtet worden.
| | Zitat von hoschi
Ich würde das nicht als GC bezeichnen, Apple tut das auch nicht.
| |
If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck
|
|
|
|
|
|
|
|
|
|
|
| | Automatic Reference Counting (ARC) is a memory management feature of the Clang compiler providing automatic reference counting for the Objective-C and Swift programming languages. At compile time it inserts into the object code messages retain and release which increase and decrease the reference count at run time...
ARC differs from tracing garbage collection in that there is no background process that deallocates the objects asynchronously at runtime. Unlike garbage collection, ARC does not handle reference cycles automatically. | |
Ja. Ne. Wildente? Je nach Sichtweise zählt man ARC zu GC, andere bezeichnen es als "Litter Collection" um zu unterstreichen, dass es keinen aktiven GC gibt.
|
|
[Dieser Beitrag wurde 5 mal editiert; zum letzten Mal von hoschi am 25.04.2018 10:30]
|
|
|
|
|
|
|
|
|
Das sind aber Implementationsdetails. Nur weil nicht jede Art von Garbagecollection einen separaten Prozess belegt, macht es das nicht weniger zur konzeptionell gleichen Idee. Und jedem Entenfurz einen fancy Namen geben ist halt so eine Informatikeigenheit. Unterscheidet sich trotzdem fundamental von manuellem Speichermanagement. Dann müsstest du auch auf die einzelnen GC-Implementationen eingehen. GC ist ja, wie bereits zu Genüge erwähnt, nicht gleich GC.
¤: Und beide Methoden haben ihre Vor- und Nachteile. Es ist ja nicht so, als wäre das mit Clang jetzt einfach so ein gelöstes Problem und alles ist schön. Gutes Paper dazu.
¤: Und noch ein Paper zu Real-time GC. Lockfree. Ist eines der Features der IBM JVM.
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von SwissBushIndian am 25.04.2018 10:41]
|
|
|
|
|
|
|
|
|
Ich wäre da wirklich vorsichtig, wenn du ARC als andere Implementierung eines GC vorstellst, für das zu falschen Annahmen über die Funktionsweise. Womöglich ist mir der Begriff GC viel zu weit ausgedehnt? Einige scheinen alles was kein manuelle Speicherverwaltung ist, im Umkehrschluss als GC zu betrachten.
Ich war noch am editieren, aber Implementierungsdetails sind das nicht mehr. Es handelt sich um eine andere Technik die auch andere Auswirkungen hat. Die Unterschiede zwischem aktiver GC und ARC sind fundamental und manuelle Speicherverwaltung hat mit Beiden gar nichts mehr zu tun.
PS: Ich treffe keine Aussage darüber ob ARC jetzt der heilige Gral ist, ich schreibe kein SWIFT oder Objective-C
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 25.04.2018 10:43]
|
|
|
|
|
|
|
|
|
|
Du missachtest halt komplett, wie sich GCs untereinander unterscheiden und kloppst alles in die gleiche Tonne. Es gibt nicht "den GC". Viele GCs implementieren als eine Möglichkeit ähnliche Methoden wie ARC. Wenn du ich so fest darauf konzentrierst, wie ARC funktionierst, musst du auch beachten, wie GCs funktionieren. Automatische Speicherverwaltung ist halt nicht "entweder GC oder ARC".
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 25.04.2018 10:44]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich nehme jetzt einfach eine Seite aus deinem Buch, und Quote den ersten Satz von Wikipedia.
| | | In computer science, garbage collection (GC) is a form of automatic memory management. | |
ARC ist auch eine Form davon. Die Resultate sind vergleichbar. Ob man das jetzt Garbage collection nennt oder nicht, ändert halt nunmal am Resultat echt wenig. Liegt vielleicht auch daran, dass der Begriff Garbage Collection sich so festgefahren hat in unserer Industrie, dass es quasi als Synonym für jede Art der nicht-manuellen Speicherverwaltung verwendet wird. Aber grundsätzlich würde ich weiterhin meinen Entensatz verwenden.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von SwissBushIndian am 25.04.2018 10:49]
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |
