renaming considerations

[cgwalters]

UPDATE

This issue is now primarily a proposal to use a name like yum-image. See
this comment and the following.

Original comment follows:

---

As I mentioned in #307 I'd like to do a rename, for a few reasons, but among others I find myself typing rpm-ostree a lot more, and it's both too long and not very sexy.

Feel free to propose more candidates, but you should verify "Googlability" - specifically we should be able to win google for "XYZ fedora" and "XYZ CentOS". Similarly, Wikipedia. Secondly, also check for "Tab-ability". Are there other conflicts in /usr/bin for much of the prefix?

Candidates:

• osm: ostree (package) manager?
• rzr: razor, historical fedora connection
• impkg: image-package
• nts: nexus tree system
• rost: short for rpm-ostree
• dasos: greek for tree
• More time to choose other candidates
• Protest vote against a rename at all

[jlebon]

Why not simply abbreviate rpm-ostree to "ros" ? Not as sexy I admit (heck, Ross was the most boring of the band), but short and types very nicely.

How about "osm" ? Kinda short for "OSTree package manager", but sounds awesome. :)

If we must go the nexus route, I'd vote for "nxt", which types better than nxs as well.

[miabbott]

My own un-scientific tests reveals that typing nxs or nxt is difficult for me. (Apparently, I haven't trained hard enough to reach that x key with ease)

But osm does type much easier, however isn't as exciting as anything nexus based.

With nxt, people will likely pronounce it as next, which may be good or bad or indifferent.

I guess I would throw my vote in for nxt if we are going the nexus route.

[cgwalters]

There's two high level concerns:

• /usr/bin conflicts
• "Googlability"

Now, we should generally assume that we'll have a conflict for any set of three letters in google. The question is more how strongly associated are the letters with 1) Software in general 2) Fedora/CentOS

Some combinations of 3 letters are too well known as either airport codes or tickers, etc.

Specifically we should be able to win google for "XYZ fedora" and "XYZ CentOS". From that perspective, ros is a bit problematic because http://wiki.ros.org/groovy/Installation/Fedora

Whereas the only hit for "nxt fedora" is https://www.reddit.com/r/runescape/comments/46n3fh/using_nxt_on_fedora/ which looks fairly obscure (I had to look it up, apparently "nxt" is a codename for a new RuneScape client program).

[cgwalters]

A suggestion of tree-based names came up http://oregonstate.edu/trees/name_common.html

[miabbott]

The tree-based names is clever. I thought this would be more "native" for you, though - http://forestry.ohiodnr.gov/trees

[nzwulfin]

If trees are on the table, the Yew tree has some interesting connections, including the fact that it grows new trunks from the root system and survives splitting the main trunk.

No significant collision I can see googling around. Pretty easy to type too.

[cgwalters]

"nxt" is a cool-sounding combination of letters which means it has a lot of other uses - a blockchain, some sort of desktop even, and apparently most prominently wrestling. Exploring a bit led to "nts" which is a lot less commonly used and has basically zero fedora/centos usage. It's easier to type...and "nexus trees"?

[cgwalters]

Thinking about acronyms around the lines of "(os)tree package rpm system image atomic":

• itps/ipts (integrated tree/package system)
• atps/apts (atomic tree/package system)

I like itps the most I think of those. The conflict level is pretty low, it's not hard to type.

[nzwulfin]

+1 for itps

ipts gets a bit too close to ip for my mind.
apts gets a bit too close to apt for comfort.

[cgwalters]

Narrowing down then to:

• nts: Nexus Tree System
• itps: Integrated Tree Package System

At the moment I'm not finding something via the "tree names" path that appeals - the downside of those is the association with the software is tenuous (tree - tree, but we also have the package thing in the mix).

One name that I'm now realizing is actually pretty good is lorax but it's definitely taken.

[cgwalters]

I did recently find one technology-related conflict for nts which is https://github.com/dfoxfranke/nts

That said...eh. We'll deal with it, meaning should obviously be clear from context.

[jberkus]

So, I'm going to advise against doing this.

I'm sorry I'm coming into this so late, but there wasn't any discussion on any forum I'm subscribed to, and I only became aware of this proposal today.

There are a lot of good reasons to rename a project or a utility: conflicts with other programs, misleading command name, poor googleability, market research testing of better new names, etc.. "Difficulty in typing" is simply not one of them, unless you've named your project/program "r4t5t2h4h1" or something with diacriticals. System administrators don't interactively type commands, they script them.

If we're renaming the project, that means that we're hitting a giant "reset" button on building awareness for it. People will not see "nts" as the continuation of "rpm-ostree", as far as they are concerned it will be a complete different project with zero history (and you'll be fielding questions for the next 5 years about "what happened to the rpm-ostree project"). Our community is small enough as it is; do you really want to start over from scratch?

The rename of ostree to libostree doesn't have the same problems; it's a clear continuation, searchable using the same terms, and being done for a better reason (that is, the original name was somewhat misleading).

Further, the proposed name of "nts" has three problems with it:

1. it has no clear relationship to Ostree.
2. Admins will confuse it with NTP.
3. it has poor searchability, especially since it matches the common abbreviation for "network time server"

If you're really concerned about the awkward name/command of rpm-ostree, then there's two reasonable steps you could take:

• eliminate the separation of rpm-ostree from ostree for the command. The distinction never made sense to anyone not on the dev team anyway.
• add the full range of rpm-ostree commands to the atomic meta-command

But please don't junk a name and command that you've spent two years building awareness of for one which is hard to search for, hard to remember, and has no clear upside.

[cgwalters]

I don't think awareness of rpm-ostree is really large. People mostly seem to skip the name and call it either "atomic" or "ostree", but both of those are problematic and confusing.

"atomic" is a big bag of stuff that's hard to talk about.

Now for "ostree"...as far as separation between ostree and rpm-ostree...there are two things. First, I can't break the ostree command line. We could theoretically replace ostree admin but...eh. Second, libostree is an independent project that can be reused by other distributions. For example, the flatpak package in debian depends on libostree, which does not (and never will) depend on RPM. In constrast, for rpm-ostree, the intention is to deeply integration with Fedora/CentOS, which would be problematic for Debian and other distributions like OpenEmbedded, etc.

With building the "newname" brand, there is a clear and direct analogy of yum/dnf -> newname in the architecture diagrams (for host systems). It's easy to talk about.

[jberkus]

Colin:

Yum/dnf is a great example of the costs of changing command lines and names. I certainly wouldn't hold it up as a positive example of the ease of such things.

Anyway, like I said, if you're going to change names we need a better reason than "hard to type". That reason will also let you choose a better name.

Have you polled any folks who are good at marketing stuff about this?

[jlebon]

I think rpm-ostree could definitely use better branding. Renaming it to something more catchy, slapping on a logo and making a website for non-dev audiences would definitely help settle its place in the Project Atomic story (combined with the rename of ostree to libostree). Basically, instead of presenting it as "this is the layer that makes ostree work with RPMs", we can "reduce" ostree to the library that it is, and really concentrate on the features that rpm-ostree brings to Project Atomic as a whole.

From what I understand, this is basically the transformation that happened to xdg-app/flatpak, and I think the rebranding worked well there. Maybe @alexlarsson can provide some feedback as to how that went and whether he thinks this is a comparable situation. (Notice BTW that the word ostree does not appear even once on the flatpak website: http://flatpak.org/).

Yum/dnf is a great example of the costs of changing command lines and names. I certainly wouldn't hold it up as a positive example of the ease of such things.

This is not a good comparison. Yum and dnf are separate codebases, and thus had many differences, which I think is where the frustration came from. Here, we're talking about a rename of the same codebase, with compat symlinks for a long while. This is more comparable to the flatpak story, so again, we should query that community to see in what ways the rename affected them negatively (my guess is, any such effect was probably more than offset by the brand recognition gained).

As to the actual name we rename it to, nts is nice and has some catchiness to it. Though it would make sense to raise awareness on the mailing lists first and see how the community reacts to it and whether better suggestions come out.

[jlebon]

we can "reduce" ostree to the library that it is, and really concentrate on the features that rpm-ostree brings to Project Atomic as a whole

And this is becoming more and more relevant now. With the additions of client-side package layering and initramfs generation, the sysroot upgrader (basically, the code that handles creating new deployments from upgrade/deploy/rebase) has diverged by even more lately from the "vanilla" ostree admin equivalents. This again hints strongly towards pushing the ostree CLI out of the picture in the sysadmin context and focusing to story on rpm-ostree alone. Removing "ostree" from its name helps with that.

[alexlarsson]

I think this is a good idea, because I agree that the rpm-ostree name is focusing on the wrong thing. All it does is that it says this is a combination of two lower-level technologies, which by themselves are not super interesting to end users. A better approach is for the highest-level user facing project (which in this case is rpm-ostree) to have a nice catchy name with a website and lots of PR, while rpm and ostree are just technologies used in the background.

However, names are very hard. We had a long search for good names in the flatpak project, and in the end we kinda randomly stumbled onto flatpak. But, it was clearly worth doing the switch for us as a project.

[cgwalters]

Hard to type is relatively minor. That said particularly as we go into the desktop space (and I am working on that), people will type it just as much as they type yum/dnf.

But yeah, what @jlebon and @alexlarsson said re branding.

[jberkus]

Ok, so those are some better reasons.

So, next, regarding names: are you sure you want to go with "nts"? It really does seem likely to lead to confusion with "ntp". I certainly doesn't help market the project. Compare "flatpak", which is a great project name.

[dustymabe]

I guess for me it would be good to know exactly why rpm-ostree is a bad name from a "confusion" perspective. i.e. what exactly is the difference between rpm-ostree and ostree and why does nts make this less confusing.

As a non-typical user I've become quite attached to rpm-ostree as i thought it made things less confusing.. My understanding is rpm-ostree helps you build and distribute ostrees out of RPMs.

[vtolstov]

I'm +1 , I prefer rpm-ostree and I know that I can install rpm and use ostree with this tool. 31 Янв 2017 г. 20:56 пользователь "Dusty Mabe" <[email protected]> написал:

…

I guess for me it would be good to know exactly why rpm-ostree is a bad name from a "confusion" perspective. i.e. what exactly is the difference between rpm-ostree and ostree and why does nts make this less confusing. As a non-typical user I've become quite attached to rpm-ostree as i thought it made things less confusing.. My understanding is rpm-ostree helps you build and distribute ostrees out of RPMs. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#405 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAdYGxjpV6wTNOoMjcVO2Nd0glebD_Reks5rX3XIgaJpZM4JUJY3> .

[cgwalters]

@jberkus I'd never heard of NTS in a time context before. I did both the google(nts) check as well as wikipedia(nts).

@dustymabe It does that, but it also acts as a client side tool. And to get on my soapbox for a second, I think this feature is of absolutely critical importance - it lets us make inroads into the Linux desktop case which ideally will gain us more developers, and I see the feature as useful on embedded devices potentially too. Yes, many of these are doing containers. But the problem is still the same one we have in our stack - what about all the things that aren't containers, like PAM modules?

So my feeling right now is that I want to do a rename. Willing to entertain other options though. For rost, a quick google(rost) shows a conflict as the first hit. Not a bad one though. And I like the fact that it has a connection to the previous name.

[cgwalters]

Although, to be fair there is also a conflict for google(nts fedora).

[miabbott]

Perhaps we could come up with something from a non-English language, like skopeo has done?

Using Greek as a starting point, dendro is tree and dasos is forest.

[dustymabe]

@dustymabe It does that, but it also acts as a client side tool. And to get on my soapbox for a second, I think this feature is of absolutely critical importance - it lets us make inroads into the Linux desktop case which ideally will gain us more developers, and I see the feature as useful on embedded devices potentially too. Yes, many of these are doing containers. But the problem is still the same one we have in our stack - what about all the things that aren't containers, like PAM modules?

so could we leave rpm-ostree as the thing that creates ostrees from rpms: i.e. rpm-ostree compose tree and then have the new "thing" (client-side) do more, such as pull from a remote set up a new deployment edit grub, generate initramfs etc.. Am I making any sense?

If we had this separation it would allow someone to create a deb-ostree tool and the new "thing" could consume the repo that was generated from it as well.

As for the bikeshed what about otim for OsTree Image Manager or trum for TRee Update Manager. I like dasos a lot, too, but there is this guy: https://github.com/dasos

[cgwalters]

I'm currently thinking about "yum hostimg" or so. The "hostimg" naming feels clearer than just "img". Google thinks it's a typo for "hosting" today (which is a bit of an issue I guess, the m/n distinction being visually subtle). Hmm. "host-img" maybe.

[dustymabe]

are we talking about actually renaming this project or are we talking about what the integration with yum would look like. I'm still not a big fan of renaming this project. As far as yum integration I still prefer yum tree update as opposed to yum hostimg update. If you want something generic and related to the host yum host update maybe? still not loving that either though.

[cgwalters]

New idea: coreosctl.

[jberkus]

The trick would be to merge it with whatever remains of the Atomic CLI.

[jlebon]

I'm worried about renaming this project to something that alludes to a specific context in which it is expected to be used vs. a more generic/"stand-alone" name like rpm-ostree. E.g. just looking back in this thread, there's mentions of words like Atomic, system containers, yum; all things which are more likely to lose ranking as time goes on.

Given that this ticket has been open for more than 2 years now, I'm leaning more now towards not renaming it and just keeping "rpm-ostree". It's stand-alone, descriptive, and more importantly has been around for 5 years now and has propagated in a lot of places. By comparison, flatpak existed only as xdg-app for less than 2 years before the rename (going by git log here).

[jlebon]

One random additional note though: the name of the CLI tool doesn't necessarily have to match the name of the project (just off the top of my head: OKD, Kubernetes, Bazaar).

E.g. the project could be named "rpm-ostree" but the CLI tool ros. In fact, I've had that alias for the past 2 years now and it's been great! That way we don't compete nearly as much with https://en.wikipedia.org/wiki/Robot_Operating_System for ranking space either.

[LorbusChris]

@jlebon I like the idea of just calling the cli differently. I'll throw in another proposal as well: rpt (rpm package tree).

I find rpm-ostree a bit long, and the dash likes to change positions on different keyboard language layouts..which is annoying for me personally.

[dustymabe]

rost is another option we've discussed. In #405 (comment) it was suggested to leave the project named rpm-ostree and just add a compatibility symlink to have /usr/bin/rost -> /usr/bin/rpm-ostree

[jlebon]

Ahh yeah, good point. Missed that the symlink-only approach was already suggested. So, looking in this thread solely at the suggestions that make sense as a shorter symlink for rpm-ostree, there's ros, rpt, and rost. I like ros and rost the most I think.

For google-ability, rost is probably better.

So my feeling right now is that I want to do a rename. Willing to entertain other options though. For rost, a quick google(rost) shows a conflict as the first hit. Not a bad one though. And I like the fact that it has a connection to the previous name.

Hmm, weird, now the top hit for "rost fedora" is https://www.hut-muehlenbeck-shop.de/product_info.php?info=p11350_borsalino-panama-fedora-weiss-rost.html (loose translation: white & rust coloured fedora). I think we could rank better than that pretty fast. :) Though note I suspect most googling will actually be for "rpm-ostree" and rost only when searching for specific commands e.g. rost upgrade or whatever.

Tab-ability:

$ ls -la /usr/bin/ro*
-rwxr-xr-x. 4 root root 25040 Dec 31  1969 /usr/bin/rofiles-fuse
$ ls -la /usr/bin/ros*
ls: cannot access '/usr/bin/ros*': No such file or directory

It feels weird to me if "rost" starts using Rust - particularly given the German connection.

This is a reality now. rpm-ostree has a bunch of Rust in it. I think this would affect us much less now though if we're just talking about the symlink.

[LorbusChris]

@cgwalters Could you add some input on this again, before we discuss this on the comm mtg?

[ajeddeloh]

My vote is for rost and against anything with image in it. I don't like *image because to me image means "dd-able chuck of data that you can boot" which is not what rpm-ostree is about.

[dustymabe]

some discussion of this happened in the Fedora CoreOS community meeting today around timestamp 17:12:36

[cgwalters]

FWIW https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable#Rebranding_of_rpm-ostree is now up and revives this. There's an entirely new rationale, which is laid out in #2883

[AdamWill]

gets out bikeshed painting brush

I don't like dnf-image or yum-image as names, honestly. Unless this literally becomes part of the dnf codebase. yum at this point has pretty strong "old stuff" energy. The whole dnf transition was a bit rocky, but we got there. If you say "yum" to a Fedora-y or Red Hat-y person, now, they think "oh, the old thing". So yum-image would be attaching old-thing energy to our cool new thing.

dnf-image doesn't have that problem, but...still, to me at least, dnf is a specific codebase, not just the idea of 'doing software manage-y things in a Fedora/RH-y environment'. I would find it pretty weird to try to explain to people 'oh yeah, dnf lives at https://github.com/rpm-software-management/dnf ... oh, wait, you mean dnf-image? No, that's this completely different thing that just sounds a lot like it's part of that thing'.

So, uh, I feel like it needs a different name. I dunno what, though...

[cgwalters]

Thanks for your thoughts on this!

dnf-image doesn't have that problem, but...still, to me at least, dnf is a specific codebase, not just the idea of 'doing software manage-y things in a Fedora/RH-y environment'. I would find it pretty weird to try to explain to people 'oh yeah, dnf lives at https://github.com/rpm-software-management/dnf ... oh, wait, you mean dnf-image? No, that's this completely different thing that just sounds a lot like it's part of that thing'.

Yeah, I think this is a way to say the argument: "it's not dnf". This has also been expressed by others. I see this PoV. OTOH, personally, I want to more strongly integrate over time. There's really a spectrum between "branding" and functionality/code. For example, until now, for the entire lifetime of rpm-ostree, we have never added an option to /etc/dnf/dnf.conf. But...why not? We could. To pick one random example, #4061 proposes a new option that could equally well be lockdown=true in /etc/dnf/dnf.conf. My PoV is that while there's no one single thing we can do that would make this be "dnf", accumulating things like this makes it more and more real.

[kkofler]

How about "osm" ? Kinda short for "OSTree package manager", but sounds awesome. :)

OSM is the abbreviation for OpenStreetMap, so I think it would be really confusing to have rpm-ostree called that way.

[boredsquirrel]

meanwhile

printf """
alias rpmup='rpm-ostree update'
alias rpmrem='rpm-ostree override remove'
alias rpminst='rpm-ostree update --install'
alias update='flatpak update -y && rpm-ostree update'
alias rpmlist="rpm -qa"
alias rpmfind="rpm -qa | grep"
alias rpmq="distrobox enter -n fedora -- dnf search"
""" > ~/.bashrc