A personal pet peeve is when people refer to having lots of features as "bloat." It's generally very nice to have lots of features all in one place without having to do things manually, or find somebody's potentially-sketchy plugin/app.
My test for "bloat" –
1. Has the project grown so large that it's starting to run into real-world performance issues? (I can't imagine this could be the case with even the largest of shell configurations except on very low-end embedded devices).
2. Has the project grown so large that bugs are popping up faster than the developers can do maintenance? Is there no or only one person who can read and understand the entire codebase? (AFAIK, no and no).
3. Are there many undocumented/poorly-documented features? Are there features that are both undocumented/poorly-documented and dangerous? Are there many deprecated or outdated features that have yet to be removed? (AFAIK, no, no, no).
4. Are there many features that both duplicate and do not improve on functionality found elsewhere? (Debatable and mostly subjective).
> Has the project grown so large that it's starting to run into real-world performance issues?
oh-my-zsh is noticeably slower than prezto on multiple 'high end' machines I have with the same 'capabilities', i.e. plugins that provide the same feature set on both.
Noticeably slower at doing what? I haven't noticed any issue, but I'm maybe a bit naive; I rarely use the shell for anything that isn't near-instantaneous and isn't just waiting for some other process to complete (e.g. curl, compilers). For more complicated stuff I usually write something in a scripting language.
Heh. I remember when zsh first got its fancy completion system, compinit would add so long to zsh startup on the dinky little machines of the day that people literally started adding progress bars and the like to their zshrc.
I stuck with the old-style completion for a long time.
Hm. I'll take a look at Prezto then. For me a new shell takes approx .5 seconds and tab completion is instant, but I'm on a 2014 MacBook Pro and use iTerm2 instead of the native terminal (not sure if that makes any difference). I don't recall it being any worse on the 2012 MacBook Air + iTerm2 I had previously, but maybe I just didn't know any better.
No it's noticeable. There is no hesitation in the responses. I recently switched because I setup something for Emacs which needed to run a shell on start up and I noticed just how slow it was because Emacs is not Async and would hang for that shell to boot to run a simple command.
On a side note, while prezto is faster, another culprit of slowness is nvm which when I disabled it made the terminal much faster to load.
Occasionally just opening the shell can be slow with oh-my-zsh. It can be a bit annoying (especially if you need a few more plugins). However I have not really noticed as much of a slowdown lately so perhaps it has been improved - I haven't really tested it, this is just my own perception.
I don't think there's any non-trivial software that completely unambiguously passes all my tests (and a lot depends on how strictly one interprets "is more than one person able to read and understand the entire codebase" – I'd allow the proviso that the reader has access to the documentation, tests and commit history, and that inherently high-complexity software like an operating system can be broken down into its components); the question is more whether it clearly fails one.[0]
Software that's prone to be subject to (arguably!) unfair charges of bloat includes old standbys that have lately been challenged by upstarts (e.g. jQuery, Apache), or that developers already dislike for reasons other than quality (e.g. Oracle, Microsoft products).
---
[0] I'll demonstrate by applying my tests as I see it to everyone's favorite poster child for bloat – the C++ programming language.
Has the project grown so large that it's starting to run into real-world performance issues?
Compilers have, and how. The binaries they produce mostly haven't, although certain language features, particularly amongst those that didn't come from C, compare unfavorably to their equivalents in "slower" languages. And the language has become complex enough as to be pretty slow on the meta level of writing or learning it.
I'll say ambiguous, leaning fail.
Has the project grown so large that bugs are popping up faster than the developers can do maintenance?
Well, the invalid pointer access meta-bug has been around for (CURRENT_YEAR - 1972) years...
Personal view is it doesn't matter if the reason for failing this test is because the maintainers place artificial restrictions on their ability to fix stuff, so I'd say fail on this one, although others might disagree.
Is there no or only one person who can read and understand the entire codebase?
Hard to define in this case. Is it the standard? The most popular compiler? Every popular compiler?
I'll say ambiguous, leaning pass. But few programming languages would pass this completely unambiguously.
Are there many undocumented/poorly-documented features?
"undefined behavior"
FAIL
Are there features that are both undocumented/poorly-documented and dangerous?
"undefined behavior"
FAIL
Are there many deprecated or outdated features that have yet to be removed?
FFFFF AAAAA I L !!
F A A I L !!
FFFF AAAAA I L !!
F A A I L
F A A I LLLL !!
Are there many features that both duplicate and do not improve on functionality found elsewhere?
Could someone please explain to me the attraction in using Oh My Zsh (and similar)? It seems strange to me to use others' configs.
Over time I've customized my bash config and have all the information I want in my prompt. If I ever switched to zsh I'd just learn how to translate what I have in bash. Why would I want to start with someone's big framework for configuration?
You answered your own question when you said "over time I've customized". The appeal of oh-my-zsh and others is that it removes the "over time" part of the equation.
It's meant to give you a lot of sensible (think like vim-sensible) defaults as well as the settings that make it feel more like bash yet show the awesome features of zsh.
A lot of people don't like to configure shells. omz gives them a head start and a source of inspiration into features they might not know.
I've never been much of a tools guy. I generally use what the default configuration is for whatever tool I use. It's just never been particularly important to me (and I don't feel like it's made even a small difference in my productivity as a programmer).
Projects like oh-my-zsh are nice because they provide a much richer default that lazy folks like me can use without ever having to know or care about how to actually configure a shell because the alternative is that I just won't do it. I'm not going to take the time to learn about the universe of configuration options. When I'm exposed to a feature it has to be really useful before I'm going to bother to learn about how to configure it. So plugins and the like are huge, they allow me to tailor my environment to the actual work I do with rich functionality that I otherwise wouldn't have.
> Projects like oh-my-zsh are nice because they provide a much richer default that lazy folks like me can use without ever having to know or care about how to actually configure a shell because the alternative is that I just won't do it.
Thanks for giving me a different perspective. For me, it bugs me to not know what's built-in vs what's configuration. For example, I recently discovered that option+arrow key to skip back/forward words was an OSX Terminal feature when it didn't work in iTerm2. So I configured it to work how I wanted in my .inputrc and now it should work everywhere.
Starting with the defaults and changing things as you get an itch to scratch seems like a better way to learn long-term, but I can see just wanting use someone's template and be done with it. I guess it's the difference between frameworks and libraries, and between people who use someone's addon pack in World of Warcraft vs just using a few addons and designing their own UI.
Actually ⌥← / ⌥→ to move by words is a feature built into the Cocoa text system. It will work in any standard text box in any OS X app. You can also use ⌥⌫ to delete by words.
Well, yes, thanks. So it arguably should have worked in iTerm2 to start with.
In any case, now with the same configuration it'll even work on Linux (I also configured ctrl+left and right to work the same for non-⌥-having keyboards).
And my point remains the same, that I learned what was OSX, what was bash, and what was readline, more about how to configure readline, that you can 'cat' with no arguments and type things to see their escape codes (which is how I got ^[^[[C and ^[^[[D as the codes for ⌥← / ⌥→), that \e is short for the escape part ^[ (though I still don't understand how escape codes work everywhere, more learning to do). All because something didn't work how I wanted. Of course it'd be nice if readline had better defaults too :)
Could you share the relevant part of your config and some rough instructions on how to set it up? I just got my first mac a few days ago and I'm tearing my hair out here.
I think oh-my-zsh is the best of both worlds. If you don't like to fiddle, it has sensible defaults and if you do, you can write and load your own plugins and themes easily. There is a rich collection of plugins and themes that you can enable by choice - and customize as desired. I've been known to fiddle with things like this and I've learned tons about what's possible and how to customize my shell by looking at the oh-my-zsh source.
Worth mentioning the fish shell [1] which takes a different approach and tries to "work out of the box" with things most people want.
I'm with you. I use the default shell (bash for linux) and don't change it much. I might tweak the prompt a little and add a few aliases and environment variables but that's about the limit of it.
The main reason is that I tend to work on a lot of servers, and sticking with default settings gives me a consistent unsurprising environment on all of them.
It is possible to adapt fairly easily between different setups. I've got a fairly advanced zsh setup but do a lot of admin on a mix of Linux, Solaris and BSD where I have to put up with whatever the defaults are. I resisted vim for a long time for similar reasons: when doing admin, I often only had vi. When I finally took the plunge and learnt how to make effective use of vim-specific features I regretted not having done it long before. And I can still manage fine on a bare install of Solaris with vi.
We keep common profile configs for remote servers in our source code repository. It helps immensely having common aliases and stuff across multiple servers, from dev boxes to production ones.
I think the difference between software and configuration is a bit artificial. Whenever you install software, you are implicitly using someone else's config: the default. oh-my-zsh users are also using someone else's config, but it's better. What's the difference?
Edit: to clarify what I mean by the distinction being artificial, I don't see why you couldn't think of the kernel as someone else's configuration for your processor, or zsh itself as someone else's configuration for your terminal window.
I have a zsh configuration that I've built over time and thoroughly customised... on Linux. For mac, which I have only recently started using at work, I use oh-my-zsh since it takes all of the environmental differences guesswork out of getting set up again.
Because you can get ideas from other people. Then you can merge your customization with others and have the best of both worlds. I moved my bash customization to a personal oh-my-zsh theme & .zshrc and didn't look back.
I configured Zsh myself, but being new to it I found the omz configuration library very useful, both for inspiration and looking up how to do the things I want.
If you like oh-my-zsh you'll love https://fishshell.com/. The main difference I use is better command completion as you're typing, and you can complete by word with alt-f. And ruby like syntax.
for example (| is the cursor and everything after it is grey text)
>echo hello world
hello world
>echo |hello world # alt-f
>echo hello| world
Fish and oh-my-zsh both take about 5 seconds to init though. If you don't like that you should be using prezto (which is the fork he mentions in the article)
> Fish and oh-my-zsh both take about 5 seconds to init though. If you don't like that you should be using prezto (which is the fork he mentions in the article)
You must have a lot of expensive stuff crammed into your config.fish file, for me fish takes < 1 second to init.
A config.fish consisting of the line 'alias a=echo' repeated 200 times takes 3 seconds to start. No config file starts out in 50 ms. So my 200 aliases seem to be the culprit here. And to be fair my init time is actually a bit over 2 seconds.
As a Fish user since it's inception, I humbly disagree.
Oh-My-Fish[0] is the preferred and popular plugin framework for Fish. The guy behind Fisherman abused DMCA to discredit OMF, which was a pretty shady tactic for an open-source project.
> The guy behind Fisherman abused DMCA to discredit OMF
I am one of the guys behind Fisherman and I didn't abuse the DMCA to discredit OMF, on the contrary, I used it to have my name properly represented in their AUTHORS file.
Now, one thing I am accountable for is, spending days and weeks nurturing and improving the project when I was involved with it. I don't know where you get your facts from, but I urge you to pay a visit to the contributor graphs in the OMF GitHub page and see who's done what and how much.
> is the preferred and popular plugin framework for Fish.
I really want to use something like Fish (or at least try out a whole lot of not-bash, at least to force me to write /bin/sh compatible scripts) but because it's not installed by default I often don't get around to it. I really should go back to learning Ansible...
Regarding fish startup time I had a problem with fish taking forever before. Turned out my ~/.config/fish/fishd.<hostname> file had erroneously ballooned to many megabytes. This caused a very long startup time. It should typically be a few kilobytes.
I actually never looked inside! I deleted all of those files without looking in them. Only after my performance improved did I check my scrollback and notice it was huge :(
I used bash-it for a long time early on. I was intimidated by switching to the unfamiliar territory of zsh, but it's a no-brainer now and I'd struggle to live without its features that I have since taken for granted.
I heard of zsh back around 2012, lots of colleagues who I respected very highly were using it. But I just never could get behind the idea of using someone else's defaults. Even when I switched to Emacs, I hand-picked every line in my configs from looking at a bunch of people's configs and with a lot of random googling to solve things. Even though it took like 2 weeks of constant tweaking to get just right, I haven't touched it much in like the past 3 years or so, and I've been super productive ever since. So meh, seems to have worked out for me. But YMMV. Also, I use eshell (with some tweaks) almost exclusively now, as opposed to a "real" terminal with bash or fish or zsh (etc.)
> Even when I switched to Emacs, I hand-picked every line in my configs from looking at a bunch of people's configs and with a lot of random googling to solve things. Even though it took like 2 weeks of constant tweaking to get just right, I haven't touched it much in like the past 3 years or so, and I've been super productive ever since.
This. The key to using Emacs well is to start with something fairly basic. Whenever you find some behavior that annoys you, take a few minutes to figure out how to fix it once and for all in your config. After a few years you will end up with a giant mess of a config that makes Emacs behave almost exactly the way you want, which you can copy over to any machine where you do serious work. You will also be able to get basic work done in a vanilla `/usr/bin/emacs`.
FWIW, after several years of zsh, I've been mostly happy with a stock fish in a terminal. It's way less broken by default than either zsh or (ugh) eshell.
Many years ago when I switched to zsh I went through the manual and made the decision on every single option. I also went and made a semi-complex prompt that worked well for me.
I've been using basically that config ever since.
When I first started using zsh I went down the road of writing custom completion functions, but pretty quickly discovered that they just didn't pay off in the long run and stopped doing it. My shell absolutely doesn't take 5s+ to open up either, it's pretty much instantaneous.
In bad news, it appears Ubuntu no longer ships the manpages for zsh and instead ships info pages. Barf.
I've tried it a few times given it weeks or month long trials, and never really found a strong enough benefit over bash, especially when I'm always going to find bash on servers I deal with.
I actually find it valuable to nuke my bashrc customisations every few years and reevaluate. Assumptions and practices entrenched in those customisations can be anti-patterns or counterproductive.
There's a lot of shortcomings in bash. I wrote my zshrc by hand, and I didn't like the fact that most people use oh-my-zsh. For me, writing my own zshrc from scratch taught me the differences between bash and zsh (I ended up writing my own .git and .hg parsers because running the commands is too slow).
Aren't you already doing that when you load up a vanilla zsh? Its just that that "somebody else" was the guy that wrote the tool. In either case, you still will want to tweak it to get exactly what you want.
However, in one of the cases, the thing you start out with is 0 features, and an extra week of work doing the same thing that thousands of people have done exactly the same before you. Only after that do you get to making it really "custom"
The intro to this article is as much a caution of becoming dependant on non-standard tools, as it is a pitch for omzsh. If you can't sit down at a normal bash window and get shit done, your shortcuts are hurting you.
The same could be said about non-QWERTY keyboard layouts but I think the potential gains from using the best tools you can are so big that you'd have to be using shells where you're unable to customize a substantial amount to end up at a productivity deficit.
I find that I mostly use systems that I can make match my setup...
there are 2 parts here: know how to do basic things with what you normally have on a machine _and_ turbocharge your development machine to optimize your productivity.
I don't see a problem with any of those as long as you have a mental model of how the 'shortcuts' you've configured work.
git clone your customizations into an account that's not yours. There's a special hell for people who do that. I don't care if it's a shared account or you're a guest in their personal terminal. Special hell. ;-)
I always get caught up in bash's syntax quirks when trying to write loops on the commandline. I've gotten so used to zsh's easy loop syntax that I always have to stop and think before writing the bash one.
I had a wonderful year with dvorak and moved on for this exact reason. I also use boring old bash to get things done.
That said, if a tool gives you a net productivity boost, you should probably adopt it. I'm pretty sure I was working with Robby when he started down this road. (Hi Robby!)
Perhaps the fact that I have never (touch) typed using any layout but Dvorak helps explain why I generally stick to the defaults otherwise: having to twiddle each machine's settings before I can make productive use of it gets old in a hurry.
I like learning from other people sharing their config files, but my attitude towards oh-my-zsh is similar to that of the author's co-workers in that I don't want to install a bunch of customizations that I don't understand. I couldn't find a summary of what all oh-my-zsh is supposed to do and the source has grown too large for me to read it quickly. I guess I trust code I haven't read most the time I am using a computer but it feels wrong to me to allow my shell to auto-update customizations that I don't understand.
910 contributors, 191 issues, 516 pull requests, and his response is that "reviewing and approving pull requests is a nice-to-happen versus a need-to-happen." While I'm glad I am not in the position of maintaining that (or anything else important), that doesn't really speak well to the long-term prospects for the project. Clearly this is something that I and many others find very useful; It would be a shame to let it stagnate. The glib part of me would suggest either 'stepping up, or stepping down', but I can't really credibly offer solutions, I just am trying to point out a problem.
So you criticize the maintainer for their large pile of (unpaid) work in the queue, but aren't willing to help out?
If you're worried about the project stagnating, why don't you offer to donate some cash? Why not offer to help in whatever way you can, even if it's just triaging tickets?
Firstly, this isn't about me. I'm not the one who started this project, I don't have any stake in maintaining it, and I'm definitely not the only one to notice that the tickets are piling up. Frankly I thought it was widely known.[0][1]
As it happens, I am probably in the running for worst/poorest developer on HN, and that's using the term "developer" broadly. To the degree that I have any resources that aren't being put towards subsistence, I'm not sure I could help anyone with anything. It doesn't feel particularly good to have to explain that, especially since everyone on here seems to be in a vastly different social situation, but either way, I'd appreciate fewer personal reflections.
You could always fork it. It is MIT licensed after all.
Personally, I just built my own zsh config that solves my problems without all the framework mess. Its less than 150 lines + some related dot files for aliases, vim, etc.
Frankly, I'm not sure I'm up to that. I don't have much in-depth experience with this project, with the finer points of zsh, or with maintaining projects in general. I'm not entirely sure I could do a better job than nothing at all. However, even if I were more capable, I still don't think it's right to try to take over someone's project without some more clear sign that they are uninterested in continuing it.
Sounds like he needs some help. Maybe a linux kernel model is more apt? Have a few people helping and looking at PRs and approving them in just the areas that they are experts in.
Humm ...
I looked for the fun if no one spotted in any comment that there was a creepy feature the author likes.
Periodic automated arbitrary code execution from a remote source.
Here is a list of the stupid ideas that old coders warned from
- abritrary remote code execution [X] this, curl|bash
- too much dependencies [X] npm
- lack of specifications, staging [X] Agile
- non deterministic HW [X] Intel
- non deterministic software [X] llvm/gcc/AI
- Single point of failure [X] github/CA
- attack by majority on P2P [X] blockchain, bitcoin
- bigger sloc is more bugs [X] heavy frameworks
- using immature technologies [X] haskell
- bloatwares [X] angular
- private corp standardizing [X] QUIC & al, browser wars
- beware of information entropy [X] big data
- moving parts [X] the Cloud
- higher surface of vulnerability [X] IoT
- monopolies [X] google
- using private cie for infra [X] github is the new sourceforge
- putting half backed std in prod [X] IPv6
- lack of consistency [X] most nosql tech
- legal risk due to IP law [X] coding by copy/pasting
If I was an old coder still coding I would say we are very close to a singularity : the total lack of trust that could result in all this is simply customers reverting to fax, teletypes, snail mail... or going to court to ask for financial compensations.
If you need an expert to help you on this, I can help.
I've tried a number of times to switch to zsh, ostensibly for oh-my-zsh. My main issue is that bash is the default almost everywhere so it's more work to change it than it is to just be "happy enough" with Bash.
I used to work on a fairly underpowered ARM5 and I could feel the impact of most prompt customisations on the speed of the system, especially on initial login. That feeling is still there - mainly because I haven't found the right SD card for my Raspberry Pi.
To avoid this becoming a complete ramble - are there any advantages to switching to zsh as someone who's reasonably comfortable with bash? Hell, even OS X switched (and boy, t/csh was a shock when using FreeBSD).
This is a difficult question to answer. I switched a long time ago, when bash did not provide the kind of completions that zsh does. Nowadays bash is catching up.
Try these things in bash (with completions installed):
1. cd to a git repository and type "git [TAB]". Do you see a list of git-specific completions?
2. cd to a directory that has a makefile and type "make [TAB]" do you see a bunch of make targets?
3. cd to a directory that has some PDF files and some other files. Type "okular [TAB]" (or whatever you use to view PDF's. Do you see just the PDF files as completions?
4. Same as 3, but try other programs like python, perl, etc. How well do bash completions keep up with zsh completions?
I'd be very surprised if bash supports completions for programs that zsh has missed.
In general, switching from bash is very easy. Your muscle-memory from bash transfers very well to zsh. You may want to change the prompt to look similar to your bash prompt, so you'll feel at home. Translating my bashrc and bashprofile took just a few minutes.
I tried oh-my-zsh and it did not feel right for me. If this is the reason you're switching, all I can say is that zsh offers benefits even without it.
A light but featureful alternative to omz is also the grml zsh configuration [0]. I've been using it since 2011 or so and I've probably touched my .zshrc once or twice. If you fancy some colors you can also add some syntax highlighting [1]. Or just use fish which is great for interactive use!
The irony is that after all those years, we still dont find a optimal way to find out - when it is a good time to annoy a user about update decisions.
Do it during the system start up phase?
Do it before they go into a break?
Do it upon return to the system, when work was already interrupted?
Do it shortly before shutdown?
No, annoyia be praised. It must be when the user has focused for longer then 5 Mins on something.
My answer would be more like "fucking never, my god!" I thought this was one of the reasons to use free software: none of this paternalistic phone-home bullshit.
It did teach me how to understand a terminal / prompt. A few bits of information here and there and you suddenly feel happier because that part of the system also work for you.
I'm sure it is. (That doesn't make it not a grammatical error.)
It just seems like every time I follow a link to Medium, the article's littered with them; surely even the most cursory of proof-reads catches an issue with the opening sentence.
My test for "bloat" –
1. Has the project grown so large that it's starting to run into real-world performance issues? (I can't imagine this could be the case with even the largest of shell configurations except on very low-end embedded devices).
2. Has the project grown so large that bugs are popping up faster than the developers can do maintenance? Is there no or only one person who can read and understand the entire codebase? (AFAIK, no and no).
3. Are there many undocumented/poorly-documented features? Are there features that are both undocumented/poorly-documented and dangerous? Are there many deprecated or outdated features that have yet to be removed? (AFAIK, no, no, no).
4. Are there many features that both duplicate and do not improve on functionality found elsewhere? (Debatable and mostly subjective).