From 89fd6124d5dbfab70b0e7e7d9123dd4412343461 Mon Sep 17 00:00:00 2001 From: Duncan Wilkie Date: Tue, 13 Jun 2023 09:13:33 -0500 Subject: Changed to generalized dotfiles repo; got config.org somewhat stable --- .xinitrc | 30 + .zprofile | 4 + .zshrc | 47 ++ 2023-06-11-214759_1919x1080_scrot.png | Bin 523062 -> 0 bytes 2023-06-11-214856_1021x767_scrot.png | Bin 231567 -> 0 bytes Geometric_Langlands_S_Duality(1)1024_1.png | Bin 1078511 -> 0 bytes README.org | 19 + config.org | 403 +++++++------ init.el | 885 ----------------------------- pam_usb.conf | 97 ++++ system-auth | 2 +- 11 files changed, 394 insertions(+), 1093 deletions(-) create mode 100644 .xinitrc create mode 100644 .zprofile create mode 100644 .zshrc delete mode 100644 2023-06-11-214759_1919x1080_scrot.png delete mode 100644 2023-06-11-214856_1021x767_scrot.png delete mode 100644 Geometric_Langlands_S_Duality(1)1024_1.png create mode 100644 README.org delete mode 100644 init.el create mode 100644 pam_usb.conf diff --git a/.xinitrc b/.xinitrc new file mode 100644 index 0000000..569841b --- /dev/null +++ b/.xinitrc @@ -0,0 +1,30 @@ +setxkbmap us -option ctrl:swapcaps + +#/home/dnw/.fehbg & +#bash /home/dnw/status.sh & +pulseaudio --start + +# EXWM start +# Disable access control for the current user. +xhost +SI:localuser:$USER + +# Make Java applications aware this is a non-reparenting window manager. +export _JAVA_AWT_WM_NONREPARENTING=1 + +# Set default cursor. +xsetroot -cursor_name left_ptr + +# Set keyboard repeat rate. +xset r rate 200 60 + +# Uncomment the following block to use the exwm-xim module. +export XMODIFIERS=@im=exwm-xim +export GTK_IM_MODULE=xim +export QT_IM_MODULE=xim +export CLUTTER_IM_MODULE=xim + +# required for GTK3 scrolling +export GDK_CORE_DEVICE_EVENTS=1 +# Finally start Emacs + +exec dbus-run-session -- emacsclient -c -a "" diff --git a/.zprofile b/.zprofile new file mode 100644 index 0000000..47eba2e --- /dev/null +++ b/.zprofile @@ -0,0 +1,4 @@ +# Honor system-wide environment variables +source /etc/profile + +[[ -t 0 && $(tty) == /dev/tty2 && $- =~ "l" ]] && source ~/.zshrc && exec startx diff --git a/.zshrc b/.zshrc new file mode 100644 index 0000000..efccaff --- /dev/null +++ b/.zshrc @@ -0,0 +1,47 @@ +[[ $TERM == "dumb" ]] && unsetopt zle && PS1='$ ' && return # prevent TRAMP issues + +autoload -U compinit bashcompinit +compinit +bashcompinit +alias ls='ls --color=auto' +alias ll='ls -al' +alias ..='cd ..' +alias ...='cd ../../' +alias .4='cd ../../..' +alias grep='grep --color=auto' +alias mkdir='mkdir -pv' +export EDITOR='emacsclient -a "" ' +export VISUAL='emacsclient -a ""' +export PAGER=/bin/less + +function preexec() { + timer=$(date +%s%3N) +} + +function precmd() { + if [ $timer ]; then + local now=$(date +%s%3N) + local d_ms=$(($now-$timer)) + local d_s=$((d_ms / 1000)) + local ms=$((d_ms % 1000)) + local s=$((d_s % 60)) + local m=$(((d_s / 60) % 60)) + local h=$((d_s / 3600)) + if ((h > 0)); then elapsed=${h}h${m}m + elif ((m > 0)); then elapsed=${m}m${s}s + elif ((s >= 10)); then elapsed=${s}.$((ms / 100))s + elif ((s > 0)); then elapsed=${s}.$((ms / 10))s + else elapsed='' #elapsed=${ms}ms + fi + + export RPROMPT="%F{240}${elapsed} %f" + unset timer + fi +} + +PROMPT='%F{blue}%2~%f%(?..%F{88} %?%f) %F{magenta}%Bᛋ%b%f ' + +# export PHITSPATH=/home/dnw/phits326A/phits +# export PATH=/home/dnw/phits326A/phits/bin:${PATH} +# export PATH=/home/dnw/phits326A/phits/dchain-sp/bin:${PATH} +export PATH=/home/dnw/Code/bin:${PATH} diff --git a/2023-06-11-214759_1919x1080_scrot.png b/2023-06-11-214759_1919x1080_scrot.png deleted file mode 100644 index 5c61b95..0000000 Binary files a/2023-06-11-214759_1919x1080_scrot.png and /dev/null differ diff --git a/2023-06-11-214856_1021x767_scrot.png b/2023-06-11-214856_1021x767_scrot.png deleted file mode 100644 index 14ee757..0000000 Binary files a/2023-06-11-214856_1021x767_scrot.png and /dev/null differ diff --git a/Geometric_Langlands_S_Duality(1)1024_1.png b/Geometric_Langlands_S_Duality(1)1024_1.png deleted file mode 100644 index 5938239..0000000 Binary files a/Geometric_Langlands_S_Duality(1)1024_1.png and /dev/null differ diff --git a/README.org b/README.org new file mode 100644 index 0000000..5f7ced1 --- /dev/null +++ b/README.org @@ -0,0 +1,19 @@ +* Some Emacs-Focused Dotfiles + +These are most of my dotfiles for Parabola/Arch on my Librebooted T60, at the current moment. Some highlights: + +- 2.3kline, literate, external-link-documented org-mode config for Emacs, with as much philosophy as I could stomach. +- Automatic =startx= upon login from tty. +- =dwm=-like, =xrandr=-friendly EXWM config. +- Libreboot as combined firmware/bootloader, with a bootloader password, full-disk encryption, and a keyfile---secure against physical access, but only one password (the HDD's LUKS key) necessary to boot normally. +- =pam_usb= and =xsecurelock= (bug discovered) for seamless, multi-factor authentication +- Airgapped GPG master key, encrypting a =~/.password-store= integrated with Emacs via =password-store.el= and the built-in =auth-sources= library. +- Pretty-but-minimal =zsh= config. + + +Some anti-highlights: + +- Minimal email/bbdb configuration +- Minimal org-mode/agenda/calendar/diary configuration +- Some untested config: a few modes, eglot. +- Missing config: ledger/finance, non-Arch automatic system package installation. diff --git a/config.org b/config.org index 153474f..b82fb05 100644 --- a/config.org +++ b/config.org @@ -1,33 +1,17 @@ #+Title DNW's GNU Emacs Configuration #+PROPERTY: header-args :tangle ./init.el - Top-level TODOs: - - Describe how I use things, and what the alternatives are and why I dislike them, more than what things do. They can read the code. - - Read through the Emacs source tree/info pages for all the features I'm missing - - Make the dashboard load on startup and shrink the image. - - Org-agenda and calendar/diary - - Better org mode in general - - Read info page for Dired. - - Clean up prose on "Why Emacs" - - DocView. - - calc - - BBDB - - Hydra looks ridiculously powerful - - Mail - - Eshell - - Learn how to use compiling and debugging - - Make notifications work - - Generalize system package installations to non-Arch package managers - - Allout/outline-mode - - Faceup - - Image-dired - - Info-xref - - elide-head - - expand.el - - filesets - - find-cmd - - follow-mode - - forms +- Org-agenda and calendar/diary +- Better org mode in general --- org-insert-link-global +- Clean up prose on "Why Emacs" +- BBDB +- Mail +- Debug/PR Eshell visual commands over TRAMP +- Learn how to use compiling and debugging +- Generalize system package installations to non-Arch package managers +- Test eglot, consult-eglot, etc. +- More extensive display-buffer-alist integration with edwina. +- Fix bank stuff and get a ledger setup working. * Why Emacs? @@ -51,28 +35,30 @@ I simply cannot relate. Let this be my act of defiance. Let this by my refusal to fit in. Let this by my writ of misanthropy -To a wreckless world of men -Who have perfected -Nothing. +To a thankless world of men +Who have perfected nothing. +Save the art of accusation. ... --- /Scornful of The Motives And Virtue of Others/, Shai Hulud, 2003 #+end_verse -Emacs and vi have long histories, each back to 1976. As editors based on them in some way have seen extensive use through all of the evolution of text and its structure (not even to mention the evolution of computers!) in the intervening 47 years, they over all newer editors can evidence the claim that their systems are capable. But what is the material grounds for this capability? I hope to convince you that they are actually in this respect /dual/---two sides of the same coin. And that, of that coin, Emacs is the side far prettier. +Emacs and vi have long histories, each back to 1976. As editors based on them in some way have seen extensive use through all of the evolution of text and its structure (not to even mention the evolution of computers!) in the intervening 47 years, they over all newer editors can evidence the claim that their systems are capable. But what are the material grounds for this capability? In both cases, the strategy is extensibility, but the tactics could not be further apart. + +The vi perspective (in line with the UNIX perspective) starts from the assertion that everything on a computer can be fundamentally identified with text. Text in the filesystem is the substance of programs and that on which programs operate; it is what they produce and consume, and that by composing individual programs that perform simple text manipulations one may arive at powerful systems from simple parts. Programs are configured through filesystem text, either with a declarative config file or by modifying and recompilng their source. Programs are accessed through (not necessarily filesystem) text, by typing their name into a shell (which can only take text input, and can only output other text and side-effects). Even hardware devices are accessed through filesystem text, by reading and writing under the =/proc= and =/dev= trees. The text editor's task is merely to present the contents of the static fraction of this text for human consumption and modification, using in no small part the extant systems for text manipulation to this end. The user's enhancements to the system then contribute jointly to the operation of the system and his prowess in the editor---vi ever-growing in functionality /precisely/ on account of its minimality and, therefore, independence of the text-manipulation tools with which it shares a system. -The vi perspective (in line with the UNIX perspective) is that text in the filesystem is the substance of programs and that on which programs operate; it is what they produce and consume, and that by composing individual programs that perform simple text manipulations one may arive at powerful systems from simple parts. Programs are configured through filesystem text, either with a declarative config file or by modifying and recompilng their source. Programs are accessed through filesystem text, by typing their name into a shell (which can only take text input, and can only output other text and side-effects). Even hardware devices are accessed through filesystem text, by reading and writing under the =/proc= and =/dev= trees. This is a worthy perspective, and certainly an elegant one. There's no question shell-fu is an ancient, effective art. This paradigm's near half-century survival seems to be because the editor itself does relatively little: it's the responsibility of the tools around the editor to extend the functionality of the editor itself. +By contrast, it seems the Emacs perspective is that text is merely the substance of which programs and the data they operate on can be /composed/, but is not what they /are/. That text is merely a description of procedures to be performed. Therefore, we need not invoke those procedures through particular text incantations in a shell (though we may), nor must all procedures interface through the intermediary of a text terminal or terminal emulator (though, again, they may). The text editor exists more generally to describe and control computer behavior, to intercess between the user and the system---which, yes, often takes the form of reading, writing, and executing text, but which also may be keystrokes bound to functionality, pictures and animations presented to the user, or interactive graphical displays. vi people have recognized this to an extent, mercilessly abusing terminal control codes to get colors and interactive animations in their shells, polluting their textual paradise with programs graphical in all but the most distorted sense (ever tried to /write/ a TUI from scratch?). Emacs by contrast has no such philosophical restrictions, so it may be principled about drawing, using code and protocols actually /designed/ for the purpose from the ground-up. -By contrast, I think the Emacs perspective is that text is merely the substance of which programs and the data they operate on can be /composed/, but is not what they /are/. Therefore, we need not control our computers through particular text incantations in a shell (though we may), nor must all programs interface through the intermediary of a text terminal or terminal emulator (though, again, they may). The text editor exists more generally to describe and control computer behavior, which, yes, often takes the form of reading, writing, and executing text, but which also can take the form of simple keystrokes bound to functionality, pictures and animations presented to the user, or interactive graphical displays. vi people have recognized this to an extent, mercilessly abusing terminal control codes to get colors and interactive animations in the tty, polluting their textual paradise with programs graphical in all but the most distorted sense. Emacs, by contrast, has no such philosophical restrictions, so it may be principled about drawing, via code and protocols actually /designed/ for the purpose, from the ground up. Emacs, rather than a text editor, should be regarded as a replacement of the /shell/, the vi man's door to his system. +Emacs is configured in Lisp. The language family represents a fixed point in the relationship between programs' identity and programs' composition. Homoiconicity, there being no structural distinction between a Lisp's representation of the data it operates on and the code doing the operation, enables ordinary Lisp code to reason about other Lisp code with the same primitives used for reasoning about anything else---no weird templating, interpolation, parsing, or quoting. Just =macroexpand=. It's a dead-simple language, with about 5 pieces of fundamental syntax (lists, procedure calls, quotes, quasiquotes, and namespace distinguishment). Other dialects can be implemented with about 10 primitives (see the [[https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/6515/sicp.zip/full-text/book/book.html][wizard book]]). It's extremely expressive---most modern CAS (for a fact: Maple, Wolfram/Mathematica, and SageMATH) drew on theoretical advances made by the MACSYMA system, written at MIT in Maclisp for the PDP-6 starting in 1968. Sage is actually said to have some of that original mainframe Lisp code, albeit ported to CommonLisp, surviving in its core routines. Configuration in a general-purpose language like this enables the editor's functionality to change as its users' preferences, requirements, hardware, and operating systems do. The actual, runtime state of configuration variables can be inspected and changed on the fly. The entire system can be modified, replaced, extended, abused, hacked, introspected, exported, and any other passive-voice verbs you can think of, at runtime, to hearts' content. People have implemented about as complicated and diverse functionality as anyone can imagine in Emacs Lisp, from [[elisp:(describe-package 'eieio)][object systems]] to [[elisp:(describe-package 'cats)][libraries of categorical programming abstractions]] to [[elisp:(describe-package 'elforth)][Forth emulation modes]]. -Emacs is configured in Lisp. The language family represents a fixed point in the relationship between programs' identity and programs' composition. Homoiconicity, there being no structural distinction between a Lisp's representation of the data it operates on and the code doing the operation, enables ordinary Lisp code to reason about other Lisp code with the same primitives used for reasoning about anything else---no weird templating, interpolation, parsing, or quoting. Just =macroexpand=. It's a dead-simple language, with about 5 pieces of syntax (lists, procedure calls, quotes, quasiquotes, and namespace distinguishment). Other versions can be implemented with about 10 primitives (see the [[https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/6515/sicp.zip/full-text/book/book.html][wizard book]]). It's extremely expressive---most modern CAS (for a fact: Maple, Wolfram/Mathematica, and SageMATH) drew on theoretical advances made by the MACSYMA system, written at MIT in Maclisp for the PDP-6 starting in 1968. Sage is actually said to have some of the original 1968 Lisp code, albeit ported to CommonLisp, surviving in its core routines. Configuration in a general-purpose language like this enables the editor's functionality to change as its users' preferences, requirements, hardware, and operating systems do. The actual, runtime state of configuration variables can be inspected and changed on the fly. The entire system can be modified, replaced, extended, abused, hacked, introspected, exported, and any other passive-voice verbs you can think of. People have implemented just about as complicated and diverse functionality as anyone can imagine in Emacs Lisp, from [[elisp:(describe-package 'eieio)][object systems]] to [[elisp:(describe-package 'cats)][libraries of categorical abstractions]] to [[elisp:(describe-package 'elforth)][Forth emulation modes]]. +The vi-style editors are hardly a monolith, but on account of their heritage they err on the side of the static UNIX Conf file for extending user behavior. The original was literally this; vim has vimscript (🤣); neovim, Lua (respectable, but far from mature). Nothing like Emacs' ecosystem, where code from the times of the dinosaurs is still found in the repositories, maintained, used, and extended. -From a user perspective, the fact that all keystrokes in Emacs are user-configurably bound to Lisp functions (or Lisp wrappers of C functions) is a large part of what enables its power. One may attach any and all of this extensive functionality to any key combination in any way, at runtime, in any way you desire. And so it has been since Stallman's FOSS port to GNU in 1984. Without this, I doubt I'd be writing this today. This contrasts again with the structure of vi: the improvements to Emacs are internal, not external. Programs written in Emacs Lisp, distributed and installed just as other programs, are used as substitutes for command-line alternatives, written in bash or C. To be clear, no generality or speed need be lost: Emacs can interact with the C ABI and command-line programs just as vi-based editors can. Instead, that generality and speed is made to balance against ease of development and use, a balance most seem to have struck against developing code externally first. Which, probably, would mean that more code would have been developed for vi, had its users the same option (neovim's move to Lua configuration confirms this further). +From a user perspective, the fact that all keystrokes in Emacs are user-configurably bound to Lisp functions (or Lisp wrappers of C functions) is paramount. One may attach any and all of this extensive functionality to any key combination in any way, at runtime, in any way you desire. And so it has been since Stallman's FOSS port to GNU in 1984. Programs written in Emacs Lisp, distributed and installed just as other programs, are used as substitutes for command-line alternatives, written in bash or C. To be clear, no generality or speed need be lost: Emacs can interact with the C ABI and command-line programs just as vi-based editors can. Instead, that generality and speed is made to balance against ease of development and use, a balance most seem to have struck against developing code externally first. Which, probably, would mean that more extension would have been developed for vi, had its users the same option (look no further than neovim's adoption of Lua). -Emacs is additionally self-documenting. In the Common Lisp tradition, every package, module, variable, function, and macro can be adorned with a docstring. These docstrings can be used to dynamically produce documentation pages for variables and keybinds, as you forget them in real-time. Emacs' use of prefix keys (e.g. =C-x=, after which the keystroke =b= will mean the Lisp function =switch-to-buffer= rather than insertion of a characters) enables packages that, through runtime querying of the current keymap, will tell you all the available next-step bindings and their functions in a key sequence if you wait too long. If you forget what a key does, or want to use a key combination in a script, =C-h k= will let you type it in and will present the documentation page of the function to which the key combination is bound. Similarly, under =C-h= are many other facilities to bring up documentation pages, which, after some configuration with an external package, will present the command, its arguments, its docstring, any manual/info entries about it, links to the documentation of other functions in close relation to it, any key bindings in any mode map that are defined to it, it's definition (whether C or Emacs Lisp), other source references to it (C or Emacs Lisp), trace calls of it, and more. I wrote my first Emacs major mode in a weekend, knowing zero Emacs Lisp beyond what I had copied verbatim from David Wilson's /Emacs from Scratch/ videos, and was distributing it among my research group the following Monday. It's difficult to overstate its power. +Emacs is additionally self-documenting. In the Common Lisp tradition, every package, module, variable, function, and macro can be adorned with a docstring. These docstrings can be used to dynamically produce documentation pages for variables and keybinds, as you forget them in real-time. Emacs' use of prefix keys (e.g. =C-x=, after which the keystroke =b= will mean the Lisp function =switch-to-buffer= rather than insertion of a =b= character) enables packages that, by runtime-querying the current keymap, will tell you all the available next-step bindings and their functions in a key sequence if you wait too long. If you forget what a key does, or want its function to use in a script, =C-h k= will let you type it in and will present the documentation page of the function to which the key combination is bound. Similarly, under =C-h= are many other facilities to bring up documentation pages, which, after some configuration, will present the command, its arguments, its docstring, any manual/info entries about it, links to the documentation of other functions in close relation to it, any relevant key bindings and their mode map, its source definition (whether C or Emacs Lisp), other calls to it from the source (C or Emacs Lisp), options to trace calls of it, and more. I wrote my first Emacs major mode in a weekend, knowing zero Emacs Lisp beyond what I had copied verbatim from David Wilson's /Emacs from Scratch/ videos, and was distributing it among my research group the following Monday. It's difficult to overstate its power. -Finally, Emacs is comparably performant to the vi ecosystem. Implementing most of the editor's functionality as modules in a scripting language means that most of Emacs' deep functionality is simply /not present/ unless explicitly loaded, either by an explicit require or as a dependency of another module or function invoked by the user. Currently, =(emacs-uptime)= returns =2 days, 9 hours, 50 minutes, 6 seconds=. Most of this time has been spent heavily loading packages to test, evaluating at some level all 6000 that're either built-in, on ELPA, or on MELPA to craft this config. Yet a simple =free -h= from the terminal reveals usage of only 602MiB, even under X, with =eww=, several info manuals, and a several-thousand-line, rich-text org document all open, among other things. That's less than the startup, idle RAM usage of some entire desktop environments, and when you consider that Emacs /is/ my desktop environment...this old, Librebooted T60 has struggled more to run certain /package managers/ than the heaviest of tasks daily Emacs editing throws at it. +Finally, Emacs is comparably performant to the vi ecosystem. Implementing most of the editor's functionality as modules in a scripting language means that most of Emacs' deep functionality is simply /not present/ unless explicitly loaded, either by an explicit require or as a dependency of another module or function invoked by the user. Currently, =(emacs-uptime)= returns =2 days, 9 hours, 50 minutes, 6 seconds=. Most of this time has been spent heavily loading packages to test, evaluating at some level all 6000 that're either built-in, on ELPA, or on MELPA to craft this config. Yet a simple =free -h= from the terminal reveals usage of only 602MiB, even under X, with =eww=, several info manuals, and a several-thousand-line, rich-text org document all open, among other things. That's less than the startup, idle RAM usage of some entire desktop environments, and when you consider that Emacs /is/ my desktop environment...this old, Librebooted T60 has struggled more to run certain /package managers/ than the heaviest of tasks Emacs editing throws at it. Emacs is, as the GNU project puts it, "/the/ extensible, customizable, self-documenting, real-time display editor." The vi ecosystem is but a pale imitation on each of those three dimensions, and so the Emacs way seems clearly the fastest towards a more principled, deeper, and enjoyable mode of human-computer interaction. @@ -84,7 +70,7 @@ Place this org file under =~/.emacs.d/=. Once Emacs is up-and-running with this This is intended to be read in tandem with other sources of documentation; particularly, the manual and built-in help facilities mentioned above. =C-h r= at any time should return to the Emacs manual, and when in doubt, spam =C-g= a few times before rerunning. To see exactly what something in the configuration snippets is doing, press =C-h o= with the point near the thing in question and it should be the first completion candidate (otherwise just type it in like a plebian 😎). -If any functionality seems useless or undesirable, add =:tangle no= to the header line (after =emacs-lisp=) in the relevant source code block. To add your own functionality, create a code block by typing = λ in Emacs Lisp mode, - ;; or \alpha -> α in TeX-mode - (global-prettify-symbols-mode t) + ;; Replace e.g. lambda -> λ in Emacs Lisp mode, + ;; or \alpha -> α in TeX-mode + (global-prettify-symbols-mode t) - ;; Enables fonts' ligature support---Iosevka has some good ones. - (use-package ligature - :if (display-graphic-p) - :config - (global-ligature-mode t) - (ligature-set-ligatures - '(prog-mode org-mode) - '("-<<" "-<" "-<-" "<--" "<---" "<<-" "<-" "->" "->>" "-->" "--->" "->-" ">-" ">>-" - "=<<" "=<" "=<=" "<==" "<===" "<<=" "<=" "=>" "=>>" "==>" "===>" "=>=" ">=" ">>=" - "<->" "<-->" "<--->" "<---->" "<=>" "<==>" "<===>" "<====>" "::" ":::" "__" - "<~~" "" "/>" "~~>" "==" "!=" "/=" "~=" "<>" "===" "!==" "!===" "=/=" "=!=" - "<:" ":=" "*=" "*+" "<*" "<*>" "*>" "<|" "<|>" "|>" "<." "<.>" ".>" "+*" "=*" "=:" ":>" - "(*" "*)" "/*" "*/" "[|" "|]" "{|" "|}" "++" "+++" "\\/" "/\\" "|-" "-|" "" "--->" "->-" ">-" ">>-" + "=<<" "=<" "=<=" "<==" "<===" "<<=" "<=" "=>" "=>>" "==>" "===>" "=>=" ">=" ">>=" + "<->" "<-->" "<--->" "<---->" "<=>" "<==>" "<===>" "<====>" "::" ":::" "__" + "<~~" "" "/>" "~~>" "==" "!=" "/=" "~=" "<>" "===" "!==" "!===" "=/=" "=!=" + "<:" ":=" "*=" "*+" "<*" "<*>" "*>" "<|" "<|>" "|>" "<." "<.>" ".>" "+*" "=*" "=:" ":>" + "(*" "*)" "/*" "*/" "[|" "|]" "{|" "|}" "++" "+++" "\\/" "/\\" "|-" "-|" " + + + + + + + + + + + SanDisk + Ultra USB 3.0 + 0101d8fb9229fee00501eaa0ec26e7148f771e8fda8c1fa162378e9cbd975560dc4c00000000000000000000282bf233009120009155810741a77293 + 4b11a4e4-140f-4d98-92a4-28219fc7eb63 + + + + + + + + + + secrets-userauth + + XSECURELOCK_AUTHPROTO=authproto_pam + XSECURELOCK_PAM_SERVICE=system-auth + XSECURELOCK_PASSWORD_PROMPT=time_hex + DISPLAY=:0.0 + XAUTHORITY=/home/dnw/.Xauthority + xsecurelock + + + + + + + + + + + + diff --git a/system-auth b/system-auth index 81f5aed..70a188e 100644 --- a/system-auth +++ b/system-auth @@ -1,6 +1,6 @@ #%PAM-1.0 -auth required pam_faillock.so preauth +auth requisite pam_faillock.so preauth # Optionally use requisite above if you do not want to prompt for the password # on locked accounts. -auth [success=2 default=ignore] pam_systemd_home.so -- cgit v1.2.3