Nach etwas googeln (Hayes Protokoll ist sicherlich relevanter Suchbegriff) habe ich nichts für Windows gefunden. Wenn du auf der anderen Seite einen Linux-Rechner hast, dann sollte man mit TCPSER was machen können: http://manned.org/tcpser/e8754729
Aufbau wäre dann: MS-DOS-PC <-- Nullmodem --> Linux-PC <-- LAN --> Internet
Nighlys will ich sogar gar nicht. Hab auch gelesen, dass es nicht gut ist zwischen nighlys und milesstones zu wechseln.
Exakt. Die M-Releases sind stabilisierte Nightlies. Immer Ende Monat wird ein Nightly abgespaltet, getestet und darauf alle Fehler korrigiert, ohne dass neue Funktionen dazukommen. Sobald das Ding stabil ist, gibts den M-Release.
Die Nightlies werden währendessen weiterentwickelt, d.h. von einem Nightly auf einen M-Release zu wechseln ist essentiell ein Downgrade, das ist nicht unterstützt und geht praktisch immer schief.
Von M auf Nightly geht immer, weil ist immer ein Update. Von Nightly auf M geht nur wenn der Nightly alt genug ist (~ 2-3 Wochen), das Datum der Abspaltung steht in der Regel im Release-Log des M-Release.
Keine M-Releases gibt es aber wenn der Maintainer keine Zeit mehr hat, oder krasse Bugs aufgetaucht sind. Solange man keine Bugs hat, lohnt sich das Update aber nicht - auf Nightly updaten ist dann aber sicher.
Zum Problem: Bist du sicher dass deine letzte Version M8 ist? Die Wikiseiten fürs Galaxy S4 sagen alle, dass nach M3 die Builds für alle S4 zusammengefügt wurden. Wenn du also noch CM11M3 hast, dann kriegst du nur deswegen keine Updates mehr, weil du nen anderen Update-Feed brauchst.
http://wiki.cyanogenmod.org/w/Jflte_Info
http://download.cyanogenmod.org/?device=jflte
Nachtrag: Ist allerdings die LTE-Variante. Bei der Internationalen Non-LTE-Variante scheint in der Tat etwas beim Releaseprozess kaputt zu sein, da ist die Liste leer:
http://download.cyanogenmod.org/?type=snapshot&device=i9500
Nachtrag II: Die Non-LTE-Variante scheint gemäss Device Status Liste ohne Maintainer zu sein. Pflegt halt offensichtlich wirklich keiner mehr:
http://wiki.cyanogenmod.org/w/Device_Status
Wobei es da gar nie ein M-Release gegeben haben soll. Woher hast du den aktuellen ROM?
Der Benchmark ist blöd. Hab 3 Kerne, kann aber nur 2/4 Threads einstellen
Müsste man jetzt experimentieren, aber spontan würde ich drauf wetten, dass 4 Threads nur minimal Overhead erzeugen. Kriegst eventuell sogar bessere Resultate als mit drei Threads, weil du ggf. mehr Prozessorzeit kriegst.
Sieht mir auch eher nach einem Fan-Trailer aus, das sind doch teilweise Szenen aus Sucker Punch.
Gut zu wissen. Merci für die Antwort.
Beachte den Nachtrag, für die ehemaligen Non-OSE-Funktionen benötigst du das Extension-Pack: https://aur.archlinux.org/packages/virtualbox-ext-oracle/
Sagt mal,
n normales Virtual Box (nicht die OSE) gibts net in den Repos von Arch Linux?
Seit VirtualBox 4.0 gibt es keine unterschiedlichen Versionen mehr, es gibt nur noch die OSE: https://www.virtualbox.org/wiki/Editions
Nachtrag: Das "virtualbox"-Paket im Repository enthält auch das Extensionpack, mit Ausnahme von VNC, dazu braucht man vrtualbox-ext-vnc.
Nachtrag: Das Extension-Pack soll man wohl manuell installieren https://wiki.archlinux.org/index.php/Virt…#Extension_pack
Windows 9: Das neue Startmenü in Aktion
Quelle ist Winfuture, die erzählen sonst ja meistens eher Quatsch. Wurde aber via OSNews und Verge verlinkt, keine Ahnung ob legitim oder nicht.
Wie soll man dann die Integrität der Logs verifizeren?
Ja gar nicht, ist ja auch nur ein Export, nicht die Rohdaten. Die Rohdaten sind nach wie vor integer.
Wenn man nicht gerade Custom-initramfs frickelt, sondern einfach mal initrd und Kernel vom Distributor nimmt, ist das nicht notwendig.
Ahja. Weil der Kernel und Distributionen immer bugfrei sind, oder wieso genau?
Early-Boot Fehler sind ein reales Problem, habe ich schon mehr als einmal debuggt. Und ich glaube euch ja auch, dass Kundenlogauswertung ebenfalls ein reales Problem ist.
Aber dein "mein Problem ist voll wichtig, und deine genannten Probleme existieren gar nicht"-Argument ist halt Bullshit.
Nachtrag: Kann sein, dass Umschulung für Kunden von "cp /var/log/messages /tmp/logfile.txt" zu "journalctl -b -o short > /tmp/logfile.txt" etwas nervig ist. Aber umzumutbar würde ich das nicht bezeichnen 
Wenn ein Prozess oder Modul während der initramfs scheisse baut, würde ich das gerne in den Logs haben, und nicht bloss auf der Konsole.
Nachtrag:
Ohne systemd könnte man einfach /var/log tarren und mailen. Aber wäre ja zu einfach, was?
Diese "ich brauch das nicht, also ist es nutzlos" Attitüde ist halt nicht konstruktiv. journald löst echte Probleme; und ist beidseitig kompatibel zu syslog (Echtzeit-Import und Echtzeit-Export nach syslog). Man kann weiterhin sein syslog verwenden, wenn man mag. Aber dieses "syslog ist mehr als genug als jemand jemals brauchen wird" ist halt echt nicht zielführend.
Ohne systemd könnte man einfach /var/log tarren und mailen. Aber wäre ja zu einfach, was?
Kann man auch mit systemd, wenn du syslog-Weiterleitung aktivierst. Ich aktiviere syslog-Export gerne manuell von Hand, wenn ich dafür echte Probleme gelöst kriege, wie etwa Logs vom Early-Boot.
Denn Early-Boot mit klassischen Loggern zu debuggen ist um einiges der grössere Schmerz als mit ein Tool aufzurufen was mir kurz ne Textdatei generiert.
Die syslog Weiterleitung war bei Fedora standardmässig aktiv, ist aber wohl rausgeflogen. Selber aktivieren geht aber nach wie vor, genauso wie der Export via journalctl.
Eben das ist der Punkt. Wird leider gekonnt ignoriert von vielen.
Hä? systemd hat schon immer, und wird auch immer, die Erstellung von syslog-Textdateien unterstützen. Eure Kunden können weiterhin Textlogs in der Gegend herumschicken wie sie lustig sind.
Dass die Logs Binärdateien sind machen die Entwickler ja nicht um Admins zu ärgern, sondern um Logs über Dateisystemgrenzen hinweg zu unterstützen (journald kann initramfs mitloggen und abspeichern), es garantiert Atomizität und Fälschungssicherheit und erlaubt es zudem Metadaten im Log abzuspeichern die eine Textdatei sonst unlesbar machen würde.
Linux: It's about choice.
wobei der anwendungsfall jetzt für ne installation ohne virtualisierung wurst ist, da kann das programm auch einfach ps ausführen um rauszufinden, welche executables geladen sind...
In dem Paper präsentieren sie auch nen Experiment wo sie auch eine über HTTPS heruntergeladene Datei erkennen können.
Prozess-Erkennung war das einfachste, weil sich das Mapping der Binaries auf Pages relativ deterministisch verhält, der Angriff lässt sich aber auch für andere Informations-Leaks nutzen. Theoretisch lassen sich Anwendungen knacken die darauf basieren dass Daten im nur im virtuellen Addressraum der Applikation lesbar sind, jedoch nicht von anderen Prozessen aus.
Nachtrag: Rein von der Angriffsidee her könnte ich mir sogar ein Experiment vorstellen wo man so eine Attacke via Javascript ausführt. In der Praxis vermutlich schwierig zu kontrollieren, aber wäre Prozess-Probing dann wieder ein ernsthaftes Problem.
Seltsam eigentlich, hat doch Minecraft 1.8 massiv Geschwindigkeitsverbesserungen gebracht.
Hast du da ein Paper zu?
https://staff.aist.go.jp/c.artho/papers…2011-suzaki.pdf
Sie haben vom aus einem VM-Guest heraus via Copy-on-Write ziemlich zuverlässig herausfinden können, ob im anderen VM-Gast ein Apache oder Firefox-Binary geladen war.
(Drepper und Poettering in einem Thread. Ich warte nur noch auf Ad Hominem :D)
ASLR und das limitiertere Tooling finde ich schon signifikante Nachteile. Die static linux Leute haben da natürlich ne andere Meinung zu: http://sta.li/faq
Die ganzen Steam-Spiele unter Linux machen ja eh den Kompromiss dass sie zwar dynamischen Linken, aber wie unter Windows einfach alle Bibliotheken selber mitbringen (gut, bei Spielen ist da eh häufig ein gepatchtes SDL mit dabei, von daher ist das nicht immer freiwillig).
Ich glaube auch nicht dass statisches Linken alle besprochenen Probleme löst, glaube da braucht es schon noch mehr Abkapselung.
Nachtrag: Same-Frame-Merging ist nicht standardmässig aktiv. Gibt da da auch Security-Bedenken, da es Sidechannel-Attacken erlaubt (man kann durch Timing-Attacken ziemlich zuverlässig rausfinden, ob bestimmte andere Binaries im RAM sind).
Und das reinschreiben auf die Standardeingabe?
Hab mich verlesen, darum hab ich den Beitrag gelöscht. Standardeingabe kann man in systemd selber nur ein TTY angeben - ein eigener Wrapper ist vermutlich zielführender.
Aus reiner technischer Neugier: Bedeutet /stop dass das Init/Systemd-Script den Server danach neu startet? Damit kann man ja Ops die Möglichkeit geben den Server neuzustarten ohne SSH-Zugang?
Ich spiele kaum mehr auf dem Server, von daher will ich hier nicht all zu laut sein - aber meine Ansichten:
Da es mit den Plugins schwierig sein wird, wäre ich auch für eine Whitelist, scheint ja ohne Plugins zu gehen.
Ich würde es da aber sehr bevorzugen, wenn die relativ frei gehandhabt wird, also dass möglichst jeder in der Liste ist. Wildfremde kommen ja eh so gut wie gar nie auf den Server - von daher wäre ich einfach dafür, dass für jeden Neuling einfach jemand anders Verantwortung übernimmt. Also dass ich problemlos sagen könnte "hier den kenn ich iRL, wenn der Scheisse baut stehe ich dafür gerade" und dann wird der erstmal auf die Liste aufgenommen.
mobGriefing=false anstatt Creeper-Heal fände ich auch okay. Unser Server war ja eh mehr Fokus auf Bauen als auf Survival.
Zu den Wassertempeln: Zumindest in den Snapshots sind Guardians (Wächter) auch in alten Biomen gespawnt. Die Worldgeneration hat sich allerdings trotzdem ziemlich geändert, weiss nicht ob Chunks rauslöschen da sauber funktioniert - dann wieder um ist es eh mitten im Ozean, da interessiert das eh keinen.
Wenn man nach dem Update also sucht, welche Chunks im 1.8 den Wassertempel enthalten sollte man die einfach rauslöschen können, und die Welt wird dann neu mit Wassertempel generiert. War zumindest im Snapshot so.
