Re: SL 6 etc. on ARM CPU units
On Sat, Dec 08, 2012 at 05:17:06PM -0800, Joseph Areeda wrote: I'm pretty sure there are Debian ports for ARM including RasberryPi. I am more interested in getting the SL userland running on the ARM machines. K.O. Here's an interesting project out of the UK http://www.southampton.ac.uk/~sjc/raspberrypi/ where the guy built a 64 node cluster using Lego for the supports. I'm also sure it was a lot of work like others have mentioned. Perhaps when the upstream providers get the kernel and the drivers going in the Fedora and RedHat branches we'll see SL7 or 8 available for ARM also. Joe On 12/07/2012 11:27 AM, Konstantin Olchanski wrote: Please do not confuse 3 separate issues: 1) Linux userland: this is pretty much universal and will run on any CPU as long as you have a cross-compiler and as long as the autoconf tools do not try too hard to prevent you from cross-compiling the stuff. 2) Linux kernel: is also pretty much universal and assumes very little about the CPU. There *is* some assembly code that needs to be ported when you move between CPUs (say from hypothetical SuperARM to hypothetical HyperARM). I believe current versions of Linux kernel have this support for all existing ARM CPU variations. 3) Linux device drivers: in the PC world devices are standardized around the PCI bus architecture (from the CPU, PCIe looks like PCI, on purpose) and most devices drivers are universal, so if you have a PCI/PCIe based ARM machine with PC-type peripherals (South Bridge, ethernet, video, etc), you are good to go. If you have an ARM machine with strange devices (i.e. the RaspberryPI), you have to wait for the manufacturer to release the specs, then you can write the drivers, then you can run Linux. Rinse, repeat for the next revision of the CPU ASIC (because they moved the registers around or used a slightly different ethernet block). It helps if you have some standardized interfaces, for example on the RaspberryPI you have standard USB, so you can use all supported USB-Wifi adapters right away. 4) boot loader: is different for each type of machine, each type of boot device media. period. (Even on PCs there is no longer any standard standard - some use old-school BIOS booting, others use EFI boot, some need BIOS/ACPI help, some do not). This makes it 4 issues, if you count the first (linux userland) non-issue. K.O. On Fri, Dec 07, 2012 at 01:01:36PM -0600, SLtryer wrote: On 10/23/2012 12:37 PM, Konstantin Olchanski wrote: An ARM platform does not exist. Unlike the PC platform where PC hardware is highly standardized and almost any OS can run on almost any vendor hardware, the ARM platform is more like the early Linux days where instead of 3 video card makers there were 23 of them, all incompatible, all without Linux drivers. If you had the wrong video card, too bad, no soup for you. In the ARM world, there is a zoo of different ARM processors, all incompatible with each other (think as if each Android device had a random CPU - a 16-bit i8086, or a 32-bit i386, or a 64-bit i7 - the variation in capabilities is that high). Then each device contains random i/o chips connected in it's own special way - there is no PCI/PCIe bus where everything is standardized. There are several WiFi chips, several Bluetooth, USB, etc chips. Some have Linux drivers, some do not. As result, there is no generic Linux that will run on every ARM machine. Not to be argumentative, but I always believed that the advantage of *nix* was that it could be ported to numerous platforms, regardless of hardware. You even mention the early Linux days, when there was little or no standardization of PC hardware. Yet, the platform didn't disappear from use simply because there might have been porting issues, most of which were caused more by proprietary secrets and hardware defects than the ever-present fact of diversity of hardware. But one could make the same argument even today: That there are many different CPU platforms, e.g., and that they are not standardized. One example I am thinking of is the Intel v. Amdahl CPU compatibility issue. Even though most of the Linux system will run on either without modification, there are still some unique issues to each of them; from having worked and studied VirtualBox, there are differences in how each manufacturer chose to implement the ring structure that permits virtualization to work as nicely as it does on these platforms. For the most part, they are compatible, but the kernel developers have to be aware of certain implemention issues, including a bug in the Intel CPU platform that requires a VirtualBox workaround (for optimizing the code or something; I forget). And this is in addition to Linux supporting umpteen different processing platforms besides the x86 types. New hardware
Re: SL 6 etc. on ARM CPU units
On Mon, 10 Dec 2012, Konstantin Olchanski wrote: On Sat, Dec 08, 2012 at 05:17:06PM -0800, Joseph Areeda wrote: I'm pretty sure there are Debian ports for ARM including RasberryPi. I am more interested in getting the SL userland running on the ARM machines. There is a RHEL 6 rebuild for arm called RedSleeve. http://www.redsleeve.org . -Connie Sieh K.O. Here's an interesting project out of the UK http://www.southampton.ac.uk/~sjc/raspberrypi/ where the guy built a 64 node cluster using Lego for the supports. I'm also sure it was a lot of work like others have mentioned. Perhaps when the upstream providers get the kernel and the drivers going in the Fedora and RedHat branches we'll see SL7 or 8 available for ARM also. Joe On 12/07/2012 11:27 AM, Konstantin Olchanski wrote: Please do not confuse 3 separate issues: 1) Linux userland: this is pretty much universal and will run on any CPU as long as you have a cross-compiler and as long as the autoconf tools do not try too hard to prevent you from cross-compiling the stuff. 2) Linux kernel: is also pretty much universal and assumes very little about the CPU. There *is* some assembly code that needs to be ported when you move between CPUs (say from hypothetical SuperARM to hypothetical HyperARM). I believe current versions of Linux kernel have this support for all existing ARM CPU variations. 3) Linux device drivers: in the PC world devices are standardized around the PCI bus architecture (from the CPU, PCIe looks like PCI, on purpose) and most devices drivers are universal, so if you have a PCI/PCIe based ARM machine with PC-type peripherals (South Bridge, ethernet, video, etc), you are good to go. If you have an ARM machine with strange devices (i.e. the RaspberryPI), you have to wait for the manufacturer to release the specs, then you can write the drivers, then you can run Linux. Rinse, repeat for the next revision of the CPU ASIC (because they moved the registers around or used a slightly different ethernet block). It helps if you have some standardized interfaces, for example on the RaspberryPI you have standard USB, so you can use all supported USB-Wifi adapters right away. 4) boot loader: is different for each type of machine, each type of boot device media. period. (Even on PCs there is no longer any standard standard - some use old-school BIOS booting, others use EFI boot, some need BIOS/ACPI help, some do not). This makes it 4 issues, if you count the first (linux userland) non-issue. K.O. On Fri, Dec 07, 2012 at 01:01:36PM -0600, SLtryer wrote: On 10/23/2012 12:37 PM, Konstantin Olchanski wrote: An ARM platform does not exist. Unlike the PC platform where PC hardware is highly standardized and almost any OS can run on almost any vendor hardware, the ARM platform is more like the early Linux days where instead of 3 video card makers there were 23 of them, all incompatible, all without Linux drivers. If you had the wrong video card, too bad, no soup for you. In the ARM world, there is a zoo of different ARM processors, all incompatible with each other (think as if each Android device had a random CPU - a 16-bit i8086, or a 32-bit i386, or a 64-bit i7 - the variation in capabilities is that high). Then each device contains random i/o chips connected in it's own special way - there is no PCI/PCIe bus where everything is standardized. There are several WiFi chips, several Bluetooth, USB, etc chips. Some have Linux drivers, some do not. As result, there is no generic Linux that will run on every ARM machine. Not to be argumentative, but I always believed that the advantage of *nix* was that it could be ported to numerous platforms, regardless of hardware. You even mention the early Linux days, when there was little or no standardization of PC hardware. Yet, the platform didn't disappear from use simply because there might have been porting issues, most of which were caused more by proprietary secrets and hardware defects than the ever-present fact of diversity of hardware. But one could make the same argument even today: That there are many different CPU platforms, e.g., and that they are not standardized. One example I am thinking of is the Intel v. Amdahl CPU compatibility issue. Even though most of the Linux system will run on either without modification, there are still some unique issues to each of them; from having worked and studied VirtualBox, there are differences in how each manufacturer chose to implement the ring structure that permits virtualization to work as nicely as it does on these platforms. For the most part, they are compatible, but the kernel developers have to be aware of certain implemention issues, including a bug in the Intel CPU platform that requires a VirtualBox workaround (for optimizing the code or something; I forget). And this is in addition to Linux supporting umpteen different processing platforms besides
Re: SL 6 etc. on ARM CPU units
On Mon, Dec 10, 2012 at 05:54:36PM -0600, Connie Sieh wrote: On Mon, 10 Dec 2012, Konstantin Olchanski wrote: On Sat, Dec 08, 2012 at 05:17:06PM -0800, Joseph Areeda wrote: I'm pretty sure there are Debian ports for ARM including RasberryPi. I am more interested in getting the SL userland running on the ARM machines. There is a RHEL 6 rebuild for arm called RedSleeve. http://www.redsleeve.org . Yes, thanks. One difficulty I expect is with no cross-install capability when I can use a 2nd computer (x86) to cross-install ARM RPMs into an ARM boot media. If you do frequent cross-compilation, you would agree with me that lack of cross-install is so silly. I think the expectation is that I have an ARM machine big enough to run the SL installer. At least the text-mode installation is still there and there is no requirement of a working ARM X11 server on whatever funny ARM machine I happen to have. K.O. -Connie Sieh K.O. Here's an interesting project out of the UK http://www.southampton.ac.uk/~sjc/raspberrypi/ where the guy built a 64 node cluster using Lego for the supports. I'm also sure it was a lot of work like others have mentioned. Perhaps when the upstream providers get the kernel and the drivers going in the Fedora and RedHat branches we'll see SL7 or 8 available for ARM also. Joe On 12/07/2012 11:27 AM, Konstantin Olchanski wrote: Please do not confuse 3 separate issues: 1) Linux userland: this is pretty much universal and will run on any CPU as long as you have a cross-compiler and as long as the autoconf tools do not try too hard to prevent you from cross-compiling the stuff. 2) Linux kernel: is also pretty much universal and assumes very little about the CPU. There *is* some assembly code that needs to be ported when you move between CPUs (say from hypothetical SuperARM to hypothetical HyperARM). I believe current versions of Linux kernel have this support for all existing ARM CPU variations. 3) Linux device drivers: in the PC world devices are standardized around the PCI bus architecture (from the CPU, PCIe looks like PCI, on purpose) and most devices drivers are universal, so if you have a PCI/PCIe based ARM machine with PC-type peripherals (South Bridge, ethernet, video, etc), you are good to go. If you have an ARM machine with strange devices (i.e. the RaspberryPI), you have to wait for the manufacturer to release the specs, then you can write the drivers, then you can run Linux. Rinse, repeat for the next revision of the CPU ASIC (because they moved the registers around or used a slightly different ethernet block). It helps if you have some standardized interfaces, for example on the RaspberryPI you have standard USB, so you can use all supported USB-Wifi adapters right away. 4) boot loader: is different for each type of machine, each type of boot device media. period. (Even on PCs there is no longer any standard standard - some use old-school BIOS booting, others use EFI boot, some need BIOS/ACPI help, some do not). This makes it 4 issues, if you count the first (linux userland) non-issue. K.O. On Fri, Dec 07, 2012 at 01:01:36PM -0600, SLtryer wrote: On 10/23/2012 12:37 PM, Konstantin Olchanski wrote: An ARM platform does not exist. Unlike the PC platform where PC hardware is highly standardized and almost any OS can run on almost any vendor hardware, the ARM platform is more like the early Linux days where instead of 3 video card makers there were 23 of them, all incompatible, all without Linux drivers. If you had the wrong video card, too bad, no soup for you. In the ARM world, there is a zoo of different ARM processors, all incompatible with each other (think as if each Android device had a random CPU - a 16-bit i8086, or a 32-bit i386, or a 64-bit i7 - the variation in capabilities is that high). Then each device contains random i/o chips connected in it's own special way - there is no PCI/PCIe bus where everything is standardized. There are several WiFi chips, several Bluetooth, USB, etc chips. Some have Linux drivers, some do not. As result, there is no generic Linux that will run on every ARM machine. Not to be argumentative, but I always believed that the advantage of *nix* was that it could be ported to numerous platforms, regardless of hardware. You even mention the early Linux days, when there was little or no standardization of PC hardware. Yet, the platform didn't disappear from use simply because there might have been porting issues, most of which were caused more by proprietary secrets and hardware defects than the ever-present fact of diversity of hardware. But one could make the same argument even today: That there are many different CPU platforms, e.g., and that they are not standardized. One example I am thinking of is the Intel v. Amdahl CPU
Re: SL 6 etc. on ARM CPU units
I'm pretty sure there are Debian ports for ARM including RasberryPi. Here's an interesting project out of the UK http://www.southampton.ac.uk/~sjc/raspberrypi/ where the guy built a 64 node cluster using Lego for the supports. I'm also sure it was a lot of work like others have mentioned. Perhaps when the upstream providers get the kernel and the drivers going in the Fedora and RedHat branches we'll see SL7 or 8 available for ARM also. Joe On 12/07/2012 11:27 AM, Konstantin Olchanski wrote: Please do not confuse 3 separate issues: 1) Linux userland: this is pretty much universal and will run on any CPU as long as you have a cross-compiler and as long as the autoconf tools do not try too hard to prevent you from cross-compiling the stuff. 2) Linux kernel: is also pretty much universal and assumes very little about the CPU. There *is* some assembly code that needs to be ported when you move between CPUs (say from hypothetical SuperARM to hypothetical HyperARM). I believe current versions of Linux kernel have this support for all existing ARM CPU variations. 3) Linux device drivers: in the PC world devices are standardized around the PCI bus architecture (from the CPU, PCIe looks like PCI, on purpose) and most devices drivers are universal, so if you have a PCI/PCIe based ARM machine with PC-type peripherals (South Bridge, ethernet, video, etc), you are good to go. If you have an ARM machine with strange devices (i.e. the RaspberryPI), you have to wait for the manufacturer to release the specs, then you can write the drivers, then you can run Linux. Rinse, repeat for the next revision of the CPU ASIC (because they moved the registers around or used a slightly different ethernet block). It helps if you have some standardized interfaces, for example on the RaspberryPI you have standard USB, so you can use all supported USB-Wifi adapters right away. 4) boot loader: is different for each type of machine, each type of boot device media. period. (Even on PCs there is no longer any standard standard - some use old-school BIOS booting, others use EFI boot, some need BIOS/ACPI help, some do not). This makes it 4 issues, if you count the first (linux userland) non-issue. K.O. On Fri, Dec 07, 2012 at 01:01:36PM -0600, SLtryer wrote: On 10/23/2012 12:37 PM, Konstantin Olchanski wrote: An ARM platform does not exist. Unlike the PC platform where PC hardware is highly standardized and almost any OS can run on almost any vendor hardware, the ARM platform is more like the early Linux days where instead of 3 video card makers there were 23 of them, all incompatible, all without Linux drivers. If you had the wrong video card, too bad, no soup for you. In the ARM world, there is a zoo of different ARM processors, all incompatible with each other (think as if each Android device had a random CPU - a 16-bit i8086, or a 32-bit i386, or a 64-bit i7 - the variation in capabilities is that high). Then each device contains random i/o chips connected in it's own special way - there is no PCI/PCIe bus where everything is standardized. There are several WiFi chips, several Bluetooth, USB, etc chips. Some have Linux drivers, some do not. As result, there is no generic Linux that will run on every ARM machine. Not to be argumentative, but I always believed that the advantage of *nix* was that it could be ported to numerous platforms, regardless of hardware. You even mention the early Linux days, when there was little or no standardization of PC hardware. Yet, the platform didn't disappear from use simply because there might have been porting issues, most of which were caused more by proprietary secrets and hardware defects than the ever-present fact of diversity of hardware. But one could make the same argument even today: That there are many different CPU platforms, e.g., and that they are not standardized. One example I am thinking of is the Intel v. Amdahl CPU compatibility issue. Even though most of the Linux system will run on either without modification, there are still some unique issues to each of them; from having worked and studied VirtualBox, there are differences in how each manufacturer chose to implement the ring structure that permits virtualization to work as nicely as it does on these platforms. For the most part, they are compatible, but the kernel developers have to be aware of certain implemention issues, including a bug in the Intel CPU platform that requires a VirtualBox workaround (for optimizing the code or something; I forget). And this is in addition to Linux supporting umpteen different processing platforms besides the x86 types. New hardware appears constantly, and some Linux user somewhere wants to use it on their system. I feel that variety of hardware and variation in hardware implementation is a fact, and a main reason why Linux and Unix are so powerful and ubiquitous. Now I just
Re: SL 6 etc. on ARM CPU units
There appear to be three substantive issues: 1. The bootloader and booting methodology (something MS wanted to change on X86-64 platforms with the advent of MS Win 8 so that, effectively, MS non-certified environments would not be allowed to boot on platforms that MS certified for MS Win 8 -- nominally, a security measure, but in reality, a MS monopoly profiteer measure). 2. Device drivers (including any relevant bus issues) -- even today, there are some PCI and other devices for X86-64 for which the device vendor has released no USA hardware compatible driver specifications and that have not been reverse engineered to work with Linux. Evidently, this situation is more pervasive with ARM platforms. 3. Obtaining standard Linux end-user applications for ARM ISA platforms. For example, there is a rather stripped version of Mozilla Firefox for ARM Android platforms, but no Mozilla Thunderbird nor Lightning. Likewise, one uses something such as Busybox to provide a subset of regular open systems utilities -- an impressive and growing subset, but not full functionality. The peculiar thing is that -- internally -- Android does use a Linux kernel -- but not any sort of typical standard linux end user environment (e.g., a very limited GUI compared with something like KDE under X11, and the applications available thereunder). In part this is because of the limited RAM of an ARM platform, but I suspect that there were other deliberate incompatibility decisions made for market sector / business / profiteer purposes. Yasha Karant On 12/08/2012 05:17 PM, Joseph Areeda wrote: I'm pretty sure there are Debian ports for ARM including RasberryPi. Here's an interesting project out of the UK http://www.southampton.ac.uk/~sjc/raspberrypi/ where the guy built a 64 node cluster using Lego for the supports. I'm also sure it was a lot of work like others have mentioned. Perhaps when the upstream providers get the kernel and the drivers going in the Fedora and RedHat branches we'll see SL7 or 8 available for ARM also. Joe On 12/07/2012 11:27 AM, Konstantin Olchanski wrote: Please do not confuse 3 separate issues: 1) Linux userland: this is pretty much universal and will run on any CPU as long as you have a cross-compiler and as long as the autoconf tools do not try too hard to prevent you from cross-compiling the stuff. 2) Linux kernel: is also pretty much universal and assumes very little about the CPU. There *is* some assembly code that needs to be ported when you move between CPUs (say from hypothetical SuperARM to hypothetical HyperARM). I believe current versions of Linux kernel have this support for all existing ARM CPU variations. 3) Linux device drivers: in the PC world devices are standardized around the PCI bus architecture (from the CPU, PCIe looks like PCI, on purpose) and most devices drivers are universal, so if you have a PCI/PCIe based ARM machine with PC-type peripherals (South Bridge, ethernet, video, etc), you are good to go. If you have an ARM machine with strange devices (i.e. the RaspberryPI), you have to wait for the manufacturer to release the specs, then you can write the drivers, then you can run Linux. Rinse, repeat for the next revision of the CPU ASIC (because they moved the registers around or used a slightly different ethernet block). It helps if you have some standardized interfaces, for example on the RaspberryPI you have standard USB, so you can use all supported USB-Wifi adapters right away. 4) boot loader: is different for each type of machine, each type of boot device media. period. (Even on PCs there is no longer any standard standard - some use old-school BIOS booting, others use EFI boot, some need BIOS/ACPI help, some do not). This makes it 4 issues, if you count the first (linux userland) non-issue. K.O. On Fri, Dec 07, 2012 at 01:01:36PM -0600, SLtryer wrote: On 10/23/2012 12:37 PM, Konstantin Olchanski wrote: An ARM platform does not exist. Unlike the PC platform where PC hardware is highly standardized and almost any OS can run on almost any vendor hardware, the ARM platform is more like the early Linux days where instead of 3 video card makers there were 23 of them, all incompatible, all without Linux drivers. If you had the wrong video card, too bad, no soup for you. In the ARM world, there is a zoo of different ARM processors, all incompatible with each other (think as if each Android device had a random CPU - a 16-bit i8086, or a 32-bit i386, or a 64-bit i7 - the variation in capabilities is that high). Then each device contains random i/o chips connected in it's own special way - there is no PCI/PCIe bus where everything is standardized. There are several WiFi chips, several Bluetooth, USB, etc chips. Some have Linux drivers, some do not. As result, there is no generic Linux that will run on every ARM machine. Not to be argumentative,
Re: SL 6 etc. on ARM CPU units
On 10/23/2012 12:37 PM, Konstantin Olchanski wrote: An ARM platform does not exist. Unlike the PC platform where PC hardware is highly standardized and almost any OS can run on almost any vendor hardware, the ARM platform is more like the early Linux days where instead of 3 video card makers there were 23 of them, all incompatible, all without Linux drivers. If you had the wrong video card, too bad, no soup for you. In the ARM world, there is a zoo of different ARM processors, all incompatible with each other (think as if each Android device had a random CPU - a 16-bit i8086, or a 32-bit i386, or a 64-bit i7 - the variation in capabilities is that high). Then each device contains random i/o chips connected in it's own special way - there is no PCI/PCIe bus where everything is standardized. There are several WiFi chips, several Bluetooth, USB, etc chips. Some have Linux drivers, some do not. As result, there is no generic Linux that will run on every ARM machine. Not to be argumentative, but I always believed that the advantage of *nix* was that it could be ported to numerous platforms, regardless of hardware. You even mention the early Linux days, when there was little or no standardization of PC hardware. Yet, the platform didn't disappear from use simply because there might have been porting issues, most of which were caused more by proprietary secrets and hardware defects than the ever-present fact of diversity of hardware. But one could make the same argument even today: That there are many different CPU platforms, e.g., and that they are not standardized. One example I am thinking of is the Intel v. Amdahl CPU compatibility issue. Even though most of the Linux system will run on either without modification, there are still some unique issues to each of them; from having worked and studied VirtualBox, there are differences in how each manufacturer chose to implement the ring structure that permits virtualization to work as nicely as it does on these platforms. For the most part, they are compatible, but the kernel developers have to be aware of certain implemention issues, including a bug in the Intel CPU platform that requires a VirtualBox workaround (for optimizing the code or something; I forget). And this is in addition to Linux supporting umpteen different processing platforms besides the x86 types. New hardware appears constantly, and some Linux user somewhere wants to use it on their system. I feel that variety of hardware and variation in hardware implementation is a fact, and a main reason why Linux and Unix are so powerful and ubiquitous. Now I just hope no one will hold me to this and insist that I actually port Linux to all these different hardware configuration! I'm not signing up; I'm just pointing out what I think is reality.
Re: SL 6 etc. on ARM CPU units
Please do not confuse 3 separate issues: 1) Linux userland: this is pretty much universal and will run on any CPU as long as you have a cross-compiler and as long as the autoconf tools do not try too hard to prevent you from cross-compiling the stuff. 2) Linux kernel: is also pretty much universal and assumes very little about the CPU. There *is* some assembly code that needs to be ported when you move between CPUs (say from hypothetical SuperARM to hypothetical HyperARM). I believe current versions of Linux kernel have this support for all existing ARM CPU variations. 3) Linux device drivers: in the PC world devices are standardized around the PCI bus architecture (from the CPU, PCIe looks like PCI, on purpose) and most devices drivers are universal, so if you have a PCI/PCIe based ARM machine with PC-type peripherals (South Bridge, ethernet, video, etc), you are good to go. If you have an ARM machine with strange devices (i.e. the RaspberryPI), you have to wait for the manufacturer to release the specs, then you can write the drivers, then you can run Linux. Rinse, repeat for the next revision of the CPU ASIC (because they moved the registers around or used a slightly different ethernet block). It helps if you have some standardized interfaces, for example on the RaspberryPI you have standard USB, so you can use all supported USB-Wifi adapters right away. 4) boot loader: is different for each type of machine, each type of boot device media. period. (Even on PCs there is no longer any standard standard - some use old-school BIOS booting, others use EFI boot, some need BIOS/ACPI help, some do not). This makes it 4 issues, if you count the first (linux userland) non-issue. K.O. On Fri, Dec 07, 2012 at 01:01:36PM -0600, SLtryer wrote: On 10/23/2012 12:37 PM, Konstantin Olchanski wrote: An ARM platform does not exist. Unlike the PC platform where PC hardware is highly standardized and almost any OS can run on almost any vendor hardware, the ARM platform is more like the early Linux days where instead of 3 video card makers there were 23 of them, all incompatible, all without Linux drivers. If you had the wrong video card, too bad, no soup for you. In the ARM world, there is a zoo of different ARM processors, all incompatible with each other (think as if each Android device had a random CPU - a 16-bit i8086, or a 32-bit i386, or a 64-bit i7 - the variation in capabilities is that high). Then each device contains random i/o chips connected in it's own special way - there is no PCI/PCIe bus where everything is standardized. There are several WiFi chips, several Bluetooth, USB, etc chips. Some have Linux drivers, some do not. As result, there is no generic Linux that will run on every ARM machine. Not to be argumentative, but I always believed that the advantage of *nix* was that it could be ported to numerous platforms, regardless of hardware. You even mention the early Linux days, when there was little or no standardization of PC hardware. Yet, the platform didn't disappear from use simply because there might have been porting issues, most of which were caused more by proprietary secrets and hardware defects than the ever-present fact of diversity of hardware. But one could make the same argument even today: That there are many different CPU platforms, e.g., and that they are not standardized. One example I am thinking of is the Intel v. Amdahl CPU compatibility issue. Even though most of the Linux system will run on either without modification, there are still some unique issues to each of them; from having worked and studied VirtualBox, there are differences in how each manufacturer chose to implement the ring structure that permits virtualization to work as nicely as it does on these platforms. For the most part, they are compatible, but the kernel developers have to be aware of certain implemention issues, including a bug in the Intel CPU platform that requires a VirtualBox workaround (for optimizing the code or something; I forget). And this is in addition to Linux supporting umpteen different processing platforms besides the x86 types. New hardware appears constantly, and some Linux user somewhere wants to use it on their system. I feel that variety of hardware and variation in hardware implementation is a fact, and a main reason why Linux and Unix are so powerful and ubiquitous. Now I just hope no one will hold me to this and insist that I actually port Linux to all these different hardware configuration! I'm not signing up; I'm just pointing out what I think is reality. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SL 6 etc. on ARM CPU units
On Mon, Oct 22, 2012 at 01:42:51PM -0700, Yasha Karant wrote: ... I have a Samsung Galaxy Tab 2 7 (USA version) ... [with] Android, ... ARM CPU platform. ... I am considering attempting to switch it it to Linux. Gaaahh! Crazy Yasha is back! Evidently, there is both an Ubuntu and Arch distribution for some versions of the ARM platform -- any versions of EL for this platform? Anyone using Linux on this platform? There is a major misunderstanding regarding the ARM platform. An ARM platform does not exist. Unlike the PC platform where PC hardware is highly standardized and almost any OS can run on almost any vendor hardware, the ARM platform is more like the early Linux days where instead of 3 video card makers there were 23 of them, all incompatible, all without Linux drivers. If you had the wrong video card, too bad, no soup for you. In the ARM world, there is a zoo of different ARM processors, all incompatible with each other (think as if each Android device had a random CPU - a 16-bit i8086, or a 32-bit i386, or a 64-bit i7 - the variation in capabilities is that high). Then each device contains random i/o chips connected in it's own special way - there is no PCI/PCIe bus where everything is standardized. There are several WiFi chips, several Bluetooth, USB, etc chips. Some have Linux drivers, some do not. As result, there is no generic Linux that will run on every ARM machine. It is even worse. There is no generic Android OS that will run on every ARM machine: Look at CyanogenMod - a community effort to port generic Android to every available phone or tablet. They have to port the code specifically to each device: http://wiki.cyanogenmod.com/wiki/Devices_Overview If not, and there are any members of this list who also use this sort of platform under Android, off list correspondence and recommendations would be appreciated (e.g., how to get bash working, how to get non-GUI file and directory manipulation commands, etc.). There are android apps for some of these things, but all the good stuff is outside of the google play store. Much open source android apps (MyTracks, etc) live on the google project hosting site: http://code.google.com/hosting/search?q=label%3aAndroid Typical amateur end-user material that I have seen on some of the Android lists (e.g., the use as an entertainment device) is of less use to me. Several of my students have discussed rooting Android to get around the limitations imposed by the environment and getting closer to the underlying linux core (that is missing most of the support programs and APIs that make functional a regular linux distribution), but I need to more fully understand the consequences for this approach before proceeding (as well as getting detailed how-to instructions). You may discover that you have to root your device to do anything interesting at all. In the nutshell, an android device is like a Linux PC with an unknown root password. (actually the password is blank, but chmod u+s /bin/su and /bin/sudo are missing so you cannot get in). Rooting is like using a blow torch to open the hood of your own car that (for better or worse) was welded shut by the car maker. To extend the analogy, with Win8/WinRT MS require that the car hood be made out of titanium, regular blow torch does not work, you have to use an h-bomb (illegal is some countries). -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SL 6 etc. on ARM CPU units
Hello, Konstantin touched on Cyanogenmod, which I think would be your best bet for having a more open OS (and ability to interact with CLI I would assume), however, I don't think it's yet supported for the Samsung Galaxy Tab 2 (see the list here: http://get.cm/). Perhaps communications with with the Cyanogenmod devs would yield more fruitful advice? -Chris
Re: SL 6 etc. on ARM CPU units
On Mon, 22 Oct 2012, Yasha Karant wrote: Because my institution has elected to (mostly) go paperless, I have a Samsung Galaxy Tab 2 7 (USA version) under some recent Android environment, ARM CPU platform. After several days of using the unit as an end-user portable computer (e.g., for PDF editing, office suite, email, web browser, video conference as needed, and 802.11 connectivity, etc., but not for coding or typical scientific applications), I am considering attempting to switch it it to Linux. Evidently, there is both an Ubuntu and Arch distribution for some versions of the ARM platform -- any versions of EL for this platform? Anyone using Linux on this platform? http://www.redsleeve.org/ appears to be a port of TUV to ARM. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge a.c.aitchi...@dpmms.cam.ac.uk http://www.dpmms.cam.ac.uk/~werdna
