Slashdot Mirror
Facebook Joins Linaro Linux-on-ARM Effort
dgharmon writes "It has been more than two years since Freescale Semiconductor, IBM, Samsung, ST-Ericsson, and Texas Instruments formed a non-profit software company called Linaro to help focus the disparate efforts to get Linux running well on ARM processors and system-on-chip designs. A slew of companies, some new to the ARM racket, have joined the Linaro effort – and as of Thursday afternoon, so has social media juggernaut Facebook."
http://mobile.slashdot.org/story/12/05/28/1632226/is-facebook-working-on-a-smartphone
sysadmins and parents of newborns get the same amount of sleep.
I'm posting from a Linux on ARM device right now.
I guess it depends on what you mean with "running well": I have a Pandaboard and, well, it has been a major clusterfuck all the way from the beginning, what with constant breakage of features, on some releases of the software the features disappear completely, and then there's the constant crashes in the kernel. Imagine my surprise when I installed the latest stable Texas Instruments - release of the kernel only to find that networking is completely broken and the kernel goes to a hard lock-up after being on for 5-10 minutes, whether or not it just sits idle this whole time.
If all I want out of it is unaccelerated X or just console applications then yes, it runs very well, and it works great as a low-foothold server for all kinds of things. I'm just saying that I sure have no high expectations for these guys and their efforts.
According to the Wikipedia article, these guys are simply trying to simplify, optimize, and reduce fragmentation in the ARM/Linux world. They're not trying to claim anything except that their tools and validation suite make your life easier.
It's sort of like the Linux Standard Base, if you remember that initiative. The LSB was invented to address concerns of fragmentation and difficulty in porting applications to Linux, because the distributions were so radically different from each other. While it didn't work out as well as hoped, it did manage to reduce the idiosyncrasies.
Isn't Android itself a Linux-derived OS? I thought Torvalds said that Android will be converging back to Linux in the future.
Yes, Android runs on a slightly modified Linux-kernel. Most of the modifications have now made their way into the mainline kernel, so in the future it may well be possible that there is no need for modifying the kernel at all. The userland on Android and any Linux-distro is entirely different, but I s'spose you knew that already.
For that matter Linaro has been making ARM patchsets for various hardware for over 10 years (maybe even longer!). Probably 3/4 of the ARM Linux hardware you'll find (be it routers, IPCams, print servers, etc) will be running some kernel with a -linaro in it, and even the ones that aren't usually have a -linaro in the gcc/binutils buildversion.
They're just trying to reduce their own costs by consolidating the majority of necessary changes into patchsets that will be accepted into the kernel, so that minimal additional, potentially conflicting, code will end up outside of the kernel in the long run.
Can't fault them for wanting to make both our and their lives easier.
It's long past time for this. China is doing MIPS servers too.
Help stamp out iliturcy.
Even if Facebook is planning a smartphone (huh?) they don't have a lot of motivation to improve core Linux on ARM. I think it more likely that they're seriously looking at transitioning their (huge) data centers to ARM in order to save energy costs.
I've poo-pooed ARM-server speculation in the past, but this goes way beyond speculation.
My first personal computer had a 6502 (and a Z80) on the motherboard. Now get off my lawn!
Geology - it's not rocket science; it's rock science
Of course, that's not what Linaro is about. They are looking forward to stop the explosion of code and architecture within the ARM familly. No two ARM machine boots the same. No two ARM processors expose component the same way. You did not read Linus saying "what about stoping the ARM crap?"
Soon they will have to address this problem, not so much as to allow Linux to spread, but because it drives the cost of ARM based devices for the companies that make money writing the operating systems for them, such as Microsoft. It is a competitive disadvantage for ARM to be in charge of a zoo.
Do it yourself, because no one else will do it yourself. [beta blockade 10-17 Feb]
Ah...I still have fond memories of my C=128
If Mr. Edison had thought smarter he wouldn't sweat as much. --Nikola Tesla
I understand the upsides of ARM servers, namely lower cost hardware and much better energy efficiency. However, what are the downsides? I've heard mixed stories about whether or not we can achieve the same performance from ARM as we can from x64, but nothing concrete.
If there are no significant shortcomings, I'd wager that Intel's days are numbered. A lot of AMD's revenues come from server deployments, and they've already jumped on board with ARM, but Intel shows no interest in doing so. You'd figure that *maybe* intel would license its architecture similar to how ARM does, rather than keeping everybody else out except for AMD through cross patent agreements, in order to keep x86 alive, but they don't show interest in doing that either.
Sure there's always the desktop market, but that segment is seeing very limited growth at the moment, and there aren't any indications that this will improve any time soon, especially with Microsoft and its apparent plans to push everybody over to architecture agnostic applications (although, whether or not that will succeed depends on who you ask.)
Careful with names containing L slashdot.org/~AiphaWolf_HK slashdot.org/~AlphaWoif_HK slashdot.org/~AiphaWoif_HK
no, it has no MMU
For that matter Linaro has been making ARM patchsets for various hardware for over 10 years (maybe even longer!).
Citation needed. According to wikipedia, Linaro was only founded 2 years ago.
Most human behaviour can be explained in terms of identity.
Android runs ON Linux. end of story... Including all the utilities unix/linux provides. It is a Linux distribution that relies on Java for the desktop. SuSE, Slackware, and RedHat are based on Linux. They have different desktops based on different technologies.
They are all Linux.
Android runs ON Linux. end of story... Including all the utilities unix/linux provides. It is a Linux distribution that relies on Java for the desktop.
Incorrect. Taken from the Wikipedia - page for Android:
Android's linux kernel has further architecture changes by Google outside the typical Linux kernel development cycle.[43] Android does not have a native X Window System by default nor does it support the full set of standard GNU libraries, and this makes it difficult to port existing Linux applications or libraries to Android.[44] But the support of simple C and SDL applications is possible by injection of a small Java shim and usage of the JNI[45] like e.g. in the Jagged Alliance 2 port for Android.[46]
So, you're saying the exact same thing I said?
I don't get your point? You're just saying the same thing as I said?
no, it has no MMU
Actually, that's not the big problem. I think that the MMUless code was merged back into the mainline at some point. Either way there's still ucLinux.
The more fundemental problem is that the stack pointer can't be moved, which makes preemptive multitasking painful.
But it has been done, and it's called lunix.
SJW n. One who posts facts.
Linaro is not a distribution. It's a joint effort to *help linux run on ARM hardware*.
For example there are about three linux based distros for the openmoko, all with custom UI front ends.
And for these "linux based distros" to work you need a running linux (kernel) on which to base them. That's the work of the software company named Linaro.
To give into more details:
as a point of comparison, in the x86 processor world, things are rather standardized, and well modularized. There's more or less only one single main platform (the PC) with some weirder variant (BIOS vs. (U)EFI, or even weirder PC vs. custom Apple Intel Macs) and a few exception (they are really rare and don't matter much for mass consumption). With clearly organized components (no matter if you go for Intel, AMD, Via or more rare hardware: you've got the same basic CPU, northbridge, south bridge, PCIe bus, etc.). And well defined procedure to initialise and control everything. On the software side, all this is controlled by using clearly modularized and segregated components.
When something new arrive to the market (like the jump from BIOS to EFI, the move from PCI to PCIe, etc.) you only need to write a module and leverage what already exists for everything else.
To boot into linux, you use the same kernel everywhere, and only load different drivers depending on the local variations.
in the hardware arm world, things are much more messy: lots of weird SoC are put together, with far less standardisation. Also, whereas the x86 hardware is general purpose and widely available to everyone (just think about all the beige boxes everywhere. Then think that if you need server, a compute node or a home theaterPC you use the samecomponents. And branded machine (brand servers) use the same componenents too), lots of the ARM hardware tend to be put together for very specific custom usage (a company using their own SoC + PCB for a router. Another for a smart phone. Another for a NAS. Another for TV set top box. Etc.). Lots of this hardware is one-shot (there's few design re-use between a router and a smartphone).
as a consequence, before Linaro, Linux on ARM was a big mess: each time a company put together some hardware, they also do their own port in a one-shot fashion: they download the linux source, write a big monolithic patch to support their own weird variant, compile it, even sometimes publish the code (to be compliant with the GPL) and call it a day.
when another company wants another ARM-based machine, they just to the same.
No modularisation. No code re-use. No easy rebasing of the kernel.
That's why for several pieces of hardware, you're basically stuck with one very specific kernel version (openmoko is still at 2.6.x something) even when the source is available: the hardware depends on a huge monolithic platform drivers which is tighly dependant on the very specific kernel version against which the patch was written.
If there's any known kernel bug, your only hope is to wait for the back-port. you can't just move to a recent kernel (to 3.6.x).
If you want to provide a distribution for several pieces of hardware, you need one separate kernel per each separate device, sometimes different kernel version (depending against which kernel version was the patch written).
A big mess.
It's not a surprise that Microsoft is having big difficulties with Windows 8 on tablets and smartphones: the hardware landscape is really weird (and their own approach is to impose 1 single specific type of platform, so writing Windows 8 is easy and have everyone else standardize on it) (that's why they won't end up being as much popular on smart phone as they wished).
The role of Linaro was to put some order in this mess, by gathering together several of the people involved (there are hardware companies here) and giving them opportunities to work together and coordinate their effort. Among them as well as together with the kernel developers and the rest of the community.
Split every
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
The Android convergence was about bringing the specificities needed to run android userland back into the main kernel tree, instead of a special separate fork.
(e.g.: Among other, Android uses some special type of IPC)
Since recent kernel (was it 3.5? 3.6? memory fails me) these modifications are back into the main tree.
So, today, *as long as the hardware is supported*, you can run Android using any modern kernel. (for example: there are some interesting experiment of having both Ubuntu and Android running on the same ARM device using the same kernel)
Linaro is about the rest, about the "as long as the hardware is supported" part. As said above by godrik:
No two ARM machine boots the same. No two ARM processors expose component the same way.
As I've explained elsewhere in this topic, this has lead in the past to a situation where every single ARM machine has a seprate monolithic patch which was custom-written in one shot by the machine maker.
The point of Linaro is to bring some discipline in this, bring cooperation between all makers & developpers, and help modularize all this into small independent component.
So when the next machine comes to the market, instead of writing yet another new monolithic patch completely from scratch, as much work as possible can be leveraged from what already exist.
And the other way around: when a new kernel version comes, instead of having to port several thousand different monolithic patches (which never happens. end-users are always stuck with hardware specific versions), it will be easier to just maintain the few modules affected by the update changes.
When both are combined, that means it'll be incedibly easy to use Android on as many devices as possible. For the manufacturer, that's a no-brain choice. The mainline kernel contains everything needed to run android, and contains a lot that can be leveraged to support the hardware. Either write just a few new needed drivers, or even better (if you're lucky) only write new settings for some generic hardware.
BTW: Microsoft has chosen a different path - screw everything else, we're only supporting one specific way, one single type of machine. Either go our way, or pick another OS. My bet is that this isn't going to work very well, specially given the flexibility that android is offering on the other hand.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Emulate an x86 or supported ARM on a 6502. Of course, performance would likely be seconds (or minutes) per FLOP. Aside from the slow instruction cycle rate of the fastest made 6502, all your "emulated" RAM would have to be on disk.
Don't try to out wierd me, three-eyes. I get stranger things than you, free with my breakfast cereal. --Zaphod Beeblebr
ucLinux is not Linux
there are the ARM patches to 2.6.14 t o 2.6.19 work on an MPU (Memory Protection Unit rather than MMU) of certain ARM systems
so, you need something to manage memory
and ucLinux is not Linux
also, the ARM patches to a few of the 2.6 kernels that use the MPU of certain ARM systems still is relying on a memory management/protection hardware
no memory management/protection, no full Linux