Talk:Btrfs/Archive 1

Archive 1

Clarification

When is "At the time of this writing" ??? --Xerces8 (talk) 09:38, 30 April 2008 (UTC)

It is still true right now. I clarified this in the article. -- intgr [talk] 21:25, 30 April 2008 (UTC)

Features

Should the current and planned features be separate? The current format of "It includes, or has plans for:..." sounds more like marketdroid misleading than an objective feature listing. --Shrike (talk) 12:54, 11 January 2009 (UTC)

Enterprise-ready file-system

What is an "enterprise-ready file-system"? Rbanffy (talk) 21:00, 31 August 2009 (UTC)

Time

It's fairly critical, I think ext4 has a much more precise time string, like milliseconds. It's missing from this article. —Preceding unsigned comment added by 86.150.225.99 (talk) 15:06, 4 December 2008 (UTC)

The time string (time stamp) of btrfs and ext4 are both accurate to one nanosecond. 173.20.39.44 (talk) 08:06, 10 July 2010 (UTC)

Ownership vis a vis ZFS

Has Oracle said anything official about their level of commitment to this code base now that they also own ZFS? 121a0012 (talk) 05:56, 16 October 2010 (UTC)

As far as I can tell, Chris Mason's account from April 2009 is the only one that can be considered "official". -- intgr [talk] 10:52, 16 October 2010 (UTC)

"Murder your wife"

We need a "protect reiser from bs" bot to rid us of lines like this. Fortunately it's gone now, but honestly, the guy's in prison getting what he deserves, let's leave stupid lines out of wiki >.> —Preceding unsigned comment added by 142.166.47.97 (talk) 17:00, 22 November 2010 (UTC)

I guess 142.166.47.97 is talking about this edit by 62.149.34.40 (talk · contribs), which was reverted 8 minutes later by 134.223.116.200 (talk · contribs). (That joke has long since ceased to be even vaguely amusing.) I've left messages on both talk pages. CWC 08:06, 23 November 2010 (UTC)

Subvolumes?

Could someone explain it more, what are subvolumes? Or provide some pointers. Keeps me thinking of mount points, but we do have mount points already, right? What's this then about exactly? --91.154.67.174 (talk) 23:10, 15 August 2008 (UTC)

http://www.h-online.com/open/The-Btrfs-file-system--/features/113738 —Preceding unsigned comment added by 209.242.136.34 (talk) 22:02, 4 August 2009 (UTC)

More on the topic. Subvolumes sound much like what ZFS calls a file system in the pool. They can be mounted individually, and can also nest, which sound much like ZFS. Is that a proper analogy? If so, perhaps this should be mentioned in the main article, as it would help those familar with ZFS to understand what a subvolume is. 129.74.228.45 (talk) 20:14, 6 December 2009 (UTC)

I'm in the process of trying to explain clearly how it fits together. My victim audience is a ZFS user. Once we've worked out an explanation that satisfies, I'll add it to the btrfs wiki and to here. Darksatanic (talk) 13:55, 22 January 2011 (UTC)

Data deduplication

Is this still happening? It isn't on the btrfs wiki and I haven't found any real evidence of happening that isn't a wishlist from 2009 interviews/btrfs articles.

There's been patches for a prototype posted to the btrfs mailing list recently. There was quite a bit of discussion about the details and methods used. Darksatanic (talk) 13:58, 22 January 2011 (UTC)

Importance level

This file system is widely mooted to replace ext4, the next primary linux file system. It has backing from oracle, a rather major player. Could I suggest that it be set to medium importance? —Preceding unsigned comment added by 86.13.28.140 (talk) 04:21, 4 March 2011 (UTC)

Broken by design

He said so according to the given references, yes. The developers, however, answered and explained why his concerns don't affect BtrFS. He, Edward, didn't reply further. So one should assume that his statement is false. —Preceding unsigned comment added by 178.26.217.21 (talk) 15:02, 28 January 2011 (UTC)

• The above appears to be untrue. See comments change log following reversion of a change to that effect. If you disagree, please post your response here. --Treekids (talk) 04:23, 21 March 2011 (UTC)

fsck - or lack thereof

Wouldn't it be prudent to mention in the article that there is no fsck tool for Btrfs? 89.242.185.207 (talk) 15:05, 11 November 2011 (UTC)

Parity based raid levels link

