| |||||||||||||
libabc: a demonstration library for kernel developerslibabc: a demonstration library for kernel developersPosted Nov 3, 2011 4:21 UTC (Thu) by RCL (guest, #63264)In reply to: libabc: a demonstration library for kernel developers by andresfreund Parent article: libabc: a demonstration library for kernel developers
No, it's not just you. Lennart is a member of open source ego-maniac elite who always speak as if they knew better than anyone else. Compare Greg K-H, Drepper, Linus (sometimes), de Raadt etc
(Log in to post comments)
libabc: a demonstration library for kernel developers Posted Nov 3, 2011 4:43 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
the issue isn't how they talk initially, it's how they react to people disagreeing with them
libabc: a demonstration library for kernel developers Posted Nov 4, 2011 0:38 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> Lennart is a member of open source ego-maniac elite who always speak as if they knew better than anyone else.
Yeah, and guess what? More often than not, he *does* know better than most other people. Which is why many distros ship with pulseaudio today and most will ship with systemd at some point (well, except for Ubuntu because of NIH syndrome).
libabc: a demonstration library for kernel developers Posted Nov 4, 2011 15:41 UTC (Fri) by alankila (subscriber, #47141) [Link]
I agree. I have utmost respect for the fact that Poettering is one of the few people who are trying to do global optimization of the linux system stack. If we had a few more people more like him, I think we'd make serious progress towards making it easier to write good applications on Linux.
I'm impressed by the fact that a lot of people are starting to realize that choice is not good but in fact very bad. And that forcing people to do things in a particular way has benefits. It might be that eventually a new mindset takes root which is less interested in things like "unix philosophy" and cares more about "how can we make it easier for mere mortals to write kick-ass applications".
It is necessary to design the system software stack well once. I think pulseaudio is excellent piece of engineering from programmer's point of view, as the simple API is simple indeed. I only wish someone took the time to add all sorts of nice goodies to it like windows 7 type audio effects and global equalizer and things like that. I have shit like that written for cyanogenmod, but integrating it into PA makes my head hurt for various reasons. However, because PA is in principle capable of doing this kind of stuff, it'd be lovely to show it off as evidence that you get interesting new features that you did not have before when running that daemon.
libabc: a demonstration library for kernel developers Posted Nov 4, 2011 15:41 UTC (Fri) by alankila (subscriber, #47141) [Link]
Apologies. When _not_ running that daemon, of course.
libabc: a demonstration library for kernel developers Posted Nov 4, 2011 23:52 UTC (Fri) by cmccabe (guest, #60281) [Link]
I'm pretty sure that Lennart would disagree with you about your dislike of UNIX philosophy.
Apps are fun, but let's not forget that most Linux systems that exist now in 2011 are either embedded devices or servers, and have little use for them. Linux is flexibile enough to be adapted to the biggest and the smallest systems precisely because we do not "force people to do things a particular way."
libabc: a demonstration library for kernel developers Posted Nov 5, 2011 1:07 UTC (Sat) by alankila (subscriber, #47141) [Link]
I don't dislike unix philosophy. I'm just saying that it's irrelevant. Results matter, especially those that make linux appealing to the 99 % of people who apparently do not use it yet.
libabc: a demonstration library for kernel developers Posted Nov 5, 2011 0:13 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
if you think choice is bad, go use an apple where you have no choice.
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.
without the ability to choose and have multiple options, none of these things that are claiming that the ability to choose is a bad thing would be allowed to start with.
It's not the question of if, it's question when Posted Nov 5, 2011 0:55 UTC (Sat) by khim (subscriber, #9252) [Link] 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.
It's not the question of if, it's question when Posted Nov 6, 2011 20:54 UTC (Sun) by jlokier (guest, #52227) [Link]
Fyi, on some architectures (e.g. ARM without MMU) we're still using LinuxThreads because NPTL isn't ported to them.
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.
libabc: a demonstration library for kernel developers Posted Nov 5, 2011 1:13 UTC (Sat) by alankila (subscriber, #47141) [Link]
I'm already an OS X user. And I think it does a whole lot of things so much better that transition from linux to OS X has been painless. After adding macports and some bunch of open source software, the practical differences are:
1) ready availability of development environments like xcode or flash studio;
|
|||||||||||||