I'm sad to see the vast number of different sound and video players available for Linux/Unix - xanim, aviplay, smpeg, xmms, mpg123 etc. All with a different set of supported encodings. When is someone going to do it ``The right way'', and define a codec interface for loadable modules. Then these codecs could easily be integrated into your favourite full-screen player, web browser etc. Futhermore, it would be impossible to provide all codecs open-source. With a standardized interface, commercial codec providers would have an easy job supplying codecs for the linux community.
We are shooting ourselves in the foot by reinventing this with every few weeks by providing a new player for your specific format.
Newly coined nonce words are often spelled with a hyphen, but the hyphen disappears when the words become widely used. For example,
people used to write ``non-zero'' and ``soft-ware'' instead of ``nonzero'' and ``software''; the same trend has occurred for hundreds of other
words. Thus it's high time for everybody to stop using the archaic spelling ``e-mail''. Think of how many keystrokes you will save in your
lifetime if you stop now! The form ``email'' has been well established in England for several years, so I am amazed to see Americans being
overly conservative in this regard. (Of course, ``email'' has been a familiar word in France much longer than in England --- but for an
entirely different reason.)
I have used all three of Perl, C/C++ and php3 for developing Web application and I don't really prefer one over another. I'd use Perl for simple, low-load scripts where text parsing is useful. I'd use php3 for database integration because it's so easy to integrate into html pages (without having to print("...") the entire page). Finally I'd use C and/or C++ for jobs where computation and complex algorithms are needed. For example, I'v recently written a rather complex calender script in C++ -- I wouldn't enjoy having to write the same thing in Perl.
Every human being who has taken just a few lessons in probability would know that a poll with no more than 150 participants is very likely to give an incorrect result. The probability that Zona simply picked more people that favors C/C++ that in the real world is simply far too big when the number of participants is this low.
The LinuxThreads library which has been included with glibc for at long time implements ONLY kernel-level threads using the clone() system call. However, as ``William Stalling'' points out in his book ``Operating Systems - Internal and Design Principles'', kernel-level threads and user-level threads each has their advantages.
Kernel-level threads can take advantage of multiple processors, but are quite expensive in process switching. User-levels, on the other hand, cannot take advantage of SMP machines because they exist in a single process with respect to the kernel, but are able to switch thread much faster because a context switch unnecessary.
This is also the reason who Java benchmarks so poorly on Linux boxes, because the most often seen tests are based on the performance with MANY threads. Linux is really poor when trying to create hundreds of threads.
My own experiements have shown that creating 8 threads using thread_create() can take a few seconds. On Solaris, which implements BOTH user-level and kernel-level threads, creating thousands of user-level threads take no time at all.
What I really would like is that someone would write a Solaris-similiar API for both user and kernel level threads. This would make it possible for application developers to choose (or even combine) the use of the two thread models for their specific purpose. The Solaris thread API allows the programmer to combine a number of user level thread into a kernel level thread which is scheduled by the kernel.
Would anyone care to take up this challenge?
Re:Please stop posting devel kernel releases.
on
Linux 2.3.2 Released
·
· Score: 1
I agree alot!!!! - I usually even know before I read it at slashdot anyway - from linux-kernel-announce@vger.
I currently developing some Web stuff for a small Internet Company. The manager of this company has made alot of website, but never used any thing but Microsoft Frontpage. Thus, he always talks HTM documents and not HTML documents, because MSFP default to the.htm extension even though.html would work. When i confronted him with it, he just said, "But if it works, i don't see the problem!". - Hmm... If we didn't have Microsoft, we'd have all these incompatibilities that other application have to be aware of. Follow the standards.
Slashdot Mirror
I'm sad to see the vast number of different sound and video players available for Linux/Unix - xanim, aviplay, smpeg, xmms, mpg123 etc. All with a different set of supported encodings. When is someone going to do it ``The right way'', and define a codec interface for loadable modules. Then these codecs could easily be integrated into your favourite full-screen player, web browser etc. Futhermore, it would be impossible to provide all codecs open-source. With a standardized interface, commercial codec providers would have an easy job supplying codecs for the linux community.
We are shooting ourselves in the foot by reinventing this with every few weeks by providing a new player for your specific format.
-- Donald E. Knuth (from here)
I have used all three of Perl, C/C++ and php3 for developing Web application and I don't really prefer one over another. I'd use Perl for simple, low-load scripts where text parsing is useful. I'd use php3 for database integration because it's so easy to integrate into html pages (without having to print("...") the entire page). Finally I'd use C and/or C++ for jobs where computation and complex algorithms are needed. For example, I'v recently written a rather complex calender script in C++ -- I wouldn't enjoy having to write the same thing in Perl.
Every human being who has taken just a few lessons in probability would know that a poll with no more than 150 participants is very likely to give an incorrect result. The probability that Zona simply picked more people that favors C/C++ that in the real world is simply far too big when the number of participants is this low.
Kernel-level threads can take advantage of multiple processors, but are quite expensive in process switching. User-levels, on the other hand, cannot take advantage of SMP machines because they exist in a single process with respect to the kernel, but are able to switch thread much faster because a context switch unnecessary.
This is also the reason who Java benchmarks so poorly on Linux boxes, because the most often seen tests are based on the performance with MANY threads. Linux is really poor when trying to create hundreds of threads.
My own experiements have shown that creating 8 threads using thread_create() can take a few seconds. On Solaris, which implements BOTH user-level and kernel-level threads, creating thousands of user-level threads take no time at all.
What I really would like is that someone would write a Solaris-similiar API for both user and kernel level threads. This would make it possible for application developers to choose (or even combine) the use of the two thread models for their specific purpose. The Solaris thread API allows the programmer to combine a number of user level thread into a kernel level thread which is scheduled by the kernel.
Would anyone care to take up this challenge?
I agree alot!!!! - I usually even know before I
read it at slashdot anyway - from linux-kernel-announce@vger.
I currently developing some Web stuff for a small Internet Company. The manager of this company has made alot of website, but never used any thing but Microsoft Frontpage. Thus, he always talks HTM documents and not HTML documents, because MSFP default to the .htm extension even though .html would work. When i confronted him with it, he just said, "But if it works, i don't see the problem!". - Hmm... If we didn't have Microsoft, we'd have all these incompatibilities that other application have to be aware of. Follow the standards.