This was previously accessed in KDE4.x via It was accessed via ; System Settings > Locale > Country/Region & Language > Other > Byte size units:

JEDEC:"1 Megabyte = 1024Kilobyte" <- this is the Windows way
IEC: "1Mebibyte = 1024 Kibibyte" <- this is the linux/GNU default
SI: "1Megabyte = 1000Kilobyte"  <- this is the manufactorer way
https://en.wikipedia.org/wiki/Binary_prefix#Standardization_of_dual_definitions

But do we need it?

contra:
* users might wonder "is it now Megabyte=1024 (the windows way) or Megabyte=1000?"
* GNU tools any many terminal tools defaults to IEC-standard so we would see users with "on my terminal its 3MiB but on my dolphin its 3,2MB! BUG!"
* other desktops are using IEC standard too

its kind of a good standard https://en.wikipedia.org/wiki/IEC_60027 and for me i cant see a good reason to support the 2 others again

Yes. 

Users won't wonder because we'll do what we have always done, - look at the assigned suffix. KiB or Kb, MiB or MB etc and decide what is appropriate for the use-case. Those who need the ability to change it, and know how and why they need to change it, should be given the choice, as they were, in KDE 4.x. 

Suddenly deciding "you don't need it any more" removes any level of consensus or feedback from your userbase.

I agree the user should be able to pick between IEC prefixes (kibi/KiB, mebi/MiB, gibi/GiB, ...) or SI prefixes (kilo/KB, mega/MB, giga/GB, ...). There is no confusion here, because MiB != MB.

I do not agree supporting 1024 B == 1 KB, 1024 KB == 1MB, ... This is a misuse of SI prefixes that has caused confusion for computer users for too long. If that is what JEDEC specifies, then we should not support JEDEC. We have SI and IEC standards; we should follow them.

I say give people their preference.  Arguing about which is "better" and why is really just about opinion, and use case, and not likely to  be productive.  Some of us have been using computers since before SI units became common.  The reason 1024 was used in the first place is because it matches the realities of the hardware.  Computers work in powers of 2 (base 2).  You still get base-2 values when buying memory chips, for instance.  It just makes sense.

Hard disk manufacturers, as a notable example, started using the SI units (base-10) because of marketing, not because it helped users.  You could sell a gigabyte hard disk even though it was really somewhat short from the traditional "gigabyte" people were used to.  Lots of eople were initially upset by this, wondering where their other 73,741,824 bytes per "gigabyte" went.  It can be argued that using the traditional base-2 measurements made more sense, since you could easily equate the valuses between your temporary (RAM) and permanenet (disk) storage.  The name changes were the main source of confusion.  I still think "gibibyte" sounds stupid, since I grew up calling it "giga-", not "gibi"-.  But I'm not about to fight for the naming prefix.  We have discreet names for each that are now well understood.  It was pretty confusing for a lot of people used to the old names.  But we've had time to get over the name change.

I can see where the SI units make sense, especially from a non-technical perspective.  They match up with people's expectations from the world of metric units.  Fine.  I would say that programs should use the current convention of KiB and kB, MiB and MB, GiB and GB, so as to be specific about what is meant.  But, still, give people the option to prefere the base-2 or base-10 unit representations for files and such as they prefer.  Personal opinions about which makes sense "universally" are merely subjective.  There are lots of reasons some may want to default to units that make sense for them.  So let them.

/2bits

Eh...  maybe I misunderstood this?  I like having preference to default to IEC versus SI units.  But using the JEDEC names for base-2 units conflicts with the SI names (base-10) and causes confusion.  Maybe if someone really wants that as a choice, they can make their case.  Personally I like using the IEC units because they make it easier for me to think about how hard disk and memory match up.  So I am voting for the choice to use those over SI units.  I have a harder time understanding why someone would want to use the JEDEC names for the base-2 units, as that would just bring back confusion.  IEC names cover base-2 just fine.  But... to each their own.  Sorry for opinion spamming....

