Comment by MeetingsBrowser
2 days ago
> I could spend hours figuring out all those things,
This post is explaining how to set up those things. Less than five minutes to read.
2 days ago
> I could spend hours figuring out all those things,
This post is explaining how to set up those things. Less than five minutes to read.
Less than five minutes to read but how long to set up my own? The author only showed what he needs/prefers ("Here is my config for starship"). I'll need to navigate the documentation of starship to figure out all those options, which defeats the purpose. Their config documentation (https://starship.rs/config/) already gives me headaches.
And from the article
> Because cloud services are available globally, I've disabled them.
That's some bad defaults right there.
> When you run a command, it also shows how long it took to execute.
No I absolutely don't want this thing done by the author. Now I am fully in the "customize my config" territory.
Also, most of us are unlike the author, and 0.07s vs 0.38s startup time means no difference.
I think the point of the previous comment has been more than clear enough.
> Also, most of us are unlike the author, and 0.07s vs 0.38s startup time means no difference.
That's quite likely a workflow thing. If you are popping up new (transient) terminals frequently, then a ~400ms wait time for each adds up and makes the entire machine feel really slow. I'm willing to wait extra half a second for a new terminal -- once -- after I've changed my autocompletion configs (rebuild + rehash takes a while), but if I had to wait for that long every time I hit Win+enter and wait for the terminal to become active, I'd be irritated pretty damn quickly too.
You get conditioned to immediate responses pretty fast.
> Less than five minutes to read.
OMZ is still easier to set up consistently. That’s why we use it.
If the concern is the bloat of OMZ then make FMZ - fast my zsh - that is just as quick to set up and doesn’t add “bloat”?
I won't spoil the article, but if you read to the end you'll find out what this "FMZ" project is called.
Can you spoil it for me, because I read it to the end and saw no mention of such a project. Unless you are referring to the DIY approach the article suggests.
1 reply →
That misses the point. I don’t even want to think about any of that stuff.
It’s a single command to install oh-my-zsh. I can fire it off, check Slack, and come back in 5 minutes. If I have to take 5 minutes to setup it up, I’m just not going to do it.
Caring enough to read a blog post and comment on hackernews, but not enough to copy/paste the changes from the blog post is a very fine line.
This is common low-quality internet arguing ("you care enough to come into this thread but..."). You can avoid this by keeping in mind that different things are different things, and analogies have many holes by default.
Not sure what your point argument is.
1 reply →
[flagged]
[flagged]
It's a tool.
Some chefs like to spend hours sharpening their knifes with wet stones. Others are just going to run it through a power sharpener and get on their way.
I like to focus my craft in places other than the terminal.
Different strokes I guess. Personally I think any time spent tinkering with the shell is a waste of time: a basic, zero-customization bash is just as good at doing things for me as a shell that I've messed around with the settings on for ages. So I don't waste time on customizing my shell because it provides no value to me, while those who get value can spend the time. We both win.
there's some nuance to this. people might want to spend minimal time hacking on their shell and more time hacking on things they find interesting that are not related to shell setup (and also not webshit). besides even if its webshit, what makes you say shell setup hacking is more or less interesting compared to webshit hacking. the term webshit itself implies you view it as less interesting than shell setup -- fair if thats your pov, but doesnt make it intrinsic.
> important webshit to build
hackernews: where a large portion of programmers are considered inferior because of the domain they work in (the domain where hackernews also lives)
1 reply →
Time is finite.
I could spend that time tinkering with the internals of an ad-hoc informal system cobbled together in the 1970s and held together by spit and glue.
Or I could just not do that.
Also, the implication that fiddling with shell scripts is somehow a better engineering/programming practice than web programming is laughable at best.
Hacker News: Where the hackers don't want to think about the code required to build the webshit nor the command-line nonsense used to write it, because the agents will take care of all that.