Well you can sort of fake a push model with AJAX in that you can have the server start sending data that is processed as it comes in 'live' without having to continually request updates. This is often the type of thing that is done (and is favorible) with file upload progress bars, chat applications, and the like. The session cache is the right idea, yes, except generally it doesn't really have to be a full database. Depending on the application, data may be copied to a database table stored in RAM or seperately cached to disk or even put into something like memcached (a network distributed RAM cache). In any case, there would be a locking mechanism on this data so that not only could the user (requesting webpages) alter it but so could other processes such as a message delivery agent in a mail system or other users in a chat application, a database trigger, etc. Continually having the client make requests would create overhead in setting up the connections everytime and reopening the user's session data, but whether or not you are doing something that is polled like this or pushed, you get the benefit of not having to wait on the database in either case.
This is slightly over-generalized; Xen's paravirtualization takes less of a hit on processors without virtualization support at the expense of having to modify the VM's OS to work correclty with Xen. The same kind of hit is normally taken with running two services on the same machine or using something line User Mode Linux or coLinux meaning that Xen is a great solution for segregating seperate applications on a single server without sacrificing the same performance as VMWare. However on newer processors with virtualization instructions, both VMWare and Xen are more on the level since the primary speed differentiator between their technologies is pretty much gone. VMWare still has a larger overhead, but then again it does quite a bit more particularly with the way it handles memory and disks for the VM. Last I checked, you can't oversubscribe the host's physical memory or disk to guest OS's in Xen. This kind of feature is absolutely essential when trying to use Virtualization to achieve high availability where sometimes you have to move (or vmotion/Xen equivalent) running machines between servers for recovery or scheduled maintenance. With xen you would either have to have enough spare ram on hosts to handle this or you'd have to reconfigure and reboot running guests to handle the extra loads.
AJAX is just another way of sending http requests to the server from the browser.
Unfortunately this alternate method makes use of a couple of potentially harmful mechanisms: client side scripting and (in IE) ActiveX. Additionally, it is not uncommon to see AJAX requests and responders bend or break the rules of HTTP also which can cause packet-inspecting firewalls some grief. Sure, you can easily code up a little shopping site where you click 'show price' to load the price via AJAX, but it's no excuse for not making that same link do the right thing in browsers that do not have that capability.
The cost of reloading some or all of a webpage (outside of the obvious bandwidth needed) depend a great deal on the way the application is coded.
In GMail for instance, it would make sense for open sessions to not query the users mailbox each time the requestor wants a list of (new) messages, but to move to an approach where a new message being delivered to the mailbox notifies the session that there is a new message. I really see no reason that GMail should be querying for the list of messages more than once after login. The data should be brought up from the archive to a faster access medium such as a distributed memory cache, sorted, indexed, and served from there. If the dataset does not undergo any significant changes, the last copy generated is still current and can be recycled with bare minimum overhead. Changes to the data should be performed to the in-memory version and backgrounded to the real database. Unfortunately the approach of 'put it into the database when it comes in'; 'get it out of the database every time you need it' when there are no strict transactional requirements is very often an extremely poor way to code high performance web applications and there are a great many large website engines that are unfortunately coded this way. Every time I see a 'slashdotted' site that is throwing database errors yet serving essentially static content I abandon all hope. This is particularly true when the site in question is supposed to be hosting an article about how to increase server performance, implement coding best practices, optimize web applications, etc.
Sure a lithium battery as big as a couple bricks would last a very long time; however when you figure that it runs for 10 hours on 100mL of methanol and you can also pack in a 3L bottle of the stuff with your gear and run for 2 solid weeks it makes the fuel cell very attractive for certain applications.
Why someone is not producing these for laptops even at their current size if they actually work seems absolutely insane to me.
It is probably easier to get vista running on a desktop simply because they are built out of commodity components, and the third party vendors are usually better about having things like vista-ready drivers available to download.
Laptops with their more specialized hardware (albeit there are fewer options to deal with) are mostly reliant on the laptop vendors for driver support, and I can tell you this: the vendors don't much care at this point about the upgrade path when Vista is still in beta. Even when it is released, current laptops may be difficult to install and support due to vendor disinterest. After all, they'd rather sell you a brand new machine with Vista preinstalled.
Still this author tends to echo the senitment of most computer users nowadays. People tend to dislike Linux and think it is hard to use because it is hard to install. Meanwhile, said users have never had to trudge through a Windows install from scratch themselves (Or they have only had to use restore CD's). Whenever they first have to they realize it's not particularly easy either. The only OS that really is easy to install in my experience has been the Mac OS, and the primary reason for this is because the OS vendor is the hardware vendor and they know ahead of the install exactly what hardware is in the machine. I personally think that people trying and failing to upgrade to Vista will switch a lot of people over to macs, but it also will simply cause a lot of people to throw away that $350 computer and just buy a new one instead.
No; ESX has its own kernel and is its own OS. The official name of the OS is VMNX or something like that. The service console that is based on RedHat runs the same as other guest OS's however it has escalated privileges with respect to what it is allowed to see and do to the running ESX kernel. If it were the case that Linux was actually providing the hardware support you'd be able to run ESX on a whole lot more than you currently can!
FDIV wasn't particularly obscure; IIRC it went unnoticed for a very long time and affected many real world calculations. It was unlike many other errata in the regard that it was a documented function misbehaving and was not caught early. You could see it in action simply by loading up a spreadsheet app and doing a division. The software workaround wasn't that difficult, but the lack at the time of microcode support made it a big hassle.
The Pentium also had the more egregious F00F bug, the nonexistent opcode which would simply deadlock the processor and could be called in any mode. The workaround was a huge performance drain on all OS's. These two problems were probably the two most serious and publicized errata for the Pentium, but they were certainly not the only ones. If you are suggesting that any microprocessor of equivalent complexity produced in recent years has shipped without a flaw, I'd like to know about it.
The HP ScanJet 5500c is discontinued but you can still find it online for less than $100. It has a feeder specifically made for photos up to 5"x7" and it does work. Like most HP Scanners, you have to learn its subtlties but it is still the best bang for the buck on volume photo scanning. The driver that comes with the scanner and the drivers offered for download by HP have problems, but there are some 3rd party patches available (a quick google will get you there fast) that make the unit much more reliable.
The feeder uses a negative pressure system to hold the photo onto the feed belt with a slight vacuum so that the picture stays flat and the surface does not scrape against the platen glass. It's also a straight path ADF so it wont bend your photos. Though other posters here say that regular ADF's work for photos, they are very likely to scratch, bend, or destroy your pictures, particularly if they jam or you get dirt/dust around the feed rollers..
The only good alternatives to the 5500c are orders of magnitude more expensive or orders of magnitude slower.
This study has no relevance to this argument. Decoding speed means nothing. It's even quite possible that decoding AAC on a general purpose CPU uses more power hungry operations than decoding MP3 (no idea if this is true, but it's possible) despite the fact that the CPU does the operation faster.
In any rate, if you want to know which codec takes less power in an MP3 player just look up the datasheets for the ASIC's that are in the player. They'll have a breakdown of power requirements for various bitrates.
I really don't mean to sound like a DRM apologist, but making irrational and flawed arguments against DRM is no way to fight it. There's lots of more rational approaches, such as explaining to the customer that they are paying for their own lockout devices.
The problem is like that tag on the mattress. You spent who knows how many tax dollars to put that thing there and the privilege you receive for all that money is the inability to cut the thing off. (Yes I do know you actually can remove the tag -- just not before it is sold.)
If it weren't for every site on the whole damn Internet parroting each other so badly perhaps this never would have made the news. Anyway their "study" is deeply flawed, and while it could be argued that DRM does actually cause your player to consume more battery life than it otherwise would, DRM is not making the power impact they claim and anyone giving the problem more than even five seconds of rational thought would realize this.
The codec is the problem. It takes more power to decode WMA (DRM or not) than it does to decode MP3. Ditto for AAC. The codecs are more computationally intensive and are decoded by general purpose CPU's in many players while MP3 is most often decoded with dedicated ASIC's. Even if all decodes are done in dedicated hardware, the MP3 codec is still likely going to be the most power efficient.
A proper study would have compared identical tracks with identical compression with and without DRM such as an iTunes track played on repeat vs the same track with DRM stripped out played the same way. I'd bet the overhead of the DRM is more on the order of 1-3% here.
It is; however, the DRM that is locking you into using WMA/AAC vs the power-saving MP3 format in the first place, but it's a bit of a stretch to say that it's the DRM's fault that a player running a more complex codec takes a power hit for doing so.
Easier said than done. HDCP is not as easy to crack as CSS was, and unlike CSS there's different keys for different devices and media. You'll have to crack the key again for every new device or Blu-Ray disc you buy.
HDCP is already cracekd. There are devices on the market which remove HDCP from a DVI/HDMI signal. There are also (very expensive) devices that are capable of capturing this video data where it can be re-encoded. All this really means is that these next two protection mechanisms are all but useless from the standpoint of trying to prevent a video from being copied and distrubited, but FWIW:
AACS as used on Blu-Ray/HD-DVD is not (yet) cracked.
The DRM that enforces the requirement of HDCP encryption on HD-resolution video output from the video card is also not (yet) cracked.
I know I didn't mention this, but although I have not (until now) run an Asterisk server in a large production environment, I have been using Asterisk experimentally for three or four years and have contributed my time and my code to its development and at times participated actively on the mailing list and the bug tracker to assist in its continued improvement.
That being said...
I'm not so much critisizing a vendor for honesty. There are a lot of ways to say "We have had reports from our customers having problems with Asterisk." I am happy to concede that it is a very complex piece of software and difficult to learn and grasp fully, especially if all you want to do is deploy it quickly and set it up yourself without help and you are not an expert on Linux, network and telephony hardware. If you spend a lot of time really working with Asterisk in an experimental environment before you settle on equipment that you like you learn a lot of the tricks necessary to combat certain problems. I don't think there is a single problem that I have seen with an Asterisk installation that could not be rectified somehow. The tone of the original post, however, was not positive. I'd rather puchase from a vendor with a better attitude -- maybe one of the many who actively and financially support the improvement of the project instead of trying to upsell you some other solution they can make more money on.
What really bothers me more than the slam is that the poster is being so two faced about the whole thing -- pushing asterisk hard on their site to make money but complaining behind the scenes. That is a dishonest vendor, and biting the hand that feeds is no way to get my support.
It's worth repeating an AC's reply to my first reactionary post -- the original post could possibly not be someone from Atacomm.
I am unbelievably suprised to read a smear on Asterisk from a vendor as big as you guys, especially one who lists Asterisk compatibility and Digium hardware all over nearly every product they sell. I guess you do get a lot of mis-targeted fallout when dumb customers can't get thier shiny new phones to work with Asterisk, but I think it's a bit unfair to call it crap.
I am currently ordering equipment to build a small (30+ extensions) PBX for the company I work for. The total package including all cabling, PoE gear, Polycom phones, UPS's, T1 interfaces, etc. budgets to under $10,000 with Asterisk. Anything else that comes close to competing on the features we will be using is four to five times the price at minimum.
For what it's worth, I was considering placing an order for a good deal of the equipment that I need from Atacomm; however, I think it's justified to remove you from the list now.
Large multiuser audio conferences are also a huge gamer feature and a market that Intel is grabbing at desperately these days. It's all but trivial to set up an Asterisk server (There is even a LiveCD distribution IIRC) and there are plenty of free SIP clients that will happily connect. As for the conferencing in Asterisk, "MeetMe" provides for a very simple and stable solution for far more than 10 users.
I do like your idea of only being able to feed 5 calls through a proxy node (or whatever the hell they call it)... I have hated Skype from day one and the more stupid crap they continue to do like this the better I feel about my initial instinct.
I understand your post and agree, but just for fun: the governor on BMW's.. (or at least the ones that have it) is 155 MPH and there are plenty of carmakers who advertise about how much faster their cars can go by comparison despite the fact that the BMW's speed is artifically limited. I don't think that it's hurting anybody's sales however.
Mercury vapor, sodium, metal halide, etc. lamps are not actually more efficient than good flourescent tubes and ballasts, though they are probably better than compact flourescents. The reason they are used is that they have a much higher MBTF which is really the most important thing when you have to shut down a lane of traffic and pay 5 construction workers for an hour to change the bulb.
Well, there are some microwaves that are better at defrosting evenly than others in my experience, but in any case, another great way to defrost things is to put them on what is essentially a big huge heatsink. They sell these things for a whole lot of money as some kind of "magic defroster" plate, but in reality all they are is a big hunk of steel coated with teflon,. You can use any large nonstick skillet to get the same effect. They work best for defrosting meats but anything that has a large flat surface to sit down on the metal will also work. To accelerate the process, put the defrosting skillet into a larger pan with water in it. The bigger the heatsink the faster the thaw.
Slashdot Mirror
Well you can sort of fake a push model with AJAX in that you can have the server start sending data that is processed as it comes in 'live' without having to continually request updates. This is often the type of thing that is done (and is favorible) with file upload progress bars, chat applications, and the like. The session cache is the right idea, yes, except generally it doesn't really have to be a full database. Depending on the application, data may be copied to a database table stored in RAM or seperately cached to disk or even put into something like memcached (a network distributed RAM cache). In any case, there would be a locking mechanism on this data so that not only could the user (requesting webpages) alter it but so could other processes such as a message delivery agent in a mail system or other users in a chat application, a database trigger, etc. Continually having the client make requests would create overhead in setting up the connections everytime and reopening the user's session data, but whether or not you are doing something that is polled like this or pushed, you get the benefit of not having to wait on the database in either case.
This is slightly over-generalized; Xen's paravirtualization takes less of a hit on processors without virtualization support at the expense of having to modify the VM's OS to work correclty with Xen. The same kind of hit is normally taken with running two services on the same machine or using something line User Mode Linux or coLinux meaning that Xen is a great solution for segregating seperate applications on a single server without sacrificing the same performance as VMWare. However on newer processors with virtualization instructions, both VMWare and Xen are more on the level since the primary speed differentiator between their technologies is pretty much gone. VMWare still has a larger overhead, but then again it does quite a bit more particularly with the way it handles memory and disks for the VM. Last I checked, you can't oversubscribe the host's physical memory or disk to guest OS's in Xen. This kind of feature is absolutely essential when trying to use Virtualization to achieve high availability where sometimes you have to move (or vmotion/Xen equivalent) running machines between servers for recovery or scheduled maintenance. With xen you would either have to have enough spare ram on hosts to handle this or you'd have to reconfigure and reboot running guests to handle the extra loads.
You said it yourself:
AJAX is just another way of sending http requests to the server from the browser.
Unfortunately this alternate method makes use of a couple of potentially harmful mechanisms: client side scripting and (in IE) ActiveX. Additionally, it is not uncommon to see AJAX requests and responders bend or break the rules of HTTP also which can cause packet-inspecting firewalls some grief. Sure, you can easily code up a little shopping site where you click 'show price' to load the price via AJAX, but it's no excuse for not making that same link do the right thing in browsers that do not have that capability.
The cost of reloading some or all of a webpage (outside of the obvious bandwidth needed) depend a great deal on the way the application is coded.
In GMail for instance, it would make sense for open sessions to not query the users mailbox each time the requestor wants a list of (new) messages, but to move to an approach where a new message being delivered to the mailbox notifies the session that there is a new message. I really see no reason that GMail should be querying for the list of messages more than once after login. The data should be brought up from the archive to a faster access medium such as a distributed memory cache, sorted, indexed, and served from there. If the dataset does not undergo any significant changes, the last copy generated is still current and can be recycled with bare minimum overhead. Changes to the data should be performed to the in-memory version and backgrounded to the real database. Unfortunately the approach of 'put it into the database when it comes in'; 'get it out of the database every time you need it' when there are no strict transactional requirements is very often an extremely poor way to code high performance web applications and there are a great many large website engines that are unfortunately coded this way. Every time I see a 'slashdotted' site that is throwing database errors yet serving essentially static content I abandon all hope. This is particularly true when the site in question is supposed to be hosting an article about how to increase server performance, implement coding best practices, optimize web applications, etc.
Sure a lithium battery as big as a couple bricks would last a very long time; however when you figure that it runs for 10 hours on 100mL of methanol and you can also pack in a 3L bottle of the stuff with your gear and run for 2 solid weeks it makes the fuel cell very attractive for certain applications.
Why someone is not producing these for laptops even at their current size if they actually work seems absolutely insane to me.
It is probably easier to get vista running on a desktop simply because they are built out of commodity components, and the third party vendors are usually better about having things like vista-ready drivers available to download.
Laptops with their more specialized hardware (albeit there are fewer options to deal with) are mostly reliant on the laptop vendors for driver support, and I can tell you this: the vendors don't much care at this point about the upgrade path when Vista is still in beta. Even when it is released, current laptops may be difficult to install and support due to vendor disinterest. After all, they'd rather sell you a brand new machine with Vista preinstalled.
Still this author tends to echo the senitment of most computer users nowadays. People tend to dislike Linux and think it is hard to use because it is hard to install. Meanwhile, said users have never had to trudge through a Windows install from scratch themselves (Or they have only had to use restore CD's). Whenever they first have to they realize it's not particularly easy either. The only OS that really is easy to install in my experience has been the Mac OS, and the primary reason for this is because the OS vendor is the hardware vendor and they know ahead of the install exactly what hardware is in the machine. I personally think that people trying and failing to upgrade to Vista will switch a lot of people over to macs, but it also will simply cause a lot of people to throw away that $350 computer and just buy a new one instead.
No; ESX has its own kernel and is its own OS. The official name of the OS is VMNX or something like that. The service console that is based on RedHat runs the same as other guest OS's however it has escalated privileges with respect to what it is allowed to see and do to the running ESX kernel. If it were the case that Linux was actually providing the hardware support you'd be able to run ESX on a whole lot more than you currently can!
Um... Are you really trying to suggest that Diebold is not getting paid enough to implement these things properly and securely?
You mean like the screensaver from Lycos that died a horrible death too?
FDIV wasn't particularly obscure; IIRC it went unnoticed for a very long time and affected many real world calculations. It was unlike many other errata in the regard that it was a documented function misbehaving and was not caught early. You could see it in action simply by loading up a spreadsheet app and doing a division. The software workaround wasn't that difficult, but the lack at the time of microcode support made it a big hassle.
The Pentium also had the more egregious F00F bug, the nonexistent opcode which would simply deadlock the processor and could be called in any mode. The workaround was a huge performance drain on all OS's. These two problems were probably the two most serious and publicized errata for the Pentium, but they were certainly not the only ones. If you are suggesting that any microprocessor of equivalent complexity produced in recent years has shipped without a flaw, I'd like to know about it.
Do you mean RS-485?
The HP ScanJet 5500c is discontinued but you can still find it online for less than $100. It has a feeder specifically made for photos up to 5"x7" and it does work. Like most HP Scanners, you have to learn its subtlties but it is still the best bang for the buck on volume photo scanning. The driver that comes with the scanner and the drivers offered for download by HP have problems, but there are some 3rd party patches available (a quick google will get you there fast) that make the unit much more reliable.
The feeder uses a negative pressure system to hold the photo onto the feed belt with a slight vacuum so that the picture stays flat and the surface does not scrape against the platen glass. It's also a straight path ADF so it wont bend your photos. Though other posters here say that regular ADF's work for photos, they are very likely to scratch, bend, or destroy your pictures, particularly if they jam or you get dirt/dust around the feed rollers..
The only good alternatives to the 5500c are orders of magnitude more expensive or orders of magnitude slower.
According to Saturday Night Live, not only is the sun a planet, it's also Harry Caray's favorite planet.
+5 informative indeed! Kudos to you, sir.
This study has no relevance to this argument. Decoding speed means nothing. It's even quite possible that decoding AAC on a general purpose CPU uses more power hungry operations than decoding MP3 (no idea if this is true, but it's possible) despite the fact that the CPU does the operation faster.
In any rate, if you want to know which codec takes less power in an MP3 player just look up the datasheets for the ASIC's that are in the player. They'll have a breakdown of power requirements for various bitrates.
PS
I really don't mean to sound like a DRM apologist, but making irrational and flawed arguments against DRM is no way to fight it. There's lots of more rational approaches, such as explaining to the customer that they are paying for their own lockout devices.
The problem is like that tag on the mattress. You spent who knows how many tax dollars to put that thing there and the privilege you receive for all that money is the inability to cut the thing off. (Yes I do know you actually can remove the tag -- just not before it is sold.)
If it weren't for every site on the whole damn Internet parroting each other so badly perhaps this never would have made the news. Anyway their "study" is deeply flawed, and while it could be argued that DRM does actually cause your player to consume more battery life than it otherwise would, DRM is not making the power impact they claim and anyone giving the problem more than even five seconds of rational thought would realize this.
The codec is the problem. It takes more power to decode WMA (DRM or not) than it does to decode MP3. Ditto for AAC. The codecs are more computationally intensive and are decoded by general purpose CPU's in many players while MP3 is most often decoded with dedicated ASIC's. Even if all decodes are done in dedicated hardware, the MP3 codec is still likely going to be the most power efficient.
A proper study would have compared identical tracks with identical compression with and without DRM such as an iTunes track played on repeat vs the same track with DRM stripped out played the same way. I'd bet the overhead of the DRM is more on the order of 1-3% here.
It is; however, the DRM that is locking you into using WMA/AAC vs the power-saving MP3 format in the first place, but it's a bit of a stretch to say that it's the DRM's fault that a player running a more complex codec takes a power hit for doing so.
Easier said than done. HDCP is not as easy to crack as CSS was, and unlike CSS there's different keys for different devices and media. You'll have to crack the key again for every new device or Blu-Ray disc you buy.
HDCP is already cracekd. There are devices on the market which remove HDCP from a DVI/HDMI signal. There are also (very expensive) devices that are capable of capturing this video data where it can be re-encoded. All this really means is that these next two protection mechanisms are all but useless from the standpoint of trying to prevent a video from being copied and distrubited, but FWIW:
AACS as used on Blu-Ray/HD-DVD is not (yet) cracked.
The DRM that enforces the requirement of HDCP encryption on HD-resolution video output from the video card is also not (yet) cracked.
I know I didn't mention this, but although I have not (until now) run an Asterisk server in a large production environment, I have been using Asterisk experimentally for three or four years and have contributed my time and my code to its development and at times participated actively on the mailing list and the bug tracker to assist in its continued improvement.
...
That being said
I'm not so much critisizing a vendor for honesty. There are a lot of ways to say "We have had reports from our customers having problems with Asterisk." I am happy to concede that it is a very complex piece of software and difficult to learn and grasp fully, especially if all you want to do is deploy it quickly and set it up yourself without help and you are not an expert on Linux, network and telephony hardware. If you spend a lot of time really working with Asterisk in an experimental environment before you settle on equipment that you like you learn a lot of the tricks necessary to combat certain problems. I don't think there is a single problem that I have seen with an Asterisk installation that could not be rectified somehow. The tone of the original post, however, was not positive. I'd rather puchase from a vendor with a better attitude -- maybe one of the many who actively and financially support the improvement of the project instead of trying to upsell you some other solution they can make more money on.
What really bothers me more than the slam is that the poster is being so two faced about the whole thing -- pushing asterisk hard on their site to make money but complaining behind the scenes. That is a dishonest vendor, and biting the hand that feeds is no way to get my support.
It's worth repeating an AC's reply to my first reactionary post -- the original post could possibly not be someone from Atacomm.
I am unbelievably suprised to read a smear on Asterisk from a vendor as big as you guys, especially one who lists Asterisk compatibility and Digium hardware all over nearly every product they sell. I guess you do get a lot of mis-targeted fallout when dumb customers can't get thier shiny new phones to work with Asterisk, but I think it's a bit unfair to call it crap.
I am currently ordering equipment to build a small (30+ extensions) PBX for the company I work for. The total package including all cabling, PoE gear, Polycom phones, UPS's, T1 interfaces, etc. budgets to under $10,000 with Asterisk. Anything else that comes close to competing on the features we will be using is four to five times the price at minimum.
For what it's worth, I was considering placing an order for a good deal of the equipment that I need from Atacomm; however, I think it's justified to remove you from the list now.
Large multiuser audio conferences are also a huge gamer feature and a market that Intel is grabbing at desperately these days. It's all but trivial to set up an Asterisk server (There is even a LiveCD distribution IIRC) and there are plenty of free SIP clients that will happily connect. As for the conferencing in Asterisk, "MeetMe" provides for a very simple and stable solution for far more than 10 users.
... I have hated Skype from day one and the more stupid crap they continue to do like this the better I feel about my initial instinct.
I do like your idea of only being able to feed 5 calls through a proxy node (or whatever the hell they call it)
I understand your post and agree, but just for fun: the governor on BMW's.. (or at least the ones that have it) is 155 MPH and there are plenty of carmakers who advertise about how much faster their cars can go by comparison despite the fact that the BMW's speed is artifically limited. I don't think that it's hurting anybody's sales however.
Ah the C-Band dish, the state flower of West Virginia!
Mercury vapor, sodium, metal halide, etc. lamps are not actually more efficient than good flourescent tubes and ballasts, though they are probably better than compact flourescents. The reason they are used is that they have a much higher MBTF which is really the most important thing when you have to shut down a lane of traffic and pay 5 construction workers for an hour to change the bulb.
Well, there are some microwaves that are better at defrosting evenly than others in my experience, but in any case, another great way to defrost things is to put them on what is essentially a big huge heatsink. They sell these things for a whole lot of money as some kind of "magic defroster" plate, but in reality all they are is a big hunk of steel coated with teflon,. You can use any large nonstick skillet to get the same effect. They work best for defrosting meats but anything that has a large flat surface to sit down on the metal will also work. To accelerate the process, put the defrosting skillet into a larger pan with water in it. The bigger the heatsink the faster the thaw.