Beiträge von gandro

  • Der Code-Schnippsel-Thread

    Zitat von thosch97


    Es ist halt hinten und vorne nicht abwärtskompatibel zu beklopptem alten Zeugs, eben mit so Späßen wie strlen("ä")=2.


    Ich hätte schreiben sollen: Es ist abwärtskompatibel mit ASCII. "ä" ist kein ASCII.

    Nachtrag: Ausserdem ist dein Fall ein Fall von Aufwärtskompatibilität. Das ist nicht zu verwechseln mit Abwärtskompatibilität.
    Lies: Jedes UTF-8-System ist abwärtskompatibel mit ASCII. Du kannst ein 30 Jahre altes ASCII-Textfile in ein UTF-8-System schmeissen, und es läuft.
    Daraus folgt nicht, dass jedes ASCII-System aufwärtskompatibel mit UTF-8 ist und dass du in ein 30 Jahre altes C-Programm UTF-8-Text schmeissen kannst.

  • Der Code-Schnippsel-Thread

    Meine Eindruck Hoffnung ist, dass sich UTF-8 vermehrt durchsetzen wird. UTF-16 verwendet man eigentlich nur noch, wenn man String-Representierungen mit existierenden Systemen/Programmiersprachen (z.B. Windows, Java, Javascript) teilen will.

    UTF-16 erlaubte mal eine Speicherstelle pro Code-Point, das ist aber längst nicht mehr der Fall. Schon seit den 90er Jahren gibt mehr Unicode-Zeichen als man mit 16bit Darstellen könnte. Und selbst wenn man auf UTF-32 umsteigen würde (was niemand tun wird, weil Bloat): Ein Unicode-Buchstabe kann immer noch aus mehr als einem Code-Point besitzen, man kann z.B. den Buchstaben ã auch aufsplitten in "~" und "a" - was zwei Codepoints sind, aber ein Zeichen - also keine Konstanter Zugriff auf einzelne Buchstaben (!= Code-Points). Gerade für nicht-europäische Schriften ist das offenbar wichtig.

    Darum gibt es inzwischen kaum mehr Argumente für UTF-16 (oder UTF-32). Es ist ein effizienteres Encoding für manche Schriften (z.B. Japanisch), dafür ist UTF-8 in lateinischen Schriften super effizient. Und halt abwärtskompatibel.

    Lesetipps:
    http://lucumr.pocoo.org/2014/1/9/ucs-vs-utf8/
    https://www.reddit.com/r/rust/comment…y_vecu8/cj0ihes

  • Internet via RS232?

    Meines Wissens ist das auch was die meisten Programme unter MS-DOS ohne Treiber unterstützen, dass sie halt direkt diesen Hayes-Befehlssatz via serielle Schnitstelle raushauen. Normalerweise würde dann da am anderen Ende ein Modem sitzen und das durch die Telefon-Leitung tunneln. Heutzutage willst du aber wohl eher einen Netzwerk-Rechner am anderen Ende der seriellen Schnittstelle haben, der dann ein Modem simuliert in dem er das Hayes-Protokoll spricht.

  • Cyanogenmod aktualisieren??

    Zitat von Dirk


    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?

  • 7zip-Benchmarks

    Zitat von Blue


    Der Benchmark ist blöd. Hab 3 Kerne, kann aber nur 2/4 Threads einstellen :b2:


    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.

  • Der Linux Problem/Fragen-Thread

    Zitat von tk1908


    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

  • [geteilt] Mal wieder ein systemd-Flamewar

    Zitat von mrshadowtux


    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 :)

  • [geteilt] Mal wieder ein systemd-Flamewar

    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:

    Zitat von mrshadowtux


    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.

  • [geteilt] Mal wieder ein systemd-Flamewar

    Zitat von mrshadowtux


    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.

  • [geteilt] Mal wieder ein systemd-Flamewar

    Zitat von mrshadowtux

    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.

    Zitat von Alpha


    Linux: It's about choice.


    Nein.

  • oreissig's Unix-Rant

    Zitat von oreissig


    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.