Sounds like blabbering to me :) Well.. programming is hard for programmers who don't think for a moment, plan and design before diving into coding, as it is life is hard for people who live their life with no sort of plan at all :)
my 2 cents worth... -- Xander R. Solis ----------------------- "Trust is the greatest gift one person can give another" GNUPG Key: 1024D/525 On Sat Jul 24 23:37 , Andy Sy <[EMAIL PROTECTED]> sent: >More whining re glibc from > >http://www.tenslashsix.com/index.php (2004-06-30 blog entry) > >"The fact of the matter is this is a result of basically one >thing: glibc folks deciding that releases arent worth while >and that distros should just take snapshots at their leisure. >People talk about linux not being a good target becomes its >hard to target, compared to win32, and they couldnt be more >right. We cant even get a LIBC that is f*cking standard across >each distros because the glibc authors cant be bothered to >do releases. Ive heard that they will be back to making releases >again soon. I can only hope this is the case. Regardless the >big guys are gonna have a patched to h*ll glibc, so its not >like its gonna matter." > > >But here's the question, why can't fork(), which makes use >of the same clone() system call that NPTL ultimately >does, not be able to scale up just as dramatically as >the much-hyped, yet maddeningly unavailable, NPTL. After >all: > >1. It is not the /RedHat-hostaged/ glibc's pthreads implementation > that is giving us these threads by the tens of thousands > scalability, it's the *kernel* (as in Linux and not GNU), correct? > Pthreads' API is generally seen as being as horrible and full of > compromises anyway. See > http://www-124.ibm.com/pthreads/ and digest the discussion at > http://www.kerneltraffic.org/kernel-traffic/kt20000911_84.html#1 > >2. "Threads are evil." http://threading.2038bug.com/index.html > >3. Normal processes on Linux are far less heavyweight > vis-a-vis threads as they were on Unix. From > http://www-106.ibm.com/developerworks/library/l-sc5.html : > > "In many, many situations, the best way to multi-task an > application is to decompose it into collaborating /processes/ > rather than /threads/. Programmers commonly resist this reality. > One reason is history: processes used to be far "heavier" than > threads, and, under most flavors of Windows, still are. With modern > Linux, though, a context switch between distinct processes might > take only 15% more time than the corresponding context switch between > same-process threads. What you gain for that cost in time is a *far > better understood and more robust programming model*. Many > programmers can safely write independent processes. Relatively few > are safe with threads." > > >-- >reply to: a n d y @ n e t f x p h . c o m > > > > >-- >Philippine Linux Users' Group (PLUG) Mailing List >[EMAIL PROTECTED] (#PLUG @ irc.free.net.ph) >Official Website: http://plug.linux.org.ph >Searchable Archives: http://marc.free.net.ph >. >To leave, go to http://lists.q-linux.com/mailman/listinfo/plug >. >Are you a Linux newbie? To join the newbie list, go to >http://lists.q-linux.com/mailman/listinfo/ph-linux-newbie ---- Introducing Spymac MailPro: http://www.spymac.com/ -- Philippine Linux Users' Group (PLUG) Mailing List [EMAIL PROTECTED] (#PLUG @ irc.free.net.ph) Official Website: http://plug.linux.org.ph Searchable Archives: http://marc.free.net.ph . To leave, go to http://lists.q-linux.com/mailman/listinfo/plug . Are you a Linux newbie? To join the newbie list, go to http://lists.q-linux.com/mailman/listinfo/ph-linux-newbie
