Less Ties With A Machine - Desktop Customization & Workflow
Users browsing this thread: 2 Guest(s)
|
|||
(This is part of the podcast discussion extension)
Link of the recording [ https://raw.githubusercontent.com/nixers...-02-19.mp3 http://podcast.nixers.net/feed/download....02-191.mp3 ] Hello fellow nixers, This thread is a discussion regarding new ways to think and work with a machine, tips and practices. I'm currently in the process of switching my main work machine because of the deprecation of 686 on Arch. Xero mentioned during the last podcast that one of his coworker reached a sort of workflow that is un-tied with the machine, dynamically setting up his custom environment at every boot. I'm not really looking for that exact setup but for something lighter, at least on the brain for possible future changes. The last few days I've thought of all the ways I could list what I wanted to transfer on my new box, what I wanted to retain from it and what software to help me manage this in the future. I've thought of dot file keepers like stow for the configuration. I've thought of ricerous, just to guide me through the installs. I've went back through my definition of minimalism to realize what I truly needed. I've thought of creating a well ordered home directory. I've thought of easy backups. I reviewed this thread about managing multiple machines. I've thought about keeping track of my things. All those ideas merge somewhere along of the lines of "less ties", "less worries", "better and lighter workflow". What are your thoughts on this fuzzy subject? If you want to contribute check this thread. Music: everlong (instumental acoustic) by cassidy orth |
|||
|
|||
I look forward to seeing what comes of this, venam.
|
|||
|
|||
I love that you can integrate everything with dmenu, here are some examples
Code: # Show battery status in dmenu Code: # Some scripts online And all you need is bind shortcut keys using xbindkeys I'm using dwm, dmenu & st so this is the kind of setup/workflow that works well for me |
|||
|
|||
I've recorded an episode of the podcast related to this topic:
Link of the recording [ https://raw.githubusercontent.com/nixers...-02-19.mp3 http://podcast.nixers.net/feed/download....02-191.mp3 ] Refer to the original post for more info. |
|||
|
|||
That's a topic I'm more and more concerned about everyday. I'v been working it for the past year as I had to reinstall different machines of mine multiple times, be it a server, phone, or desktop.
The first step toward it (and the most consequent one) was to learn how to NOT customize softwares. If you dont have any dotfike, then you dont need to manage them. It doesn't sound like rocket science, but its actually helpful. When you login to a virgin system, all you need to do is installing the software you need, and you're good to go! By using default configs, you also spend less time configuring things and more time using them. Another point I'm still working on is the persistence of data accross installs. This can be done using things like NFS. But I dont have something 100% working yet. This also include deployment of new SSH keys and password managers, so this point is a bit touchy. And last, but not least: Deciding what I want after the reinstall. I'm still not 100% satisfied with all the distros out there, so each install brings the question on the table (i currently run 6 different OS across 8 machines) |
|||
|
|||
I came up with a solution I'm going to try for this.
Basically, i'm going to set up a server on my desktop, serving up many things - one of which is a PXE server I'll then have my main work machines, two thinkpads as diskless clients, using their onboard SSD's as cache; and serving up a shared home directory to each machine. It seems that this is possible to do, coming from such things as http://wiki.ltsp.org/wiki/Concepts I'll keep this updated as things change, but i'm planning on creating a small builld chain and config to generate the images for a specific type of device. I want to have the ability to do musl or glibc on boot on x86, or start up on a Pi, and this way it should be doable. |
|||
|
|||
(02-03-2017, 03:45 AM)Halfwit Wrote: The first step toward it (and the most consequent one) was to learn how to NOT customize softwares.I've understated this many times. It's hard to find the right balance between vanilla or customized software. For example, the advantage of using the default keybinds in a software means that wherever that software is installed you'll directly know how to interact with it without installing your own configs. |
|||
|
|||
(03-03-2017, 02:40 AM)venam Wrote: I've understated this many times. And my law for this is to only customize not-so-common software, software i'd only use on my computer. That's the case of mutt, for example, i'm not checking email on every remote i log. Even after this i try to keep the changes to a minimun (at least when it comes to keybinds) on my personal computer.
argonaut · musician · developer · writer · https://www.betoissues.com
|
|||
|
|||
Finally transcripted this one:
Let's bring back this topic of discussion, it was so interesting to hear about all the ideas the community could come up with. |
|||
|
|||
Thank you for these podcasts!
(18-04-2018, 11:22 AM)venam Wrote: I guess the best way, first way I can think of, to have nothing as a Thin client and then a server which gives all the environment (SSH, X11 forwarding, drawterm... :P). Then you need a good connection, but that is a great deal of device-independence! Oops, but what about ties with the server which powers it? Then the question comes again... (18-04-2018, 11:22 AM)venam Wrote: But the real disadvantage now is that usually a lot of binaries are There could be a /arch/amd64 /arch/i386 /arch/armhf... and then an export PATH=$PATH:/arch/$(uname -m) (18-04-2018, 11:22 AM)venam Wrote: backups No "backups". More like duplication, mirroring... Git is good at this, and I keep my e-mail safe like that. Git only store incremental changes, and in case you mess up a repository, you can `git init` a new one, move the index/pack/objects files. After all, with the maildir format, every mail is a text files, so git works very well. (18-04-2018, 11:22 AM)venam Wrote: What to backup, how to backup, and how to deploy it. Every time I use a new machine, I git clone everything on it. That acts as a backup. Even if I wanted to delete my own data forever (password on dotfiles...), I'd have a hard time doing so. Even with a hammer. :P Text files are not very big, so that is possible. (18-04-2018, 11:22 AM)venam Wrote: By second memory I mean an extension of your thoughts, thinking, and Interesting. Let’s list all the places where I keep my memories as a personal example: I'm thinking about making a wiki or notetaking system. Then I can forget something, it would be easily available. It seems that I mostly remember the path to access to things in internet than making real bookmarks. But then if the path changes, I'm screwed. Another approach is instead of storing links to documents, storing the actual document. For whatever .ps, .pdf, .txt, it's easy. Then you can probably do a full text search on your own machine. :P (18-04-2018, 11:22 AM)venam Wrote: No, there’s nothing wrong with having your machine helping you remember Books have had this role before hard drives. Oh, so this is my grand parents like their bookshelf this much? And the mere fact of saying "I want to remember this so I put it in a safe place" make me remember that thing more than any other with no effort. Maybe it acts as a signal to my brain to: "Store this in a safe place" wherease "I'll remember it later" makes my memory filter it out... (18-04-2018, 11:22 AM)venam Wrote: list of whatever you have installed My take on this is having a tiny (stupid) portable package manager that I can use on all distros (besides Windows and *maybe* plan9) and have a build recipe for all package I really care about (mail client, text editor, git, rsync, libressl...). They get installed in ~/.local/{bin,lib,share/man}. Pretty weird? But hey, it works and I can have packages for things that are rarely packaged (suckless tools). (18-04-2018, 11:22 AM)venam Wrote: So that means having everything in your home, having a transportable home. That might be taking things a little bit too far, as then you have configurations in /etc, /usr/local/etc, /var, /home/username, /home/git, /root... But I do this, hehe. (18-04-2018, 11:22 AM)venam Wrote: The script that sets everything up. AKA poor man's puppet. :P |
|||
|
|||
(21-04-2018, 04:51 AM)josuah Wrote: Interesting. This reminds me of three recent entries I've shared in the newsletter about this topic: Are we our tools: https://codewithoutrules.com/2018/03/23/...our-tools/ The Grand Analogy: https://www.edge.org/response-detail/25335 The extended mind: http://cognitivemedium.com/tat/index.html (21-04-2018, 04:51 AM)josuah Wrote: AKA poor man's puppet. :PThis could be a nice additional idea. Same as containerization and the likes too. |
|||
|
|||
I'm digging back this thread, as I recently decided to cleanup my workstation (running crux 3.4). I had 2 drives hanging around, doing nothing so I am doing an experiment:
- reinstall crux 3.5 from scratch, amd remounting /home from last install (hdd) - install openbsd 6.6 from scratch, and recreate my environment there (ssd) In the end, the environment should be somehow the same (same software installed, and dotfiles, if any), but the way to get there is totally different. I want to see how hard it is to recreate it from scratch on the openbsd drive, and how dirty my clean crux 3.5 system becomes when I recreate the environment arounf mmd an existing /home. Sonfar, both systems are up, and I boot in crux from now on. My "fresh" system is surprisingly useful out-of-the-box, because I started installng more and more software in ~/.local (like st, wmutils, sxhkd, ...) this has the nice benefit of feeling right at home on a new install ! Pretty cool so far. however, many software didn't work right away because librairies where missing. I should compile them statically perhaps ;) I can't wait till I rebuild my workflow on openbsd now, to see how tedious it is. That's gonna be complex, as my /home currently lives on an LVM partition, so I don't have any way to read it while on openbsd. And Linux cannot mount openbsd UFS in rw either.... Good times ahead ^^ |
|||
|
|||
(14-03-2020, 09:00 PM)z3bra Wrote: I'm digging back this thread I've had a similar epiphany. Since writing about the topic, digging into UX/UI, and anything rotating around it, I've taken a different approach to computing. A book I've recently read goes a long way in explaining it, it's called the design of everyday things. It's premise is that if you're not able to use a tool don't blame yourself, blame the tool. Another one is about asking yourself why would you have to learn different behavior to do the same thing with different tools. So, with this in mind, I've settled on a vanilla reproducible setup that has the less friction possible between me wanting to do something and it happening. I got a text file with the list of everything that was every installed and customized on the system, a script to rebuild the symbolic links for configurations if ever needed. And that's mostly it. I've taken to heart the habit of questioning a tool once I experience a discrepancy or lag between what I want to do and what's actually going on. There's a similar exercise I do with my programming environment IDEs called a Code Kata. |
|||
|
|||
(15-03-2020, 05:56 AM)venam Wrote:(14-03-2020, 09:00 PM)z3bra Wrote: I'm digging back this threadAnother one is about asking yourself why would you have to learn different behavior to do the same thing with different tools. Maybe I'm slightly missing the point, but I find all these arguments slightly unfair. The ultimate goal of both a cello and a trumpet is to make music, but that doesn't mean that either should be blamed for the fact that they approach that goal in a different way. Should a kazoo be the only instrument, because it is the only one that one can immediately play a tune on? It can also be hard to know what is good design and what is learnt: I remember listening to some recordings of Microsoft testing the double-click system, which didn't seem to come at all naturally to some people. It might be that I'm beating a strawman, in which case I apologise. Anyway, my personal way of partially solving the situation is mostly to push as much as possible into email: I keep my notes in email, emails in email (but not a full archive, just things I care about), news in email, and appointments are mailed to me. Wherever I am, it's easy to access and I can use various different interfaces. This requires a collection of shell scripts, which is not ideal, but my primary problem at the moment that I'm trying to solve is avoiding external services and minimising the need for internet connectivity; it happens that lessening ties with any particular machine has partially arisen from that. Tangentially, I've been meaning to read the design of everyday things. Is it worth it? |
|||
|
|||
> Tangentially, I've been meaning to read the design of everyday things. Is it worth it?
It's a great read -- helped me change my perspective on how I interact with tools and interfaces in my day to day. WRT this thread, I moved most of my ties into emacs, so I just need a platform that can lift me into my elisp playground. I suppose that might be an approach of complexity, embrace big meta tools that let me do what I like (I'm a nix/nixos user as well) -- my line of thinking is that I'll be happy with the right "big tools" that let me create what I want -- I think from a "ties to a machine" POV this actually simplifies things, since you have fewer targets/tools that enable tools by owning more of the environment |
|||
|
|||
(16-03-2020, 04:25 PM)neeasade Wrote: I moved most of my ties into emacs, so I just need a platform that can lift me into my elisp playground. That's pretty much what I had for the last six months or so; a single literate org configuration, for all my tools, and some bootstrapping scripts to tangle it. The configuration was sorted by category, so I had a mail section which held the dotfiles for msmtp, mpop, mairix, rmail, and the parts of the guix profile necessary to install those programs, an interface section for xresources, emacs theme, and the gui lobotomisation, and so on. I found this very beneficial in working out what was actually necessary for each way I interacted with the computer and how they linked together. I didn't like using features written exclusively as part as Emacs though (org mode for example), preferring to use tools which Emacs was simply an interface for (such as shell or rmail), and I've been moving away from Emacs because of this. I've started tentative designs for something similar to Acme but keyboard-oriented to fill this niche for me but ultimately I'm not sure what I want. But whatever happens, whatever I think idealistically, you can guarantee that I'm going to back on Emacs in a month or so, because I'm addicted and can't get away from it. |
|||
|
|||
(16-03-2020, 02:08 PM)twee Wrote: Maybe I'm slightly missing the point, but I find all these arguments slightly unfair. The ultimate goal of both a cello and a trumpet is to make music, but that doesn't mean that either should be blamed for the fact that they approach that goal in a different way. Instruments are not "everyday things", so it's a bit of a strawman. Maybe a better way to explain it would be to say that there needs to be less friction, less disconnection, with the things you don't really want to have to think about. They need to happen without a thought so that you can get on and do what is actually of importance to you, be it playing the trombone or the kazoo. That's why re-learning is a bother because it takes time away from what you really want to do. Standards are of tremendous help but customization can be too if it fits your special workflow. I think the metaphor of the extended mind and the grand analogy that I linked previously are great. |
|||
|
|||
I think I get what venam means here: switching tools takes you away from your original goal. When I want to take notes, I don't wanna bother with learning how to save (:w ? c-x c-s ? c-w ?), so if all editors had a common way to do it, that'd be easier to switch tools.
I don't particularly agree with that though, as this would prevent having good idioms like vi's mosal edition, which is just so different from traditional edition. It's aboit choice after all, so the best way to lessen ties woth a machine is to provide multiple alternatives. For example, ubuntu has both vi and nano by default. Openbsd integrated mg specially for that: providesimple alternatives on the base system. I personally think that to lessen the burden of "learning tools", the best solution is to provide a common intrrface to them, so you are not surprised when learning the tool. OpenBSD does it right, as all the configuration format for their tools are STRICTLY the same. Take nsd or httpd, both will use the same keywords to listen on an interface. They also all have great manpages with a good documentation, organized in the same way. If their was a common ground for all unix tools, that would be much easier to swap systems, I guarantee it ! Now until we get that, I'll keep installing stuff statically to ~/.local so I can easily "migrate" from one system to another ☺ |
|||
|
|||
@z3bra hear hear.
@twee FWIW I've definitely gone the other direction, folding {git,shell,notes,irc,dev,dmenu,...} into emacs. For me the benefit is the blended experience between everything I pull in, going for the extended feel that @venam has mentioned. |
|||
|
|||
(18-03-2020, 11:14 AM)neeasade Wrote: I've definitely gone the other direction, folding {git,shell,notes,irc,dev,dmenu,...} into emacs. For me the benefit is the blended experience between everything I pull in This is why I'm currently staying with Emacs, but in the long run I don't feel like emacs entirely fits the model I want. I like Emacs frontends to stuff currently because of the uniformity, but want to be able to also not use Emacs if I so choose, if that makes sense. (18-03-2020, 05:24 AM)venam Wrote: Instruments are not "everyday things", so it's a bit of a strawman. My apologies, I thought that might be the case, but it wasn't the intention, I was genuinely confused. (18-03-2020, 05:24 AM)venam Wrote: That's why re-learning is a bother because it takes time away from what you really want to do. I think that this is always going to be something of a problem with computers in their current incarnation, because the metaphors are imperfect and different people prefer different interpretations of them. At the start of the year I started writing my notes on real life paper after a long time using various plain-text systems, because for what I want it's the best way. Overall I never really re-searched them a whole lot, and I've had a lot of fun experimenting with indexing systems. Yes, it's not automated, but I think that having to do it manually has actually helped me to write better notes in the process. That's probably a very different kind of less ties with a machine than you were thinking of, but it's working for me :P (18-03-2020, 05:56 AM)z3bra Wrote: if all editors had a common way to do it, that'd be easier to switch tools. I don't particularly agree with that... I agree, because then there'd also be less point to switch tools. The CUA standard is pretty much this, and while it's great to be able to use Pages or Word or whatever and know what keys do, like you say the power of individual applications is lost. (18-03-2020, 05:56 AM)z3bra Wrote: the best solution is to provide a common intrrface to them, so you are not surprised when learning the tool. Yep, as I mentioned to @neeasade this is why I'm currently using Emacs still and why I'm so interested in Acme. (18-03-2020, 05:56 AM)z3bra Wrote: OpenBSD does it right OpenBSD is definitely my favourite unixy system, unfortunately the battery life was so bad on my laptop that I had to move away :( (18-03-2020, 05:56 AM)z3bra Wrote: Now until we get that, I'll keep installing stuff statically to ~/.local so I can easily "migrate" from one system to another ☺ I used to do a similar thing, but now I use Emacs... |
|||
|
|||
If it's a short gig you can carry a flash drive with your preferred setup.
If it's a long term employment you can write a bootstrapping script to install and configure your working env. For servers default vim is almost enough, most of the time you edit config files or looking at logs. If it's an employer which requires: Windows 10, .NET, corporate spyware preinstalled, no Linux, code in VSCode only (unified environments, group policies, you are not an Admin), you know what to do in this case, calm down, breathe, walk away without explanation, there are nothing to fix here. |
|||
|
|||
I feel that NixOS really provides a solution to this.
The fact that system iis "tied to" a machine is actually because the actual behavior of the system is distributed and hidden in the file system, through various small configs, command calls, etc. If every detail of the system is "reachable" from somewhere, or even better, they are stored centrally somewhere, then the system naturally becomes portable. NixOS tries to put everything in the config file of NixOS itself, in this way, once you have the NixOS config file, you have your whole system. There is also home-manager, which manages user dot files as well. Another thing I really like about NixOS is that its package system is so flexible. The fact that NixOS uses a programming language to describe packages implies that you can customize the build option, etc. of any package, *while keeping it completely managed by the package manager*. Which makes tweaked packages much easier to manage and port. |
|||
|
|||
(09-12-2020, 12:30 AM)Guest0x0 Wrote: I feel that NixOS really provides a solution to this. Right now I mostly just use the Nix package manager on Arch to provide Haskell, but all of this sounds very nice. I'll keep this in mind the next time I'm reinstalling Linux. |
|||
|
|||
NixOS works just like GuixSD in these regards. Still, you’re tied to this very configuration format then.
-- <mort> choosing a terrible license just to be spiteful towards others is possibly the most tux0r thing I've ever seen |
|||
|
|||
(09-12-2020, 06:22 AM)jkl Wrote: NixOS works just like GuixSD in these regards. Still, you’re tied to this very configuration format then.Well, historically NixOS comes earlier. But the two systems are very similar, and people from the two are close, too. So to some extent they are the same under the context here. Certainly you are now tied to the very distro and config format, but people usually don’t expect a completely identical system and/or small amount of work, while they do expect so when switching to another hardware. People switching distro are seeking changes, so that case is not the concern of this thread, I guess. |
|||
|
|||
No one expects you to learn yet another programming language just to switch distribution. If you know python,bash, and somewhat of C you are good to go for any linux distro, except those two, where they push you to learn lisp dialect. It isn't for everybody.
|
|||
|
|||
(09-12-2020, 07:39 AM)stratex Wrote: No one expects you to learn yet another programming language just to switch distribution. If you know python,bash, and somewhat of C you are good to go for any linux distro, except those two, where they push you to learn lisp dialect. It isn't for everybody. Nix is configured with the Nix language, inspired by Haskell and not Lisp. The distros are different in that regard. Judging from the configuration examples of Nix, it looks easy enough to manage a config like that even if you're not proficient in Haskell. These languages were also chosen for a reason: They provide more power and flexibility. If we continue to use shell, C and Python forever, we'll never advance the *nix landscape. I think the fact that they stray from the usual format is good because it breeds innovation. I do understand how you feel though. As an example, Rust uses TOML for Cargo configuration which is basically the only place that configuration language is used. |
|||
|
|||
I'm surprised that the only tool for automated configurations mentioned (very quiclky) in that thread seems to be puppet... and is only mentioned as "the poor man's puppet".
I am personally quite interested in that topic, which is why I am (slowly) building my own debian installer, of which having an acceptable PXE configuration is only the 1st step (it's not good enough for me), and I have found various tools to achieve that goal, that I would split in 2 categories, each having different contraints: * agent-based tools, which usually derive from cfengine, which agent is written in C (puppet being one of them). They are (probably) great when you are actually admin of the targets, and have the right to install stuff. They (should) allow a system to auto-repair or to inform it's administrators about the derive from the repository from which their configuration is derived * independent tools, which seems to all be some fashion of interpreted language. I know more about rexify, which is written in perl, there are some in bourne script, but the most well known nowadays seems to be written in python. I don't really think a package manager can do the trick here, not alone at least, you'd need some way to trigger it, and a cron tab for updates will just break stuff at a moment or another, except if you own your repo and validate the packages you put there, but that's a lot of work |
|||
|
|||
I surely hope that Python will fall into obscurity soon. It was an awful idea to overrun the Perl ecosystem with a teaching language as a vehicle. The victims are yet to be identified.
TOML predates the rise of Rust though. -- <mort> choosing a terrible license just to be spiteful towards others is possibly the most tux0r thing I've ever seen |
|||
|
|||
Alright, one of my favorite thread.
I've been trying out nix the past few days and as the people in this thread have noted, it's indeed a wonderful way to have less ties with a machine. Do you have new tricks or ideas related to that topic? Maybe things related to nix or nixOS too? |
|||