|
|
|
|
|
|
|
|
Cool!
Cooler:
Spoiler - markieren, um zu lesen:
Ja, ich habe das Büro damit beschallt, während ich das Paket geöffnet habe...
| Chandrasekhar:
"It is written with the zeal of a missionary preaching to cannibals. [...] But I (probably for historical reasons) have always been allergic to missionaries." | |
Happy Little WoS.
Virialsatz: Alles ist doppelt so schnell wie es schwer ist.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Wraith of Seth am 27.10.2017 14:21]
|
|
|
|
|
|
WoS ey, die Sandalen sind viel zu groß, der Mini Rechner, und dann - ist das Windows?
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von Oli am 27.10.2017 14:25]
|
|
|
|
|
|
Ne, die Sandalen müssen so, sonst sind die zu schmal. Ein universelles Problem mit Schuhen für mich. Der große Zeh war bei der Größe drunter beim Abrollen immer überm Rand.
Und nein, das ist Linux. Für den Rechner kann ich nichts, der ist gestellt.
Being the only child of an evil corporate overlord has a few very distinct advantages.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Wraith of Seth am 27.10.2017 14:29]
|
|
|
|
|
|
Ich würde postulieren, dass das nen etwas älteres KDE 5 ist
|
|
|
|
|
|
|
Zum TeXen benutze ich dann immer mein Surface, weil die Uniinstallation von TeXLive a) nicht vollständig und b) selten aktuell ist.
Als ich das bei der doch eigentlich typisch Linux-versierten IT anmäkelte kam nur zurück: "Historische Gründe, bleibt so."
Lokale Installationsrechte für eine ganze TeXLive-Fassung? Wo kämen wir denn da hin?! Zumal der Platz dafür nicht reicht...
Boo knows! Do not stow thrones in grass houses!
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von Wraith of Seth am 27.10.2017 14:38]
|
|
|
|
|
|
Texlive sollte man einfach in home installieren können und ohne Doku ist es auch nicht so groß. Rebelliere!
|
|
|
|
|
|
|
Tue ich doch. Ich texe als Physiker auf einer Windowsmaschine. Rebellischer geht nicht. :evil:
The mature approach was SOLID. What was plan B? - Torture Barbie until my demands were met.
|
|
|
|
|
|
|
Ich habe ein Analysis Problem, vielleicht entsteht es aber durch einen Fehler den ich in der stochastischen Herleitung mache, also gebe ich diese mal dazu.
Sei Z_t eine Markovkette über stetiger Zeit, mit endlichem, abzählbarem Zustandsraum . Z hat cadlag Pfade und ist ohne instantaneous rate changes (mein Markovwissen ist rostig und englisch; sofortige Änderungsraten? ), also . So wie ich das verstehe, gibt es also keine Zustände, auf denen ich nur infinitesimal verbleibe?
Dazu kommen zwei messbare Funktionen , die
für alle z in E erfüllen.
Jetzt ist die Behauptung, dass für alle t>=0, das gewöhnliche Integral
differenzierbar sei.
Aber ich denke, man kann doch einfach so wählen, dass es in 0 beginnt und mit einer gewissen Rate auf 1 springt, was ein absorbierender Zustand ist. In einer beliebigen Realisation ist Z also 0 bis zum Zeitpunkt , ab dann konstant 1. Der Endzeitpunkt des Integrals, t, sei hinreichend groß.
Jetzt nehme ich und , was gewährleistet, dass die Summe/Differenz der Funktionen nie Null ist.
Dann ist doch
.
Das heißt,
für ,
und
für .
F ist doch nicht differenzierbar in ?
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Irdorath am 28.10.2017 14:00]
|
|
|
|
|
|
Hat jemand Empfehlungen für ein Lehrbuch zur analytischen Berechnung von Eigenfrequenzen (von Feder-Masse-Dämpfern bis hin zu komplexeren Strukturen)?
Unter "Modalanalyse" finde ich nur Mumpitz
|
|
|
|
|
|
|
Komplexer wie in komplexe Zahl? Dann such mal nach "quasi-normal mode" - frag mich nicht, was der deutsche Name davon ist... "Spectral analysis" könnte auch noch passen, da die Eigenfrequenzen im funktionalanalytischen Spektrum liegen und man damit z.B. kontinuierliche Spektren und Punktspektren gemeinsam abfrühstücken kann. Aber das ist... ...involviert.
And therefore never send to know for whom the bell tolls; it tolls for thee.
|
|
|
|
|
|
|
Ich habe gerade einen Brainfreeze. In welcher Reihenfolge betrachtet man e^x^2 ? Ich dachte, Terme werden von links nach rechts ausgewertet, also (e^x)^2 . Wolframalpha macht es genau anders, also e^(x^2). Wer ist zu doof?
|
|
|
|
|
|
|
Du.
Stell dir vor, was mit der Gassfunktion passieren würde, würde man es so auswerten wie du.
|
|
|
|
|
|
|
Iirc war es bei Exponenten nicht klar definiert, wie aufgelöst wird, eben weil es nicht assoziativ ist. Hängt also von Konvention und Präferenz ab...
PS: Deshalb gehört man für sowas ohne Klammer und Kontext gepaddelt.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Wraith of Seth am 30.10.2017 7:34]
|
|
|
|
|
|
| Zitat von Wraith of Seth
PS: Deshalb gehört man für sowas ohne Klammer und Kontext gepaddelt.
| |
Naja, ich würde sagen, bei ist es ziemlich klar. Auch ohne Klammern. Auch, weil es andernfalls schwierig wird, wenn eine Summe im Exponenten steht:
|
|
|
|
|
|
|
Da hast du aber auch eine optische Anleitung. Die z.B. bereits kein Analogon zu Punkt vor Strich ist... Bzw. die Notation ersetzt die Klammerung.
Ich habe die als Frage bzgl in-line Notation verstanden - frag dich doch mal, was du da gerade getext hast...
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Wraith of Seth am 30.10.2017 7:49]
|
|
|
|
|
|
Eine Verkettung von Funktionen liest man doch üblicherweise von rechts nach links. Für das Beispiel e^x^2 heißt das, erst quadrieren, dann e^resultat. Imho hat das deshalb schon seinen Sinn so...
e: gibts Gegenbeispiele?
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von R am 30.10.2017 8:11]
|
|
|
|
|
|
| Zitat von R
Eine Verkettung von Funktionen liest man doch üblicherweise von rechts nach links. Für das Beispiel e^x^2 heißt das, erst quadrieren, dann e^resultat. Imho hat das deshalb schon seinen Sinn so...
e: gibts Gegenbeispiele?
| |
Wo hast du das mit der Reihenfolge der Verkettung her? Alleine die Diskussion zeigt mir, dass es doch nicht ganz klar ist. Wer entkräftet mein Argument "Terme von links nach rechts"?
|
|
|
|
|
|
|
Das hier ist aber keine Verkettung von Funktionen, sondern erstmal zweistellige Operatoren. Natürlich kannst du die als Funktionen reinterpretieren - aber das ist weder notationell trivial, noch wie Hänschen sich das vorstellt. Zumal die von rechts nach links Sache bei f \circ g schwer genug zu lesen ist, dass auch Monographien noch darauf hinweisen...
|
|
|
|
|
|
|
Ich danke euch erstmal, hat mir weitergeholfen.
|
|
|
|
|
|
|
Kurze Crypto Frage.
Ich möchte ein kleines Projekt machen, was in etwa so funktioniert:
Auf einem PC führt ein User (per cron job) ein Python script aus, was gewisse Daten sammelt und an meinen Server schickt. Dieser nutzt Google Cloud Messaging um dann auf eine Client Android App des Users eine Notification zu schicken oder so. Außerdem speichert er die gesammelten Daten.
Da ich die Daten nicht sehen können will, sollten sie Ende-zu-Ende verschlüsselt sein. Der User erstellt also zuerst ein Schlüsselpaar, und die Daten werden verschlüsselt. Nun muss er bei seiner Android App aber ja in der Lage sein, den Kram wieder zu entschlüsseln. Ich will eigentlich nicht, dass der User erst auf der App irgendeinen Schlüssel erstellen muss. Außerdem will ich ggf. später weitere Clients für den gleichen User zulassen.
Kriege ich das irgendwie hin? Am liebsten würde ich dem User nur einen Token erstellen lassen, welcher kurz genug ist, um ihn auf dem Handy abzutippen und zum Entschlüsseln zu nutzen.
Sowas hier wohl.
https://stackoverflow.com/questions/27335726/how-do-i-encrypt-and-decrypt-a-string-in-python
/e: Dies hier klingt gut: https://github.com/andrewcooke/simple-crypt Leider scheint die Verschlüsslung ein bisschen lange zu dauern. Die Daten sind nicht so wahnsinnig sensibel, und das Script sollte schnell sein...
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von Oli am 31.10.2017 11:03]
|
|
|
|
|
|
Mit AES ist deine Keylänge 16 und den Vektor schickst du einfach mit. Das reicht für dich um den Kram nicht lesen zu können. Die Frage ist, ob 16 Zeichen für den User zumutbar sind oder nicht.
¤: Du schränkst dabei natürlich eine Entropie auf die verwendeten Buchstaben ein wenn die 16 Zeichen für ein "schönes" Password benutzt werden, aber um Leute daran zu hinderen mitzulesen reicht das völlig uas.
¤: Der letzte Link macht genau das was ich meine, einfach sehr sicher. Für deinen Zweck reichen 128bit völlig aus.
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von SwissBushIndian am 31.10.2017 11:07]
|
|
|
|
|
|
Für AES Verschlüsslung kann ich doch einfach openssl mittels subprocess() missbrauchen, oder?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Hmm, nur als andere Idee, wie wäre es wenn du deine Seele auch für die Dateien an Google verkaufst und sowas hier nutzt?
https://cloud.google.com/storage/docs/gsutil/addlhelp/SupplyingYourOwnEncryptionKeys
Wenn ich das richtig sehe kannst du da userspezifische Decryption-Keys angeben. Deren Länge habe ich auf die schnelle nicht finden können, deshalb nehme ich gerade an dass du dir das aussuchen kannst, dementsprechend auch kurz genug zum eintippen.
Das ganze hat natürlich auch andere technische und vielleicht sogar finanzielle Implikationen, aber vielleicht überwiegen die Vorteile am Ende.
|
|
|
|
|
|
|
Ja das ist klar
Wobei man bei einem randomisieten Vektor für jede Nachricht auch das Angriffsziel ziemlich klein macht. Ist halt immer die Frage ob etwas NSA sicher oder halt eben nicht sein muss.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 31.10.2017 11:15]
|
|
|
|
|
|
Klingt nach nem recht klassischen Fall für Noise Protocols z.B. Noise_X_25519_AESGCM_SHA256. Ich weiß aber nicht, ob es dafür inzwischen Wrapper für Python gibt.
|
|
|
|
|
|
|
|
|
|
|
Ich bin unsicher, wie gut die Verschlüsslung sein soll.
Es geht um folgendes: Auf HPC clustern ist es im Moment so, dass man eine Mail bekommt, wenn Jobs starten, aborten oder completen. Außerdem kann den Status seiner Jobs immer irgendwie auf den Clustern checken. Das ist sowohl umständlich als auch nervig, wenn man viele Jobs in der Queue hat. Ich habe die letzten Tage jeden Morgen 20+ mails gelöscht.
Ich würde das gerne schöner machen, mit einer Android App. Also rufe ich den Status von Jobs per cron minütlich ab, und sende die Infos an meinen Server, der wiederum (falls ein Event passiert ist) auf die Android Clients pushed.
Da sind eigentlich keine persönlichen Daten dabei, und ich kann auch von jedem anderen Nutzer die Queue angucken. Aber dennoch will ich nicht unbedingt eine Datenbank am Netz haben, wo eine history aller Jobs der NUtzer irgendwie gespeichert ist. Deshalb würde ich die Daten teilweise verschlüsseln wollen (also zumindest Job ID, name, user, binary path, etc.)
Es scheint mir ein bisschen übertrieben, da jetzt so wahnsinnig sichere Verfahren anzuwenden. Außerdem muss die Verschlüsslung schnell gehen.
Eigentlich wollte ihc auch vermeiden, Dependencies zu haben. Ich hatte gehofft, sowas geht mit der stdlib von Python.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 31.10.2017 12:14]
|
|
|
|
|
Thema: pOT-lnformatik, Mathematik, Physik XXI ( X-Ray-Edition ) |