search

coreos / rpm-ostree

⚛📦 Hybrid image/package system with atomic upgrades and package layering
https://coreos.github.io/rpm-ostree
Other
871 stars 195 forks source link

renaming considerations #405

Open cgwalters opened 8 years ago

cgwalters commented 8 years ago

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 https://github.com/projectatomic/rpm-ostree/pull/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:

jlebon commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

There's two high level concerns:

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 commented 8 years ago

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

miabbott commented 8 years ago

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

nzwulfin commented 8 years ago

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 commented 8 years ago

"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 commented 8 years ago

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

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

nzwulfin commented 8 years ago

+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 commented 8 years ago

Narrowing down then to:

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 commented 7 years ago

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 commented 7 years ago

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:

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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" notifications@github.com написал:

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 https://github.com/projectatomic/rpm-ostree/issues/405#issuecomment-276440037, or mute the thread https://github.com/notifications/unsubscribe-auth/AAdYGxjpV6wTNOoMjcVO2Nd0glebD_Reks5rX3XIgaJpZM4JUJY3 .

cgwalters commented 7 years ago

@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 commented 7 years ago

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

miabbott commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

There are indeed people using libostree for Debian systems. In fact, supporting this is the rationale for having rpm-ostree and ostree separate. For example, https://endlessos.com/ And there's also discussion on the upstream list for both Debian desktop systems and embedded (that one is OpenEmbedded/Yocto, not Debian, but the point remains relevant).

And yeah, I agree that rpm-ostree "feels" better on compose servers. On that topic though...I'd like to move towards providing Docker images. Like this does.

dustymabe commented 7 years ago

So I guess a few more questions are:

A diagram of each "tool" in the puzzle and how they fit with everything else would be really useful. Also we could illustrate any piece of the puzzle that can be pluggable, (i.e. rpm-ostree compose tree and deb-ostree compose tree could be interchangeable). Sorry to beat this into the ground.

cgwalters commented 7 years ago

@dustymabe The scope of what we're talking about is in the pull request. What may not be obvious is the underlying infrastructure for having two names exists since this pull request.

Here's a direct commit link.

All of the command line will remain unchanged.

jlebon commented 7 years ago

Just to jump on the naming bandwagon, I really like rost. It's obvious where it comes from, it's short, it's easy to type, and you can say it like a word, rather than an acronym. (Apparently it's an alternative spelling for roust, "a strong tide or current, especially in a narrow channel"). Its pronunciation is pretty close to Rust, though within the context it should be obvious of course.

dustymabe commented 7 years ago

Just to jump on the naming bandwagon, I really like rost

I'm +1 especially if the R O S T is just short for Rpm OSTree, which I assume is the case.

oh and is it pronounced "roast" or "rossed" ?

jlebon commented 7 years ago

Right, that's what it's short for. I've been pronouncing it "rossed", though funny you say that, according to Merriam-Webster, it's also an old word for roast.

cgwalters commented 7 years ago

@miabbott Mmm...non-English names increase the risk of conflicting with something and us not knowing unless we find a native speaker. Though dasos does have a nice ring to it.

For rost...I think we'd want to check with some other language speakers too. Google Translate thinks it's Romanian - "sneak", though in German it's rust?

Maybe the next step here is to formalize a list of candidates/options, something like:

Then we have some sort of weighted vote by contributors?

dustymabe commented 7 years ago

+1 for a vote.

I think for rost we could still have people refer to it as rpm ostree if they wanted to, as it would just be an acronym for that. also we could encourage people to try to call it "roast" to quell any confusion with "rust" that may happen with variations in the way people pronounce "rossed".

magcius commented 7 years ago

whoa cool look at all the colors I have to paint my bikeshed!

jlebon commented 7 years ago

Where did we land on this? Should we take it for a vote, or maybe just feedback on the lists for now?

rost sounds like it would get confused with rust, both in typing (looks like a typo) and in spoken conversation

Yeah, it's a risk, though I think their domains are sufficiently different I think that it'd be pretty easy from context to understand what is meant?

dustymabe commented 7 years ago

I've already have alias rost=rpm-ostree 😄

cgwalters commented 7 years ago

