c0dev0id

Memory management, virtual and residential memory

C0dev0id — 2021-09-26T00:00:00Z

------------------------------------------------------------------------ Memory management is a complex topic and most can be left for the kernel tto handle. But having a fundamental idea about where memory is allocated greatly helps in understanding top(1) and the memory footprint of applications. # Process memory address space (page) When a process starts up, the kernel assigns is a so called memory page. The page size depends on the architecture. On amd64 it's 2^64 - 1 bytes. Every memory allocation this process performs, returns a pointer to some place within this page. Forcing a pointer outside this page, will cause a SEGFAULT. char *w = 1; // segfault char *w = malloc(12); // returns pointer within page # Memory allocation (virtual memory) Let's say we allocatate 2G of memory: char *m = malloc(2*1073741824); // 2*1G in bytes This will grab 2G of consecutive address space within the process memory. At this point, the memory is likely available but not guaranteed. The allocation shows up in top(1) as "SIZE" or on linux as "VIRT"ual memory. This memory is not actually used. So nothing has been written to the physical RAM chip in your computer. # Using memory (residential memory) Once memory gets used, it will actually use up space on your RAM chip. memset(m, 'u', 1073741824); Now we've written the character "u" to the first 1G of our allocated memory. If we look at top(), we'll see something like this: PID TID PRI NICE SIZE RES STATE WAIT TIME CPU COMMAND 96621 569318 3 0 2048M 1027M sleep/12 ttyin 0:01 1.66% ./a.out ^ ^ allocated memory -' `- used (written) memory Note 1: When memory is swapped to disk, it leaves the residential bucket and can be seen as swap->used. Note 2: Stack memory will also show up as residential when used. Unused stack memory will *not* show up as virtual memory. Note 3: Residential memory includes shared memory as well. If you see 10 chrome processes which are consuming 300MB of residential memory each, this does *not* mean that chrome as a whole is using 3000MB. TODO: Find out how the shared memory part of RES can be seen on OpenBSD. (Linux has SHR in top) Changelog: * 2021-09-26: Created * 2021-09-26: + segfault example * 2021-11-01: s/1G/2G/g in the paragraph below malloc() # * 2022-06-28:

GnuPG Quickstart

C0dev0id — 2021-05-19T00:00:00Z

