|
|
|
|
|
|
|
| | Zitat von hoschi
Nutzer in AUR. Wie überall auf dem Planeten 
| |
Gibt es eigentlich ein aktuelles Programm das mir Abhängigkeiten auflöst und AUR Pakete baut/auf Updates prüft?
Das ist elends nervig von Hand und alle Projekte die es da gibt scheinen regelmäßig zu sterben. pacaur ist auch schon wieder verlassen.
|
|
|
|
|
|
|
|
|
|
|
|
Ugh. In der Wiki-Tabelle sieht bauerbill gut aus.
|
|
|
|
|
|
|
|
|
|
|
|
Nutze gerade aurman. Tut
|
|
|
|
|
|
|
|
|
|
|
cower weil. Beides Maintainer/Entwickler von Archlinux. Es gibt vermutlich so viele AUR-Helper, wie Linuxdistributionen.
Wobei ich versuche so wenig wie möglich Pakete aus AUR zu beziehen. Daheim geht besser, hier in der Arbeit sind es 24 Pakete von Squirrel, über cppreference-devhelp, mingw, nsis bis hin zu osslsigncode.
|
|
|
|
|
|
|
|
|
|
Popcorn & Cola LKML
|
Als ich davon gehört habe, habe ich unweigerlich auf Matthew Garret getippt. Garret ist dafür bekannt Secure Boot voran zu treiben. Garret hört nicht auf Torvalds und redet weiter auf ihn ein, und erfüllt sein gepflegtes SJW-Klischee. Es ist eben nicht in Ordung eine Agenda durchzusetzen, indem man die andere Seite zermürbt und Tode diskutiert. Was versteht der an der Wortwahl von Torvalds nicht. Nein heißt doch Nein?
Ich habe das hier für das vorläufige Ende gehalten, es geht jedoch weiter:
| | > There are four cases:
No.
Matthew., stop with the agenda already. | |
Ts'o und Greg machen sich dann noch über den möglichen Missbruach kexec lustig. Hier ein bisschen Geschichte dazu. Natürlich kann man heute Secure Boot nicht überall nutzerfreundlich abschalten. Das war nie Microsofts Ziel.
|
|
[Dieser Beitrag wurde 10 mal editiert; zum letzten Mal von hoschi am 04.04.2018 15:49]
|
|
|
|
|
|
|
|
|
Ich kann yay empfehlen. Bin nach dem Tod von pacaur dorthin gewechselt und bin sehr positiv davon überrascht, wie schnell die coolen Features von pacauer implementiert werden. Das Projekt ist gerade relativ flott unterwegs und funktioniert sehr gut.
Im Gegensatz zu manchen anderen AUR-Helpern (*hust* bauerbill) ist das Installieren auch erfreulich einfach.
|
|
|
|
|
|
|
|
|
|
|
Mein Laptop-Akku (Dell Inspiron, 1,5 Jahre alt) verhält sich komisch. Je näher die Ladung in Richtung Voll kommt, desto länger wird die berechnete, und offenbar auch die effektive, Ladezeit. Sprich, 0-90% dauert ca. zwei Stunden, die restlichen 10% ... nun, es sind jetzt etwa 20 Stunden ohne dass die Lade-LED ausgegangen wäre. 
Dabei ist folgendes auch seltsam: Bis gestern hatte ich das acpi -Package nicht drauf. Im xfce-Powermanagement wurde für die Akku-"Qualität" immernoch "100% (42 Wh)" angezeigt. Dann habe ich acpi installiert. Dort, und ab dann auch im xfce-Manager beträgt die Akkuleistung nur noch "83% (34,5 Wh)". Das mag ja nach 1,5 Jahren durchaus korrekt sein.
Aber was mach ich jetzt in Bezug auf diese exponentielle Ladezeit? Hardwareschaden? Ich habe die Tage jetzt keine Kernel/acpi/oÄ-Update gemacht.
|
|
|
|
|
|
|
|
|
|
|
- Intelligente Ladeelektronik, welche den Akku am Ende langsamer und schonender lädt?!
- Ein paar Zellen sind defekt?
Der zwei Jahre alte Akku im T420 macht mir auch sorgen, wir öfter benützt als die im X220. Der im T420 war am Samstag nur auf 10%, obwohl der am Freitag den ganzen Tag eingedockt war. Das X220 wird aber eher mal voll auf- und entladen.
Ich habe echt Angst vor eingekeppten Akkus.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 04.04.2018 22:56]
|
|
|
|
|
|
|
|
|
Das kann auch einfach nen Bug in dem ACPI-Krempel sein. So nach dem Motto:
BMS: "Ich lade jetzt noch bis 34.5 Wh mit 0.1 W Ladeleistung"
Linux: "Ah ok, du lädst also noch bis 42 Wh mit 0.1 W Ladeleistung und das dauert DREITAUSEND Stunden"
|
|
|
|
|
|
|
|
|
|
|
Mit dem ThinkPad-Werkzeugen konnte man (früher) sondetliche Sachen erzwingen um der Physik im Akku zu helfen.
Der DELL ist beim Laden an?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 04.04.2018 23:01]
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Das kann auch einfach nen Bug in dem ACPI-Krempel sein. So nach dem Motto:
| |
Ja, aber wieso tritt es plötzlich auf? Ich hab die letzte Woche wie gesagt keine ACPI/Kernel-Updates gemacht. Das Verhalten ist seit gestern.
Außerdem müsste ich das verifizieren können, wenn ich lade ohne dass ein Kernel/ACPI läuft aka. das Gerät aus ist, oder?
| | Zitat von hoschi
Der DELL ist beim Laden an?
| |
Als ich es gestern gemerkt habe, hatte er im Standby geladen. Also in Betrieb und Standby kann ich das Verhalten reproduzieren. Siehe oben - mögliche Gemeinsamkeit, dass ACPI da noch rummacht (also im Standby)?
Sollte wohl mal hart ausschalten und voll laden.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Rufus am 04.04.2018 23:49]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich sehe da zwei strukturelle Defizite: Erstens: nicht-trivialer Signal-Handler (mehr als ein Flag setzen geht halt oft schief). Zweitens: Signale sind async und gemeinsame Daten zwischen einem Handler und dem Rest der Welt müssen im Grunde wie zwei unterschiedliche Threads betrachtet werden [mit dem Unterschied, dass der Handler den Stack des Threads benutzt, der das Signal bekommt, und dass natürlich der Signal-empfangende Thread und der Handler prinzipbedingt nicht gleichzeitig ablaufen].
e: Es sei hier namegedroppt, dass wenn man irgendwas mit ner select/epoll/kqueue/whatever Hauptschleifer hat - also die meisten Server - dann braucht man wahrscheinlich keine Signal-Handler mehr, weil man sich seit ner Weile auf den meisten OSen Signale per FD anliefern lassen kann.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 05.04.2018 14:52]
|
|
|
|
|
|
|
|
|
ok, der Hersteller unseres 80k¤-SANs müsste auch mal nen Euro oder zwei in seine Qualitätskontrolle stecken. Wenn die BMCs der beiden Controller in einem gerouteten Netzwerk stecken und da irgendeinen Management-Traffic mitbekommen, können sie sich mal so ganz unvorbereitet verabschieden.
Anders ausgedrückt: der Controller, der die Wartbarkeit des Systems über Netzwerk erlaubt, stürzt ab, wenn er Netzwerktraffic bekommt. You had one job...
|
|
|
|
|
|
|
|
|
|
|
Haha
Der Hinweis im Patch für Holey-Beep auf die Lücke in Patch 
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 06.04.2018 22:45]
|
|
|
|
|
|
|
|
|
Microsoft liebt Linux! Sie imitieren das Verhalten von Debian fast perfekt
- alter Fork
- selber rumgefrickelt ohne Upstream
- RAR
- Schlangenöl
- signed als unsigned
Mir fehlt hier nur noch die ungarische Notation.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 06.04.2018 23:39]
|
|
|
|
|
|
|
|
|
|
Microsoft's AV gilt ja gemeinhin noch als der am ordentlichsten gebaute AV, aber auch hier muss man mal wieder fragen: wieso läuft ein verschissener Unpacker unter SYSTEM?
|
|
|
|
|
|
|
|
|
|
Teufel mit Belzebub austreiben
|
Das blöde für mich ist, ich habe Windowsanwendern die kein GNU/Linux wollen, lange den Windows-Vircenscanner empfohlen. Geringe Systemlast, keine Show und Geld, außerdem haben die Programmierer hoffentlich wirklich Ahnung. Mein Problem mit Schlangenöl ist ja, neben der fehlgeleiteten Technik an sich, dass die Peogrammierer es bei Microsoft besser wissen (können). Moment an spricht noch dafür, das kein große Show im Systemtray stattfindet? Oder, dass diese Krankheit bei Win10 sowieso dabei ist und ein Problem reicht ja.
Zum Glück gibt es die Seuche nur für Windows in dieser Form.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
jo und bei dem text ist mir aufgefallen dass golem ihr design geändert haben. von der schreibweise her konnte das nur hanno sein, aber ich habs beim besten willen nicht gefunden.
hab nach drei minuten suchen oder so den kleinen link entdeckt... das find ich schon nen kleinen rückschritt zum alten design :/
|
|
|
|
|
|
|
|
|
|
|
"Quelle: hab" ... schwach 
Ask HN: Are there any reasonable alternatives to MacBook Pro for developer?
Das ist eine der hackernewsigsten Hackernewsnews, die ich je gesehen habe.
|
|
|
|
|
|
|
|
|
|
|
hier der Link, nachdem uns Ratte angefüttert hat.
TLDR:
Also jemand mit einem Mac, merkt dass die neuen Appledinger nicht besser geworden sind. Antwort ist ThinkPad. HiDPI-Diskussion geht los, irgendwer mit einem alten Debian jammert und erklärt es liegt an Linux und GNOME. Antwort ist, benütze ein aktuelles GNOME (kann ich bestätigen, läuft einwandfrei und altes Gtk2 halt eben so lala)), Macs benützt man auch nicht mit drei Jahre alten MacOS. Und bei alten Anwendung, Fontgröße hoch.
PS: Habe bemerkt das Hinting bei GNOME per Default aus ist. Mit ist deutlich besser auf normalen Displays mit 96 PPI. Bei den 125 PPI vom X220 merkt man weniger. Beim 4K Monitor fällt Hinting mir nicht mehr auf. Ist Infinality(?) bei Ubuntu noch irgendwie besser, das meiste ist doch inzwischen zurückportiert?
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von hoschi am 08.04.2018 21:44]
|
|
|
|
|
|
|
|
|
| | *Mögliche Probleme nach dem Update:*
Problembeschreibung: Der Login mit dem bisherigen Passwort funktioniert nach dem Update nicht mehr.
Lösung: Dell hat in einer der letzten Versionen eingeführt, dass iDRAC-Passwörter nur aus maximal 20 Zeichen bestehen dürfen. Passwörter, die länger sind, werden nach dem Update nach 20 Stellen abgeschnitten. Geben Sie daher nur die ersten 20 Zeichen Ihres Passwortes beim Login ein.
| |
Ok.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von TheRealHawk
| | *Mögliche Probleme nach dem Update:*
Problembeschreibung: Der Login mit dem bisherigen Passwort funktioniert nach dem Update nicht mehr.
Lösung: Dell hat in einer der letzten Versionen eingeführt, dass iDRAC-Passwörter nur aus maximal 20 Zeichen bestehen dürfen. Passwörter, die länger sind, werden nach dem Update nach 20 Stellen abgeschnitten. Geben Sie daher nur die ersten 20 Zeichen Ihres Passwortes beim Login ein.
| |
Ok.
| |
brrr, will garnicht wissen wie die davor gespeichert waren wenn das wirklich funktioniert...
|
|
|
|
|
|
|
|
|
|
|
Weiß jemand, wie pacman -Fo funktioniert: Schaut das in einer globalen Datanbank nach, welches Paket welche Dateien anlegt, oder hält es ein lokales Log, welches installierte Paket welche Datei angelegt hat?
Hintergrund: Ich hab ein paar py Skripte in /usr/bin, welche nach pacman -Fo zu einem Paket gehören - das Paket ist aber laut pacman -Q gar nicht installiert, taucht aber auch nicht z.B. in pip list auf.
|
|
|
|
|
|
|
|
|
|
|
/var/lib/pacman/local -> Deine installierten Pakete, das ist ein Verzeichnisbaum
/var/lib/pacman/sync -> Heruntergeladene Paketdatenbank, das ist ein Archiv.
Ich bevorzuge pacman -Qo, welche /var/lib/pacman/local nutzt:
| |
| Code: |
$ which ls
/usr/bin/ls
$ pacman -Qo /usr/bin/ls
/usr/bin/ls is owned by coreutils 8.29-1
|
|
Ich denke pacman -F geht auf eine sogenannte files database und ist neu ab Pacman "5.0". Dich interessiert der Inhalt von /var/lib/pacman/local, hier sind lokal installierte Pakete und Dateien gespeichert, somit ist die Option pacman -Qo für dich die richtige. Die "files database" ist für den Betrieb nicht erforderlich und ich habe auch keine, die Dokumentation und der Hintergrund kommt mir unglücklich vor. Damit könntest du wohl abfragen welches nicht lokal installierte Paket eine bestimmte Datei enthält. Würde mir das besser bei [-S] vorstellen können.
Vermutung:
Entweder per PIP oder manuell wurden diese Skripte installiert, zufällig enthalten die Repositories bestimmte Pakete mit passenden Dateien. Und deswegen willst du da auch aufräumen?
|
|
[Dieser Beitrag wurde 11 mal editiert; zum letzten Mal von hoschi am 09.04.2018 17:23]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |
