| |||||||||||||
LFCS: ARM, control groups, and the next 20 yearsLFCS: ARM, control groups, and the next 20 yearsPosted Apr 14, 2011 2:52 UTC (Thu) by elanthis (guest, #6227)In reply to: LFCS: ARM, control groups, and the next 20 years by patrick_g Parent article: LFCS: ARM, control groups, and the next 20 years
It's not particularly surprising. What is surprising is how the quantity-over-quality approach is so often praised by the Linux users.
One or two fantastic developers are worth 20 mediocre developers, and each of those mediocre developers is worth 100 idiot developers. (And the really bad developers are basically just negative worth and cancel out the value of better developers on the same team.)
Linux -- and much FOSS -- is praised for a many-eyes, scratch-an-itch approach to development. Anyone with real experience with software development knows better. A small, skilled team that has a focused set of real-world goals is going to accomplish much higher quality work than what a throng of "newbs" can pull off. Linux has a lot of skilled devs, but so does FreeBSD, and the masses of amateur Linux contributors just don't amount to much in comparison.
(Log in to post comments)
LFCS: ARM, control groups, and the next 20 years Posted Apr 14, 2011 6:56 UTC (Thu) by jthill (guest, #56558) [Link] People's skills change over time, mostly with growing experience. Where will the next batch of good devs come from, and where will they go?
LFCS: ARM, control groups, and the next 20 years Posted Apr 14, 2011 9:43 UTC (Thu) by error27 (subscriber, #8346) [Link]
Newbs don't really hurt anything. They do small easy to review patches. The negative quality code goes in staging. It either improves or it gets dropped.
You do see people learn as well. You reject their patches and they start breaking them up properly and writing better changelogs. It sounds stupid but it makes a big difference.
LFCS: ARM, control groups, and the next 20 years Posted Apr 15, 2011 21:02 UTC (Fri) by rilder (subscriber, #59804) [Link]
Comparison of FreeBSD of Linux is unfair in this context. You should in turn compare FreeBSD to distros which do a similar thing and they are doing a pretty good job there.
The 'numbers' that people point out wrt. FOSS needn't be just the core developers but it can also be testers, distro packagers, bug reporters, users. So more people scrutinizing the code will mean more eyes naturally. What FreeBSD lacks and Linux has is the concept of diverse distros from Gentoo,Exherbo to Ubuntu which will provide a whole spectrum of feedback to upstream developers. The feedback IMO is quite as important as other things.
People may be quick to point out the fragmentation this may have caused but a richer, diverse user/development base also contributes to richer products on long term, fittest stay and sustain (think of Genetic algorithms).
OTOH, FreeBSD which has been emphatically been pointed is *NOT* up to the mark in desktop, though they are quite good in servers. They still use a O(1) scheduler which Linux used eons back. A quick peek at their GSOc ideas page quickly reveals a stark difference between features in Linux and FreeBSD. I can point out specifics but don't want to since I love both and aware of their field of application.
"
LFCS: ARM, control groups, and the next 20 years Posted Apr 16, 2011 10:07 UTC (Sat) by WolfWings (subscriber, #56790) [Link]
[...] They still use a O(1) scheduler which Linux used eons back. [...]
And many of the largest users of Linux have forward-ported the O(1) scheduler *BACK* into Linux as of 2.6.26 at least, and some users are using the tree w/ the BrainFuck scheduler instead, which is another O(1) scheduler that works all the way up to 2.6.38 already.
http://lwn.net/Articles/357658/
http://ck.kolivas.org/patches/bfs/
So, just because the 'official' mainline Linux scheduler is no longer the 'old O(1) scheduler' doesn't mean that O(1) schedulers are dead, they're quite actively used, and many people prefer them to the recent attempts to add more brains to the scheduler. Much like trying to add filesystem-aware processing to hard drives, I don't think adding deeply program-aware tuning to schedulers without trusting the programs to tell the kernel about themselves will work, long-term.
LFCS: ARM, control groups, and the next 20 years Posted Apr 16, 2011 13:46 UTC (Sat) by corbet (editor, #1) [Link] Umm... the current CFS scheduler was written (as was Con's deadline scheduler before it) to get all of those interactivity heuristics out of the kernel. They are still mostly gone. Con's BFS (which is not an O(1) scheduler sticks with the fairness approach. Things have improved since the O(1) days.
LFCS: ARM, control groups, and the next 20 years Posted Apr 16, 2011 20:39 UTC (Sat) by rilder (subscriber, #59804) [Link]
I should have clarified better. I was not referring to any scheduler with complexity of O(1). I was specifically referring to scheduler predating current CFS in mainline. That scheduler was called O(1), and *no*, current BFS is not similar to that. One of most salient differences being, the history or any history distribution not being maintained by either BFS or CFS. FreeBSD, OTOH, still has a scheduler (ULE) with semantics predating back to that O(1) scheduler linux *had*. Check -- http://jeffr-tech.livejournal.com/24280.html -- for some interesting nitbits. Also, with regards to interactivity (which is what I was referring to earlier when i meant desktops), this scheduler is not up to the mark. There is also a proposal to "clean room" port BFS to FreeBSD among GSoC projects.
|
|||||||||||||