|
|
|
|
|
|
|
|
Aber wenn du nach nem BGP Angriff halt mal den Traffic von Holland routen musst?
|
|
|
|
|
|
|
|
|
|
|
der bastelaufwand waren so in etwa 10 minuten. das ist nach wie vor nen SoC. das basteln beschränkte sich da primär auf das verlegen der kabel in dem gehäuse, wenn man mal lüfter reinstecken und platte reinschrauben aussen vor lässt.
die kosten sind natürlich ein klein wenig höher, aber es gibt halt nicht wirklich irgendwas im hosentaschenformat, was vernünftig mehr als nen gigabit routen kann.
wobei dieses board halt auch noch mit die kleinste version von dem teil ist, den gibts auch noch als 16-core version und nem SAS bzw. U.2 RAID chip on-board.
das teil wird halt auch iptables und co machen, aber halt auch direktes routing sowohl intern, als auch extern.
auch wenn das teil natürlich etwas mehr kann, effektiv ist das trotzdem ne lustige platform mit nem leicht übertriebenen lspci output.
wenn man das board jetzt nicht unbedingt in das 19 zoll gehäuse verpflanzt, dann drückt das den preis schon noch um einiges. das board geht halt für ca. 390 euronen. dafür bekommst du dann ne dual port X552 intel nic, mit 2 i210 und ner quad port powerville aka i350-t4, dazu gibts dann noch zwei x8 PCIe 3 slots.
aktueller plan dafür ist, die beiden 10 gbes gehen jeweils zu nem switch, an die beiden i210 kommen die beiden aussenanbindungen (wovon bisher nur eine da ist...). das teil soll dann zwischen vlans routen, wenn ich die aus "gründen" nicht auf dem switch direkt routen kann und soll jeglichen multicast scheiss managen.
es ist aber auch ein wenig investition in die zukunft. 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Rufus
APROPOS Router, darf ich euch die Geilheit vorstellen, die mir gerade die Sonne aus dem Arsch scheinen lässt. Wie einige sicher wissen, nutze ich seit Jahren kleine Boards als Router. Cubietruck, Wandboard, Raspi, zuletzte die APU2 von pcengines. Jedes Board hatte bisher irgendeine Scheiße, die nicht ins 21. Jahrhundert passte. Entweder ARM mit obskuren Repos, nur ein Ethernet onboard oder kein SATA. Die APU war zuletzt der beste Kompromiss, x86, 3x Ethernet, aber kein echtes BIOS, sondern mit seriellem Gehampel zu flashen, System dann nur von SD bootfähig.
Die Suche nach schmerzlosem Minicomputing hat nun ein Ende: https://www.zotac.com/us/product/mini_pcs/ci327-nano
- x86 (Centrino)
- SATA (bootable)
- Dual Gigabit + WLAN onboard
- HDMI (+DisplayPort)
- viele USB 2/3-Ports und SD-Slot
- normales BIOS
Ist somit nicht mehr von einem normalen PC zu unterscheiden. Monitor+Tastatur+Maus+Installationsstick des Lieblingssystem dran, aufsetzen, fertig.
FICK JA ENDLICH
| |
Das sieht echt ziemlich cool aus. Hast du schon einen?
/e: Lediglich wifi könnte vermutlich besser sein, mit zwei Antennen. Und sehe ich es richtig, dass 802.11n nicht mehr unterstützt wird? Also nur 5 GHz?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 23.05.2018 8:52]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
bahn.de Login-Flow-Chart (je-des-mal)
Login
->
Benutzername/Passwort falsch.
->
Benutzername/Passwort falsch.
->
Benutzername/Passwort falsch.
->
Passwort vergessen
->
Keine Identifizierung möglich
(Hinweis: Nach zwei Jahren werden Logins automatisch entfernt)
->
Neuanmeldung
->
Benutzername
->
Formular so: Benutzername ✓
->
Formular abschicken
->
Dieser Benutzername ist schon vergeben
->
???
->
Passwort vergessen
->
???
->
Passwort zurücksetzen
->
?!
->
Ticket kaufen
|
|
|
|
|
|
|
|
|
|
|
Hassthread? Oder Funthread 
Ich habe das hier nicht so kritisch gesehen, aber diese Nutzungsfall ist wirklich nett und gut. UNIX als IDE.
|
|
|
|
|
|
|
|
|
|
|
|
Ein Dateimanager, der keine Programme starten kann? Sowas kanns nur bei Gnome geben.
|
|
|
|
|
|
|
|
|
|
|
Japp. So haben viele reagiert. Ich nicht - merkwürdig.
Unter Linux verwende ich Nautilus permanent zum Verwalten und Öffnen von Dateien, aber so gut wie nie um Programme explizit zu starten. Als Einsatzfeld habe ich nur vermurskte Javaprogramme mit Wrapperscript ohne .desktop Datei wahr genommen. Auch sowas, wie CEWE-Fotobuch, hängt sich unter ~/.local/share/application ordentlich ein. Eben als Dateimanager, weniger als Programmstarter wie unter Windows zwingend notwendig. Bemerkenswerte finde ich, dass der Entwickler eingesehen hat, dass er nicht Recht hat und langfristig sogar eine Verbesserung plant. Das kenne ich, so vom Chefentwickler vom gnome-terminal nicht, also pflegt ein Co-Maintainer ständig die Hintergrundtransparenz nach.
Ich war allerdings mit dem Entwickler von Nautilus schon Joggen und verzeihe dann schneller 
|
|
[Dieser Beitrag wurde 9 mal editiert; zum letzten Mal von hoschi am 23.05.2018 11:38]
|
|
|
|
|
|
|
|
|
Einer der beste persönlichen Errungenschaften der letzten Zeit für mich ist, .desktop Dateien zu erstellen. Alacarte ist nett, aber die Desktop-Shell sollte das direkt unterstützen. Insbesondere bei Java sollte man als Workaround die Option StartupWMClass (in der .desktop) auf die Mainklasse setzen, weil eine Spezifikation nicht erfüllt wird. Wrapperscript ist sowieso notwendig, wegen dem Aufruf der VM und die meisten Javaanwendung funktionieren nicht, wenn man das Arbeitsverzechnis nicht auf das Verzeichnis der JAR ändert.
Und generell nicht mit dem Toolkit (Gtk, Qt...) das Icon der Anwendung setzen, funktioniert nur unter X11. Die .desktop Datei übernimmt das, speziell unter Wayland.
|
|
[Dieser Beitrag wurde 5 mal editiert; zum letzten Mal von hoschi am 23.05.2018 11:40]
|
|
|
|
|
|
|
|
|
Ich habe jetzt knot-resolver endlich mal eingerichtet. In Sachen Konfiguration war systemd etwas nervig, vielleicht schicke ich da mal nen Patch Richtung manpage.
Ich habe das erstmal minimalinvasiv gemacht, d.h. Anfragen laufen nach wie vor über dnsmasq, der dann knot-resolver als (einzigen) Upstream hat.
1.) knot-resolver installieren
2.) systemctl edit kresd.socket
[Socket]
# v- Existierende ListenXY werden dadurch entfernt, sonst nimmt die Kiste per Default 127.0.0.1:53 & Co. mit
ListenDatagram=
ListenStream=
ListenDatagram=127.0.0.1:54
ListenStream=127.0.0.1:54
3.) dnsmasq.conf
no-resolv
server=127.0.0.1#54 <-- :54 mag er gar net
4.) daemon-reload; enable kresd.socket; start kresd.socket; restart dnsmasq
Die kresd-Docs erklären dann, wie man aufs Terminal vom Daemon kommt (kresd.socket wants kresd@1.service):
# nc -U /run/knot-resolver/control@1
> cache.count()
196
> worker.stats()
[rss] => 14876672
[pagefaults] => 0
[csw] => 184
[queries] => 59
[tls] => 0
[timeout] => 9
[swaps] => 0
[systime] => 0.024575
[udp] => 144
[dropped] => 0
[ipv6] => 66
[concurrent] => 0
[tcp] => 0
[ipv4] => 78
[usertime] => 0.033791
> ^C
... auch eine Möglichkeit ein separates CLI-Tool & IPC-Protokoll zu vermeiden.
Wenn man das ganze via systemd macht, dann läuft kresd automatisch als nicht-root, wie es sich gehört.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 23.05.2018 15:09]
|
|
|
|
|
|
|
|
Stellt sich raus, dass knot-resolver so feine Software ist, dass man lediglich ein hints.add_hosts() in die Config schreiben muss, damit es exakt das gleiche wie dnsmasq tut.
Und das Ding kann eine Menge interessanter Dinge von sich aus, z.B. selbstständig demnächst ablaufende Einträge im Cache erneuern.
Dickes Danke für die Empfehlung hier im Thread. 10/10.
e: Man möchte möglicherweise (wenn man z.B. konfuse Anforderungen wie "DHCP-Clients sollen per Default DNS kriegen" hat  ) noch dhcp-option=option:dns-server,meineip in der dnsmasq-Config ergänzen. Und dann möchte man die Leases auf den entsprechenden Rechnern, bei denen DNS dann eventuell nicht mehr ging, erneuern, sofern es solche Rechner gibt, was ich weder bestätigen noch dementieren kann. Windows holt sich übrigens ein neues DHCP-Lease, wenn man einmal die IP-Einstellungen öffnet und ohne Änderungen wieder schließt. Habe ich gehört. Vom Freund eines Schwagers, den ich selten sehe.
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von csde_rats am 23.05.2018 20:34]
|
|
|
|
|
|
|
|
|
BIOS-Updates Coming Soon 
<Lügenbaron>Keine Angst, alles ist dann sicher! Und ihr System wird nicht langsamer.</Lügenbaron>
|
|
|
|
|
|
|
|
|
|
|
Ich hab zu dem Knot-Dimselbums mal einen Artikel im Arch-Wiki angelegt. Bei "Wiki" kriege ich ja schon direkt ein leicht schlechtes Gefühl im Bauch, dass ich gerade meine Zeit verschwende weil irgendein Blockwart gleich um die Ecke kommt und Dinge aufwischt. Im Arch-Wiki kamen stattdessen Leute um die Ecke und haben den Artikel verbessert und schöner gemacht.
Plötzlich ist mir klar, warum dieses Wiki wirklich so gut ist.
|
|
|
|
|
|
|
|
|
|
|
Ich habe da auch schon Sachen gepflegt 
¯\_(ツ)_/¯
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 24.05.2018 15:20]
|
|
|
|
|
|
|
|
|
|
Ich gehe mir mit meinem Arch Fanboyism eigentlich schon selbst auf die Nerven, aber es ist halt einfach <3.
|
|
|
|
|
|
|
|
|
|
|
|
Was kann das was andere Systeme nicht können, außer komplizierter sein?
|
|
|
|
|
|
|
|
|
|
|
Für wirkliche Produktivsysteme nichts. Für Studenten oder ähnliches ist es eine wunderbare Grundlage um mehr über das Betriebssystem zu lernen.
Und die Community dazu ist gut. Es macht den Einstieg produktiv teilzunehmen recht einfach.
Und da es sehr aktuell ist, macht spielen und ausprobieren damit auch Spaß.
|
|
|
|
|
|
|
|
|
|
|
|
ist wie Gentoo, nur ohne die beruhigenden Compiler-Pausen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von TheRealHawk
Was kann das was andere Systeme nicht können, außer komplizierter sein?
| |
Was ich genieße ist, dass es sehr nah am "standard" Linux ist, das Wiki sehr, sehr gut ist, es unglaublich viele special snowflake packages im AUR gibt und es rolling release hat. Ich teste dauernd irgendwelche wissenschaftlichen Codes mal eben aus und dazu muss der build Prozess und das Nachinstallieren komischer dependencies so einfach wie möglich sein. Für die Art von Arbeit ist arch perfekt,finde ich.
/e: Immer wenn ich irgendwo ein Paket kompilieren will, gucke ich in das AUR build script, anstatt ./configure --help zu machen.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 24.05.2018 20:15]
|
|
|
|
|
|
|
|
|
|
Ich müsste inzwischen auch mal wechseln. Aber jedes anspruchsvollere Deployment besteht inzwischen aus docker-compose up -d :/
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von GarlandGreene
ist wie Gentoo, nur ohne die beruhigenden Compiler-Pausen.
| |
Das war tatsächlich ziemlich nice im Praxissemester.
"Ihr seid ja eigentlich nur am Kaffee saufen!"
"Nö, wir installieren Gentoo Stage 1."
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von TheRealHawk
Was kann das was andere Systeme nicht können, außer komplizierter sein?
| |
Es ist pures GNU/Linux:
- Upstream Pakete, ohne Änderungen
- Upstream Stable, es ist aktuell
- Gute Dokumentiert, Wiki
- Unkompliziert, folgt dem KISS-Prinzip
- Maintainer sind zugänglich
- Nachteil, keine vorkompilierten Debugpakete
Toll für alle Informatiker auf dem privaten oder geschäftlichen System. Nichts für den geschäftliche Server oder normale Leute.
|
|
|
|
|
|
|
|
|
|
|
Das größte Problem an Arch ist, wenn man dann plötzlich vor Systemen sitzt, die feature mäßig zwischen 2 bis 5 Jahren hinterherhinken und man sicher wundert, warum feature xy plötzlich nicht funktioniert.
aka
"C++11 support EXPERIMENTAL"
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von RichterSkala am 24.05.2018 22:14]
|
|
|
|
|
|
|
|
Ich möchte lösen! Das gesuchte Worte ist “Debian”?!
Wäre interessant ein fünf Jahre altes Arch mal zu aktualisieren 🧐
|
|
|
|
|
|
|
|
|
|
|
|
Hab das Problem da nicht, aber ich nehm für den Desktop auch eh testing/sid.
|
|
|
|
|
|
|
|
|
|
|
Ich habe das Problem nicht, weil ich nicht für den Desktop entwickle.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Wäre interessant ein fünf Jahre altes Arch mal zu aktualisieren 🧐
| |
Meine aktuelle Desktop-Arch-Installation (die ich auf zwei Rechner geforkt habe ) müsste noch von 2012 sein.
Die wurde allerdings mehr als einmal geupdated - glaube ich
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 24.05.2018 22:32]
|
|
|
|
|
|
|
|
|
| | Zitat von SwissBushIndian
Ich habe das Problem nicht, weil ich nicht für den Desktop entwickle.
| |
Ja gut, das auch.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Ich möchte lösen! Das gesuchte Worte ist “Debian”?!
Wäre interessant ein fünf Jahre altes Arch mal zu aktualisieren 🧐
| |
CentOS, ist ein HPC. Naja, kein problem, erst mal eigenen gcc builden
(In aller fairness, da ist ein Intel Compiler drauf, der womöglich besser ist, aber ich hatte weder Zeit noch Lust mich damit auseinanderzusetzen und ich oller hipster hab natürlich mein Zeug in c++17 gemacht, dafür hatte der noch nicht mal ne flag)
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
| | Zitat von hoschi
Wäre interessant ein fünf Jahre altes Arch mal zu aktualisieren 🧐
| |
Meine aktuelle Desktop-Arch-Installation (die ich auf zwei Rechner geforkt habe ) müsste noch von 2012 sein.
Die wurde allerdings mehr als einmal geupdated - glaube ich
| |
| |
| Code: |
[2012-12-28 11:43] Running 'pacman -r /mnt -Sy --cachedir=/mnt/var/cache/pacman/pkg --noconfirm base base-devel'
[2012-12-28 11:43] synchronizing package lists
[2012-12-28 11:44] Running 'pacman -r /mnt -Sy --cachedir=/mnt/var/cache/pacman/pkg --noconfirm base base-devel'
[2012-12-28 11:44] synchronizing package lists
[2012-12-28 11:44] installed linux-api-headers (3.6.3-1)
...
...
...
[2018-05-18 12:11] [ALPM] running 'systemd-update.hook'...
[2018-05-18 12:11] [ALPM] running 'texinfo-install.hook'...
[2018-05-18 12:11] [ALPM] running 'update-ca-trust.hook'...
|
|
War mal mein Desktop in der Arbeit, dann Umzug auf SSD, dann Umzug ins ThinkPad. Mal schauen wo es die Installation noch so hinzieht. Meine Kollegen aus Spanien bevorzugen offenbar CentOS mit KDE.
Wobei einige Server hier wesentlich älter SLES-Installation sind, leider haben die nie Updates erhalten. Ich fasse da nichts an, in dem Moloch aus RPM mache ich nur alles kaputt und es läuft nicht mehr
Ich darf für Server, Web und Desktop gleichzeitig entwickeln.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 25.05.2018 11:53]
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |
