I hear that objection and it's a decent one, but that one just isn't as well known. Even as an American, I'm not thrilled that "offensive in America" matters more, but it does.
I have the impression that many of the people who know ‘gimp’ as a slur only do because some of the others feel a need to bring it up every single time GIMP is mentioned anywhere ever.
Respectfully, that's kind of a ridiculous "impression," easily refuted by many of us who have wanted to recommend GIMP to people.
And again, it's called "reading the room." Even if you don't care about it being "offensive" or a "slur," names still matter. Like, if the word "poop" was in the name of some otherwise good software.
> Respectfully, that's kind of a ridiculous "impression," easily refuted by many of us who have wanted to recommend GIMP to people.
Is it though? Almost every time the topic is discussed, I see someone in the comments only then learning that the word is also known by some as a slur.
> Like, if the word "poop" was in the name of some otherwise good software.
Except that ‘poop’ is a common word with a single common meaning. ‘Gimp’ is not a common word and has several different meanings, one of them a slur, another kinky, and others probably innocuous (if even more uncommon). Many people (even among native English speakers, though let’s not forget about the rest of the world) only know the word as the name of the program. The two don’t really compare.
I think "Do people commonly understand 'gimp' as a derogatory word?" is the wrong question.
The right question is, "Did _enough_ people understand 'gimp' as a derogatory word to harm its adoption?" and the answer is probably yes.
The people complaining about GIMP's name are the ones who love and use it, who have seen the name cause problems. There's a modicum of grief for the counterfactual (of how much better GIMP might be if it didn't set up artificial barriers for itself), and the frustration with people who obstinately don't see the problem.
I think both questions are good to ask. Another follow-up question would be ‘how big is the damage to adoption’, since the answer could range from ‘barely perceptible’ to ‘devastating’. An answer closer to the latter would, in my opinion, make a great reason for a name change.
People who never hear about GIMP in the first place are never going to use it.
Someone asks, "How did you make that?" and your answer is PhotoShop and not GIMP. That's one less person who might use GIMP, and one less person who might introduce GIMP to other people, and so forth.
The difference is that git was among the best-in-class and developed and used by the people behind Linux, and that the word 'git' wasn't as offensive as 'gimp'.
If GIMP had feature-parity with Photoshop, and had been adopted by Condé Nast or ILM, and had a less-offensive name like "Dumm" or "Silly Image Editor", then this would be more comparable.
Adding to sibling comments: I used to use Ansible professionally and PyInfra for homelab. Ansible is ridiculously slow.
The only issue was I had to implement some facts and operations myself that probably were available in some Ansible package but to be honest it was trivial.
Don't use Hugo. The maintainers are so detached from reality it's not even funny. The project is about 12 years old, has +80k stars on github and used in production by many. Despite that still no 1.0 version and they introduce breaking changes for no good reason. You website will break all the time. I made a mistake of creating few websites with it and now I have to rewrite them all in other SSG because I refuse to participate in this circus.
Can't agree, even though I was also hit by breaking changes from time to time with my own templates. Because this has a BIG upside: I am very happy with Hugo and how they love to solve problems in detail and think through features to the end. Because of these frequent re-factorings and sometimes (!) breaking changes, it gets more elegant every year.
And this is really not a production problem. As stated in the comments before, just don't upgrade if you don't want to / have no time yet. It is a self-contained static site generator without external dependencies. It won't break. And the security of an old Hugo binary is mostly a non-issue if you do not load remote content.
And, if you have some time: Their changes are really well documented. The changelogs are really good.
The main problem is sticking with an unmaintained template of a third party which breaks when you finally want to upgrade and don't want to fork / don't know when a an template update comes along. But that's the reason I write my own. It was worth the effort.
Eh. It’s written in go. I just built the binary, stuffed it in my repo and continued to use the same version for years. Then when I wanted to update I rewrote my whole theme from scratch, recompiled and now I’m set for years again.
and a convenience symlink ~/.local/bin/hugo, pointing to my "production" version. I can easliy call whichever version I like with hugo<tab><tab>. What am I missing?
It depends on your workflow I guess, but the advantages of having a Hugo version tagged in an image:
- sharing it easily between computers/users (docker pull registry/image:tag)
- having the appropriate binary version embedded in your code through a docker-compose in your repo
- having custom aliases dedicated to hugo included (build/serve/run...)
- using the exact same image in your CI/CD
- not "polluting" your local computer with some more stuff
In what specific areas Phoenix Live View is so far ahead? Do you mind elaborating?
The unfortunate disadvantage of Live View is that you need to write Elixir. A lovely language, but it would be hard to sell in company that use only <SOME_LANGUAGE>. The hypermedia libraries like d* and htmx can be used with any backend.
