Seite 14 von 14 ErsteErste ... 41011121314
Ergebnis 261 bis 266 von 266

Thema: echo rand(); - "It’s all in the graphics."

  1. #261
    Zitat Zitat von Mivey Beitrag anzeigen
    Kann sein, dass der echte Support dafür in den Sand gesetzt wurde als die ersten Homo Habilis Europa kolonisiert haben. Hast du ne Zeitmaschine?
    (Ne echt, wofür brauchst du das denn? Bin neugierig)
    Ich habe einen Bingokartengenerator gebastelt. Der frisst eine Liste an Einträgen, shuffelt die und generiert anschließend eine hübsch quadratische Tabelle beliebiger Größe (optional mit freiem Feld in der Mitte).
    Ursprünglich waren die Felder immer 5×5, da habe ich den Feldern einfach 20% Breite und Höhe zugewiesen. Dann dachte ich aber, dass konfigurierbare Größe viel cooler wäre und habe die Felder mit display: flex dazu gebracht, gleichgroß zu sein.
    Sieht auf @media screen gut aus, sieht auf @media print gut aus (alles außer dem Bingoblatt wird ausgeblendet, Bingoblatt verliert ein paar Styles zum tintensparendem Ausdrucken) aber in der Druckvorschau und dem eigentlichen Druck sind entweder die Border superhässlich (also unterschiedlich breit, Firefox) oder das ganze Ding klappt zusammen (mag wohl flex nicht im Druck, Chrome).

    edit: So, scheiß drauf. Ich iteriere jetzt einfach über alle tds und setze Höhe und Breite passend :/ Was ist denn bei Print-Stylesheets so best practice?
    Stackoverflow sagt: ¯\_(ツ)_/¯ mach halt 670px feste Breite wie im Mittelalter

    Geändert von WeTa (21.03.2016 um 10:43 Uhr)

  2. #262

  3. #263
    Ja, diese Container in der virtuellen Umgebung finde ich die Hölle. Da könnte zwar zum Deployen Klasse sein, aber da bleibt die Performance bestimmt schon liegen.

    Außerdem frisst das Platz ohne Ende. Wenn man alles statisch rum linkt und in einen Container packt, kann man die shared Libraries doch glatt vergessen. Dann hat man im größten Fall die gleiche Library in x vielen Containern auf der Platte zu liegen, statt nur einmal und der Rest linkt das dynamisch. Nein nein, den Mist muss man nicht mit machen!

  4. #264
    Zitat Zitat von niR-kun Beitrag anzeigen
    Ja, diese Container in der virtuellen Umgebung finde ich die Hölle. Da könnte zwar zum Deployen Klasse sein, aber da bleibt die Performance bestimmt schon liegen.

    Außerdem frisst das Platz ohne Ende. Wenn man alles statisch rum linkt und in einen Container packt, kann man die shared Libraries doch glatt vergessen. Dann hat man im größten Fall die gleiche Library in x vielen Containern auf der Platte zu liegen, statt nur einmal und der Rest linkt das dynamisch. Nein nein, den Mist muss man nicht mit machen!
    Könnt man nicht gleich alles statisch linken also ohne Container, so dass das Program gar nicht suchen muss was auf dem lokalen System installiert ist? Wäre den doch auch "reproduzierbar" und würd auch nicht mehr Speicher brauchen als x-Schichten von virtuellen System.

  5. #265
    Zitat Zitat von Mivey Beitrag anzeigen
    Könnt man nicht gleich alles statisch linken also ohne Container, so dass das Program gar nicht suchen muss was auf dem lokalen System installiert ist? Wäre den doch auch "reproduzierbar" und würd auch nicht mehr Speicher brauchen als x-Schichten von virtuellen System.
    Jein... es gibt da noch ein paar mehr Aspekte, warum Container praktisch sind:

    • Das Konzept funktioniert auch für Szenarien, wo statisches Linken nicht möglich ist (z.B. wenn eine eigenständige Executable aufgerufen wird oder in interpretierten Sprachen, die nicht alles dynamisch linken können)
    • Container haben einen enormen Sicherheitsvorteil. Alles, was nicht explizit freigegeben wird, ist für den Container unsichtbar. Das heißt, selbst wenn ein Angreifer Rootrechte im Container kriegt, kann er damit kaum Schaden anrichten. Er kann im Wesentlichen nur auf die Daten zugreifen, die zu diesem einen Prozess gehören.
    • Wenn in einem Container tatsächlich mal Dateien beschädigt werden (durch einen Bug oder weil ein Angreifer ausführbaren Code durch Malware ersetzt), lässt sich der Container sehr einfach wegwerfen und neu initialisieren (z.B. docker-compose stop && docker-compose rm -f && docker-compse up -d)
    • Wenn ich auf einem Server neue Software installieren will, muss ich mir gar keine Gedanken machen, welche Abhängigkeiten ich installieren muss, selbst wenn die Software nicht in meinem Paketmanager ist (was für viele Webanwendungen gilt). Mit einer 20 Zeilen langen docker-compose.yml bekomme ich eine Owncloud Instanz mit allem, was dazu gehört. Oder Feedbin. Oder Piwik. Oder einen Minecraft Server...
    • Ich kann mir sicher sein, dass auf meiner Entwicklermaschine exakt die gleichen Versionen von allem laufen, wie auf dem Server. Auch noch in einem Jahr, wenn ich einen Bug in einer alten Version reproduzieren muss.


    Viele dieser Vorteile hätten einzelne VMs pro Anwendung natürlich auch, aber die brauchen mehr Platz auf der Festplatte, mehr RAM, mehr CPU und mehr Zeit zum Booten, weil sie jeweils einen eigenen Kernel und eigene Treiber mitbringen. Ein Docker Container startet genau so schnell, wie ein blanker Prozess und hat einen vernachlässigbaren Performanceoverhead. Der Platzbedarf auf der Festplatte ist zwar etwas höher, als bei einer Direktinstallation, aber immer noch deutlich unter dem von einer ganzen VM. Zumal Docker auf einem Dateisystem aufbaut, das in Schichten organisiert ist. Wenn ich zwei Container habe, die auf dem gleichen Image aufbauen, liegt das Image auch nur einmal auf der Platte, pro Container werden nur die jeweils veränderten Dateien neu abgelegt. Die Images in sich sind auch nochmal geschichtet, Wenn ich z.B. zwei Rails Anwendungen habe, können die beide vom Basisimage ruby:2.3 erben und die Images ruby:2.3 und node:6.3 basieren (momentan) beide auf dem gleichen Basisimage buildpack-deps:jessie. Außerdem sind die Basisimages in der Regel so sehr abgespeckt, dass wirklich nur das drin ist, was man braucht. In den oben genannten hat man z.B. nicht mal less oder einen einfachen Texteditor.

    Container in einer VM sind natürlich ziemlich unhandlich. Das liegt aber aus den oben genannten Gründen mehr an der VM, als an den Containern. Und zumindest unter Windows könnte das Problem demnächst wegfallen, da der Windows Kernel seit dem aktuellen Update auch Linux Binaries ausführen kann (yay!). Docker funktioniert zwar noch nicht richtig, aber so wies aussieht, dürfte das bald behoben sein.

    Disclaimer: ich betreibe einen Ubuntu 16.04 Server, auf dem aktuell 19 Docker-Container (z.B. vier davon für die BMT-Website) laufen.

  6. #266
    Email Templates sind die Hölle, ich schwöre.
    Nee, das stimmt eigentlich nicht. Email-Teamplates für Outlook schreiben ist die Hölle.
    Die eigentliche Hölle sind natürlich HTML-Emails, aber pssst von irgendwas muss ich ja essen können

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •