Sorry but the cognitive load for this shell is just too darn high. I understand the power, I even get close to grok'ing the 'why', but I just don't see how I can intuit all the various features from the app. Do I need to spend a few hours doing a tutorial first? If so: forget it. I don't have time to do that, not for a shell, no matter how fancy it is .. however, if there is a neat and easy and fast way to learn these powerful features built-in, I'll give it a chance. As it stands though, the video just makes me glaze over about 1/5th of the way into it .. I'm impressed by the awesome power, but the load is just too high.
Xiki: An amazing shell
111–120 of 130 posts
Re: Xiki: An amazing shell
#112These alternative shells always get me really excited, until I try them out. Then the drawbacks become immediately and very painfully obvious: - Some are extremely slow, especially those that rely on complete webservers / node.js / whatever as a backend - Memory-hungry. I've got an average of about 30 terminals open at all times. 50 Mb per terminal really is a bit too much. 10 Mb is the upper limit on what a single t…
TMUX is a thing. People should really be using it for this type of workflow considering you can set up environments that don't necessarily have to be running all the time for other projects. This seems far more like a self-inflicted problem than anything.
It is a thing, but I find that having separate desktops ("spaces" in OSX terminology) for different tasks helps me context switch back to the task quicker. I keep different desktops for different tasks, each with their own terminal running. Each terminal may have several tabs opens. When it's time to switch to that task, I switch to that desktop. When that task is completely done, I just close everything and remove the desktop.
Keeping this all in my head - even remembering how many shells I had open to do what - takes more thinking and effort than I want it to. It is far easier for me to just say, "This is where all the stuff for X goes" and physically isolate it from everything for Y and Z. And when I go back to it, it's all where I left it. I find this a much easier workflow.
Re: Xiki: An amazing shell
#113Earlier quoted context omitted.
> when I was supposed to be doing my job No negotiating your way out of that. I know lots of people have done this type of thing at work, but I guarantee you he didn't have anything in his employment agreement that said "If I dick around instead of working and get paid for it like I was working, everything is fine, don't even worry about it." That's a fire-able offense for any sane employer that doesn't have a 20% ti…
Well I know I negotiate for the right to keep developing my own projects. Also, I work remote, and to me -- time is fungible -- I work nights/weekends etc. So if I work on a fun project 'during the workday' it is still mine, didn't become my employers suddenly, I just have to make up the worktime.
That's a major advantage to WFH. Just don't use company equipment when you do it.
Re: Xiki: An amazing shell
#114Earlier quoted context omitted.
TMUX is a thing. People should really be using it for this type of workflow considering you can set up environments that don't necessarily have to be running all the time for other projects. This seems far more like a self-inflicted problem than anything.
It is a thing, but I find that having separate desktops ("spaces" in OSX terminology) for different tasks helps me context switch back to the task quicker. I keep different desktops for different tasks, each with their own terminal running. Each terminal may have several tabs opens. When it's time to switch to that task, I switch to that desktop. When that task is completely done, I just close everything and remove t…
That sounds a lot like my workflow actually.
You can still actually use tmux with it, with one session per workflow ('^b $' can name the session from inside it).
I found it useful, especially with Clojure and vim. The splits are nice everywhere, and it's way better to be in the habit of opening a tmux/screen when sshing.
That workflow is also why I hate OSX updates that force a reboot, which piles all the terminal and Chrome windows in one desktop. And then it's just an update for RAW camera files or something that I don't care about, but it nags me every day. /rant
Re: Xiki: An amazing shell
#115Earlier quoted context omitted.
Wow, an average of 30 terminals at all times? Just out of curiosity... what for exactly? Real-time monitoring?
I mean, why do you have 30 tabs open at all times? You move on to something else, forget your tab was open, and go through at the end of the week and clean them all out.
You move on to something else, forget your tab was open, and go through at the end of the week and clean them all out.
No, that's what you do, and have extrapolated it to be what everyone does.
I use tree style tabs and mtputty, I leave open the things I use a lot and/or am focused on today. I find that I return to already open things enough that it's works for me. Re-opening programs and re-navigating to the same things I always use them for isn't a grand inconvenience or anything, but I do it for our software that uses floating licenses and it is annoying in my workflow.
Re: Xiki: An amazing shell
#116Earlier quoted context omitted.
You can go a long way with bash; it's worth learning because it lets you glue tools written in different "real" languages together very easily, as long as they all talk text. There aren't many other languages specifically designed for process control, orchestration and piping. I don't like fish because it has almost no features, compared with bash.
I've never understood why anyone would inflict oneself with bash scripting. If you really need something portable you should use standard /bin/sh anyway since bash is not installed by default everywhere (I believe many linux distros don't even ship with bash anymore, but a lightweight clone called "dash"?). And if you don't care about portability out of the box, why not use... Well basically anything else? Perl, pyth…
I don't know, I feel like POpen and friends in python just aren't as nice as doing 'thing-one | thing-two' kinda stuff, with some ifs, and some variables.
Re: Xiki: An amazing shell
#117Earlier quoted context omitted.
It is a thing, but I find that having separate desktops ("spaces" in OSX terminology) for different tasks helps me context switch back to the task quicker. I keep different desktops for different tasks, each with their own terminal running. Each terminal may have several tabs opens. When it's time to switch to that task, I switch to that desktop. When that task is completely done, I just close everything and remove t…
That sounds a lot like my workflow actually. You can still actually use tmux with it, with one session per workflow ('^b $' can name the session from inside it). I found it useful, especially with Clojure and vim. The splits are nice everywhere, and it's way better to be in the habit of opening a tmux/screen when sshing. That workflow is also why I hate OSX updates that force a reboot, which piles all the terminal an…
I still use screen remotely. This workflow is for the Mac in front of me. A lot of the terminals I have locally are associated with a screen session remotely. But keeping the local sessions open, active and logically grouped helps me remember what I was doing, and need to do.
Re: Xiki: An amazing shell
#118Most recent discussion here: https://news.ycombinator.com/item?id=7869246, and previously here: https://news.ycombinator.com/item?id=4512928.
Re: Xiki: An amazing shell
#119Holy freaking crap that's amazing. I love how the video all of the sudden starts to show 9000 features/ways it can be used. Looks like the paradigm adapts well to many different common workflows. It's really great to see someone really thinking from scratch about the shell -- something that very rarely goes through any meaningful changes like this. I hope this project goes far and becomes the new default.
Actually, that's exactly where the video lost me. A few additional shell capabilities? I'm interested -- cool!
But throw in a database editor and a million other unrelated-to-the-shell features? I've been down that road before, and it's a maintenance nightmare. Unless this project has huge community backing, it seems inevitable that the development resources will be stretched too thin. Then it won't work on my next computer and the bug report will sit in the queue for months while I return to bash. I don't think I want to play this game.
Re: Xiki: An amazing shell
#120> “Originally I created Xiki for my own use,” said Muth. “When I was supposed to be doing my boring job as a software dev at banks and insurance companies in Ohio 13 years ago, I started making this thing that let me run commands and navigate files directly from my notes. Ever since then I’ve found myself unable to resist working on it. I use it for everything.” Isn't this a bit concerning? It sounds like this was cr…
I don't like to sound derogatory, but xiki would have to turn into a multi million dollar business before insurance or bank companies would consider any legal action.
"but xiki would have to turn into a multi million dollar business before insurance or bank companies would consider any legal action."
Or until they step on the wrong foot, or rub some executive the wrong way.
It's murky water and just because in most situations it'll be "okay", doesn't mean we shouldn't worry about it from the start.