SI should be an option as metric is easiest for people. IMHO this should be the default but MHO isn't particularly important.
IEC should be an option (there are times when it's useful, e.g. counting disk "pages"). For that matter, hexidecimal is useful with IEC.

However - from a quote on Wikipedia (https://en.wikipedia.org/wiki/Binary_prefix):

The International Bureau of Weights and Measures (BIPM), which maintains the International System of Units (SI), expressly prohibits the use of SI prefixes to denote binary multiples, and recommends the use of the IEC prefixes as an alternative since units of information are not included in SI.

So using JEDEC would be against their wishes, and they're the authority on these matters.


Also, can you please make a special one for me with capital Kilo :)

any updates?

At a library level  KFormat absolutely supports IECBinaryDialect, JEDECBinaryDialect, MetricBinaryDialect.

We use the right thing in the right places. Providing this as a some sort of global option doesn't seem to make any sense and none has been provided here.

If an app does the wrong thing please report it there.

(In reply to David Edmundson from comment #9)
> We use the right thing in the right places. Providing this as a some sort of
> global option doesn't seem to make any sense and none has been provided here.
> 
> If an app does the wrong thing please report it there.
Please reopen.

Reason: there is no agreement about what is “the right thing in the right places”. Apps just use the (current) default, which is IECBinaryDialect. I personally think that this does not make sense and that MetricBinaryDialect is ‘the right thing’ to use. However, I can see that this is a matter of taste, so I wouldn't want to force my preference on others.

Just like we can choose a period or comma as the fractional separator and other locale-related things, the units to use for measuring file sizes should be user-configurable. It does not make sense to do this at the application level, because then each application needs to implement this separately, possibly leading to issues because the maintainer is a staunch proponent of one of the options. The easiest is to just make the Plasma-wide default configurable, as it was in KDE 4.

I've opened bugs for asking application maintainers (e.g., Bug 428045), but the response automatically leads to the default set in frameworks-kcoreaddons, which the apps use. So this is not seen as an application-level choice.

Heh, yeah. Re-opening.

Yeah, it seems very silly that this regressed in KF5; SI units are a lot more natural, are what storage media is marketed as, and also match data transfer rates (a 1MB file takes 1 second to transfer at 8Mbps or 1MB/s). This should absolutely be configurable, and I would go as far as saying SI units should be the default. Power of two storage sizes have no useful meaning; beyond sector/block sizes there is no power of two pattern. The only common quantities that are still measured in powers of two are RAM sizes, and the only use case for cross-referencing RAM sizes to file sizes is for things like VM suspend RAM images. That's it.

(And I say this as someone who tinkers with hardware and kernels and deals with things like 8 MiB Flash images all the time - I couldn't care less that those are shown as 8.4 MB in directory listings. I know how to round down.)

I have seen people arguing over this for a couple of decades now.
There are threads about it all over the net.
The IEC recommendation is not accepted worldwide.
At JEDEC, their documentation uses the 1024 B = 1 kB definition (or KB if you prefer).
The other problem: The Byte is not an SI unit. The bit is not a SI unit. SI comes from a scientific body and deals with the natural sciences (physics, chemistry, biology).

On Linux, I have noticed that kiB, MiB, GiB, TiB are popular.
Now, check out your Firefox, SearchMonkey, Chromium and probably a bunch of other apps. They are using 1024 B = 1 kB.

This is what I propose. Let’s make everyone happy. Let’s satisfy everyone’s needs.
Let’s write highly flexible/configurable programs.

PUT IN 3 OPTIONS:
1. One for 1024 B = 1 kB (and 1024 kB = MB and etc). JEDEC lovers and Comp Sci traditional people will be happy with this.
2. One for the IEC dudes and dudettes.  1024 B = 1 kiB
3. One for the people who prefer to divide and multiple by 1000.
4. It’s even possible to satisfy xaxazak needs with his desire for a capital K.

This way, we achieve maximum happiness joy satisfaction.
That’s what I did in my program.
In fact, if I was in charge of KDE, I would even add the option to have metric time. You just click on a check box and click OK.

Of course JEDEC would use the binary definition; their entire business is basically RAM and Flash specifications. They are basically the only organization with a reason to prefer binary powers of 2, as they define specs for the only hardware where that still is useful in any way :-)

But yes, this should be configurable; I don't think we're ever going to convince everyone of our way being the Right Way and we shouldn't need to. One of the reasons to use KDE is its configurability.

That said, ever since people started talking calling 1440 KiB floppies "1.44 MB" (which is incorrect regardless of what definition of MB you use) the problem with binary units has been evident. Nobody can do power of two math in their head properly. The only significant argument for binary units is tradition/historical reasons (or being compatible with Windows). The thing is, they made sense when storage capacities were small enough that they were small multiples of the unit size (i.e. sector size, usually a small power of 2) since then you end up with "nice" numbers in binary units. But once your capacity is more than 4 or 5 orders of magnitude larger than the base unit (>1 prefix), this stops making any sense because capacities are not themselves powers of two and you're not going to get nice round numbers no matter what. I'm not going to make a big deal about binary units being the default if it ends up like that, but I do think the average user is better served by power of 10 prefixes (and those who prefer power of two prefixes can definitely go and change the setting). Either way it should be a setting.

It’s too bad that this wasn’t nailed down from day 1. It is sort of like some countries have right side road driving while others are left side road driving.

For end users, I have noticed that they don’t care what the default is. I have experience in this. What they care about is the date of modification of a file. If the date is too old, they ask “But I was working on it for 3 h. I saved the file. What happened?”
You also have the situation of “Oh no, I saved the file to my network drive and it is showing a file size of 0 kB. What happened?”.

When it comes to our personal computers, we are the king/queen of that environment. We should be able to configure it to our liking.
Maybe I want to make a driving in the city game and I want left side driving. Maybe I want the people in my game to have yellow skin tone.

This is why there are many Linux distros and all sorts of desktop environments + all sorts of software. They even give you the source code so that some can customize it to their liking.

Please fix this. I want sane prefixes

It's 2022 and in plasma you can configure every possible preference except you can't change something so essential to make people less confused.
This is a regression and a clear imposition that goes against KDE principles and I still don't see any valid reason to not provide choice on this key point.
Anyway thanks for your non-stop efforts on this great DE.

*** Bug 428045 has been marked as a duplicate of this bug. ***

I think this is a duplicate of bug 57240, the same exact reasons described there (and here in this report) still apply.

*** This bug has been marked as a duplicate of bug 57240 ***

The good news is that manually fiddling with the config, as in bug 57240, does indeed still work and lets you get real SI units. Great!

The bad news is that bug predates the existence of the UI in KDE 4.x, and this bug is a *regression* since the UI did exist at a later point and subsequently disappeared. So this isn't a duplicate, since it's a regression. If you can find documentation that the subsequent removal of the UI was intentional and it will not be restored, that would make this bug a WONTFIX, not a DUPLICATE.

AFAICS, the removal of the UI was intentional because it is in-line with the comments in bug 57240 (e.g. https://bugs.kde.org/show_bug.cgi?id=57240#c75).

Also I don't see a UI being added for this.

(From my point of view this is a duplicate because "the ability to switch the size units" is there; but I don't mind closing as wontfix).

The UI was there in KDE4. It was lost in KDE5. Do you have a reference as to why it was removed?

When 57240 was closed, there was no UI and no intent to add an UI. A UI was later added anyway. Clearly someone thought it was important. If it was deliberately removed, that action is not documented in 57240, since it predates the addition of the UI entirely.

I see, thanks for the info.

Let's keep it open until someone who knows that info chimes in (I wasn't around at that time, and git.reviewboard.kde.org was taken down a long time ago, so I don't have easy access to those old code reviews).

I think we should add a UI to switch. The binary units are annoying and unfamiliar to most users (as evidenced by all the bug reports we get about people wanting to switch). Experts may prefer them, but these divergent preferences mean that the logical course of action is to make it configurable IMO.

I would much prefer to have a bug free implementation rather than an Option in the UI.
In fact, this is the first time I have heard that KDE has a solution for this. Thanks Ahmad Samir for linking to 57240.
I had no idea that we could add [Locale]\nBinaryUnitDialect=1 to
home/username/.config/kdeglobals

If the file (kdeglobals) contained comments, it would have guided me.

As for the bug, in Dolphin, if I have no file selected, on the Status bar it shows
68 folder, 6 files (6.4 MiB). It is showing MiB instead of MB.

Also, KSysGuard is still showing HDD space and RAM and network traffic as kiB, MiB, GiB, TiB.
I don’t know. Is there some other config file that I need to edit?
I added
[Locale]
BinaryUnitDialect=1

to file ksysguardrc but it did not fix KSysGuard.

(In reply to vmelkon from comment #25)
> I would much prefer to have a bug free implementation rather than an Option
> in the UI.

Bug 57240's last comment mentioned that apps that do not respect BinaryUnitDialect should receive a bug report. I've done this now for Dolphin (Bug 453853) and system settings (Bug 453854).

I'd like to encourage everyone here to look at their favorite apps and see whether they respect the option or not. If not, please file a bug report for them. You could use my reports for Dolphin and system settings are inspiration/a template. It may be useful to always put Bug 57240 in ‘Depends on’ (just the number suffices) and this bug, Bug 364321, in ‘Blocks’ (toggle advanced fields if needed). That way, we can use this bug to track adherence of apps. (I would say this is a soft block, as the UI implementation need not wait for fixes landing with the apps. If some developer prefers a different organization of all these bugs, go ahead, I do not mind, as long as we can get an overview.)

This is what happens to hidden options: the feature they controls bit-rots because it's not being regularly tested. The fact that this is happening is a strong argument to me in favor of exposing it in the UI so more people can use it and the codepaths it enabled get more use.

(In reply to Nate Graham from comment #27)
> This is what happens to hidden options: the feature they controls bit-rots
> because it's not being regularly tested. The fact that this is happening is
> a strong argument to me in favor of exposing it in the UI so more people can
> use it and the codepaths it enabled get more use.

Nate Graham, yes, a feature needs to be part of the beaten path. When it is used by a lot of people, eventually, bugs get discovered, reported, and cleaned up.

I backed up (I posted a comment)
https://bugs.kde.org/show_bug.cgi?id=453853
https://bugs.kde.org/show_bug.cgi?id=453854

of Erik Quaeghebeur
It is a very easy thing to fix. They can send me the source, I fix it and send it back to them.

Also, I tried Ark. To my surprise, it does obey the BinaryUnitDialect=1 and display KB, MB, GB.

(In reply to vmelkon from comment #28)
> It is a very easy thing to fix. They can send me the source, I fix it and
> send it back to them.

To get fixes into KDE, the workflow is to submit merge requests. See https://community.kde.org/Get_Involved/development#Submit_a_Merge_Request and related material. Dolphin, for example has its source at https://invent.kde.org/system/dolphin.

FYI: I’ve added a bug report (bug 466468) for spinbox support for formatting of byte values (respecting BinaryUnitDialect).

(In reply to Erik Quaeghebeur from comment #29)
> (In reply to vmelkon from comment #28)
> > It is a very easy thing to fix. They can send me the source, I fix it and
> > send it back to them.
> 
> To get fixes into KDE, the workflow is to submit merge requests. See
> https://community.kde.org/Get_Involved/development#Submit_a_Merge_Request
> and related material. Dolphin, for example has its source at
> https://invent.kde.org/system/dolphin.

Hello Erik Quaeghebeur,
I followed the steps to download the KDE framework and whatever and finally, I was able to compile KCalc. It runs. I checked the version and it is the latest KCalc.
That is nice.

I then tried to compile Dolphin and it failed.
The failure has to do with the “script” trying to download and compile things on the fly and then it tells me some component is missing and how to run a command to install it.
So, I ran the command and it installed it.
Then, I ran the script again and it tells me that that same component is missing.

Sorry, I don’t know anything about cmake scripts and how they check what is needed and all that autodownload.
I’m not even sure why they don’t give us a zip file to download and we can all just open it in Qt Creator.

I just don’t know enough about developing on Linux. I’m not even sure how debugging is done.

Sorry. I can’t help any further.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3709

Git commit 875135ef11bc62f239943f59fef780e2a92b9f44 by Méven Car.
Committed on 22/04/2024 at 17:57.
Pushed by meven into branch 'master'.

regionandlang kcm: add binary dialect setting

M  +1    -0    kcms/region_language/CMakeLists.txt
A  +97   -0    kcms/region_language/binarydialectmodel.cpp     [License: GPL(v2.0+)]
A  +22   -0    kcms/region_language/binarydialectmodel.h     [License: GPL(v2.0+)]
M  +1    -1    kcms/region_language/kcm_regionandlang.json
M  +93   -47   kcms/region_language/kcmregionandlang.cpp
M  +2    -0    kcms/region_language/kcmregionandlang.h
M  +4    -0    kcms/region_language/localelistmodel.cpp
M  +92   -28   kcms/region_language/optionsmodel.cpp
M  +17   -0    kcms/region_language/optionsmodel.h
M  +7    -2    kcms/region_language/regionandlangsettings.cpp
M  +1    -1    kcms/region_language/settingtype.h
M  +79   -1    kcms/region_language/ui/main.qml

https://invent.kde.org/plasma/plasma-workspace/-/commit/875135ef11bc62f239943f59fef780e2a92b9f44

I just wanted to say thanks, I remember the original bug reporter, and post, and I'm grateful that a solution has been found. Thank you!