Just read an article about cars of 2020 and remembered the conversation I've had recently. The person I was talking to said "Oh yeah, *now* you will start seeing real progress!" I said "Why?" and got this in return:
Until now, all the progress regarding green technologies (at least in US) was hampered by the fact that the Big Three had a very cozy relation with the Big Oil and didn't have a need to do anything at all. The demand for vehicles with high gas consumption was lobbied and advertised, and all was well and good.
And then, he said, the oil prices skyrocketed.
The automotive industry, he said, felt betrayed. They've been delivered a death blow at the moment they weren't doing so well already.
Now they're pissed and won't try to appease the Big Oil anymore. They've been demonstrated that no amount of lobbying and "vendor relations" gives them any guarantees when there is a chance of reaping an immediate benefit. In other words, Exxon reports record profits, whereas for Big Three, a government donation is considered. No more Mr. Nice Guy.
Oh well.
Whereas I don't believe that the problems the Big Three is having is closely related to gas prices (other manufacturers have been successfully chasing them into the single MPG territory), but rather due to extreme crappiness of their products, it would definitely be interesting to see what they'll come up with. So far, nothing spectacular - say, Ford's hybrid SUVs have no more appeal to me than their regular SUVs - their Tin Lizzy pedigree shows way too well. And with everybody jumping on the green bandwagon, they will have to do much better than they did before in order to become competitive again.
I'm not holding my breath.
Wednesday, August 27, 2008
Tuesday, August 26, 2008
Rudiments? Atavisms?
I've noticed an interesting fact during recent (and not so recent) refactoring sessions: junior programmers are using constructs that they couldn't possibly be taught using. Such as, huge blocks of variable declarations (the record is 152 declared variables: int i1, int i2; ... int i99; and so on), usually uninitialized.
The devastating consequence of this is that the compiler won't be able to detect branches that don't initialize the variables, and will happily use given default values and thus let you produce complete crap.
The closest historical origin of this is C, not even C++. It is highly unlikely that very junior Java programmers ever had any C exposure. The only explanation I have is that they keep stealing the code that was written somewhere in late nineties by some inexperienced C programmer trying to learn Java, and they keep doing that for years and years (actually, rather decades now) without a slightest attempt at comprehension of what it actually does, or where did it come from. Thus reaffirming again the painful experience of cargo cult programming.
Like the saying goes, you can write Fortran in any language...
But I wonder, maybe there's a different, better explanation?
The devastating consequence of this is that the compiler won't be able to detect branches that don't initialize the variables, and will happily use given default values and thus let you produce complete crap.
The closest historical origin of this is C, not even C++. It is highly unlikely that very junior Java programmers ever had any C exposure. The only explanation I have is that they keep stealing the code that was written somewhere in late nineties by some inexperienced C programmer trying to learn Java, and they keep doing that for years and years (actually, rather decades now) without a slightest attempt at comprehension of what it actually does, or where did it come from. Thus reaffirming again the painful experience of cargo cult programming.
Like the saying goes, you can write Fortran in any language...
But I wonder, maybe there's a different, better explanation?
Friday, August 22, 2008
Is Your Gas Pump Ripping You Off?
Just read this article and thought of a trend that I've noticed since the pipeline to Phoenix ruptured in 2003.
To put it shortly, every time the price of gas goes up, so goes the quality - the MPG meter in my car won't lie to me (that much, that is). Goes up significantly - a couple of miles per gallon.
And every time the price of gas goes down, buckle up - the quality would be, should I say, under par...
Right now, with the price drop from $4.60 to $3.60 - guess what, I've just lost 5 MPG.
The only explanation I have is that higher prices cause more angry customers and higher risk of inspections that the companies are not willing to let happen, hence, less cheating.
Oh, and the irony? Back in 2003, people complained about $2 per gallon...
To put it shortly, every time the price of gas goes up, so goes the quality - the MPG meter in my car won't lie to me (that much, that is). Goes up significantly - a couple of miles per gallon.
And every time the price of gas goes down, buckle up - the quality would be, should I say, under par...
Right now, with the price drop from $4.60 to $3.60 - guess what, I've just lost 5 MPG.
The only explanation I have is that higher prices cause more angry customers and higher risk of inspections that the companies are not willing to let happen, hence, less cheating.
Oh, and the irony? Back in 2003, people complained about $2 per gallon...
Thursday, August 21, 2008
Mark My Words: Google Apps Leasing
There is a major factor limiting the Google Apps acceptance: fear.
Small companies and individuals are able to comprehend the scope, security and privacy implications of Google Apps pretty easily - O horror! Big Brother is watching you! Duh, as if The Holy Triad (Equifax, Experian and Transunion) didn't already sell your intimate financial details to everyone and their uncle.
On the other hand, big corporations are neck deep in quagmires of existing policies - hardware and software procurement and user base, information access and security, legal retention and audit, cost to exit for existing obligations to name a few.
The most important issue in the context of Google Apps is information security and privacy. The very thought of trusting the crown jewels (or, at least, what they perceive them to be) to the outside entity causes a condition close to a heart attack for those that will be held responsible for the decision that's been made. Corporate officials don't like that. They prefer to keep the status quo and, ideally, not change anything at all. Or, at the very least, to deal with known threats.
Consequently, the hell with freeze over before corporations will trust^H^H^H^H^Hturn over their corporate data to Google.
How can Google get out of this predicament? I see two ways.
One, provide the user accessible API that will make sure that the only way to store the corporate data on an outside server is the encrypted way. This, however, introduces the whole issue of key and/or certificate management, which is somewhat familiar (albeit annoying) to IT folks, but which is going to kick the non-IT personnel out of their socks, no matter how simple it seems for the IT enabled. I don't see this happening anytime soon.
Two, allow corporations to physically lease the hardware that hosts Google Apps, like it does it for Google Mini. This will give them the warm and cozy feeling of being in a familiar environment, never mind that the people supervising the installation will probably orders of magnitude less experienced than Google would've dedicated to support tasks. It's BAU (Business As Usual) for them, which gives them an illusion that they can deal with it like they used to, which, in turn, makes them more likely to accept this sort of nuisance.
I've been expecting this to happen since the first time this topic was brought up in a water cooler conversation, about a year ago. Let's see how long it takes Google to deliver.
Small companies and individuals are able to comprehend the scope, security and privacy implications of Google Apps pretty easily - O horror! Big Brother is watching you! Duh, as if The Holy Triad (Equifax, Experian and Transunion) didn't already sell your intimate financial details to everyone and their uncle.
On the other hand, big corporations are neck deep in quagmires of existing policies - hardware and software procurement and user base, information access and security, legal retention and audit, cost to exit for existing obligations to name a few.
The most important issue in the context of Google Apps is information security and privacy. The very thought of trusting the crown jewels (or, at least, what they perceive them to be) to the outside entity causes a condition close to a heart attack for those that will be held responsible for the decision that's been made. Corporate officials don't like that. They prefer to keep the status quo and, ideally, not change anything at all. Or, at the very least, to deal with known threats.
Consequently, the hell with freeze over before corporations will trust^H^H^H^H^Hturn over their corporate data to Google.
How can Google get out of this predicament? I see two ways.
One, provide the user accessible API that will make sure that the only way to store the corporate data on an outside server is the encrypted way. This, however, introduces the whole issue of key and/or certificate management, which is somewhat familiar (albeit annoying) to IT folks, but which is going to kick the non-IT personnel out of their socks, no matter how simple it seems for the IT enabled. I don't see this happening anytime soon.
Two, allow corporations to physically lease the hardware that hosts Google Apps, like it does it for Google Mini. This will give them the warm and cozy feeling of being in a familiar environment, never mind that the people supervising the installation will probably orders of magnitude less experienced than Google would've dedicated to support tasks. It's BAU (Business As Usual) for them, which gives them an illusion that they can deal with it like they used to, which, in turn, makes them more likely to accept this sort of nuisance.
I've been expecting this to happen since the first time this topic was brought up in a water cooler conversation, about a year ago. Let's see how long it takes Google to deliver.
I Will Not Be Watching Your Video
It's actually pretty simple: I don't have time. Whereas it takes a split second to evaluate the text, and virtually no effort to skip the parts you're already familiar with - when you're watching the video, you will have to listen to all of the preliminary stuff and bad jokes and stuttering and looking for remote and apologizing for bad English and you name it. Oh, and don't even think of using a video as a quick reference - it's not searchable, either.
Same applies for the discoverability: my ability to find your video is limited by metadata that you provide, and it may not contain keywords for topics that you discuss.
Sadly, this affects even such incredibly educational things as Google's Seattle Conference on Scalability.
And another reason - strange, but fact - video services are often disabled by corporate firewalls.
Bottom line: if you want me to hear you, write it down. Session transcript will do just fine.
Same applies for the discoverability: my ability to find your video is limited by metadata that you provide, and it may not contain keywords for topics that you discuss.
Sadly, this affects even such incredibly educational things as Google's Seattle Conference on Scalability.
And another reason - strange, but fact - video services are often disabled by corporate firewalls.
Bottom line: if you want me to hear you, write it down. Session transcript will do just fine.
Wednesday, August 20, 2008
Random Thoughts: Does It Have To Be That Stupid?
I just can't stop wondering why NetBeans even as of version 6.1 has to do the disk lookup (traversing possibly thousands of directories on network mounts) on such a simple operation as "Go To File", instead of caching those file names once per session and then updating the cache as necessary, like other IDEs do?
Tuesday, August 19, 2008
Mobile Integration: Turn Off The Damn Phone!!!
There are few among as that can say that they always mute the phone before entering a meeting, a movie, or the library, or any other place where the hysterical hollering of the ring tone is at least unwelcome, and at most, sometimes, dangerous to your life (imagine the screeching brakes ring tone that your driver is exposed to - not good).
There are even fewer that actually do.
So I thought, wouldn't it be nice if your calendar had a "change ringer settings" feature that would help you to remember and actually put the phone on mute or vibrate or whatever is appropriate for the occasion...
Of course, it opens the usual can of worms - you don't want everybody and their uncle arbitrarily changing your phone settings due to a vulnerability or simple lack of diligence in the implementation, and of course, the protocol must use strong cryptography supporting trust relationship between your cloud applications and your mobile devices - but I hope that mobile API providers either already have this available, or are working on publishing it anytime soon...
Update: Not a complete solution (in particular, it's not integrated with the calendar), but definitely a step in the right direction: Android Locale.
There are even fewer that actually do.
So I thought, wouldn't it be nice if your calendar had a "change ringer settings" feature that would help you to remember and actually put the phone on mute or vibrate or whatever is appropriate for the occasion...
Of course, it opens the usual can of worms - you don't want everybody and their uncle arbitrarily changing your phone settings due to a vulnerability or simple lack of diligence in the implementation, and of course, the protocol must use strong cryptography supporting trust relationship between your cloud applications and your mobile devices - but I hope that mobile API providers either already have this available, or are working on publishing it anytime soon...
Update: Not a complete solution (in particular, it's not integrated with the calendar), but definitely a step in the right direction: Android Locale.
Friday, August 15, 2008
Russian Programmers
This text had been originally found in Russian, and then translated for the sake of my coworkers. For many years, it was hiding in backups until I found it again recently - and I think it hasn't lost its actuality since the time it's been translated (about 2000).
Original author is unknown. Original Russian text is lost (UPDATE: found again). If you are the author, or know the author, the chance to add the reference and give credit to the person who absolutely deserves it would be appreciated.
Here goes.
Any Russian programmer will spend just a couple of minutes to read someone else's code, and then will invariably jump and start shouting to himself: The hell with it! Throw it away! Rewrite it all! Then, a glimpse of a doubt will appear in his mind for a split second, and the rest of the day he will spend convincing himself that it is not that hard of a job to rewrite it all. And if approached right, it'll be piece of cake. But it will be The Right Thing, lean and mean and clean and nice. Next morning, he's adamantly convinced and is reporting to the supervisors that rewriting the code will take a day. No more than a day. All risks included, two days. As a result, he will be granted a week, and six months later it will be successfully finished. Until another Russian programmer sees it.
Meanwhile, in the four adjacent cubicles four Chinese programmers will work hard. In some unimaginable way, these programmers are managing to appear earlier in the office than their Russian colleague, they are managing to go home later, and at the same time they are managing to do three times less together than that one Russian guy. These four haven't produced any new code for a long time, they are just maintaining the code once written by an Indian programmer and then rewritten by two Russians. Bugs don't just live in this code. They have their nest in it. This nest is constantly reproducing itself, viciously using favorite Chinese technology known as "copy'n'paste" in other parts of the world. The bugs are proliferating from this code using static and passed by reference variables (because the Chinese programmers can't stand the inconvenience of not being able to change the value of the variables passed to their modules by the calling modules the Russian programmer is busy rewriting).
When coming across this module, the Russian programmer becomes speechless for a short period of time, then starts rapidly talking a mix of Chinese and Russian. He's long planning to rewrite the Chinese module, but he doesn't have time. The Chinese are responsible for critical bugs, and the management knows about it, and is harassing them constantly. The Chinese programmers keep hastily reassigning the bugs to each other, because they suspect that their attempts to fix the bugs will cause new, even more serious bugs. And they are right in their suspicion.
There's the only person in the office able to figure out how exactly the static variables get their values and in which order - the Indian programmer. But he's meditating. Therefore, when the Chinese Gang Of Four is laid off... Why them? Who else?!?!? Russian guy hasn't finished rewriting yet, and the Indian - the company's main asset - rarely pays any attention whatsoever to the project, but when he does, everybody is suddenly reminded that there's no one else who gets the architecture. So, when Chinese are let go, the code has two possible fates. One, Russian gets it and rewrites it. Two, Canadian gets it.
The Canadian is another thing altogether. Without a slightest hesitation, he will rush forward to fix the cruelest and nastiest Chinese made bug. The Chinese reported it fixed four times (each of them once), but every time it was back, even more intimidating, like Schwarzenegger. So, the Canadian will do what Chinese have not dared to do for the last three years. He will use the debugger to find out where exactly the static variable will become -1 instead of correct 0, and with steady hand, will introduce another static variable next to it, with the correct value. The bug will be defeated.
But the price of the victory will be high.
Everything, including the code that the Russian has just finished rewriting, will cease to work. The Russian will be dumbfounded for a couple of days, after which he will announce that of course, the design was wrong from the very beginning, and everything has to be rewritten. It will take a week. No more than a week. The Canadian will valiantly move to fix the bugs, but everything will become ever worse, though who would have thought... The commotion will kick the Indian out of meditation, and he will offer a brilliant solution - to branch the code. There will be two branches - one with The Bug, but working, and another, without The Bug, but not working either. The Russian, upon hearing of such decision, will break his slide rule in half and call his wife names after he gets home, but will say nothing to the management.
Fortunately, none of it will matter at all, because the product is selling anyway. Therefore the management is generally happy and is constantly reminding the employees that they were selected as creme de la creme. And that they have firmly established their ability to release the product by being able to release it. Once in a long while.
Original author is unknown. Original Russian text is lost (UPDATE: found again). If you are the author, or know the author, the chance to add the reference and give credit to the person who absolutely deserves it would be appreciated.
Here goes.
Any Russian programmer will spend just a couple of minutes to read someone else's code, and then will invariably jump and start shouting to himself: The hell with it! Throw it away! Rewrite it all! Then, a glimpse of a doubt will appear in his mind for a split second, and the rest of the day he will spend convincing himself that it is not that hard of a job to rewrite it all. And if approached right, it'll be piece of cake. But it will be The Right Thing, lean and mean and clean and nice. Next morning, he's adamantly convinced and is reporting to the supervisors that rewriting the code will take a day. No more than a day. All risks included, two days. As a result, he will be granted a week, and six months later it will be successfully finished. Until another Russian programmer sees it.
Meanwhile, in the four adjacent cubicles four Chinese programmers will work hard. In some unimaginable way, these programmers are managing to appear earlier in the office than their Russian colleague, they are managing to go home later, and at the same time they are managing to do three times less together than that one Russian guy. These four haven't produced any new code for a long time, they are just maintaining the code once written by an Indian programmer and then rewritten by two Russians. Bugs don't just live in this code. They have their nest in it. This nest is constantly reproducing itself, viciously using favorite Chinese technology known as "copy'n'paste" in other parts of the world. The bugs are proliferating from this code using static and passed by reference variables (because the Chinese programmers can't stand the inconvenience of not being able to change the value of the variables passed to their modules by the calling modules the Russian programmer is busy rewriting).
When coming across this module, the Russian programmer becomes speechless for a short period of time, then starts rapidly talking a mix of Chinese and Russian. He's long planning to rewrite the Chinese module, but he doesn't have time. The Chinese are responsible for critical bugs, and the management knows about it, and is harassing them constantly. The Chinese programmers keep hastily reassigning the bugs to each other, because they suspect that their attempts to fix the bugs will cause new, even more serious bugs. And they are right in their suspicion.
There's the only person in the office able to figure out how exactly the static variables get their values and in which order - the Indian programmer. But he's meditating. Therefore, when the Chinese Gang Of Four is laid off... Why them? Who else?!?!? Russian guy hasn't finished rewriting yet, and the Indian - the company's main asset - rarely pays any attention whatsoever to the project, but when he does, everybody is suddenly reminded that there's no one else who gets the architecture. So, when Chinese are let go, the code has two possible fates. One, Russian gets it and rewrites it. Two, Canadian gets it.
The Canadian is another thing altogether. Without a slightest hesitation, he will rush forward to fix the cruelest and nastiest Chinese made bug. The Chinese reported it fixed four times (each of them once), but every time it was back, even more intimidating, like Schwarzenegger. So, the Canadian will do what Chinese have not dared to do for the last three years. He will use the debugger to find out where exactly the static variable will become -1 instead of correct 0, and with steady hand, will introduce another static variable next to it, with the correct value. The bug will be defeated.
But the price of the victory will be high.
Everything, including the code that the Russian has just finished rewriting, will cease to work. The Russian will be dumbfounded for a couple of days, after which he will announce that of course, the design was wrong from the very beginning, and everything has to be rewritten. It will take a week. No more than a week. The Canadian will valiantly move to fix the bugs, but everything will become ever worse, though who would have thought... The commotion will kick the Indian out of meditation, and he will offer a brilliant solution - to branch the code. There will be two branches - one with The Bug, but working, and another, without The Bug, but not working either. The Russian, upon hearing of such decision, will break his slide rule in half and call his wife names after he gets home, but will say nothing to the management.
Fortunately, none of it will matter at all, because the product is selling anyway. Therefore the management is generally happy and is constantly reminding the employees that they were selected as creme de la creme. And that they have firmly established their ability to release the product by being able to release it. Once in a long while.
Wednesday, August 13, 2008
BlackBerry Curve 8320: Mystery Overheating, Battery Drain
Suddenly found the phone quite hot, with the battery completely drained. At first I thought that I just kept the keyboard jammed in my pocket for a few hours - said to myself, no big deal, I'll just charge it overnight.
In the morning, the phone was still hot - I thought, no big deal, it's just been charging.
Then the battery charge started rapidly disappearing again. Cold reboot helped.
Trivial analysis would offer an educated guess - there was a runaway process consuming CPU and power. Too bad BlackBerry in production configuration doesn't offer any diagnostic tools...
So I just wrote it off as a weird bug.
Until the next time it happened, few days later.
Primary suspect: Google Maps for Mobile. Not everything is clear at this point, but it seems that the necessary conditions are:
Interestingly enough, a similar problem was reported for iPhone 3G (read this, search for "draws") - apparently, it is possible to drain the battery faster than the power adapter charges it.
Last time, it was possible to stop the drain by closing Google Maps - it took me a few tries, however, and I'm not sure how exactly did I get the BlackBerry out of that condition. Let's see if this happens again, and what would Google do to Maps to fix this.
In the morning, the phone was still hot - I thought, no big deal, it's just been charging.
Then the battery charge started rapidly disappearing again. Cold reboot helped.
Trivial analysis would offer an educated guess - there was a runaway process consuming CPU and power. Too bad BlackBerry in production configuration doesn't offer any diagnostic tools...
So I just wrote it off as a weird bug.
Until the next time it happened, few days later.
Primary suspect: Google Maps for Mobile. Not everything is clear at this point, but it seems that the necessary conditions are:
- fetching driving directions;
- following the route;
- driving through a no reception zone (not sure).
Interestingly enough, a similar problem was reported for iPhone 3G (read this, search for "draws") - apparently, it is possible to drain the battery faster than the power adapter charges it.
Last time, it was possible to stop the drain by closing Google Maps - it took me a few tries, however, and I'm not sure how exactly did I get the BlackBerry out of that condition. Let's see if this happens again, and what would Google do to Maps to fix this.
Antec P-182: Mixed Blessing
When the time has come to build a new box, there were two primary considerations: one, I didn't want to rebuild an existing case, two, I got tired of "overpaying" (should've known better, but later about it), as was the case (or so I thought at the time) with Lian-Li V-Cool PC-V1200B.
Also, loud cases eventually got me tired, and a quiet case like this was probably the last straw.
So, after careful consideration, I decided to try Antec P-182.
Well... TANSTAAFL.
Lian-Li cases remind me or Sir Henry Royce (yes, the Rolls-Royce Royce): The quality remains long after the price is forgotten. Even ancient (vintage of 2002) Lian-Li PC-60 would be a very good case today, if not for noisy 80mm fans (there is a 120mm version, but alas, it was manufactured later).
P-182, on the other hand... Every step of the way shows the cost cutting measures. More the pity because the design decisions are basically sound.
P-182 is not as big as reviews would like you to believe. 8800GTS cards do fit into the case, but forget about installing hard drives or extra fan into the middle bay cage - the cables get in the way.
Cable management is a nightmare. Despite the fact that P-182 is considered an improvement over P-180 (I dread to think how bad *that* was), cables don't really have much place to be hidden at, plastic doors bend and become difficult to close, cables routed in the lower compartment tend to interfere with fan blades - not fun at all.
Fans were the last straw.
I am very disappointed to have trusted the opinion expressed by Silent PC Review in their P-182 review. I guess they have based that opinion on medium or low speed setting on the fans, neither of which is really acceptable for a person on a low budget in the middle of Arizona summer.
Interestingly enough, a separate review TriCool fans were described as "definitely not quiet".
Setting the fans or medium or low speed, given the fact that the box had one of the hottest (no pun intended) motherboards on the market (ASUS Striker II Formula), ambient temperature about 30°C, disks heating up to 43°Cб was absolutely out of question.
Had to replace the stock fans.
Decided to trust Silent PC Review once again, and bought Scythe SY1225SL12M (used other Scythe product, S-FLEX SFF21D before, liked them a lot - but the flow would have not been sufficient for this case).
This brought the price of the caseto $200 - the price of a comparable feature set, but better manufactured Lian-Li.
Also, when I took the fans off, it turned out that the underside of fan grills is quite sharp and rough, creating turbulence and without doubt adding extra wind noise. Had this happened before the component installation, it would've been OK to smooth them over, but with the motherboard and power supply installed, and cables routed, I said the hell with it.
The very last straw - turned out that the plastic door has a razor sharp edge. Lost a quart of blood and about 2"x1/4" piece of skin - it was kinda unbelievable to cause such a wound with a piece of, mind you, soft plastic.
All in all, after all was said and done, I had issued the last expletive and promised myself not to buy new cases, ever, even if it means that I will have to make them out of wood.
Now that I'm done with the criticism...
The case is relatively quiet, and relatively cool (as in temperature, not as in appeal).
All the fans except the drive compartment one are under variable speed control provided by BIOS. The last fan is simply turned on at 70% speed.
Hard drive noise is very well contained. I simply don't hear them (Seagate Barracuda, not quite known for being quiet).
Even the 8800GTS SLI is not audible until their fans get up to about 50% speed, with the cards themselves not heating up above lazy 70°C (for comparison,
XFX GF7950GT PVT71JYHE9 is feeling just fine all the way up to 120°C).
The only noise left after fan replacement is a slight hum of the fans - mostly video card fans. Doesn't interfere with listening to the music. Doesn't interfere with work. Playing games? I don't think you'd notice anything at all. HVAC turning on absolutely drowns all the noise produced by the box.
Is it possible to make the case quieter? Yes, by using a cooler motherboard and hard drives (Western Digital drives seem to be the best in this context nowadays). You can also use even quieter S-FLEX fans, but that'll be tempting the fate.
Is it possible to make the case cooler? Absolutely - just set all the fans at 100% speed (after the fans have been replaced, of course). Even then the case is quite acceptable, albeit noticeable.
In other words, am I happy with the case? Well, after all the time and efforts spent on it, mostly yes - provided I don't have to get in often, the cables are really annoying to deal with.
Am I gonna buy a comparable case again? Hell no. Either another of my dozen leftover cases gets an extreme makeup, or I'm gonna buy another Lian-Li. I don't think that would be much more expensive, and know for sure that the quality would be better.
Also, loud cases eventually got me tired, and a quiet case like this was probably the last straw.
So, after careful consideration, I decided to try Antec P-182.
Well... TANSTAAFL.
Lian-Li cases remind me or Sir Henry Royce (yes, the Rolls-Royce Royce): The quality remains long after the price is forgotten. Even ancient (vintage of 2002) Lian-Li PC-60 would be a very good case today, if not for noisy 80mm fans (there is a 120mm version, but alas, it was manufactured later).
P-182, on the other hand... Every step of the way shows the cost cutting measures. More the pity because the design decisions are basically sound.
P-182 is not as big as reviews would like you to believe. 8800GTS cards do fit into the case, but forget about installing hard drives or extra fan into the middle bay cage - the cables get in the way.
Cable management is a nightmare. Despite the fact that P-182 is considered an improvement over P-180 (I dread to think how bad *that* was), cables don't really have much place to be hidden at, plastic doors bend and become difficult to close, cables routed in the lower compartment tend to interfere with fan blades - not fun at all.
Fans were the last straw.
I am very disappointed to have trusted the opinion expressed by Silent PC Review in their P-182 review. I guess they have based that opinion on medium or low speed setting on the fans, neither of which is really acceptable for a person on a low budget in the middle of Arizona summer.
Interestingly enough, a separate review TriCool fans were described as "definitely not quiet".
Setting the fans or medium or low speed, given the fact that the box had one of the hottest (no pun intended) motherboards on the market (ASUS Striker II Formula), ambient temperature about 30°C, disks heating up to 43°Cб was absolutely out of question.
Had to replace the stock fans.
Decided to trust Silent PC Review once again, and bought Scythe SY1225SL12M (used other Scythe product, S-FLEX SFF21D before, liked them a lot - but the flow would have not been sufficient for this case).
This brought the price of the caseto $200 - the price of a comparable feature set, but better manufactured Lian-Li.
Also, when I took the fans off, it turned out that the underside of fan grills is quite sharp and rough, creating turbulence and without doubt adding extra wind noise. Had this happened before the component installation, it would've been OK to smooth them over, but with the motherboard and power supply installed, and cables routed, I said the hell with it.
The very last straw - turned out that the plastic door has a razor sharp edge. Lost a quart of blood and about 2"x1/4" piece of skin - it was kinda unbelievable to cause such a wound with a piece of, mind you, soft plastic.
All in all, after all was said and done, I had issued the last expletive and promised myself not to buy new cases, ever, even if it means that I will have to make them out of wood.
Now that I'm done with the criticism...
The case is relatively quiet, and relatively cool (as in temperature, not as in appeal).
All the fans except the drive compartment one are under variable speed control provided by BIOS. The last fan is simply turned on at 70% speed.
Hard drive noise is very well contained. I simply don't hear them (Seagate Barracuda, not quite known for being quiet).
Even the 8800GTS SLI is not audible until their fans get up to about 50% speed, with the cards themselves not heating up above lazy 70°C (for comparison,
XFX GF7950GT PVT71JYHE9 is feeling just fine all the way up to 120°C).
The only noise left after fan replacement is a slight hum of the fans - mostly video card fans. Doesn't interfere with listening to the music. Doesn't interfere with work. Playing games? I don't think you'd notice anything at all. HVAC turning on absolutely drowns all the noise produced by the box.
Is it possible to make the case quieter? Yes, by using a cooler motherboard and hard drives (Western Digital drives seem to be the best in this context nowadays). You can also use even quieter S-FLEX fans, but that'll be tempting the fate.
Is it possible to make the case cooler? Absolutely - just set all the fans at 100% speed (after the fans have been replaced, of course). Even then the case is quite acceptable, albeit noticeable.
In other words, am I happy with the case? Well, after all the time and efforts spent on it, mostly yes - provided I don't have to get in often, the cables are really annoying to deal with.
Am I gonna buy a comparable case again? Hell no. Either another of my dozen leftover cases gets an extreme makeup, or I'm gonna buy another Lian-Li. I don't think that would be much more expensive, and know for sure that the quality would be better.
Subscribe to:
Posts (Atom)
