Jump to content

xTrekStorex

Member
  • Posts

    519
  • Joined

  • Last visited

Awards

About xTrekStorex

  • Birthday Apr 15, 1995

Contact Methods

Profile Information

  • Gender
    Male
  • Location
    AudiLand <3
  • Interests
    Computer Hard- & Software
    Server-Administration
    Networking
    Coding (Delphi, C/C++,PHP/HTML/CSS/JS/MySQL, Bash)
    Overall Recommendations/Repairs/etc
    Anime & Manga
    Music
    Cars & All Tech in general
  • Biography
    Alex, loves tech, PC-Games, Anime, addicted to music and a bit into cars - works in IT
  • Occupation
    Linux System Engineer
  • Member title
    Yes, a GTX1080 is absolutely mandatory to watch YouTube.

System

  • CPU
    Intel i7 6700K @4.6GHz
  • Motherboard
    ASUS RoG Maximus VIII Gene
  • RAM
    HyperX Savage 16GB DDR4 2800MHz CL14
  • GPU
    EVGA GTX1080 SC
  • Case
    Bitfenix Phenom M
  • Storage
    Intel 750 Series PCIe SSD 400GB
  • PSU
    EVGA SuperNova G2 550W
  • Display(s)
    Dell U2715H, Samsung SyncMaster P2450H, Samsung SyncMaster 931BF
  • Cooling
    Noctua NF-F12 PWM LTT-Edition & Thermalright Macho Black
  • Keyboard
    Corsair K70 RGB MXBrown O-ring modded - want my MXBlues back though or MXGreys or MXGreens instead..
  • Mouse
    Logitech G900
  • Sound
    BeyerDynamic DT880 Premium (600 Ω) on Fiio E10K & Samson Meteor
  • Operating System
    Windows 10 Pro 64bit

Recent Profile Visitors

