Template talk:Infobox OS/Archive 1

Archive 1

Archive 2

"version" vs "current version"

I don't understand what the purpose of having both "version" and "latest stable release" is - many uses of this infobox will be on things which have had multiple versions (even something as seemingly singular as Windows 95 or Windows 98), so only the latter will make sense. On some articles, the two can be used for an internal number and a more descriptive release name, but if that is the intended distinction, a better label is needed - "latest stable version"/"latest stable release" - and I would think just using "Name (number)" would be fine in most cases. Or is it just meant to be a kind of "overarching" version number (so, Win98=4.10), in which case what does one put on Ubuntu? - IMSoP 15:51, 26 August 2005 (UTC)

This is a catch all template. It is most likely that we will need to create a new template for Linux distributions. - Ta bu shi da yu 03:09, 3 September 2005 (UTC)

Somebody already removed the bit I was talking about. I don't think that Linux distributions are any more of a "special case" than any other OS - we have an article on Mac OS, one on Microsoft Windows, and one on Debian, each of which have had many releases; we also have an article on Windows Me, which really only had one release, but that's OK, we still want the same box, because for instance Windows 95 did have multiple releases. - IMSoP 12:04, 3 September 2005 (UTC)

Outsourcing of latest release version/date

See Template talk:Infobox Software. --Melancholie 23:31, 5 September 2005 (UTC)

User Inferface

Since 84.121.33.199/84.121.3.160 wanted it, I cleaned up their additional option so that it could be used for multiple operating systems. Janizary 21:54, 16 November 2005 (UTC)

It's not an additional, but instead mandatory option now.

Unless you figure out how to make existing articles using this template look decently (that is, not the way Windows 95 looks now), I'm moving the updated template to a new name. --tyomitch 05:57, 17 November 2005 (UTC)

Done, fixed that myself now =) --tyomitch 19:36, 18 November 2005 (UTC)

More information in the info box

I believe that there should be more places for information in the info box. This could especially be useful for GNU/Linux distributions, where information such as the source model, kernel, and even screen shots are usually more or less the same. Possible extra pieces of information could include something along the lines of:

• The philosophy or purpose of the OS (i.e. server, desktop, developer, beginner, localisation, all-encompasing, etc.)
• The target audience of the OS (i.e. beginners, advanced users, persons in a particular profession)
• Package management / update model (i.e. complete binaries, binary patches, source and with / without dependency resolution)
• Installation media (i.e. CDs (+ no. of), network / Internet install, etc.)

Currently only small amounts of information provided are really useful for the largest category of OS's there is. I would like to have some comments on this, and see if we can do anything about it all. There could concievably be more pieces of information that could be added that would be relevant for all OS's. James Hales 09:37, 18 April 2006 (UTC)

• Good suggestions, but I have a few issues:
  • Philosophy: far too nebulous, can't apply this to all O/Ses. Also leads to pontificating, something we want to avoid (ever seen OS advocates at work? It's not pretty).
  • Target audience: I'd like to see what you'd get for a Mac OS... again, too nebulous and subjective.
  • Package management/update model: now that is a good idea.
  • Installation media: also a good idea. - Ta bu shi da yu 08:30, 19 April 2006 (UTC)

Supported platforms? NicM 16:19, 19 April 2006 (UTC).

Also a good idea. When I get a chance I'll do it. - Ta bu shi da yu 03:53, 20 April 2006 (UTC)

Supported platforms is a good idea.

The idea of having philosophy / target audience was so that there would be some useful information for a lot more Linux distributions. Granted, OS's such as Windows, Mac OS, Fedora and Debian all try to cater to every possible niche, but there are only really a few that do that. A lot of Linux distributions go in for specialization, i.e. distros intended mainly for servers, software development, localization, etc. so listing those things would be useful. Otherwise I'd just like to see some more fields perhaps to make the OS sidebar more useful to the myriads of OS's out there with more or less the same kernel, source model, etc.

Perhaps the philosophy / target audience problems could be fixed by having a set list of options to choose from. I understand the concerns about the philosophy, so perhaps we could use another word to describe the property, i.e. purpose, which would hopefully prevent advocates from going overboard. James Hales 07:03, 20 April 2006 (UTC)

I don't thing installation media is a good idea. It's whatever the current technology is for when the software was packaged. Dread Lord CyberSkull ✎☠ 05:25, 20 April 2006 (UTC)

It does vary from OS to OS, i.e. how many CDs are required, if there is a DVD version, or if there is a network / Internet install version. James Hales 07:03, 20 April 2006 (UTC)

I have put in two new fields: supported platforms and package management. It seems that someone has already put in an update model one. The reasoning behind the placement is that it is just underneath the update model placed there before, and the latest release date, which I believe should go first, I believe that the website should be placed down the bottom and I believe that these fields fit in amongst releases rather than kernel/default ui/license. An example of the use of the new fields can be seen on the Fedora Core article.

I would still like to see some way that the purpose / target audience can fit in. Maybe we should fall back to Wikipedia policy which is that information should be verifiable. The purpose / target audience should be what the producers / developers market it as, and not what the users believe it is. --James Hales 08:56, 30 April 2006 (UTC)

I don't like the "package manager" field name, it doesn't fit in well with any of the *BSDs ports systems. How about "Software installation method" or suchlike? NicM 09:31, 30 April 2006 (UTC).

I agree. Software installation method itself sounds long, but it could apply to a load of things, so is good. Perhaps something that is shorter and sounds better could be chosen later, but it gets the idea across perfectly and and also allows for OSs without managers per-se, i.e. where you might have to compile software manually, or use crappy, third-party installation EXEs like Windows. --James Hales 09:51, 30 April 2006 (UTC)

Change width of left column

The width of the left column is, currently too short, so that text in it is several lines, leaving lots of ugly, unprofessional space-consuming extra space. How can this be fixed? - Centrx 00:14, 10 March 2006 (UTC)

Is anyone going to fix this ugly infobox or help me fix it? - Centrx 22:23, 6 May 2006 (UTC)

I tried to fix it by surrounding the long bits with . It did not yield very attractive results. This might be improved by making the whole infobox wider. Some of the longer pieces of text we might not be able to help, as stopping them from wrapping would require the box to become too wide. --James Hales 11:35, 7 May 2006 (UTC)

Package manager should be package format

Among the many other problems with this infobox, "package manager" should instead be "package format", such as "DEB" and "RPM", as this is important in terms of inter-operability, etc. Different software can use different package management systems, but interpret the same format. Overall, this item should be removed anyway. It is only really relevant to Linux distributions in terms of comparisons, and it is not so important that it needs to be at the top of every page. -- Centrx 22:31, 6 June 2006 (UTC)

It is optional. And it would be best IMO to mention both manager and format, eg "APT (.deb)". NicM 07:35, 7 June 2006 (UTC).

You need two separate fields. - Samsara (talk • contribs) 09:44, 7 June 2006 (UTC)

I don't think that is necessary. Just add a note saying it would be preferential to mention the package format if appropriate. NicM 15:12, 7 June 2006 (UTC).

Icons

Hello, I thought it would be nice to have icons for the various systems. Obviously to integrate them easily into the template they would have to be renamed to match the name parameter: ((Image:OS_{{{name}}}_icon.png))

--Iancarter 20:20, 18 June 2006 (UTC)

This isn't permissible on Wikipedia. There is no valid Fair Use rationale for including copyrighted logos on so many pages. The Linux icon is fine, of course, but all the others will have to go. Warrens 20:49, 18 June 2006 (UTC)

1. "so many pages"? it would only be on the respective OS page (via the template), which I believe already contain logos in huge high quality formats.
2. "no valid Fair Use rationale": Nominative use allows references to products that would otherwise not be identifiable (plus: the image license clearly references the copyright owner). Having icon versions would allow articles to contain nicer (or less text-cluttered) list and tables.

WP Policy is not clear about this.

--Iancarter 22:05, 18 June 2006 (UTC)

Please read Wikipedia:Logos, and Template:Logo. It should be clear that the only valid purpose for using a copyrighted/trademarked logo on Wikipedia is for illustrative purposes in the article that discusses the subject which the logo represents. That's the extent to which Wikipedia tolerates fair use. Practically speaking, this means that the official Microsoft logo is valid on the Microsoft article page, but not elsewhere in the encyclopedia. There is a lot of precedent for this on Wikipedia; for example, you can have a look at the edit history for Template:Windows-stub to see various attempts to include a Microsoft Windows logo on hundreds of pages; these have been quickly reverted by many different editors. Warrens 23:59, 18 June 2006 (UTC)

so, I just read all articles and discussions; I still do not see a problem - WP:Logos states that it is OK to use the logo as long as it will not negatively affect the owner. I am sure you agree that the OS template is something very similar to the OS article (which is why it exists). I also agree that placing a logo in a stub template is not a good idea because the stub articles might not be NPOV. Having and using logos is not the problem, it is using them in a context that is unknown, has negative connotations, or might negatively affect the business of the owner (even if negative might be NPOV like missing features in a comparison). No sane business will have anything against free brand-strengthening if it is neutral or even slightly positive (but that again could conflict with WP:NOT). I tried to look up Microsofts trademark policies but that takes me to a nice 404 :-) hmmmm. I would also like to know if you work for a major OS company or are a trademark lawyer. --Iancarter 01:02, 19 June 2006 (UTC)

Who I work for is completely irrelevant to any discussion regarding article work on Wikipedia. We're here to write a free encyclopedia -- stay focused on that. Whether you see a problem or not isn't really relevant, either; it is going to be a problem, and that's why I've reverted your changes. We have to make sure we avoid adding any unnecessary non-free material into the encyclopedia that doesn't materially contribute to it. For fair use, one "current" logo is sufficient for illustrative purposes, and additional logos may be used only when the logo is discussed as part of an article. Additional logos for purely decorative purposes are unnecessary and harm Wikipedia's case for fair use of this material. You and I don't have to like that or agree with that, but that's how it is.

Anyhow, in accordance with what the fair use rationale given in Template:Logo states, we have logos for all the major operating systems (and specific versions thereof) in the encyclopedia, and associated with the articles on those operating systems. They're almost all of pretty good quality, too. These are sufficient; let's leave it at that and focus on improving the content of the encyclopedia itself. Warrens 01:36, 19 June 2006 (UTC)

Arg: ignorant and unbacked statements like that's how it is and it is going to be a problem are neither helpful nor good conduct. I read your comments, i read the policies and your edit history - and still I see no problem with my suggestion. You must excuse that I am forced to perceive your edits and rationale as unreasonable and egoistic. I am not willing to participate in the edit wars your claim of dominance on OS articles has caused you to enter. I asked you politely and rethorically what your profession was because your actions and comments are judgemental or biased - I am questioning your knowledge on trademarks and the WP policy. Give it a thought and take it down a notch. I ll just keep out of your way - all I tried was to suggest something that would "improve the content" by creating visual reference not "decoration". Sorry if you find this offensive - feel free to delete this post. --Iancarter 02:53, 19 June 2006 (UTC)

Warrens knowledge of Wikipedia policy is apt for this case. Saying that that's how it is is fair enough here because Warrens does not have to justify Wikipedia policy, but you have to follow it to contribute here. Take it up elsewhere if you disagree with the policy. Wikipedia does not allow unnecessary use of trademarks. They are allowed once for the visual identification of a corporation, product, etc. but are not allowed to be used en masse, so to speak, i.e. in a template. If an OS page does not have a logo on it, you might be able to include a logo there, but you must justify fair use for on that page (the reason logos/trademarks are not allowed in templates).

If you want a reference, go to Wikipedia:Fair use and search for "They should never be used on templates". That is on the topic of fair use of images.

Adding a 16x16 icon to a template does not add anything to a page except to make it a tiny, tiny bit prettier. Visual identification is not a good justification for a 16x16 image which is very unclear. No loss. Note also that some trademark holders place guidelines on use of their trademarks and logos, often setting a minimum size for their logos (which is usually well above 16x16). An example I can think of is the Firefox and OpenOffice.org trademarked logos (look at the guielines for Firefox). --James Hales 13:51, 19 June 2006 (UTC)

OK, thanks - that makes more sense. Sorry for the hassle. (I still like icons) --Iancarter 18:28, 19 June 2006 (UTC)

Price/Cost

What do you think about the idea of adding a parameter cost to the template. It would indicates the eventual OS cost (or the caption "free of charge" if it's free) expressed in the currency of the state where its authors live and a possible link to a part of the article which talk about the different price of the product in more detail (around the world). So for exemple, for Microsoft Vista it could be the average and a link to the table that details it. 16@r 14:27, 22 October 2006 (UTC)

Programming languages

Since "language" isn't documented here (though one can figure it out by looking at other templates, e.g., the Infobox_Software template) it's used in some places to list supported programming languages. RSTS/E shows an example.

That's not right because the link on "language(s)" points to natural language. But this suggests a field for "programming languages" might be useful.

Paul Koning (talk) 22:49, 15 December 2007 (UTC)

Size

I would add the size field, because this is important to compare Live USB distros (see Comparison of Linux LiveDistros). --Mac (talk) 08:25, 5 March 2008 (UTC)

screenshots statement

The person adding the screenshots included a silly statement: Do NOT change the screenshot unless there is BIG change in the UI. When taking screenshot, please resize your window (e.g. 640*480), disable your extensions and use the default theme.

I recommend an entirely different set of guidelines &mbash; the screenshot in the infobox should be "new-os" i.e. as basic as possible:

• Make the screen the most popular resolution for the time: 1024×768. This accurately reflects what most users would be seeing when they install the OS.
• Create a new user called "Wikipedia" or "wikipedia" — this should disable all extensions, set the UI to the default theme and background and place the OS defaults into the default places. If you OS does not do this(!!!) I suppose you should do it manually.
• Open a Window with the default file browser and a window with the default web browser, pointed to the default folder and the wikipedia page respectively.
• Change the screenshot EVERY time there is ANY change in what you see of the UI (in this screenshot i.e. the file browser and the web browser). There is no reason to to keep up with every change in OS's.
  • Aree except the thumbnails transcribed onto pages should be from low resolution screen shots unless high resolutioni is really important. It just make everything more visible, on the image page then you can ink to a full rez screenshotScientus (talk) 10:38, 26 December 2008 (UTC)

Additionally, I think you should be able to add a "used-os" screenshot in the OS of the article that includes things like extensions, custom themes, and little things like your desktop icons are different, that exemplifies different applications, maybe this screenshot could be at 1280 × 1024 just because that would allow you to show more. --Ctachme 20:20, 21 May 2005 (UTC)

Uh... all the images are shrunk down to about 250-300px... what resolution did you think you would see them at? I took this from the software infobox. - Ta bu shi da yu 04:42, 22 May 2005 (UTC)

I'm not talking about the thumbnails, I'm talking about the screenshots themselves, obviously, the thumbnails will be smaller. --Ctachme 13:28, 22 May 2005 (UTC)

Ah. Well, all I can say is a) be bold, and b) I took this from the software infobox. Go ahead and update it! - Ta bu shi da yu 23:38, 22 May 2005 (UTC)

OS Families

Another tiresome "roots" debate going on at Talk:Mac OS X. Is there any place that the OS families are defined? MFNickster (talk) 06:23, 15 September 2009 (UTC)

Obviously not, or there wouldn't be a 200k-long discussion of it. There are various trees for unix-like systems, but obviously OS X's heritage is a little more complicated. Chris Cunningham (not at work) - talk 13:15, 15 September 2009 (UTC)

I only meant for the purposes of the infobox - is it completely up to the editor? MFNickster (talk) 15:47, 15 September 2009 (UTC)

Yep. Basic consensus thus far has been that if there's any controversy as to what particular family a Unixish system is derived from then Unix-like is an acceptable compromise for the infobox, though. Chris Cunningham (not at work) - talk 15:58, 15 September 2009 (UTC)

Great! ...except when an editor won't accept the acceptable compromise! ;-) MFNickster (talk) 16:53, 15 September 2009 (UTC)

In this particular case, I'm reasonably sure that AlistairMcMillan (talk · contribs) has it right in this edit. Chris Cunningham (not at work) - talk 20:18, 15 September 2009 (UTC)

LTS (Long-term service) field?

It is common for software to have LTS versions, which may differ from the lastest stable releases. So it seems like it should be important to have a latest_LTS_version field in this infobox. Jason Quinn (talk) 23:54, 25 February 2009 (UTC)

That's a good idea. Coincidentally, it's also been suggested in Template talk:Infobox software. If there is no opposition, this should be added. --Waldir ^talk 12:35, 6 June 2010 (UTC)

Preceded by / Succeeded by

Over on the {{Infobox OS version}} template, I added two new parameters that were requested a year ago. Would anyone be against adding these params to this template?

| labelxx =  Preceded by
| dataxx = {{{preceded_by|}}}
| labelyy = Succeeded by
| datayy =   {{{succeeded_by|}}}

– Kerαunoςcopia^◁_galaxies 01:13, 10 June 2010 (UTC)

What is language

The usage information does not define the language keyword, and it could be interpreted as any of the following potentially useful data:

• Programming languages in which the OS is implimented
• Programming languages that the OS supports
• Natural languages used for messages from the OS Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:18, 14 June 2010 (UTC)

Data for proprietary operating systems

In the IBM world there is frequently an order number for programs, even for free programs. Should that be put in as part of the name or left out?

In the case of MVS, there are separate order number for JES2 verions and JES3 versions. Should both numbers be provided? Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:24, 14 June 2010 (UTC)

Language

See Template talk:Infobox Software#Language 16@r 14:28, 23 November 2006 (UTC)

That really casts no light on the usage. The field might plausibly refer to any of

• The languages in which the OS is implemented
• Languages implemented in the OS
• Languages for which add-on processors are available
• Natural languages used in OS commands and messages.

IMHO the first three are important enough to merit separate fields, and I could make a case for the fourth as well. If, as seems to be the case, one of the first three is intended then the Wikilink should be to Programming languages rather than to Natural languages. Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:38, 25 October 2010 (UTC)

"working state" field

What do you say about changing the "working state" field to be called "development status", as {{Infobox software}} uses? That seems more intuitive to me, and it'd be nice to have a standardized nomenclature for this field across such similar templates. --Waldir ^talk 12:26, 6 June 2010 (UTC)

Working state sure sounds strange and I'm all for standard nomenclature. 85.76.189.136 (talk) 16:38, 22 January 2011 (UTC)

latest_preview_version

The visible text for latest_preview_version and latest_preview_date shows up as "Latest unstable release". Is there any way to change it so that it actually shows as "Latest preview release"? Using the word "unstable" is not really accurate. An OS may be stable but just not publicly available. Best to not misinform people. --Jimv1983 (talk) 04:21, 25 October 2011 (UTC)

Default user interface

Should the caption link to operating system user interface instead of user interface? Incnis Mrsi (talk) 12:18, 8 January 2013 (UTC)

Add once_supported

Hi could some one add once_supported please Skybliei (talk) 08:50, 9 April 2013 (UTC)

Hello. You have not explained the function of the parameter. In other words, what exactly are we supposed to add? Best regards, Codename Lisa (talk) 10:07, 10 April 2013 (UTC)

Add size

Hi please add

|lablexx = Size 
|datayy = {{{size|}}}

Please

90.218.191.245 (talk) 19:41, 5 July 2013 (UTC)

Hi. What is this size parameter going to contain? Download size or installation size? Best regards, Codename Lisa (talk) 14:00, 6 July 2013 (UTC)

both download size and installation size 109.153.189.230 (talk) 14:04, 7 July 2013 (UTC)

Than I am afraid I have to oppose. Giving two pieces of information in one parameter is wrong. Besides, there is usually no source telling the size of an OS installation because an OS footprint is a very disputed and controversial topic. OSes take up a unique amount of disk space on each computer and it is a common knowledge that not everything in an OS folder or even an OS file is part of OS itself. It is going to spark unending edit wars between editors who think the article is always showing the wrong version. I'd rather oppose having this nightmare. Thanks. Best regards, Codename Lisa (talk)

well then installation size 176.26.62.46 (talk) 15:39, 8 July 2013 (UTC)

OS family in Linux distros

According to my talk page, in Linux distros-related article field needs a simple clarification in its documentation. If any distro is based/has its parent, like Linux Mint, CentOS or just Ubuntu, the field OS family looks like:

Unix-like, based on *** (for example  Debian)

However, Debian will have only Unix-like, because doesn't have its parent, it's absolutely separate system, which is not based on any other. Since I edit Wikipedia, I see this rule in many significant Linux articles, that's why and many other editors (like Elizium23) think that is widely standard and should be respected. So, let's reach the consensus to add this to the /doc. --Rezonansowy (talk • contribs) 23:13, 7 November 2013 (UTC)

This should not be present in any Linux articles, even those with a "parent". The OS family is Unix-like, only. Yworo (talk) 23:59, 7 November 2013 (UTC)

May I know, why? --Rezonansowy (talk • contribs) 01:12, 8 November 2013 (UTC)

Yes, why the restriction? It seems unnecessary. It seems quite informative to give a slightly more detailed (yet still concise) pedigree of the OS in question. "Unix-like" doesn't even tell us it's Linux. The Linux distribution family is a sub-family that seems like useful information. Why leave it out? Elizium23 (talk) 04:42, 8 November 2013 (UTC)

Because what constitutes an OS family is defined by computer science. And the instruction on the template have not been changed. I believe an RfC would be in order before doing so, but it's incorrect at this time to add qualifications to the template. Better would be to add a "Parent OS" field to it. Please don't misuse the family field, add another field dedicated to the purpose you envision. Yworo (talk) 20:10, 14 November 2013 (UTC)

It could also cause problems with "lineage" debates. If a distro starts as a fork of one branch and then begins to merge with another branch, what is it based on? And at what point does a distro become its own entity? At which point is it sufficiently different that it is no longer based on that original distro? Walter Görlitz (talk) 20:22, 14 November 2013 (UTC)

It is a simle solution for this problem: Unix-like, based on Debian (1-5) and Slackware (6-8) --Rezonansowy (talk • contribs) 21:09, 14 November 2013 (UTC)

I don't agree with you, let me quote the doc - The name of the family/line of operating systems.... I think that Debian is parent for Ubuntu, so Ubuntu is in its family, for me it's a simple solution. --Rezonansowy (talk • contribs) 21:03, 14 November 2013 (UTC)

And I don't agree with you. Why do you neglect to quote the explanatory note as well: "Family - This is the operating system family, examples include Microsoft Windows, Unix-like and Mac OS. Linux and Mac OS X are not OS families." This is not going to be resolved by two or three editors discussing it on this talk page or by edit warring over it. As I said, feel free to start an RfC, but without that level of input, there is not an adequate consensus to change this. Yworo (talk) 15:07, 1 December 2013 (UTC)

Hi. Unix-like is definitely not a family, just as "Java-based software", "DirectX-based video games" or "all people wearing red shirt" are not family. Members of this hierarchy are not even produced by the same company; how can they be family? I think the sense in family metaphor was entirely lost on the person who added it. Now, Linux can be regarded as a superfamily like Windows, which consists of Windows NT, Windows CE and other families.

Besides, when it comes to linguistics, there is arbitrary membership issue to consider. You see, acting is a form of art; but an actor would never introduce himself as an "artist". (An artist conjures up an image of a geeky person with strange clothes or paintbrushes behind one ear. An actor conjures up the image of a suave rich person on a red carpet.) Likewise, Mac OS X might have connections to Unix but no one of right mind says Mac OS X and Android are family; they are competitors, the opposite of family.

Best regards,

Codename Lisa (talk) 19:51, 1 December 2013 (UTC)

