Editing 1636: XKCD Stack
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
| Latest revision | Your text | ||
| Line 58: | Line 58: | ||
*Third, the 32-bit or 48-bit version: The {{w|Intel 80386}} processor used an architecture known as {{w|IA-32}}, which implies the {{w|Address bus|address bus}} is 32-bit wide and thus able to handle up to 4{{w|Gibibyte|GiB}} of {{w|Random-access memory|RAM}} memory. This was plenty for the early 1990s, when a typical home PC would have about 8MiB (this is 512 times less than 4GiB). However, about 10 years after that, a typical home PC could well use more than 4GiB of RAM, so several {{w|64-bit computing|64-bit architectures}} were created. These architectures are not compatible (32-bit software may run on 64-bit hardware of the same family, but software compiled as 64-bit doesn't work on a 32-bit system), so programs (including the Java Runtime Environment, or JRE) often have 32-bit and 64-bit versions to allow the most appropriate version to be installed. Furthermore, the JRE is heavily used by many web browsers, and for this to work the JRE and browser need to be the same "number of bits". This means that most people have installed both versions of the JRE to be able to use it with both 32-bit and 64-bit browsers. There's no 48-bit architecture (though some 64-bit processors including the {{w|x86-64|most common ones}} don't actually <b>use</b> all 64 bits everywhere, ignoring some bits so actual virtual or physical memory is smaller (in the case of the most common ones, 48bits virtual and 40bits physical), they simulate a full 64-bit environment to allow adding more bits later, so there are no specific 48-bit applications). | *Third, the 32-bit or 48-bit version: The {{w|Intel 80386}} processor used an architecture known as {{w|IA-32}}, which implies the {{w|Address bus|address bus}} is 32-bit wide and thus able to handle up to 4{{w|Gibibyte|GiB}} of {{w|Random-access memory|RAM}} memory. This was plenty for the early 1990s, when a typical home PC would have about 8MiB (this is 512 times less than 4GiB). However, about 10 years after that, a typical home PC could well use more than 4GiB of RAM, so several {{w|64-bit computing|64-bit architectures}} were created. These architectures are not compatible (32-bit software may run on 64-bit hardware of the same family, but software compiled as 64-bit doesn't work on a 32-bit system), so programs (including the Java Runtime Environment, or JRE) often have 32-bit and 64-bit versions to allow the most appropriate version to be installed. Furthermore, the JRE is heavily used by many web browsers, and for this to work the JRE and browser need to be the same "number of bits". This means that most people have installed both versions of the JRE to be able to use it with both 32-bit and 64-bit browsers. There's no 48-bit architecture (though some 64-bit processors including the {{w|x86-64|most common ones}} don't actually <b>use</b> all 64 bits everywhere, ignoring some bits so actual virtual or physical memory is smaller (in the case of the most common ones, 48bits virtual and 40bits physical), they simulate a full 64-bit environment to allow adding more bits later, so there are no specific 48-bit applications). | ||
| − | *Fourth, | + | *Fourth, an application trying to let the user install a new version of the JRE should direct the user to the download page in the [https://java.com/ java.com site], not to the main page which deals with lots of issues with java and is not particularly helpful when trying to update the JRE. It may be a common frustration of users to be directed or redirected to the Java frontpage by accident. |
| − | *Fifth | + | *Fifth, and continuing with the joke of users updating from 7.3.8.1¾ to 6.0.0.1 and not knowing why they should, the new version is said to "run fine but not really change anything". This is the usual behavior for Java updates: they run fine (possibly in opposition to [[1197: All Adobe Updates]], where updating must be done several times and the user is never sure they have installed all the newest updates), but after finished updating the user can't see any difference with the previous behavior, and/or may still be told that an update is required. Considering that 7.3.8.1¾ is bigger number than 6.0.0.1, it can also refer to the fact that the test for upgrading is incorrect and 7.3.8.1¾ is actually newer version or that a downgrade is required for the applet to work properly, because no one fixed it to work with the newer version. It may also refer to the fact installing new Java versions often requires editing environment variables to force the OS to default to the new JRE, which standard users of an application don’t know to do, leading their computer to use the old JRE anyway. |
| − | |||
| − | |||
==Transcript== | ==Transcript== | ||