6,112 profile views
  1. F ist SP, A ist AF. Noctua hat auch noch die S Serie die als reiner Gehäuselüfter gedacht sind, also nach hinten offen und keinen Kühler. Vermutlich entsprechend leiser und gar keinen Gegendruck. Ich gehe eigentlich immer mit SP. Nur die LTT Edition hatte für 120mm nur die F12 und für 140mm die A14. Daher habe ich 4 F12 und 1 A14
  2. minimale RPM sind aber anders. genau wie Anlauf PWM. Meine NF-F12 laufen bei 500RPM
  3. Übel geil. Ich hab ja eh immer Noctua verbaut (und werde das auch beibehalten). Aktuell habe ich die LTT Edition NF-F12 und NF-A14 drin - sind also schon schön schwarz. Hab auch weiße Chromax Ecken noch hier liegen, aber immer noch nicht verbaut (Lüfter müssten nochmal raus). Gleiches gilt auch für mein Custom Cablemod Kit (Cablemod Konfigurator - custom Länge, Farbe und Muster Sleeve pro Kabel für mein EVGA SuperNova G2, exakt für mein Gehäuse ausgemessen), das seit nem Jahr eingeschweißt im Schrank liegt, weil ich den PC nicht zerlegen will.. - 150€ gut investiert Feier die neuen Chromax Sachen aber richtig - Industrial war einfach nie was für silent Builds und die LTT Edition gibts nicht mehr.
  4. und vielleicht auch mal was aktuelles von mir. seit vorgestern ist der neue NAS Barebone im Einsatz (zweite von unten - erste ist der alte) Leider nehmen 2011 und 2011v2 nur bis zu 2 Quad-Rank DIMMs pro Channel - entsprechend hat die Box jetzt nur 128GB RAM statt der bisherigen 192GB... Mal schauen wo ich die übrigen 4x 16GB jetzt verbaue..
  5. naja... ich nutze Discord alltäglich seit der Beta (/r/homelab - Server Community) und ich find in Sachen Voice ist Teamspeak immer noch besser. Das Channel und Rechte System finde ich auch viel sinnvoller ab einer User Anzahl von 5+. Als Chat ist Discord sehr geil, auch der Video Chat ist gut umgesetzt. Quasi eine Community Version von Slack mit ein paar Extras. Aber für Voice... Viele feiern Discord halt auch weils komplett kostenlos nutzbar ist. Jeder kann seinen eigenen Server erstellen etc. Aber das führt zu mehreren Problemen. a) hat jede Sau ihren eigenen Server, was absolut sinnfrei ist b) haben die Leute keine Ahnung von Moderation und Administration und viele Server werden zu Spamschleudern für Bots und Co. c) sind Server nicht einfach betretbar - man muss Invite-Links haben. Man kann zwar öffentliche Invites verfügbar machen aber die muss derjenige trotzdem erstmal finden bzw anklicken - anstatt sich einfach eben auf eine URL zu verbinden. Und dann bleiben die auch noch im Interface hinterlegt als "deine Server". Wenn du einen Server löschst verlässt du diesen quasi und musst wieder einen Invite-Link nutzen um beizutreten Wenn man nicht die Möglichkeit hat einen TS zu nutzen mag das wirklich "besser" sein aber das Problem hatte ich nie, dank meinem Hobby. Server, Domain und Ressourcen sind eh da. Wir haben übrigens einen Discord Server (Napper), wird eben nur kaum genutzt. Ich nutze aber auch meine TS kaum noch, da ich meine geringe Freizeit vollends für die Wartung und Projekte im Server Bereich einsetze oder einfach mal entspanne, ne Serie von meinen Servern streame und schlafe. Die GTX1080 rendert seit 4 Monaten auch eigentlich nur noch YouTube und Emby Streams - mit wenigen Ausnahmen.
  6. Kollege hat mich heute noch gefragt ob er soll, nope. würde immernoch 7700K kaufen. ich warte mit meinem 6700K eh noch ne ganze weile. höchstens wenn ich dann endlich irgendwann mal auf CL gehe wird alles auf den aktuellen stand gebracht, und auch nur damit ichs nicht alsbald wieder zerlegen muss
  7. von der eigentlichen truppe hier ist ja auch fast keiner mehr auf LTT unterwegs. und ich seh hier keine interessanten themen wo ich zeit opfern würde
  8. Bei dir liegen sich die Anwendungsfälle auch sehr nahe, wodurch eine Aufteilung in VMs nicht unbedingt sinnvoll wäre. Z.B. würdest du Media Storage aufs Netzwerk legen, was langsamer ist als direkter Plattenzugriff und einige Plex Features wie automatische Erkennung von Änderungen deaktiviert (geht nur bei lokalen Dateisystemen). Eine Kapselung von Apps in Containern ist es aber eigentlich immer (ist auch möglich Host Storage in den Container zu mounten -> Media). Ist eben die Frage ob es den Aufwand wert ist, da zB bei Plex Kommunikation ins Netzwerk gegeben sein muss. Da müsstest du dich ein wenig in Docker einlesen. Das ist nicht schwer - eigentlich sagst du nur "Plex Container Port 32400 -> Host Port 32400" oder gleich 80/443. Das ganze zu virtualisieren ist sinnvoll um eine Migration auf andere Hardware zu vereinfachen und die Ressourcen-Verteilung besser zu steuern. Letzteres kommt aber eigentlich erst bei mehr Apps zum Tragen, indem zu zB der Plex VM viel CPU Ressourcen gibst, dafür aber wenig RAM und Storage. Einer anderen VM, dann wieder zB mehr RAM o.Ä.. Es dient halt alles dazu den Host besser zu kontrollieren anstatt dass jeder Prozess Zugriff auf alle Ressourcen hat und sich diese unter Volllast darum prügeln müssen. So ziemlich jede Technologie in der Cloud dient zur Vereinfachung der Umsetzungen durch Automatisierung und der Garantie von Ausfallsicherheit. Und bei letzterer setzt die absolute Kontrolle der Hardware Ressourcen durch VMs an - nichts dem Zufall überlassen. Prozesse dürfen sich nicht gegenseitig beeinflussen oder gar abschießen.
  9. Hat er aber leider nicht. Also dann: Wenn man sich stark in diese Ideen eingelebt hat, kommen auch schnell so Gewohnheiten wie 1 VM pro Service oder 1 Container pro Service zu Stande. Container bieten gegenüber VMs dabei noch den Vorteil, dass sie schlanker sind, dadurch dass sie kein volles Betriebssystem mit sich bringen, maximal nur dessen Dateien - keinen laufenden Kernel. Dadurch lassen sich wesentlich mehr Apps auf der selben Hardware betreiben als in VMs. Ein Container lässt sich instant deployen, da er nur aus Dateien besteht. Eine VM muss erstmal installiert und konfiguriert, selbst im Falle eines Klons immerhin noch gebootet werden. Im Gegenzug sind Container schlechter isoliert, ihr Netzwerk ist wesentlich komplexer (virtuelle Tunnel, NAT, Forwarding etc) und man ist an den Kernel des Hosts gebunden. Einfachstes Beispiel: Du kannst keine Windows App Container auf einem Linux Host ausführen, außer der Container bringt seinen eigenen Emulator gleich mit und führt diesen aus. Andersherum kannst du auf einem Windows Server 2016 keine Linux App Container ausführen, da der Kernel diese nicht umsetzen kann. Letzteres ist mit dem Linux Subsystem in aktuellen Windows Versionen teilweise möglich, da dieses im Kernel die Linux Binaries emulieren kann. Wie gut das läuft, keine Ahnung. Aber es kann auch vorkommen dass gewisse Apps eine bestimmte Kernel Version oder Kernel Module benötigen. Bei Containern müssen dann entweder alle Container mit dieser Änderung am Host laufen oder man setzt einen neuen Host dafür auf. Hier treffen sich die beiden Welten oft - VMs als Docker Host. Dadurch kann man zB eine Docker Cloud sauber skalieren (Kubernetes oder Docker Swarm) und Betriebsysteme wie CoreOS (Container optimiert) einsetzen, ohne vollständig an diese gebunden zu sein (CoreOS für Docker, Debian für irgendwas, CentOS für was anderes, Windows für noch was anderes, etc). Apps sind einfach in die Docker Cloud zu droppen und laufen sofort, während die Hardware Verwaltung und Migration der eigentlichen Hosts ein Kinderspiel ist, dank VMs. Einfach neues Blech hinstellen (Hardware) und VMs migrieren - geht sogar live im Betrieb. Und nochmal zu der Geschichte mit persistentem Storage und Maschinen unabhängig von Treibern und Co. : Dadurch dass du die Maschinen nicht mehr auf die Hardware anpassen musst, mit Kernel Modulen, Treibern, deren Konfiguration etc, da sie in einer VM laufen - also abstrakt von der Hardware, und auch keine App Daten mehr lokal liegen, wird die Maschine wertlos und generisch. D.h. die Basis aller Maschinen gleicht sich an und sie wird leicht reproduzierbar. Das ist eben einer der Hauptgründe für Skalierung und das "Wegwerf"-Verhalten mit Cloud Maschinen. Irgendwas geht nicht oder soll geändert werden? Deploy einfach neu mit dem passenden Image/Modul.
  10. Ich hatte gerade nochmal nen halben Roman geschrieben und bin dann an meiner Maus auf "zurück" gekommen..... mal schauen ob ich mir das nochmal aus den Fingern sauge....
  11. VMs sind gut um Systeme unabhängiger und sauberer zu machen. Du trennst dadurch, dass Maschinen virtuell auf der selben Hardware laufen, den Netzwerkstack, Bibliotheken, Programme etc halt pro Einsatzzweck auf. Wichtigste Punkte eben das Betriebssystem (z.B. immer das optimale OS für den jeweiligen Einsatz - reicht ja schon wenn du eine Linux und eine Windows VM auf dem selben Hardware Server hast) und Netzwerk. Du kannst einem Server zwar auch einfach mehrere Netzwerkkarten oder VLANs geben und entsprechend IPs verteilen, aber wenn dir auf dem Server dann was daneben geht steht direkt absolut alles. Und das größte Manko an Bare-Metal (also direkt auf der Hardware zu laufen) ist, dass eine Migration auf eine andere Maschine extrem komplex ist, da sich Treiber und Storagearchitekturen ändern etc. Meist ist das mit Klonen der Festplatte oder Wiederherstellung aus Backup nicht getan, während das bei ner VM eben in ner Minute gemacht ist - meist sogar automatisiert. Und ansonsten gibts halt auch noch Sicherheitsaspekte, da du eine Anwendungen in ihr eigenes Betriebssystem mit festen Ressourcen (Sitchwort Ressourcen-Management) einsperrst. Ein ähnliches Konzept ohne eigenes OS, bzw. eig nur ohne eigenen Kernel sind eben Container wie Docker oder LXC. Dabei wird nur der Applikationsteil abgeschottet, jeweils mit eigenen Instanzen der Dienste und Bibliotheken die er braucht. Dadurch hast du eben wieder Unabhängigkeit zwischen den Apps (zB geteilte Perl-Bibliotheken, die eine App braucht Version B, die andere läuft aber nur mit Version A). Und dadurch dass Container als Image deployt werden können hast du keine händische Installation mehr. Gepaart mit persistent network storage und zentralen Datenbanken hast dann noch die Möglichkeit deine Appdaten dauerhaft zu speichern ohne sie an ein Deployment zu binden. Du kannst also einfach sagen "ok es gibt eine neue Version von der App. anstatt ein update zu machen deploy ich einfach das neue image und lösche das alte" oder der container geht kaputt. löschen und neu deployen. Durch den persistenten Speicher im Netz oder in einer unabhängigen Datenbank kannst du deine Dateien einfach wieder in das neue Deployment einbinden lassen und weiter gehts. Auch das Skalieren von Apps über Cluster APIs wie REST wird dadurch extrem leicht. einfach bei starker Last ein paar weitere Instanzen ausrollen und wenn die Anfragen abnehmen wieder löschen. Die Verteilung der Maschinen und Container Instanzen auf der Hardware lässt sich so ziemlich immer Automatisieren. Spielt halt alles in das Thema Cloud mit automatischer Skalierung, Lastenverteilung und Ausfallsicherheit.
  12. Total vergessen zu antworten... Fürs Streaming hatte ich jetzt fast zwei Jahre lang Plex im Einsatz, habe das aber nach mehreren Problemen bei mehr als einem Netzwerk im "Heimnetz", dem Cloud-Zwang (plex.tv) und der mehr als kläglich gelösten Konfigurationsdatei eingestampft und Emby aufgesetzt. Kostet im Premium auch das Gleiche (hatte vorher auch Plex Pass, hauptsächlich wegen Updates - DVR, CloudSync, etc brauch ich nicht) und hat die gleichen Premium Features. Hatte Emby vor nem Jahr schon mal getestet, da war es aber noch echt buggy. Die verwenden ja nur OpenSource Technologien, u.A. ffmpeg als Transcoder, wo Plex auf einen eigenen gewechselt ist - hauptsächlich wegen Kompatibilität. ffmpeg ist aber deutlich besser geworden. Man merkt zwar immer noch dass Emby eigentlich für Windows geschrieben wurde (muss unter Linux mit mono emuliert werden), aber es läuft echt performant und stabil. Und nach aktuellem Vergleich bringt Emby tatsächlich sogar mehr Frames bei gleichen Ressourcen zustande als Plex. Ich muss aber auch sagen, dass Plex' Apps für Android und FireTV minimal besser sind. Da entdecke ich doch recht oft kleine Bugs bei Emby. Und ich muss bei Emby nicht die Cloud-Accounts verwenden, um nicht 90% der Funktionen zu verlieren. Finde ich wesentlich charmanter. Auch den remote Zugriff mache ich nicht über deren Cloud, sondern per Reverse Proxy von meinem gemieteten Server in Frankreich (den ich hoffentlich bald kündigen kann wenn ich vier "neue" Hosts in der Firma unterbringen darf). Das hab ich mit Plex zwar auch schon gemacht, aber der hat trotzdem immer wieder nach Hause telefoniert (plex.tv). Aktuelle Emby VM: Mediatheken sind eingebundene SMB-Shares von meiner NAS - was eigentlich schon keine NAS mehr, sondern ein 170W ZFS Fileserver ist Wenn du zu irgendwas Fragen hast oder Bilder haben willst, einfach raus damit..
  13. Da meldet sich mein vergrabenes LTT-Chrome-Addon zu Wort und hier steht ein halber Roman drin... Damit hab ich nicht gerechnet. Ich guck auch weder LTT noch bin ich hier im Forum des Halbwissens aktiv. Sind mir einfach zu viele YouTube-Studenten unterwegs, neben den Leuten die wirklich Ahnung (größtenteils auf beruflicher Basis) haben. Zum Zocken komm ich kaum noch. Nach vollendeter Ausbildung und jetzt als Vollzeit beschäftigter "Linux Systems Engineer" hab ich kaum noch Zeit für Hobbies und dem Gaming haben meine heimischen Server den Rang abgelaufen. Falls wer gucken will: Wenn ich also Zeit finde schraub ich entweder an Enterprise Hardware, programmiere Puppet-Module zur Automatisierung oder gucke einfach ne Serie über meine selbstgehosteten Streamingserver. Vor allem da ich sehr viel mit Servern und Cloud im Beruf (und privat) zu tun habe, bringen mich Linus Server Videos zur Weißglut. Wenn im HomeLab Discord einer ein LTT Video postet, wird er direkt gesteinigt Auch das Wort unRAID ist eine Einladung zum Scheiterhaufen. Wenn sich das also noch wer gibt, bitte nicht für bare Münze nehmen, was er da so alles sagt und zeigt. Wenn ich aber doch mal Zeit zum Zocken habe isses mit Kollegen und da aktuell PUBG oder Overwatch. Letztens auch mal Fortnite angetestet. Dennoch kann ich den Steam Sales nicht absagen und mein Pile of Shame wächst jede Saison weiter... Gleiches für meinen Desktop. Der Hardware Enthusiasmus ist geblieben - auch für YouTube bleiben 6700K und die 1080 drin. Und so wie das aussieht wird der nächstes Jahr auch nochmal aufgerüstet...
×