As a result, you enable them to understand what's happening. You eliminate a whole class of problems as well, because you know exactly the tools they're installing and using. You write something more focused, as I did: the readers can practice, you can describe and explain everything they're doing because the focus is more narrow. If I wanted to do that, I would have created another "Awesome list of Linux tools" on GitHub.Ģ. As a result, the readers can't really practice with a concrete project, and they might end up lost in an ocean of links. The book is not practical anymore, because you don't speak about something in particular but some general ideas. If I simplify a bit, I see two different approaches:ġ. Rather, I think that there are ways to make the book a more useful resource for more people by broadening it to "here's how I do it and here are some other ways that might work better for you." Tiling window managers are not dependent on distribution. Ubuntu has a different way of reasoning about system maintenance that might offer less friction for other people. The strong opinions of Arch Linux are orthogonal to the goal of switching to a tiling window manager. This makes reasoning about the ongoing process of maintaining a Linux installation consistent. I guess what I am getting at is "highly opinionated" is better suited for ongoing processes than it is for soft goals. Text editors are another place where the right tool varies among people. A neutral description of the options and links to resources might have broader appeal. Similarly, there are several tiling window managers. Rather Ubuntu is probably easier for many people. It's not that there is anything wrong with Arch. Last thing: If you already know and use all these tools, you won't learn much from the book I'm afraid.Īny feedback, positive or negative, is welcome!įor what it's worth, I think there is a lot of space between what you use and what might work for other people. If you want to know how this system looks, I've made a short video ( ) describing the one we build in the book. If you're curious, you can read the first 30 pages of the book, including the whole table of content there. The goal is not to impose a particular workflow I tried to explain every single shell command and piece of configuration for the readers to be able to shape their systems to their own needs. This system is based on Arch Linux, i3, Neovim, Zsh, and tmux. I've spent hundreds of hours on it, and now I'm really proud to finally release Building Your Mouseless Development Environment, where I explain in detail how to build a similar system to the one I use every day. Fortunately, I found a temporary place to live where I decided to write this book. An idea popped up in my mind: what about writing a book to pass on all the knowledge I had about this kind of mouseless development environment? What about enabling every developer to build their own system if they wanted to?Īfter shortening a trip in Asia beginning of 2020 because of Covid-19, I came back in Berlin without any job or even a flat, only some clothes and my old Lenovo x220. I had the feeling that I was more efficient with it, but more importantly I really enjoyed using it.įast-forward 2 years ago. From there, I built my system step by step, configured it as I wanted, according to my own needs. They are very good developers, so at the end they convinced me to look at them. My colleagues were pushing me to try the tools they were already using for years. What's the point using less of the mouse? Such a waste of time!"
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |