• 1 Post
  • 9 Comments
Joined 3 years ago
cake
Cake day: January 23rd, 2022

help-circle

  • vim isn’t required for any files, you just followed online tutorials for how to edit those files instead of RTFM

    terminal text editing is convoluted because it has to strike a balance between figuring out when a keypress is part of the text you’re typing, vs when it’s a command you’re using, and making sure that all the editor commands the designer wanted are accessible.

    vim is great because it allows for thousands more editing commands and macros, and much more customization of the editor, up to allowing plugins that emulate other functionality. As it stands, my setup basically functions as a full, lightweight-ish, multi-language IDE that rivals Emacs or Visual Studio.

    On top of all that, I don’t have to move my hands away from the homerow of keys to navigate or edit, which may not seem like much, but adds up to a lot of avoid typos and time saved from moving my hands to reach the arrows/delete/home/end/pgup/pgdn.

    Some examples:

    h, j,k,l move left, down, up, and right respectively, but they can be combined with a number to move that many rows or columns; e.g. 6j will move down 6 rows

    dd deletes a line, but using a number + d + a movement will delete that many characters/lines in the path of the cursor: e.g. 34dl will delete 34 characters to the right of the cursor, 12dk will delete 12 lines up.

    gg will take you to the first line, G will take you to the last, and number + either will take you to that line: e.g. 3275gg or 3275G will take you to line 3275

    and finally you can use /text or regex pattern you want to search for and Enter to search the document for the first occurence below your current location, and then use n to search for the next occurence, or N to search for the previous

    That doesn’t even scratch the surface (that’s just the cheatsheet, which only scratches the surface), but if you can get a handle on only what I’ve said, and switching between input and command mode (i and Esc respectively), the speedup to navigation alone will make it seem more sensible.

    And as always, don’t forget to :wq (write to file and quit)





  • BaumGeist@lemmy.mltolinuxmemes@lemmy.worldnow I know why
    link
    fedilink
    arrow-up
    13
    arrow-down
    14
    ·
    6 days ago

    It’s always wild to me how these hateposts climb to the top, when all the complaints can be boiled down to “I don’t like the design choices”

    Have you tried… Just not using it? No one’s forcing you to use it. Have you tried using a different DE instead?


  • On the Caveat Emptor (“Let the buyer beware”) side of things, I look at other metrics well before I rely on stars.

    How many contributors does it have? How many active forks? How many pull requests? How many issues are open and how many get solved and how often and how lively are the discussions? When was the last merge? How active is the maintainer?

    Stars might as well be facebook likes imo: when used as intended, they didn’t say much more than “this is what the majority of people like” (surprise, I’m on lemmy bc I have other priorities than what’s popular), now they mean nothing at all.



  • I will be using your example of Arch as a great stepping off point, because honestly imo the best way to learn is by having a project to work on

    1. RTFM - Read The Fucking Manual. Read the docs, read the code comments if need be. In the case of installing an OS, use the installation guide as a starting point; Arch’s is on their wiki, and links to several other sections that go more in-depth about what each step does and why it does it.

    2. DuckDuck it - if you don’t understand what something is or why you’re doing it, search it. If you understand it completely, search it anyway and check the docs because no you don’t, you just don’t know how little you know. If you know why we do something and what function it fulfills, but not how… Then you’re a power user.

    Using your example of commands from the internet, break the command down into as many parts as you can, and figure out what each part does. If there’s punctuation marks, don’t assume you know what those are doing. man [command's name] is your friend.

    1. Do all of the above as often as possible, no matter how slow it makes progress feel. Learning these things the proper way now will save you from days, weeks and months of troubleshooting in the future. I mean it, literally at every step of the process.

    2. secondary sources are invaluable, but for this it might help to get into the best way to self-educate. The only gospel are the docs and/or manual that were written by the code/OS maintainers - primary sources - everything else is opinion.

    Here’s a source i agree with on the best way to self-educate, but keep in mind even Artem is still just a secondary source.

    That being said, here’s a few secondary sources that helped me understand how OSes work and why:

    nand2tetris: build an operating system starting with logic gates and working your way up from there. It has a offshoot site that’s slowly being rolled out, that implements it all in a gamified interface: nandgame

    os-tutorial: build an OS from scratch

    Linux From Scratch: Learn everything about Linux by building your own distro from the kernel up.

    Unfortunately everything that taught about the behind-the-scenes aspects of OSes in general—and Linux in specific—were either projects like the above, or just seeing what came up in a DuckDuckGo, Youtube, forum, or wiki etc. search. Below are just resources that teach you about the “power user” level of knowledge, not “super user” but not your average user either.

    Fireships’ 100+ Linux Things you Need to Know: it’s not particularly good on its own, but it does introduce a lot of concepts and vocab for you to then look up elsewhere

    freeCodeCamp.org offers a lot of courses that will go over using Linux. None go too in-depth on the fundamentals of Operating Systems, but they will still introduce most of what you need to know for day-to-day use. I don’t want to link them all, but just search for linux freecodecamp on youtube and find one that piques your interest. The longer, the more in-depth—you don’t have to watch it all in one sitting.

    1. And of course, when all else fails: just ask. Participate in the community, don’t be afraid of looking stupid. The only people that get no respect are the ones who refuse to accept others’ help because they know better than those they’re asking to help them. (ignore the gatekeepers who want to project their own need for an identity onto you)