|
|
|
|
|
|
|
|
wow, und ich dachte unsere Sophos-Firewall wäre Dreck. Was setzt ihr ein?
|
|
|
|
|
|
|
|
|
|
|
|
Das betreffende Gerät ist ne klitzekleine Juniper von anno Josef. Ich habe keine Ahnung, wie deren aktuelle Reihen DNS-Objekte handlen. Das sage ich fairerweise dazu.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Rufus am 25.04.2017 21:08]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
ich muss also leider hoffen dass du dieses Feature nicht bekommst. Und am Ende dreht sich das gegen dich
| |
Hab ich schon, steht am Ende im Text: autocomplete="new-password" 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Rufus
Sicherlich die beste, aber gleichermaßen ausgeschlossenste Option. Noch was?
| |
Internet -------------------> Endgeräte
x x
\-Firewall-/
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von TheRealHawk
| | Zitat von hoschi
ich muss also leider hoffen dass du dieses Feature nicht bekommst. Und am Ende dreht sich das gegen dich
| |
Hab ich schon, steht am Ende im Text: autocomplete="new-password"
| |
Vernuenftige Entscheidung! So lange die in der "sozialen Einrichtung" nicht die Faehigkeit entwickeln einen anderen Webbrowser (der das nicht versteht) zu installieren, hast du deine Ruhe.
// edit
Ich weiss nicht ob ich dauerhaft zum Maintainer geeignet waere. Irgend so ein Upstream-Projekt haut unvermittelt ein Update raus und man will dann ja sofort das perfekte Paket an die Anwender ausrollen. Wenn das Projekt aber etwas stark veraendert hat oder sogar kaputt gemacht hat, braucht das laenger. Ich haette da immer Angst nicht gruendlich genug oder zu langsam zu sein. Und wenn ein Datum fuer das Release feststeht wird es nicht besser.
Bin heute auf GNOME 3.24 hoch, scheint alles zu funktionieren. Paar kleine neue Features bemerkt und keine entfernten Features festgestellt 
GNOME-Builder hat weiterhin Probleme mir die "Symbole" von C++-Klassen anzuzeigen, funktioniert wenigstens gelegentlich. Empathy hatte den Single-Window-Mode unter Archlinux schon vorarb. Die URL in Epihany ist jetzt immer ein Eingabefeld, wie ueberall, sehr schoen. Und gnome-recipes fehlt bei Archlinux noch bei den offiziellen Pakete. Ich will das haben!
|
|
[Dieser Beitrag wurde 7 mal editiert; zum letzten Mal von hoschi am 26.04.2017 1:19]
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
| | Zitat von Rufus
Sicherlich die beste, aber gleichermaßen ausgeschlossenste Option. Noch was?
| |
Internet -------------------> Endgeräte
x x
\-Firewall-/
| |
Mein Traum vom sauberen Netz. Aber wir wissen doch, die gewachsene Infrastruktur muss von der Plastikfirewall von Schlaengenoel Corp. geschuetzt werden.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Rufus
| | Zitat von TheRealHawk
Hatte mich schon gefragt wer noch FTP nutzt.
| |
*meld*
Und zwar für security.debian.org. Wo wir schon dabei sind, hat vielleicht jemand ne Idee:
[...]
| |
hmmm, einfach mal ein paar möglichkeiten in den raum geworfen, für gut oder schlecht befinden darfste dann selber:
proxyserver aufsetzen und den in der firewall freischalten? bei nem proxy kannste whitelisting auf urlbasis betreiben...
ansonsten noch spezieller: approx nehmen und den rechner auf dem das läuft in der firewall auch für alles was auf port 80 ist ausgehend freischalten?
approx ist mir aber gelegentlich alle schaltjahre mal verreckt, da hats geholfen den cache zu löschen und das ding lief wieder.
|
|
|
|
|
|
|
|
|
|
|
ich frag mich da gerade, wo du da mehr als 4 IPs zurück bekommst?
ich bekomme hier sehr spezifisch immer die gleichen 4 v4 und die gleichen 3 v6 adressen zurück. egal ob ich die via meinem lokalen resolver ziehe oder von dem isp dns oder von googles.
die sind halt auch DNSSEC signiert. da würd es mich schon wundern, wenn die sich andauernd ändern würden, weil das nen ziemlicher aufwand werden dürfte da andauernd die sachen neu zu signieren und die alten zu entfernen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Traxer
ich frag mich da gerade, wo du da mehr als 4 IPs zurück bekommst?
| |
Also for starters wären hier schonmal 10:
128.31.0.63
128.61.240.73
133.242.99.74
149.20.20.6
150.203.164.38
195.20.242.89
200.17.202.197
212.211.132.32
212.211.132.250
217.196.149.233
In welchen Mustern und Intervallen die alternieren, und was die dafür für Verrenkungen betreiben müssen, interessiert mich eigentlich nicht für fünf Pfennig.
Habe jetzt btw einfach villa, lobos und wieck in die apt.sources geschrieben und ignoriere die Warning von apt, dass Quellen doppelt sind.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Rufus am 26.04.2017 20:08]
|
|
|
|
|
|
|
|
|
|
sicher das dass der gesicherte security.debian.org kram ist, den du da bekommst und nicht direkt cdn.debian.net aka deb.debian.org?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von TheRealHawk
Ich hätte damit kein Problem, wenn die Vergabe eines Master-Kennworts für die Speicherung von Kennwörtern verpflichtend wäre. So kann aber jeder einfach im Browser das Klartextkennwort einsehen.
PS: Debian shutting down public FTP services
Hatte mich schon gefragt wer noch FTP nutzt.
| |
die leute von golem beweisen da leider ausserordentliche kompetenz... nicht
| |
Vor allem im Vergleich zur Linux-Community ist an der Entscheidung von Debian interessant, dass das Projekt als Alternative zu FTP das unverschlüsselte HTTP empfiehlt und anbietet. Die Kernel-Hacker setzen stattdessen auf HTTPS. Die Debian-Archive sind darüber hinaus auch überhaupt nicht per HTTPS erreichbar. Der Versuch, per HTTPS auf die Archive zuzugreifen, führt zudem zu einem Zertifikatsfehler.
| |
würd ne wette eingehen dass es keine 30 sekunden googlesuche braucht bis man auf die begründung dafür stösst
Spoiler - markieren, um zu lesen:
debian sichert seinen mechanismus über das signieren der repository files und der pakete selbst ab. sie wollen kein https weil es da schwierigkeiten gibt mit cnames usw für mehrere mirrors. da müssten sie dann mit weiterleitungen arbeiten was sie wohl nicht wollen
|
|
|
|
|
|
|
|
|
|
|
|
Dass man apt-transport-https erst nachinstallieren muss wenn man Drittanbieter-Repos einbinden will ist trotzdem etwas meh, vor allem wenns dann nicht funktioniert (evtl. mangels SNI, hatte keine Lust mich weiter damit zu beschäftigen).
|
|
|
|
|
|
|
|
|
|
|
Lohnt sich der Aufpreis fuer einen Kaby Lake i7 gegenueber einem i5? Geht um die CPU in nem Laptop (T470p) und jeweils die Quadcore-Variante. Ich habe keinen blassen Schimmer, vermute aber, dass es sich nicht lohnt.
Geraet wird von Entwicklern genutzt werden.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von tbd
Geraet wird von Entwicklern genutzt werden.
| |
da hast du die antwort. es lohnt sich.
davon abgesehen ist es ein laptop, da gilt grundsätzlich man nimmt was man kriegen kann. die ausnahme dafür ist, wenn das gerät nicht lange halten soll.
|
|
|
|
|
|
|
|
|
|
|
|
"Entwickler" ist ein weites Feld. Der i7-7600U im 470s hat schon deutliche Hitzeprobleme, der i7-7700HQ (?) wird das nicht besser machen.
|
|
|
|
|
|
|
|
|
|
|
Soll lange halten, vermutlich 4 Jahre ( ).
Wenn es die Hitzprobleme gibt heisst das, dass die schnellere CPU frueher drosselt und der Geschwindigkeitsvorteil sich dann erledigt hat, oder? Also eventuell doch der i5, trotz der angegebenen Zielgruppe.
"Entwickler" bedeutet Java
|
|
|
|
|
|
|
|
|
|
|
Hitzeprobleme will man eigentlich generell nicht haben, unabhängig von der Geschwindigkeit. Ich wüsste jetzt aber nicht, wo ein i7 gegenüber einem i5 große Vorteile haben würde. Leichte Vorteile wird er sicherlich haben, allein durch höheren Takt.
Man könnte jetzt argumentieren, daß Entwicklerzeit teuer ist und sich schnellere Hardware für Entwickler immer lohnt. Aber ich selbst verbringe die meiste Zeit mit (oft ergebnislosem) Nachdenken, nicht mit kompilieren. Grundsätzlich ist mir ein stabiler, zuverlässiger Rechner wichtiger als ein schnellerer.
¤: meine Kiste ist übrigens ein i5-2500. Wird irgendwann mal Zeit für was neues, aber bisher läuft eigentlich alles noch ziemlich fix.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von GarlandGreene am 27.04.2017 8:56]
|
|
|
|
|
|
|
|
|
Ich hab einfach geschaut was ich jetzt drin hab, der 7200U ist ~20% schneller, reicht mir.
Man kann natürlich den Lüfter manuell steuern, den Takt begrenzen, Kerne abschalten, aber die Frage war ja ob sich der Aufpreis lohnt.
|
|
|
|
|
|
|
|
|
|
|
|
Bei schnellen Wahl-CPUs lohnt es sich zu Googeln, ob das Kühlsystem vom fraglichen Laptop überhaupt, so generell, in der Lage ist das Teil zu kühlen (unabhängig davon, welche Staubsaugergeräuschkulisse entstehen mag).
|
|
|
|
|
|
|
|
|
|
|
Meine Erfahrung:
- Mehr CPU-Kerne sind wichtig, zwei Kerne sind einfach zu wenig. Generell sind mehr Kerne viel besser als mehr Takt, gerade beim Kompilieren und parallelen Arbeiten. Intel bekommt das mit dem Strombedarf nach wie vor nicht hin und bietet keine wirklich mobilen CPUs mit vier Kerne an, deswegen musst du das "p" am Laptop hinnehmen. Deine Entwickler werden dir verzeihen, denke ich mal. Mit CoffeeLake soll es dann endlich moderne 4-Kern-Prozessoren fuer schlanke Laptops geben
- i7 oder i5 ist egal, nur grobe Marketingeinteilung. Die wichtigen Features wie HT oder VT haben die i5 auch. Es gibt selten Ausnahmefaelle wie das X220, da hat man erst mit dem i7 USB-3.0 bekommen, aber das war ein extra Feature von Lenovo und nicht von Intel.
- Generell: Die Stabilitaet und Zuverlaessigkeit des Geraetes, sowie die I/O-Schnittstellen zum Menschen, also Tastatur und Bildschirm, sind viel wichtiger als ein bisschen schnellere Hardware. Lieber HiDPI als 300 MHz Pseudo-Boost-Takt.
- ThinkPadliebe == Entwicklerliebe == Linuxliebe
Ich hatte einmal ein Laptop von Acer, mit i5 oder i7 und einer sehr schnellen Radeon 58xx und ausreichendem Akku. Es war schlecht! Der Bildschirm war verspiegelt und leuchtschwach und die Tastatur war schwammig, unpraezise ohne konkave Tasten. Davon abgesehen waren aussen und innen verschiedene Materialien verbaut. ThinkPads findet unverstaendlicher weisse nicht jede(r) huebsch, aber sie sind zeitlos und gefaellig.
Gemein waere auch ein zu kleine oder unzuverlaessige SSD, nur fuer ein paar MHz mehr. Viele muessen, wie ich, auch noch ein VirtualBox oder so rumschleppen und dann ist der Speicherplatz schnell weg und Datenverlust ist grausam. Und RAM braucht man immer!
|
|
[Dieser Beitrag wurde 8 mal editiert; zum letzten Mal von hoschi am 27.04.2017 11:15]
|
|
|
|
|
|
|
|
|
Beim i5 ist leider eben kein HT mit dabei wenn ich das richtig sehe. Der hat zwar 4 physikalische Kerne - wie der i7 - allerdings keine 8 "virtuellen" Kerne, somit kein Hyper-Threading.
Also spricht fuer den i7, dass er HT hat, Takt und Cache sind nett aber nicht ausschlaggebend.
Die Werte fuer TDP sind bei i5 und i7 gleich, somit haben auch beide die gleichen potentiellen Abwaermeprobleme (nicht?), wobei ich zu dem Thema beim T470p bis jetzt keine spezifischen Probleme ergoogeln konnte.
Was mich noch stoert (und ich habe keine Ahnung, was sich Lenovo dabei gedacht hat): es ist scheinbar nicht moeglich einen i7 ohne dedizierte nVidia-Grafikkarte zu konfigurieren. Was moechte uns der Autor damit sagen? Ich schleppe ungern einen Stromverbraucher mit, den ich nicht haben will.
(Ich bin auch einer der Entwickler. Oder besser: Admin gone Entwickler, mal sehen wie es wird ).
|
|
|
|
|
|
|
|
|
|
|
der i5 in dem T470p hat anscheinend kein HT, stimmt.
Bezüglich Grafik: ich hab zuhause ein XMG-Notebook mit dedizierter Grafik, die wird eigentlich nur bei Bedarf zugeschaltet. Funktioniert zumindest unter Windows einwandfrei und transparent (= man merkt's nicht).
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von tbd
Die Werte fuer TDP sind bei i5 und i7 gleich, somit haben auch beide die gleichen potentiellen Abwaermeprobleme (nicht?)
| |
Ne
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von tbd
Beim i5 ist leider eben kein HT mit dabei wenn ich das richtig sehe. Der hat zwar 4 physikalische Kerne - wie der i7 - allerdings keine 8 "virtuellen" Kerne, somit kein Hyper-Threading. | |
Ungewoehnlich und etwas fies.
| | Zitat von tbd
Was mich noch stoert (und ich habe keine Ahnung, was sich Lenovo dabei gedacht hat): es ist scheinbar nicht moeglich einen i7 ohne dedizierte nVidia-Grafikkarte zu konfigurieren. Was moechte uns der Autor damit sagen? Ich schleppe ungern einen Stromverbraucher mit, den ich nicht haben will.
| |
Das ist mal richtig schlecht. Das kann im Zweifel nur Probleme verursachen und kostet unnoetig Geld. Garland hat recht, dass man das in der Regel im BIOS abschalten kann und dann mit der Intelgrafik sorgenlos arbeiten kann. Es ist ein unnoetiges Bauteil, somit eine unnoetige Fehlerquelle und am Ende muss jemand die 100 Gramm rumtragen.
Und jetzt eine Geschichte aus dem echten Leben:
Kollege wollte auf seinem ThinkPad T520 Linux installieren und haette fortwaehrend Probleme im Betrieb mit drei ( ) Bildschirmen. Ursache war, das irgendwer zu viel Geld gehabt hatte und die Nvidiakarte im Laptop geordert hatte. Und dann hat der Vorbesitzer ein BIOS-Passwort gesetzt und gekuendigt, abschalten nicht mehr moeglich 
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 27.04.2017 11:46]
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
| | Zitat von tbd
Die Werte fuer TDP sind bei i5 und i7 gleich, somit haben auch beide die gleichen potentiellen Abwaermeprobleme (nicht?)
| |
Ne
| |
Weil wohl beide das Silizium fuer HT haben - und wenn das aktiv ist, verbraucht das Strom, was wieder zu Abwaerme fuehrt. Einwaende?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 27.04.2017 11:47]
|
|
|
|
|
|
|
|
|
| | Zitat von tbd
wobei ich zu dem Thema beim T470p bis jetzt keine spezifischen Probleme ergoogeln konnte
| |
Gibt auch noch kein brauchbares Review.
|
|
|
|
|
|
|
|
|
|
|
|
von "im Bios abschaltbar" hab ich nicht gesprochen. Ich meinte, daß Windows die stromfressende NVidia-Grafik nur bei Bedarf zuschaltet. Erkennt man eigentlich nur daran, daß irgendwelche 3D-Klamotten ruckeln, wenn man mal versehentlich ohne angeschlossenes Netzteil startet. Kann man auch übersteuern, aber standardmäßig wird die dedizierte Grafik nur bei angeschlossenem Netzteil aktiviert (und auch dann eben nur, wenn sie benötigt wird).
|
|
|
|
|
|
|
|
|
|
|
Da wir hier im Linux Thread sind und ich mit meinem T420s mit dedizierter nVidia Grafik nur Probleme habe unter Arch, würde ich davon aber auch mal hart abraten! 
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 // 0x23 ( const int MAX_POST = 30 * 100; // 0x23 ) |
