Replace SI prefixes with IEC for units of information (ISO/IEC 80000)

[Andrew15-5]

This is the copy of the flatpak/flatpak#5504, since Flatpak CLI and Flathub web both have the same issue.

To be more transparent when it comes to digital size of something (binaries/flatpak packages), flatpak (both CLI and web) should move from SI prefixes to IEC (binary) prefixes, in other words add a small i like so: MB → MiB (same with G, K etc.). Right now, just looking at the 69 MB, user can't know for sure if it is 69 Mebi × 1024 Kibi × 1024 Byte × 8 bit = 578813952 bit or 69 Mega × 1000 Kilo × 1000 Byte × 8 bit = 552000000 bit, which already an almost 5% difference in size.

Many CLI/GUI programs already use binary prefixes (I'm so happy), but there are still many others that don't (:().

AFAIK, this also intentionally (ab)used by marketing teams to sell something with 2 TB of storage, but it's definitely not the 2 TiB that everyone wants to think. Why do I think this way? Because my peers and teachers/professors don't even know that there is a thing called "Kibibyte" (and we are talking about software engineers). Hence, the majority of the people worldwide also don't know this.

I want Flathub to be more transparent/clear on this matter!

What are the rules:

• one whitespace between the value and the unit;
• first letter is always in uppercase (B, K, M, G, T, P, E, Z, Y);
• if value is >= 1024 then:
  • the second letter is i (lowercase; from "binary");
  • the third letter is B (uppercase; from "byte").

See https://en.wikipedia.org/wiki/Binary_prefix

[razzeee]

The logic for displaying it is here https://github.com/flathub/website/blob/main/frontend/src/size.ts

[Andrew15-5]

@razzeee, if you are the one to review the PR, then it is now ready.

[TingPing]

I'm confused by this change. SI is the "correct" unit for file sizes. IEC should be used for measuring things like memory.

[Andrew15-5]

Let's continue our discussion here: flatpak/flatpak#5504 (comment).

[TingPing]

While it is worthwhile having the conversation there I think the reality of the situation is this choice falls on to @razzeee for the website.

As-is, the website's units don't match flatpak or GNOME Software. It might match Plasma Discover but I'm not sure.

[Andrew15-5]

As-is, the website's units don't match flatpak or GNOME Software. It might match Plasma Discover but I'm not sure.

As-is, the website's units don't match flatpak's because only website's units were fixed so far. And the website's units do match the ones that the International Bureau of Weights and Measures declared acceptable (the IEC units).

I think the reality of the situation is this choice falls on to @razzeee for the website.

I'm really having a hard time understanding you, @TingPing, and it looks like you are implicitly trying to say that @razzeee should reconsider and accept your personal view on things, i.e., revert my PR, so that flathub will again use SI units. Also, adding the GNOME/Plasma comparison has nothing to do with the matter at hand. Moreover, @razzeee already agreed with my issue (by providing the place where I can fix the legacy units) and merged my PR, which means that we both think the IEC units should be used instead of SI units. Therefore, I will close this issue. I don't see any reason why we should keep it open, because changes were already merged, and any disagreement can be resolved in the same single place for discussion (flatpak/flatpak#5504). And only when we will come to a conclusion, the question of opening this issue again should be raised.

P.S. @TingPing, I think I sound harsh, but I'm trying to follow "logic and concrete arguments" approach (I just come up with this phrase) and be as straightforward as I can so that everyone fully understands my point of view and intentions etc. So I'm sorry, if I'm too rough.

[TingPing]

The reason I commented here at all is because a user reported the website having the wrong units. It is not only my view and the fact it does not match flatpak nor GNOME expands that to many users views.

I am asking for their input because they maintain the site. I just want clarification that they do want the website to use these units.

Also, adding the GNOME/Plasma comparison has nothing to do with the matter at hand.

Yes it does. This website hosts Flatpaks. Users consume flatpaks through the website, the cli tool, and graphical stores. It is odd when they do not match.

and any disagreement can be resolved in the same single place for discussion (flatpak/flatpak#5504). And only when we will come to a conclusion, the question of opening this issue again should be raised.

Don't take this the wrong way but Flatpak doesn't have a lot of active maintainers so this issue will likely never be addressed there. That is why the decision here matters most.

I'll also say if they say "I think the change is fine" I'm not going to crusade against it. I just found it a strange change when somebody brought it up.

[razzeee]

FYI I don't have a problem walking this back, depending on what gets decided

[TingPing]

I just don't expect other maintainers to chime in unless we go out of our way to ping them all.

Almost all contributors to flatpak are gnome/glib developers so while I doubt any of them have a strong opinion they would probably side with the glib default, SI, which is what Flatpak already did.

[Andrew15-5]

The main problem, I think, is the discrepancy between website and CLI tool. And this potentially can be fixed really quickly if I told where the units are being printed from (in the source code). I have no problem making the PR to flatpak, but I soon will be pretty busy, and I haven't tried building flatpak from source yet (https://github.com/flatpak/flatpak/blob/main/CONTRIBUTING.md), so this is something to keep in mind if this is important for merging changes.

[TingPing]

You can search for g_format_size() to find it.

I am only a contributor to flatpak but you already know my stance against such a change.

We also don't have a good way of making it a preference either.

[Andrew15-5]

About glib and GNOME. I can try to reach out and submit a ticket there as well, but this will happen maybe after 24th of January. And we will see if they agree on the IEC units.

Probably the main note here is that GNOME and glib are not rolling-release type of software, so even if they are fixed, most users won't see any changes in a very long time. So changes will show up gradually for all users, and therefore there is no rush in fixing glib/gtk now. But I don't want to take my sweet time, too.

[TingPing]

glib made this choice probably 20 years ago and you'd have to change many hundreds of projects. That decision is long past.

[Andrew15-5]

glib made this choice probably 20 years ago and you'd have to change many hundreds of projects. That decision is long past.

If a lot of projects depend on glib library, this doesn't mean that I have to change all these projects — I only have to introduce changes to glib, and all the software that will build against the new glib will automatically "be fixed". But the core thing right here is if projects do use glib's function to convert bytes, and not their own. If, for example, flatpak were to use their own conversion function (like many of non-glib/non-C projects do), then everything can be fixed "in house"/locally and there will be no dependency on an upstream issue to be resolved.

It is always better and easier to make small changes rather than big ones. So I propose adding a custom conversion function in flatpak, at least until I go to GLib folks and open an issue there (which may or may not be agreed upon). And we can discuss details of introduction of this conversion function at flatpak/flatpak#5504.

P.S. I have noticed that for some topics and issues, some maintainers can have a very strong opinion and even if the majority of knowledgeable people will try to reason (with facts and all that good stuff) with the maintainers in the result the issue still can be closed as "won't fix". The big example for this is https://wiki.archlinux.org/title/XDG_Base_Directory. So a new GLib proposal can be also rejected simply because some maintainer can say "I don't see any reason for changes" even after "any reason" (or several reasons) was clearly stated. Not everyone (not even past me) knows that things can happen this way.

[TingPing]

But the core thing right here is if projects do use glib's function to convert bytes, and not their own.

You can just pass G_FORMAT_SIZE_IEC_UNITS.

I only have to introduce changes to glib, and all the software that will build against the new glib will automatically "be fixed"

glib wouldn't do a major break in behavior under applications like that. I don't think anybody would accept this change in general.

[TingPing]

P.S. I have noticed that for some topics and issues, some maintainers can have a very strong opinion and even if the majority of knowledgeable people will try to reason (with facts and all that good stuff) with the maintainers in the result the issue still can be closed as "won't fix".

Everybody thinks they are correct. There is actually no true answer between SI and IEC. Citing NIST doesn't make something the reality.

These are all independent projects making their own choices. glib and flatpak chose SI.

[Andrew15-5]

I understand that GLib is one tough nut to crack. But you need to realize that:
1.1. someone projects didn't really choose SI over IEC, because they could've potentially only had one choice (SI) — the one that they knew about;
1.2. similarly, projects that chose IEC units clearly chose them, because everyone around still use SI units and IEC, are, unfortunately, still a minority;
2. you can say that "there is actually no true answer between SI and IEC" and I can agree with this, but there is a big difference between "a true answer" and "a better choice" and a lot of things aren't set in stone and we can change anything;
3.1. choosing units that are "governed" and "accepted" by BIPM and as a result by 63 countries worldwide means that everyone who agrees with BIPM also agrees with IEC over SI, simply because this way we are following rules and therefore can clearly understand each other when communicating;
3.2. going against the international rules means that there always will be miscommunication and misunderstanding and as a result arguments, such as we're having right now;
4. We need to choose something that will help us understand each other, rather than something that will forever have two meanings (SI units); choosing the latter simply because "glib made this choice probably 20 years ago" and "that decision is long past" means that the decision is made with attachment to the past or legacy code, i.e., by conservative way of thinking, which is known to not be the best way of thinking, to lightly put it (when it comes to development and thinking of a brighter future).

[barthalion]

I have re-opened it on purpose, it would be much appreciated if you could stop closing it until we decide if we follow Flatpak's conventions for the website or not.