Less Ties With A Machine - Desktop Customization & Workflow
venam
(21-04-2018, 04:51 AM)josuah Wrote: 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.

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. :P
This could be a nice additional idea. Same as containerization and the likes too.
z3bra
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 ^^
venam
(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.
twee
(15-03-2020, 05:56 AM)venam Wrote:
(14-03-2020, 09:00 PM)z3bra Wrote: I'm digging back this thread
Another 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?
neeasade
> 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
twee
(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.
venam
(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.
z3bra
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 ☺
neeasade
@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.
twee
(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...




Members  |  Stats  |  Night Mode