It would be nice to have "Parity-based RAID (RAID5 and RAID6)[13]" link to the current state of raid5 implementation for btrfs instead of the wiki entry for standard raid levels. It represents a major hurdle in Btrfs atm that put's off people from using it. People that are knowledgeable enough to look into btrfs probably know about raid levels .83.101.79.210 (talk) 12:03, 22 March 2012 (UTC)

wiki

Resolved

 – btrfs wiki

This article references the btrfs wiki. Unfortunately that wiki no longer seems to be in operation since the kernel.org compromise. Does anyone know if there are plans to resurrect it (or indeed if it has already been resurrected) in the same location or otherwise? 86.22.248.209 (talk) 00:27, 23 October 2011 (UTC)

In the meanwhile I pulled some out of archive.org but do not have the time to do them all right now. I note the Oracle project page redirects to the defunct wiki site. No idea of the state of the project as a whole; we should rerain from speculation until we get a source for what it going on. W Nowicki (talk) 01:11, 6 November 2011 (UTC)

Actually today it seems back online for me at least. Would be nice to find some kind of announcement? W Nowicki (talk) 17:00, 8 November 2011 (UTC)

The original wiki (https://btrfs.wiki.kernel.org/) is now active again. CWC 09:14, 16 May 2012 (UTC)

Halted?

Resolved

 – The btrfs wiki is again being updated

Perhaps we should mention to the fact that no significant developments seem to have taken place in almost a year. The "news" section in the btrfs wiki itself hasn't been updated since July, 2011. — Preceding unsigned comment added by 190.245.70.191 (talk) 13:37, 27 January 2012 (UTC)

The developers may be slack about updating their wiki, but they continue to produce code. Read lwn.net for details. Cheers, CWC 14:09, 27 January 2012 (UTC)

& also ref to Development of the BTRFS linux file system
--Mkouklis (talk) 05:23, 28 January 2012 (UTC) :)

The explanation is that https://btrfs.wiki.kernel.org/ is READONLY and obsolete, replaced by http://btrfs.ipv5.de/ which does have up-to-date news. -- Sverdrup (talk) 00:17, 7 February 2012 (UTC)

And here's the source, I don't think it has any business on the article page but: [ANN] Editable clone of btrfs.wiki.k.org -- Sverdrup (talk) 00:27, 7 February 2012 (UTC)

I don't think you get to call them "planned" features if NONE of them have been added in two years' time. e.g. take a look at the BTRFS article's history at January of 2010. — Preceding unsigned comment added by 69.211.17.177 (talk) 22:17, 11 February 2012 (UTC)

There will be more BtrFS changes and performance enhancements in Oracle Linux's upcoming UEK R2 release - I think I should add some info in the article too... Raysonho (talk) 00:58, 12 February 2012 (UTC)

