D'Oh My Zsh – How I unexpectedly built a monster of an open source project
medium.com
medium.com
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).
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.
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.
nvm has been the thing slowing down my terminal loads?
Thanks.
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.
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?[Dig trenches, commence C vs. C++ flamewar]
---
In conclusion, yes, C++ is bloated.
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?
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.
So for me projects like this are awesome.
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.
Other default key bindings: http://www.hcs.harvard.edu/~jrus/site/system-bindings.html
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 :)
Worth mentioning the fish shell [1] which takes a different approach and tries to "work out of the box" with things most people want.
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.
I agree with sticking with bash for that reason, but why not customize that as much as you want since it's easy to scp dotfiles around?
Also with git clone from github it's easy to copy settings on any non too security sensitive boxes.
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.
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)
You must have a lot of expensive stuff crammed into your config.fish file, for me fish takes < 1 second to init.
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.
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.
Not according to reality → http://why.fisherman.sh
Greatly disagree on the fish startup time, for me it takes approximately the same time as bash. Can't comment on zsh though.
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.
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.
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.
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.
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.
Worst part of this is that it's useful. ȱ_ȱ
There's no shame in customizing shortcuts. Isn't that the entire point of emacs?
Customize all you want, but don't become dependant on your customizations.
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!)
I find that I mostly use systems that I can make match my setup...
And when you ssh into another machine, or have to use a different machine, well you're just as slow as other people using no config at 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.
https://github.com/sorin-ionescu/prezto/issues/197
The linked oh-my-zsh issue is an interesting read (or skim).
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?
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.
[0]http://joshldavis.com/2014/07/26/oh-my-zsh-is-a-disease-anti... [1]https://www.bountysource.com/issues/102375-move-plugins-to-s...
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 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).
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.
[0]: https://github.com/grml/grml-etc-core/tree/master/etc/zsh
http://i.imgur.com/3FKaEIy.png
It's incredibly easy to set up, I have a script to do it[1] but doing it by hand is trivial.
[1]: https://github.com/beefsack/bash-powerline-installer/blob/ma...
No, annoyia be praised. It must be when the user has focused for longer then 5 Mins on something.
Not oh-my-zsh. It was top trending for the Shell category, not for all of GitHub.
> This wouldn’t my first foray into open source software;
> nor my last.
I know that I'm annoyed perhaps too easily by poor grammar - but the opening sentence, really?!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.
Customization is nice but I guess I mostly prefer to spend as little time thinking about shells as possible.