Wikipedia:Articles for deletion/RAM Limit

The following discussion is an archived debate of the proposed deletion of the article below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page.

The result was no consensus. –Juliancolton ^Tropical ^Cyclone 04:24, 14 February 2009 (UTC)[reply]

RAM Limit

A non-notable thech-thing; ram problems with 32-bit systems are commonly documented and not worth an independent article. Ironholds (talk) 14:19, 8 February 2009 (UTC)[reply]

Delete. I think a useful article on memory limitations of operating systems could be written, but this isn't it. This isn't even part of it. This is a Windows-centric user guide, and it isn't even accurate. JulesH (talk) 15:47, 8 February 2009 (UTC)[reply]
- Inaccuracy is a cleanup issue. If you know better than what the article states, and have the sources to back your content up, then edit the article. Sitting on the sidelines in an AFD discussion and opining delete just because another editor has written poorly does not achieve the goal of writing the encyclopaedia. AFD is not cleanup. Uncle G (talk) 03:16, 9 February 2009 (UTC)[reply]
Delete. Although the information here is accurate (if somewhat confusing) this title is not widely used to describe it. Perhaps some of this could be salvaged and put in the NTLDR or Windows articles. Pburka (talk) 17:58, 8 February 2009 (UTC)[reply]
- Why? These limits are neither NTLDR-specific nor even Windows-specific. Several of them are fundamental aspects of the relevant processor architecture. And title problems are not deletion issues. You have, as an editor with an account, a rename button. Use it! Uncle G (talk) 03:16, 9 February 2009 (UTC)[reply]
  - They are, in fact, Windows specific, at least as described in this article. The IA32 architecture is not responsible for these limitations -- it's a historic design issue of Windows. NTLDR is responsible for configuring the address space at boot time, so it seemed like a reasonable place for some of the content. My concern about the title is that I'm not sure that this is a stand-alone topic at all. It seems like collection of minor details of the Windows operating system. Pburka (talk) 04:33, 9 February 2009 (UTC)[reply]
    - There are two limits that the article could discuss. The title suggests that it's going to be about why 32-bit systems cannot use a full 4GB RAM, a problem which is entirely due to the architecture and which no OS can bypass (without using Physical Address Extension, which uses 36-bit addressing) because 2³² bits = 4GB and devices other than the RAM must be mapped to this same memory space. However, it's mostly talking about the Windows-specific limit on process virtual memory in 32-bit systems (not the same as RAM). Each process can have a maximum of 3GB of virtual memory in 32-bit Windows, if the process is large address space aware (otherwise 2GB), but this is per-process not per system. I think the author must have confused these two issues. If we want an article talking about the virtual memory limit, the article really should be renamed. -- Mithent (talk) 08:52, 10 February 2009 (UTC)[reply]
Please point to the part of Wikipedia:Deletion policy that states that we delete articles on "commonly documented" subjects. And please point to the part of Wikipedia:Notability that states that "commonly documented" things that garner the sort of in-depth coverage that is exemplified by sources #1, #2, and #3 cited in this very article at the time that it was nominated are not notable. You'll find that you cannot. Neither say any such thing.
This is a very poor show on your part, Ironholds, not the least of which is your repeated biting of a new user on xyr very first article, when that new user even attempted to do things properly from the get-go, citing sources that are not only on-point and in-depth but also in fact support all of the content. Your nominating this article for deletion 92 seconds after its creation, was extreme biting, and your speedy deletion nomination of Windows 32bit RAM Limit after you had befuddled a new user with multiple repeated deletion nominations into blanking the article, was not particularly helpful to a new user. Do not bite the newcomers!
And try to remember that you're here to write. You're not here to template other people into submission with repeated deletion nominations. If you see an incomplete article on a "commonly documented" subject, pull out some of that documentation, and improve the article! It's what you're supposed to be doing. Read the Wikipedia:Editing policy. Also read Wikipedia:Stub and User:Uncle G/Wikipedia triage. Uncle G (talk) 03:16, 9 February 2009 (UTC)[reply]
You can see inside the heads of new users now? I assume that is one of the many mystical powers they give to experienced users. The 'blanking of the page' was not (I think, you obviously seem to know better) in response to the deletion templates. The article RAM Limit has exactly the same content as Windows RAM Limit; either he is creating multiple copies of the same page or (more likely) it was an attempted move, either to change the title or to avoid the deletion tag. The speedy deletion was perfectly valid; he had blanked it for the aforementioned move/copy. Ironholds (talk) 06:20, 9 February 2009 (UTC)[reply]
Keep, rewrite and rename to Computer address space limits. There have been several notable limits on address space in the history of computing, like the 64kB limit, 640kB limit, 1MB limit, 16MB limit, 4GB limit. Some are imposed by architecture - CPU or otherwise, some by BIOS, some by OS. 76.66.196.229 (talk) 07:50, 9 February 2009 (UTC)[reply]
Keep, rewrite Maybe a good future article. --Mr Accountable (talk) 06:28, 12 February 2009 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the article's talk page or in a deletion review). No further edits should be made to this page.