Beiträge von gandro

    Das ist mir schon klar: Ich wollte ja eben explizit keine relativen Grössen, weil das sonst auf grossen Bildschirmen unlesbar wird (probiers aus im Firebug): Wenn die Uhrzeit und der Antwortende in der Mitte des Bildschirmen ist, dann ist das auf breiten Bildschirmen richtig weit weg vom Threadtitel. Auf auf kleinen Bildschirmen ist es in der Bildschirmmitte hingegen fast schon wieder zu nahe.
    Relative Grössen sind super wenn es um die Aufteilung von Bildschirmplatz geht, nicht aber um die Breite von Text anzupassen. Fancy Textspalten-Frameworks in der Richtung fangen darum ja auch dann an extra Spalten einzufügen, anstatt die existierenden Spalten zu vergrössern.

    Unabhängig von der Technik glaube ich wäre die saubere Lösung das Verhalten für kleine Bildschirme einfach zu ändern, anstatt versuchen relative Breiten festzulegen die nirgendwo wirklich funktionieren.

    Zum Tabellenproblem: Meine CSS-Skillz sind gerade nicht ausreichend um die Tabellenformatierung zu hinzukriegen wie es sein soll, und momentan fehlen mir auch die Nerven. Patches und Pullrequests werden gerne entgegen genommen.
    Das aktuelle Verhalten was ich absichtlich so für breite Bildschirme gemacht habe: Alle Spalten sind fixe Breite, nur die dritte ist variabel. Vermutlich müsste ich CSS-Media-Queries machen und auf schmallen Auflösungen das Verhalten zu ändern, dass der dann auch die anderen Spalten verkleinert. Eigentlich möchte man 'max-width' (ansatt das aktuelle 'width'), aber das gibts nur für Blockelemente, und nicht für Spalten.

    Bezüglich Responsive Design: Ich würde sehr gerne die ganzen Themes hier mal durch ein einziges Responsive/Fluid ersetzen. Besonders bei dem eher mässigen Mobile-Theme wäre das ne schöne Alternative.

    Aber diese ganzen Forentemplates sind alle dermassen ein Gepfusche dass das kein Spass ist und Wochen in Anspruch nimmt. Zeit, die ich echt nicht habe. Falls sich mal wer hinsetzen will und ein MyBB-Theme in sauber zu entwickeln, ich unterstütze gerne. Wobei MyBB 1.8 und 2.0 eh die ganzen Templates wieder kaputt machen. Und das MyBB ist da kein Einzeltäte, die anderen Forensoftwares sind auch alle in den frühen 2000ern stecken geblieben Interfacetechnisch.

    Unsere Designs funktionieren nicht in kleinen Auflösungen, das ist richtig.

    Dass der HDPI-Internet-Explorer da grössere CSS-Pixel hat ist nicht unbedingt hilfreich. Nachtrag: Hm. Sind 'ex'es, vll krieg ich das gefixt.
    Im Notfall einfach das Mobile-Theme verwenden.

    Das mag jetzt etwas Vorschnell sein, aber ich rate allen davon ab, Linux als Windows-Ersatz zu verwenden. Der einzige Unterschied hier ist doch ob Windows Aero oder KDE dein Desktop ist. Dafür braucht man doch nicht das OS wechseln, wo KDE doch Windows noch am ähnlichsten ist (verglichen mit GNOME3 oder awesome). Ansonsten läuft alle Software auf dem Desktop da entweder nur unter Windows (Office 2007) oder besser unter Windows (Steam hat mehr Spiele, Skype hat mehr Funktionen, Chrome hat mehr Plugins)

    Hab noch niemanden erlebt der mit nicht-nativer Software unter Linux glücklich wurde. Und die Schuld wird dann oft "Linux" gegeben.

    Letztendlich erinnert die Geschichte doch sehr an MS-DOS vor 10 Jahren - viele Rechner die genau für einen speziellen Zweck verwendet werden (Kassensysteme, Industrie-Steuerung, Retrospiele usw) werden wohl weiterhin mit XP laufen.

    Auf dem Desktop hingegen zweifle ich daran, dass man in Zukunft damit ernsthaft noch produktiv arbeiten kann (und damit meine ich mehr als E-Mail in Thunderbird und Briefe in Word) und dass mit Supportende auch der Programmsupport eingestellt wird, so dass ich das Problem von alleine erledigt.

    Einziger relevanter Unterschied zu MS-DOS ist allerdings die doch relativ grosse Angrifffläche. DOS-Systeme hingen so gut wie nie am Internet, bei XP sieht das schon anders aus. Und USB-Stick-Viren sind gerade bei XP auch nach wie vor ein Problem.


    Nachbautoner?


    Nur Originale.. man findet im Web ja relativ viele Videos und Hacks was Resetten von Nachbautonern betrifft, aber nichts was Original-Toner betrifft. Ich schau mir mal noch freakeds Zeugs an, sind aber halt beides andere Modelle und beides Fälle von Nachbautonern.

    Zu meinem Modell hab ich nur bezüglich Resetchips für Nachbautoner gefunden, was mich halt doch sehr verwirrt.

    Nachtrag: Hab inzwischen auch das Tech-Menü gefunden, wo man alle möglichen Zähler zurückstellen kann, nur nicht den der Toner:

    In schneller Abfolge drücken: Menu -> ID Copy -> Links -> Rechts > Menü > Zurück (Unten) > Menü

    Danach erscheint ein Eintrag "Tech Menu", wo man Counter und Memory zurücksetzen kann. Ohne Erfolg.

    Meine Eltern haben einen Samsung CLX-3185 Farblaser, vor ca. einem Monat neue Toner gekauft und alle vier Stück ersetzt.
    Nun meldet der Drucker, dass der gelbe Toner bereits wieder leer ist, obwohl gemäss Statistik gerade mal 610 Seiten damit gedruckt wurden.

    Auch die anderen drei Toner sind nach nur wenig hundert Seiten so gut wie leer, da ist irgendwas falsch. Habe die Toner schon mehrmals raus- und wieder reingetan, Kontakte scheinen sauber. Ich weiss nicht ob die Toner jemals kompletten Füllstand gemeldet haben.

    Bin komplett ratlos, in der Software hab ich auch nirgendwo ne Rekalibrierung oder so gefunden. Waren bisher immer die teuren Original-Toner von Samsung.

    Hab ich als es raus gekommen ist mir glaube ich als gekürztes Hörbuch (nur 15h anstatt 37h) gegeben, hat mir gefallen. Hatte für den Nachfolger aber nie die nötige Musse aufbringen können, dazu ist es dann doch zu lange und zu wenig spannend.

    "Satoshi Nakamoto", der Erfinder von Bitcoin, heisst in Wirklichkeit... Satoshi Nakamoto. Ein eigenbrötlerischer, von seiner Frau getrennt lebender, 64-jähriger japanisch-amerikanischer Ingenieur der wohl auch in der Luftfahrt- Kommunikations- und Rüstungsindustrie gearbeitet hat und mit der ganzen Sache nichts mehr zu tun haben will. Die Geschichte ist so dermassen unspektakulär dass sie vermutlich wahr ist.

    http://mag.newsweek.com/2014/03/14/bit…i-nakamoto.html


    etwas OT: lohnt sich Loop Unrolling denn überhaupt in nennenswertem Umfang? also für zwei iterationen leuchtet mir das ja noch ein, aber den gesamten schleifenrumpf irgendwie 8x oder so zu replizieren bläßt den code doch ungemein auf und verschlechtert damit die cache-lokalität deutlich. bei moderenen sprungvorhersagen ist es doch bestimmt einfacher die schleife schleife sein zu lassen, sodass sie komplett im Cache abläuft und anderen Krams nicht verdrängt


    Glaube wo es der Compiler es darf, wird teilweise Loop-Unwinding auch gemacht um den Instruction Level Parallelism zu erhöhen:

    Code
    for(i=0; i < 1000; i++) { 
      sum += a[i]
    }

    könnte ja mit Partial Loop Unwinding umgeschrieben werden als

    Code
    for(i=0; i < 500 ; i+=2) { 
      sum1 += a[i];
      sum2 += a[i+1];
    }
     sum = sum1 + sum2;

    Erlaubt es dem Prozessor jetzt explizit zumindest zwei Additionen zu parallelisieren. Ich hab ehrlich gesagt aber keine Ahnung inwiefern sowas wirklich von Compilern gemacht wird (korrekt wäre es ja nur für Ints, nicht for Floats), oder ob Prozessoren evtl. inzwischen sogar in der Lage sind sowas selber zu erkennen.

    Wobei ich mir auch vorstellen kann dass gerade solche Trade-Off Optimierungen (Cache vs. Branchprediction) auch schlicht sehr prozessorspezifisch sind.
    Erinnere mich an ein Beispiel im GCC wo die Schleifenbedingung in while-Loops zweimal generiert wurde, einmal für die initiale Überprüfung, einmal für die Überprüfung während der Iteration, weil das dem Branch-Predictor vom P6 (Pentium Pro und aufwärts) besser gefallen hat. Wurde dann irgendwann aber geändert, weil spätere Intels sich da anders verhalten haben.

    Was tatsächlich gemacht wird, kann sich von Compiler zu Compiler Version ändern. Es gibt wenig "generelle", grosse Optimierungen, sondern viele kleine Dinge die getan werden. Es hängt auch ein bisschen von der Programmiersprache ab, je "höher" die Programmiersprache, desto mehr Optimierungspotential einsteht.

    Relativ simple Optimierungen betreffen die Optimierung von mathematischen Operationen. Beispielsweise kann eine Division (oder Multiplikation) durch 2, 4, 8, 16, usw bei Ganzzahlen durch Bitverschiebung schneller gemacht werden:

    x = y / 16 macht ein Compiler zu x = y >> 4.

    Oder manche Rechnungen können bereits zur Kompilizierzeit vorgenommen werden: pi = 3.14159; u = 2 * pi * r wird zu u = 6.28318 * r. Sollte Pi in dem Programm später nicht mehr verwendet werden, dann wird der Compiler die Variable eliminieren.


    Dann gibt es relativ viele Optimierungen die Schleifen betreffen:

    Code
    for (i=0; i < 10; ++i) {
         a[i] = 17 * i;
     }

    Kann der Compiler die (langsame) Multiplikation durch eine schnellere Addition ersetzen:

    Code
    tmp = -17;
     for (i = 0; i < 10; ++i) {
         tmp = tmp + 17;
         a[i] = tmp;
     }

    Gerade bei Schleifen mit fixer Grösser kann der Compiler dann auch die Schleife durch "Copy&Paste" ersetzen ("Loop unwinding"):

    Code
    for( i=0 ; i<8 ; i=i+1 ) {
        dest[i] = src[i];
    }

    wird zu

    Code
    dest[0] = src[0];
    dest[1] = src[1];
    dest[2] = src[2];
    dest[3] = src[3];
    dest[4] = src[4];
    dest[5] = src[5];
    dest[6] = src[6];
    dest[7] = src[7];

    Je nach dem kann der Compiler auch Dinge etwas umordnen. Beispielsweise:

    Code
    u = (b + c) * x;
    v = (b + c) * y;

    wird der gemeinsame Teil rausgenommen und nur 1x berechnet, anstatt zweimal:

    Code
    tmp = b + c;
    u = tmp * x;
    v = tmp * y;

    Oder eine If-Abfrage in der Schleife die jedes mal das gleich funktioniert kann rausgenommen werden, so dass die Überprüfung nur einmal stattfindet:

    Code
    int result = 0;
    boolean do_plus = ...;
    for( i=0 ; i<100 ; i=i+1 ) {
      if(do_plus == true) {
        result = result + i;
      } else {
        result = result - i;
      }
    }

    wird zu


    Das sind ein paar (imho) anschauliche Beispiele, hab die meisten aus der Wikipedia geklaut: https://en.wikipedia.org/wiki/Optimizing_compiler

    Die Liste von möglichen Optimierungen ist aber riesig, insbesondere auch wenn es um das Generieren von Maschinen- oder Bytecode geht.

    • Auf Intel-Plattformen (x86) gibt es z.B. einen Maschinenbefehl der Addition und Multiplikation um 2,4,8 kombiniert: x = a * 4 + c kann in einem einzigen Assemblerbefehl gemacht werden, anstatt zwei (zuerst Multiplikation, dann Addition).
    • Spezielle SSE-Instruktionen können verwendet werden, wenn der Compiler merkt dass die gleiche Opteration mehrmals ausgeführt wird:
      Code
      for (i=0; i<8; i++){
          a[i] = b[i] + c[i];
        }

      Anstatt da eine Schleife zu verwenden kann der Compiler da etwa dem Prozessor dank SSE-Instruktionen sagen, er solle alle 8 Rechnungen gleichzeitig ausführen, anstatt eine nach der anderen (nennt sich Schleifen Vektorisierung).

    • In Programmiersprachen wie Java kann manchmal die Überprüfung wegfallen, ob ein Zugriff im Array ist, wenn der Compiler garantieren kann, dass dies nicht der Fall ist, so dass weniger Überprüfungscode ausgeführt werden muss.
    • In Programmiersprachen mit bekannten Funktionen wie C kann der Compiler auch Funktionen strlen (Länge eines Strings berechnen) bereits zur Kompilierzeit ausführen, strlen("hallo") kann der Compiler ausrechnen dass das 5 ist, weil der String keine Variablen ist.
    • Weitere Optimierungen wären etwa das Rauslöschen von Funktionen die niemals aufgerufen werden, oder Schleifen die niemals ausgeführt werden usw.
    • In anderen Sprachen wo Rekursion wichtig kann der Compiler auch rekursive Funktionsaufrufe durch "Tail-Call-Optimization" wegoptimieren, damit die so schnell sind wie Schleifen.

    Grundsätzlich gilt dass der Compiler häufig auch Dinge optimiert, wo der Mensch auch drauf gekommen wäre, also lieber mal eine Variable mehr verwenden wenn es den Code lesbarer macht.

    Nachtrag: Eine leider etwas gar technische, aber kurze Übersicht findet auch in den LLVM-Dokus: http://llvm.org/docs/Passes.html

    Und bei richtigen Unixen statt Linux?


    Verstehe diese Verweise auf andere Unix-Systeme nicht so ganz.

    sysvinit, upstart und systemd sind alle Init-Systeme rein für Linux geschrieben. Dass erstere beide jetzt durch systemd verdrängt werden hat ja auf andere Unix-Systeme keinen direkten Einfluss.

    Die anderen Unix-Systeme andere Init-Systeme fahren ist ja jetzt ebenfalls nichts, wo systemd gross Einfluss drauf hat. BSD & Co waren schon immer inkompatibel mit den Initsystemen in Linux, daran ändert sich jetzt auch nichts.


    Klappt auf den ganzen Unixen einwandfrei, da wirds ja wohl auch Linux hinkriegen.


    sysvinit läuft nur auf Linux? Debian kFreeBSD verwendet extra Kompatibiliätslayer.

    Nachtrag: Die restlichen BSD-Initsysteme kenne ich zuwenig. Sagt ja keiner dass es gar nicht funktioniert, lief ja bisher auch. Ne saubere Lösung war es trotzdem nicht, dass weiss jeder der schon mal selber ein Initskript selber geschrieben hat.

    Das Hauptproblem am alten SysV Init ist dessen Prozessmanagement: Ein Service bei sysvinit ist ein Shellscript. Das heisst, das Shellscript muss sicherstellen dass die Kindprozesse und Forks sauber verwaltet werden, PID-Dateien managen oder anlegen und mit sonstigen Quirks von Programmen umgehen. Dazu sind diese Initscripte dann auch noch distributionsabhängig gewesen (Debian hat den start-stop-daemon Helper, Arch hat eine Bibliothek von bash-Helpern); das ist nicht nur langsam, das ist auch total unwartbar und komplex.

    Wie im verlinkten Artikel schon erwähnt: systemd ist nicht die erste oder einzige Antwort auf ein solches Problem, es gibt andere Systeme die ähnlich funktionieren; aber sysvinit selber hat das Problem nie gelöst.