I am a boss. I hire people. It doesn't matter to me. In this case, if I knew the NDA was particularly draconian as this one appears, I would probably favor the person who recognizes the fault and attempts to have it corrected. There is nothing wrong with it. After all, if you don't stand up for yourself nobody else will.
Re:Screw making coffee, that's what baristas are f
on
Which Instant Coffee?
·
· Score: 1
It's been my experience that most of the people who work at Starbucks do not understand the barista lingo. Also, you might want to confirm the normal dosage of shots in the Venti. I believe it is two, not three.
My venti quad white mocha gets me charged for two extra shots.
The way I understand it, the P4 pipeline isn't 100% utilized very often. Often there are gaps between instructions. Those gaps add up quickly and can get expensive since no instructions are being sent where one could have been.
HT is an attempt to fill those wasted gaps with useful instructions. Does it work? Maybe. I could also be completely wrong with this post.
If you enable HT, you are cutting your L3 cache in half per "processor." So your 2.5Ghz Xeon with 512k cache turns into two 2.5ghz chips with 256k each.
We have deployed a few 6650s here, these are Quad Xeons with 1 meg of cache, and it's amazing to look at top reporting 8 procs. But it didn't take long before we saw the same thing you have.
But it depends on your usage patterns too. If you're serving a lot of small requests - that run very quickly - HT may not be a bad idea. OTOH, running fewer and larger requests would certainly benefit from disabling HT.
The reason is that database servers can take advantage of large cache sizes more than most apps. They can move a lot of the dataset near the proc and cut down on query times dramatically. Less cache, more RAM accesses, slower queries.
About a year ago Dell was recommending that HT be disabled for better performance. Not sure if that is still the case today.
(and it is quite possible to have a 100% legal music library that goes beyond 100MB. its just probably not terribly common.)
It's quite common I'd think. I have 2 gigs of OGGs sitting here, made up of 41 CDs, which are also sitting within 2 feet of me at this moment. I own them all.
Actually, it wouldn't. The URL Translator only maps URLs to system filenames. Basically, it just tells Apache where the CGI is and does not impact how Apache will execute the CGI. The script will still execute in a seperate process.
First, the biggest problem with having so many virtual hosts is the file handle utilization. This is mostly caused by having seperate logs for each host (a custom access log and an error log.) After 300 hosts you'll start adding ulimit lines to your apache startup scripts. And that's ugly. You can prevent this one by defining no log entries on your vhost configs and using a global config. Write a script to parse out the logs for each domain at the end of the day or whatever.
Have you considered an SSL accelerator? They really do work. All HTTPS requests are handled on that box making the requests themselves normal HTTP on your webserver. No need for SSL support on your web server AT ALL. I cannot tell you how handy these things are. I'm sure you can find one that can fill your needs. Ours has handled 500 concurrent connections before.
Another thing you might consider, although I'm not sure how it would work in your situation, do not define any VirtualHost entries at all. A global mod_perl URL translator handler could do all of that work for you.
Let's say, for example, that you host www.example.com. Your URI Translator will look at the requested domain name and set the requested filename to/home/users/example.com/www.example.com/html (or whatever you're using.)
If that works for you, you'll never have to restart apache again. Instead, just adding users to the directory structure will make the websites available.
Pound is awesome but it has a few very serious problems:
1) Memory leaks - in our environment pound leaked memory like a siv. I had a cron job that restarted it daily it was so bad. In Pound's defense, this may have been a leak in the openssl libs.
2) Compatibility - Older versions of pound had very serious problems with some browsers. We had many clients that should not access the secure website. You had to upgrade to the pound-current tarball to fix it, which probably introduced the memory leak mentioned above.:)
3) It is slow - I hadn't noticed how slow it was until we replaced it.
4) Pound does not scale well when used as a load balancer. We couldn't get it to handle more than 100 concurrent connections. This may have been a hardware limitation (was not a dual proc, had only 1 gig of ram.)
We replaced pound with an Intel SSL accelerator and haven't looked back. It rocks.
That would be bad, if they were actually lying. Fact is, regular users really don't need a 64bit proc. Frankly, regular users don't need a 3.5Ghz P4 either.
This is one of those times where being right doesn't make you right (or something like that.) Market pressure has forced Intel's hand here. Shareholders are looking at what AMD is doing and Intel is getting a browbeating for having nothing to strike back with.
However, unless the major player in IM implements the protocol, this standard importance is not very high.
Actually, this isn't really true. ICQ/AOL, MSN and Yahoo all have a different protocol but products like Trillian can use Jabber as a generic protocol to layer on top of these proprietary protocols.
Not that I think it will happen, but with Jabber being a standard you'd think these smaller IM players could join together. Or at least link together.
You don't need to compare East vs West to see this cultural divide. We have this all over the US too. Many have already mentioned the differences between West Coast and East Coast but also look at North vs South.
The rank / trust system was very common throughout this entire country before the 60's. It's still prevalent in the deep South today.
I wonder if this behavior is in any way related to family upbringing? Those in more rigid and structure households (where everyone has a role and is depended on to fill that role) are more likely to trust their superiors in a professional environment. This theory could be supported by recruiting statistics, by region, of the US Armed Forces.
On the flip side - those with a loose family structure, where each member is more independent, are more likely to distrust.
a lot of war is already like a video game, and killing is so much easier when you don't have to look at your enemies face when you kill him and his family
You have a good point, land-based long range missles take a lot of the human factor out. But I think you're missing the real point. They're purpose is just as much about protecting our troops as is it inflicting damage. One way or another we're going to strike - so would you rather do it safely? I would. And if you were a member of the US Armed Forces you would too.
You would do better to complain about the accuracy of the weapon instead of it's destructive power. (That being said, these weapons have amazing accuracy.)
There doesn't seem to be that much to find on Venus! How about Mars? Let's see... lot's of rocks, red sand and lots of guesses.
Mars may be interesting because it would be the best inner-system planet to colonize but it's not very likely to happen. Look at what happened with the moon. We went there and haven't been back in nearly 30 years. How would a Mars expedition be any different? Well, we probably wouldn't return 5 times.
I don't want to discount Mars. Anytime we land there it's an amazing accomplishment and great kudos to the guys that make it happen. But to say that Venus is less interesting is quite foolish. In fact, due to the environment extremes, I'd say we're more likely to discover something REALLY interesting there.
You're not supposed to. In-game advertising is all about Branding. No, NBA 2004 doesn't make you want that new pair of Nike Pumps but next time you're in a Foot Locker the brand will stick out more.
If done right, advertisments in a game can add to the realism. GTA3 wouldn't have been so real if they didn't play Pogo The Monkey ads on the radio occasionally.
Need for Speed Underground (an excellent game btw) has TONS of stickers representing REAL brands you can decorate your car with. This is not a bad thing. It makes the game more real. And hey, if I'm looking for neon next time I'll know some brands to look for. Great for me.
I went to a real engineering school to learn Computer Engineering (a 4 year EEE + CS program), and every time I see a company create a certification program that takes less than a month to become an "engineer", well... it makes me cringe.
That's funny, I get the same feeling when I hear people claim that their 4 year degree makes them an engineer. Last I checked you need to know the math and also be able to apply it. (It's that last part that university cannot teach.)
Anyone else find it interesting that Intel is working on x86-64 code? Or am I reading too much into this...
len.brown:intel.com:
o [ACPI] fix x86_64 build errors
o [ACPI] fix x86_64 !CONFIG_ACPI build
o 2.4.23 build x86_64 build fixes
o x86_64 build fix from previous cset
o [ACPI] sync some i386 ACPI build fixes into x86_64 to fix !CONFIG_ACPI build
(Note some non-x86-64 changes omited from excerpt)
Regardless of how many rounds per second you gun can fire, the delay between each shot is also magnified in the sphere of effect.
So - if bullet-time runs at 1/100th of real-time that 0.01/second delay between rounds turns into one full second when the second round enters the SOE.
That being said, if the bullet-time SOE just slows things down then I will be extremely disappointed. The entire concept of bullet-time and the (IMO) related slow-motion fighting effects was to convey the speed of the characters involved. Max Payne almost got this right with it's Bullet Time implementation (you could aim at normal speed but you couldn't actually move faster)
A perfect implementation would allow for different time ratios for everyone in the system. Higher-level players would move insanely fast to low-level players because their time ratios were different. You wouldn't need SOE at all really, but while time-compression can be easily implemented in a computer it's the inverse that is impossible. In a MMORPG anyway.
Honestly, I don't remember the specs but why bog down the AGP bus when you have a perfectly good PCI-X bus for the HD broadcast? PCI/PCI-X/AGP tend to run on seperate bus so I'd think this would be cleaner / faster than the All-In-One approach.
Also, and this might be different with HDTV, but the quality of recordings from one of those ATI TV cards aren't all that great. One would think a dedicated card could do a better job. ATI just slaps these things on as an afterthought almost.
Java's main strength was supposed to be platform independence. However, due to missteps by Sun and backstabbing by Microsoft, Java has been relegated to the back-end of a web page, running under Unix. In this client-server architecture, speed is crucial, and Javas bytecode doesn't cut it.
Although I would argue that Java's OO implementation is also it's main strength, but platform independence is also a big deal.
Microsoft's antics only really prevent Java Applets from becoming a much bigger thing than they are today. In any other client-side Java deployment you can be sure the JRE ships with the app, is installed on the client machine by the sys-admin (corporate environment) or the installer handles JRE installation for you.
If you truly believe that Java isn't platform independent, go look at any of the numerous Java Apps that have been written. Notice how they run on Windows, Mac, Linux and Solaris? That's not a typo. Here is one if you're too lazy to look yourself.
Native binaries are the only way to get the speed necessary in the post-.com days
This is also wrong. One need only look at the rapid proliferation of languages such as Perl, PHP, Python and (duh) Java as evidence. Asm/C/C++ have their uses - but to use them for everything should get you fired.
Fortunately, Linux is FREE (as in herpes and porn)and makes commodity hardware perform as well as enterprise offerings from Dell, Compaq, IBM, etc.
Linux is an operating system - Java is a programming language. What are you trying to compare? Funny thing is, the Linux and Windows JREs are usually ahead of the solaris JRE - because more java users use... well, Linux and Windows.
Furthermore, all major unices (AIX, SCO, *BSD, HPUX, Solaris, etc) include linux binary support, so linux binaries are more platform independent than Java is.
Wonderful - so your app will run on all these different flavors of UNIX... just slower. Where as the JRE was built for the OS and does not need the same kind of translation. On top of that, it can take advantage of OS features a Linux binary may not be able to.
Oh yeah - and Java runs on all those platforms plus Windows. So by sheer numbers Java is more platform independent.
Slashdot Mirror
I am a boss. I hire people. It doesn't matter to me. In this case, if I knew the NDA was particularly draconian as this one appears, I would probably favor the person who recognizes the fault and attempts to have it corrected. There is nothing wrong with it. After all, if you don't stand up for yourself nobody else will.
It's been my experience that most of the people who work at Starbucks do not understand the barista lingo. Also, you might want to confirm the normal dosage of shots in the Venti. I believe it is two, not three.
My venti quad white mocha gets me charged for two extra shots.
The way I understand it, the P4 pipeline isn't 100% utilized very often. Often there are gaps between instructions. Those gaps add up quickly and can get expensive since no instructions are being sent where one could have been.
HT is an attempt to fill those wasted gaps with useful instructions. Does it work? Maybe. I could also be completely wrong with this post.
If you enable HT, you are cutting your L3 cache in half per "processor." So your 2.5Ghz Xeon with 512k cache turns into two 2.5ghz chips with 256k each.
We have deployed a few 6650s here, these are Quad Xeons with 1 meg of cache, and it's amazing to look at top reporting 8 procs. But it didn't take long before we saw the same thing you have.
But it depends on your usage patterns too. If you're serving a lot of small requests - that run very quickly - HT may not be a bad idea. OTOH, running fewer and larger requests would certainly benefit from disabling HT.
The reason is that database servers can take advantage of large cache sizes more than most apps. They can move a lot of the dataset near the proc and cut down on query times dramatically. Less cache, more RAM accesses, slower queries.
About a year ago Dell was recommending that HT be disabled for better performance. Not sure if that is still the case today.
Cases are like women... push hard enough and they'll take a big screw in any hole.
(and it is quite possible to have a 100% legal music library that goes beyond 100MB. its just probably not terribly common.)
It's quite common I'd think. I have 2 gigs of OGGs sitting here, made up of 41 CDs, which are also sitting within 2 feet of me at this moment. I own them all.
100MB? Pish.
RedHat's ES/AS kernels include the scheduler and VM enhancments from 2.6.
Actually, it wouldn't. The URL Translator only maps URLs to system filenames. Basically, it just tells Apache where the CGI is and does not impact how Apache will execute the CGI. The script will still execute in a seperate process.
First, the biggest problem with having so many virtual hosts is the file handle utilization. This is mostly caused by having seperate logs for each host (a custom access log and an error log.) After 300 hosts you'll start adding ulimit lines to your apache startup scripts. And that's ugly. You can prevent this one by defining no log entries on your vhost configs and using a global config. Write a script to parse out the logs for each domain at the end of the day or whatever.
/home/users/example.com/www.example.com/html (or whatever you're using.)
Have you considered an SSL accelerator? They really do work. All HTTPS requests are handled on that box making the requests themselves normal HTTP on your webserver. No need for SSL support on your web server AT ALL. I cannot tell you how handy these things are. I'm sure you can find one that can fill your needs. Ours has handled 500 concurrent connections before.
Another thing you might consider, although I'm not sure how it would work in your situation, do not define any VirtualHost entries at all. A global mod_perl URL translator handler could do all of that work for you.
Let's say, for example, that you host www.example.com. Your URI Translator will look at the requested domain name and set the requested filename to
If that works for you, you'll never have to restart apache again. Instead, just adding users to the directory structure will make the websites available.
Pound is awesome but it has a few very serious problems:
:)
1) Memory leaks - in our environment pound leaked memory like a siv. I had a cron job that restarted it daily it was so bad. In Pound's defense, this may have been a leak in the openssl libs.
2) Compatibility - Older versions of pound had very serious problems with some browsers. We had many clients that should not access the secure website. You had to upgrade to the pound-current tarball to fix it, which probably introduced the memory leak mentioned above.
3) It is slow - I hadn't noticed how slow it was until we replaced it.
4) Pound does not scale well when used as a load balancer. We couldn't get it to handle more than 100 concurrent connections. This may have been a hardware limitation (was not a dual proc, had only 1 gig of ram.)
We replaced pound with an Intel SSL accelerator and haven't looked back. It rocks.
When a parent talks about their kid being "healthy" it can sometimes mean "porkchop." Funny how that works.
That would be bad, if they were actually lying. Fact is, regular users really don't need a 64bit proc. Frankly, regular users don't need a 3.5Ghz P4 either.
This is one of those times where being right doesn't make you right (or something like that.) Market pressure has forced Intel's hand here. Shareholders are looking at what AMD is doing and Intel is getting a browbeating for having nothing to strike back with.
However, unless the major player in IM implements the protocol, this standard importance is not very high.
Actually, this isn't really true. ICQ/AOL, MSN and Yahoo all have a different protocol but products like Trillian can use Jabber as a generic protocol to layer on top of these proprietary protocols.
Not that I think it will happen, but with Jabber being a standard you'd think these smaller IM players could join together. Or at least link together.
You don't need to compare East vs West to see this cultural divide. We have this all over the US too. Many have already mentioned the differences between West Coast and East Coast but also look at North vs South.
The rank / trust system was very common throughout this entire country before the 60's. It's still prevalent in the deep South today.
I wonder if this behavior is in any way related to family upbringing? Those in more rigid and structure households (where everyone has a role and is depended on to fill that role) are more likely to trust their superiors in a professional environment. This theory could be supported by recruiting statistics, by region, of the US Armed Forces.
On the flip side - those with a loose family structure, where each member is more independent, are more likely to distrust.
a lot of war is already like a video game, and killing is so much easier when you don't have to look at your enemies face when you kill him and his family
Funny, I bet the 156,000 troops in Iraq would have a different opinion.
You have a good point, land-based long range missles take a lot of the human factor out. But I think you're missing the real point. They're purpose is just as much about protecting our troops as is it inflicting damage. One way or another we're going to strike - so would you rather do it safely? I would. And if you were a member of the US Armed Forces you would too.
You would do better to complain about the accuracy of the weapon instead of it's destructive power. (That being said, these weapons have amazing accuracy.)
70's era technology got there. Imagine what 21st century tech could do, if it were done right?
:)
Melt faster.
There doesn't seem to be that much to find on Venus! How about Mars? Let's see... lot's of rocks, red sand and lots of guesses.
Mars may be interesting because it would be the best inner-system planet to colonize but it's not very likely to happen. Look at what happened with the moon. We went there and haven't been back in nearly 30 years. How would a Mars expedition be any different? Well, we probably wouldn't return 5 times.
I don't want to discount Mars. Anytime we land there it's an amazing accomplishment and great kudos to the guys that make it happen. But to say that Venus is less interesting is quite foolish. In fact, due to the environment extremes, I'd say we're more likely to discover something REALLY interesting there.
You're not supposed to. In-game advertising is all about Branding. No, NBA 2004 doesn't make you want that new pair of Nike Pumps but next time you're in a Foot Locker the brand will stick out more.
If done right, advertisments in a game can add to the realism. GTA3 wouldn't have been so real if they didn't play Pogo The Monkey ads on the radio occasionally.
Need for Speed Underground (an excellent game btw) has TONS of stickers representing REAL brands you can decorate your car with. This is not a bad thing. It makes the game more real. And hey, if I'm looking for neon next time I'll know some brands to look for. Great for me.
I went to a real engineering school to learn Computer Engineering (a 4 year EEE + CS program), and every time I see a company create a certification program that takes less than a month to become an "engineer", well... it makes me cringe.
That's funny, I get the same feeling when I hear people claim that their 4 year degree makes them an engineer. Last I checked you need to know the math and also be able to apply it. (It's that last part that university cannot teach.)
Anyone else find it interesting that Intel is working on x86-64 code? Or am I reading too much into this...
len.brown:intel.com:
o [ACPI] fix x86_64 build errors
o [ACPI] fix x86_64 !CONFIG_ACPI build
o 2.4.23 build x86_64 build fixes
o x86_64 build fix from previous cset
o [ACPI] sync some i386 ACPI build fixes into x86_64 to fix !CONFIG_ACPI build
(Note some non-x86-64 changes omited from excerpt)
Wishful thinking probably.
Regardless of how many rounds per second you gun can fire, the delay between each shot is also magnified in the sphere of effect.
So - if bullet-time runs at 1/100th of real-time that 0.01/second delay between rounds turns into one full second when the second round enters the SOE.
That being said, if the bullet-time SOE just slows things down then I will be extremely disappointed. The entire concept of bullet-time and the (IMO) related slow-motion fighting effects was to convey the speed of the characters involved. Max Payne almost got this right with it's Bullet Time implementation (you could aim at normal speed but you couldn't actually move faster)
A perfect implementation would allow for different time ratios for everyone in the system. Higher-level players would move insanely fast to low-level players because their time ratios were different. You wouldn't need SOE at all really, but while time-compression can be easily implemented in a computer it's the inverse that is impossible. In a MMORPG anyway.
Honestly, I don't remember the specs but why bog down the AGP bus when you have a perfectly good PCI-X bus for the HD broadcast? PCI/PCI-X/AGP tend to run on seperate bus so I'd think this would be cleaner / faster than the All-In-One approach.
Also, and this might be different with HDTV, but the quality of recordings from one of those ATI TV cards aren't all that great. One would think a dedicated card could do a better job. ATI just slaps these things on as an afterthought almost.
... really wonder how much training they have to go through before the males respond.
I'd rather have someone respond than be modded up.
I realize you didn't think about your sig when you added that last sentence. But now don't you wish you hadn't?
(It's a joke, laugh.)
I cannot believe I'm going to argue for Java....
Java's main strength was supposed to be platform independence. However, due to missteps by Sun and backstabbing by Microsoft, Java has been relegated to the back-end of a web page, running under Unix. In this client-server architecture, speed is crucial, and Javas bytecode doesn't cut it.
Although I would argue that Java's OO implementation is also it's main strength, but platform independence is also a big deal.
Microsoft's antics only really prevent Java Applets from becoming a much bigger thing than they are today. In any other client-side Java deployment you can be sure the JRE ships with the app, is installed on the client machine by the sys-admin (corporate environment) or the installer handles JRE installation for you.
If you truly believe that Java isn't platform independent, go look at any of the numerous Java Apps that have been written. Notice how they run on Windows, Mac, Linux and Solaris? That's not a typo. Here is one if you're too lazy to look yourself.
Native binaries are the only way to get the speed necessary in the post-.com days
This is also wrong. One need only look at the rapid proliferation of languages such as Perl, PHP, Python and (duh) Java as evidence. Asm/C/C++ have their uses - but to use them for everything should get you fired.
Fortunately, Linux is FREE (as in herpes and porn)and makes commodity hardware perform as well as enterprise offerings from Dell, Compaq, IBM, etc.
Linux is an operating system - Java is a programming language. What are you trying to compare? Funny thing is, the Linux and Windows JREs are usually ahead of the solaris JRE - because more java users use... well, Linux and Windows.
Furthermore, all major unices (AIX, SCO, *BSD, HPUX, Solaris, etc) include linux binary support, so linux binaries are more platform independent than Java is.
Wonderful - so your app will run on all these different flavors of UNIX... just slower. Where as the JRE was built for the OS and does not need the same kind of translation. On top of that, it can take advantage of OS features a Linux binary may not be able to.
Oh yeah - and Java runs on all those platforms plus Windows. So by sheer numbers Java is more platform independent.
Exactly my first thought. Also similar to a game called "Stunts." I believe EA published it?
I've always thought those were some of the best racing games out there.
Let's hope they put oil slicks and the other weapons for Racing Destruction Set!!!