This article is within the scope of WikiProject Linux, a collaborative effort to improve the coverage of Linux on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
This article is within the scope of WikiProject Free Software, a collaborative effort to improve the coverage of free software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Debian is within the scope of WikiProject Open, a collaborative attempt at improving Wikimedia content with the help of openly licensed materials and improving Wikipedia articles related to openness (including open access publishing, open educational resources, etc.). If you would like to participate, visit the project page for more information.
I think it impossible to solve this elegantly, due to the Idiocracy, which decides quite too much in the Wikipedia:
We need a better explanation of "data compression algorithm".
We need better understanding of how software is regularly some (compiled) implementation of an idea/definition/standard
We need to make clear that only US law grants patents on software (= patents on algorithms). So a Debian server hosted in France or pretty much anywhere on this planet where there are no patents on algorithms, it should be perfectly ok to offer the FOSS implementation of lossy data compression algorithms… Why don't we? There is no US law in France, is there?
We need to stop using the words "technology", "multimedia" and "standard" sooo often.
A question: are we to assume, the people reading this article know what a "computer file" is, and what a "file system" is? User:ScotXWt@lk 18:22, 29 August 2016 (UTC)
Being a Linux distribution Debian consists almost entirely of free and open-source software written by 3rd parties. But some software is being developed by Debian, e.g. deb (file format), the Debian installer, Advanced Packaging Tool, and maybe some other stuff. Not sure whether this Debian-own software should get an own section. User:ScotXWt@lk 18:41, 29 August 2016
@Rwxrwxrwx: The releases life cycle table is a essential case for every OS article. It is true that there is a page named Debian version history which provides this table, but it is need to be included in the main article for more and better visibility and accessibility, like below articles:
If you want, you can start a discussion about whether the Version History article should be merged back into the main article, but having most of its content duplicated in the main article is a bit silly. — Rwxrwxrwx (talk) 18:03, 10 November 2016 (UTC)
I am agree with you, but as I said, this table is extremely essential, I suggest that content of the "Release history" section moved to its main article (Debian version history) and only this table with information about phases of support provided, like below articles:
Debian version history should be merged back into this article. Per WP:SPLIT, a split is not justified on grounds of excessive size (30k readable prose here, 3k there) or unrelated content (they deal with the same thing). — Rwxrwxrwx (talk) 11:03, 11 November 2016 (UTC)
In the previous discussion I was agree with your last sentence, not with your suggestion (merging), because this article is already bloated and confusing. I think it is better that all or most content of the "History/Release history" section moved to its main article (Debian version history) and only the release life cycle table with information about the support phases provided, because that table is extremely essential and useful. Below article are good examples:
First, it would help if you could clearly indicate your "vote" above in the usual way ("Merge" or "Don't Merge" in bold at the start).
In WP:SPINOFF#Article_spinoffs: "Summary style" meta-articles and summary sections, it says that where a section of an article has been spun-off into a sub-article, the corresponding section in the main article should be "condensed into a brief summary section". Now, if that section has become "bloated and confusing", then it should be heavily trimmed back and useful material transferred to the sub-article. The sub-article is reserved for the lengthy technical details, which in this case would include the full list of support periods, package counts, kernel versions, etc. Duplicating that in the main article totally defeats the purpose of the sub-article.
However, as stated in the merge proposal rationale, the article sizes (at 30k and 3k prose, plus tables) are not big enough to justify a separate version history article, as explained in WP:SPLIT, which is why I propose they be merged (and duplicate material deleted in the process).
Don't Merge While there isn't a ton of text in the version history article, the visuals do take up a substantial amount of space, and are a nice tool. If anything, we should be expanding the version history article (same goes for Linux Mint). — Preceding unsigned comment added by 18.104.22.168 (talk) 01:11, 18 November 2016 (UTC)