• 0 Posts
  • 24 Comments
Joined 10 months ago
cake
Cake day: January 12th, 2024

help-circle








  • Little addendum to the last part of About Fragmentation section, since I don’t want to leave it unfinished and make people struggle if they follow my advices:

    $HOME/.local/opt is a “usual” (there are few more, I prefer this one) location for pre-built (downloaded) and built-locally apps that you don’t want to install system-wide.

    For example:

    1. I downloaded neovim binaries because I didn’t have time to build em (lazy ass), but at least I did it from their git repository.
    2. I untarred the archive using tar xvf nvim<press TAB>, or right clicked on the archive in a GUI file manager and clicked decompress.
    3. moved nvim-linux-x64 directory into .local/opt, and renamed it to nvim (usually done in one command, if using terminal - mv nvim-linux-x64 $HOME/.local/opt/nvim)
    4. Changed dir into .local/opt/nvim and found the executable, in our case something like ./bin/nvim.
    5. I link that executable into a directory for binary files that lies on the PATH (system checks PATH it to find shit), like this - ln -s /home/<my nickname>/.local/opt/nvim/bin/nvim /home/<my nickname>/.local/bin/nvim this command requires absolute paths and creates a SYMBOLIC link (you can read up on that if you’re interested). GUI file managers usually have functionality for creating symlinks, right click on file to find out.
    6. Some distros include .local/bin to path by default, while others don’t. Simple way to do so is open your .bashrc or .zshrc that’s located in $HOME in a text editor, and somewhere close to the end of file write export PATH="$HOME/.local/bin:$PATH"
    7. I close and reopen my terminal. Nvim is now installed, by hand.

    Something like that. It’s all done just for organization and quality of life.


    1. Kate, Neovim, Emacs, +lots and lots more, pick your poison.

    2. QEMU/KMV can host windows guests pretty flawlessly, pain to setup though. I use it to work in visual studio for college stuff. USB passthrough should work. No idea about thunderbolt though.

    3. Native games work as expected, not native games only work through a translator either raw Wine or Proton (is better suited for games). They have frontends, such as Steam, Lutris, and other. Not all games work through translators. Consult protondb for games you want to play.

    4. Natively? No idea, didn’t play a single native game. Through Steam - flawlessly.

    5. Playing video through mpv has GUI. It has GUI. For videos. You might want to consider VLC, if audio GUI is a requirement. Or any other GUI audio player.

    6. Any DAW/video editor. I’ll bet my life on that 90% of them use ffmpeg. Tools like flacon most likely use ffmpeg. It’s everywhere.

    7. rename command. Probably dolphin and nautilus have mass renamers with a GUI, but I only used rename and it gets the job done.

    8. Depends on your desktop environment, kde probably has support for anything shortcut related.

    9. On Linux we usually don’t install random shit we download through browser. That’s what package managers are for, every base distro has its own package manager with its own structure. And if package managers are lacking then we get source code and build it. In very rare cases like Reaper DAW probably only then we download binaries.

    More about fragmentation: Linux uses ELF executables. Amd64 elves will work on every amd64 Linux machine (that has required libs). Some distros package apps into intermediary archives that are prebuilt into a more structure friendly to that distro way. If you install one distros prebuilt archive on another one, it might install files into different dirs and you will not know how to get out of that situation. All Linux software is available under every distro, if you include building from source as an option. If you really must download shit off of web and install it but it doesn’t display your exact distro follow these instructions: 1. child distro usually can install base distro’s intermediary archives and be ok about it, example: ubuntu is child to debian, popos is child to ubuntu. 2. Extract archive and locate the binaries, that’s it. Then put it somewhere in $HOME/.local/opt and ln -s fullpathtoappbin fullpathtolocalbinarydir or just run from $HOME/Downloads.

    1. I stopped reading around here, that’s way too much fucking text for me alone.




  • ma1w4re@lemm.eetoLinux@lemmy.mlHow to quit VIM?
    link
    fedilink
    arrow-up
    2
    ·
    3 months ago

    To your “never got the appeal”.

    Ngl for me using vim is the only option. If something needs to be done using a mouse, it’s just not going to be done. I can’t aim properly due to problems with my arms, and it itches something in my brain everytime I try, it makes me literally furious and enraged.

    I tried using zed, but quickly found out that I can only control the text field with motions, nothing else.

    If I try using mouse, speed of anything I do gets multiplied by 0.1.

    Thanks to vim, I’m able to work with loads of text at all.

    Simple as that.



  • Sorry if it comes out robotic, since I don’t use stow myself I just opened the manual and parsed it for you.

    You manually create the repo of packages ONCE and then use stow to deploy them without having to link stuff manually every time.

    As for “what’s it doing for me”, stow is just a generic deployment script that somebody else has written for you. You can just as well create your own and do it your way.

    I personally used to have a bash script with one custom function “symlink” that error checked the linking process and a list of target/destination under the function.

    Now I’m trying to code a python script similar to stow that works with packages of configs but instead of recreating paths inside the package you just provide a json file with target/destination for each file in the package.

    Both of my ways have same shortcoming as stow: you have to do some manual work before the script can kick in.

    Hopefully my messages have been helpful.


  • Recreating a path to original locations is a way to configure stow.

    You can utilize bash to automate it. Mkdir can create entire trees in a single command.

    After links were created you start using your configured software.

    It’s a link farm built using a packaging system. You put your configs into a “package” and then link said package where it belongs.

    Git is useful not as a combination for stow, but a standalone way to version control your configs.

    For nonidentical devices you create additional packages prefixed with specific device name. You don’t need to link all packages at once with stow, pass a name of a package to link it alone.