The original wiki (https://btrfs.wiki.kernel.org/) is now active again. CWC 09:14, 16 May 2012 (UTC)

BTRFS Issues

There is no topic about BTRFS issues. May I create one (something like Poor performance writing small chunks of bytes) based on this thread? — Preceding unsigned comment added by Fmcavalcanti (talk • contribs) 05:49, 24 July 2011 (UTC)

I would say no. Although the thread is interesting and may be true, WP would not view it as a reliable source. It's also recent and indicts a different poor implementation as a root cause. The material should wait until more reliable sources appear or the speaker's prominence can be shown. Glrx (talk) 14:58, 24 July 2011 (UTC)

I think at least the problem with free space reporting should be mentioned. I ended up finding this out the hard way. Dist-upgrade from Kubuntu 11.10 -> 12.04 almost went completely belly up when i space ran out when there should have been 12 gigabytes of free space. And I also think there might be some truth to the claims of "poor performance writing small chunks of bytes". All package updates (and specifically the dist-upgrade) were agonizingly slow on btrfs. DeeGeeFin (talk) 10:47, 8 May 2012 (UTC)

Package updates are not a performance issue in writing small chunks of bytes. It's a performance issue in sync(), and dpkg calls sync() or fsync() a *lot*. I'm not denying there's a performance problem, but just pointing out that it's not what DeeGeeFin is suggesting. 78.105.124.113 (talk) 22:43, 24 May 2012 (UTC)

Current Status of btrfsck

It might be worth noting that the Btrfs fsck tool (called btrfsck) is now available in rolling release distros like Arch, albeit it has limited functionality and isn't quite ready for prime-time yet. Source — Preceding unsigned comment added by 68.97.183.82 (talk) 21:59, 29 January 2012 (UTC)

Not complete since it does check but not repair. -- Sverdrup (talk) 22:08, 5 February 2012 (UTC)

And now it does repairs of the extent tree, plus a few other lesser fixes. There's more to come, too. 78.105.124.113 (talk) 22:45, 24 May 2012 (UTC)

Possible source: Chris Mason talk

Chris Mason gave a talk with the title "Btrfs Filesystem: Status and New Features" on 5-Apr-2012. You can watch it here, or download it as a .webm file. The Linux "KernelNewbies.org" site recommends this video in its summary of Linux 3.4, which includes several improvements to btrfs.

I suspect this talk would be a good source for our article, but I haven't watched it yet (still downloading). Has anyone else watched it? More importantly, does anyone have a transcript of the talk, or any detailed reports about it? Cheers, CWC 14:41, 27 May 2012 (UTC)

Btrfs checking and recovery

As stated btrfsck is "relatively new code". So, what about btrfs scrub start,which dive deeper in filesystem checking and exist for a long time (more than btrfsck). — Preceding unsigned comment added by 2A02:8422:1191:6E00:56E6:FCFF:FEDB:2BBA (talk) 21:17, 17 February 2013 (UTC)

Filename and path limitations

1. The infobox states filenames are <= 255 bytes. However as I understand it, the actual limitation is that btrfs has a limit of 255 bytes under linux (which is due to limitations of the VFS layer), but by design if VFS were not setting this limit, btrfs itself supports far longer filenames. If this is correct then the infobox should state something like "255 bytes under linux (due to limitations of VFS layer); native limit otherwise: XXX bytes".
2. Needs to provide info on maximum path length.

FT2 ^{(Talk | email)} 10:58, 28 May 2013 (UTC)

Other possible references

• Linux Foundation interview of Chris Mason by Amanda McPherson —Preceding unsigned comment added by AlastairIrvine (talk • contribs) 08:44, 30 June 2009 (UTC)

There are two points on the "planned features" list requesting citation. But they are both mentioned directly on the main btrfs site => first reference. I'd change it but I have no idea of how to use the editor. I hope this was the right place to put it. — Preceding unsigned comment added by 62.2.43.87 (talk) 08:57, 11 July 2013 (UTC)

LZ4 and Snappy should be removed from infobox

I don't think LZ4 and Snappy compression formats should be listed in the infobox because they aren't mainline at the time of writing (http://git.kernel.org/cgit/linux/kernel/git/mason/linux-btrfs.git/tree/fs/btrfs/compression.h?h=next lists on ZLIB and LZO), there's no timeline on when they will be accepted and in the case of snappy it's not clear that it would ever be accepted. Further details on https://btrfs.wiki.kernel.org/index.php/Compression#Are_there_other_compression_methods_supported.3F .

87.115.170.109 (talk) 07:52, 15 September 2013 (UTC)

Contradictory Assumption

Hi there.

I've read the wiki article and found a problem with this line :

Btrfs 1.0 (with finalized on-disk format) was originally slated for a late 2008 release,[5] but as of June 2010[update] is still not yet ready for production use. It has, however, been accepted into the mainline kernel for testing as of 2.6.29-rc1.[6]

The sentence "but as of June 2010[update] is still not yet ready for production use" is an contradictory to the rest of the article. The only reference to btrfs and production use that I could find in June 2010 was this mailing list post : https://lists.ubuntu.com/archives/ubuntu-devel/2010-June/030918.html which is in reference to using btrfs on maverick, the next version of Ubuntu, which would not be production ready. Later in the article it's stated :

"Several Linux distributions (including SLES 11 SP1 and the upcoming RHEL 6) have also begun offering Btrfs as a choice of root file system during installation"

Both these are production Linux operating systems, and contradicts the "not ready for production" line since they are both offering the filesystem.

Hence I'm removing the contradiction. Bain (talk) 12:54, 16 July 2010 (UTC)

Good point, Bain. As I understand it, the official position is that btrfs is not ready for production use, but people have started using it on their personal systems without (as far as I know) any problems.

So the edit you made is spot on. Thanks, CWC 18:54, 17 July 2010 (UTC)

@Bain: btrfs is included in RHEL 6 as a "technology preview", with a big red warning — not as a first-class supported file system. The Ubuntu mailing list post you linked also comes with a big warning "still NOT RECOMMENDED FOR PRODUCTION USE and MAY EAT YOUR DATA". With these warning labels, how can you possibly reach the conclusion that btrfs is ready for production use? If anything, it suggests the opposite. I am reverting your edit. -- intgr [talk] 14:57, 18 July 2010 (UTC)

I've re-added and reformulated the sentence, because removing it entirely seemed wrong to me. It now says that no stable release has been made yet, which is what we know definitively. Whether or not it can be thought of as production-ready is probably in the eye of the beholder. — DataWraith (talk) 15:01, 18 July 2010 (UTC)

Yep, that's better. Thanks! -- intgr [talk] 22:23, 18 July 2010 (UTC)

Since the official btrfs wiki says that the file format is not unstable anymore and makes the point quite clear, I think it is in order that the first paragraph be updated accordingly. Lifeboy (talk) 18:37, 25 August 2014 (UTC)

Perhaps we should note somehow that Btrfs still isn't production-ready, despite the fact that the lead section now only states that Btrfs' on-disk format is stable? Anyway, got it cleaned up and fixed a reference. — Dsimic (talk | contribs) 16:48, 28 August 2014 (UTC)

I find it interesting that you removed my citation and put a link directly to a wiki instead. Surely the source wiki will change over time or may vanish completely? This is why I put a web citation link instead? Lifeboy (talk) 17:14, 28 August 2014 (UTC)

That's a good remark, and one of the reasons why wikis (in general) aren't supposed to be reliable sources. Perhaps we could simply include a quotation into the reference, or maybe we could go with using Wayback Machine instead? — Dsimic (talk | contribs) 17:25, 28 August 2014 (UTC)

I used [webcitation] since it was created for this purpose and provides a formal way to cite a source. After all, the original reference for btrfs' unstable status came from webcitation. See their [FAQ], which explains the advantages, as well as the [consortium's member list]. Lifeboy (talk) 18:11, 28 August 2014 (UTC)

Well, ok, please feel free to restore the archival part of citation; just as a note, using |archiveurl= also requires |archivedate= to be specified. By the way, can anchors be used in the URL provided that way, so it points to the exact section? — Dsimic (talk | contribs) 18:28, 28 August 2014 (UTC)

Cloning across subvolumes

The article currently contains "As a result, this operation only works within the boundaries of the same Btrfs file system, while it can cross the boundaries of subvolumes since version 3.6 of the Linux kernel". I took this out on the grounds that it is excessive detail, but I notice that it has been restored. The source says "Cloning is not allowed to cross vfsmounts, i.e. when two subvolumes from one filesystem are mounted separately" and I have just tested this and the source is correct. I would suggest the article is currently misleading and believe at least "while it can cross the boundaries of subvolumes since version 3.6 of the Linux kernel" should be removed. TwoTwoHello (talk) 13:53, 27 November 2014 (UTC)

Hello! Well, it was me restoring that content back at the time; however, I'd say that we might want to leave it as part of the Btrfs § Cloning section. The Btrfs has been changed at a quite fast pace over time, so it should be useful to have such changelog-style information available despite the fact it might look like excessive detail. At the same time, I've cleaned it up a bit so the potentially misleading information is no longer conveyed. Hope it makes sense. — Dsimic (talk | contribs) 20:20, 27 November 2014 (UTC)

Superblocks

The Superblocks section claims "Superblock mirrors are kept at fixed locations:[77] 64 KiB into every block device, with additional copies at 64 MiB, 256 GiB and 1 PiB. When a superblock mirror is updated, its generation number is incremented. At mount time, the copy with the highest generation number is used. All superblock mirrors are updated in tandem, except in SSD mode which alternates updates among mirrors to provide some wear leveling."

And (https://btrfs.wiki.kernel.org/index.php/User:Wtachi/On-disk_Format#Superblock) claims "Note that btrfs only recognizes disks with a valid 0x1 0000 superblock; otherwise, there would be confusion with other filesystems. "

I haven't seen any relevant information in (http://btrfs.ipv5.de/) indicating anything about the current state of superblock use.

In old link - now seemingly defunct but still cached by Google - (https://oss.oracle.com/pipermail/btrfs-devel/2008-February/000513.html), Chris Mason writes that:

Yes, SSDs are a big target of mine, and so the parts that are not currently
favorable for SSDs will be changed. The big problem right now is that btrfs
writes to a fixed super block for every commit. That will change to a
rotating set of fixed super blocks to lower wear and improve redundancy.

• Is there any information if btrfs still hammers the same fixed superblock locations?
• Is there any information about the implications that a broken primary superblock will make btrfs no longer recognize the disk, implying that this single (but constantly updated) data structure is a single-point-of-failure?
• Is there any information about the implications for SSD wear leveling if no change has been introduced? And especially how common is it that the SSD uses region-based wear leveling in which each superblock will only rotate among a limited number of flash blocks of the SSD? Or where the two first superblocks might even end up in the same wear-leveling region?

Zyxxel (talk) 22:56, 28 December 2014 (UTC)

Btrfs vs ZFS

Resolved

 – Comparison of file systems

Btrfs is a direct GPL-licensed competitor to ZFS, due to ZFS's unusual anti-GPL licensing. As such, this article could benefit from a comparison with ZFS, since ZFS is really the standard to be beat. Badon (talk) 05:06, 16 September 2011 (UTC)

Yes, it would be great to have such a comparison (and even better to include HAMMER as well). However, it would be hard to do one ourselves without infringing Wikipedia's ban on "original research". I suspect we'll have to wait for someone (an academic? a news-site?) to publish a comparison, which probably won't happen until the btrfs crew release a production-quality version. Cheers, CWC 17:37, 16 September 2011 (UTC)

Afaict the killer feature of zfs is the ability to provide "better than raid" protection for your data through a combination of checksums and raid like techniques. The impression I get (and finding up to date info is hard given that the wiki is down) is that theese things are planed but not implmented yet in BTRFS.

Furthermore after years of development the BTRFS guys don't even seem to have delivered a proper fsck which makes it hard to take them seriously.... 86.22.248.209 (talk) 14:26, 23 October 2011 (UTC)

It should also be mentioned that Btrfs is heavily inspired by ZFS, which explains why Btrfs has/will have similar functionality as ZFS. — Preceding unsigned comment added by 213.114.153.172 (talk) 20:38, 12 February 2012 (UTC)

There is already a Comparison of file systems. --Tim (talk) 13:52, 1 October 2016 (UTC)

Btrfs falsely described as "deprecated"

The article states that "the release notes of Red Hat indicate that Btrfs is deprecated", which is apparently contributing to the oddly pervasive belief that Btrfs itself is somehow problematic. But, given that this is the release notes for a paid support service, not the release notes for a software product, this doesn't actually mean anything beyond that Red Hat no longer offers their paid support service to cover their customers' usage of Btrfs.

Red Hat has neither the authority nor the capability to affect Btrfs for good or ill, given that they've never really developed it at all. See Josef Bacik's post about Red Hat involvement with Btrfs. The most they can do is configure their own kernels with the Btrfs module disabled, or refuse to add an installer option to format the root filesystem of a new Red Hat system as Btrfs.

Speaking as a longtime user of Btrfs on a Linux distro which ships recent kernel releases, it's never given me problems. AFAIK no community distro has said anything bad about Btrfs at all, and Red Hat is the only commercial one to do so. And Red Hat has unusual and exceptional reasons for being unwilling to deal with Btrfs -- they cannot do downstream development of Btrfs in order to safely merge new fixes into the elderly kernels they need to continue supporting, since they have no in-house kernel developers who work on Btrfs. In contrast, SUSE has a great deal of in-house expertise, hence why, according to the existing reference, "Suse reaffirmed its commitment to Btrfs".

This information is IMHO too important to be hidden away in references while the Wiki article itself seems to imply the exact opposite. I would change "Btrfs is being deprecated" to "Btrfs is no longer receiving paid support", and "no further updates planned to be included" to "no further updates planned to be backported into Red Hat stable kernels", etc. -- Eli Schwartz (talk) 16:13, 1 January 2018 (UTC)

Pronounciation

I thought it's supposed to be "Better FS" not "Butter FS". I don't know, what sense "Butter FS" should make but I can see one in "Better FS" :-) —Preceding unsigned comment added by 212.202.52.182 (talk) 20:53, 22 August 2008 (UTC)

The full name is "B-Tree FS". 79.233.81.133 (talk) 15:50, 16 October 2008 (UTC)

No, it's pronounced as "Butter FS". You can hear that at talks about the file system. —Preceding unsigned comment added by 78.42.30.223 (talk) 16:18, 16 November 2008 (UTC)

In the video she says "It's called Butter FS or B-tree FS, but all the cool kids say Butter FS" and not "It's called Better FS or B-tree FS, but all the cool kids say Butter FS". So I will change it. 79.233.87.236 (talk) 16:40, 27 November 2008 (UTC)

It's definitely "Butter FS", in both the referenced video and LWN link. I'd never even heard of "Better FS" until I saw it on this page. Fixed it again. Azuriel (talk) 04:26, 21 January 2009 (UTC)

It's pronounced both way, according the btrfs author Chris Mason (source). Benjamin Pineau (talk) 19:27, 1 August 2009 (UTC)

I've added a reference to Chris Mason saying it is pronounced as both BetterFS and ButterFS. —Preceding unsigned comment added by 81.106.97.225 (talk) 19:41, 4 June 2010 (UTC)

He was clearly joking when he said that. Here's the source that 81.106.97.225 provided. Sorry, but I have reverted the edit to the article. -- intgr [talk] 21:53, 4 June 2010 (UTC)

Here is a recent web cast by Chris Mason where btrfs is pronounced "Butter FS": ([1]) (registration required). jthetzel (talk) 22:40, 26 October 2010 (UTC)

ButterFS is a silly name. They are passing up a huge marketing opportunity here. I mean, I know this is FOSS and all but they probably want their software to benefit as many people as possible, right? ButterFS? Butterface? Really? And look at this: btrfsck.c Do you want that pronounced (in one's head anyway) as "Butter Fuck" or "Better Fuck"? I know which I would prefer for any software I gave a care about.

Be that as it may, this is entirely the wrong place to be arguing over such things. Wikipedia is an encyclopaedia - we (as editors) are simply meant to report facts and explain ideas. All the sources say it is pronounced "butter eff-ess" so that is what the article says. Your arguments have no place here. Take it up on a mailing list or something. --Imroy (talk) 15:39, 12 June 2010 (UTC)

ButterFS might be a silly name. That's why its name is NOT ButterFS, but btrfs. It's pronouciation is "Butter FS" and that's a big difference. QT is pronounced "cute", but its name is not Cute, it's still QT. "ButterFS" is a pronounciation which allows usage in a fast and easy way. If you talk about btrfs, you clearly don't want to always pronounce each letter ("b t r f s") or always say "B-Tree FS", which would be the technically correct way of calling it, hence btrfs stands for "B TRee File System". "Butter FS" is a fast way, but keep in mind that "Butter FS" is the pronouciation(!), so you would never write "Butter FS" in a text about btrfs, you would always use "btrfs". —Preceding unsigned comment added by 92.224.49.132 (talk) 19:10, 16 September 2010 (UTC)

Given that it's among the cream of file systems and is based on the copy-on-write (COW) principle, Butter FS is the ideal name. ;o) 92.3.212.212 (talk) 10:13, 14 August 2017 (UTC)

I pronounce it Bitter FS. Maybe I should write a website and then have it referenced? 210.165.180.184 (talk) 10:03, 5 January 2012 (UTC)

I have been unable to find any official reference to Btrfs as "B-tree file system". Additionally, according to Oracle, Btrfs "is not a true acronym". I'll now edit the article to reflect this. 85.64.33.163 (talk) 20:22, 28 April 2018 (UTC)

I don't see how this is helpful, or relevant, especially not in the opening paragraph. It is not clear to me, at all, what is even meant by it not being a true acronym, as the very same sentence in the cited page says, "As the btrfs file system uses B-trees in its implementation, its name derives from the name of those data structures..." What is clear is that there are numerous references to BTRFS using B-Trees in this wiki page, in the btrfs.readthedocs.org wiki, and in many independent publications. It seems prudent to remove this statement from the opening paragraph. This action is taken in good faith. If there is more to the discussion which I am missing, let's talk about it. If there are good reasons to include this statement, there should be more detail about the distinctions, and the statement should be moved to a more relevant section of the wiki page, like the Design section, or a Controversy section if there is a lot more to the story. — Preceding unsigned comment added by Kron Kyrios (talk • contribs) 19:09, 16 May 2023 (UTC)

References