Well, I at least really like the Rust programming language and had been trying previous experimentation with using it in libostree - not yet rpm-ostree, but that was the idea. (The thing with doing it for rpm-ostree is it much more quickly hits up on needing usable introspection bindings and that's a whole world in itself)

It feels weird to me if "rost" starts using Rust - particularly given the German connection. I'm not going to say I'm entirely against it, but I can't say I like it (yet) either. Maybe it'd grow on me.

I propose we gather more candidates - I edited the first comment at the top with a list, feel free to comment with more, but please do some checking against the Google criteria.

cgwalters commented 7 years ago

One criteria to add to the mix is TAB conflicts. For example, here (using atomic-ws:atomicws/fedora/x86_64/continuous):

# ls -al /usr/bin/fl*
-rwxr-xr-x. 2 root root 697384 Dec 31  1969 /usr/bin/flatpak
-rwxr-xr-x. 3 root root   7866 Dec 31  1969 /usr/bin/flatpak-bisect
-rwxr-xr-x. 3 root root  28192 Dec 31  1969 /usr/bin/flock

That's really good - one can just type fla<tab>. The fact that flat is English helps me at least since it's easier to type.

So perhaps an area we're underexploring is longer names that are still "tab-able". I notice at least das<tab> would work for dasos.

jlebon commented 7 years ago

Can you also add the various criteria in the first post? E.g. Google-ability, tab-ability, etc...

dustymabe commented 7 years ago

/me wishes we could have a running poll on this somewhere - maybe a google form vote?

jlebon commented 7 years ago

Here are a couple more in the "tree" family:

Google-ability for all those seems pretty good. Wikipedia articles all free for grab. Though apparently, TreeBox is a vaping product.

jberkus commented 7 years ago

I'd be happy to run a poll, if we can narrow this down to 4 options or fewer.

If we name it "nxs", can we advertise it using the famous boy band of the 80's?

jberkus commented 7 years ago

So, where are we on this? Did we lose interest?

cgwalters commented 7 years ago

I'm definitely still interested. Here's another one in the 3 letter category:

btp, short for Binary Trees and Packages. Tab-ability: conflicts, but it's just 3 letters. Googability: Fine for "fedora btp/centos btp". No major conflicts: https://en.wikipedia.org/wiki/BTP However, the British Transport Police clearly own Google for this now.

jberkus commented 7 years ago

I'm still not keen on cryptic TLAs, regardless of what they are. Although at least BTP makes some kind of sense.

dustymabe commented 7 years ago

I still vote for keeping rpm-ostree and/or derivative like rost where we don't lose the identity that once was rpm-ostree.

cgwalters commented 7 years ago

I've been thinking about this more lately a lot. I'm increasingly coming around to the thought that we add three new aliases: yum, dnf, (and to some degree rpm).

Let's dig into my new proposal here a bit more :smile: First, why rpm? It's pretty simple, I want to take over rpm -ivh foo.rpm for example to redirect to rpm-ostree install ./foo.rpm. Another very interesting one is e.g. rpm -qa - we could redirect that to a DBus request. Why would we do that? Because running rpm -q is fundamentally racy if another process is changing the database. Which can happen again with us with livefs. That's a very longstanding issue with RPM that we now have the opportunity to fix with a unified architecture.

To implement this we'd need to symlink /usr/bin/rpm → /usr/bin/rpm-ostree, parse/intercept options, and redirect back to /usr/libexec/rpm-real for options we don't handle.

Next, and probably more controversially, why both yum and dnf? Basically, we start talking about an "ostree plugin" for "yum". Yes, that's not really how it works, but it's a useful first approximation trying to explain things to someone who e.g. has been using Ubuntu for a while but has a superficial understanding of Fedora/yum.

Another argument for this is that our story for many container builds is yum/dnf, and having 3rd thing is just confusing.

Things would get interesting if we implement this via the "wrapper model" similar to what I proposed for /usr/libexec/rpm-real, since we could e.g. just redirect to /usr/libexec/dnf-real search via rpm-ostree search, without having to move search out of dnf and into libdnf.

(Technically this would mean adding the dnf package of course to FAH, but we already have to have Python due to atomic, cloud-init, and ansible anyways)

This proposal makes things messier in some ways for sure, but we avoid having to retrain admin fingers. And it emphasizes much more strongly the package layering support.

cgwalters commented 7 years ago

Although possibly if we go this route we should only define the aliases for interactive shells, at least at first, to avoid having things detect the presence of /usr/bin/yum and start doing anything advanced that we may not intercept correctly.

jberkus commented 7 years ago

@cgwalters that sounds pretty good to me, it would help people over the transition to Atomic.

ncoghlan commented 7 years ago

Just chiming in to say that the proposed yum/dnf/rpm aliasing would be a very elegant solution to the issue I filed (https://github.com/projectatomic/atomic/issues/1041) about the "Command not found" error for dnf being very confusing for folks following a regular Fedora tutorial without knowing they have an Atomic Host instance instead.

Elegant from a user perspective, anyway - I make no claims as to the feasibility of an elegant implementation ;)