------------------------------------------------------------------------ I love GPG and the way it works. I know there are many that complain about it because it has flaws. My stance on this is that I prefer battle-tested software with known flaws to something with unknown flaws. Anyway, this should get you started with GnuPG # Prerequisites Install gpg and pinentry. $ pkg_add gnupg pinentry # You need a Key If you want to lock and unlock stuff, you need a key. This is how you get to one: $ gpg --generate-key Hop through the wizard until you see these lines: pub rsa3072 2021-05-19 [SC] [expires: 2023-05-19] BA696588D9A04AD9F70DA33EC54733F6DBECC2C1 uid John Doe sub rsa3072 2021-05-19 [E] [expires: 2023-05-19] If you see an error like: gpg: agent_genkey failed: Permission denied Add the following entry and try again. $ cat ~/.gnupg/gpg-agent.conf allow-loopback-pinentry Congratulations, you got yourself a GPG Key. This long gibberish is your full GPG Key ID. Most of the time, you can simply use the last 8 characters. So the short version of this GPG Key is DBECC2C1. You can set it as default key, so it's used to encrypt stuff when no explicit key is given. $ cat ~/.gnupg/gpg.conf default-key DBECC2C1 # Share the key with your people If you want someone to be able to encrypt something for you, send him or her the output of: $ gpg --export -a DBECC2C1 You can also use your email address instead of the Key ID, if you have only one key with it. This key is public. So put it on some webspace and add a link to your email header or signature. # Upload the key so people can find it You can also upload your key to a key server. For this, configure a keyserver: $ cat ~/.gnupg/gpg.conf keyserver hkp://ha.pool.sks-keyservers.net Then send your key to it: $ gpg --send-keys DBECC2C1 # You got a key from someone Add a key from someone else to gnupg, so you can use it to encrypt data for this person. If the key is on your harddrive, use: $ gpg --import The file ending here is kind of undefined. Some call it .asc, .gpg, .pub or .key. If the key is on a key server, you can import it like so: $ gpg --recv-key 52BE43BA This would import my key. You can look at it now with: $ gpg --list-keys 52BE43BA # Encrypt a file This encrypts the file plain.txt with the public key DBECC2C1. $ gpg --encrypt -r DBECC2C1 file.txt Now you have file.txt.gpg, which is the encrypted version # Decrypt a file GnuPG automaticall figures out what key it can use to decrypt a file. So tthis will output the content of file.txt on the terminal. If you want tto save the output in a file, add -o file.txt. $ gpg -d file.txt.gpg $ gpg -d file.txt.gpg -o file.txt Choose a better password prompt =============================== You can change the way gpg asks for the password: $ cat ~/.gnupg/gpg-agent.conf pinentry-program /usr/local/bin/pinentry-curses Options are: - pinentry (sometimes also called pinentry-tty) - pinentry-curses - pinentry-gtk2: pkg_add pinentry-gtk2 - pinentry-gnome3: pkg_add pinentry-gnome3 - pinentry-dmenu: gopher://github.com/ritze/pinentry-dmenu ! Note: If you use a console pinentry program and want to use gpg with a ! ! GUI tool (like thunderbird), the password prompt will be invisible and ! ! gpg/thunderbird will freeze. " Makes sense, doesn't it? Start GPG Agent for password caching ==================================== Put this in your .kshrc or .bashrc: $ cat ~/.kshrc export GPG_TTY=$(tty) gpg-connect-agent /bye Make a Backup ============= There is no handholding cloud or support team you can call when you messed up or deleted your key. So back it up safely. Either you backup your ~/.gnugp directory, or you export the secret keys and backup them safely. $ gpg --export-secret-keys -a DBECC2C1 > gpg_key_backup.sec Seriously, don't skip this step. Configure Mutt ============== Install mutt with the gpgme flavor. Gpgme is the "new way" of handling gpg in mutt. $ pkg_add mutt--gpgme If you're not on OpenBSD, check with `mutt -v` if it was compiled with tthe --enable-gpgme option. Then enable it in mutt. $ cat ~/.muttrc crypt_use_gpgme = yes In the mutt compose view, you can now select Security Options. From: C0dev0id To: j.doe@example.com Cc: Bcc: Subject: Hello my friend Reply-To: Fcc: =Sent Security: Sign, Encrypt (PGP/MIME) Sign as: You can change the setting with the key "p", which should bring up a selection menu. PGP (e)ncrypt, (s)ign, sign (a)s, (b)oth, s/(m)ime or (c)lear? Changelog: * 2021-05-17: Created * 2022-06-28: Gemini compatible styling :/

Linux Presentation Day 2021 (DE)

C0dev0id — 2021-05-05T00:00:00Z

