|
|
|
|
|
|
|
|
|
|
|
|
|
|
klassischer Fall von bugreport im google result gesehen aber nicht angeklickt, danke.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Generell sollte in eine Config nur das enthalten, was man selbst geändert haben möchte, keine kopierten Einstellungen.
| |
Öhm, seh ich anders. Ich hab das lieber explizit. Debian, Ubuntu, Mint, Arch, Manjaro, alles verhält sich gleich. 5/7, would have 300 line .vimrc again.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Nun gut, in der .gvimrc steht auch noch bissl was. 
|
|
|
|
|
|
|
|
|
|
|
|
Wobei bei mir das meiste Kommentare sind wahrscheinlich. Was tut es, warum ist es da, hass über vimscript. Sowas.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
iptables-restore statt ip6tables-restore benutzt, Büro tot. Kacke.
|
|
|
|
|
|
|
|
|
|
|
Zum Glück hast du noch acht Stunden zum Reparieren, bis die ersten Kollegen kommen!
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von statixx
| | Zitat von hoschi
Generell sollte in eine Config nur das enthalten, was man selbst geändert haben möchte, keine kopierten Einstellungen.
| |
Öhm, seh ich anders. Ich hab das lieber explizit. Debian, Ubuntu, Mint, Arch, Manjaro, alles verhält sich gleich. 5/7, would have 300 line .vimrc again.
| |
Kannst du erklären was du alles änderst? In der /etc/vimrc?
|
|
|
|
|
|
|
|
|
|
|
Um ehrlich zu sein - da steht inzwischen mit Sicherheit auch überflüssiges drin, ich hab das Ding seit meiner Gentoo-Zeit um 2006 rum und hab es damals tatsächlich komplett kopiert, seitdem ists halt etwas gewachsen. Mir gefiel das Default-Verhalten unter Gentoo damals besser als unter den anderen Distris die ich vorher genutzt hatte, daher schlepp ich's seitdem mit rum.
Was hab ich denn alles drin... z.B. Support für Vundle, eine größere history, Mausunterstützung an, ein paar Bindings für Navigation zwischen Tabs, Session-übergreifendes undo/redo, custom statusline und ein paar filetype-spezifische Indent-settings.
Ansonsten halt noch so Standard-Kram wie autoindent, syntax-highlighting, hlsearch, smartcase, showmatch, colorscheme, number, listchars.
Ich würd sie ja posten, aber ich hab Angst vor "LOL DEINE VIMRC IST SCHEISSE".
/e: Achso, alles in der ~/.vimrc, in /etc/vimrc bleibt alles so wie's ist.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von statixx am 09.05.2018 8:38]
|
|
|
|
|
|
|
|
|
Danke. Ich dachte zuerst du willst kleine Konfigurationsunterschiede und Flags zwischen den Distributionen ausgleichen, weil du die alle aufgelistet hast. Du möchtest deinen VIM überall!
| | Zitat von statixx
Um ehrlich zu sein - da steht inzwischen mit Sicherheit auch überflüssiges drin, ich hab das Ding seit meiner Gentoo-Zeit um 2006 rum und hab es damals tatsächlich komplett kopiert, seitdem ists halt etwas gewachsen. Mir gefiel das Default-Verhalten unter Gentoo damals besser als unter den anderen Distris die ich vorher genutzt hatte, daher schlepp ich's seitdem mit rum.
| |
Gentoo hat vieles schön* gemacht 
Ich denke das tatsächlich generell anders. Ich vertraue lieber dem Default der Software oder Distribution und ändere nur Einstellungen die ich kenne. So kann ich undefiniertes Verhalten ausschließen und habe nichts überflüssiges in der Konfiguration.
Am liebsten würde ich die VIM-Konfiguration der Ubuntuserver hier leicht ändern, aber sowas ist für die Kollegen nicht so gut. Es sollte sowas wie eine Option für SSH geben, mit der man die VIM-Konfiguration für die Session überladen kann. Das klingt verrückt?
* Syntax-Highlighting per Default mit less
|
|
|
|
|
|
|
|
|
|
|
|
Ich ändere auch nur so wenig wie möglich und übernehme keine expliziten Einstellungen, bei einem Editor ist das vielleicht nochmal was anderes als bei anderer Software, aber häufig gibt es ja einen Grund dass die Standards sich ändern. Macht Migrationen auch wesentlich einfacher wenn man nur zwei annähernd identische Dateien diffen muss.
|
|
|
|
|
|
|
|
|
|
|
So halte ich das auch bei Änderungen am System (z.B. kein Suspend durch LID-CLOSE, kommentiert und genau unter Originalzeile) und anderen Konfigurationsdateien. Generell kommentiere ich geänderten Einstellungen unter /etc um sie nachvollziehen zu können, unter ~/ nur wenn es nicht selbsterklärend ist. Die Strategie nur dediziert, möglichst kleine Änderungen vorzunehmen zieht sich bei mir durch, von Systemd, VIM, MySQL bis zu Counter-Strike (autoexec.cfg überschreibt config.cfg). Der Ansatz eine Defaultkonfiguration aus /lib in /etc zu überschreiben ist gut, da hat Systemd etwas richtig gemacht.
Ich bin immer hin- und hergerissen bei Dotfile-Repositories, ich finde es schlau. Andererseits, wie viel kann und muss man ändern um so ein Repository zu benötigen? Macht das jemand von euch?
|
|
[Dieser Beitrag wurde 6 mal editiert; zum letzten Mal von hoschi am 09.05.2018 11:46]
|
|
|
|
|
|
|
|
|
|
Systemweiten Krempel änder ich auch nur minimal, mein oben beschriebenes Vorgehen kommt bei den dotfiles in ~ zum Einsatz. Dort fahr ich seit Jahren für alles gut ausser für awesome, alles andere hat bisher die Syntax nich gebrochen. Alles in nem git-repo + ein Skript das Symlinks zu den Originalfiles setzt. Auf ner neuen Maschine einmal git clone, einmal ./create_symlinks.sh und schon wuppt das Ding. Plus die Möglichkeit commits zu reverten, z.B. wenn das Debian testing zuhause schon awesome 4 hat, das Mint auf Arbeit aber noch 3. Sehr komfortabel.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Ich bin immer hin- und hergerissen bei Dotfile-Repositories, ich finde es schlau. Andererseits, wie viel kann und muss man ändern um so ein Repository zu benötigen? Macht das jemand von euch?
| |
Jup  Verwaltet mit dem großartigen dotmgr
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
So halte ich das auch bei Änderungen am System (z.B. kein Suspend durch LID-CLOSE, kommentiert und genau unter Originalzeile) und anderen Konfigurationsdateien. Generell kommentiere ich geänderten Einstellungen unter /etc um sie nachvollziehen zu können, unter ~/ nur wenn es nicht selbsterklärend ist. Die Strategie nur dediziert, möglichst kleine Änderungen vorzunehmen zieht sich bei mir durch, von Systemd, VIM, MySQL bis zu Counter-Strike (autoexec.cfg überschreibt config.cfg). Der Ansatz eine Defaultkonfiguration aus /lib in /etc zu überschreiben ist gut, da hat Systemd etwas richtig gemacht.
Ich bin immer hin- und hergerissen bei Dotfile-Repositories, ich finde es schlau. Andererseits, wie viel kann und muss man ändern um so ein Repository zu benötigen? Macht das jemand von euch?
| |
Ein Repository lohnt sich so grob ab dem zweiten Commit. Nur weil man eines hat heißt das nicht, dass man es ständig ändern muss und plötzlich werden Änderungen in /etc oder in den "eigenen" Dotfiles sehr gut nachvollziehbar, portabel und vor allem diffbar. Warum sollte es irgendeinen Unterschied geben zwischen Code und Konfiguration, sodass es offensichtlich dumm ist Code ohne Repos zu verwalten, aber Konfiguration nicht?
Davon unabhängig hat mein dotfiles-Repo seit 2013 etwa 800 Commits (klingt schlimmer als es ist  ) und ich verwende es auf etwa 10 Hosts.
|
|
|
|
|
|
|
|
|
|
|
|
Backup ist auch leichter, da git-repos zentral gelagert werden (bei mir zumindest).
|
|
|
|
|
|
|
|
|
|
|
https://nvd.nist.gov/vuln/detail/CVE-2018-8897
| | | A statement in the System Programming Guide of the Intel 64 and IA-32 Architectures Software Developer's Manual (SDM) was mishandled in the development of some or all operating-system kernels, resulting in unexpected behavior for #DB exceptions that are deferred by MOV SS or POP SS, as demonstrated by (for example) privilege escalation in Windows, macOS, some Xen configurations, or FreeBSD, or a Linux kernel crash. | |
Wie gottvoll das ist.
e: Originär ist das wohl ein 8086-Feature.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 10.05.2018 23:36]
|
|
|
|
|
|
|
|
|
|
sportlich, das betrifft dann wohl code auf alle intel prozessoren seit ... (ewig)?
|
|
|
|
|
|
|
|
|
|
|
Danke für dein Einblick.
| | Zitat von MartiniMoe
| | Zitat von hoschi
Ich bin immer hin- und hergerissen bei Dotfile-Repositories, ich finde es schlau. Andererseits, wie viel kann und muss man ändern um so ein Repository zu benötigen? Macht das jemand von euch?
| |
Jup Verwaltet mit dem großartigen dotmgr
| |
Dotmgr - ich hätte wissen müssen, dass es sowas gibt
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
https://nvd.nist.gov/vuln/detail/CVE-2018-8897
| | | A statement in the System Programming Guide of the Intel 64 and IA-32 Architectures Software Developer's Manual (SDM) was mishandled in the development of some or all operating-system kernels, resulting in unexpected behavior for #DB exceptions that are deferred by MOV SS or POP SS, as demonstrated by (for example) privilege escalation in Windows, macOS, some Xen configurations, or FreeBSD, or a Linux kernel crash. | |
Wie gottvoll das ist.
e: Originär ist das wohl ein 8086-Feature.
| |
Ich kenne mich mit Assembler bzw. IA32 nicht aus. Eine MOV-Anweisung verschiebt etwas und SS ist wohl das Stack-Register? Für mich hört sich das nicht nach logischem und erwartbarem Verhalten an, also ist ein gute Dokumentation (überlebens) wichtig.
Haben alle vom selben Quellcode abgeschrieben oder hat Intel da eine schlechte (unerwartet) Lösung nicht gut dokumentiert? Die erste Website zu MOV erwähnt das dann auch im Fließtext, ohne extra Hervorhebung. Bei einfacheren Websiten die einfach mal die verfügbaren Befehle auflisten, fehlt der Hinweis. Was sagt ein Assemblerprogrammierer dazu, ist das ein merkwürdiger Seiteneffekt oder ein Standardfeature bei Zugriff auf SS?
|
|
[Dieser Beitrag wurde 6 mal editiert; zum letzten Mal von hoschi am 11.05.2018 11:07]
|
|
|
|
|
|
|
|
|
Das kommt noch aus Zeiten mit segmentierten Speicher. Wenn du den Stack wechseln willst, musst du also SS (Stack Segment) und SP (Stack Pointer, innerhalb SS) atomar ändern. Wenn du SS änderst und dann ein Interrupt kommst, hast du ein Problem (weil z.B. Interrupt-Handler auch den Stack benutzen).
Dafür gibt es zwei Lösungen: a) Man schaut, ob SS geschrieben wird, und dann wird für einen Takt alles was den nächsten Befehl unterbrechen könnte ausgeschaltet. Das ist keine sonderlich untypische Lösung und gibt es in allen möglichen Prozessoren. b) Man macht einen "großen" Befehl, der SS und SP gleichzeitig setzen kann.
Was hier jetzt nicht so ganz klar ist, was passiert, wenn man nicht etwa MOV SS; MOV SP tut, sondern sowas wie MOV SS; SYSENTER, wenn gleichzeitig ein Interrupt (etwa Breakpoint) bei MOV SS passiert.
|
|
|
|
|
|
|
|
|
|
|
Danke
Atomarer Zugriff auf zwei Register ist wohl der entscheidende Zusammenhang und erschließt mir die Logik dahinter für den Inhibit.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 11.05.2018 11:48]
|
|
|
|
|
|
|
|
|
| | Zitat von [KdM]MrDeath
sportlich, das betrifft dann wohl code auf alle intel prozessoren seit ... (ewig)?
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@SBI das hier löst mein Mausproblem zuverlässig.
| |
| Code: |
ExecStartPre=/bin/sh -c 'echo -n "none" > /sys/bus/serio/devices/serio1/drvctl'
ExecStart=/bin/sh -c 'echo -n "reconnect" > /sys/bus/serio/devices/serio1/drvctl' |
|
|
|
|
|
|
|
|
|
|
|
|
Nice. Gleich mal eingebaut, mein Schnucki :-*
Ist aber natürlich auch völlig einleuchtend.
|
|
|
|
|
|
|
|
|
|
|
Völlig offensichtlich, vorallem dass man none vorher braucht damit das nicht auch hängt.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |
