I agree that the *nice* thing to do would be to allow any cars to be retrieved, even past deadline... but OTOH holding cars hostage is a very good way to put a little pressure on the people that might be undecided as whether or not to renew the license. ethics vs. business...
higher throughput can be achieved with one process or thread (whichever floats your boat) per CPU, using epoll() (linux 2.6 only, use poll() for more portability) with non-blocking I/O.
however, it's easier conceptually to write a threaded server, it's more natural to write, and you just launch a single thread per connection. unfortunately, currently, this doesn't scale (see Why Events Are A Bad Idea (for High-concurrency Servers) http://www.usenix.org/events/hotos03/tech/vonbehre n.html for an argument that thread implementations, and not their design, are the issue).
the former method can handle thousands of simultaneous connections with high throughput, even on a decent workstation; the latter cannot. threads simply have an inherent overhead that cannot be eliminated.
i've actually been working on writing a non-portable insanely fast httpd in my spare time (svn co svn://parseerror.dyndns.org/web/) over the past few weeks as a way to explore non-blocking I/O + epoll() and it performs very well (~600% faster conns/sec than a traditional fork()ing server (which i wrote first)).
The human *race* will survive just fine, by adapting to whatever happens, as we've done for a hundred thousand years... although usually when people ask this kind of question they are really asking "Can my way of life as I know it continue to be feasible?" or "What will things be like for future generations?"... If the world heats up, the ice caps melt and 95% of the land floods, then the Nepalese will repopulate it when the waters drop. If the world overcrowds and wars are waged over resouces, then some people will survive. If we see a worldwide pandemic that kills billions, those immune or unaffected will live on.
Humans are not in any danger of going extinct in the short term. Whether or not *you* or any of *your offspring* or *your way of life* survive whatever happens is another story.
If you have specific problems, fix them. If you have lots of legacy cruft that is not necessary, then trim it. If your code/revision management system is poor, then upgrade it and/or develop new procedures. If your code is hard to understand then perhaps you need to re-architect it and/or document it. Throwing away all the code and all the experience you have accumulated is the biggest mistake you can make.
If your problems do not directly relate to issues inherent in the language or its libraries then getting rid of it will not make your problems go away. The language is not the problem.
If you can have an amazing experience, we believe price is not a problem.
This reminds me of:
Duff Beer Owner: "Our customers enjoy the fine taste of Duff Beer rather than it's alcoolic content. Im predicting our new alcohol-free beer, Duff Zero, will sell even better than our previous products."
I'd argue that the 'Net is not being utilized to its potential as long as language acts as a barrier. Currently I have no hope of understanding anything written in a language other than English.
As for communicating with people in other countries -- every day on IRC.
imminent Audio pronunciation of "imminent" ( P ) Pronunciation Key (m-nnt) adj.
About to occur; impending: in imminent danger.
vs.
eminent Audio pronunciation of "eminent" ( P ) Pronunciation Key (m-nnt) adj.
1. Towering or standing out above others; prominent: an eminent peak.
2. Of high rank, station, or quality; noteworthy: eminent members of the community.
3. Outstanding, as in character or performance; distinguished: an eminent historian. See Synonyms at noted.
don't forget all the extra ads they show in the trailers! nothing like paying $26 for yourself and a date to eat some popcorn and watch ads! oh wait, this is/., forget the date...
I've considered this question before; one one hand I've got very much of a "right tool for the job" attitude... on the other hand within a company there is usually the need to move people between projects ocassionally or do code review.
Recently, I've run into an issue with wanting to work on a co-workers code... which was in C#. I've had some experience with C#, but it was a few years ago and I use C daily. Switching projects is tough enough, but switching syntax and more importantly *mindset* ended up taking too much time to justify for what I wanted, which was just to unofficially take a peek and help out a bit.
The decision depends greatly on the size of your company and your particular situation, of course. The larger your company is, the more standardizing on a language or languages makes sense. The fewer languages you use, the more flexible you will be to move between projects and to share common libraries.
I would suggest standardizing on a single language for all *major projects*, but don't force people to rewrite their shell scripts in Java:-P
Slashdot Mirror
Internal Server Error
so... not so well?
Robots don't have any emotions, and sometimes that makes me very sad. -- Bender
Yes, but can Michael Dell's dual Xenon 32GB RAM workstation run Windows Vista?
I agree that the *nice* thing to do would be to allow any cars to be retrieved, even past deadline... but OTOH holding cars hostage is a very good way to put a little pressure on the people that might be undecided as whether or not to renew the license. ethics vs. business...
that's about enough to pay a single competent developer full-time. or two (incompetent and/or young) ones.
check in your tuition.
READ: the average slashdotter will need 2.
however, it's easier conceptually to write a threaded server, it's more natural to write, and you just launch a single thread per connection. unfortunately, currently, this doesn't scale (see Why Events Are A Bad Idea (for High-concurrency Servers) http://www.usenix.org/events/hotos03/tech/vonbehre n.html for an argument that thread implementations, and not their design, are the issue).
the former method can handle thousands of simultaneous connections with high throughput, even on a decent workstation; the latter cannot. threads simply have an inherent overhead that cannot be eliminated.
i've actually been working on writing a non-portable insanely fast httpd in my spare time (svn co svn://parseerror.dyndns.org/web/) over the past few weeks as a way to explore non-blocking I/O + epoll() and it performs very well (~600% faster conns/sec than a traditional fork()ing server (which i wrote first)).
for further discussion see The C10K Problem http://www.kegel.com/c10k.html which goes in-depth on these very subjects
The human *race* will survive just fine, by adapting to whatever happens, as we've done for a hundred thousand years... although usually when people ask this kind of question they are really asking "Can my way of life as I know it continue to be feasible?" or "What will things be like for future generations?"... If the world heats up, the ice caps melt and 95% of the land floods, then the Nepalese will repopulate it when the waters drop. If the world overcrowds and wars are waged over resouces, then some people will survive. If we see a worldwide pandemic that kills billions, those immune or unaffected will live on.
Humans are not in any danger of going extinct in the short term. Whether or not *you* or any of *your offspring* or *your way of life* survive whatever happens is another story.
I believe the parent was assuming Linux-centric viewpoint (welcome to Slashdot); though the AVR chips are fun :)
agreed. password prompts do not a secure system make.
If you have specific problems, fix them. If you have lots of legacy cruft that is not necessary, then trim it. If your code/revision management system is poor, then upgrade it and/or develop new procedures. If your code is hard to understand then perhaps you need to re-architect it and/or document it. Throwing away all the code and all the experience you have accumulated is the biggest mistake you can make. If your problems do not directly relate to issues inherent in the language or its libraries then getting rid of it will not make your problems go away. The language is not the problem.
This reminds me of:
they're screwed.
"Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety."
But where will they put the porn?!1
As for communicating with people in other countries -- every day on IRC.
imminent Audio pronunciation of "imminent" ( P ) Pronunciation Key (m-nnt)
adj.
About to occur; impending: in imminent danger.
vs.
eminent Audio pronunciation of "eminent" ( P ) Pronunciation Key (m-nnt)
adj.
1. Towering or standing out above others; prominent: an eminent peak.
2. Of high rank, station, or quality; noteworthy: eminent members of the community.
3. Outstanding, as in character or performance; distinguished: an eminent historian. See Synonyms at noted.
Life is hilariously cruel.
don't forget all the extra ads they show in the trailers! nothing like paying $26 for yourself and a date to eat some popcorn and watch ads! oh wait, this is /., forget the date...
move there.
The first rule of online suicide club is...
I've considered this question before; one one hand I've got very much of a "right tool for the job" attitude... on the other hand within a company there is usually the need to move people between projects ocassionally or do code review.
:-P
Recently, I've run into an issue with wanting to work on a co-workers code... which was in C#. I've had some experience with C#, but it was a few years ago and I use C daily. Switching projects is tough enough, but switching syntax and more importantly *mindset* ended up taking too much time to justify for what I wanted, which was just to unofficially take a peek and help out a bit.
The decision depends greatly on the size of your company and your particular situation, of course. The larger your company is, the more standardizing on a language or languages makes sense. The fewer languages you use, the more flexible you will be to move between projects and to share common libraries.
I would suggest standardizing on a single language for all *major projects*, but don't force people to rewrite their shell scripts in Java
You can save on water and power by not showering regularly.... but I think that's a given.
What, you've never heard of stone tablets? They last FOREVER, but the write latency is a killer.
Agreed. No one seems to want to stand up to the Chinese government because of all the money to be made.