------------------------------------------------------------------------ This year, I decided to take part in the linux presentation day (LPD). While I'm not really a Linux person (anymore), I think supporting people tto switch to OpenSource software is a valuable thing. The event is supposed to be a European wide, but it looks like it's mostly a German event. I recorded 3 Talks for it (in German). The Linux Presentation Day is on the 15th of May 2021, but the Videos will be online starting from the 7th. [h|LPD-Online 2021 Fahrplan|URL:gopher://l-p-d.org/de/events/lpd_online_2021-1/fahrplan/start|server|port] Once online, I'll add the videos to our Unix User Group Wiki as well. [h|* Terminals verwalten mit TMUX|URL:gopher://wiki.uugrn.org/UUGRN:LPD-Online-2021/TMUX|server|port] [h|* Shell Survival Guide I|URL:gopher://wiki.uugrn.org/UUGRN:LPD-Online-2021/Shell_Survial_Guide_1|server|port] [h|* Shell Survival Guide II|URL:gopher://wiki.uugrn.org/UUGRN:LPD-Online-2021/Shell_Survial_Guide_2|server|port] I definitely have enough material for two more Shell Survival Guides, but I was not able to record them in time. Maybe I'll add them at a later point to our Unix User Group Wiki. [h|Feel free to meet us at our Introduction Live Channel (DE) @ 15th of May|URL:gopher://l-p-d.org/fahrplan#7ecc|server|port] # Changelog: # * 2021-05-05: Created # * 2021-05-05: Fixed URL

DeltaChat - an e-mail based OSS messenger

C0dev0id — 2021-01-12T00:00:00Z

------------------------------------------------------------------------ I know you know WhatsApp, Facebook, Telegram, Threema and Signal. But do you know there is one messenger you likely don't know about but have an account already? It works fully distributed, supports E2E encryption, allows group chats, attachments, offline messages, does not track you, runs on all your devices and has multi-client support? Sounds too good to be true? Meet DeltaChat. DeltaChat is a messenger application which uses e-mail as backend. It connects tto your email account and creates a DeltaChat folder. All your chat meessages go there. If you export your encryption key from the delta chat app, you can also read those messages via email (it uses gpg autocrypt). Also, if you write someone from within the DeltaChat app and this person does not have DeltaChat installed, this is perfectly fine. He can respond via E-Mail and it will work just as well. Okay, there are no stickers (yet) and obviouly no phone and video call functionality. But other than that, it pretty much ticks all the boxes a convenient and secure and free and distributed OpenSource messenger should. The setup is as easy as entering your email credentials and everyhing else is taken care of. [h| * DeltaChat Homepage|URL:gopher://delta.chat|server|port] [h| * DeltaChat Clients for Windows, Android, iOS, macOS, Linux and Source Code|URL:gopher://get.delta.chat|server|port] # Changelog: # * 2021-01-12: Created

Port Submission Checklist

C0dev0id — 2021-01-10T00:00:00Z

------------------------------------------------------------------------ We all make errors. Especially me. When something is almost done, I tend tto skip steps in the QA phase. So this is a personal checklist to help me focus and not skip steps. 0. Set up the _pbuild user and don't work as root. Existing Port Update Checklist: 1. Execute portcheck 2. Execute make port-lib-depends-check 3. Execute make update-plist 4. Execute make update-patches 5. Execute make test 6. Document (new) patches 7. Check REVISION (remove on upstream update) 8. Test the software 9. Really, test the thing! 10. Review the created patches for unnecessary cruft New Port Checklist: 1. Execute portcheck -N 2. Execute make port-lib-depends-check 3. Remove -g CFLAG if present 4. Add a test target if possible 5. Document patches 6. Execute make plist 7. Make sure files are installed to the correct path 8. Execute make test 9. Test on a bare test machine to catch all dependency issues 10. Test the software 11. Really, test the thing! 12. Review the created patches for unnecessary cruft When submitting a patch to the mailing list: 1. The patch goes inline (new ports and huge diffs go as tarball) 2. Don't mess up tabs 3. Mention upstream changes (or link to changelog) 4. Mention port changes 5. Mention carried out tests (and result) 6. Mention tested architectures Carry out all steps with full concentration. Don't assume steps could be skipped, just because it worked in the last version. When creating patches, create fixes that can be upstreamed (and do so) if possible. # Changelog: # * 2021-01-10: Created # * 2021-01-12: s/make plist/make update-plist/ (thx solene) # * 2021-01-21: Add remove -g

Mutt inline patch handling

C0dev0id — 2021-01-09T00:00:00Z

------------------------------------------------------------------------ Developers like to send diffs inline in emails. They do this, because it's fast and easy to read through them, comment on them and also to apply them. Many version control systems take over the email text into the patch description as well. Up to now, my workflow was manual. I had to save the email somewhere, tthen open a terminal, cd to the direcory the patch shall be applied in and call the patch utility with the path to the saved email as argument. No more. This mutt macro takes the current visible email and copies it to a ttemporary file (/tmp/mutt-patch.diff). Then it executes the portpatch.sh shell script. All with one push on ctrl+s while looking at the email. The macro must be written in one line and ^S can be entered with the keyboard sequence ctrl+v ctrl+s: macro pager ^S "rm -f /tmp/mutt-patch.diff

/tmp/mutt-patch.diff

echo 'Saved as /tmp/mutt-patch.diff'

~/.mutt/scripts/portpatch.sh /tmp/mutt-patch.diff" The portpatch.sh script: #!/bin/sh printf '\n-------------------------------------------------------\n' cat "$1" | egrep ^Index\|^RCS\|--git printf '-------------------------------------------------------\n\n' printf "Path for patch [/usr/ports]? " read _path [ -z "$_path" ] && _path=/usr/ports doas patch -p0 -d $_path < "$1" cd $_path && ksh The script shows some relvant bits from the email patch that are handy tto determine on which path the patch shall be applied. Next it alles the user to enter a different path. I most use /usr/ports, so this is the default. Then the patch is applied and a ksh shell is opened for further work. Quitting the shell brings me back to mutt to work on the next email. This is quite friggin handy. # Changelog: # * 2021-01-09: Created

OpenBSD How to use a webcam

C0dev0id — 2020-11-15T00:00:00Z

------------------------------------------------------------------------ +----------------------------------------------------------------------+ | | | Enabling Video Recording (OpenBSD 6.9) | | | +----------------------------------------------------------------------+ For privacy reasons, video recording is disabled by default in OpenBSD. The sysctl "kern.video.record" may be used to enable it. While recording is disabled, a blank video will be shown. # sysctl kern.video.record=1 # echo kern.video.record=1 >> /etc/sysctl.conf +----------------------------------------------------------------------+ | | | Supported Hardware | | | +----------------------------------------------------------------------+ Most webcams today implement the USB Video Class (UVC) specification, which is supported by the uvideo(4) device driver and attaches to the video(4) device. The manpage lists some supported devices, but there is a good chance that other devices work as well. For example, webcams in Lenovo Thinkpad laptops do usually work. A supported webcam (or other video device) shows up in dmesg like this: uvideo0 at uhub0 port 8 configuration 1 interface 0 "Azurewave \ Integrated Camera" rev 2.01/69.05 addr 10 video0 at uvideo0 uvideo1 at uhub0 port 8 configuration 1 interface 2 "Azurewave \ Integrated Camera" rev 2.01/69.05 addr 10 video1 at uvideo1 You see that an uvideo device was detected and has been attached to video0. This device will be accessible through /dev/video0. Modern laptops sometimes attach a second video device, which is the infrared camera for face recognition. The second camera does not produce a usable video stream. You can find the usable camera with the video(1) command: $ video -q -f /dev/video0 video device /dev/video0: encodings: yuy2 frame sizes (width x height, in pixels) and rates (in frames per second): 320x180: 30 320x240: 30 352x288: 30 424x240: 30 640x360: 30 640x480: 30 848x480: 20 960x540: 15 1280x720: 10 controls: brightness, contrast, saturation, hue, gamma, sharpness, white_balance_temperature $ video -q -f /dev/video1 video: /dev/video1 has no usable YUV encodings The usable camera device shows supported resolutions and frameratei. Note that the framerates only apply to the uncompressed YUY2 stream. More on that in "Recording a webcam stream" +----------------------------------------------------------------------+ | | | Using a webcam as user | | | +----------------------------------------------------------------------+ To use the webcam as regular user, you need to change the device permissions. Only root is allowed to access video devices by default. One way of allowing your user to access the video devices is to change the permissions from ~/.xsession. You can configure doas(1) to perform chmod(1) as superuser without asking for a password for your user. $ doas chown $USER /dev/video0 +----------------------------------------------------------------------+ | | | Recoding a webcam stream | | | +----------------------------------------------------------------------+ This section uses ffplay and ffmpeg from graphics/ffmpeg. To find out what your camera is capable of, run the following command: $ ffplay -f v4l2 -list_formats all -i /dev/video0 [...] [video4linux2,v4l2 @ 0x921f8420800] Raw : yuyv422 : YUYV : 640x480 \ 320x180 320x240 352x288 424x240 640x360 848x480 960x540 1280x720 [video4linux2,v4l2 @ 0x921f8420800] Compressed: mjpeg : MJPEG : \ 1280x720 320x180 320x240 352x288 424x240 640x360 640x480 848x480 At the end of the output, you'll find two lines similiar to the two above. The first line shows resolutions supported in the uncompressed YUYV format. The frame rates in this format can be very low. The second line shows the supported MJPEG compressed video resolutions, which deliver much higher framerates (usually 30fps or 60fps). Now try to play the webcam stream. Choose one of the MJPEG resolutions and run: $ ffplay -f v4l2 -input_format mjpeg -video_size 1280x720 -i /dev/video0 [...] Input #0, video4linux2,v4l2, from '/dev/video0':B sq= 0B f=0/0 Duration: N/A, start: 1599377893.546533, bitrate: N/A Stream #0:0: Video: mjpeg (Baseline), yuvj422p(pc, bt470bg/unknown\ /unknown), 1280x720, 30 fps, 30 tbr, 1000k tbn, 1000k tbc The webcam stream should be displayed. Ffplay also shows the used resolution and the framerate (fps) used. If this works, you can go ahead and record the video with ffmpeg: $ ffmpeg -f v4l2 -input_format mjpeg -video_size 1280x720 \ -i /dev/video0 ~/video.mkv +----------------------------------------------------------------------+ | | | Controlling webcam settings | | | +----------------------------------------------------------------------+ Webcams usually have brightness, contrast and other controls. Video(1) allows you to alter these settings. First find out which supported controls your camera has: $ video -c brightness=128 contrast=32 saturation=64 hue=0 gamma=120 sharpness=3 white_balance_temperature=auto You can change for example the brightness setting to 200: $ video brightness=200 brightness: 128 -> 200 If you would like to reset all settings to their defaults, you can do so with: $ video -d $ video -c brightness=128 contrast=32 saturation=64 hue=0 gamma=120 sharpness=3 white_balance_temperature=auto Some settings, like the white_balance_temperature support automatic adjustments. You can set them to a fixed value or set them to "auto", which lets the camera decide and use whatever value it thinks is best. +----------------------------------------------------------------------+ | | | Access webcam in chromium | | | +----------------------------------------------------------------------+ Chromium has access to /dev/video and /dev/video0 by default. To allow Chromium to access other video devices, you need to add the device paths tto /etc/chromium/unveil.main and /etc/chromium/unveil.utility_video +----------------------------------------------------------------------+ | | | Access webcam in firefox | | | +----------------------------------------------------------------------+ Firefox has access to /dev/video and /dev/video0 by default. To allow Firefox to access other video devices, you need to add the device paths to /etc/firefox/unveil.main. # Changelog: # * 2020-11-15: Created # * 2021-01-04: Changed styling # * 2021-07-21: Corrected browser headings

OpenBSD FDE Setup

C0dev0id — 2020-11-14T00:00:00Z

------------------------------------------------------------------------ This is a condensed version of OpenBSD FDE encryption FAQ. Boot installer, drop to shell with "s" # cd /dev && sh MAKEDEV sd0 # dd if=/dev/urandom of=/dev/rsd0c bs=1m # fdisk -iy -g -b 960 sd0 # GPT / without -g and -b for MBR # disklabel -E sd0 Note, switch to kbd en before setting the password as this is what you have on the boot prompt. # bioctl -c C -l sd0a softraid0 # dd if=/dev/zero of=/dev/rsd1c bs=1m count=1 Ctrl+D to restart the installer. Choose sd1 as install target. If sd1 is not present: # cd /dev && sh MAKEDEV sd1 When the installer later asks about installing with MBR or GPT layout, choose MBR. Even if you boot via UEFI/GPT. # Changelog: # * 2020-11-14: Created # * 2021-04-18: Added MBR info for disk layout selection

OpenBSD Desktop GPU recommendation

C0dev0id — 2020-07-12T00:00:00Z

======================================================================== OpenBSD has decent intel GPU support. So finding a laptop that works great is not really difficult. The story is different when you look at desktops. I've tested several graphic cards and there are winners. +----------------------------------------------------------------------+ | | | Radeon R9 390X (radeon) | | | +----------------------------------------------------------------------+ This card is driven by the HAWAII XT chipset, which is covered by the radeon drivers HAWAII support. It's the latest and fastest device supported by this driver. +----------------------------------------------------------------------+ | | | Radeon HD 7790 (radeon) | | | +----------------------------------------------------------------------+ This card is driven by the BONAIRE chipset, which is the predecessor to HAWAII. This card is still listed as high end card, but draws a lot less power than the R9. Both are fine for gaming. Both cards support resolutions up to 4K. However only via display port. The R9 delivers 4K@30Hz via HDMI. Newer AMD GPUs are supported by the amdgpu driver, which is not as stable as the old radeon driver. +----------------------------------------------------------------------+ | | | UPDATE: Radeon RX 450 (amdgpu) | | | +----------------------------------------------------------------------+ My setup is HDMI based, and I had to use an active adapter from DP to HDMI to get to a 60Hz 4k signal. This HDMI signal is then going into my KVM switch and from there to the screen. With this many hops, I experienced some sort of jitter every once in a while. There was significant progress in the amdgpu development in the last months, so I gave it a shot again. I'm now using an RX 450 card with tthe Polaris 12 chipset. It runs stable for me. So maybe amdgpu is ready for prime time? At least with this chipset I'm very pleased with its performance. The HDMI 4k signal is stable. # Changelog: # * 2020-07-12: Created # * 2020-12-09: Add RX 450 amdgpu

Browser Dark Mode (Chrome and Firefox)

C0dev0id — 2020-05-17T00:00:00Z

======================================================================== Dark Mode luckily has become a thing also in the non-unix world. Finally browser can be used with dark interfaces and websites can have alternative color schemes. However, in other operating systems, there is a global toggle for dark mode, which also switches the browser into it. This is not the case on linux and unix systems. +----------------------------------------------------------------------+ | | | Chrome / Chromium / Iridium | | | +----------------------------------------------------------------------+ Chrome and Chromium starting with version 73 can be tought to start in dark mode: $ chrome --enable-features=WebUIDarkMode --force-dark-mode Then go to chrome://settings/?search=themes and switch the theme to "Classic". +----------------------------------------------------------------------+ | | | Firefox | | | +----------------------------------------------------------------------+ Firefox got the dark mode in release 70. 0. Go to "about:config" 1. Enter "ui.systemUsesDarkTheme" into the search bar 2. Click "Number" and then "+" 3. Enter "1" and click the check mark Right click on a free spot in the icon bar and select "customize". At tthe bottom left of the screen, you can switch to a dark theme. Note: If you've set privacy.resistFingerprinting to "true" the CSS dark mode switching won't work. Kudus to @andinus@tilde.zone for figuring tthis out. There you go, both browsers are in dark mode now. The UI should be dark and also websites that support the @media (prefers-color-scheme: dark) directive should make use of it. You can test it on my webpage (gopher://codevoid.de). The light version has a light gray background and a blue font. The dark version has a dark gray background and an orange font. vim-browser (vimb) ================== $ echo "set dark-mode=true" >> $HOME/.config/vimb/config # Changelog: # * 2020-05-17: Created # * 2020-12-04: Added vimb

Build OpenBSD Kernel

C0dev0id — 2019-10-24T00:00:00Z

======================================================================== I'm running OpenBSD-current for a while in order to support my port. It's currently only one port, but that's a start, right? Anyway... every once in a while I stumble over a patch on the OpenBSD Mailinglist I want to try and this requires me to apply the patch and build the Kernel with it. But how? Well, the documentation is where you would expect it: gopher://www.openbsd.org/faq/faq5.html#Custom Download the kernel source # cd /usr # cvs -qd anoncvs@anoncvs.ca.openbsd.org:/cvs checkout -P src Update the kernel source # cd /usr/src # cvs -q up -Pd Configure Kernel # cd /usr/src/sys/arch/amd64/conf # cp GENERIC.MP MYKERNEL # config MYKERNEL Build and install kernel (amd64) # cd /sys/arch/amd64/compile/MYKERNEL # make clean # make # make install # the old kernel is /obsd now That's it. Reboot. This is ONLY the Kernel. If you need to build the whole system, please consult the OpenBSD documentation. # Changelog: # * 2019-10-24: Created

LineageOS on Motorola Z2 Force

C0dev0id — 2019-10-17T00:00:00Z

======================================================================== Whenever there is a major LineageOS Update, chances are that I forgot tthe flashing process. So here are the notes. Disclaimer: Due to the missing tools to flash from OpenBSD, I use my work computer, which runs windows. Required Downloads: * Android Platform Tools (contains adb and fastboot) gopher://dl.google.com/android/repository/platform-tools-latest-windows.zip * Motorola Smart Assistant (contains USB drivers for fastboot) gopher://support.lenovo.com/us/en/downloads/ds101291 Prepare: - Install motorola smart assistant - Extract platform-tools make sure you're in the platform tools directory or that they are in your $PATH. Update steps: - > Boot into bootloader (power+down) - $ fastboot flash boot_a .img - $ fastboot flash boot_b .img - > Boot into bootloader (power+down) -> Boot Recovery - > Factory Reset -> Wipe data / factory reset + Wipe System - > Apply update -> adb sideload - $ adb sideload .zip - $ adb sideload .zip - > Reboot $ == commandline activity > == phone activity Notes: * "adb devices" works without USB drivers * "fastboot devices" shows nothing if USB drivers are not installed * This phone has two boot areas and therefore "fastboot flash boot" will fail. The areas "boot_a" and "boot_b" must be used instead. If "boot_a" and "boot_b" are flashed differently, booting will fail. # Changelog: # * 2019-10-17: Created # * 2019-10-17: Added activity indicator and "Prepare" # * 2019-10-17: Clarify boot_a, boot_b situation

Manage dotfiles with git

C0dev0id — 2019-04-27T00:00:00Z

======================================================================== I'm managing my dotfiles with git. My method serves me well for a few years already and so I think it's time to write it down. If you think git, you might think of a dotfile repository and dozens of symlinks into the home directory. This is precisely what kept me from using git until I discovered bare repositories. Create your dotfile repository with the --bare parameter $ git init --bare $HOME/.cfg This creates only a folder for git control files, which normally reside inside the .git folder within the repository. You can now tell git to use $HOME as your work-tree directory. This makes git handle your home directory like all the files would be within tthe git repository. Now you can: $ git --git-dir=$HOME/.cfg/ --work-tree=$HOME add .vimrc $ git --git-dir=$HOME/.cfg/ --work-tree=$HOME commit -m "my .vimrc" If course it is silly to type out such a long command every time you want to interract with your dotfiles. So why not create an alias? $ alias config='git --git-dir=$HOME/.cfg/ --work-tree=$HOME' Put this in your .bashrc or .kshrc and you can now use the command "config" in the same way you usually use git. $ config add .vimrc $ config commit -m "my vimrc" Maybe you were brave and typed "config status" already. This will list tthe content of your whole home directory as "untracked files". This is not what we want. We can run "git config" and tell it to stop doing tthis. But of course we must run our git, which is called "config". $ config config --local status.showUntrackedFiles no Now git status will only check what's being tracked. So if you add your vimrc file and later change it, "config status" will show it, "config diff" will diff it... You can now use the power of git with your new "config" command. The solution is not perfect, so I'm using a few workarounds. 1. Passwords Try to keep your passwords out of your dotfiles. In many cases, this can be done with gpg (or password-store gopher://www.passwordstore.org). Examples: - .msmtprc: passwordeval "gpg2 -d $HOME/.msmtp-pw.gpg" - .offlineimaprc: pythonfile=~/.offlineimap.py remotepasseval=get_pass("mail","user","993") - .muttrc: source "gpg2 -d $HOME/.mutt-pw.gpg |" Actually, I use "password store" and prefer to use it to retrieve passwords. In mutt this would be something like: source "pass Accouts/private-mutt |" Another method I use is that I keep the origin of some files gpg encrypted. For example my .ssh/config file, as I don't want to leak hostnames user and ports. My vim has the vim-gpg plugin loaded and can therefore edit .gpg files directoy (decrypt, edit, encrypt). So I create a simple shell alias for convenience: $ sshconfig() { $ vim ~/.ssh/config.gpg && \ $ gpg2 -qd ~/.ssh/config.gpg > ~/.ssh/config $ } With this I run "sshconfig", update my file, save, done. of course I added only config.gpg to my git. On a new system I have to run sshconfig once to create the config file. 2. Stuff outside $HOME I wanted to add a few files that reside in /etc. Here I took the lazy route and created $HOME/.etc and copied the files there. On a new machine I have the files, but need to copy them manually. Works fine for me. 3. Host specific files I try to keep my dotfiles compatible to all computers I use. But sometimes this is not possible and there are a few methods to battle this. If your configuration allows code evaluation, you may do something like ". myconfig.$(hostname -s)" and just check in individual files per host. If this does not work or you have a file that needs to have a password in it, you could copy the file, remove the password and check it in as template or sample file. The methods above served me very well over the past years and I'm not seeing why I would want to change it. It's easy and simple and I don't need to remember anything beside a few git commands. Well okay, because I'm lazy and don't want to think about git commit messages, I'm using this to push my changes: $ dotfiles_autoupdate() { $ MSG="Update $(date +"%Y-%m-%d %H:%M") $(uname -s)/$(uname -m)" $ config add -u && \ $ config commit -m "$MSG" && \ $ config push $ } This command takes all changed files and commits them with the date and some machine information. Not creative, but I don't care. YMMV. # Changelog: # * 2019-04-27: Created # * 2019-04-28: Added password evaluation examples # * 2020-05-17: Added password-store and sshconfig examples