It's not the question of if, it's question when [LWN.net]

It's not the question of if, it's question when

Posted Nov 5, 2011 0:55 UTC (Sat) by khim (subscriber, #9252)
In reply to: libabc: a demonstration library for kernel developers by dlang
Parent article: libabc: a demonstration library for kernel developers

oh, you think _your_ ability to choose is good, but other people shouldn't be annoyed by the ability to choose? sorry, you have crossed the line.

It's not "the ability to choose". It's the list of choices. There are "Linux way": you can pick your distribution which have different init systems, different desktop environments, different set of compilers and support libraries... and handful of games or office suites. Or you can have "Android way": only one set of libraries (but evolving one), but 500'000 applications including dozen of office suites and thousands of games.

Sure, 500'000 Android applications are greatly inflated number (most of them is trivial crap), but there are a lot of good ones, too. Linux can never achieve anything remotely similar till it'll provide one supported environment and not dozens of incompatible ones with hudnreds of possibilties and subpossibilities.

As was said in the good article on the subject: flexibility begets complexity, complexity begets problems. Flexibility is good, problems are bad so you need the right balance.

Linux world is skewed to the side of flexibility (and accompanying problems) to such a degree that it's useless for most people unless someone removes most of the choices. At some point we can reach the state where we'll have not enough flexibility, but we so, sooo, SOOO far from that point that we can stop worrying about that for the next 10 years.

P.S. Kernel people understand that better then userspace, again. If you'll take a look on the list of options presented in "make config" you'll see literally hundreds of options. But if you'll try to push something without very serious justification... you'll be disappointed. Think LVM2 vs EVMS. Or, further up stack: linuxthreads vs NPTL vs NGPT. Few years ago we had "choice", now only NPTL remains... but is it such a bad thing? Yet further up stack we have a mess where dozens of choices coexist just because noone bothered to eliminate them.

(Log in to post comments)

There is nothing wrong with use of the old version

Posted Nov 6, 2011 21:54 UTC (Sun) by khim (subscriber, #9252) [Link]

Do you use glibc 2.5 or have you ported linuxthreads to glibc 2.14?

Last time I've checked ARM for MMU-less CPUs had no support for glibc at all and was able to compile only tiny number of programs - usually old versions.

There are nothing wrong with playing with old/unusual hardware and software but it just makes no sense to worry about ARM for MMU compatibility when you develop libraries for modern Linux. Probably even less sense then trying to support Windows by default.

There is nothing wrong with use of the old version

Posted Nov 7, 2011 22:58 UTC (Mon) by jlokier (guest, #52227) [Link]

The GP comment seemed to imply that we should eliminate choice where it's no longer useful, and that NPTL is now good enough to be universal on Linux. Eventually I hope it is, there's no technical reason why it shouldn't be, but for the moment, there is still useful work being doing on Linux systems that NPTL doesn't yet support. That's all I wanted to point out.

No I haven't ported glibc. You wouldn't do that for a low-memory system (glibc is not small (but I look hopefully at eglibc)); uclibc is a better choice. I've built a Gentoo x86 system using uclibc in the past, so it's not impractical to use. There aren't a lot of glibc-isms in apps, and uclibc tries fairly hard to be compatible.

ARM with no MMU runs uclinux and uclibc, like anything with no MMU, and that's no too bad, there's quite a lot of software that builds on it.

There's only two real issues: No fork (affects fewer programs than you'd think), and no ELF shared objects, which is a bigger restriction as lots of things assume shared objects nowadays. Some no-MMU platforms do support ELF, and ARM could, but nobody's implemented it for ARM; I started, but had to move on. Almost everything else works the same as with MMU; file mmap is limited, but very few programs depend on it. And of course low memory, but that's not unique to no-MMU systems.

I accept the charge of unusual hardware, but just for some perspective: (a) count the number of home routers and set top boxes in the world; and (b) in the last 2 years I've worked for 4 different companies developing on no-MMU hardware, 3 of them ARM, and another architecture that I probably shouldn't name because it's not mainlined. Another no-MMU-only architecture got merged in Linux 3.1. It is niche, but it's still part of current Linux activity in the embedded universe, not limited to museum pieces. I would still strongly recommend choosing a chip with MMU if at all possible though, even for tiny systems :-)

Responding to "it just makes no sense to worry about ARM for MMU compatibility": Generally in a library, there's no need for specific "ARM-without-MMU" support. Assuming it works effortlessly on ARM (which it should these days), it would be just about the MMU, independent of CPU architecture. Which most things do fine, and a few need small changes.

I wouldn't be surprised if GNOME and Firefox worked with fewer changes than you'd expect on a no-MMU target (so long as it had ELF), even one still using LinuxThreads, if there was enough memory. But of course there isn't enough memory :-)

Well, people are free to do whatever they want with your library...

Posted Nov 8, 2011 7:23 UTC (Tue) by khim (subscriber, #9252) [Link]

Responding to "it just makes no sense to worry about ARM for MMU compatibility": Generally in a library, there's no need for specific "ARM-without-MMU" support. Assuming it works effortlessly on ARM (which it should these days), it would be just about the MMU, independent of CPU architecture. Which most things do fine, and a few need small changes.

That's fine. If your library is used on some exotic platform (be it Windows, VMS or ARM without MMU) then I see no problem with it. But if you start changing everything from the start to support them... that's another thing.