I had not seen this previously. I would say "Unix-like", can be a family in the sense of an "OS Family", that is OSes the are compatible, in the computer science-sense, with the same programs. This however should not include Android or iOS in my view. This however doesn't work well for Windows (RT eg.). See also JavaOS and related Dalvik as an integral part of Android. comp.arch (talk) 16:33, 15 April 2014 (UTC)

OS family - Android is missing.

I have established, with sources and have not been reverted, that Android is its own OS family. When is a family a family? When it has children? For Android it does. For iOS, it probably never will, still I would think it would also be its own "family" in the compatibility sense. What defines an OS? What programs you can run on it. You have Android apps that run on Android and not in general on Unix-like (and vice versa, as Android is only very restrictedly Unix-like). iOS is also distinct from OS X and "Unix". Maybe we should rename the field name also? Any thoughts? comp.arch (talk) 20:32, 14 April 2014 (UTC)

Hi. Android is a family? What are its family members then? Best regards, Codename Lisa (talk) 05:17, 15 April 2014 (UTC)

Amazon's Fire OS is compatible or at least mostly (they say 75%+ of apps if I recall). They have Dalvik and that is probably 100% compatible but the OS as a whole is proprietary, so you can't really be sure (but see no reason why they would try to be incompatible (at that level)). I guess because they add APIs (and/or remove and maybe peripherals is the reason you do not get 100% compatibility). From the article I see at least the Nokia X Software Platform, Alibaba Group's Aliyun OS and more? comp.arch (talk) 09:12, 15 April 2014 (UTC)

Yor definition of OS family is wrong: if OS is forked, it doesn't automatically make it a family. Eg. Berkeley Software Distribution with its countless forks and derivatives is not an OS family. Android in this regard is strikingly similar to NEXTSTEP: both feature custom framkeworks on top of Unix system, and both come in flavors. FWIW iOS and Android share OS family. — Dmitrij D. Czarkoff (talk•track) 10:27, 15 April 2014 (UTC)

What makes a family? I would say members that are related. What do you propose? iOS and Android have millions of mutually incompatible programs and you want to say they are related how? Operating systems: "the operating system acts as an intermediary between programs and the computer hardware [..] Examples of popular modern operating systems include Android, BSD, iOS, Linux, OS X, QNX, Microsoft Windows,[3] Windows Phone, and IBM z/OS. All these, except Windows, Windows Phone and z/OS, share roots in UNIX." How would you organize these in a family tree? Also RISC OS wouldn't fit. comp.arch (talk) 13:30, 15 April 2014 (UTC)

Hi. Family is entirely a matter of branding. Members of the family must have partially similar names. For example, Windows family contains Windows NT, Windows 9x, Windows Phone, Windows Compact Embedded, etc. They are all "Windows". For open-source software which are forked left, right and center, we use "distribution" or "distro"; e.g. Linux distros.

I myself have used the word "family" in discussions by mistake but I am hoping I haven't done it in the article. Best regards, Codename Lisa (talk) 14:45, 15 April 2014 (UTC)

So you are saying Ubuntu would be a family (including xUbuntu, Lubuntu, Ubuntu Touch etc.). And Android possibly (including Android KeyLime and Gingerbread etc. and/or Android Wear). Happens to be compatible also, mostly, within, less so for Windows *. Would you then not use "Unix-like"? As documentation is inconsistent and not clear on purpose: "Microsoft Windows, Unix-like and Mac OS. Linux and Mac OS X are not OS families" but also "For example: 'Mac OS X'". I do not see a field for "distro" or compatibility, that is needed. comp.arch (talk) 16:15, 15 April 2014 (UTC)

Did I say family is a matter of branding? It means "Lindows" and "Windows Defender" are not members of Windows family just because they have "Windows" in their names. (Hence your point about Android Wear.) Gingerbread is a version of Android, not its siblings.

Documentation is okay, but perhaps you've forgotten that in English, we speak in synecdoche.

My recommendation: Take it easy. Not taking it easy just hurts you. Best regards, Codename Lisa (talk) 16:49, 15 April 2014 (UTC)

Members of family share common native environment and interfaces. Eg. Android, GNU, various BSD flavors and commercial Unixes share the same set of interfaces, which allows all of them run the same software. Android, MacOS X and iOS have their unique libraries on top of this set of interfaces, which doesn't stop them from belonging to the same family. FWIW Andoid may be turned into full-featured Unix system (even with Android market software), so it is practically indistinguishable from numerous commercial Unixes that offered custom incompatible libraries. — Dmitrij D. Czarkoff (talk•track) 19:01, 15 April 2014 (UTC)

Free distribution guideline

Please add the parameter "Free distribution guideline". Read Free distribution guideline for more information. For instance, Trisquel GNU/Linux uses GNU GFSD as free distribution guideline] while Debian uses DFSG --David Hedlund (talk) 19:51, 20 April 2014 (UTC)

Not done: Hi. You have not provided sufficient data as what this parameter is supposed to accept and what is its impact on all operating system articles in Wikipedia in general. Best regards, Codename Lisa (talk) 20:04, 20 April 2014 (UTC)

All GNU/Linux distributions listed at Category:Free software only Linux distributions follow the GNU GFSD. Free distribution guidelines determine if licenses are free or not. --David Hedlund (talk) 20:06, 20 April 2014 (UTC)

We already have the |license= for that purpose. Best regards, Codename Lisa (talk) 20:12, 20 April 2014 (UTC)

Source model

For the record, I meant source model to mean open or closed source. - Ta bu shi da yu 11:21, 16 May 2006 (UTC)

Yes, but how is that different from "license", and what is appropriate to say for a distribution that includes open and closed source software, and that may be developing some of its specific packages as open and some as closed? - Samsara (talk • contribs) 12:36, 16 May 2006 (UTC)

Well, my idea is that you can divide up the software world into two classes of software: open sourced software and closed source software. It helps those who don't know that what source model each license is run under. Is there an issue with this, by any chance? I'm flexible on how we do things. - Ta bu shi da yu 06:04, 22 May 2006 (UTC)

There really is no point in doing that since anyone who puts in a license usually wikilinks it to the license article, giving the reader info on what it means. Dread Lord CyberSkull ✎☠ 07:20, 22 May 2006 (UTC)

Some OS's can come under many different licenses. Saying open / closed source is just like summarising that "the licenses used are open / closed source style licenses". I think it is a good field; mighty useful. It is redundant, but so is all of the other information in the Infobox. --James Hales 14:49, 23 May 2006 (UTC)

...Because most of the infobox is nearly pointless. - Centrx 21:08, 24 May 2006 (UTC)

I agree with James Hales, the field is useful and is different from licensing. --SF007 (talk) 04:13, 15 January 2012 (UTC)

Wait, what's a source model?

I think the license field is adequate. What are the technical issues related to deleting this field? It appears this template is used on 250 articles. --71.161.215.238 02:02, 14 August 2006 (UTC)

It probably should at least be made clear that the license vs. source model fields are somewhat redundant, and that they are optional (I assume?) This won't stop people reinserting stuff into those fields left, right and center, of course, which would be the ideal situation. But I guess to not frustrate people who find the fields useful in their articles, you'd have to create a second, crippled version of this template, which is not an elegant way at any rate. Not to mention spoken articles... - Samsara (talk • contribs) 10:54, 14 August 2006 (UTC)

I think this is a complete invented classification and think it should be deprecated it as well. I'm deleting this documentation:

Source model - this does not mean licensing model. The primary source models are open source, closed source and shared source; however, if an OS is referred to by its vendor/provider as "free software" and all the software distributed with it is licensed with an FSF approved software license, then free and open source software may be used. If the source is provided but the use is restricted, use, commercial open source software. Things like Free software, Proprietary software, and Shareware are licensing models and should not be used here.

This is especially confused because using "open source" as the "source model" could include proprietary software that comes with the source code. This would conflict with the working definition of open-source software. Additionally, "shared source" can be either proprietary or free software. This kind of confusion isn't helpful to readers. Granted, it is compelling to try and categorize this aspect of software and its source code, it quickly becomes problematic to be helpful. --Ashawley (talk) 20:48, 7 September 2009 (UTC)

There are more than two significantly different models, and the FSF does not consider an unrestricted license to be free. There are at least 4 models that I am aware of.

• Closed. The user has no access to the source.
• Proprietary. The user has access to the source, but is not permitted to make it publically available. He may be permitted to share modifications with other licensed users.
• FSF GPL: the user is allowed to sell derivative works but must license them under the GPL and provide source code.
• BSD. The user may do what he wants with the source code.

Note that the FSF does not like the BSD license, which is less restrictive than the GPL. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:42, 25 October 2010 (UTC)

The term "open source" has a conceptual problem: it mixes up software licensing with development methodology, using a term "source model" whose meaning is unclear. "Open source software" is a criterion about how a program is developed. If a program's source is available under a certain kind of license, then it is "open source".

There is an "open source development methodology", what ESR called the "Bazaar" model. But the two do not necessarily go together. Which one does "source model" refer to?

If a single person develops a certain program, and releases source code once a year under the GNU GPL or the modified BSD license, that program qualifies as "open source". If he never releases intermediate versions and declines to discuss its development with anyone, he does not practice the "open source development methodology", but the program is "open source" anyway. What should be entered as the "source model" of that program?

It is also possible to practice the "open source development methodology" but release the program under licensing that is not "open source". What should be entered as the "source model" of that program?

Is "source model" really a way of characterizing licenses, or does it refer to development methodology?

--David Hedlund (talk) 19:14, 21 April 2014 (UTC)

Hello, David. You've asked a lot of question for which the answer is already in your message or questions that beckon non-existent problems. In short, a source model refers to source code and nothing else. "Open source", "closed source" and "shared source" are distinct enough: If the source code is accessible to all, then it is open source. If it is accessible to few third-parties, it is shared source. If it is a trade secret, it is close source. For open source, as long as the source is not changed, release of the source code does not even need to be recurrent. Best regards, Codename Lisa (talk) 11:40, 22 April 2014 (UTC)

New field proposal: development started

Because of a long-running dispute over the initial release date of Unix, I'd like to propose a new field "development started" to this template, to signify when development on an OS started. That could be useful for experimental operating systems as well. Is this a good idea, or is the use case too restricted and should we just put a text in the "released" field over at Unix to explain the situation? QVVERTYVS (hm?) 14:48, 22 April 2014 (UTC)

Hi.

• I have two things on my mind about this proposal. First, I am not sure I am getting you right: Are you saying there is a dispute and so, you are proposing something that is already disputed? (What is a marijuana reference anyway?)

• Second, the distance between development start date and release doesn't mean anything alone. For one thing, to correctly judge what this distance means, we must know how many milestones there were, how long they took, whether there was a pause or interregnum there or how strenuous each phase was. And let's not forget that development starts after the design phase, so the developing company was probably hard at work even before development start. Conclusion: I think this is a piece of intricate detail and must appear in the History section of the article where enough context can be given.

Best regards,

Codename Lisa (talk) 16:08, 22 April 2014 (UTC)

What I'm proposing is to add a field that signifies when development started, which may be interpreted as "start of design" or "start of implementation" by those using the field. 1969 is not disputed for Unix; there was no significant design phase, all the sources will tell you Ken Thompson simply sat down at a scrap computer with an idea, implemented it, then convinced his colleagues that it was a good idea and they applied for funding.

Then comes the problem. Unix development started in 1969 as a skunk works project. A manual was published (internally inside the Bell system) in 1971. That could be the first release date. It left Bell Labs for other AT&T divisions in 1972, it was shipped to universities in 1973 or 74, and it was commercially available ca. 1977 (see Version 6 Unix). We could cram a lot of this into the release date field, but the start of development doesn't really fit. That would mean we need to list a different date than everybody else, including the BBC. 1969 is engrained in the collective mind as the starting date of Unix. No-one in the computing community seems to care enough about the first release date to mention it.

Now this might seem very Unix-specific, but the thing is that many interesting operating systems never get released. For research OSs, the publication date of the first paper is more interesting than when it was first shipped (or offered) to anyone else.

I don't entirely get the marijuana thing either; it was vandalism on the page, but got the discussion going :) QVVERTYVS (hm?) 18:06, 22 April 2014 (UTC)

I second this proposal: there are systems that were widely discussed (and thus became notable) before being released. I believe the same field may be added to {{Infobox software}} if everything goes right with this template. — Dmitrij D. Czarkoff (talk•track) 10:44, 23 April 2014 (UTC)

Hi, Qwertyus. Now I get it. But I prefer tables that incorporate {{version}} instead. This is currently being practiced. Besides, I really don't think it is a good idea to increase the length of infoboxes. But these are all just my opinion. Whatever gets implemented is probably for the best. Good luck. Best regards, Codename Lisa (talk) 12:34, 23 April 2014 (UTC)

Do users really need to see "Initial release" date above other relevant information?

