Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Hardware Companies Team Up To Fight Mobile Linux Fragmentation

Soulskill posted more than 3 years ago | from the isn't-that-cheating dept.

IBM 47

Nunavut writes with news that a number of hardware companies have banded together to battle the fragmentation of the mobile Linux market. ARM, Freescale Semiconductor, IBM, Samsung, ST-Ericsson, and Texas Instruments are forming Linaro, a nonprofit organization that plans to focus on "low-level software around the Linux kernel that touches the silicon, key pieces of middleware that enable new markets, and tools that help the developer write and debug code." "Linaro's chief goal is to reduce the time that it takes to bring a new ARM-powered product to market with Linux. This effort is largely neutral with respect to what software environment and components individual vendors choose to run in user space. Linaro will not compete with existing platforms such as MeeGo and Android. Instead, it will attempt to improve the shared underlying software components that allow those platforms and others to run on ARM SoCs. In principle, this could actually reduce fragmentation at the lower levels of the Linux stack."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


Biggest issue they face... (-1)

CdBee (742846) | more than 3 years ago | (#32468522)

.. will almost certainly be non-open-source apps. Good luck to them but I'd have thought their stated aims will be easy - recompile, optimise, repeat until done.

Then try to ship a product without flash because you've optimised away all your concerns but missed out on an important closed-source deal-breaker

Re:Biggest issue they face... (5, Insightful)

Anonymous Coward | more than 3 years ago | (#32468652)

What in god's name are you blathering about? This is a non profit organization that intends to deal with low level hardware libraries. It has nothing to do with "apps" and they have no intention of shipping a product. All of this is right in the summary.

Duct Tape Prevents Mobile Linux Fragmentation (1)

tomhudson (43916) | more than 3 years ago | (#32468946)

Just tell him that they're recommending duct tape to prevent mobile linux fragmentation - he obviously only reads the headlines while trying to get a first post :-)

And it eliminates the need to defrag (I know, linux doesn't need defragging :-) - just add a new layer of tape every month.

And if you want, Monica Lewinsky is now offering a line of Duct Tape Nobile Phone Defragmentation Skins - because you never know where someone's going to stick their phone ...

Re:Biggest issue they face... (1)

Sleepy (4551) | more than 3 years ago | (#32469346)


Back in the day... we used to ridicule people who actually read the STORY but didn't also cross reference it from another media source!

Give the guy a break -- look at his USER ID. You can't possibly expect a Generation Z'er to read the SUMMARY, can you? Trust me, it's a lost cause.
Just accept it will only get worse.. I expect the next generation only posts words without capitalizing the first word of each sentence, all words without vowels and zero punctuation.

Now get off my lawn!

re biggest issue they face (1, Funny)

Anonymous Coward | more than 3 years ago | (#32470104)

generation z is the last one dude the world ends after this so quit wasting time reading summaries and punctuating how much did you pay for 4551 anyway question mark

Re:Biggest issue they face... (5, Funny)

Anonymous Coward | more than 3 years ago | (#32468674)


You've won the coveted "You Retard!" slashdot community award.

Do you have any thing to say about this prestigious win?

Re:Biggest issue they face... (0)

Anonymous Coward | more than 3 years ago | (#32468732)

Finally you will be able to defragment your Linux!

Uh oh (0)

Anonymous Coward | more than 3 years ago | (#32468558)

enable new markets

This probably will not go well.

Re:Uh oh (5, Funny)

maxwell demon (590494) | more than 3 years ago | (#32468744)

enable new markets

This probably will not go well.

Oh, that one is easy. Just go to the configuration, and check the box at "enable new markets". Alternatively you can also do it by hand with
echo 1 > /proc/market/new/enabled

Motorola Backflip on AT&T (1)

tepples (727027) | more than 3 years ago | (#32470174)

Just go to the configuration, and check the box at "enable new markets".

Unless your carrier has removed "enable new markets" from the menu, as AT&T appears to do [pcworld.com].

if they'll fail (3, Insightful)

underqualified (1318035) | more than 3 years ago | (#32468576)

they'll be yet another fragment

Re:if they'll fail (0)

Anonymous Coward | more than 3 years ago | (#32468606)

But they'd be an irrelevant fragment.

These days, the underlying OS doesn't matter, even when it comes to mobile devices. That's not where the interesting or critical development is happening. What matters these days is the higher-level APIs. Those are what mobile applications use, with very few mobile apps actually needing to care about the underlying OS.

Re:if they'll fail (1)

sznupi (719324) | more than 3 years ago | (#32468660)

...and since quite a few (not only Android and MeeGo, also part of bada OS for example) of those "high-level APIs that matter" rely on essentially commoditized underlying OS - what's wrong with providers of architecture and SoCs which run that OS teaming up?

Re:if they'll fail (2, Insightful)

jedidiah (1196) | more than 3 years ago | (#32468668)

Yes. This is about "standardizing the Darwin part" of an iPhone or an iPad.

If this leads to Android or Ubuntu being able to readily run on an iPad and other similar SoCs then I believe they will have set out what they wanted to achieve.

Re:if they'll fail (0)

Anonymous Coward | more than 3 years ago | (#32468804)

android and ubuntu already do run readily on anything that has a linux kernel and working drivers. Working drivers being the most difficult part, because too many companies like those forming linaro just release binary only drivers that only work on one specific kernel version.

Re:if they'll fail (1)

jedidiah (1196) | more than 3 years ago | (#32470192)

Mobile ARM systems aren't beefy enough to be terribly effective if all of the acceleration features aren't available.

Even an iphone suffers from this if you force it outside of it's predefined limits.

Re:if they'll fail (1)

sznupi (719324) | more than 3 years ago | (#32556836)

Why would they even care about what iPad has, considering Apple surely tries to prevent tempering also with this product?

Re:if they'll fail (3, Interesting)

JohnBailey (1092697) | more than 3 years ago | (#32470468)

These days, the underlying OS doesn't matter, even when it comes to mobile devices. That's not where the interesting or critical development is happening. What matters these days is the higher-level APIs. Those are what mobile applications use, with very few mobile apps actually needing to care about the underlying OS.

Absolutely.. The really important bit is the place where they hay is stored for the unicorns. Apple user right?

Re:if they'll fail (0)

Anonymous Coward | more than 3 years ago | (#32468690)

Since they're primarily only improving existing software, the only way for them to "fail" is if their code isn't getting accepted upstream. And that seems unlikely, since they start their work directly with the upstream developers..

Ubuntu (0)

Anonymous Coward | more than 3 years ago | (#32468580)


Linaro is closely aligned with Ubuntu's Linux on ARM initiative. Many elements of the Linaro project will be managed through Canonical's Launchpad collaboration platform, though a lot of the code will be managed and contributed upstream. Much like Ubuntu, the Linaro project will adhere to a six-month, time-based release cycle. This will allow for rapid iteration and predictability. Ubuntu founder Mark Shuttleworth discussed certain aspects of Linaro in a blog entry that was published Thursday. He views the project as a win for consistency and a constructive way to reduce fragmentation without eroding the diversity of the mobile Linux ecosystem.

Good idea - but these orgs move very slowly (3, Informative)

Foredecker (161844) | more than 3 years ago | (#32468588)

I've participated in a few industry wide organizations like this. They can be somewhat effective, but even then, they move very, very slowly.

Re:Good idea - but these orgs move very slowly (1)

Alef (605149) | more than 3 years ago | (#32468898)

After having read the FAQ [linaro.org] on the Linaro web site and a blog entry [markshuttleworth.com] by Mark Shuttleworth, I get the feeling that this is an initiative coming from Canonical. If they will be driving this forward, with support from the hardware vendors of course, it might not become your garden variety standards organisation. In that case, the key issue will be to keep the commitment from the hardware manufacturers. But I guess it could work out alright considering Canonical isn't a direct competitor to any of them.

Re:Good idea - but these orgs move very slowly (1)

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#32469044)

I would suspect that the only people unhappy with this particular initiative are those who compete with linux, for obvious reasons, and possibly those companies who currently specialize in doing bespoke embedded linux work for hire. MontaVista, for instance, has basically made a business of doing the (often obnoxious and tricky) work of turning "linux runs on ARCHITECTURE" into "Linux is now running on CUSTOMERS_HORRID_EMBEDDED_BOARD". An industry consortium dedicated to giving that away probably isn't ideal for them.

Presumably, any hardware manufacturers who treat their BSPs as a source of profit(or consider their BSPs to be superior to such a degree that they serve as a key differentiator from competing products) from would also be displeased; but the impression that I get is that most of them view hacking together the BSP as a necessary evil to be endured in selling the board(even when they do charge for them, it's more of a cost recovery/keeping out the riff-raff sort of thing), so most would probably prefer a strategy that makes it happen as cheaply as possible.

You are correct. (1)

agoliveira (188870) | more than 3 years ago | (#32472006)

Canonical started this a few months ago.
I work for Canonical (not in this project tough) and follow it with a personal interest.

Not necessarily (4, Interesting)

Kupfernigk (1190345) | more than 3 years ago | (#32469028)

To quote a BSi project manager I once used to work with, there are 2 sorts of standards initiative - those intended to get something done, which can be very fast, and those intended to hold up standardisation while the prime mover gains market share. Since this is intended to create a standard quicker than Windows 7 whatever edition can gain traction, it could all happen very fast.

I once had the good fortune to work on a project where the standard proceeded so much faster than capability that for 6 months we were the world's only supplier of a standards-compliant product, though a small one. Believe me, it was worth the effort.

Re:Good idea - but these orgs move very slowly (1)

yorugua (697900) | more than 3 years ago | (#32471000)

I've participated in a few industry wide organizations like this. They can be somewhat effective, but even then, they move very, very slowly.

I hope it turns out better than the old "Project Monterrey" thing...

Foredecker - tell us more about "slow" please (0)

Anonymous Coward | more than 3 years ago | (#32523594)

I've participated in a few industry wide organizations like this. They can be somewhat effective, but even then, they move very, very slowly. - by Foredecker (161844) * on Saturday June 05, @10:33AM (#32468588) Homepage

On the note of "moving slowly", you're not one to talk. See here:

http://slashdot.org/comments.pl?sid=1630116&cid=31975424 [slashdot.org]

How many months ago was it you'd stated you'd find answers to the HOSTS file dilemna noted there? 7 months now. You stated you'd get back to that poster in far less (2 months or so).

Pertinent material, requoted from the url above, now once again below:


"Be patient :) Ill get to this. I just dont know when. I think I can get back to you by mid February, but it may be March." - by Foredecker (161844) * on Saturday April 24, @01:42PM (#31968126) Homepage

That quote of your words is from here -> http://slashdot.org/comments.pl?sid=1495166&cid=30715150 [slashdot.org] back in January (10th of Jan 2010)...

Once more, to refresh you on it:

This is again, in regards to HOSTS files in VISTA, Windows Server 2008, & Windows 7 being unable to use the smaller & faster + more efficient "0" blocking "IP Address" (vs. the larger, slower, & less efficient on filesize & read/write time (or, worse yet, "loopback adapter IP address") which are STILL useable in Windows VISTA, Windows Server 2008, & Windows 7!).

However/Again (refreshing your mind on the particulars/details), before MS "Patch Tuesday" on 12/09/2008 though? Well - You could STILL USE THE SMALLER & FASTER 0 blocking address in HOSTS files, vs. the larger & slower + less efficient or worse still, the loopback adapter address in Windows VISTA, Windows Server 2008, & Windows 7 (for blocking out KNOWN BAD sites &/or servers)...

Using 0 yields increases in speed + efficiency & due to FAR LESS FILESIZE involved for reads inside the file and reading the HOSTS file as a whole (smaller = faster), especially!



HOSTS using 0, with 840,000 blocked KNOWN BAD sites &/or servers entries in it blocked = 18,430 kb size


HOSTS using, with 840,000 blocked KNOWN BAD sites &/or servers entries in it blocked = 23,338 kb size


HOSTS using, with 840,000 blocked KNOWN BAD sites &/or servers entries in it blocked = 24,975 kb size


As you can see, 25%-35% approximate filesize diff.'s in using smaller vs. larger preceeding blocking addresses in front of bad sites/servers domain-hosts names manifest themselves ("do the math" etc.), & thus? Using 0 as a blocking address indeed DOES MAKE A DIFFERENCE here, for performance sake!

(Which is YOUR division @ MS you head, correct? In the "Windows Client Performance Division" so, this ought to interest you some, & hopefully enough to find out WHY the IP Stack Team has taken out the fastest & smallest + most efficient entry of 0 for blocking in HOSTS files... makes NO sense that they did, because of the evidences above!)

Funniest part is, the Windows 2000, Windows Server 2003, & Windows XP still can use the smaller, faster, & most efficient 0 blocking address (vs. the larger/slower & worst of all, but, MS inserted the ability to use 0 as a blocking IP address back as far as Windows 2000 (not its original OEM pre-service pack/hotfix release, but, somewhere in between SP#1 - SP#4 for Windows 2000... this is a BETTER STANDARD, one that MS set no less, because it yields a smaller & faster read HOSTS file, period!)

The physics of it all back me on this, & so does the math.

Especially when populating either the DNS ClientSide Cache service, OR, the local diskcache (which depends on the SIZE of the HOSTS file)


That also brings up 2 more issues I noted on a BUG I have found in hardcodes & inflexible buffers/structures in DNS it seems, in Windows, which I noted to you before (on pagefiles & DNS client too):

The local DNS Client Service needs fixing for larger HOSTS files too, & in ALL FORMS of Windows NT-based OS... I state this, because it "breaks down" & begins to LAG THE OPERATING SYSTEM BADLY with relatively larger HOSTS files being used!

(On a guess, you people @ MS are using the BSD reference design for the local DNS cache via a structure (or possibly an object) that has LIMITED SIZE, rather than a "flexible" FIFO queue (or, a "redimmable array") etc./et al instead - So, thank goodness the LOCAL DNS CLIENT CACHE SERVICE can be turned off, & instead, the local diskcache takes over once it has populated its memory buffer via (on a guess), Binary Tree populations...)

Let me know what's up on your end, because you said you'd get to that by Feb-March 2010, & it's the tail end of April 2010, only 5 days away from May 2010...




You're obviously not anyone to be stating others move slowly based on the above from you. I read you blog also where you tried to pick apart what he said which I quoted again for everyone reading's reference, and in the end you had to admit that a larger hosts file will read slower.

You said you'd get back to him, and it appears that you have not, and that he was correct in his assumptions because you first tried to "knock down" his statements, but in the end, you had to admit he was correct instead and trying to "snow someone" that you'd "get back to them" is not working in your favor here at all, so as far as talking about being slow here now on your part? See the above.

Battle fragmentation ... (0)

Anonymous Coward | more than 3 years ago | (#32468598)

... or compete with Qualcomm? How many Android devices don't have Qualcom hardware?

Direct response to Meego (0)

Colin Smith (2679) | more than 3 years ago | (#32468724)

Nokia & Intel.

But with added committees.


Re:Direct response to Meego (3, Insightful)

dwater (72834) | more than 3 years ago | (#32469218)

won't this also help meego?

Re:Direct response to Meego (1)

MacAnkka (1172589) | more than 3 years ago | (#32469860)

My thoughts exactly. These Linaro guys will focus on getting the the low level kernel stuff patched up and fixed for the all the new ARM platforms as they are released. MeeGo develelopers can use that, they won't have to worry about the low level stuff as much and they can focus on the user experience and all the other special stuff that makes MeeGo different. Same goes for all the other linux-based mobile operating systems. I guess that would include Android, too.

That the way I understood it, at least.

Re:Direct response to Meego (1)

dwater (72834) | more than 3 years ago | (#32469944)

I'm sure they say as much on their web site...this is from their FAQ :

Q8. How is Linaro different from Android, MeeGo, LiMo or other similar distribution?

A8. Linaro software and tools provide a common software foundation for the industry to use with multiple software stacks and distributions. Linaro software and tools focus on areas that interact directly with the silicon. Distributions such as Android and Ubuntu provide the full user experience whereas Linaro enhances the upstream projects directly and provides useful components to any downstream distributions that wish to leverage the work done by Linaro.

The Extended Extention Extender (0)

Anonymous Coward | more than 3 years ago | (#32468762)

Like Extending Extended Extensions? Then Get the Extended Extension Extender Extended edition with Extra-Extended Extreme Extension Extending Extenders.

It's the apps, stupid (1, Informative)

Burz (138833) | more than 3 years ago | (#32468950)

What is this about improving the ability to bring new Linux-based devices to market? There are scads of them already, and that's part of the problem.

The fragmentation these devices represent mainly occurs above and below the kernel level: Above in the sense that the libraries and UI kits that are included change greatly not only between devices, but also between iterations of a single product; Below in that there is no (realistically desirable) minimum hardware spec for a Linux-based device in any given class like smart phones.

So this Linaro effort doesn't seem to help out where help is most needed IMO: Enabling creative types who work above the hardware level to identify and easily make use of a robust and attractive platform... something to confidently write apps on. As with the PC revolution, again its the apps that will win user interest.

Linaro maybe more of an attempt to get the likes of Google to heel with its forking of the Linux kernel for use in Android. But I would say that Android itself is the better focus for a standardization effort: it is full-featured so the roles that any particular components will be expected to satisfy can be looked at much more holistically when features are being written or debugged. And without that holistic view -- like what happened to Desktop Linux as a vague concept -- components that are written or standardized outside of a specific user-targeted platform (like Android, or iPhone for that matter) are unlikely to give rise to a coherent and satisfying user experience.

IOW, design affects all layers simultaneously and what works for people administering servers does not work when people expect to create/sell/share software applications on a user-oriented platform.

Re:It's the apps, stupid (5, Insightful)

aero6dof (415422) | more than 3 years ago | (#32469058)

Given the membership and their statements, it actually sounds like they might be working on integrating/standardizing the access to underlying hardware. Most of those manufacturers make ARM chips with various added peripherals. It would certainly save time if I could grab a Linux distro that was everything below the UI level without having to spend time integrating the low level chip libraries to access the custom hardware functions in the chip.

Re:It's the apps, stupid (1)

Daengbo (523424) | more than 3 years ago | (#32469326)

I get where you're coming from: choice is bad, especially when it involves MP3 players, TVs, and phones. I get it, but I don't agree. This is about making hardware vendors' lives easier, not application developers'.

Summary (3, Insightful)

bcmm (768152) | more than 3 years ago | (#32468952)

Very good idea. Code reuse is always good. However, one minor point about the summary: fat chance of Android either helping or being helped by this - AFAIK, they've already messed up their Linux-derived kernel to the point where you can't assume that modules from actual Linux will work with it.

That's why I'm rooting for MeeGo (3, Insightful)

Qubit (100461) | more than 3 years ago | (#32474042)

I gotta hand it to the MeeGo folks. Their project has goals like

1) Keep it FOSS. All of it (in the core distro)
2) Upstream code whenever possible

Even if you don't use it as a mobile OS, the work being done on it by Intel, Nokia, etc... is going to benefit pretty much every Linux-derived distro out there.

If Linaro wants to join the party and throw time/money at improving Linux-y software running on ARM chips, that sounds pretty darn good to me!

Words (1)

Alarindris (1253418) | more than 3 years ago | (#32469286)

Why "Fight Fragmentation" rather than "Promote Unity"? We're all on the same team right?

Re:Words (1)

stiggle (649614) | more than 3 years ago | (#32494106)

Fight is "action"
Promote is "passive"

Both are "marketing"

Therefore if you want to convey the synergy of the stakeholders within the working group committee then you need to be forthcoming in the policy statement to delineate the competing elements and actively market your intentions.

PS. I've been writing crap for management too often the last few weeks - I'm sorry :-)

If it gets TI to fix the I2C... (0)

Anonymous Coward | more than 3 years ago | (#32470118)

interface for their damn AIC33 audio chips, I'll be happy.

I predict (1)

abulafia (7826) | more than 3 years ago | (#32470864)

That this will work about as well as the various "let's unite Unix" corporate drum circles from the 80s and 90s.

They did eventually get things to a point where a subset that wasn't entirely useless could usually compile pretty cleanly, most of the time, sort of, in most places. So long as the code wasn't concerned with whatever the market was concerned with five years prior.

Linus did more to unite Unix than any of the cross-company bodies.

To be more fair, moving the compatibility bar forward, even slowly, is not a bad thing. I just don't think it will do much to shape things in any meaningful way for quite some time.

See your shit and raise you a FORK !! (0)

Anonymous Coward | more than 3 years ago | (#32470948)

I will FORK you motherfucker! motherfucker!!

OpenEmbedded (0)

Anonymous Coward | more than 3 years ago | (#32474014)

I wonder if they'll utilize OpenEmbedded since it already takes care of a lot of this type of thing.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account