Grundsätzlich unterstützen wir alle halbwegs anständigen Browser, da gehören die Stock-Android-Browser auch dazu. Wie du das beschreibst, scheint das aber definitiv ein Browser-Bug zu sein: Das Mobile-Theme enthält praktisch kein JavaScript, ich sehe keine Möglichkeit wie das Theme hier den Browser sonst so blockieren könnte.
Ich persönlich verwende Firefox auf Android, läuft runder als Chrome.
Aus aktuellem Anlass (Blogpost von Kumpel, Englisch): http://nickler.ninja/blog/2015/06/28/csgojackpots-weak-rng/
Kurzum: Math.random() ist zwar uniform (d.h. jede Zahl hat die gleiche Wahrscheinlichkeit), aber vorhersagbar. Wenn man zwei rohe (d.h der direkte Output zwischen 0 und 1), aufeinander folgende Zufallszahlen kennt, kann man die restlichen voraus sagen.
https://events.ccc.de/2015/06/29/camp-tickets/
Ich habe übrigens eine Village angemeldet.
Wichtig: Verkauf nur bis 31. Juli. Anders als beim Kongress gibt es wohl kein Vor-Ort Kauf, also nicht vergessen!
So. Direkt noch ne Frage.
Hab ja auf meinem X220 n Arch Linux laufen. tp_smapi ist installiert, thinkpad_acpi ist geladen und tpm ist installiert.
Nur wie bekomme ich die Special-Keys (FN+*) zum Laufen? Kann die Bildschirmhelligkeit nicht regeln. Gibt es da irgendeinen Trick?
Beim X220 (wie auch schon bei seinen Vorgängern) ist die Helligkeitssteuerung reine Software. Ohne ein Tool was auf die Tastendrücke hört und die Helligkeit entsprechend einstellt geht da nichts, gnome-power-manager z.B.
Erster kurzer Hinweis, da ist ein Bug im Code. So wie deine Funktion geschrieben ist, sind sowohl min als auch max inklusive. Da hast du in manchen Fällen Rückgabewerte ausserhalb des Arrays (zufall == array.length).
Bugfix, einfach abrunden, siehe unten.
Math.round() ist sowieso gefährlich, siehe: https://de.wikipedia.org/wiki/Rundung#Mathematisches_Runden
»Das kaufmännische Runden erzeugt kleine systematische Fehler, da das Aufrunden um 0,5 vorkommt, das Abrunden um 0,5 jedoch nie; das kann Statistiken geringfügig verzerren.«
In deinem Falle ist hier aber noch ein anderes Problem: Weil A am Rand ist, können nur die Werte [0 bis 0.4999] zu A werden. Für alle anderen ist es aber mehr, nämlich z.B. [3.5 bis 4.4999] für den Buchstaben D. Das heisst konkret, dass A bei dir halb mal so oft vorkommt wie alle anderen Buchstaben! Für das letzte Element gilt das gleiche - das ist bei dir wegen obigem Bug aber nicht einem Buchstaben zuzuweisen.
Darum: Unbedingt Math.floor() (oder .ceil()) nehmen!
function zufallszahl(min,max)
{
return(min+Math.floor(Math.random()*(max-min)));
}Die Zufälligkeit sieht für mich aber ziemlich okay aus, das ist alles Uniformverteilt wie es sein soll: https://jsfiddle.net/p7r3owL3/
Tipp: Mach Math.round() an, dann siehst du auch den statistischen Fehler den ich erwähnt habe.
Wenn du die Anzahl versuche runterdrehst (z.B. auf 100) dann sieht es anders aus. Kann gut sein dass beim manuellen Testen (mit weniger als 100 Versuchen) ein Buchstabe überdurchschnittlich häufig vorkommt, so funktioniert halt Zufall. Erst bei sehr vielen Versuchen gleicht sich das wieder aus.
Meine Konklusion ist also, dass alles okay ist. Wenn du trotzdem einen besseren Zufallsgenerator willst (wobei wie heinze sagt, das Ding ist zufällig, sieht man halt nicht), alle modernen Browser (IE11+) besitzen einen kryptografisch sicheren Zufallsgenerator: https://developer.mozilla.org/en-US/docs/Web…getRandomValues
Der obligatorische Comic zu dem Thema
Nachtrag: Habe die Diskussion zwischen sandi und CHRISNEW oben übersehen, sorry!
Fuck, dass du bis nächste Woche schon zusagen musst. Ich wäre erstmal mit einem Vielleicht am Start. (lol CHRiSNEW und Planung, siehe 31C3)
Naja, ist eher für die Grobplanung, ob es eher 15 oder eher 5 Leute werden.
Ich muss auch am Sonntag schon wieder los. Aber nochmals 4 Jahre will ich dafür nicht warten..
Alle vier Jahre ist Chaos Communication Camp, und diesen Sommer ist es endlich wieder so weit. Es findet statt vom 13. bis 17. August 2015 im Ziegeleipark Mildenberg, Brandenburg.
Das Camp ist wie der alljährliche Congress ein Treffen von Hackern und Nerds aus aller Welt, die sich für ein paar Tage in der freien Natur zum campen (mit Zelt und so) zusammenfinden. Nebst guter Gesellschaft und Party gibts auch Vorträge, Workshops etc.
Eintrittspreis ist noch nicht festgelegt, wird aber irgendwo zwischen 150-200€ liegen.
Da ich eine Village (ein Zeltdorf) angemeldet habe, wollte ich hier mal fragen wer denn aus dem WHF-Universum dahinreist und in unserer Village sein Zelt aufstellen will, da ich bis nächste Woche (20. Juni) dem CCC Bescheid geben muss, wieviele Leute wir sind. 
Na super, in alten Versionen ging das noch. Und jedes mal runterziehen wenn man wissen will wie voll der Akku ist? Androids Usability war mal deutlich besser.. Ok, dann wohl doch eine App.
Ich kann mich irren, aber ich meine dass Vanilla Android das nie konnte, das ist afaik immer schon ein Feature der Custom-ROMs ala CyanogenMod gewesen.
Finde da auch nichts. Scheint wohl irgendwie auf deren Makefiles aufzubauen. Naja, hier ist mein Quick & Dirty* Makefile, was die ganzen Dateien in den Parent-Foldern durch Systemlibraries ersetzt. Funktioniert auf meinem Rechner, hab freeglut installiert.
http://pastie.org/10227051 (Nachtrag: Lieber als Link, da Makefiles Tab-sensitiv sind)
*Vermutlich furchtbar inkorrekt und enthält ein paar Libraries zuviel. Keine Lust mir da die ganzen komischen Umgebungsvariablen anzuschauen. Aber kompiliert und läuft.
Ein (sehr) kurzer Blick auf die Makefile lässt mich am Kopf kratzen. Das Ding sucht nach Source-Code in "../../..". Kann es sein dass das ZIP nicht die kompletten Sourcen sind, sondern nur irgend nen Add-On?
Wird gemacht! Bin noch unterwegs.
Ein Teilproblem dabei ist, dass die ganzen Hardwarehersteller ihre Systeme nur mit Windows testen, sobald sich ein System etwas anders verhält gibts oft Probleme.
Gestern wieder an den Dresden Files weitergelesen: Fool Moon von Jim Butcher. Sehr unterhaltsam.
Ich glaube am einfachsten willst du schlicht Cache-Control: no-cache. Der Name ist etwas ungünstig gewählt, aber es erzwingt das von dir im Ursprungsbeitrag skizzierte Verhalten - dem Client ist es dann verboten irgendwelche Heuristiken bzw. generell Fresh Content zu verwenden, sondern er muss jedes mal die Revalidierung mit If-Modified-Since o.ä. durchführen.
Ich gebe jetzt wie in Quelle empfohlen Cache-Control: private, must-revalidate, max-age=1 und Expires: -1 mit und es scheint zu funktionieren.
Expires sollte nicht nötig sein wenn du max-age hast. Vermutlich macht das mehr kaputt als es fixt, weil der Browser jetzt von dir widersprüchliche Informationen kriegt (Die Seite ist noch eine Sekunde lang gültig und diese Seite ist schon nicht mehr gültig). Ausserdem bin ich mir nicht sicher, ob Expires:-1 überhaupt gültiges HTTP ist.
Warum setzt du "private"? Sind es wirklich userspezifische Daten? Mit deinem Problem hat das ja eigentlich nichts zu tun.
Ist da irgendwo eine Fehlkonfiguration? Ist das ein Bug? Oder ist das tatsächlich die Mentalität der IE-Entwickler? Ich kann’s eigentlich kaum glauben, wie man etwas so Fundamentales so fundamental verkacken kann. Ich hab schon von Workarounds gelesen à la ›immer negatives Expiration-Datum mitgeben‹. Muss ich jetzt noch OVER 9000 weitere Header-Zeilen (gibt ja auch noch ETags und Caching-Direktiven) mitgeben, nur damit der IE annähernd wie ein Browser funktioniert?
Das ist komplett legitimes Verhalten. Solange du nicht "Cache-Control: no-cache" o.ä. ähnliche Header gesetzt hast, darf der Browser gecachte Requests ohne Revalidierung aus dem Cache präsentieren.
Das Google Stichwort hier ist Freshness & Stale Responses, das HTTP RFC hat da mehr Informationen. Grundsätzlich gilt, dass wenn du keine Cache-Control-Header angibst, dass der Browser dann Heuristiken anwenden darf um zu bestimmen ob ne Seite Stale ist oder nicht. Solange eine Seite nicht Stale ist, muss der Browser auch nicht mit If-Modified-Since o.ä. revalidieren.
Wäre auch ziemlich dämlich jedes Mal 100ms Latenz mit Revalidierung zu verschwenden, nur um es dann trotzdem aus dem Cache anzuzeigen. Der Zeitverschwender ist ja heutzutage die Latenz, nicht die Bandbreite.
Caching ist ein unheimlich komplexes Problem. Der HTTP-Caching-Standard ist ziemlich genial in der Hinsicht, aber er funktioniert halt anders als die meisten das erwarten. Ich hatte bisher leider auch nie die Zeit und Musse mich da wirklich einzulesen, so dass ich keine direkte Empfehlung aussprechen könnte. Spontan glaube ich aber, dass du entweder must-revalidate mit max-age oder gleich no-cache haben willst.
Nachtrag: Nach etwas durchscrollen glaube ich schon, dass hier ne Heuristik anschlägt.
If the response has a Last-Modified header field (Section 2.2 of
[RFC7232]), caches are encouraged to use a heuristic expiration value
that is no more than some fraction of the interval since that time.
A typical setting of this fraction might be 10%.Wenn dir das nicht passt, musst du eine explizite Freshness-Angabe machen, mit Cache-Control max-age oder Expires.