|
|
|
|
| Zitat von [KdM]MrDeath
| Zitat von hoschi
Und um mich dem Kommentar bei Stackexchange anzuschliessen, bitte ss aus iproute2 verwenden. Nicht netstat
| |
aber ifconfig wird doch wieder gepflegt!
und direkt ne inkompatibilität reingemacht
|
net-tools (1.60+git20161116.90da8a0-1) unstable; urgency=medium
After 15 years without upstream development, net-tools is being worked on
again, fixing many long-standing issues.
The bad news is that the output of many commands has changed, and it is sure
to break scripts that relied on parsing it.
If you have customs scripts that use any of these commands, please make sure
they still work after this upgrade:
netstat, ifconfig, ipmaddr, iptunnel, mii-tool, nameif, plipconfig, rarp,
route, slattach, arp.
Apologies in advance for the trouble that this may cause, but maintaining a
separate version of net-tools just to keep the old format is something I am
not able to do.
-- Martín Ferrari <tincho@debian.org> Mon, 26 Dec 2016 05:29:25 +0000
| |
| |
Das waere mit dem Naziprogramm nicht passiert
| Zitat von Oli
Wieso fahren alle so auf Ninja ab? Die von cmake generierten Makefiles laufen bei mir (parallel) schneller durch als der initial build mit Ninja. Inkrementelle builds sind etwa gleich schnell. Oder sind die build files, die `cmake -G Ninja` erstellt nur schlecht?
| |
Ich denke der Hype kommt durch Meson. Was bis auf diesen komischen Ausrutscher, der nur Windows betraf ( ), bei mir auch erstmal schoen laeuft. Jetzt kann es sein, dass viele Projekte von den Autotools auf Meson/Ninja umsteigen und der Lobgesang daher groesser ist?
make -> ninja
autotools (autoreconf, autoscan, automake..) -> meson
Ich kenne CMAKE nicht aus der Praxis, also kann ich diese Seite wiederum nicht bewerten.
| Zitat von Oli
Ryzen finde ich ja ganz interessant. NNur, dass die keinen Grafik Chip drin haben, stört mich - ich bin immer gut mit den Intel HD Dingern gefahren, zocken will ich ohnehin nicht. Welche billige Graka kauft denn der Programmierer von heute zum Ryzen CPU dazu?
| |
Kaufe dir einen RyZen und eine normale Low-Profile-Grafikkarte oder etwas minimal besseres (wegen DisplayPort und so) wie eine RX550. Mit der RX550 hast du dann Displayport und HDMI und FreeSync und die Karte nimmt dir keinen Arbeitsspeicher weg, vielleicht also besser wegen UltraHD Monitoren. Oder du wartest noch bis zum Sommer und holst dir dann eine APU
Generell sind dedizierte Komponenten immer besser, ausser es kommt auf Platzersparnis an. Im Laptop braucht eine seperate GPU viel Platz und eine eigene Kuehlung und die Energieersparnis steht im Vordergrund. Und dann sind sie nicht austauschbar! Weswegen die interne Grafikchip die bessere Wahl ist, IntelHD eben
|
[Dieser Beitrag wurde 13 mal editiert; zum letzten Mal von hoschi am 04.05.2017 12:10]
|
|
|
|
|
|
Hab's ja schon öfter gesagt, aber bei neuen Build-Systemen bin ich immer erstmal skeptisch. Besonders wenn die Kiste in Python geschrieben ist und noch extra Dependencies mitbringt. Das macht Bootstrapping nämlich nicht einfacher.
e: Imperative Konfiguration? Ich dachte wir wüssten schon, dass das nicht funktioniert.
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 04.05.2017 11:57]
|
|
|
|
|
|
Python ist in dem Fall auch so eine Dependency (meine Allergie gegen Depedencies hat nachgelassen, aber sie ist noch da) die ich nicht brauche, aber wohl wesentlich besser als M4 und irgendwelche UNIX-Textersetzungsvoodoo wie bei den Autotools. Und Python ist wirklich immer schon installiert.
Sie betonen bei Meson auch zwei Dinge, sind nutzen bewusst keine Sprachfeatures von Python im 'meson.build'. Es gibt naemlich gerade Pythonprogrammierer, die natuerlich gerne Abkuerzungen nehmen wuerden mit Pythonfeatures in den Buildfiles. Und darauf aufbauend betonen sie, dass jemand C/C++/Go/Rust oder eine andere Snake_Case_Sprache einfach toller findet und man dann nochmal mit nativem Quellcode mehr Performance herausquetschen koennte. Ich weiss aber auch, dass du schon gegenueber Python skeptisch eingestellt bist.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 04.05.2017 12:03]
|
|
|
|
|
|
Eigentlich mag ich Python ja sehr (Sprache, manche Communities, manche Libraries) und habe sehr viel Code damit geschrieben ...
... aber es wäre schon ganz nett, wenn der Scheißdreck nicht alle Nase lang auseinanderfallen würde. Ich bin irgendwelche obskuren Import-Fehler, komische, unreproduzierbar falsche Pfade in tox, py.test was irgendwelche Module nicht findet, setup.py was es IRGENDWIE manchmal schafft Sachen für eine falsche ABI zu kompilieren (size mismatch blabla) einfach leid. Oder so ganz simple Basics wie unreproduzierbar kaputtes Assertion-Rewriting in py.test. Unlogische, unreproduzierbare Fehler mit scm_setuptools (auf dem EXAKT gleichen git-Repo!). Python-Deployment war nicht mal schlecht und ist jetzt besser geworden. Python-Deployment IST schlecht.
Da braucht man sich gar nicht mehr über npm lustig machen, das fällt auch nicht öfter auseinander. Und da sind wir noch gar nicht dabei, wie bestenfalls schwierig nahezu jede größere Python-Codebase ist. Dynamische-Sprachen-Apologeten "Aber das funktioniert auch alles ganz toll für große Anwendungen!11" können mich mal.
Ich kann Leute verstehen, die Python-Software aus Prinzip nicht ernst nehmen.
Oli: https://geizhals.de/?cat=gra16_512&v=e&hloc=at&hloc=de&fcols=24&bl1_id=30&xf=11570_passiv+(l%FCfterlos)~653_AMD
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von csde_rats am 04.05.2017 12:12]
|
|
|
|
|
|
Bei uns ist Python verboten, als Entwicklungs aber auch Infrastruktursprache. Auch ein Mittel...
|
|
|
|
|
|
|
ich bin ja nach wie vor sehr gespannt, wie das mit der CoreCLR und co weitergeht.
|
|
|
|
|
|
|
Dito. Das wäre auch definitiv etwas für hier.
|
|
|
|
|
|
|
https://bugs.archlinux.org/task/53831
Ich kann an dem Zertifikat bestimmt nichts aendern, schlecht gemacht OpenSSL. Das mit MD5 ist doof und ich habe das schon weitergegeben, aber so schnell bewegen die sich bei uns sicher nicht.
Loesung: VPNC weiter verwenden
Damit ist niemandem geholfen und wir haben ein Paradebeispiel dafuer, was eine dicke fette Warnung sein sollte und stattdessen ein harter Fehler ist. Damit hat OpenSSL 1.1.0 hier das Internet unsicherer gemacht
Das ist wie die lustigen Aktionen von Firefox und Chrome, die schwach verschluesselte Websiten nicht laden. Ja was passiert dann? Genau https://.
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von hoschi am 04.05.2017 15:31]
|
|
|
|
|
|
| Zitat von hoschi
Ich kann an dem Zertifikat bestimmt nichts aendern, gut gemacht OpenSSL. Das mit MD5 ist doof und ich habe das schon weitergegeben, aber so schnell bewegen die sich bei uns sicher nicht.
| |
lol, du gibst im jahr 2017 openssl die schuld weil es nichtmehr mit md5 zertifikaten zusammenarbeiten will? nimm doch gleich plaintext!!eins!elf!
ja, du kannst daran _jetzt_ nichts ändern, aber es steht ausser frage dass der dienste anbieter sich da bewegen muss. und das hätte er locker schon vor ~3 jahren machen müssen... man kann nicht einerseits auf openssl bugs schimpfen da im jahr 2015 server geknackt werden weil die noch ne (deaktivierte) implementierung von SSL2 im code rumliegen haben (DROWN-Attacke) und dann gleichzeitig sich beschweren wenn _endlich_ mal md5 rausfliegt. da hatte echt _jeder_ genug vorlaufzeit und genug warnschüsse.
|
|
|
|
|
|
|
Du haettest auch einfach den Kommentar im Bug zitieren koennen
| I don't consider this a packaging, OpenVPN or OpenSSL bug. MD5 SSL certificates were proven insecure in 2008, Microsoft killed MD5 CA certificates in 2014, now OpenSSL on Archlinux does it in 2017. Google is pushing for SHA1 deprecation since 2014.
| |
Ich war vorher und bin jetzt deiner Meinung. Aber ich bin hier User, ich kann nicht eingreifen. Ich bin wehrlos. Und ein "Downgrade" auf VPNC ist halt nicht hilfreich. Mein Punkt ist "Bitte unbedingt warnen!" aber nicht fremde Sandburgen kaputt machen. Ja. Die Sandburg seht zu nah am Wasser, die naechste Flut kommt...aber lass sie jetzt stehen.
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 04.05.2017 15:47]
|
|
|
|
|
|
So wird man den alten, unsicheren Ranz halt nicht los.
NIEMAND hört auf Deprecation Warnings.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 04.05.2017 16:01]
|
|
|
|
|
|
Und jetzt halte dich fest:
Das OpenVPN ist neu ):(
|
|
|
|
|
|
|
|
|
|
|
Ne. Gewachsene Infrasturktur. Lieber einer Personal-Firewall davor!
// edith meint:
Kernel 4.11 erlaubt einem ja direkt im Kernel fuer ASPM vorgaben zu machen:
- BIOS-Werte
- Powersave
- Mehr Powersave
- Performance
Ich probiere jetzt mal "Powersave" und vielleicht muss dann powertop --auto-tune nicht mehr so aggressiv eingreifen?
// edith sagt: Doch, muss es. Also zurueck auf "BIOS-Werte"
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 04.05.2017 21:54]
|
|
|
|
|
|
|
|
|
|
i have bad news for you
oh und wegen vim letztens, vergiss es, war eh blödsinn der nich zu ende gedacht war
|
|
|
|
|
|
|
Hat mich trotzdem auf die Idee gebracht zu suchen. Es gibt ja einen Hack.
Wegen Saturn V: Verdammtes pOT!
|
|
|
|
|
|
Was zum...
|
Ich habe gerade mit less eine Logfile beobachtet und war im Follow-Modus mit Shift+f. Wollte dann etwas im Webbrowser schreiben und habe nicht bemerkt, dass ich noch im Terminal bin.
Irgendwie habe ich aus less heraus GNU-Nano gestartet
|
|
|
|
|
|
|
Mit v startet man aus less $EDITOR um die aktuelle Datei zu bearbeiten.
|
|
|
|
|
|
|
Ah! Danke! $EDITOR ist nicht belegt, aber Ubuntusohn hat sicher NANO irgendwo hardgecodet. Irgendwie ist das...praktisch
|
|
|
|
|
|
|
| Zitat von [CSF]Omega
Mit v startet man aus less $EDITOR um die aktuelle Datei zu bearbeiten.
| |
Geil. Shift-F kannte ich auch noch nicht, nice.
|
|
|
|
|
|
|
Ctrl-Shif-W startet den eingebauten Web-Browser.
|
|
|
|
|
|
|
| Zitat von statixx
| Zitat von [CSF]Omega
Mit v startet man aus less $EDITOR um die aktuelle Datei zu bearbeiten.
| |
Geil. Shift-F kannte ich auch noch nicht, nice.
| |
Ist die beste Tastenkombination neben Shift+zz in VIM
|
|
|
|
|
|
|
|
|
|
|
Sagmal tek, bist du nächste Woche an der Jazz/RTC usw Konferenz?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Eher *topkek*
Intel bestaetigt in allen Punkten, wie gefaehrlich Fremdsteuerung durch Dritte ist. Leider ist Windows 10 mit dem Liveupdate das Gleiche, nicht so tief eingebaut, aber weiter verbreitet. Falls die Geruechte stimmen, ist uebrigens ein groesseres Sicherheitleck in letzterem. Irgendwas mit Remoteangreifbarkeit in der Standardinstallation.
PS: "I'Robot" laeuft gerade, diese rote Leuchten beim Liveupdate durch USR beruhigt irgendwie nicht
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von hoschi am 06.05.2017 21:06]
|
|
|
|
|
|
| Zitat von hoschi
Falls die Geruechte stimmen, ist uebrigens ein groesseres Sicherheitleck in letzterem. Irgendwas mit Remoteangreifbarkeit in der Standardinstallation. | |
Drei Posts über deinem, Twitterlink
|
|
|
|
|
|
Thema: Der Linux-Thread 100 // 0x23 ( const int MAX_POST = 30 * 100; // 0x23 ) |