Because whoever won would be the president. So it could have been meant as something like "We are committed to making the process work to decide a winner". If you are arguing that his wording was bad, assuming he wanted to say that, then I agree 100%. It might have even meant that plus, I think Bush should/will be reelected (although that would go beyond mearly stupid).
Given he said those words in a public interview, I just can't see him having meant to say basically "We are committed to helping Ohio deliver it's votes for Bush".
Never attribute to malice, what can be explain by stupidity.
Lets ignore the fact that you have a former CEO, who resigned for allegations of corruption, and who was committed to "delivering" an election to one party.
Most of the rest seems fair, but I beleive the CEO said something like "Diebold is committed to delivering the election for the president". Which, I understand, could be read as "for the current president" but reading it as "for the future president, whoever that may be" seems much more likely, IMO.
I'm willing to bet that a dual-core processor will feel faster, largely because you'll be able to do things if one process gets bogged down due to disk or network waits.
But I doubt a four-core (or pair of dual-core) processors will feel much different.
For the admitedly, rarer cases, where you have two apps. go max-CPU at once (often they are talking to each other, or a single program with multiple tasks). I agree in general though, and needing to go from 4 to 8 seems much less likely though (atm.) and 80 is just so insanley high (again atm.).
and could be faster given the right workload (something multi-threaded that takes a dataset that can reside entirely in memory) [...] I remember playing with Concurrent Euclid back when I was an undergrad, and AFAIK we're still using locks, mutexes and signals to enable threads to play nice with each other.
You mean "multiple tasks". You do not need to apply a design constraint here. Oracle doesn't use threads, PostgreSQL doesn't use threads, postfix, vsftpd, samba, And-httpd, lighttpd and Apache-httpd (with MPM) all don't use threads. All of which can happily take advantage of multiple CPUs/cores.
While funny, it's actually more true of Linux distros.
I'd rather have the combined differences of the top 20 Linux distributions than between Linux and any of the BSDs. In the same vein the difference between any two linux distributions are almost always: 1) versions of the same upstream package. 2) preference of one upstream package over another (Ie. exim vs. postfix). The differences between any two of the BSDs are "same package name, different code/maintainers/development".
Writing a simple web server is trivial. It doesn't even need to be multi-threaded, though it wouldn't be difficult to make it serve multiple connections at once with select.
Speakling as someone who has written a web server (and guarantees that it's secure)... First, there is no such thing as a "simple web server". Even if you limit yourself to HTTP/1.0 and don't parse any headers, it's not a 3-4 hour problem. And you really need to parse at least Host: to even think about calling it a real webserver, and not just worthless junk.
Also, none of the good web servers are multi-threaded (RHCA doesn't really qualify as multi-threaded, as there are no processes in kernel land). So "doesn't even need" is very misleading IMNSHO.
Someone who can't write the code to parse out a GET request is pretty lame.
I assume you have this idea of what HTTP is that bears no resemblance to reality. Parsing the GET line well is non-trivial, parsing the GET line only doesn't qualify as a web server IMO.
Yes, I've seen something that firefox can talk to which is 1 line of C (roughly 12 if you put a return after each function call). While it's "cute" that's not a real webserver.
Aehm, N64 had the first true 3D jump'n run (Mario64)
While the controls were very nice (and I bought one, for that game), Tomb Raider had 3rd person 3d jump+run+fight a long time before the N64 (although, yes, it was the first console to do it).
Fortunately, most of my programming has been on modern operating systems such as Windows, where you can assume any system call is thread safe,
As does Linux, Solaris, etc. etc.... why you think gethostbyname() would be a system call I'm not sure. Extreme inexperience, comes to mind.
I guess it is no big deal, since gethostbyname has been deprecated since 1999 so it really doesn't matter
As the article said, gethostbyname() was used to prove a point (and taken directly from recent real life code). If you have a blocking call, a common "solution" is to create a thread for it... this is almost certainly the worst solution possible. Using a process is often faster (in both senses) and more reliable, in the long run.
strncpy() is thread-safe: You can call strncpy() in a reentrant fashion from as many threads as you wish. Now that is completely different from trying to strncpy() over the same memory area in multiple threads. Fortunately, the example code in the links doesn't do that.
And, again, you fail threading 101, strncpy() doesn't guarantee the order of assignment. So if you strncpy() to a destination from two threads, without locking, you can end up with any random permutation of either string. This also means that you can't read from a string and write a new value (also note that even if strncpy() had guaranteed order, you couldn't do that as there are no memory barriers and the inherent race condition that the writer can sleep). So, yes, strncpy() is "safe on the destination" to use on it's own, in threaded programs, as long as you never want to use the data it produces./dev/null is good that way too...
Of course, you're probably just ignoring/ignorant-of this and producing buggy crap... but, hey, it was "easy" to write and you didn't have to design anything... it crashes really fast too.
I'll ignore that total ignorance in your last paragraph.
Should the developer of an application that uses flat files, possibly because the app is designed to run on inexpensive shared web hosting that may not provide any DBMS, switch to SQL and have the users eat the higher price of hosting?
The main point for speed is to not constantly create tasks and switch between them to get some piece of work done, that will never make something go faster (basically compare doing work X, vs. work X plus switch/create time Y... the best thing isn't to have Y be low, but for Y to not exist at all).
You mean the technique called "preforking", where the master process starts a dozen worker processes in advance, right?
No, preforking is just moving around when Y happens. Think of it this way:
say you have 16 cores and get 32 "bits of work" a second to process... common "threaded designs" have you accept all 32 "bits of work" a second from one task, and put them on a queue. Then you have 16 other tasks, taking a "bit of work" doing it and then going back for another (or blocking, if there is none).
Here Y consists of, moving the cache for the data from the "accepting" task to the worker tasks (on a different core), all the syncronization for the queue and the task switch time (you have 17 tasks on 16 cores, so you have to switch). The average time for a bit of work to be processed is X (time to do work) + Y. There are many techniques people come up with for reducing Y, like saying you should use threads, an in memory queue and locks (instead of, say, processes and a pipe with a lock).
An explicit process design might well just have 16 processes, each "accepts a bit of work" (or block waiting) and then does it. Y is non-existant. Average time for a bit of work to be processed is just X.
Now, to be fair, you could implement the "process design" with threads. Although you'd still need locking on any global resources that the threads share, and you probably have random other locks that aren't required in this design but aren't easy to get rid of (think FILE *). And you don't have sixteen compartmentalized tasks, just one.
And, IMNSHO, you are just much less likely to get that result. The temptation to use threading almost implies not doing the design work upfront, on what needs to be shared and what doesn't, so you share everything and as you write code you add blocks where the sharing happens.
Without threads, how can one program take advantage of the multiple cores in a machine (dual CPU, dual core, hyperthreading)? If you use processes
You just answered your own question.
[If you use processes], there still has to be some sort of locking so that your multiple server processes don't step on each others' toes when manipulating shared state.
NO, there has to be some syncronization... that doesn't have to be "locks", in the sense you need them with threads.
With threads all resources are shared between tasks you are co-operating with, you cannot "trust" much to be "yours". So you need to sprinkle magic instructions places that say "I'm claiming this little bit so, assuming I always sprinkle the magic instruction in the right places, I'll be fine".
With a process, you are isolated from all the other tasks you are co-operating with, everything is yours apart from this little bit you desigate "to be used carefully, to communicate with others". That bit can even be implemented using shared memory and "locks", if you wish... but that isn't a requirement.
In many cases it's possible to share a very small amount of data between the tasks, and that can be passed around via. files/sockets/etc.
I didn't see anything about the startup and switching performance penalties for using processes on the 90 percent of installations that have slow processes but fast threads.
And if you are continuing to use DOS in 2006, I'm unlikely to care that you find it hard to write programs without memory protection. I assume you are talking about win32, as it's the only major OS that isn't basically Unix. However even then, as I understand it, it is possible to write applications as co-operating services (and context switch time, is not significant... although, yes, it's worse than Linux... but then so is the thread switch time).
The main point for speed is to not constantly create tasks and switch between them to get some piece of work done, that will never make something go faster (basically compare doing work X, vs. work X plus switch/create time Y... the best thing isn't to have Y be low, but for Y to not exist at all).
He then pretends that some system function is not-reentrant and not thread-safe, writes some intentionally bad naive threading code, then tells us the problems with it.
There is no pretending, the fact you are unaware of which system functions are "thread safe" and what that entails just proves the point.
The assumptions that the code runs under are >10 years out-of-date (a non-reentrant thread-unsafe version of strncpy!?!?).
You are confused, strncpy() is not thread-safe... never has been, never will. The problems outlined are identical to ones I've seen in real life within the last year. By "competant programers" who, like you, think that threaded programing is a solution worth pursuing (and who "request" that library functions make their life easier by destroying performance and reliability by taking locks everywhere -- which as the page says, doesn't actually help them much anyway).
And lastly, the author proposes no alternate solution!
Please read the page again, slowly, you might learn something this time through (the other links, esp. the one by Tridge are also sure to help you, if you actually read them).
Pay special attention to the parts about asynchronous interfaces and multi-tasking (using processes, with defined interfaces for communication). If you mean "a solution so that threaded program isn't slow and buggy", then no I can't help you and neither can anyone else.
Of course, you might just not have any idea what an event based design looks like, what an asynchronous interfaces looks like or how to design an IPC protocol so compartmentalized tasks can communicate, safely. In fact, given you seem to be arguing for threading, it's almost guaranteed.
Actually, it all depends on the workload. Some would say that Processes are a Unix hack, because they didn't think about threads.
Actually, not so much. Saying you "didn't think about threads" is like arguing that you went with protected multi-tasking OS and "didn't think about DOS". Adding memory protection and compartmentalisation is the only difference between a thread and a "process". In most cases, you just don't care anyway... all you want is to not block, and threads are the worst fix for that problem.
Power steering, anti-lock brakes, etc. are all seamless transitions from the "old" way, i.e. you do not have to learn how to drive a completely different way of driving to take advantage of them.
Not quite, in an emergency braking situation you are supposed to "pump" normal brakes... doing so with anti-lock brakes is bad.
You seem to not be reading the facts I'm trying to educate you with. PAM was reimplemented (Ie. what is in Linux didn't come from Sun). The slab memory allocator is in the Linux kernel, and again didn't come from Sun (AFAIK Sun have never contributed anything to the Linux kernel). Given that the "list" you did provide was inaccurate, I'm hardly inclined to assume "plus lots more" is the truth.
Sun has donated the following Netbeans, JXTA, Chunks of GNOME, NFS V3/RPC, Glassfish, Grid Engine, Chunks of Tomcat, Chunks of Mozilla, Chuncks of Apache, Cubic Spline, XFN, PAM, ZFS, DTRACE to name a small part of their largess
You originally said "more code in Red Hat than contributed by Red Hat", very few of the above are shipped by Red Hat. I guess some more bits are in Fedora, which you could incorrectly call Red Hat. I'm very suspicious of "NFS V3/RPC" given that the Linux code is almost all in Kernel, and thus. totally Sun free. Likewise I'm suspicious of PAM, because my understanding was that it was based on the idea from Sun but a complete re-inplementation.
So we're left with what: some GNOME, some Mozilla, some Apache-httpd and some Tomcat (and they are still pushing their proprietary Webserver/AS, even though it's worse in their own benchmarks). Paint me underwhelmed.
Let me soothe your concerns, in fact Sun without OpenSolaris dwarfs IBM in terms of OpenSource contributions, as has been pointed out on a number of occasions more code in RedHat was donated by Sun than any other commercial company IBM and RedHat included.
This excludes Sun's donations such as OpenOffice
With the OO.o code, they are probably in the running with IBM (I'm not entirely sure, eclipse was a big code drop) and maybe even Red Hat. But I don't believe they "dwarf" Red Hat even then, and they sure as hell don't come close without it. Red Hat has paid major GCC, glibc, binutils and linux-kernel contributors for _years_. It may have "been pointed out" by hopeful Sun people, but I don't see a link to some real data.
And... have you seen the glibc RPC code, I really wouldn't be boasting to anyone that I contributed it... even in it's post Sun mostly "fixed" state it's so bad you could easily assume they meant harm to others by giving it away.
Did you ever wonder why, if there are two products, one BSD or MIT licensed and one GPL licensed, and when the BSD or MIT licensed product is inferior, the BSD or MIT product has invariably won within two years?
Linux vs. FreeBSD, in many many ways FreeBSD was obviously better at earlier points. I think you'd be hard pressed to argue that FreeBSD "won".
wuftpd vs. vsftpd, wuftpd is a custom BSD like license (pretty common with "BSD")... again wuftpd failed and had decades unopposed.
Xt vs. gtk+, there's no way you can say Xt won and it also had decades unopposed.
bind and dhcpd, are OK examples... except they are basically still unopposed (you could argue that bind has a few very small competitors). It's hardly an example of your theoretical argument though (they were both unopposed for _many_ years, and had well funded maintainers -- and even then many people are still waiting for a good bind replacement).
I can take your becoming offensive as strong evidence that you indeed lied there.:-)
You called me a liar, without knowing anything about me... and presumably without even looking at my website. I'm pretty bored arguing with you, as you're just giving the party line of "Oh, that opinion's not really a problem... you just think it is, but you're wrong" combined with offensivly suggesting I'm just stupid for not realizing this on my own. So allow me to just say: Your opinion is wrong, you ignorant python fan boy.
None taken, python fan boys wishing reality were different is well documented.
People who actually use Python for REAL work, really tend to become fans of the significant whitespace.
See, you did it again.
Ofcourse copy&paste and reindent work. Just use the emacs python-mode shortcut
You mis-spelt "of course they don't work, you have to use this totally different editor feature", there you go wishing reality away again. I can see how you must get used to it after a while and forget you're doing it.
Huh? How many empty blocks do you have? What exactly are you writing?
How much longer is "pass" than "{}"? (hint, if you measure in keystrokes its even less)
if (0) {} else if (x) { } else if (y) { }
That's the most obvious use. It's also not so much about the keystrokes, as the meaning... {} is an empty block, pass is a workaround because blocks can't be empty... mentally everytime I do it instead of thinking I don't need to put anything in that block... I have to actively think "I need to put pass there, because there isn't an invisible block".
I don't nest my code in HTML, and I'm not sure why that would be a problem
It's a problem because whitespace is significant, and I'm not surprised you don't do it with python... because it sucks... due to the whitespace being significant thing. Sometimes this is very nice to do when you have much more html than code, and it works fine with every other language. Think about putting code in xml processing instructions, for example.
The SSI bit is basically an extension to this, you build a large xml/html document from many smaller ones (that, again, have code in them) this causes even bigger problems with python, because seperate blocks can magically merge together.
IT IS harder to read, you've removed the "ends block" visual marker. You can't easily line up the end of a block with the start of a block... you can argue that all blocks should fit on a screen, but this isn't true in the core python code.
This is simply untrue, and a silly claim.
NOBODY, and I mean NOBODY reads the {} when they read C/C++/Java code. Everybody reads the indentation, and only the indentation. The ONLY one who reads {} is the compiler.
Yes, welcome to python party line reality again. People don't "read" the syntax, but they _sure as hell_ parse it and use it as visual indicators -- which sane people regard as "reading" the source. Yes, it's possible to come up with corner cases where the visual clues (including the indentation) lie to the reader... but that _almost never happens in real life_ (and reindenting, note not running a special C only command, finds those problems 99.999% of times). Well done, python fixed a non-problem and "only" caused constant pain and misery in return.
Blocks larger than the screen are unreadable
I responded to this in my original post... core python code does not follow this rule, it's so obviously removed from reality I'm finding it hard to respond at all.
And that's a good thing (to not be able to break the indentation).
No, it's a limitation. Obviously you don't want to do it all the time, but being able to do it sometimes (for quick, short term, changes) is useful. It's like a knife that doesn't cut human skin... sure most of the time that's nice and useful (I'd happily enable indentation _warnings_ in GCC for example), but it _really sucks_ if you ever want to cut yo
Many of us Pythoneers have been there. Exactly where you are, bitching about the "whitespace".
Only after using it for a little while we understood that we can never go back.
When I first learnt python I assumed the whitespace thing would be no big deal, it's only after using it for a while that I saw how moronic it was.
There really is no real claim against significant whitespace except the knee-jerk reaction of ".. but.. but.. its just wrong!"
10 year old editor habits don't work anymore, Ie. copy & paste & reindent almost never "just works". This is with an editor (xemacs) that has a lot of python support.
it means you have to sprinkle "pass" warts everywhere, because it can't deal with empty blocks
writing code inside other languages (like html) is much harder
likewise getting code from multiple places is basically impossible (think html + SSI)
IT IS harder to read, you've removed the "ends block" visual marker. You can't easily line up the end of a block with the start of a block... you can argue that all blocks should fit on a screen, but this isn't true in the core python code.
You can't create blocks on their own (without doing if True: before it), all other languages allow this that I know of
You can't break the indentation rules for a 1 line patch to add an if statement.
and the fact that tab is treated as 8 spaces means it can look "right" to any sane human but still be wrong... have fun debugging that.
Read the book, see
the data. 1 in 1000 mutual funds beats the DOW over 10 years.
That's not what you said previously... you said over 10 years only one beat it every year (which is a very different metric). It is somewhat well known that a lot of managed funds do badly with regard to a pure index, mostly due to the funds fees, and I'd agree this is a good indication of what will happen to an average day trader. But there are good mutual funds that beat the indexes over 5, 10 and 15 years.
The first two provide a search bar in my panel (which I haven't used today), the third one provides a single analog clock (much like oclock, which takes "3516 1664")... eclipse was just started and is open at a blank page, as is openeoffice... evolution has been up a day and is in front of GBs of email.
The xemacs bit also shows the problem of garbage collection, the middle one is running gnus and is normally about the same size as the others... but earlier today I received some multi-MB pictures, and the GC didn't win.
Also note that eclipse has an edge over most other Java apps. I use due to actually being compiled to native code via. gcj.
When do the C/C++ people finally admit that Java has good performance, or is there going to be continuous goalpost-moving?:)
Err, when it's true (Ie. never)... it's sometimes deemed "acceptable" to have not-good performance, but that isn't the same thing.
It's not just strange- it's wrong. My job title at one point was "Systems Engineer". I didn't have an engineering degree, and my father (who did) was severely irked, rightfully so;
Go to Merriam-Webster and look up "journalism". Under "2B", you'll find "writing characterized by a direct presentation of facts or description of events without an attempt at interpretation". When anyone in the media talks about "journalism", that is the context they are referring to
That's fine then, using a strict interpretation of that I can happily say three things: 1) There are no (or almost no) journalists publishing on livejournal. 2) There are no (dito) journalists publishing on network TV. 3) There are no (dito) journalists publishing in any mainstream daily newspaper.
However back in the real world, people are using a definition of journalism that encompases a large portion of, at least, the later two points.
Having everything be an object, including files, would allow a file to be subclassed as some sort of metadata object for various uses.
Having a file be a persistent object, in this respect, would allow the file to be referenced through a different class or interface than may have been originally intended.
Inheritance == mount --bind. directories are implied by "files", thus it should be obvious how you have collections (== classes) of files (== methods). Private methods == no privilages.
As the saying goes, "Those who don't understand Unix are doomed to reinvent it, poorly."
Slashdot Mirror
Because whoever won would be the president. So it could have been meant as something like "We are committed to making the process work to decide a winner". If you are arguing that his wording was bad, assuming he wanted to say that, then I agree 100%. It might have even meant that plus, I think Bush should/will be reelected (although that would go beyond mearly stupid).
Given he said those words in a public interview, I just can't see him having meant to say basically "We are committed to helping Ohio deliver it's votes for Bush".
Never attribute to malice, what can be explain by stupidity.
Most of the rest seems fair, but I beleive the CEO said something like "Diebold is committed to delivering the election for the president". Which, I understand, could be read as "for the current president" but reading it as "for the future president, whoever that may be" seems much more likely, IMO.
For the admitedly, rarer cases, where you have two apps. go max-CPU at once (often they are talking to each other, or a single program with multiple tasks). I agree in general though, and needing to go from 4 to 8 seems much less likely though (atm.) and 80 is just so insanley high (again atm.).
You mean "multiple tasks". You do not need to apply a design constraint here. Oracle doesn't use threads, PostgreSQL doesn't use threads, postfix, vsftpd, samba, And-httpd, lighttpd and Apache-httpd (with MPM) all don't use threads. All of which can happily take advantage of multiple CPUs/cores.
I'd rather have the combined differences of the top 20 Linux distributions than between Linux and any of the BSDs. In the same vein the difference between any two linux distributions are almost always: 1) versions of the same upstream package. 2) preference of one upstream package over another (Ie. exim vs. postfix). The differences between any two of the BSDs are "same package name, different code/maintainers/development".
Speakling as someone who has written a web server (and guarantees that it's secure) ... First, there is no such thing as a "simple web server". Even if you limit yourself to HTTP/1.0 and don't parse any headers, it's not a 3-4 hour problem. And you really need to parse at least Host: to even think about calling it a real webserver, and not just worthless junk.
Also, none of the good web servers are multi-threaded (RHCA doesn't really qualify as multi-threaded, as there are no processes in kernel land). So "doesn't even need" is very misleading IMNSHO.
I assume you have this idea of what HTTP is that bears no resemblance to reality. Parsing the GET line well is non-trivial, parsing the GET line only doesn't qualify as a web server IMO.
Yes, I've seen something that firefox can talk to which is 1 line of C (roughly 12 if you put a return after each function call). While it's "cute" that's not a real webserver.
While the controls were very nice (and I bought one, for that game), Tomb Raider had 3rd person 3d jump+run+fight a long time before the N64 (although, yes, it was the first console to do it).
As does Linux, Solaris, etc. etc. ... why you think gethostbyname() would be a system call I'm not sure. Extreme inexperience, comes to mind.
As the article said, gethostbyname() was used to prove a point (and taken directly from recent real life code). If you have a blocking call, a common "solution" is to create a thread for it ... this is almost certainly the worst solution possible. Using a process is often faster (in both senses) and more reliable, in the long run.
And, again, you fail threading 101, strncpy() doesn't guarantee the order of assignment. So if you strncpy() to a destination from two threads, without locking, you can end up with any random permutation of either string. This also means that you can't read from a string and write a new value (also note that even if strncpy() had guaranteed order, you couldn't do that as there are no memory barriers and the inherent race condition that the writer can sleep). So, yes, strncpy() is "safe on the destination" to use on it's own, in threaded programs, as long as you never want to use the data it produces. /dev/null is good that way too ...
Of course, you're probably just ignoring/ignorant-of this and producing buggy crap ... but, hey, it was "easy" to write and you didn't have to design anything ... it crashes really fast too.
I'll ignore that total ignorance in your last paragraph.
I'd recommend SQL without an external DBMS.
No, preforking is just moving around when Y happens. Think of it this way:
say you have 16 cores and get 32 "bits of work" a second to process ... common "threaded designs" have you accept all 32 "bits of work" a second from one task, and put them on a queue. Then you have 16 other tasks, taking a "bit of work" doing it and then going back for another (or blocking, if there is none).
Here Y consists of, moving the cache for the data from the "accepting" task to the worker tasks (on a different core), all the syncronization for the queue and the task switch time (you have 17 tasks on 16 cores, so you have to switch). The average time for a bit of work to be processed is X (time to do work) + Y. There are many techniques people come up with for reducing Y, like saying you should use threads, an in memory queue and locks (instead of, say, processes and a pipe with a lock).
An explicit process design might well just have 16 processes, each "accepts a bit of work" (or block waiting) and then does it. Y is non-existant. Average time for a bit of work to be processed is just X.
Now, to be fair, you could implement the "process design" with threads. Although you'd still need locking on any global resources that the threads share, and you probably have random other locks that aren't required in this design but aren't easy to get rid of (think FILE *). And you don't have sixteen compartmentalized tasks, just one.
And, IMNSHO, you are just much less likely to get that result. The temptation to use threading almost implies not doing the design work upfront, on what needs to be shared and what doesn't, so you share everything and as you write code you add blocks where the sharing happens.
You just answered your own question.
NO, there has to be some syncronization ... that doesn't have to be "locks", in the sense you need them with threads.
With threads all resources are shared between tasks you are co-operating with, you cannot "trust" much to be "yours". So you need to sprinkle magic instructions places that say "I'm claiming this little bit so, assuming I always sprinkle the magic instruction in the right places, I'll be fine".
With a process, you are isolated from all the other tasks you are co-operating with, everything is yours apart from this little bit you desigate "to be used carefully, to communicate with others". That bit can even be implemented using shared memory and "locks", if you wish ... but that isn't a requirement.
In many cases it's possible to share a very small amount of data between the tasks, and that can be passed around via. files/sockets/etc.
And if you are continuing to use DOS in 2006, I'm unlikely to care that you find it hard to write programs without memory protection. I assume you are talking about win32, as it's the only major OS that isn't basically Unix. However even then, as I understand it, it is possible to write applications as co-operating services (and context switch time, is not significant ... although, yes, it's worse than Linux ... but then so is the thread switch time).
The main point for speed is to not constantly create tasks and switch between them to get some piece of work done, that will never make something go faster (basically compare doing work X, vs. work X plus switch/create time Y ... the best thing isn't to have Y be low, but for Y to not exist at all).
There is no pretending, the fact you are unaware of which system functions are "thread safe" and what that entails just proves the point.
You are confused, strncpy() is not thread-safe ... never has been, never will. The problems outlined are identical to ones I've seen in real life within the last year. By "competant programers" who, like you, think that threaded programing is a solution worth pursuing (and who "request" that library functions make their life easier by destroying performance and reliability by taking locks everywhere -- which as the page says, doesn't actually help them much anyway).
Please read the page again, slowly, you might learn something this time through (the other links, esp. the one by Tridge are also sure to help you, if you actually read them).
Pay special attention to the parts about asynchronous interfaces and multi-tasking (using processes, with defined interfaces for communication). If you mean "a solution so that threaded program isn't slow and buggy", then no I can't help you and neither can anyone else.
Of course, you might just not have any idea what an event based design looks like, what an asynchronous interfaces looks like or how to design an IPC protocol so compartmentalized tasks can communicate, safely. In fact, given you seem to be arguing for threading, it's almost guaranteed.
Actually, not so much. Saying you "didn't think about threads" is like arguing that you went with protected multi-tasking OS and "didn't think about DOS". Adding memory protection and compartmentalisation is the only difference between a thread and a "process". In most cases, you just don't care anyway ... all you want is to not block, and threads are the worst fix for that problem.
That's not true, it screws up the ABS systems analysis.
Not quite, in an emergency braking situation you are supposed to "pump" normal brakes ... doing so with anti-lock brakes is bad.
You seem to not be reading the facts I'm trying to educate you with. PAM was reimplemented (Ie. what is in Linux didn't come from Sun). The slab memory allocator is in the Linux kernel, and again didn't come from Sun (AFAIK Sun have never contributed anything to the Linux kernel). Given that the "list" you did provide was inaccurate, I'm hardly inclined to assume "plus lots more" is the truth.
You originally said "more code in Red Hat than contributed by Red Hat", very few of the above are shipped by Red Hat. I guess some more bits are in Fedora, which you could incorrectly call Red Hat. I'm very suspicious of "NFS V3/RPC" given that the Linux code is almost all in Kernel, and thus. totally Sun free. Likewise I'm suspicious of PAM, because my understanding was that it was based on the idea from Sun but a complete re-inplementation.
So we're left with what: some GNOME, some Mozilla, some Apache-httpd and some Tomcat (and they are still pushing their proprietary Webserver/AS, even though it's worse in their own benchmarks). Paint me underwhelmed.
With the OO.o code, they are probably in the running with IBM (I'm not entirely sure, eclipse was a big code drop) and maybe even Red Hat. But I don't believe they "dwarf" Red Hat even then, and they sure as hell don't come close without it. Red Hat has paid major GCC, glibc, binutils and linux-kernel contributors for _years_. It may have "been pointed out" by hopeful Sun people, but I don't see a link to some real data.
And ... have you seen the glibc RPC code, I really wouldn't be boasting to anyone that I contributed it ... even in it's post Sun mostly "fixed" state it's so bad you could easily assume they meant harm to others by giving it away.
Linux vs. FreeBSD, in many many ways FreeBSD was obviously better at earlier points. I think you'd be hard pressed to argue that FreeBSD "won".
wuftpd vs. vsftpd, wuftpd is a custom BSD like license (pretty common with "BSD") ... again wuftpd failed and had decades unopposed.
Xt vs. gtk+, there's no way you can say Xt won and it also had decades unopposed.
bind and dhcpd, are OK examples ... except they are basically still unopposed (you could argue that bind has a few very small competitors). It's hardly an example of your theoretical argument though (they were both unopposed for _many_ years, and had well funded maintainers -- and even then many people are still waiting for a good bind replacement).
You called me a liar, without knowing anything about me ... and presumably without even looking at my website. I'm pretty bored arguing with you, as you're just giving the party line of "Oh, that opinion's not really a problem ... you just think it is, but you're wrong" combined with offensivly suggesting I'm just stupid for not realizing this on my own. So allow me to just say: Your opinion is wrong, you ignorant python fan boy.
None taken, python fan boys wishing reality were different is well documented.
See, you did it again.
You mis-spelt "of course they don't work, you have to use this totally different editor feature", there you go wishing reality away again. I can see how you must get used to it after a while and forget you're doing it.
That's the most obvious use. It's also not so much about the keystrokes, as the meaning ... {} is an empty block, pass is a workaround because blocks can't be empty ... mentally everytime I do it instead of thinking I don't need to put anything in that block ... I have to actively think "I need to put pass there, because there isn't an invisible block".
It's a problem because whitespace is significant, and I'm not surprised you don't do it with python ... because it sucks ... due to the whitespace being significant thing. Sometimes this is very nice to do when you have much more html than code, and it works fine with every other language. Think about putting code in xml processing instructions, for example.
The SSI bit is basically an extension to this, you build a large xml/html document from many smaller ones (that, again, have code in them) this causes even bigger problems with python, because seperate blocks can magically merge together.
Yes, welcome to python party line reality again. People don't "read" the syntax, but they _sure as hell_ parse it and use it as visual indicators -- which sane people regard as "reading" the source. Yes, it's possible to come up with corner cases where the visual clues (including the indentation) lie to the reader ... but that _almost never happens in real life_ (and reindenting, note not running a special C only command, finds those problems 99.999% of times). Well done, python fixed a non-problem and "only" caused constant pain and misery in return.
I responded to this in my original post ... core python code does not follow this rule, it's so obviously removed from reality I'm finding it hard to respond at all.
No, it's a limitation. Obviously you don't want to do it all the time, but being able to do it sometimes (for quick, short term, changes) is useful. It's like a knife that doesn't cut human skin ... sure most of the time that's nice and useful (I'd happily enable indentation _warnings_ in GCC for example), but it _really sucks_ if you ever want to cut yo
When I first learnt python I assumed the whitespace thing would be no big deal, it's only after using it for a while that I saw how moronic it was.
That's not what you said previously ... you said over 10 years only one beat it every year (which is a very different metric). It is somewhat well known that a lot of managed funds do badly with regard to a pure index, mostly due to the funds fees, and I'd agree this is a good indication of what will happen to an average day trader. But there are good mutual funds that beat the indexes over 5, 10 and 15 years.
To be fair, they have a valid reason (even if we disagree) for ignoring other paritions in that sometimes people have them without knowing.
You don't think it's relevant that you compared performance against the one web server that explicitly doesn't care about performance?
The first two provide a search bar in my panel (which I haven't used today), the third one provides a single analog clock (much like oclock, which takes "3516 1664") ... eclipse was just started and is open at a blank page, as is openeoffice ... evolution has been up a day and is in front of GBs of email.
The xemacs bit also shows the problem of garbage collection, the middle one is running gnus and is normally about the same size as the others ... but earlier today I received some multi-MB pictures, and the GC didn't win.
Also note that eclipse has an edge over most other Java apps. I use due to actually being compiled to native code via. gcj.
Err, when it's true (Ie. never) ... it's sometimes deemed "acceptable" to have not-good performance, but that isn't the same thing.
That's fine then, using a strict interpretation of that I can happily say three things: 1) There are no (or almost no) journalists publishing on livejournal. 2) There are no (dito) journalists publishing on network TV. 3) There are no (dito) journalists publishing in any mainstream daily newspaper.
However back in the real world, people are using a definition of journalism that encompases a large portion of, at least, the later two points.
Inheritance == mount --bind. directories are implied by "files", thus it should be obvious how you have collections (== classes) of files (== methods). Private methods == no privilages.
As the saying goes, "Those who don't understand Unix are doomed to reinvent it, poorly."