My edit summary: "(Not rocket science.) Moved "Initial release" down (below Latest and Preview). It's annoying to have to read past the Initial release every time it's present, when it's NEVER the first date I'm looking for."
(Here's the change, though diff does not show how simple it actually is (cut, move, paste; adjust the numbers).)

00:03:57 later: "Reverted 1 edit by A876 (talk): BRD revert. It is your own fault for using Wikipedia for discovering release dates. Wikipedia mission is different." (user:Codename Lisa)

"BRD", as in "BOLD, Revert, Discuss". Okay, let's.

I kind-of expected a frightened panic-button revert on a Template edit. (Change is scary. Acceptance is too unlikely to be true.) But I could not anticipate the exact "reasoning" that would be used. I never expected such vengeful thuggishness. What lowlife scum I must be, to use Wikipedia for something that [you presume] I want to use it for. Why, I'm desecrating the Mission of sacred Wikipedia (which surely is NOT accommodating lowlife scum such as me). The fact that I am irked occasionally by seeing the least-useful information first - why, I deserve that suffering and much much more. I should even be made immortal, so that I can suffer the deserved pain of seeing my own ugly selfishness, forever.

Wikipedia and this template are very old! If any meaningful change was required, why, surely it would have already been made by the Geniuses that be. (I expected an argument like this, but didn't get it. However, it is implicit.) There is a threshold for annoyance - small errors often are not annoying enough to provoke an edit. By recurrence, this little objection finally reached my annoyance threshold and I acted. This reversion will drive up my threshold for testing changes - it's harder to do anything knowing in advance that it will be casually smacked down. Will it please the Powers when I cease attempting such vile disruption? Or will they feel unsatisfied when they don't get to smite the blasphemer as often?

I committed the atrocity of writing my comment in the first person! Why, correcting something that occasionally annoys me makes Wikipedia more useful ONLY FOR ME, and couldn't possibly make it less annoying or more useful for other users.

If anyone reads an article about an operating system or other software product, WHY is the AGE of its first release more important to them than whether it is maintained and updated? For Jimbo's sake, give someone a chance at common sense. If I'm not supposed to "[use] Wikipedia for discovering a release [date]", then why not get rid of the Infobox altogether? It seems like pure reactionary bigotry: undo any change you see, and make up any insulting surrealistic justification you like. (After reading the editor's history and talk pages to see what they deserve). Bold, Revert, Intimidate. Bold, Revert, let Die in committee.

To the unlikely person who ever comes across this suggestion on this Talk page, please consider the idea on its own merits, agree or disagree, and let the bureaucracy continue preventing anything helpful from happening. -A876 (talk) 00:42, 31 May 2014 (UTC)

Weird, I was pretty sure that it was me who reverted your edit. Two reasons:

1. It is already absolutely trivial to identify right dates, and your change improves nothing in this regard.

2. Infobox contents are logically arranged, with dates coming consequentially. Your edit breaks this for nothing.

As you may notice, your little selfish theory has nothing to do with reality. — Dmitrij D. Czarkoff (talk•track) 06:42, 31 May 2014 (UTC)

Initial release date should come first for the same reason that birth dates come before death dates: It forms a range, a period of time. It is also compatible with the flow of article's prose.

Try assuming good faith and commenting on the contribution only; you'll be surprised to see how lovely people are about it. 91.99.225.214 (talk) 09:15, 31 May 2014 (UTC)

So Dmitrij D. Czarkoff is also Codename Lisa? How sweet, but isn't there a stern rule about this? Or are you not technically a sock puppet if you only share a soul but not a body?

1. It improved something. Start date is sometimes present, sometimes not.

2. Oh, I see, my edit destroys Logic. Obviously I knew I was taking the dates out of sainted Chronological order. Current - Future - Past is also a sensible order for things. It's not like no thought went into this.

3. The added unsubstantiated insult ("your little selfish [hypothesis]") only confirms.

Yup, birth–death. I can't argue against that. "Abraham Lincoln (February 12, 1809 – April 15, 1865)." Now that is a format where it is "absolutely trivial to identify right dates". But chronological order in an article can get burdensome – for weak unchecked example, must the Windows article always begin with Windows 1.0? Few are really looking for thatinformation, so it is pushed aside.

I did not make the first personal attack. B-R-D does NOT prescribe reverting, so it is no excuse ("It is not the intention of this page to encourage reverting.") – so why cite it? Thus a real reason is required. The vindictive edit-excuse provided is no explanation. The most relevant advice for any edit seems to be write for the enemy. Anticipate every shallow, unconsidered reaction that will come up when the other editor does not assume good faith, but assumes my idiocy, and assumes that their shallow, unconsidered reaction is a complete answer and definitive, when they really just didn't like something. I would like to "comment on the contribution", but it is still hard to see an Undo as a "contribution". It is a de-contribution, a reversion, whose only substance is the edit-excuse provided. Editing quiet pages is like playing White in chess. Returning to subject:

Do users really need to see "Initial release" date above other relevant dates? -A876 (talk) 04:29, 1 June 2014 (UTC)

What a joy!

1. You have three editors saying that users really need to see "Initial release" date above other relevant dates. What makes you think that asking another time would help pushing your side?

2. BRD, and particularly R in it, does prescribe reverting. Seeing someone damaging templates for no apparent reason even more so.

3. Yes, Windows article must begin with Windows 1.0, and Microsoft article must not begin with Windows. We are working on encyclopedia here, not the yellow pages of internet.

4. I am not Codename Lisa. If in doubt, please proceed to WP:SPI.

5. "your little selfish theory" is not an insult – it is accurate neutral summary of your comment. And of your second comment as well. If in doubt, please proceed to WP:ANI.

6. There is no evidence that anybody assumed idiocity on your side. At least I did not, despite your attempts to make me doing so.

Being pointy and accusing others is not helpful even when you are right, which obviously is not the case here. — Dmitrij D. Czarkoff (talk•track) 07:26, 1 June 2014 (UTC)

1. Three editors did not say exactly that. If they thought about it, they would not say it. ("Need", indeed.) Don't put words into their mouths. Codename Lisa undid my evil, selfish repurposing of Wikipedia. (abrasive) You said I broke logic (unlikely) and "improved nothing". (so?) 91.99.225.214 said "Initial release date should come first for the same reason that birth dates come before death dates..." (insufficient, irrelevant.) (Always knee-jerk; zombie-logic; status-quo; no one else ever had a point.) I sometimes run my life by the numbers - as they say, if TEN people say I'm drunk, I'll probably go sleep it off. (It's surprising, though, how many people will stand up to prevent correction of a blatant wrong (in other places), as if status quo is the only Truth.)

2. BRD is NOT carte blanche to automatically revert every change; it says so. It even links to Wikipedia:Revert only when necessary. I found some interesting notions there: "Don't revert an edit because it is unnecessary — because it does not improve the article." "Whenever you believe that the author of an edit was simply misinformed, or didn't think an edit through, go ahead and revert." (that must be me, eh?) "Reverting [of itself] tends to be hostile..." "No edit, reversion or not, should be made for the purpose of teaching another editor a lesson or keeping an editor from enjoying the fruits of his crimes." (See?) My favorite: "When reverting, be specific about your reasons in the edit summary..." (i.e., just say you don't like it, ha ha.) Templates are watched a little more closely, but does that justify a prior reversion comment like this one (not applied to me): "This user is too careless. I will not risk having these changes without someone having vetted it first." (WOW!) — (followed by not vetting anything)? It can get a little high-tech with all this coding and extended reach — but I don't expect guideline pages on editing Templates any time soon.

3. Abraham Lincoln article does NOT begin with his boyhood - the intro jumps straight to his presidency. Infobox can be seen as another intro - it certainly is NOT the [chronological] article body; it's another summary.

4. Fact: Codename Lisa reverted my edit. Somehow you said "Weird [my new nickname?], I was pretty sure that it was me who reverted your edit." (In case you wondered where I got the idea that you were Codename Lisa - that statement says so.) And then you went on to state reasons why [you or she] did what [you or she] did! (Whatever. I agree you are not Codename Lisa.)

5. No need for Mom and Dad. Somehow I found myself smacked down. I objected.

6. I had a point. Sometimes it looks like people just don't try.

Moving screenshot to the bottom?

Hi.

I am writing to inquire about edit #614639082 by Technical 13 which moves the screenshot of the OS to the bottom.

Both the edit and its edit summary ("stacking the two images looks horrible") surprised me. For one thing, editors go through a lot of efforts to make sure the logo and the screenshot look good and artistic together. For another, most infoboxes including {{Infobox}}, {{infobox software}}, {{infobox web browser}}, {{infobox OS version}}, {{infobox OS component}}, {{infobox video game}} and others (I am sure there are others) show the screenshot at the top. Why must this one deviate from that consistent format? Oh, and non-free images are often uploaded with the rationale of helping to identify the subject of the article and deliberately putting them where scroll bars hide them isn't exactly conducive to that objective.

Overall, my thought was that we should act on this one exactly as we are encouraged to edit, when it comes to templates: Radical changes need discussion first.

Best regards,
Codename Lisa (talk) 06:33, 28 June 2014 (UTC)

I am all for keeping screenshot in upper part of infobox simply because it provides valuable graphical clue about the subject of the article. Unlike illustration in the article's body, which are there to illustrate the particular aspects of the software, this one serves the same purpose as lead section, and its content and placement should follow the same rules. — Dmitrij D. Czarkoff (talk•track) 09:07, 28 June 2014 (UTC)

• @Lisa and Dmitrij: {{Infobox OS}} was brought to my attention by Wikipedia:Teahouse/Questions#Infobox Problem where I found this version of VxWorks where the stacking of the two boxes on top of each other looked bad and just didn't flow making it hard to gain anything from either of the images. Rob had created two separate infoboxes for the sole purpose of adding some kind of space in between the two images. I consolidated the infoboxes into one template (as it should be) and then modified the infobox template to address the root issue of the two images looking bad without some kind of separation in between them. I'm not opposed to it being near the top, but there needs to be at least "some" information in between them because I find there is a loss of perception exactly where one image ends and the next starts and only a line or more of content (context) is going to fix that. — {{U|Technical 13}} ^{(e • t • c)} 11:23, 28 June 2014 (UTC)

• Hello, Technical 13. Before I start, you need to double-check your diff links. (Holocaust?) Now, small problem requires small tools. VxWorks deviated from the standard 64px size for rectangular logos. At 64px, the image looks okay. Wide logo size is only provisioned for logos with wordmarks.

Best regards,

Codename Lisa (talk) 01:14, 29 June 2014 (UTC)

• Lisa, are you saying we should force |logo_size = {{#if:{{{screenshot|}}}|64px|{{{logo_size|64px}}}}}? I'd be okay with that, but otherwise I expect there are other infoboxes out there that "deviate" from the standard (where is that documented with a warning saying using other sizes is bad, I may have missed it) size for logos ("it should fill the width of the box, of course"). — {{U|Technical 13}} ^{(e • t • c)} 02:18, 29 June 2014 (UTC)

• No. I am definitely not saying that. All I am saying is that red attracts the most attention, grey on white attracts the least attention, such a big logo and such a small screenshot back there were not optimal combinations. Like I said, editors spend time making sure the article looks good. VxWorks editors hadn't. 64px is not a policy; it is a discovery.

Best regards,

Codename Lisa (talk) 02:24, 29 June 2014 (UTC)

FWIW I am all for limiting height of logo in infobox, although to my knowledge we only control width... — Dmitrij D. Czarkoff (talk•track) 07:46, 29 June 2014 (UTC)

One single case is not enough to warrant this change. In this case, the problem is Robpater himself. A chain of his edits has concerned me: e.g. he changed back IA-32 to x86 despite I having dropped him a note about it and him have promised to go over it. If it transpires that he is a stubborn person, any hard limit that we apply probably drive him to use alternative means of circumvention. On the other hand, his only fault might have been using "Save" button instead of "Preview" button and not getting his priories right. We should wait a bit longer and see how things unfold. I know I have said this at least ten times before but patience is one of the virtues of an encyclopedia writer. Best regards, Codename Lisa (talk) 00:36, 1 July 2014 (UTC)

My comment was based on my experience with multiple pages with huge logos. I have no opinion on Robpater's edits – I didn't look into his edits. — Dmitrij D. Czarkoff (talk•track) 04:39, 1 July 2014 (UTC)

Oh! Very sorry for complete misunderstanding! Well, yes, if a large number of articles are the source of the problem, it is very natural, yes. (And since you are a veteran in the field of templates, your word has double the worth.) If you wish to elaborate, by all means, I am all ears.

Best regards,

Codename Lisa (talk) 13:09, 1 July 2014 (UTC)

Some changes to Module:InfoboxImage are required to implement my idea. Currently they are pending approval. — Dmitrij D. Czarkoff (talk•track) 21:48, 1 July 2014 (UTC)

True. But before I can agree or disagree, I have to a sample of problem articles and know the hard limit you have in mind. Best regards, Codename Lisa (talk) 01:19, 2 July 2014 (UTC)

I didn't think about any particular hard limit value, and frankly I would prefer to delegate this aspect to editors with better design skills and visual taste then I have. For the testing purposes I implemented 250px vertical limit in this template's sandbox, which is probably too small to be practical. I also implemented hard limit of 800×800 px in corresponding Lua module's sandbox, which is rediculously high and is basically only needed to simplify code. I would appreciate your thoughts on these digits.

Regarding samples: I normally shrink oversized logos on spot. We could temorarily add tracking categories to this template to get a grasp of sizes people manualy specify. Or, alternatively, I could build a script to query all articles with this template and publish a short report. — Dmitrij D. Czarkoff (talk•track) 11:46, 2 July 2014 (UTC)

Ready for use

Moved from Template talk:Infobox OS version

 – following merge of {{infobox OS version}} into {{infobox OS}} — Dmitrij D. Czarkoff (talk•track) 11:22, 13 July 2014 (UTC)

I finally got around to writing the documentation for this infobox... whew, there's quite a bit of it! Hopefully it will serve as a useful guide for implementers of this template. -/- Warren 00:25, 24 September 2006 (UTC)

logo_size

Moved from Template talk:Infobox OS version

 – following merge of {{infobox OS version}} into {{infobox OS}} — Dmitrij D. Czarkoff (talk•track) 11:22, 13 July 2014 (UTC)

I added an optional logo_size parameter for logos that look bad at 250px like this one. It still defaults to 250px, so existing uses should be unaffected. Deco 21:41, 27 February 2007 (UTC)

Style / layout

Moved from Template talk:Infobox OS version

 – following merge of {{infobox OS version}} into {{infobox OS}} — Dmitrij D. Czarkoff (talk•track) 11:22, 13 July 2014 (UTC)

So there's a perfectly good set of defaults for {{infobox}}. These defaults work fine on a great many templates, including most of the computing ones ({{infobox software}}, {{infobox computer}} and {{infobox OS}} being the most obvious). There's no real need IMO to deviate from these at all. I'd appreciate a rationale for why this box demands a special layout. For now, I've conceded to re-adding the colour strip for headers and collapsed the table borders. Chris Cunningham (not at work) - talk 20:12, 2 December 2008 (UTC)

I've made yet more concessions to the old version. A reminder again that this is temporary, until Warren explains what he means by the terms "organized", "too wide" et cetera. However, the current version is practically the same layout as the old, and is by my reckoning more compact. Chris Cunningham (not at work) - talk 08:05, 3 December 2008 (UTC)

If you consider it "concessions", then you haven't thought about why the old template was the way it was.

I've set up User:Warren/Tableau with the current template at the top, and working backwards chronologically to the original template, so you can see the issues all at once.

Width: You've increased the width of the template by 35 pixels without a justification. Again, it's vital to remember that width is at an absolute premium at the beginning of articles. The navbox was 310px before, which is already too wide.

Chances are pretty good that you're using a high-resolution display... try viewing User:Warren/Tableau when the browser is set to fit within a 1024 pixel-wide display. The lead sentences of the article break roughly as follows: "Windows Vista is a line of operating systems[4] developed by Microsoft for" "use on personal computers, including home and business desktops," "laptops, Tablet PCs, and media center PCs. Prior to its announcement on" "July 22, 2005, Windows Vista was known by its codename Longhorn.[5]" The original template layout has enough extra width to add two more words, "Development of", in those first four lines. It's not much, but every bit helps on a smaller screen.

Now you might argue that you needed to make it wider to fit "Default user interfaces" on one line. I don't think we don't need this field at all; it wasn't in the original template design, but someone added it and several other parameters earlier this year without an edit summary or any decent rationale for doing so. With the exception of "Platform support", which is something that has changed from version to version of the operating systems we use this template on, I think all of those fields can go. That'll reduce the perceived need for width.

Organization: The old template had sections for Developer (whose contents are centered), Release Information (which is a table), Support Status (whose contents are centered), and a free-form "Further reading" section. Remember that the only purpose of the navbox is to help the user navigate and find some detail they're looking for quickly. Your earlier design lost all of that organization and turned it into a single long table... long tables are hard on the eyes, and the user ends up not even trying to take it all in. (this is user interface design philosophy) Your revisions have fixed some of this, but I still believe that "is it being supported" is still worthy of its own section.

Border: It should go around the whole thing. There is a visual consistency involved in having the top border of the box align with the first line of the article. Having a logo and part of the information contained in the navbox floating free adds a bunch of empty space around the top, which is disconcerting. Again, this is UI design philosophy.

Also, the colons are missing. The text on the left serves as a label for the text on the right. Colons are a visual cue. Again, this is UI design philosophy.

I keep bringing UI design up because I work professionally as a user interface and user interaction designer. Organizing and presenting information on computer screens is my life's work. So I like to think what I know what I'm talking about here. You self-identify as a system administrator on your user page, so I understand why you'd value consistency and the technical aspects underlying how the template works. But that's really not important as far as the final output is concerned -- what's important is the answer to the question, "will the user look at the article and be helped, or be frustrated?" Everything you do with template editing should serve only that purpose. Warren -talk-

Hey, my current job isn't under discussion here. Let's not go pulling rank. To address these points:

1. Width. The default width of an {{infobox}} is 22em. This is used by all {{infobox}} templates by default. If you think that this value is too high, then it should be addressed at template talk:infobox, which will benefit the whole project and not just a handful of articles on various Windows and Mac OS versions. The same goes for the additional spacing caused by not making the borders collapse - if you think this should be the infobox default then please request that centrally and it'll benefit everyone. Turns out that just shortening a couple of labels fixes this without resorting to hacks. With the borders uncollapsed (which is the default), the infobox is currently only a handful of px wider than the old one, and doesn't result in any wrapping of text relative to the old one if the first paragraph of your test page.
2. Organisation. I agree that there is some value in breaking up long lists of key-value pairs if it helps readability. This can be easily done using section headers. The current version splits at the same points as the old one.
3. The infobox is a table. Using a caption to denote a table heading is a perfectly standard, semantically valid way of presenting an HTML table title. I just can't agree that this is a negative usability-wise.
4. The colons are unnecessary - the information is presented in clear key-value pairs, using separate HTML elements and different styling. We could add all sorts of different ways of making the types stand out from each other - putting the key in upp case, or making it bright red, for instance - which we do not do because it is unnecessary. Colons are an indistinct form of screen punctuation and do not add significantly to the distinction.

In the interests of keeping a dialogue going, so far as I can tell the only current sticking points are:

1. The need for colons as separators;
2. The use of a caption rather than an in-table header for the title;
3. The need for an off-green background colour to the headers rather than leaving it transparent.

Chris Cunningham (not at work) - talk 11:28, 3 December 2008 (UTC)

Coloured Infobox section headers are extremely common on Wikipedia. I picked Cleveland Indians, World War II, Mars and James Earl Jones off the top of my head as articles likely to have Infoboxes, and all four of them use a background colour. Again, it's a visual navigation aid; if you don't like coloured backgrounds for Infobox section headings, fine, but you'll have to take up the fight elsewhere.

I disagree that colons are unnecessary, but whatever, not worth arguing over. I've seen colons go into and out of Infobox templates a number of times over the years.

I am also in the group of people that thinks 22em is too wide for most Infoboxes. {{Infobox}}, at its default size, will occupy almost a third of the browser's total width when maximized on a 1024-pixel wide screen. And that's a third of ~1000 pixels... a lot of people using mobile devices don't have that kind of luxury, and a lot of other people don't use fully-maximized browser windows. Frankly, it looks like shit, and I have some doubts that that particular decision was made through any kind of process beyond "hey, what's this wedged in my ass? i'll pull it out! oh, it's a 22!". 19 or 20em would work better for a wider range of display devices, and wouldn't infringe on the actual content of the article so much.

Finally, the Infobox isn't a "table". It's a box containing information, which includes a list of name/value pairs (and a name/value pair is really stretching the definition of a "table", which is typically a construct that gives specific meaning to the X and Y axis), lists of articles, images, and other navigation elements. The notion that a table caption appears above the top of the table's border doesn't apply here. And again, it looks bad. If you aren't going to change it back, then I will. Warren -talk- 16:16, 3 December 2008 (UTC)

In order:

1. transparent headers are also extremely common. I could rattle off a few examples too. And I already did "take up the fight elsewhere"; I took it up on the WikiProjects: I took it up on the {{infobox}} discussion; and I take it up periodically when people discuss further standardisation of infobox templates. The rest of the computing WikiProject uses them, which was my doing, and has done for some time now without opposition. So here I am "taking up the fight" with the last hold-out on the Project. If you'd like to give the argument for why it is that including an arbitrarily-coloured stripe aids in readability of the template significantly enough to overcome the drawback of the distraction it causes, then we can have that, but I'd rather it were done centrally on template talk:infobox.
2. Cool, that's settled then. Again, I'd have no problem with these going back in if there were consensus on the issue. In fact, in the long run these could be automatically generated using the CSS :after pseudo-class. But that's something to discuss in the years ahead.
3. Well, that the standard width "looks like shit" is definitely a minority position right now. I'd have to ask you to take up the fight elsewhere on this one. :)
4. It's made from a <table>, uses semantically-valid HTML table constructs and classes, and presents data in a structured and tabular format. I don't think the definition of "table" you've given is what is generally meant by the term when discussing semantic HTML. As for it "looking bad", again, it's gone unopposed on a good deal of other templates, so this is an issue of personal preference. If you want to change it then it can be modified into an "above" attribute pretty easily, but I'd rather we had a wider discussion on the final outcome.

Chris Cunningham (not at work) - talk 17:02, 3 December 2008 (UTC)

←Perhaps one of you could kindly put both versions side by side so that others might compare them? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:23, 3 December 2008 (UTC)

/testcases. Warren's pre-infoboxing rev is in the /sandbox. Chris Cunningham (not at work) - talk 20:46, 3 December 2008 (UTC)

Thank you. I made a table so that they are now side-by-side. I can't believe there's an edit war over such small differences, but FWIW, I prefer the {{infobox}} version overall, but prefer the heading to be inside the box, as in the "Previous" version. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:58, 3 December 2008 (UTC)

Windows 7 is one of the top 100 articles on Wikipedia. Windows Vista was in the top 20 when it was released. This template isn't off in some far-flung corner of the encyclopedia; tens of thousands of people see it every day. I've been working on the encyclopedia long enough to know that people need to be literally brow-beaten into producing something that looks good instead of focusing solely on the technical exercise of simply adding content, or consolidating for the sake of maintainability. The new {{Infobox}}-based template may be more maintainable, but given that there were only a handful of non-bot edits in the last year and a half, there's no solid justification for improving the maintainability at the expense of the visuals. Warren -talk- 00:00, 9 December 2008 (UTC)

That's a purely subjective call. Given that there has been no discussion on any of the other software templates regarding the styling, and that several articles using those infoboxen are higher placed than Windows 7 in the page view listings, this suggests that you're the only one who feels so. You're using "code versus looks" as a straw man, when in fact I believe that the new styling was more attractive as well as being more functional. Still, there's no time limit on getting these improvements rolled out; I'll take the issue to the WikiProject page. Chris Cunningham (not at work) - talk 00:51, 9 December 2008 (UTC)

Reference styling

Moved from Template talk:Infobox OS version

 – following merge of {{infobox OS version}} into {{infobox OS}} — Dmitrij D. Czarkoff (talk•track) 11:22, 13 July 2014 (UTC)

So a change to have the references in the lede changed to use proper <ref></ref> tags instead of superscripted inline extlinks was reverted with a cryptic edit summary which I can only assume was meant to mean something like "I respectfully disagree that this is a productive change". I don't see why there's a reason for these links to be included inline instead of in the refs section - reference styling should be consistent within articles and that includes the infobox. Planning on restoring the use of proper ref tags here. Chris Cunningham (not at work) - talk 11:56, 8 December 2008 (UTC)

Os Cite needed

Moved from Template talk:Infobox OS version

 – following merge of {{infobox OS version}} into {{infobox OS}} — Dmitrij D. Czarkoff (talk•track) 11:22, 13 July 2014 (UTC)

The "Os cite needed" is not working, if the release_version does not have a URL, still show "[info]" but with no link--Sotcr (talk) 01:42, 9 December 2008 (UTC)

I Mean, like in here [1], in the Preview_Release says (citation needed), but now that does'nt work --Sotcr (talk) 01:44, 9 December 2008 (UTC)

Discussion at WP:SOFTWARE

Moved from Template talk:Infobox OS version

 – following merge of {{infobox OS version}} into {{infobox OS}} — Dmitrij D. Czarkoff (talk•track) 11:22, 13 July 2014 (UTC)

I've opened a larger discussion of the styling issue over at Wikipedia talk:WikiProject Software#Infobox discussion. Chris Cunningham (not at work) - talk 10:11, 9 December 2008 (UTC)

Six weeks later, there has been no opposition. This has been broadcast as widely as it can be put now; as such, in the continuing lack of opposition from anyone but the template author, I'm syncing this with the new sandbox code again. Any issues, please let me know. Chris Cunningham (not at work) - talk 14:25, 17 January 2009 (UTC)

Yeah, you didn't resolve /my/ issues with the infobox layout. Until you can produce a version of the {{infobox}} template where the top part goes inside the box, not outside, then I vehemently oppose this change. Warren -talk- 17:55, 17 January 2009 (UTC)

Done. Test cases. Chris Cunningham (not at work) - talk 11:24, 18 January 2009 (UTC)

ref tag broken

Moved from Template talk:Infobox OS version

 – following merge of {{infobox OS version}} into {{infobox OS}} — Dmitrij D. Czarkoff (talk•track) 11:22, 13 July 2014 (UTC)

It appears that some changes to this template have broken the element that generates the <ref> ... </ref> tags. This looks to be from the data9 and data10 elements in the template.

For examples, see:

• Windows 7 where the first entry in the references section is "[{{{preview_url}}} info]"
• Mac OS X v10.5 where the first two entries in the references section are: "[{{{first_release_url}}} info]" and "[{{{release_url}}} info]"

--- Barek (talk • contribs) - 18:09, 17 February 2009 (UTC)

I don't know why the URLs aren't being formatted properly in the ref tags, but I've changed them to inline links again to fix this. Chris Cunningham (not at work) - talk 09:27, 18 February 2009 (UTC)

proceeded by/succeeded by

Moved from Template talk:Infobox OS version

 – following merge of {{infobox OS version}} into {{infobox OS}} — Dmitrij D. Czarkoff (talk•track) 11:22, 13 July 2014 (UTC)

Could we have:

| header22 = proceeded by

| data22 =

| header23 = succeeded by

| data23 =

Such that one can indicate Apple System 6 was succeeded by System 7 etc.. ? An alternative might be next/previous. Alternative:

| label31 = Predecessor

| label32 = Successor

Electron9 (talk) 09:37, 12 May 2009 (UTC)

I just swung by to ask for the exact same thing (only it's spelled preceded). I would love to just go through OSes and not have to hunt for the earlier OS. But looks like this was requested a year ago with no comment (I don't know if the addition was made to the template and the /doc page not updated). But if anyone's out there, a "preceded by" and "followed by" parameters in the infobox would be wonderful. – Kerαunoςcopia^◁_galaxies 00:26, 10 June 2010 (UTC)

Y Added. I tested it on my own sandbox, but obviously feel free to fix/revert and be sure to double-check my additions to the /doc page as well. Appreciated. – Kerαunoςcopia^◁_galaxies 01:00, 10 June 2010 (UTC)

Merging templates

Moved from Template talk:Infobox OS version

 – following merge of {{infobox OS version}} into {{infobox OS}} — Dmitrij D. Czarkoff (talk•track) 11:22, 13 July 2014 (UTC)

When this template is merged with template:inforbox os could we create a section so for example it would look like it is now but you would for example do this to get version

{{inforbox os 
| os version = yes
}}

So that it is still a different type of template compared to template:infobox os please 86.135.255.245 (talk) 16:50, 15 December 2013 (UTC)

Hi.

Who says it is going to be merged? I tried to merge them twice but their technical differences are so huge, I aborted midway. Those carried-away flock of uninformed editors who blindly voted can sure try, but if I see a single problem with their merger, I'd revert.

Best regards,

Codename Lisa (talk) 02:50, 16 December 2013 (UTC)

Completely new Infobox OS

Moved from Template talk:Infobox OS version

 – following merge of {{infobox OS version}} into {{infobox OS}} — Dmitrij D. Czarkoff (talk•track) 11:22, 13 July 2014 (UTC)

There is no way we can merge Template:Infobox OS and Template:Infobox OS version, because as Codename Lisa said, there are huge and complex differences between the two infoboxes. My suggestion is that we create an entirely new Infobox OS, or at the very least add more parameters to the existing Infobox OS. It's not worth merging the infoboxes when there are huge differences between the two. That's my suggestion.

Warm regards, Helixsoft (Talk|Contributions|Templates|Userboxes) 15:20, 22 January 2014 (UTC).

Hi. Joel Spolsky once wrote that it is only on TV that two quarreling kids are subdued by shouting louder than either of them. In real world, such an attempt would turn into a three-way quarrel. He says such was the case when someone tried to resolve the conflict between the incompatible RSS versions with an Atom specification.

We have two infoboxes already. A third won't fix a problem. It only adds to the problem. A merge is out of question at the moment but something close will eventually happen, either by me or someone more experienced than me, or someone who just finds the delicate spot of compromise. When I was replying to the other user, I needed to snap him out of his daydreaming of bliss. The guest editor had assumed so much about the end result that was already making edit requests on the future template!

Best regards,

Codename Lisa (talk) 15:52, 22 January 2014 (UTC)

date parameter?

Moved from Template talk:Infobox OS version

 – following merge of {{infobox OS version}} into {{infobox OS}} — Dmitrij D. Czarkoff (talk•track) 11:22, 13 July 2014 (UTC)

A user edited OS X Mavericks, saying "|date=June 2013" deleted from Infobox. Not sure what it is (doesn't display))", although they didn't actually remove that in the edit.

As a test, I tried changing the date parameter's value to "hello sailor" and previewing the article; it showed the article as being in the redlinked category "Articles with unsourced statements from hello sailor".

I then removed the "date=" parameter; the AnomieBOT put it back, with a value of March 2014.

Does a date=XXX parameter add the article to the category "Articles with unsourced statements from XXX"? Are some of the "Articles with unsourced statements from XXX" categories hidden, so that they don't show up?

Where, if anywhere, is that parameter documented? Guy Harris (talk) 20:13, 4 March 2014 (UTC)

Hi. Just checked the source code for your question. Unlike several other infoboxes, {{Infobox OS version}} does implement an actual |date= parameter. You see this infobox implements |first_release_url=, |GA_url=, |release_url= and |preview_url=; if they are empty, the infobox inserts a {{Citation needed}} in their places and passes the |date= parameter to {{Citation needed}}, which needs a date.

Best regards,

Codename Lisa (talk) 06:53, 5 March 2014 (UTC)

Add frequently updated

Moved from Template talk:Infobox OS version

 – following merge of {{infobox OS version}} into {{infobox OS}} — Dmitrij D. Czarkoff (talk•track) 11:22, 13 July 2014 (UTC)

Hi please add support for frequently updated. 86.135.252.13 (talk) 22:44, 26 March 2014 (UTC)

Over my dead body! And over Jimbo Wales's dead body too: This parameter would be a recipe for a disaster called eternal state of sourcelessness, eternal undue weight, associated edit wars and version number vandalism. No! Let the sleeping devil lie! Hell, don't create the sleeping devil.

Best regards, Codename Lisa (talk) 03:25, 27 March 2014 (UTC)

Userland?

What does "userland" mean in the context of this template? The User space article it references doesn't shed any light on the subject, and the documentation for this temaplate doesn't explain the parameters with any vigor. -- Mikeblas (talk) 03:01, 26 March 2014 (UTC)

Hi. This is one of the inventions of the Linux folk. In Windows, this field would be equal to Windows Shell. In Linux distros, however, windowing system and a lot of other things tangible to user also into user mode. Plus, articles on Linux distros use this field to say where the bundled apps come from, e.g. GNOME or KDE This is not an issue with Windows, Mac, OS/2 and a lot of others outside Linux distros. (In fact, in Mac, the concept third-party is negligible.

Best regards,

Codename Lisa (talk) 00:29, 27 March 2014 (UTC)

P.S. Guess what? There is a |ui= too. Very confusing. Best regards, Codename Lisa (talk) 00:31, 27 March 2014 (UTC)

I would not say that Linux articles use this field to say GNOME or KDE. The userland encompasses much more than the GUI. The "ui" field is clearly for GNOME or KDE, while the userland field is typically either "BSD" or "GNU" indicating the family membership of all the application-level utilities such as ls, rm, mv and others. Elizium23 (talk) 01:03, 27 March 2014 (UTC)

The problem is that UI is not outside userland. Besides, KDE or GNOME aren't UI elements only. GNOME Character Map or Kate are apps after all. Best regards, Codename Lisa (talk) 01:12, 27 March 2014 (UTC)

Indeed, "userland" implies a particular architecture; and the shell is the shell -- it's only a part of what some call "userland". POint is, there's zero documentation for the parameter's intention here and therefore weak understanding of it; it's based on a colloquial phrase and therefore not broadly agreed-upon, and it suffers from inconsistent application throughout the corpus. Seems like it should be clarified or deleted. -- Mikeblas (talk) 15:14, 5 April 2014 (UTC)

"Userland" is a very strange-seeming parameter. I would suggest renaming it to "Significant user mode components" -- i.e. "of the major functions of this operating system, which are implemented outside of kernel mode or ring 0?" Jeh (talk) 00:40, 10 July 2014 (UTC)

I'm having a discussion about Unix - operating systems. Some seems to view Unix as only kernel space (APIs). OSes clearly include (some part of) userland also - User interfaces (at least one) - for Unix eg. the CLI. I wander what components should be included in modern usage of the term OS and "Significant user mode components" - eg. a sound-subsystem is not critical - but still part of the OS (not just inputand/UI)? And when OSes would not be considered the "same" anymore (when sound-subsystem is changed? graphics/replaced by surfaceflinger?).. comp.arch (talk) 16:07, 21 July 2014 (UTC)

As I gather, "userland" is here for articles about Debian GNU/kFreeBSD and alike. At least it is too ambiguous outside this scope. — Dmitrij D. Czarkoff (talk•track) 16:27, 21 July 2014 (UTC)

Now that @Czarkoff: mention it, would you say one of the options for userland should be Android? I disagree personally with calling Android Unix-like (as a family), but while that is how WP describes it would Fire OS and Android be "Unix-like"/Android? (family/userland)? Android doesn't have GNU by design? And Bionic is not BSD (a fork)? And Dalvik (for now..) and more as a whole is "Android's" userland? comp.arch (talk) 20:54, 21 July 2014 (UTC)

Android has several layers of userland:

• BSD userland (bionic is fork of NetBSD's libc, and multiple NetBSD utilities are included);
• Android-specific utilities (adb and friends, custom frameworks, etc.);
• Dalvik;
• UI goo;
• Standard applications (clock widget, alarm, browser, etc.);

Enumerating all of this in infobox is plain silly, so |userland= parameter for Android just should be left alone. FWIW same is true for any GNU/Linux distro. — Dmitrij D. Czarkoff (talk•track) 21:32, 21 July 2014 (UTC)

Completing Infobox_OS_version merge

Per Wikipedia:Templates for discussion/Log/2013 August 24#Template:Infobox OS_version, I have added fields to support Infobox_OS_version. The new fields do not affect current Infobox_OS articles. The merge has been delayed long enough. -- Netoholic @ 23:17, 9 July 2014 (UTC)

I very dislike the "merged" version of this template:

1. Putting operating system family on top of the template is appropriate for OS version articles, but is completely inappropriate for articles about operating systems.
2. With a separate Releases "group" the "Preceded by" and "Succeeded by" look very much out of place.
3. The ugly plainlinks in Releases.
4. |released= may be specified alongside the Release dates-related mess from {{infobox OS version}}, and is shown in different location.

These are the most outstanding issues, and they should be fixed before the production version of this template is updated. — Dmitrij D. Czarkoff (talk•track) 23:21, 9 July 2014 (UTC)

Feel free to fix or correct it as much as you like, as long as you preserve the parameters unique to Infobox_OS_version. I am not here to dictate how the infobox should look, only to complete a very, very long overdue merge backlog decided by consensus. In practice, the OS_version articles look just fine converted to the OS template. --Netoholic @ 23:25, 9 July 2014 (UTC)

Hello, old timer

I'd like to re-iterate what I said in your talk page: The consensus was to merge, not to mutilate. Your switch misfiles many parameters, especially those related to WP:V. While I appreciate undertaking a long-overdue endeavor, I do not appreciate creating problems that didn't exist before.

Best regards,

Codename Lisa (talk) 23:32, 9 July 2014 (UTC)

I extensively tested on the sandbox and left the edit on the main template for about half-a-day before I began the article conversion work. This is a required merge, and any problems with the new version must be addressed by going forward by including the OS_version parameters, not backward, and definitely not stagnant as it has been for approaching a full year. Today is the day. --Netoholic @ 23:36, 9 July 2014 (UTC)

@Netoholic: FWIW keeping all the parameters of both infoboxes is harmful. The merge does not excuse from necessity to keep this template consistent. — Dmitrij D. Czarkoff (talk•track) 23:45, 9 July 2014 (UTC)

(edit conflict)Although I sympathize with your high spirit of no more procrastination, I do believe that patience is one of the virtues of a a Wikipedian. The reason this task was delayed was because everybody knew that it would be time-taking and arduous, so much so that no one dared starting it. There is no deadlines in Wikipedia and there is no excuse for faking completion of long overdue task.

Do not misfile information. That's all we ask.

Best regards,

Codename Lisa (talk) 23:49, 9 July 2014 (UTC)

@Czarkoff:,@Codename Lisa:: I will give editors a day to implement a version which both implements the Infobox_OS_version parameters and addresses any specific concerns raised above (re: layout, etc.). If no version is live, I will re-implement mine and continue the article work. If editors here continue to act in violation of the consensus decision after that time, I will escalate. There is simply no option to continue to pushback efforts to implement a near-unanimous decision on TFD. -- Netoholic @ 23:53, 9 July 2014 (UTC)

Then You should escalate right now, because I see this ultimatum as inappropriate action, as well as the way you enforce the merge, and the way you remove comments as well BTW. — Dmitrij D. Czarkoff (talk•track) 00:00, 10 July 2014 (UTC)

(edit conflict) Now, now. Are you threatening me? By all means do escalate; the sooner the damaging, disruptive and non-collegial nature of your work comes to light, the better. I on the other hand, advise you to stop commenting on the contributors and begin working your differences of opinion with us.

Concerned, Codename Lisa (talk) 00:06, 10 July 2014 (UTC)

I agree with Codename Lisa: By all means, escalate. Your "consensus" to merge two templates and force all uses of one to switch to the other is not binding on the community at large. Did you, prior to any discussion, notify maintainers of the articles that use the template you want to delete? Any notices on those articles' talk pages? Not that I ever saw. Your subsequent editing of articles that use the template you want to delete, with edit summaries and talk page comments that apparently are completely unallowing of any compromise (~"it's been decided behind your backs, deal with it") is at best disruptive and... well, "non-collegial" is about the most polite way to put it. Please stop. Jeh (talk) 00:24, 10 July 2014 (UTC)

@Jeh: actually, I'm just a worker-bee trying to clear up a backlog from WP:TFD. The decision to merge was made at Wikipedia:Templates for discussion/Log/2013 August 24#Template:Infobox OS version almost a year ago. I don't have an opinion one way or the other about specifics, I'm just trying to move it along. --Netoholic @ 00:37, 10 July 2014 (UTC)

I do not agree that any "decision to merge" that was made (however long ago; that's irrelevant) without notifying maintainers of articles that use the template is binding on anybody outside of your little beehive. If you want something that is defensible as a community-wide consensus, then you had better have involved the community long prior to the decision. I don't see that that happened.

Your recent conduct and phraseology do not suggest a mere "worker-bee", but rather someone who is rather strenuously trying to push an agenda. I personally would have said "you know, the many users of Template:Infobox OS version seem singularly uninterested in switching over. Maybe they don't even know about this new thing? Maybe we should bring this up on the talk pages of the articles that use it?"

And the conclusion after that effort might well be "Huh, they really don't like the merged template. I guess we'll have to keep both." You have to remain open to that. Template creators and maintainers don't run this place.

Don't expect that you can do what you recently did without pushback. And saying "there is no option for pushback" under such circumstances is just pouring gasoline on the fire. Jeh (talk) 01:00, 10 July 2014 (UTC)

Implementation

Hello everyone

I propose the merger should occurs on the basis of {{Infobox OS}}, because it is implemented on more articles and changing its layout to {{Infobox OS version}}'s layout is more likely to be contested. If you think the other layout is a better idea that will be lauded, I suggest we complete the merger first, then do the layout with a separate bold edit. Therefore, the following changes must occur in {{Infobox OS}}:

1. These parameters added: |RTM_date=, |support_status=, |other_articles=
2. |GA_date= should be added as an alias for |released=
3. These parameters renamed in the article space to those of {{Infobox OS}} equivalents:
   • |first_release_date= → |RTM_date=
   • |release_version= → |latest release version=
   • |release_date= → |latest release date=
   • |preview_version= → |latest preview version=
   • |preview_date= → |latest preview date=
   • |human language= → |language=
4. These parameters discontinued:
   • |first_release_url=: Merge implementations with |first_release_date= and convert to {{cite web}}
   • |GA_url=: Merge implementations with |GA_date= and convert to {{cite web}}
   • |release_url=: Merge implementations with |release_date= and convert to {{cite web}}
   • |preview_url=: Merge implementations with |preview_date= and convert to {{cite web}}
   • |date=: Disregard
5. Special provisions added for |Discontinued=: This parameter must be disregarded when |family= is set. The word "discontinued" is never used for a single version because all development efforts on a version of program ceases when it is released to manufacturing; any patch released consists development on a later version. (For support status, we have another parameter.) We could do it the other way, but this way is more fool-proof, so to speak.
6. Special provisions added for |Discontinued=: This parameter must be disregarded when |succeeded by= is set. The word "discontinued" is never used for a single version because all development efforts on a version of program ceases when it is released to manufacturing; any patch released consists development on a later version. (For support status, we have another parameter.)

Best regards, Codename Lisa (talk) 00:31, 10 July 2014 (UTC)

|family= and |source model= already exist. --Netoholic @ 00:47, 10 July 2014 (UTC)

• Question |Discontinued= has no documentation, is that a simple discontinued = yes flag? Can you give an example of an article with one? --Netoholic @ 00:55, 10 July 2014 (UTC) Striking question. This |Discontinued= seems to only to be in Infobox_OS, not Infobox_OS_version, and |succeeded by= exists in both already, so this is unrelated to the merge itself (its a question for future maintenance). --Netoholic @ 01:01, 10 July 2014 (UTC)
• We already have |family= here, and it is used in different meaning – in {{infobox OS version}} it basically means "operating system this is version of" (see template:infobox OS version/doc#Example), which has nothing to do with OS family. More appropriate name should be chosen, eg. "series". — Dmitrij D. Czarkoff (talk•track) 01:06, 10 July 2014 (UTC)
  • How is it used here differently, and why can't we use the same (existing) parameter and field for both meanings? --Netoholic @ 01:48, 10 July 2014 (UTC)

Actually, it is related; the merge now enables incorrect activation of a flag on articles that previously didn't suffer. The fact that the articles using {{Infobox OS}} didn't suffer from this issue is just a merry coincident, caused mainly by the consequences of WP:GNG. However, we are about to take an action that can potentially open an avenue of mischief. So, provisions to prevent it, is our responsibility. Best regards, Codename Lisa (talk) 01:58, 10 July 2014 (UTC)

• FWIW I would propose to avoid adding aliases to this template. I'd rather turn template:infobox OS version into a wrapper and collect its native syntax uses into maintenance category. This will create a backlog of ~70 articles, which could be timely ported to the syntax of this template. — Dmitrij D. Czarkoff (talk•track) 01:06, 10 July 2014 (UTC)
  • You don't need a wrapper or a maintenance category. Part of my task is to actually complete the migration once Infobox_OS has all the right changes to accomodate, not leave it to languish for someone else. --Netoholic @ 01:12, 10 July 2014 (UTC)

"Family" is an inherently vague word; it is just a loose metaphor. As any attempt to invoke a definition for it constitutes original research. But we can add a |version of= with the same function as that of "family" in {{Infobox OS version}} that also disables |family=. How is that? Codename Lisa (talk) 01:58, 10 July 2014 (UTC)

Family is not the only problem here. {{infobox OS version}} has many alternative parameters, most undocumented; this template has many duplicates already. Introduction of this many new parameters will make it barely readable and will eat unreasonable amount of processing resources. Keep in mind, that this infobox provides both underscored and spaced syntax, while {{infobox OS version}} only has underscored parameters, so basically we'll have to introduce two new parameters for each missing from {{infobox OS version}}. We'll definitely loose some on the way – at least those URL things.

That is: the end result will be incompatible with {{infobox OS version}} enough to make wrapping unavoidable. Why not drop quirky syntax that won't sit well here anyway? — Dmitrij D. Czarkoff (talk•track) 02:13, 10 July 2014 (UTC)

Alternate parameter problems have two very simple causes: The template supports spaced parameters (it shouldn't have in the first place), and the template documentation itself is inconsistent, using some spaced and some not. A simple bot run can eliminate the old, inappropriate parameters, but for today, we'll have to leave them in and support them. What's most important is to know the most preferred parameters names, and update the documentation to be 100% correct and current. --Netoholic @ 03:06, 10 July 2014 (UTC)

Why do we have to support them? — Dmitrij D. Czarkoff (talk•track) 06:20, 10 July 2014 (UTC)

Because this is a merge. After the articles are all converted, then someone can lead a separate project to standardize the parameters. --Netoholic @ 06:40, 10 July 2014 (UTC)

This is a harmful way, IMO. The wrapper would harm this template less, and I see no reason to believe that the damage is really required. Also, as stated above, these template's syntax is incompatible, so your way of merging is impossible at all. — Dmitrij D. Czarkoff (talk•track) 10:01, 10 July 2014 (UTC)

• Question - are {{{RTM_date}}} and {{{GA_date}}} the more preferable default names for their respective fields (replacing first_release_date and release_date, etc.? --Netoholic @ 01:13, 10 July 2014 (UTC)

Hi. Actually, collision of the application domain was my main concern. When you hear "release date", does it mean "release to manufacturing" or "general availability"? This distinction decides what we do.

Best regards,

Codename Lisa (talk) 01:27, 10 July 2014 (UTC)

Definitely GA date. Software is released to customers, not to CD fabs. — Dmitrij D. Czarkoff (talk•track) 02:15, 10 July 2014 (UTC)

FWIW I would drop RTM altogether – it is unapplicable to articles about operating systems, and OS version articles discuss these dates in prose anyway. In the end, RTM is not even user-visible process stage. — Dmitrij D. Czarkoff (talk•track) 02:21, 10 July 2014 (UTC)

A very strong consensus through editing is formed in favor them. We had a widespread misuse of |release= tag when people added both dates of Windows version to it and microformat broke. (I used to revert them but they were so recurrent that Dogmaticeclectic to filed an edit warring case against me. Of course, it was finally decided that I wasn't doing edit warring; but I was took the cue and separated the fields.) It stopped when I finally added those dates. So, as you can see, we definitely need them.

As for your other concern, I fully agree with you that we do not need alias proliferation. That is why article 3 of my proposal suggests renaming implementations instead of adding them.

Best regards,

Codename Lisa (talk) 19:36, 10 July 2014 (UTC)

@Codename Lisa:/@Czarkoff:: I've completed the requests for the template and the changes can be seen on Template:Infobox OS/testcases#Merge OS version along with a corrected list of the most preferred parameter names (old ones are still supported). Please take a look, and let me know if there are any major concerns before I continue with the merge. -- Netoholic @ 09:29, 10 July 2014 (UTC)

"General availability" works for Windows, MacOS and Android (the users of {{infobox OS version}}), but it does not work with other operating systems. For example, initial release of Plan 9 from Bell Labs was only available to select customers, and first release in general availability was "Second release", which came years later.

I also strongly oppose moving rather significant release information to the bottom, and I don't see any need in child infobox, which effectively doubles the server load penalty of this template. — Dmitrij D. Czarkoff (talk•track) 11:08, 10 July 2014 (UTC)

I understand. But this isn't something to address in merger stage. Let's be done with it, then we can discuss how best to dispose of them. We already have enough to discuss, you see.

Best regards,

Codename Lisa (talk) 19:36, 10 July 2014 (UTC)

Wrapper

I updated template:infobox OS/sandbox and template:infobox OS version/sandbox, and the results can be seen at template:infobox OS version/testcases. I ported as many parameters as I could (actually, per suggestions by Codename Lisa), though I believe that "Release to manufacturing" and "Further reading" should be dropped. The rest of the merge process appears to be the following:

1. Update all articles using {{infobox OS version}} to use {{infobox OS}} directly.
2. Change {{infobox OS version}} to output error in case of using old syntax.
3. After a grace period (eg. 1 month) redirect template:infobox OS version to template:infobox OS and consider merge complete.

If this option gains support, I will agree to be held accountable for the whole process. I will also manually convert all references from plainlink fields of {{infobox OS version}} into proper references in articles' native citation formats. — Dmitrij D. Czarkoff (talk•track) 12:36, 10 July 2014 (UTC)

• Issue: There is no reason at all to make Infobox_OS_version into a wrapper. You can see from the testcases that the release_url information goes missing anyway. Articles will be directly changed from Infobox_OS_version to an updated Infobox_OS, so no articles will ever use such a wrapper and there is no need for a grace period as OS_version will have been completely orphaned. After the articles are converted, Infobox_OS_version can be immediately redirected - merge complete. --Netoholic @ 18:08, 10 July 2014 (UTC)
  • Again, there are |family= parameters in both infoboxes used in different meanings. — Dmitrij D. Czarkoff (talk•track) 19:01, 10 July 2014 (UTC)
    • I don't see what that has to do anything. During the conversion, change OS_version |family= into |version_of= and its done. --Netoholic @ 19:07, 10 July 2014 (UTC)
      • Sure. And this is the same for all other parameters as well. The syntax of {{infobox OS version}} will not survive, so there is no reason to break consistency of this template. — Dmitrij D. Czarkoff (talk•track) 19:17, 10 July 2014 (UTC)
        • Yes. I'll update the main OS template and also the documentation to reflect the most preferred and consistent parameters. Then as I (we) go through the old OS_version articles, the OS parameters will replace the OS_version ones. --Netoholic @ 20:00, 10 July 2014 (UTC)

• Issue: Far too many parameters in Infobox_OS don't look anything like their row labels, nor are they consistent/predicable. There is no point in introducing a GA_date field if the row label isn't going to say General availability. I'd suggest calling it just |release_date=. During the article conversion, you're switching parameters to their most preferred OS_version equivalents anyway, so no need to support something that didn't exist before in Infobox_OS_version. --Netoholic @ 18:08, 10 July 2014 (UTC)
  • This template supported both spaced and underscored versions. I see no reason to break this. — Dmitrij D. Czarkoff (talk•track) 19:17, 10 July 2014 (UTC)
    • It will support both. --Netoholic @ 20:00, 10 July 2014 (UTC)
      • Then please make sure it does say "general availability". We are merging, not deleting parameters. We must have a set of |RTM_date=/|GA_date= that override |release_date= or an equivalent alternative. As I said earlier, there has been a whole conundrum leading to the creation of RTM date and GA date fields. This isn't something to let go just because of fancy.
        Best regards,
        Codename Lisa (talk) 20:15, 10 July 2014 (UTC)
        • You know, I wanted to merge yesterday, and the version you guys reverted would have done that perfectly. Discuss it after the merge, as I still don't see a consensus on the right label to use (General availability vs Initial release). -- Netoholic @ 20:31, 10 July 2014 (UTC)
          • Yes, thanks for your good idea yesterday. I assure you, this great idea wasn't the reason for which I reverted. Misfiling existing fields was. Best regards, Codename Lisa (talk) 20:36, 10 July 2014 (UTC)

• Issue: Separating all the release information under a single header is far better than throwing arbitrary information onto the screen in what looks, to me, like a random order. People have complained on this talk page about the presentation, so putting similar information under headers is desirable. This is a merge, so some ideas from Infobox_OS_version should be incorporated, and headers are a very good one. --Netoholic @ 18:08, 10 July 2014 (UTC)
  • I strongly disagree on this statement. Frankly, to me everything different in {{infobox OS version}} looks either inferior or completely wrong. I feel particularily strong dislike towards the visual style of that template, and sectioning is another aspect that I believe we should get rid of ASAP. Frankly, I see nothing in {{infobox OS version}} that would be an improvement over current {{Infobox OS}}. — Dmitrij D. Czarkoff (talk•track) 19:17, 10 July 2014 (UTC)
    • Seconding this for now. We can discuss this after a merge. Best regards, Codename Lisa (talk) 20:16, 10 July 2014 (UTC)
      • Preserving the existing headers of OS_version so as not to shock anyone watching those pages today. Post-merge, the subject can be discussed. --Netoholic @ 20:31, 10 July 2014 (UTC)
        • It will definitely be a change for 800 other article who hadn't seen it. So, no. We only have the go-ahead for merging OS version into OS, not the other way around. So, I still second Dmitrij's opinion. Best regards, Codename Lisa (talk) 20:36, 10 July 2014 (UTC)
          • Then you should have let me proceed yesterday as that version made NO visual change at all to Infobox_OS articles OR Infobox_OS_version articles. It was a straight merge, and visual discussion could have happened afterward. Now you guys have asked for certain changes, which I have tried to accommodate, but those changes to unify fields are now what you're objecting to. The OS articles now will will see some label changes, some reordering of rows, and a clean, simple header for the "Release information" with release information grouped under it. They will either come here to complain or praise it, in which case we'll get a lot more feedback and change it later, but the reality is we need to move forward with the merge and concerns like this should not be stopping that from happening. --Netoholic @ 21:04, 10 July 2014 (UTC)
            • We need to move forward with merge. If you also want to restructure this infobox or change style, gain consensus first. Right now it is 2 vs. 1 against change of visual style and sectioning. — Dmitrij D. Czarkoff (talk•track) 21:26, 10 July 2014 (UTC)
              • The version I tried to implement yesterday that you guys reverted made no visual changes to either set of articles. I am seriously considering just implementing that again and leave you guys to discuss visual aspects later. Right now, either the OS articles gain a header, or OS_version articles lose their headers - and I'm not comfortable with either direction. -- Netoholic @ 21:44, 10 July 2014 (UTC)
                • The version from yesterday introduced sections (one, which is better then many but still one more then appropriate), equated operating system to OS family and allowed GA, RTM and "initial release" side by side, all of which are inappropriate. — Dmitrij D. Czarkoff (talk•track) 22:10, 10 July 2014 (UTC)
                  • All of which are easily-done changes to the template that did not require a full revert and complete undoing of the article conversion work I'd already done. -- Netoholic @ 22:23, 10 July 2014 (UTC)
                    • Revert and complete undoing were necessary because the change happened out of process. You really should have given a clear notice and a reasonable timeframe. |family= issue is a good example of a reason to avoid rushing in such cases – your article convertion work would mislead readers instead of helping them. — Dmitrij D. Czarkoff (talk•track) 23:07, 10 July 2014 (UTC)
                      • "out of process"? This merge has been overdue for almost a full year. I came here to help, and have been bitten pretty hard for stepping into this particular walled garden. Now, let's stop with the blaming and get this little project over with. After the merge, you guys can discuss the future of the template as it applies to all OS's. We don't need all the answers today, we just need something good enough that doesn't cause data to be lost. --Netoholic @ 03:01, 11 July 2014 (UTC)
                        • Agree with Dmitri. Out of process: I watch most of the Windows NT-family articles and I never saw any notice that anyone was discussing merging (deleting) a key template, nor any notice after "consensus to merge" was established at TFD. That was not your doing (or your lack of doing), but you compounded it by just disruptively forcing the new template on so many articles (and losing information), again without any prior notification. You compounded this further by stating there was no room at all for pushback. So, yeah, you've been bitten; take a lesson and try to do the next one better. Meanwhile, the amount of disagreement here suggests, if nothing else, that the previous consensus is no longer valid (see consensus can change; it has, after all, been a year). Certainly there is not support for your arbitrarily setting one-day deadlines and issuing ultimatums. "Something good enough that doesn't cause data to be lost" we already have—in the existing templates. The urgency to "get this little project over with" is all in your head. Jeh (talk) 03:36, 11 July 2014 (UTC)
                          • Wikipedia is a big place, sometimes people miss key discussions, but when it was put up for TFD, a notice was placed on the template that appeared on the every OS_version article for 5 days. I can attest, without doubt, that I made sure every article I started converting to Infobox_OS did not lose information. I had every article up side-by-side old and new template before I hit "Save page". My contribs show I converted 12 Windows OS articles in about 45 minutes. That means I gave each one about 4 minutes of time on average. Pretty damn thorough. When I start merging again, I will be equally diligent. Even more-so now that people have requested I change parameters and create cite_web refs to replace bare links. --Netoholic @ 03:48, 11 July 2014 (UTC)
                            • The trouble with that notification is that unless you're watching the template, nothing shows up in your watchlist; it's not the same as putting a notice on the article talk page. So I'm still having a problem with the notion that consensus at TFD is binding on WP at large, requiring us to accept the new template. The dissent here shows that you have no consensus or mandate (and certainly no necessity) to "start merging again". If article maintainers don't want to move away from the old template, they shouldn't have to. Jeh (talk) 04:07, 11 July 2014 (UTC)
                      • You know, the TfD never approved any particular version of merged template. Provided that the template you edit has 825 transclusions, so one may argue that boldly changing this template is unacceptable per se. Even if you disagree, WP:BRD defines due process: if you were reverted, discuss to reach consensus. — Dmitrij D. Czarkoff (talk•track) 14:22, 11 July 2014 (UTC)
• Comment I probably agree about removing "Further reading" - it doesn't seem like a very good use for the infobox, better as an article section. During article conversion, I'll look at how that is being used on each article and if needed we'll remove or change it. --Netoholic @ 20:31, 10 July 2014 (UTC)
  • This isn't something you can disagree with. It is created in attempt to curtail the creation of separate mini-navboxes. You need obtain addition consensus for misfiling it. Best regards, Codename Lisa (talk) 20:36, 10 July 2014 (UTC)

Straight merge

I merged all parameters of {{infobox OS version}} into sandbox of this template. Apart from |family= vs. |version of= issue this template will safely replace {{infobox OS version}} without loosing any data at all. The inconsistency between RTM and GA on one side and "initial release" on the other side is dealt by hiding "initial release" if either |RTM date= or |GA date= is used. This template may be installed without disrupting 825 articles that are already using it.

@Codename Lisa, Jeh, and Netoholic: Comments? Quesions? Issues?

P.S.: Netoholic, please don't edit production, sandbox and testcases before all participants have responded. — Dmitrij D. Czarkoff (talk•track) 18:02, 11 July 2014 (UTC)

I must apologize but I am having a bad headache right now. It was a busy day both in and out of Wikipedia. I make a full review tomorrow. But you can use this track parameter implementations.

https://docs.google.com/file/d/0B8tNkKG_EzjZbVpJbVNxbGdOY2c/edit?pli=1

You need to download it and use Excel to view it. But in case you don't have Excel, here is an Online version, courtesy of one of my pals:

https://onedrive.live.com/view.aspx?resid=EE0F5C6F873726F!1091&ithint=file%2c.xlsx&app=Excel&authkey=!AJ35hETYEDUpliM

Right now, only one issue caught my eye: In this diff, I see you've changed

{{#if:{{{title|{{{name|}}}}}}|{{{title|{{{name|}}}}}}|<includeonly>{{PAGENAME}}</includeonly>}}

...into:

{{{title|{{{name|<includeonly>{{PAGENAME}}</includeonly>}}}}}}

...which you shouldn't. The {{#if}} tag is there to make sure someone does not provide a name consisting of whitespace characters. We had an experience with this in {{Infobox web browser}}.

Best regards,

Codename Lisa (talk) 19:01, 11 July 2014 (UTC)

I am afraid you are wrong:

Markup	Renders as
{{infobox OS|name= }}	Infobox OS/Archive 1
{{infobox OS | name = ↵ }}	Infobox OS/Archive 1

As expected, whitespace is stripped and {{PAGETITLE}} is substituted. Anyway, I don't care much about this particular change – if you think that one more parser function there is not a problem, just go on and change it back. — Dmitrij D. Czarkoff (talk•track) 19:52, 11 July 2014 (UTC)

No, it is me who is wrong. — Dmitrij D. Czarkoff (talk•track) 15:48, 13 July 2014 (UTC)

re Codename Lisa's comment above: I'm sorry too - I am not at all familiar with template syntax and don't have time to come up on it, not in a useful time to work on this. I will look at diffs of results but I can't comment usefully on the code. Jeh (talk) 10:50, 12 July 2014 (UTC)

@Jeh: you can assess results at this template's testcases and testcases of {{infobox OS version}}. — Dmitrij D. Czarkoff (talk•track) 12:25, 12 July 2014 (UTC)

Would it be inappropriate to suggest any other changes at this time? I intensely dislike the "userland" parameter. "User mode" is less OS-specific and more formally accepted. Jeh (talk) 18:22, 12 July 2014 (UTC)

I also have some issues with some parameters. Let's keep them aside until the merge is complete, or we'll never get it done. — Dmitrij D. Czarkoff (talk•track) 21:26, 12 July 2014 (UTC)

Just finished reviewing with Araxis Merger. Your work is excellent. Here is what I can find.

Small issue: You've implemented |version of= in the same place as |family=. The only reason I suggested |version of= was as a compromise to have the text "a version of Windows NT" displayed below the title. If it is not going to be below the title, then we don't need this. |family= would suffice.

Missing parameter: |other_articles= is missing. We can discuss its merits after the merger. Right now, let's just add it.

Best regards,

Codename Lisa (talk) 19:12, 12 July 2014 (UTC)

Totally forgot about |other_articles=; thank you for adding it. I really want to see support status together with |succeded by= and |preceded_by= (logically connected), but this can really be discussed later. I still insist on separate |version of=, because I totally can't accept |family=[[Linux Mint]] or |family=[[Android (operating system)|]]. If it is less controversial moved to top, so be it. — Dmitrij D. Czarkoff (talk•track) 21:26, 12 July 2014 (UTC)

Excellent. Can the transition begin?

Best regards,

Codename Lisa (talk) 09:54, 13 July 2014 (UTC)

I guess so. In template:infobox OS version/sandbox I have a wrapper that passes arguments of {{infobox OS version}} into {{infobox OS}} substituting |family= with |version of= and leaving all other syntax intact. I'll push both sandboxes to production and redirect template talk:infobox OS version here now. I believe that we should pass to discussion of other changes (parameters' names, necessity of fields, etc.) not before the merged version stays live for couple of days. — Dmitrij D. Czarkoff (talk•track) 10:25, 13 July 2014 (UTC)

Wait a second. It think you must move the maintenance category code into {{Infobox OS}} so that the wrapper can be substituted, i.e. I edit every article containing {{Infobox OS version}} and replace it with {{subst:Infobox OS version/sandbox}}. You don't even need to push the wrapper into production area. We can then merge the documentation pages (because they save a lot of rewrite) and delete the entire OS version hoopla. Don't you agree?

Best regards,

Codename Lisa (talk) 10:45, 13 July 2014 (UTC)

@Czarkoff: Should I take your edit as a "yes" and begin immediately? Codename Lisa (talk) 11:23, 13 July 2014 (UTC)

Unfortunately I've seen your comment too late. Actually, I've already pushed the template. And I think we still need this wrapper even after the |family= gets out: the future syntax discussion will require keeping track of other deprecated parameters. If you disagree, please go ahead and implement it your way – I don't have strong preference here. — Dmitrij D. Czarkoff (talk•track) 11:28, 13 July 2014 (UTC)

@Codename Lisa: No, wait! You can't add this category to {{infobox OS}}, because it will categorize the valid use of |family= as well. And we can't delete {{infobox OS version}} per Wikipedia:Copyright policy – it is merged, so we have to retain attribution. Please, don't substitute {{infobox OS version}}! — Dmitrij D. Czarkoff (talk•track) 11:36, 13 July 2014 (UTC) (updated 11:40, 13 July 2014 (UTC))

(edit conflict)

@Czarkoff: Please excuse my abusing the ping system but I think you need to see my last edit in the template. Better abuse ping than sorry, right?

Now, you don't need to worry about the category; you can attach it to |version of= instead. The result is the same. And yes, we won't delete Template:Infobox OS version page; we redirect it. (Earlier instances of "delete" mean "replace implementation".) But the purpose of the merger discussion from the beginning was to eliminate the case of two templates with slightly different syntax being in existence. So, don't worry; the substitution can go ahead without a problem. I still wait for your reply.

Best regards,

Codename Lisa (talk) 11:48, 13 July 2014 (UTC)

No, if we attach it to |version of=, it will capture legitimate uses of |version of= in {{infobox OS version}} (which now has this parameter). Actually, template:infobox OS version is a legitimate redirect to template:infobox OS, so I don't see any necessity of bypassing it. Furthermore, I am still not sure whether this merge version will be there for long – I really intend to start discussion about split them back – and in such case we really should keep the redirect usage where appropriate. — Dmitrij D. Czarkoff (talk•track) 11:57, 13 July 2014 (UTC)

I'm not sure what exactly you are trying to capture and why you are trying to capture it. But please carry on. And please start the split discussion before any other discussion. Best regards, Codename Lisa (talk) 12:02, 13 July 2014 (UTC)

I am trying to categorize articles that block redirection of {{infobox OS version}} to {{infobox OS}}, namely those using |family= in sense of "operating system" as opposed to "operating system family". I am currently updating documentation of this template to include new parameters. This update is required to make the actual problem with the merge visible. When I will finish that, I'll start the split discussion. — Dmitrij D. Czarkoff (talk•track) 12:24, 13 July 2014 (UTC)

I finished initial run of documentation changes and started split discussion below. I suggest local discussion first, and then probably RFC with more succint wording and polished arguments. I hope that you, Codename Lisa could write the RFC question if/when it is necessary. — Dmitrij D. Czarkoff (talk•track) 15:33, 13 July 2014 (UTC)

Some of these long parameters added to template leave almost no space for the actual values, so I temporarily disabled "white-space: nowrap;" See Windows Fundamentals for Legacy PC and Splashtop for examples. Best regards, Codename Lisa (talk) 12:20, 14 July 2014 (UTC)

I think it would be better to wrap the particular "Released to manufacturing", which was "Released to<br />manufacturing" in {infobox OS version}. Or – even better – forget about it entirely, as it is just plain trivia, definitely not significant enough for infobox by all means. — Dmitrij D. Czarkoff (talk•track) 16:29, 14 July 2014 (UTC)

I think its clear even in just this discussion that people do consider it significant and in my passes of OS_version articles it is referred to often (even though the confusing parameters sometimes placed RTM date information into the "GA" row, something I tried to fix but was reverted). Remember, if its not appropriate for any particular OS, then leave the parameter blank and RTM won't display on the article. No need to make a bunch of articles lose information that is relevant to them just because its not relevant to others. --Netoholic @ 19:15, 14 July 2014 (UTC)

Of 900+ articles using this template it is relevant to about 50 (x86 Windows releases, MacOS releases and OSX releases). At the same time, the possibilities for confusion and misuse are endless. P.S.: Netoholic, could you, please, revert your edit: this redirect opens gates for abuse due to |family= parameter conflict. Not all editors are already familiar with new syntax or know about this merge at all. — Dmitrij D. Czarkoff (talk•track) 21:28, 14 July 2014 (UTC)

If an editor adds the infobox to an article, and they try using "family" and don't get the result they were expecting, they will look up the documentation and fix it. The redirect will point them to the correct merged template name and to the documentation of the syntax. There is no need for a tracking category. -- Netoholic @ 22:16, 14 July 2014 (UTC)

Sure. Unfortunately, editor may not even inspect the result, being sure he knows how to handle {{infobox OS version}}. Or see this edit for example of another potential probelm. — Dmitrij D. Czarkoff (talk•track) 10:03, 16 July 2014 (UTC)

I can sympathize how it feels when you're reverted after making technical improvements. That doesn't mean you stop moving ahead. --Netoholic @ 17:18, 16 July 2014 (UTC)

You've missed the point: the editor was acting under strong believe that he knows how to handle {{infobox OS version}} without knowing that it was merged and this parameter now means something it didn't use to mean. That is: he accidentially inserted misinformation to the article (well, not really, because in this case it was |family=Microsoft Windows, which is absolutely OK), just because he was expecting things to be stable. Given that most likely he was never aware of TfD or merge discussion, that is a reasonable expectation, isn't it? That is the only reason I want to see a wrapper in place of {{infobox OS version}}. — Dmitrij D. Czarkoff (talk•track) 19:42, 16 July 2014 (UTC)

All it takes is to inform the editor of the changes. Let him know that these two templates are now one, and that some of the parameters are changed/changing. -- Netoholic @ 20:39, 16 July 2014 (UTC)

You are again missing the point: the problem is not with one particular editor or edit, but with the unknown set of editors. That's why there are grace periods and wrappers. — Dmitrij D. Czarkoff (talk•track) 23:11, 16 July 2014 (UTC)

Does it help to think that I am "missing the point", so you don't have to acknowledge that I disagree with the point? I trust that editors will correct any future mistakes in the parameters, either themselves or the people watching the pages. I have no confidence that any tracking category will actually be monitored by anyone, and highly doubt mistakes last long enough to show up there. Based on the rest of the discussion here, I suspect the real reason for the wrapper is to keep the merge from being fully completed, and eventually to keep trying to split these back up. That mindset is limiting. Time to move forward and treat all OS articles under one umbrella, and address education as its needed. People are pretty smart and they'll figure this out. -- Netoholic @ 03:27, 17 July 2014 (UTC)

I hope that you are missing the point, because otherwise your comments don't make any sense. I was monitoring this category, and will be if you stop blocking its usage. It does not hurt anyway. Obviously, the wrapped has nothing to do with completion of the merge – it was already complete when it was installed, and nothing changes in this regard. Obviously, it has nothing to do with split discussion – the list of articles using {{infobox OS version}} is available here, and wrapper does not help in any way. Unlike you I have a respect for others' opinions, and the only reason I want this wrapper to be there is to reduce the damage from parameter conflict of pre-merge templates. Do you have at least any argument against this wrapper, which is not based on bad faith assumption? — Dmitrij D. Czarkoff (talk•track) 08:23, 17 July 2014 (UTC)

Mini-poll: wrapper

Question

{{infobox OS version}} was merged into {{infobox OS}}. Both these templates prior to merge used |family= with different meanings behind this parameter ("operating system this release is version of" and "operating system family this OS belongs to"), so during merge the |family= parameter of less used {{infobox OS version}} was renamed to |version of=. Corresponding changes were committed to all articles which used {{infobox OS version}}, but this change still causes confusion among editors (examples: 1, 2). I propose a wrapper template in place of {{infobox OS version}}, which would convert |family= into |version of=, and put all instances of such |family= parameter use in articles into Category:Articles using infobox OS version syntax (which was used during merge for this purpose), transparently passing all other arguments intact, for the time span of one month (until 14 August 2014)? Alternative option, as suggested by Netoholic in discussion above, is to leave everything as is in hope someone would eventually fix the misuse of parameter. — Dmitrij D. Czarkoff (talk•track) 08:28, 17 July 2014 (UTC) (updated at 14:33, 17 July 2014 (UTC) per comment by Widefox below)

• Support (obviously). @Netoholic, Codename Lisa, and Jeh: pinging participants of this discussion. — Dmitrij D. Czarkoff (talk•track) 08:28, 17 July 2014 (UTC)
• Support Maybe with a "template is going away" warning. Jeh (talk) 08:53, 17 July 2014 (UTC)
• Comment @Plastikspork, Rezonansowy, Uniwersalista, Longbyte1, Pigsonthewing, Wizardist, and Lukeno94: @Dogmaticeclectic, Widefox, ViperSnake151, Aunva6, EverythingGeography, and OsmanRF34: - Pinging the people that voted in the original TFD to see what they think about your plans to continue to delay this merge, per this wrapper suggestion and the #Split OS versions back section below also. -- Netoholic @ 09:41, 17 July 2014 (UTC)
  • You are constantly accuse me of delaying the merge. What exactly am I delaying? Which part of merge is not finished? — Dmitrij D. Czarkoff (talk•track) 14:36, 17 July 2014 (UTC)
• Comment I see a solution, but no (concise) description of the problem and options. (below there's discussion of splitting, 10 months since the previous consensus to merge, so I don't feel like I can input without an overview). Widefox; talk 11:41, 17 July 2014 (UTC)
• Oppose I've been in favor of substing all implementation of {{Infobox OS version}}, leaving nothing but a redirect behind. When Dmitrij protested, I deferred, because his course of action was harmless. IMHO, the problem of some people reverting the change from |family= to |os version= was because of not pushing forward. A link to the TfD in the edit summary was a must. Best regards, Codename Lisa (talk) 14:36, 17 July 2014 (UTC)
  • How exactly would substitution or link to TfD help with naming clash? — Dmitrij D. Czarkoff (talk•track) 14:40, 17 July 2014 (UTC)
    • Along with a subst, it prevents revert. Good faith erroneous reverts occur because of lack of knowledge. When sufficient context and reason is provided, the good-faith reviewer does not revert. Golden rule of editing Wikipedia: The best editor is the one writes the best edit summary. Best regards, Codename Lisa (talk) 14:44, 17 July 2014 (UTC)
      • Although I don't agree, you definitely have a point: my edit summary was far from perfect. — Dmitrij D. Czarkoff (talk•track) 15:43, 17 July 2014 (UTC)
• Oppose: This change is still very new, if after six months there still seems to be a major confusion among editors then it may be good to discuss it. I think it is just a matter of people needing time to adapt. — {{U|Technical 13}} ^{(e • t • c)} 15:38, 17 July 2014 (UTC)
• Mixed I don't really see any distinct difference between the two parameters' meanings, so what's the big fuss about it? I haven't really seen an OS version that is in an OS family but is not a specific version of that OS, nor have I seen it the other way around. Longbyte1 (talk) 23:19, 17 July 2014 (UTC)
  • @Longbyte1: Mac OS X Lion is version of OS X, but belongs to Unix-like family. Android L is a version of Android (operating system), but belongs to Unix-like family. Windows Phone 8 is version of Windows Phone, but belongs to Microsoft Windows family. One would argue that OS family (what |family= parameter of this infobox is talking about) is a property of operating systems, not of their releases/versions. — Dmitrij D. Czarkoff (talk•track) 09:35, 18 July 2014 (UTC)
    • I partially agree. "Family" is a lose metaphor, not a technical jargon with definition. Unix-like not a family because its members are not developed by one developer. It is a trait, like "operating systems with GUI" or "x86 operating systems". My proposal for creating |version of= was to strike a compromise with User:Netoholic about the location and style of the text, not to cause a schism. Best regards, Codename Lisa (talk) 13:23, 18 July 2014 (UTC)
      • I agree. Any category that lumps Mac OS X Lion and Android L together is so broad as to be almost meaningless. I also wonder if the "family" designation on individual articles is backed up by a reliable external source that identifies that, or if this is a designation that Wikipedia authors have come up with. If "Version_of" is the "parent", "family" should be the "grandparent", not the great-great-great-great-grandparent. Android's "family" then should be something like Linux for mobile devices, which I think there is a lot more reliable sourcing for. To keep "family" relevant, you need to define it better and put it in the template documentation. -- Netoholic @ 16:19, 18 July 2014 (UTC)
        • Family applies to all immediate relatives, so the families of Windows XP, Android L and OS X are Windows NT, Android and OS X. Windows is a super-family. Try searching for the word "family" in Ars Technica, CNET and Softpedia News. You'll see what I mean. Seriously, isn't it obvious? Windows XP is the predecessor of Windows Vista, then these two are from a family. Best regards, Codename Lisa (talk) 16:46, 18 July 2014 (UTC)
          • @Codename Lisa: there are two different, unrelated sets of termins, which share some words. Windows Phone 8 is part of Windows Phone family, which is family of Windows Phone releases. In this sense Windows Phone itself belongs to the family of mobile OSs by Microsoft. Same is true for Ubuntu 10.10, Ubuntu and GNU/linux, or for OS X 10.5, OS X and MacOS. There is another, completely unrelated term family, which defines groups of operating systems from CS point of view. In this sense classic MacOS and MacOS X don't belong to the same family, while Android and OS X do; all systems from Microsoft with the word "Windows", together with ReactOS, belong to the same family as well. That is the root of problem here: if you speak of the former meaning, there is indeed no family "Unix-like", and "Windows" is a family that only includes some of MS's OSes up to Windows ME. If you speak of the latter, there is no family "Android" or "OS X". This ambiguity always allows to clump everything together, but the result would be completely meaningless.
            @Netoholic: OS X and Android have more in common, then OS X and classic MacOS. They even share more source code. — Dmitrij D. Czarkoff (talk•track) 18:35, 18 July 2014 (UTC)
• Weak oppose: Temporary templates should be discouraged. Dogmaticeclectic (talk) 00:23, 26 July 2014 (UTC)

Split OS versions back

Now that merge (per outcome of TfD discussion) of {{infobox OS}} and {{infobox OS version}} is mostly complete, I want to start discussion about splitting them back. The problem here is that these templates are largerly incompatible. I am not talking here about minor editorial issues (styling, sectioning, parameter name clashes, parameter naming convention, etc.), but rather about much more fundamental differences:

1. The set of dates to be covered is very different between operating systems and their versions:
   • Released to manufacturing applies only to OS versions. For example, each Microsoft Windows release was released to manufacturing at some point.
   • General availability is tied to target audience of operating system, which may differ significantly from release to release. For example, First release of Plan 9 from Bell Labs was targetted at universities; Second release – at business users; Third release – at mass consumption (first gratis release); Fourth release – at developers (first "free software" release); Fifth release didn't happen yet. That is: target group changed with every release, denoting every release as date of general availability for some users.
   • Initial release is clear for operating system (first time developer published the system) but is problematic for releases: ambiguous between RTM and GA dates.
   • Latest stable/preview releases for OSes are clear, but for OS versions are mostly meaningless. Most OS versions don't progress through versions once released; those that do don't require expensive (in terms of server load) processing of external versioning templates, because this information is mostly local to the article.
2. The due weight considerations for latest releases of OSes and versions are also very different: for OSes this information is rather important and belongs to top or middle position within infobox; for OS versions this information is rather obscure, and even if there is something to list, it is the least important aspect.
3. Working state: OSes mostly are either Active or Discontinued, while OS versions are either Supported or Unsupported. These are not exactly incompatible, but require completely separate documentation. Joining them facilitates erroneous editing decisions with consequent unnecessary discussions, cosmetic and/or misinformed edits and edit warring.
4. Support status is different for each release, and may be quite complicated even for individual releases. Provided the available detail for support status of Microsoft Windows releases, the inclusion of this field to the infobox of Microsoft Windows will most likely lead to regular disputes about the level of detail to be covered in the infobox. At the same time, this field is natural and appropriate in infoboxes of OS versions.
5. Predcessor/successor information:
   • It has different due weight and different optimal representation with infobox. While this information is critical for OS versions, it is of arguable worth for OSes (not so many systems were officially deprecated in favor of another OS).
   • It appears natural to use {{succession box}}-like presentation of OS versions, similarily to the way {{infobox former country}} implements that. But for OSes, which rarely have predcessor or successor such approach is impractical and damaging, just like for {{infobox country}}.
6. Finally, here goes the "family" problem, which is lately recieving excessive attention at several different locations throught Wikipedia. This word has different meanings in context of OSes (where it denotes the range of several closely related operating systems) and OS versions (where it is alias of "operating system"). Linux Mint 10 is a release within "Linux Mint" family of OS releases, but it belongs to "Unix-like" family of operating systems. Currently these are disambiguated within this template between |family= and |version of= respective parameters, but I can bet that amount of errors will be excessive for both parameters. ({{infobox OS|name=Fedora|version of=Linux|family=Unix-like}} anyone?) This problem is saturated by the fact that drive-by editors from RFCs, WP:3O, WP:DRN and similar avenues will simply not notice the inconsistency between "{{infobox OS|name=MacOS X Lion|family=MacOS X}}" and "{{infobox OS|name=MacOS 7|family=MacOS}}", leaving passionate knowledgable editors frustrated. If this looks like overstatement to you, please see this discussion and this followup. Yes, these things are important to some of us.

Based on all of this, I suggest splitting these templates back. — Dmitrij D. Czarkoff (talk•track) 15:27, 13 July 2014 (UTC)

I wonder if the root of the problem lies a little deeper. Maybe we need a template for "OS family" and one for "OS family member". Jeh (talk) 22:17, 13 July 2014 (UTC)

The decision was merge. Find a way for Infobox_OS_version to use Infobox_OS. -- Netoholic @ 03:28, 14 July 2014 (UTC)

WP:Consensus can change, and this is shaping up to be a very good example of that. Perhaps we shouldn't merge after all. I might even oppose merge from this point forward. Perhaps a new discussion should be called with all previous participants in the CfD as well as those here as well as those in associated WikiProjects. Elizium23 (talk) 03:51, 14 July 2014 (UTC)

No, this is game-playing. There is no technical or logical reason that all operating systems can't use the same template. You can even define completely different sets of parameters, if you want. What seems to be happening is a rift between the "old-tech" and "new-tech" guys that think their stuff is so different that it can't work. Its bullocks. -- Netoholic @ 03:56, 14 July 2014 (UTC)

Ahem. "Consensus can change" is part of the Wikipedia policy on consensus. Not a guideline, not an essay. Policy. That isn't "gameplaying." To ignore this, to fall back on a year-old decision that did not involve the vast majority of users of the template (OS page maintainers), is to ignore one of Wikipedia's key principles. WP is supposed to be edited collaboratively. A "service organization" like TFD should not even be interested in forcing its decisions on users who disagree with them.

On topic: an operating system family isn't at all the same thing as an operating system (i.e. a family member). And "version" or "release" can be a different thing yet again. Why should the people who need to use a template have to puzzle over a bunch of parameters that have nothing to do with their subject? Jeh (talk) 06:45, 14 July 2014 (UTC)

@Elizium23 and Netoholic: templates are merged now. I left a wrapper at {{infobox OS version}} just to catch misuse of |family= parameter. template talk:infobox OS version is already redirected here, as well as template:infobox OS version/doc. {{infobox OS version}} may also be redirected any second, although a grace period for people to get used to |version of= vs. |family= is required.

Netoholic, I am fed up with your bad faith assumption. As demonstrated by the merge there is no technical reason making use of this template impossible for both operating systems and operating system releases. There are multiple editorial issues that make it impractical, particularily provided that these two sets are not homogenous as you are trying to present. — Dmitrij D. Czarkoff (talk•track) 08:42, 14 July 2014 (UTC)

• This is indeed GAMING because CCC says proposing to change a recent consensus can be disruptive. This merge consensus is barely a few days old and has just been completed, proposing that CCC that quickly is disruptive and I urge you to drop the stick and give it 4-6 months to see if it really works or not. — {{U|Technical 13}} ^{(e • t • c)} 15:49, 17 July 2014 (UTC)

• The consensus you are talking about is a TfD discussion from August 24, 2013 (about eleven months ago). I was not aware of that discussion, did not participate there, was not notified of it and never had a chance of voicing my opinion, so there is no slightest sight of WP:GAMING here. At any rate, I have no problems with giving the merged template a go for some time. — Dmitrij D. Czarkoff (talk•track) 22:50, 17 July 2014 (UTC)

From someone that's worked through a lot of these kinds of merges, some suggestions for post-merge priorities:

• All decisions related to Template:Infobox OS now have to take into consideration that it is being used on all operating system articles and any versions thereof.
• The vast majority of existing label/data rows are suited fine for any article using this template, but a few parameter names are complex, redundant, and unclear (in particular, the handling of release dates could be done with several parameters, and any that don't apply can just be left blank, hiding the rows).
  1. Decide what data fields you want to see in infoboxes. You can even say what fields you want only in versions or only in broader OS articles, but don't make that automatic assumption... try to commonize where possible.
  2. Establish what the best label is for each particular type of data.
  3. Place a parameter name in the template that matches and put that into the documentation (ex. if Initial release is an important bit of data, then you should use |initial release=). This helps people not have to refer to the template documentation, they can add parameters on the fly.
• As people work on articles, they will over time convert them to the standard parameters for you. You could even flag any (OS or OS_version alike) that uses deprecated parameters the same way they do with citation templates - categories and CSS-hidden warning text.

Lastly, take note of what labels/data and parameters they use in Template:Infobox software and stay in sync where possible. If I had to guess, a merger of between Infobox_OS and that one has potential to be suggested at some point, that's more likely than this one being split back up. --Netoholic @ 04:45, 14 July 2014 (UTC)

• Oppose splitting them back apart. While I acknowledge that CCC, it doesn't happen that quickly and this proposal is disruptive. — {{U|Technical 13}} ^{(e • t • c)} 15:49, 17 July 2014 (UTC)

  Comment You're mistaken. The consensus to merge is from a discussion at TFD that happened about a year ago. In which time virtually no one moved away from the "OS versions" template, suggesting a grossly unpopular decision made without sufficient input from the template's users. It is TFDs forcing of this old, improper decision on a clearly disapproving user community that is disruptive. What is happening now is not a recently-formed consensus deriving from a proper discussion, it is going along with the path of least resistance, for now. STILL without input from the vast majority of the template's users. Jeh (talk) 17:42, 17 July 2014 (UTC)

  • It doesn't matter when the consensus happened. What matters is that the consensus was just carried out and no-one has had time to see how the change will work. I disagree that it taking a year for someone technically minded enough to properly merge the templates over a year to do so has any bearing on how much or little of a consensus there was. It was just the lack of a volunteer capable of carrying out the work. Please, don't confuse the two. — {{U|Technical 13}} ^{(e • t • c)} 20:54, 18 July 2014 (UTC)
• Comment: User:czarkoff, would you mind elaborating on your arguments above? Specifically, I would like to know which - if any - of your points you feel could not reasonably be fixed so that one template could cover both situations. Dogmaticeclectic (talk) 00:35, 26 July 2014 (UTC)
  • The problem here is not that they can't coexist – they can, and do so right now. The problem is that OS and OS release are distinct topics with different terminology and different weight of individual pieces of information, so the encyclopedic coverage of both sets would benefit from separate templates. — Dmitrij D. Czarkoff (talk•track) 03:50, 26 July 2014 (UTC)

{{Infobox OS }} should be agnostic between release and version

The usage of the terms release and version is not consistent among vendors; indeed, it is not always consistent among vendors, e.g., IBM has used release numbers subordinate to version number for some products and version number subordinate to release numbers for other products. The {{Infobox OS }} template really ought to be agnostic is to which is subordinate to which. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:30, 12 February 2015 (UTC)

Hello, Chatul. I have a lot to say about this but, to have a fair discussion, if you have an idea as to how this should be implemented, please let us know.

Best regards,

Codename Lisa (talk) 01:49, 13 February 2015 (UTC)

I'd suggest keywords of Version-i and Version-nomenclature-i for i at least from 1 to 3, with 1 being the highest level,e.g., for level within release within version it would be

version-1-nomenclature = Version |

Version-2-nomenclature = Release |

Version-3-nomenclature = Level

Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:53, 18 February 2015 (UTC)

I am not sure I follow. What are these exactly?

Best regards,

Codename Lisa (talk) 18:14, 19 February 2015 (UTC)

The intent is to allow the editor to indicate the particular nomenclature used by a vendor for numbering releases of a particular product. I was suggesting version-1-nomenclature for the vendor's designation of the major number, with version-1 being the corresponding number. Similarly, version-2-nomenclature would be the vendors term for the number subordinate to version-1-nomenclature. I was assuming that three levels were enough, but have no reason to limit it to three. Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:14, 23 February 2015 (UTC)

Yes, but I am still at the dark as to what change you are proposing to this template, or at least how the syntax and rendering result must have changed after I accomplish this change.

However, I general, what you explained goes against MOS:STABILITY. Wikipedia has no mandate to use the same language and nomenclature that one vendor uses. Best regards, Codename Lisa (talk) 13:52, 27 February 2015 (UTC)

I'm confused: MOS:STABILITY redirects to MOS, and I don't see a section with stability in its title. What section are you referring to? Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:45, 4 March 2015 (UTC)

Yes, it redirects to a very specific sentence in WP:MOS. Best regards, Codename Lisa (talk) 21:23, 4 March 2015 (UTC)

Are you referring to Style and formatting should be consistent within an article, though not necessarily throughout Wikipedia.? That sentence refers to changing the style of an existing article, not to what layouts can or should be offered by a template. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:50, 8 March 2015 (UTC)

Not done: After almost a month, it is still unclear as to what is exactly requested. Personally, I cannot possibly make a change when all I have is a vague topic like "should be agnostic" and some vague pseudo–pseudo-code like above. Best regards, Codename Lisa (talk) 19:37, 8 March 2015 (UTC)

Contested addition of | forked from

I contested the addition of a |forked from= parameter, added by our friend MureninC (talk · contribs). The change by MureninC imported this information from WikiData automatically. I find this highly controversial. Deeply technical information such as this definitely needs a source. In fact, this issue is so severe that I say without a source, this field must not show its contents.

Just imagine the horrors this field can cause without a source: Would-be know-it-all editors (face it; we do have such editors) fighting over whether Windows 10 is a fork of Windows 10 Mobile or Windows 10 Mobile a fork of Windows 10, or both being an edition of the same thing. Worse: There would be a war over whether Linux X is a fork of Linux Y or Linux Z, especially when two different sources contradict each other on this.(And we have to cover both, without taking side.) Remember the |programming language= fiasco? People who didn't know the programming language just filled the field in with "C / C++"! (Even now we have people who put "multilingual" into |languages= and "multiplatform" into |platform=.) Such a field as |forked from=, if added, must be subjected to additional treatments to ease oversight.

Fleet Command (talk) 17:44, 23 December 2015 (UTC)

Ugh... I don't even know what to reply here... Why would anyone claim, or even have to claim in the mere presence of |forked from=, that Windows 10 is a fork of Windows 10 Mobile, or vice versa? Likewise, why would such claim be made without references? Wikidata does have support for what appears to be any number of references for each claim; it does appear that such references can be pulled into Wikipedia, too, for example, see ru:Шаблон:Карточка_ОС and ru:Шаблон:wikidata/p348, which does pull in the references. Are you suggesting that Wikidata itself is unreliable, and should not be used, and should not be trusted? Else, why are you reverting this, instead of improving the template to pick up the references from Wikidata, which is indeed not done in this template for any of the other stuff picked up from Wikidata, either? Why would there at all be a war over Linux forking? All such things would be quite clearly documented in git. And what does "C / C++" fiasco has to do with this? Was it a reason to remove the language param from the infobox? (It looks like |programmed in= is still in.) If we follow this argument, that things have to be not present, because they can be abused, and fail to be properly reviewed, then doesn't that go against the whole notion of what is Wikipedia? And are you suggesting that Wikidata as a whole is not oversighted enough? MureninC (talk) 22:16, 23 December 2015 (UTC)

@MureninC and FleetCommand: Picking up references from Wikidata could be problematic. If possible, how do we write a code that complies with WP:FACR requirements? I have seen the referencing system in Wikidata; it is impossible to add all the necessary fields like publisher, author and cited work if those items do not have a Wikipedia article or Wikidata entry associated with them. I myself have once been to FACR; the process is brutal. I find it horrifying and even totally plausible to imagine a FACR nomination might fail just because some guy edited something on Wikidata.

That said, I hate other stuff exists/other stuff don't exist (OSE) discussions without a reason. I grant that FC here is invoking a past instance of something that happened and suggesting a course of action based on that (as opposed to suggesting a course of action merely because it was taken).

As for "Why would there at all be a war over Linux forking?" there already is. We also already had a fight over whether Windows Phone 8 is a member of Windows NT family or Windows Phone, because apparently it is using NT kernel instead of CE kernel.

Maybe we should invite other member of WikiProject Software to this discussion. Then we can call in an RfC.

Best regards,

Codename Lisa (talk) 16:36, 25 December 2015 (UTC)

I have to say, I personally do find wikidata interface very annoying, annoyingly slow and hard to use.

That said, if noone's using wikidata, how will it ever improve? I actually do see the data from wikidata getting used much more thoroughly on the Russian and Belorussian wikipedia templates (although only the Russian one appears to pick up both the external references and as well as make wikilinks to the referenced items, too (and any number of either), where Belorussian only does wikilinks (still, any number of elements, though), and here on the English one the templates only seem to pick up the first value of a property, and don't bother not only with the external references, but don't even make up any wikilinks, either, nor do they bother with showing multiple items for a property).

As for wikidata's reference support, I agree, adding references to wikidata is a huge pain, due to its uber-slow dynamic interface and lack of a copy-paste functionality (e.g., if a single reference is used more than once, either on the same article, or multiple different articles). However, the rules specifically do allow for individual authors to be added as new entries to wikidata, without having to satisfy notability like it would have been for new articles here on wikipedia, so, it's not impossible (plus the title is just a text field).

What is annoying, however, is that it appears that results of this work don't actually properly show up anywhere other than the Russian wikipedia (through just some templates, and not others, and only when the page does not explicitly fill in the template fields), plus the slow interface and lack of copy paste means that only the most determined people will bother to add more than the URL and the title (and the slow and dynamic language selection means that even adding a title is very slow and problematic, plus the lack of copy paste for the whole reference if used more than once).

Best regards,

MureninC (talk) 21:30, 25 December 2015 (UTC)

I have been to one WP:FACR and one the many things that was brutally scrutinized was the citation style. Is it possible to implement a code that generate the following?

Mills, Elinor (18 June 2009). "Microsoft's free antimalware beta on the way". CNET. CBS Interactive. Retrieved 10 July 2009.

Or does Wikidata not allow it? You might want to review {{Cite web}} and {{Cite book}} for their parameters. Things like |isbn=, |number= and |volume= need to be supported.

If you want to drive motivations for improvements in WikiData, you can start with something less high-profile in this infobox, like |RTM date= and |GA date=.

Best regards,

Codename Lisa (talk) 21:48, 25 December 2015 (UTC)

Yes, it should be totally possible. Dates are supported; if the author doesn't exist, one can create a new wikidata entry just for the name of the author (admittedly, the process is cumbersome, as I've already mentioned above); title is just text; publishers generally already have wikipedia pages, and can be wikilinked automatically, too, if the pages exist.

I've finally found a bit more details – it looks like Module:Wikidata is what must be used to have proper rendering and linking of stuff from wikidata; however, just like the infobox templates here themselves (with the redundant underscore aliases), it does seem to suffer from a massive lack of big-picture understanding and direction – it doesn't have a universal usage guideline, instead suggesting contradicting ways that it can be employed within the infoboxes (e.g., whether you must explicitly pick up stuff from wikidata within each page that employs an infobox, which seems non-scalable and problematic for introduction of new fields, vs. the automatic pick up, vs. letting the page overwrite the field by simply having an empty parameter, which likewise seems to be non-scalable, as it's been a general practice to include the whole template on a given page, letting users fill in the blanks, which means that all pages must be updated at least once to not automatically blank the fields from wikidata in such usage etc); additionally, unlike the ru:Модуль:Wikidata, it currently doesn't appear to have documented support for references.

* references — булевый переключатель (по умолчанию true).

I've started Module talk:Wikidata#Why the references from Wikidata get dropped? in an attempt to get some clarification.

Best regards,

MureninC (talk) 01:02, 31 December 2015 (UTC)

Link rot

The URL parameters give references with bare URLs that may constitute link rot. GeoffreyT2000 (talk) 05:57, 13 January 2016 (UTC)

Hello. When you put a bare URL in it, yes, gives a bare URL. If you put a {{cite web}} in it, however, it works.

But not need to dodge the question: We are aware of the problem. Deprecation is favorable but it is not a one-man's job. (Well, ... technically, if you pay the man for a full time job... it is.) Feel free to ignore |_url= parameters and insert the citation directly.

Best regards,

Codename Lisa (talk) 00:19, 15 January 2016 (UTC)

support status -> release status

Should support status be renamed to release status? Is that about whether the OS is in alpha or beta stage? See this discussion why I ask: https://en.wikipedia.org/wiki/Talk:Android_N#Release_status   Daniel.Cardenas (talk) 20:59, 15 June 2016 (UTC)

@User:Daniel.Cardenas: Definitely not. Support status is about the support policy of the developer, i.e. for how many years are there technical support, patches, and feature packs. (Canonical and Microsoft both have such policies for Ubuntu and Windows.) Things like alpha and beta stage are handled by |preview version= and |preview date=. Fleet Command (talk) 08:38, 16 June 2016 (UTC)

Need something that indicates the quality of the release. latest preview version looks like it is asking for a version identifier. For android all of the releases are called preview 1, preview 2, etc... But quality is given on this page: https://developer.android.com/preview/overview.html , search for alpha and beta. Should we add a field like quality status that explicitly calls out the quality? Thanks for the help, Daniel.Cardenas (talk) 11:00, 16 June 2016 (UTC)

Displaying more than one stable or preview release?

Sometimes there might be more than one preview release; for example, iOS and OS X have betas of updates to the current stable release and two betas of the next major release, one for developers and one for users (the two betas for iOS 10 have the same build number, but the two betas for macOS Sierra don't).

There might also be multiple stable releases, although that seems less likely.

The only ways I've seen to display that are:

• put the full release information - version and release date - in the "latest xxx version" parameter, with a <br/> between them to put them on separate lines, and don't use "latest XXX date" at all;
• use a template for that information, and use multiple {{LPR}} or {{LSR}} templates in the body of that template.

The former means you don't need a possibly-otherwise-unnecessary template for the release information; the latter means you aren't stuffing dates into "latest xxx version", in case some software cares about the metadata and wants the version and date information separate.

Which of those is best, for articles that don't already have version information templates for other reasons? Guy Harris (talk) 02:25, 8 July 2016 (UTC)

Hey. I don't think you should list multiple version numbers. Only the latest version. The connotation of announcing the next major version is far different from announcing the next major patch, and I think it is quite clear that for Wikipedia infoboxes, which are subject in glance, the former is more important. Fleet Command (talk) 07:03, 8 July 2016 (UTC)

OK, you're saying that the only "preview versions" we should list in any infobox are "next major release" preview versions, not "next software update" preview versions? Guy Harris (talk) 18:19, 8 July 2016 (UTC)

And if an OS has separate developer and public beta versions, as macOS and iOS do, should only the most recent of them be shown (even if, as appears to be the case based on build numbers, a developer beta coming out on July 5 is a newer build than a public beta coming out two days later)? Guy Harris (talk) 21:14, 8 July 2016 (UTC)

I never said only. If someone reported something minor, the best thing is to do nothing about it. (Assuming there is nothing else wrong with the whole contribution.) But I think we should report the latest version (as opposed to the most recent one). When you have a dilemma, answer this question: Which of these versions represent the highest point of the OS development? For example, report XXX v21.0 released 20 July 2015 (latest) instead of XXX v20.203 released 20 January 2016 (most recent). FleetCommand (Speak your mind!) 16:59, 9 July 2016 (UTC)

"I never said only." What you said was "Hey. I don't think you should list multiple version numbers. Only the latest version.", so you did, in fact, say "only".

Your comment pretty much amounts to "don't list betas of updates to the current major version". Others who have updated the infoboxes seem to disagree, so I don't see a consensus either way. Guy Harris (talk) 18:55, 9 July 2016 (UTC)

Don't put words in my mouth. Articles about individual versions of an OS, e.g. Windows XP can still list beta service packs. Windows 10 and Windows 10 Mobile notably update the version numbers often.

iOS and OS X are not the only OS articles on Wikipedia. And it seems so self-contradictory that a field reads "latest preview version" and lists a far-from-latest version. FleetCommand (Speak your mind!) 23:04, 10 July 2016 (UTC)

Not listing, in the main article for an OS, preview versions of updates to the current major release seems reasonable. I'd still want to hear others weigh in on this, however.

That still doesn't address OSes that have, for the next major release, two streams of preview updates, a "developer" stream, and a "user" stream, with the first one presumably intended for people testing 1) whether their existing versions of their software works on new releases and 2) whether under-development versions of their software that uses the shiny new features of the new release works correctly, and with the second one intended for people who want to test 1) whether the new version works for them and 2) whether the shiny new features of the new release work for them. The "developer" stream releases may have a newer build as the latest version than the "user" release does - the expectation might be that people wouldn't use the "developer" releases for day-to-day work but that people willing to live on the bleeding edge might use the "user" releases for day-to-day work - and might even have a newer build come out in the "developer" stream before an older build comes out in the "user" stream.

There might be some who would argue that this means the most recent builds on both streams should be shown. Guy Harris (talk) 00:29, 11 July 2016 (UTC)

The situation you are describing reminds me of Windows 10 that has three release rings: Fast, slow, release preview ring. If you want to ask others, then, according to X!, you should probably ask ViperSnake151, Codename Lisa, NeoGeneric, The Professor123 and Comp.arch. Of course, you can look up OS X and iOS stats but you yourself are the top editor there. (Now that I come to think of it, I have only seen you adding multiple version numbers; it was some office software article.) FleetCommand (Speak your mind!) 07:26, 11 July 2016 (UTC)

If by " I have only seen you adding multiple version numbers" you mean that I'm the only person you've seen adding multiple version numbers, rather than that you've never seen me, for example, reducing multiple version numbers to single version numbers, I'm not the only person who's put multiple versions into inboxes in OS X and iOS articles - I'm not even the person who started the tradition; see, for example, this edit, which put in both software-update and next-release betas, and this edit, which adds separate developer-track and user-track (public) betas.

I'd rather just throw something out to the general public, so I'll try putting something in the talk pages for various OS X, iOS, and Windows pages; if that doesn't provoke any response, I'll consider asking the people you mention, as well as IAdam1n and possibly Bbb2007. Guy Harris (talk) 08:00, 11 July 2016 (UTC)

Good idea. FleetCommand (Speak your mind!) 08:11, 11 July 2016 (UTC)

OK, done. I somewhat arbitrarily chose Talk:OS X, Talk:iOS, Talk:Windows NT, Talk:Ubuntu (operating system), Talk:Red Hat Enterprise Linux, and Talk:Debian for OSes and Talk:macOS Sierra, Talk:iOS 10, and Talk:Windows 10 for OS releases; perhaps other Linux distributions, *BSDs, and commercial UNIXes, and various non-UN*X/non-Windows OSes should be included, along with other Darwin and Windows NT derivatives, and so on. Guy Harris (talk) 08:23, 11 July 2016 (UTC)

Hello, Guy Harris

I saw your messages which you have left everywhere. They say that you are comfortable with whatever outcome. Also, I mulled over your rather aggressive conversation with FC here. The rather contrasting attitudes notwithstanding, please tell me what is the core problem anyway? Is there something you want done and can't?

Best regards,

Codename Lisa (talk) 14:05, 12 July 2016 (UTC)

No, there isn't. All I want is to make sure that all sides are represented in this discussion, and some conclusion reached as to whether this infobox should support showing multiple preview and stable releases. If the conclusion is that it should, it should perhaps be modified in some way to do so more easily; if the conclusion is that it shouldn't, the places where it's showing that should be changed not to do so. Guy Harris (talk) 16:58, 12 July 2016 (UTC)

I am against changing this. Adding different preview versions adds unnecessary detail to the infobox and I do not see why it is not sufficient to mention the most recent version. The iOS 10 infobox is already far too bloated and repeats information that is presented well in the article itself, using lists or tables.–Totie (talk) 15:14, 20 July 2016 (UTC)

Deprecated fields lack a description and emphasis on deprecated status

I couldn't find a way to change deprecated status value to <strong>, like the way a required value is emphasized. It's also not very appropriate to use the description field of a deprecated field to state the deprecation status again, because that should be reserved for explaining the actual purpose of the feature. There was also a problem with Codename Lisa using uppercase letters to denote deprecation which may break accessibility, but I've fixed this. It would also be nice if the background color of those table rows could be changed for deprecated features, but I have no idea how to do this with templatedata. 80.221.159.67 (talk) 05:09, 7 September 2016 (UTC)

Minor reorder: ARM first?

Proposal: In Template:Infobox OS/doc, in section "Example", in the brief list of "supported platforms", move "[[ARM architecture|ARM]]" to the start of the list.

Reason: Such a move is long overdue, given how the microprocessor market has grown and evolved. Internationally and nationally, for many years, by unit volume, the sales and growth rates of ARM architecture chips, and devices based thereon, have exceeded those of the Intel architecture. In 2016, the number of ARM chips sold annually reached an estimated 4.1 billion. By unit volume and growth rate, a solid case exists to list ARM first. ARM occurring first or earlier in the order of the "supported platforms" list suggests and encourages a more volume oriented bias, viewpoint, or agenda, of fairly simple, transparent, unarguable Wikipedia:Neutrality; see WP:DUE. ARM being first is also more correct alphabetically, which makes lists cleaner and is aesthetically pleasing, but is of secondary importance to neutrality. This all seems obvious, straightforward, and uncontroversial.

Counter reason 1: In contrast, by financial value, the sales of Intel architecture chips, and maybe devices based thereon, have always exceeded those of the ARM architecture, and will for many more years, but the growth rate is far slower. ARM occurring last or later in the order of the "supported platforms" list suggests and encourages a more commercial, financial, and PC (Windows + Macintosh) oriented bias, viewpoint, or agenda, of greater complexity, opacity, and more debatable neutrality.

Counter reason 2: The example "supported platforms" treats the operating system Debian, which may have more instances running on Intel than on ARM architectures. However, the guidance in Template:Infobox OS applies to infoboxes for all operating systems, not only to one.

Conclusion: In a short list of computer chip architectures, should ARM be first or last? Ideally, Wikipedia should be exemplary in as many ways as possible, and stand well above as many questionable biases as possible.

I know that everyone is busy, and that these sorts of issues can take a long time to resolve. I will thus await response(s) for at least a month or two, which seems a reasonable time for comment. Then, if no objections are posted, I will make the proposed change.

Thank you all for your time in considering this matter. Have a healthy and productive year. -- Jerryobject (talk) 12:57, 26 March 2017 (UTC)

I would not support ordering by some strict measure of popularity. For one thing, there is the "popular by what measure?" problem. (Do we put ARM first simply because a lot more ARM chips are sold than x86 chips? Or shouldn't this be determined by how many ARM, x86, etc., chips are running the OS that's the subject of each particular article in which the template is used?) But ordering alphabetically is a defensible "neutral" choice that would just happen to put ARM near the beginning of the list.

Nevertheless it could be perceived as overly promotional of ARM. If your motive is really to eliminate perceived bias, or influence, then you should be arguing for a random sequence, to be chosen each time the template is used in a new article. Or hey! Maybe the template could pick a random sequence each time it's displayed...

On the other hand, Wikipedia is written for the general reader, and the general reader is far more likely to have heard of x86/x64 than of ARM. Putting a relative unknown like ARM first violates the principle of least astonishment. Hence ordering by familiarity is defensible. (And last is not necessarily a bad place to be. People remember best what they hear first, but they remember almost as well what they hear last.)

But really... what you're suggesting changing here is practically meaningless. It is just an example. The example lists shown here do not dictate ordering in the template's actual use. Nobody will see what's written here unless they happen to look at the template page. I find the notion that the example as constructed promotes any sort of "bias" to be abjectly silly, as silly as my not-serious idea of requiring a random sequence.

Can't you find something more important that needs doing here? And by "here" I mean Wikipedia in general.

If it isn't clear - this is an objection to your proposal. Jeh (talk) 13:49, 26 March 2017 (UTC)

And an objection that I support 100%, especially given that the list is, as you note, just an example - 99 44/100% of people won't even see it. Guy Harris (talk) 17:07, 26 March 2017 (UTC)

init system field

Hi, I think the default init system of operating system is a worthwhile field to add to the infobox. Like for Arch Linux the field would be systemd, while for Slackware Linux it'd be SysVinit and for Void Linux it'd be runit. Fuse809 (contribs · email · talk · uploads) 07:18, 10 October 2017 (UTC)

And what would it be for Windows NT or z/OS or VSE, to name three current actively-developed (the current versions of NT are called "Windows 10" and "Windows Server 2016") non-UN*X operating systems, not to mention other OSes such as OpenVMS, OS 2200, Burroughs MCP, etc.? Not every OS is a UN*X that has a UN*X-style notion of an "init system". Is the idea that this would be left blank for non-UN*X OSes? Guy Harris (talk) 08:57, 10 October 2017 (UTC)

Apart from applicability, it is intricate details that interest only a minuscule portion of our readership. Linux itself has a minuscule marketshare. (~2%)

Best regards,
Codename Lisa (talk) 09:45, 10 October 2017 (UTC)

Package manager is also a field not applicable to several more popular operating systems like Windows, yet it is still included in there. macOS has an init system too, as do the BSDs. Yes it would be not included in the infoboxes of OSs for which it is non-applicable. You can make the argument that the kernel and userland utilities are so intricate they aren't relevant to most readers either. Fuse809 (contribs · email · talk · uploads) 10:07, 10 October 2017 (UTC)

Good lord. I hate the "other stuff exists" argument. This is the second most hated argument in the whole Wikipedia too. If you really want to contribute to the discussion, your energy best spent focusing on pitching the requested change, showing us why it is a good idea. Dragging other fields into the mud gives the impression that your request has no merit on its own and you yourself are petty. In fact, many of the fields in {{Infobox video game}} are already removed. Same things might happen here too.

Best regards,
Codename Lisa (talk) 10:51, 10 October 2017 (UTC)

Thanks I didn't know such a policy exists. Also good point, must admit I don't have an argument beyond this, although I must also admit I have no argument for any field in the infobox. The reality is that not everyone finds every field interesting and important. From a practical point of view what does it matter when an OS was founded? To an end-user it makes little difference and I'm guessing that's the point of view of most PC users. Likewise what does it matter what kernel the system runs? The only field that would really matter to end-users is probably whether it is actively developed. If you could point me to something that gives clear guidance on these questions I might be able to come up arguments for this proposed entry. Thanks again, you're very informative. Fuse809 (contribs · email · talk · uploads) 13:59, 10 October 2017 (UTC)

@Fuse809: It is not a policy. It is a mere essay with no force in Wikipedia. Feel free to ignore everything I said so far. It has the value of an advice. And that advice is: If you want people to agree with your position, focus on showing how cool, convenient and benefitary your position is. Do not focus on arguing that "other worthless junk exists" because it makes your proposition look like junk.

But the policy that concerns you is a simple one: Consensus. All I have to say in that regard is that I don't think it is a good idea to fill the infobox with cryptic stuff that almost no one understands. And this is just my position. If the rest of Wikipedia thinks it is okay, or even a good idea, we will add it.

Best regards,
Codename Lisa (talk) 14:15, 10 October 2017 (UTC)

Afraid this comment was less clear than your last one. Thanks for clarifying it's not a policy, I know about consensus which is why I added this question in the first place, seeing whether others agree with my position. What is vague in your answer is what is "cryptic stuff" here? The kernel isn't too cryptic not to be included, nor is the userland utilities, nor is the programming language it is coded in, etc. So I'm struggling to understand what truly makes anything "cryptic" in this context. Help me understand what makes something too cryptic and what makes it just this side of acceptable? Fuse809 (contribs · email · talk · uploads) 14:21, 10 October 2017 (UTC)

I guess the question I have is.... is this actually important? We could stuff literally hundreds of properties about operating systems into these templates, and the dozens of ways that Linux distros in particular can distinguish themselves from eachother... but we don't because we have to force ourselves to be selective for the sake of readability to a global audience. Is "what framework the operating system uses to load device drivers and services" really as fundamentally important as "who makes this operating system" or "is this a current operating system"?

The answer to this is no.

Look, if you have an emotional attachment to the recent init debates in the Linux community, that's fine, but please try to let that emotion go before contemplating what is important on Wikipedia. I get it, there's a lot of passion about systemd and all that but it's a narrow issue that shouldn't affect how we describe all operating systems. Warren -talk- 14:27, 10 October 2017 (UTC)

Na I'm easy as far as init systems go, so it's got nothing to do with emotion. It's just I think it's an important piece of information for readers. If someone is reading about an operating system it probably means they're interested in it and its most important properties. In the Linux world and most other less popular operating systems Wikipedia is a great source of information and I think the infobox (I suspect you's will agree with this) is meant to give people a quick glance over the critical features of the system. I think the init system is an important and critical property. Must admit I fail to see how init system is any less important than kernel, userland utilities or who it is developed by. Trying my best to understand yas position here. I get cramming heaps of useless stuff would be problematic, but how is an init system useless? Fuse809 (contribs · email · talk · uploads) 14:32, 10 October 2017 (UTC)

What if there's more than one predecessor?

@Dimsar01: Mac OS X 10.0 has a {{Infobox OS version}} with two predecessors - Mac OS X Public Beta and Mac OS 9. The automatic linking done by this infobox won't work with that.

(Also, what happens if there's no Wikipedia page for the predecessor?) Guy Harris (talk) 20:26, 19 January 2018 (UTC)

@Guy Harris: For the first question, it’s a known problem, I’m thinking about right now. If you have any idea, share it. For the second question, you write the name of it and it appears as a red link, so someone can create the article. –Dimsar01 ^Talk ⌚→ 00:38, 20 January 2018 (UTC)

@Dimsar01: "If you have any idea, share it." How about "get rid of the automatic linking", which 1) removes the problem, as you can put whatever you want displayed into those fields and 2) means that all the existing uses of {{Infobox OS version}} other than the iOS N ones don't have to be changed the way the iOS N ones did. There's no need to exactly duplicate the behavior of the {{Infobox song contest}} in every detail; for a song contest series, the predecessor and successor are pretty straightforward (year N is preceded by year N-1 and followed by year N+1), but for OSes, the first release of an OS might be preceded by multiple OSes (as is the case for macOS), and the last release of a discontinued OS might even be followed by multiple OSes. Guy Harris (talk) 01:00, 20 January 2018 (UTC)

Hi. :)

There are more problems than those mentioned here. What if the successor or predecessor is introduced in the same page and we need to section-link to it? What if we need to supply a source?

"If you have any idea, share it" isn't the correct attitude either. In case of all largely used templates, the burden of having the better idea is on the contributor, and must be proven via sandboxing in advance of the main edit. What problem was Dimsar01 trying to solve here with this particular edit? Nothing. I don't see anything getting significantly better.

Best regards,
Codename Lisa (talk) 07:44, 20 January 2018 (UTC)

I've undone this whole fiasco. Dimsar01, it's pretty clear that you either didn't notice or worse, didn't care that your changes created a significant problem -- many of the pages, like Android Ice Cream Sandwich and Mac OS X Snow Leopard had their Infobox widths increase by well over 100px! This is absolutely not acceptable. The width of the Infobox should be very consistent from one page to the next (within a specific topic, at least) to facilitate visual coherence, as well as to keep similar informational elements in the same place. 275-325px wide Infoboxes are fine, but 450px is certainly not -- we want these to be somewhat narrow in order to maximize the amount of space for the main article itself. Also, the people maintaining the Microsoft Windows versions articles have decided that they want the release year of the precedessor/successor to be visible as well.... narrowing the allowed text to only permit a single wikilinked article takes this capability away.

The template editor comes with a way of previewing changes in articles before applying it. The onus is on you to test your changes. Also, separately, I agree with Guy Harris in that there is no necessity for this template to perfectly match what happens in Infoboxes on other subjects. Infoboxes must conform to the content they aim to describe, not the other way around. — Warren. ‘ talk , 02:39, 20 January 2018 (UTC)

Root file system field: is it a worthy option?

Different operating systems have different root file systems, both the default and available options. Like for Linux the default is none (different distros different default), while those available include (but not limited to):

• Btrfs

• ext/2/3/4

• JFS

• XFS

• ZFS (with third-party kernel module)

. While for FreeBSD the options include UFS and ZFS and the default is UFS. I'm debating whether this is a worthy option, largely because the infobox is a little crowded already and while it is important to me, it may not be to others, so, I thought I'd start a discussion here. Thank you for your no doubt helpful inputs, in advance. Fuse809 (contribs · email · talk · uploads) 06:20, 17 November 2018 (UTC)

screenshot_size parameter

The screenshot_size parameter reads, "A width for the screenshot, including the 'px'; the default is '290px'. For example: '200px'" seems outdated. First, there's no ability to indicate if the screenshot is vertical or horizontal (portrait). I assume that the default is assumed to be horizontal as most desktop applications would be laid-out like that, but with more mobile OSes (like Android Pie) that needs to be adjusted. Can we add the ability to use the upright parameter the way that images are permitted to be used.

Second, a default of 290 pixels is a bit too large. The default for thumbnails in most skins is 240 pixels. We should really only be suggesting that the image be enlarged to 200 pixels if it is smaller than that, and most screen shots are not going to be smaller than 200 pixels. This could be a MOS:ACCESS issue. Some visually impaired readers set their font and thumbnail sizes larger and setting a fixed pixel size will result in images that are smaller than expected. Walter Görlitz (talk) 22:52, 27 August 2019 (UTC)

OS family

The documentation for this infobox describes the family= parameter as follows:

The name of the family of operating systems that this version is a part of. Examples include 'Microsoft Windows', 'Unix-like' and 'Mac OS'; 'Linux' and 'Mac OS X' are not OS families

Unix-like

In a discussion at Talk:Debian#Debian being a Unix-like operating system it was pointed out that Arch Linux, Deepin, Fedora, Gentoo and Linux Mint (as examples) all list the OS Family as Linux and that KDE neon lists it as Linux (Unix-like). I'm raising the question of how this contradiction should be resolved for discussion here. Wtmitchell (talk) (earlier Boracay Bill) 11:07, 13 September 2019 (UTC)

Prompted by the closing clarification in the quote above, I looked at the Linux and OS X Yosemite articles. Following this, it seems to me that the addition of a footnotes= parameter and an associated Footnotes section to this infobox might be useful, along with a documentation suggestion that clarifications to or additional details regarding the OS family classification might be provided there and/or in <ref>'d footnotes in the article proper. Wtmitchell (talk) (earlier Boracay Bill) 11:36, 13 September 2019 (UTC)

It's weird, I suppose the intent is to have extremely broad families. (Nevermind that Mac OS X is BSD-based.) Is it useful for "Unix-like" to be a superset that includes, e.g. SunOS, AIX, Linux, BSD, etc.? If we want "Linux" to be a family in its own right, then we should decide how to classify one or more non-Linux Unix-like families. Pragmatically, I say just follow the existing docs and fix the non-conforming infoboxes. Elizium23 (talk) 11:38, 13 September 2019 (UTC)

"Unix-like" is not encouraged by the project. The goal is to have an easily identifiable OS in the infobox. Walter Görlitz (talk) 14:36, 13 September 2019 (UTC)

"Unix-like" is very general and vague, I think one of the following cases is the correct one:

1. "Unix-like (Linux)" and "Unix-like (BSD)"
2. "Linux (Unix-like)" and "BSD (Unix-like)"

"Is it useful for "Unix-like" to be a superset that includes, e.g. SunOS, AIX, Linux, BSD, etc.?"

"SunOS, AIX" and Solaris with similar OSes all are the real UNIX and should not be called "Unix-like", currently there are only 2 families of Unix-like OSes:

1. Linux distros
2. BSD OSes (never call them BSD distros)

so either of my proposed options should be selected. Editor-1 (talk) 16:24, 13 September 2019 (UTC)

"Real UNIX" as in "derived from AT&T code" or "real UNIX" as in "passed the Single UNIX Specification test suite and are thus eligible to have the UNIX registered trademark used for them" (either is possible without the other, and both are also possible simultaneously)? Guy Harris (talk) 19:04, 13 September 2019 (UTC)

The Unix-like article includes "genetic Unix" systems under this umbrella. It also mentions Windows Subsystem for Linux. Minix is still under active development. Then there are a plethora of "Unix-like" mobile OSes that that article does not mention: Android, KaiOS, iOS, ChromeOS. I would say there are far more than the two "families" you name. So what's a "family"? The Linux article says that Linux distros are in the Linux family. So we may need a more elaborate taxonomy. And that is a discussion for Wikipedia talk:WikiProject Linux, et. al., not a minor template talk page. Elizium23 (talk) 19:12, 13 September 2019 (UTC)

@Guy Harris:

• ("Real UNIX" as in "derived from AT&T code"): NO
• ("real UNIX" as in "passed the Single UNIX Specification test suite and are thus eligible to have the UNIX registered trademark used for them"): YES, same as macOS.

@Elizium23: (there are a plethora of "Unix-like" mobile OSes that that article does not mention: Android, KaiOS, iOS, ChromeOS. I would say there are far more than the two "families" you name)

Android and ChromeOS are part of the Linux family, iOS same as macOS is UNIX. KaiOS: "KaiOS is a mobile operating system based on Linux" so it is also part of the Linux family.Editor-1 (talk) 07:58, 15 September 2019 (UTC)

"Android and ChromeOS are part of the Linux family, iOS same as macOS is UNIX." Except that iOS, unlike macOS, has not passed the SUS test suite and is thus not eligible to have the UNIX registered trademark used for it, so, if the "Unix" family includes all SUS-passing OSes, it includes macOS but not iOS.

And, if the UNIX family, doesn't include all OSes derived from AT&T code, it wouldn't include Version 6 Unix or Version 7 Unix, which would seem a bit odd.... Guy Harris (talk) 08:20, 15 September 2019 (UTC)

("if the UNIX family, doesn't include all OSes derived from AT&T code, it wouldn't include Version 6 Unix or Version 7 Unix, which would seem a bit odd.")

No that was not my mean, I thought that you are pointing to BSD-based OSes like FreeBSD and OpenBSD which have some "AT&T code", if we consider BSD as Unix, we should not consider its forks as Unix, they are just "BSD" to only separate them with Linux.Editor-1 (talk) 12:09, 15 September 2019 (UTC)

I was pointing to the statement

"SunOS, AIX" and Solaris with similar OSes all are the real UNIX and should not be called "Unix-like"

and asking which of the definitions of "real UNIX" was being used. If it's "passed the SUS validation suite", then some OSes that would probably be thought of as UNIXes, such as V6 and V7, wouldn't qualify.

If all OSes sufficiently compatible with the SUS, even if they haven't passed the validation suite, could be considered "UNIX-like", would all of the currently-available UNIX-like OSes all qualify either as "Linux", "BSD", or "UNIX"? If "Linux" means "uses the Linux kernel", Android would qualify as Linux; if Darwin is sufficiently BSD-flavored, {i,tv,watch}OS would qualify as BSD. The Big Three remaining traditional "commercial UNIX"es - Solaris, AIX, HP-UX - would qualify as "UNIX", as would the on-death-watch Tru64 UNIX. The now-dead IRIX, however, wouldn't, unless it got trademark certification and I just didn't look in the right place on The Open Group's Web site.

As for the other definition, "derived from AT&T code", that includes, I think, all of the traditional commercial UNIXes, as well as all of the BSD-flavored UNIXes, with all of them having replaced some amount of the AT&T code with their own code; I wasn't specifically pointing at the BSDs. That would leave Linux, and possibly some other historical OSes, as the only non-UNIX UNIX-like OSes.

And if BSD - all the way up to 4.4-Lite - is "UNIX", why would the OSes derived from 4.4-Lite not be UNIX? Guy Harris (talk) 17:49, 15 September 2019 (UTC)

---

I'm neither an academic nor an expert. Long ago, I was a sometime schlub programmer who sometimes found himself in the middle of an OS kernel but more often wrote or maintained applications. I was heavily involved in the Debian project from its inception in 1993 to late 1996 and, through the mists of time, I recall being gratified then as attention came to be paid to POSIX (mostly posix.2, as the project was focused on putting together a coherent Linux distribution rather than on the OS itself). Anyhow, writing as a former schlub programmer, I remark: (1) perhaps POSIX ought to come into this somewhere re unix-like and (2) perhaps a line of distinction ought to be clearly drawn or taxonomic categorization made between OS kernals and OS distributions, and between their respective families. Wtmitchell (talk) (earlier Boracay Bill) 12:19, 15 September 2019 (UTC)

And then there is Unix System Services in IBM's z/OS, which has been passing UNIX and POSIX validation for decades but does not have a Unix-like kernel, but rather is layered on top of MVS. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:05, 15 September 2019 (UTC)

Is Unix System Services an OS or a compatibility layer in an OS?

(And, speaking of MVS and z/OS, to which OS family or families do they belong? "OS/360 and successors"? "MVS", the subfamily of that family that has separate address spaces for processesjob steps or whatever they're called? Should MVS and z/OS be put into both of those families?) Guy Harris (talk) 21:08, 15 September 2019 (UTC)

This infobox seems to be for OSes, not just kernels. Linux is a bit weird in that 1) there are several different low-level userlands, providing services generally considered to be OS services, atop the same kernel (GNU libc etc. and Bionic libc, to name two of the most significant) and 2) the name "Linux" is, for better or worse, used to refer to both the kernel and to OSes built atop that kernel.

So Android is part of the Linux family if that family is defined as "everything using the Linux kernel" and isn't part of the Linux family if that family is defined as, for example, "everything using the Linux kernel and GNU libc". Guy Harris (talk) 21:14, 15 September 2019 (UTC)

I view "UNIX-like" as 1) it supports an API that's sufficiently compatible with some AT&T variant of UNIX and 2) if it has a command line, it supports a shell and command set that's sufficiently compatible with those of some AT&T variant of UNIX. ("AT&T variant" includes Research UNIX as well as System RomanNumeral). At this point, AT&T's out of the UNIX business, and the Single UNIX Specification is the closest thing to a spec for "compatible with some AT&T variant of UNIX", so that's where POSIX would come in. However, not everything worthy of being considered "UNIX-like" has passed the Single UNIX Specification test suite, so not all "UNIX-like" systems are "UNIX(R)" systems.

(I seem to remember, a long time ago, an era in which "UNIX-like" referred to OSes that were similar to AT&T-style UNIX but not necessarily compatible, with "UNIX-compatible" being used for those that were compatible, but there aren't many left in the former category, so that usage has gone by the wayside.) Guy Harris (talk) 21:22, 15 September 2019 (UTC)

It seems to me that defining "Unix-like" by consensus will be akin to nailing Jell-O to the wall. It's a slippery designation and everyone has our own opinions about what fits, what's marginal, and what's a definite outlyer. I think at this point we should decide whether we are happy with "Unix-like" being a huge, kitchen-sink umbrella term for everything, or if we should slice up "family" and make it more granular. I like the concept of "Unix-compatible". Being an old-school geek, I remember when there was "Unix" and there was "BSD" and never the twain did meet. Frankly, if we split up the "Unix-like" family, I feel that three divisions should matter. "Linux" should be in a class of its own: it's a broad family already, and the implementations of the Linux kernel have transcended traditional uses of Unix in a way that has redefined the genre. If a "Linux" family is excluded from "Unix" or "Unix-like" then we can divide "everything that's left" at least two ways. Which two? "BSD-derived" is a good start, and it'd cover OS X, iOS, and the real BSDs, past and present. I am curious where such things as BeOS, Haiku, Plan 9 from Bell Labs, and Inferno would fall here; they're experimental curiosities, but deserving of classification nonetheless. (FYI: only one of those four articles claims an "OS family" field -- Haiku says it's in the BeOS family! Elizium23 (talk) 22:44, 15 September 2019 (UTC)

Being an old-school geek, I remember when there was just "UNIX", the manual for which was called "UNIX Programmer's Manual, Sixth Edition". I don't remember there being "Unix" and "BSD", although I do remember "System V" and "BSD"; however, that was somewhat misleading, as there were commercial UNIXes that had a mix of BSD-flavored and SV-flavored APIs in the cases where the APIs differed. The name "UNIX", at the time, could only apply to the UNIXes released by AT&T as System V; you couldn't use the trademark unless the only source code changes made were done to port to your hardware.

System V Release 4 pulled a lot of BSD and SunOS APIs and code into System V, which caused UNIX War II between UNIX International (the AT&T/Sun camp) and the Open Software Foundation (the DEC/IBM/HP/Apollo/Bull/Nixdorf/Siemens/etc. camp). However, by that point, by and large the APIs where there was a significant SV-vs-BSD difference were either deprecated in favor of newer APIs (such as signal(), deprecated in favor of sigaction() and company), with the newer APIs being mostly or completely compatible between all of the OSes, or went in an SV-ish direction with extensions (the POSIX terminal interface, with some added flags and control characters to support BSDisms), and they all supported BSD-style socket APIs. Eventually the war pretty much fizzled out, especially after AT&T sold the UNIX code off to Novell (with a brief Univel period), OSF merged with UNIX International and then merged with X/Open to make The Open Group, in whose hands the UNIX trademark ended up. The SUS came out of all that, and the trademark was disconnected from the code, with anything passing the SUS validation suite being allowed to be called "UNIX(R)".

I'm not sure there are many, if any, areas where a Linux kernel-based OS is used where no other UN*X was used. The Linux kernel is, however, the only one I know of used in all those areas. It's probably worthy of a family of its own; the main question I'd ask is whether "this OS has a Linux kernel" suffices or whether some amount of userland in common (e.g., GNU libc) is also required. My inclination is not to limit the userland, given that, for example, there are at least four significant C standard libraries used with Linux - GNU libc, uClibc, musl, and Bionic - only one of which is part of the GNU project and only two of which are licensed under the LGPL.

I'd have separate "BSD" and "Darwin" families, putting the *BSDs and derivatives into the "BSD" family and {watch,tv,i,iPad,mac}OS into the "Darwin" family - there's a lot more to the Darwin-based OSes than just the BSD part (Mach messaging, for example, is used all over those OSes, including the implementation of a number of core UNIX APIs such as host name resolution, user-database lookup, etc.).

BeOS didn't attempt to be completely UNIX compatible, as far as I know, so it doesn't belong in any UNIX family (another case of "UNIX-like" in the old sense rather than the new "UNIX-compatible" sense). I'd put it and Haiku into a BeOS family.

What remains are largely based, to varying degrees, on AT&T code, with some amount of BSD and other code added. We could, I guess, have a "UNIX" family for all of them; a lot of code written for V7 would work on all of them (as well as all the Linux, BSD, and Darwin OSes), but you couldn't do terminal ioctls, and writing for V7 wouldn't let it run on V6.

The result of that would have no way of indicating that the OS is "UNIX-compatible". The only formal definition of "UNIX-compatible" is the SUS; note that at least two Linux distributions, and one Darwin-based OS, have passed the SUS test suite, and no form of Research UNIX, and none of AT&T's System Roman Numeral releases, have passed the SUS test suite, so you could have some OSes for which AT&T or some part thereof used the UNIX trademark that wouldn't be "UNIX-compatible" in the SUS sense. Guy Harris (talk) 17:32, 16 September 2019 (UTC)

Small in infobox

I've noticed that the infobox is pulling in data from elsewhere and it's small, which violates MOS:SMALLFONT. Can we "un-small" it please? Walter Görlitz (talk) 22:49, 22 January 2020 (UTC)

OS family redux

Somebody claims, on Talk:Ubuntu, that, at least for the Ubuntu page, the consensus is that the family field should have "Linux".

This disagrees with the documentation for this template.

Either the template's documentation should be changed to allow Linux (and recommend it for Linux distributions; there's no reason for Ubuntu to differ from, for example, Fedora), perhaps allowing or specifying "(Unix-like)" after it, or the discussion for Ubuntu should be reopened. Guy Harris (talk) 00:48, 1 January 2020 (UTC)

Yeah! We should fix this template's documentation. Walter Görlitz (talk) 06:16, 1 January 2020 (UTC)

I don't see Linux as a completely different OS than FreeBSD or OpenBSD, they have many commons and their structures are very similar, so Linux is not an unique OS family. -- Editor-1 (talk) 15:40, 1 January 2020 (UTC)

But, given that 1) like most other Unix-like systems, it has its own peculiar APIs and other quirks on top of the common UN*X base (if you don't do at least one thing differently from all other Unix-like systems, you're not really a Unix-like system :-)) and 2) there are multiple distribution that share most of those quirks, is it a subfamily of the family of Unix-like systems, with members of the family worthy of being noted as such? Guy Harris (talk) 18:55, 1 January 2020 (UTC)

We don't need sub-families, no. If we want to create navigation templates to make the distinction, that's fine, but the infobox should summarize the content of the article, not create debates. Walter Görlitz (talk) 20:46, 1 January 2020 (UTC)

What do you mean by "need sub-families"? I'm indicating that Linux distributions 1) could be considered as constituting a family of OSes and 2) that family is a subfamily of the family of Unix-like systems, so that "Linux", as a shorthand for "Linux distribution", could be considered an OS family, even if it's not a unique family. Guy Harris (talk) 23:06, 1 January 2020 (UTC)

Have you never read MOS:INDENTGAP? When responding, do not leave a blank line between the comment that preceded you. It causes several problems with screen readers.

There are Debian-based distros, Red Hat-based, and several others. List of Linux distributions seems to break them down by package manager used. That's what I mean by sub-families as they're all Linux. Walter Görlitz (talk) 23:22, 1 January 2020 (UTC)

I wasn't saying we needed sub-families of Linux. I was saying that Linux could be considered a subfamily of the family of Unix-like systems, if a justification for considering it a family is desired. Guy Harris (talk) 23:56, 1 January 2020 (UTC)

I see. I wasn't trying to make the case for it, but the distinctions, if any are needed, could be made in nav templates such as, {{Linux distributions}}, rather than the infobox. Walter Görlitz (talk) 00:36, 2 January 2020 (UTC)

Again, "Linux (UNIX-like)" is not needed. It's part of the Linux family. While it is like UNIX, it's not, and it's enough to state it's part of the Linux family and if someone wants to dig-in to find the lineage, the can do so by clicking on the link. Not sure if that makes sens for the various BSDs or other families but those families are smaller and UNIX-like may be appropriate for them. Walter Görlitz (talk) 22:58, 22 January 2020 (UTC)

Init-System

Please add a line for "init-system". In the Unix/Linux-World the init system has become a quite relevant descriptor of a distribution. See also Distrowatch. --Liebeskind (talk) 12:07, 23 November 2020 (UTC)

latest_release_date

There seems to be a difference of three days, see https://en.wikipedia.org/wiki/AmigaOS_4 -- Polluks ★ 17:45, 17 January 2021 (UTC)

I did a purge of the page (select "Purge" from the "More" drop-down menu to the left of the search box, at least in the desktop/notebook version of Wikipedia), and it's now saying "5 days ago" rather than "1 day ago". Not sure how that got stuck in the cache. Guy Harris (talk) 22:25, 17 January 2021 (UTC)

I see, thanks! -- Polluks ★ 13:00, 20 January 2021 (UTC)

Special 'hide' value for website parameter

Special 'hide' value for website parameter Hi folks,

Is there a way to highlight the 'hide' parameter in the documentation for the website/"Official Website" parameter? The docs seem to be designed to be used by both the VisualEditor and a documentation web page.

As I completely missed the parameter when reading the docs, I was wondering if there was a way to produce a bolded 'hide' in the documentation, but hopefully remain compatible with both the web page and the VisualEditor.

Thanks! Lent (talk) 00:17, 22 January 2021 (UTC)

Does ''''hide'''' not work with the Visual Editor? If not, that sounds like a bug with the Visual Editor.... Guy Harris (talk) 02:33, 22 January 2021 (UTC)

Incorrect number of days since (zero)

At KDE Plasma 5, I see "Stable release 5.21 (16 February 2021; 0 days ago) [±]", as of Feb 21, instead of "5 days ago". If I render the external data template, I do see "5 days". -- Dandv 10:17, 21 February 2021 (UTC)

To quote my response to "latest_release_date" above:

I did a purge of the page (select "Purge" from the "More" drop-down menu to the left of the search box, at least in the desktop/notebook version of Wikipedia), and it's now saying "5 days ago" rather than "1 day ago". Not sure how that got stuck in the cache.

The same applies here, with "1 day ago" replaced by "0 days ago". Guy Harris (talk) 20:09, 21 February 2021 (UTC)

...although that infobox is Template:Infobox software rather than this one. Guy Harris (talk) 20:10, 21 February 2021 (UTC)

Problem with "Working state" parameter

Hello, there is a Linux distribution called CentOS Linux which is still under maintenance and support for its version 7 until Q2/Q3 of 2024, and its version 8 until 31 December 2021, but it will be discontinued after these versions.

One user (user:Quetstar) changed the value of the parameter from "Current" to "Discontinued" and does not allow anyone to change it, and argued:

The "discontinued" label is appropriate for 3 reasons: CentOS 7 no longer gets point releases, CentOS 8 will die at the end of the year, There will not be a CentOS 9. That approach is similar to the one taken for Scientific Linux, which is discontinued, but still supported until RHEL 7 dies in 2024.

and when I suggested the user to use "Discontinued (under maintenance)" he/she argued:

Using the Discontinued label, without any descriptors, has been Wikipedia policy since forever. So i think it should stay as is until the wider Wikipedia community decides otherwise, but i'm open to any other ideas.

full debate: Talk:CentOS#Working State

The Scientific Linux article that user:Quetstar referred was edited on 24 February 2020 by user:Psypherium and its working state was changed from "Current" to "Discontinued": Special:Diff/942439879

now me and another user (user:OmenosDev) which are opposed to user:Quetstar and also user:Psypherium, need to know that are their actions and argumentations correct and per "Wikipedia policy" or not?

Thank you very much--FMM-1992 (talk) 18:37, 9 June 2021 (UTC)

Many news sources consider "no longer receiving feature updates, but still temporarily maintained to add security patches" to mean "discontinued".

"Sad News! Scientific Linux is Being Discontinued". April 24, 2019. Retrieved June 10, 2021."Scientific Linux Distro is Being Discontinued; The Fermi National Accelerator Laboratory and CERN Will Move To CentOS". April 24, 2019. Retrieved June 10, 2021."Scientific Linux Will Be Discontinued After 14 Years as Fermilab Moves to CentOS". April 24, 2019. Retrieved June 10, 2021.

I would be inclined to agree with what seems to be the consensus of the community, the semantics seem to be correct. Simply maintaining a distro does not entitle it to be considered "current".

I would disagree with "Quetstar" in their description of "The working state part of the infobox is about the development status of the distro, not support." In my interpretation, the word "current" has an implied sentence alongside it, the full reading being "currently receiving feature updates". "Maintained" means that it is only receiving point releases for packages and libraries, not full number releases. "Maintained" would therefore mean that it is only receiving security patches, not feature patches. By this reading, "Maintained (But no longer receiving feature updates, only security updates.)" seems to more closely semantically align with "Discontinued".

(Edit: It's not so much that I "Disagree" with what Quetstar said, but I do not believe that they gave enough information to allow you to arrive at an adequate understanding of the way that the terminology is used in this specific instance.)

"Discontinued (under maintenance)" is not a valid value for the "working state" parameter. I do not believe that adding it is necessary. The current values of 'Current', 'Discontinued', or 'No longer supported' are sufficient for the vast majority of distributions, and adding another variable for a very small minority of distros is adding unnecessary complication.

The main question here would appear to be "does adding this parameter variable have a positive informational benefit to the encyclopedia", and I would argue that it doesn't, because it does not clearly explain the situation, which is only adequately explained through the use of total sentences, not a three word infobox parameter variable. The information about these distributions being "discontinued but still temporarily maintained" should be given in the lead of the articles. This is sufficient.

My understanding is that "Wikipedia policy" is to give the same information that is provided in the citations, but written in a more encyclopedic way to have a more positive informational benefit (and to modify the presentation/wording of the information in order for it to be able to be licensed under CC). The instances where the information is more adequately explained in another way, are instances where the wording should be changed. But for infobox variables that are preexisting, and conform to the general consensus of the most informational semantics, the words should be given in the same manner as they are given by the citations.

My first thought at compromise would be to rename the "Discontinued" value, to "Unmaintained", and then to switch these distros back to "Current", but I believe that this would be a step backwards, as the common usage of this word is to refer to a distro which is actively receiving feature updates, and not merely maintained with security patches and similar things.

I guess I would give the idea of adding a "Discontinued (Under Maintenance)" parameter a "weak support", but with the above given caveats to that support.

I can definitely see that you strongly believe in improving Wikipedia to provide a greater informational benefit to society.

I am just now reading the "Working State" discussion on the talk page, and I would tend to agree with your suggestion of "CentOS Stream" being given its own article. I would agree with taking that to AfC.

I'm not awake enough to give this the adequate amount of thought at the moment, I'll be going to sleep now and I might be of a completely different opinion when I wake.

I am very pleased with your attempts to improve the informational content of wikipedia pages in relation to FOSS projects, just because we have a differing semantic interpretation of these infobox parameters does not detract from my admiration of your efforts in any way.

(edit) - Via Fermilab's statement: "future development has permanently ended" Their semantic interpretation of the word "Developed" follows the general (software development) consensus, although I would be inclined to suggest that it does not adequately explain the situation to those who are not familiar with the general (software development) interpretation of the word "Developed". The Dictionary definitions of the word "Developed" are not aligned with the developer interpretation of the word. This is why a detailed description of the meaning of "Maintained" in an operating system software development context should be adequately given in the lead of articles where it is necessary. I do not believe that this is currently the case in the CentOS or Scientific Linux articles.

Via Software maintenance: "Software maintenance in software engineering is the modification of a software product after delivery to correct faults, to improve performance or other attributes." But not to add features. I believe this is the distinction, in relation to the working state of an operating system, between "Developed"/"Current", and "Maintained"/"Discontinued". "Software development" in regards to modification of the code, happens in both "maintained" and "developed" operating systems, but this second use of the word "developed" is specifically referring to the modification (and addition) of code to add features that did not previously exist, as opposed to merely correcting faults and improving performance and other attributes.

I agree, this is very confusing.

Psypherium^{talk page} 00:35, 10 June 2021 (UTC)

First things first, thank you for this response @Psypherium. And wow, kudos for such a detailed write up, I wasn't expecting that.

In my mind, I would use the terms Developed, Maintenance (not "maintained"), and Discontinued to describe the Working State of operating systems. To me those are the three primary states that an operating system will exist in. I intentionally opt for Maintenance rather than Maintained for two reasons:

• The latter word is overloaded (case: your P1/P2 analysis); and
• The term "Maintenance" has an actual meaning within the software community as a descriptor of project/product lifecycle and one that's easier to understand from the layman perspective. E.g. "I sent in my car for maintenance" implies that it's getting fixed, not adding new features.

---

Developed: New features and functionality (regardless of release type, i.e. point, rolling, etc)

Maintenance: No new features and functionality, strictly bug fix and security updates (but still releasing updates/"maintained" by someone).

Discontinued: All forms of development of the distribution have ceased.

---

I'm not a fan of the term "Current" because it is ambiguous. Is the project current (in line) with something else? Are they "currently" releasing updates of any kind? Does "Current" == "latest"? To me it raises more questions than answers. I fully admit I'm looking at this from the technical perspective.

This brings me to another sub-topic: Many distributions have multiple sub-projects or versions they are working on. Is the Working State only to refer to the most recent version?

OmenosDev (talk) 13:16, 10 June 2021 (UTC)

The working state parameter refers to the status of the entire distribution, not just the latest version. Furthermore, it is not necessary for the infobox to talk about the whole project, but just the stable release of it. For example, the infobox in the OpenSUSE article only describes Leap (the aforementioned stable release), despite the facts that it also produces Tumbleweed, which is a rolling release. Quetstar (talk) 17:59, 10 June 2021 (UTC)

(Part 2) This is keeping me awake.

"Maintaining software which is no longer being developed" is technically a form of "software development". It exists in a state of simultaneously being "software that is being developed" and "Software that is no longer being developed".

Software developers have accidentally given birth to Schrödinger's software development. The English language would like like to take this opportunity to severely admonish them all for their odious and wicked abominations that they have cruelly inflicted upon the English language.

I'm joking, and this is all very funny, but I'm simultaneously a little upset. I'm ambivalent about this.

Psypherium^{talk page} 02:55, 10 June 2021 (UTC)

I would strongly note that the headlines about "to be discontinued" are in future tense and do not indicate that the distro is discontinued, but indeed they all point out that support will continue on the current versions. DistroWatch indicates Scientific Linux as Active in green, so I do not think it is fair to say that media gazing in a crystal ball to say "will be discontinued someday" is the same as stamping "Discontinued" on a distro that is actively receiving bug-fixes and security updates. Elizium23 (talk) 13:35, 10 June 2021 (UTC)

Via Fermilab's statement: "Future development has permanently ended" - This is synonymous with "Feature development has been discontinued" - Given the current choice of parameters, these projects more closely semantically align with the "discontinued" value, rather than the "current" one.

I think that something we can all agree with, is that the current values for this parameter are inadequate. Neither "Current" nor "Discontinued" are appropriate words to use in the case of distros like these ones. "Discontinued" is synonymous with "No longer supported". Having both values is the source of this contention. In the context of this parameter, the "Discontinued" value is more closely synonymous with "Maintenance" than to the other values, but the word "Maintenance" already exists, and this word should be used instead. "Discontinued" and "Maintenance" are not synonymous anywhere outside of this parameter value.

I am in favor of renaming the parameter values with something along the lines of what OmenosDev has suggested. Though I think that I would prefer "active" or "fully active" rather than "developed". Maintenance is technically a form of "software development". Also, "fully active" is more of a "state" than "developed".

I would also suggest that the "maintenance" value should wikilink to Software maintenance.

Psypherium^{talk page} 17:30, 10 June 2021 (UTC)

As for me, i would keep the working state parameter as is until there is wide consensus in favour of changing it, because that would impact not just Linux distros, but other operating systems like Windows and macOS. Quetstar (talk) 17:49, 10 June 2021 (UTC)

@Psypherium: I was going back and forth on what the first item could be. Initially had "Developed" or "Developing", but "Developing" could be ambiguous as to the maturity of a project. I thought about "Active" and "Active Development" (tossing out the latter if desired to stay with a one-word scheme), though I can't remember why I discarded them. At the moment I can't see any glaring issues with them. But I agree that "Developed" is also not the most ideal terminology.

@Quetstar: Is there anything about the suggestions described above that would negatively impact or inaccurately describe the non-Linux operating systems? My focus in my suggestions above are not specific to the Linux ecosystem, but intended for operating systems as a whole. If members of the other communities would like to participate in this discussion, then that'd be great. I don't know the best way to ask editors of those communities to join here, though.

The main reason for this discussion is that "Current" and "Discontinued" do not fully cover the major lifecycle events of an operating system, nor unambiguously describe them. At the very least enabling the use of an additional option would not impact others and provide more accurate reporting.

OmenosDev (talk) 22:24, 10 June 2021 (UTC)

@OmenosDev: the WP:RFC process should do the trick. As for the non-Linux OSes, the community has a different way on how to describe their working state, especially on the version pages of each OS, particularly Windows 10, so that would change the way how to describe their support period. Quetstar (talk) 23:09, 10 June 2021 (UTC)

Presumably "the community have" was intended to be "the communities (plural) have", i.e. this field may be used differently for different OS families - not surprising, given that different OSes and OS families may well have different lifecycles. Guy Harris (talk) 23:25, 10 June 2021 (UTC)

@Guy Harris i was meaning the community has Quetstar (talk) 23:43, 10 June 2021 (UTC)

To which community are you referring? The Wikipedia community as a whole?

If so, "Current" seems to be popular for living non-Linux OSes, with "Discontinued" being popular but not universal for dead OSes:

macOS has "Current" for working_state, and the individual major versions don't have working_state. The same applies to iOS. The individual versions use support_status (and, given that Apple don't seem to have an officially-stated support policy, that ends up being a source of edit wars, but I digress). The classic Mac OS has "Historic, not supported" for working_state; individual versions that have their own pages, other than System 6, also have that for working_state; they all also have support_status, also set to "Historic, not supported".

Microsoft Windows doesn't have working_state. Pages for versions of the "classic Microsoft Windows" ("Windows OT", if you will) don't have it, either, but they do have support_status, cf. Windows 3.1 and Windows 95. Windows NT has "Current" for working_state; Windows NT 3.1 through Windows NT 4.0 have support_status but not working_state, Windows 2000 has "No longer supported" for working_state and also has support_status, all the subsequent client versions from Windows XP through Windows 10 have support_status but not working_state. Windows Server has neither working_state nor support_status; the versions have both, set either to "Current" or, for Windows Server 2003, "No longer supported", except for Windows Server 2008, which lacks working_state.

FreeBSD, NetBSD, OpenBSD, and DragonFly BSD have working_state set to "Current", as do Oracle Solaris, AIX, HP-UX, z/OS, VSE, OpenVMS, RISC OS, IBM i, BS2000, and possibly others. "Discontinued" seems to be used for most dead OSes. Guy Harris (talk) 01:25, 11 June 2021 (UTC)

As a distribution maintainer, I endorse this viewpoint. Many operating systems have multiple major versions, with the latest ones getting new features, and the older ones focusing on only bug fixes to avoid introducing regressions. These states exist simultaneously in an active project, and the only way to describe that accurately is to break out the state of each major version. As it relates to the overall operating system, if any version is still being maintained to any extent, the operating system is "current" or "active". "Discontinued" should only be used for completely inactive and unmaintained operating systems. Carlwgeorge (talk) 04:17, 11 June 2021 (UTC)

Unable to distinguish Mac OS and macOS, leading to incorrect automatically included information

On Classic Mac OS, I had to change the infobox to the retronym "Classic Mac OS" to get it to stop claiming that Apple had released a new preview a few days ago, because it was unable to distinguish Mac OS from macOS. This works as a quick fix, but it's far from ideal to have to include incorrect information just to get the infobox to stop misbehaving. Keiyakins (talk) 16:46, 29 July 2022 (UTC)