They offload some of the processing, but they'll still take up a hefty chunk of CPU.
I'm talking about 100% hardware MPEG decoders that take an MPEG stream in and give video out, such as the decoder on MyHD MDP-1x0 series cards. (Unfortunately not supported under Linux.) The only CPU those will use is that required to shift a stream from your hard drive to the card.
Depends on your video card, depends on your exact playback configuration (type of deinterlacing desired/used, etc).
A 1.7 GHz P4 won't cut it even with MoComp and IDCT. It doesn't even come close - I've tried. A 2 GHz P4 will barely do the job with MoComp and IDCT acceleration. If you want acceptable quality deinterlacing (The hardware deinterlacing offered by XvMC is awful, or at least it was a year ago), I haven't heard of anyone pulling it off with less than a 2.8 GHz P4 with HyperThreading.
Of course, Athlons will do this with somewhat lower clock rates, although not the typical 2/3 of an equivalent P4 that is the general rule of thumb - the P4 isn't nearly as crippled by its deep pipeline when doing video decompression as it is for most other applications.
I haven't had a chance to test HD playback on my Athlon XP 2800+ yet (no HD content available until I buy a new QAM-capable tuner card, the old one was ATSC only and never did get reliable reception), although from what I've heard it'll get by for HD playback in MythTV.
Modern video cards accelerate a decent portion of MPEG-2 playback, but you still need a decent amount of CPU.
I think with the most recent video cards, it's something like 50/50.
Note: I'm not counting hardware resolution scaling here. Output scaling is one aspect of video playback that is historically EXTREMELY CPU-hungry, but has been supported in hardware on any video card made in the past decade or more. Even with hardware scaling, you need a 2-3 GHz+ CPU to play back high def MPEG-2, and additional HW acceleration (IDCT, MoComp) offloads 20-30% at best. VIA's video chipsets offload much more of MPEG-2 playback than most other video cards, but until the CN400 series, they were only able to offload standard def content. (90% of hardware MPEG decoders on the market only support MPEG-2 MP@ML, i.e. standard def content. MP@HL decoders for high def content are rare and expensive.)
How many simultaneous calls per AP were you running?
I didn't say that 802.11g was totally unsuited to VoIP, just that the maximum capacity was much lower than one would expect given the bitrate of 11g (54 Mbps) and the required bitrate per VoIP channel (worst case 64 kbps) because the throughput penalty for small packets over 802.11g is so large. The analysis I remember reading indicated at best 24-30 concurrent VoIP connections on an 11g AP with a good codec, which is approximately the same capacity as uncompressed TDM voice over a T1 (24 concurrent 64 kbps uncompressed connections).
The problem is that people running home servers are becoming more and more common.
These CPUs would be great for machines such as home mail servers and MythTV backends, except for the fact that many such home server machines have lots of HD storage, and the power usage of the CPUs becomes small at idle compared to the power usage of the HDs.
Definately. Backend-only servers, if configured correctly, will use little to no CPU. (Unless you want to transcode from MPEG2 to MPEG4 at a lower bitrate after recording.) If recording MPEG2 from either a hardware MPEG encoder (Hauppauge PVR-150/250/350/500 for example) or an HDTV tuner card (pcHDTV HD-3000, AirStar HD5000, etc), all the system has to do is shuffle data between the card and hard drive. My PVR-350 used at most 1% of my Athlon XP 2800+ when recording, my PVR-500 probably is similar in performance but since it's in a seperate box I don't really pay attention.
For playback of SD content, Via-based Mini-ITX systems will also work well. The basic guideline is that if you can play back DVDs on a system, it should work fine as a MythTV frontend for standard def content. (Same resolutions/framerates/bitrates.)
For HD playback, it's a different story. Only the new CN400-chipset Mini-ITX boards (e.g. SP8000, SP13000) have even a chance at HD playback, but I haven't really seen any solid confirmation yet as to whether they actually do work for HD. (I've occasionally seen hints that people were using SP13000s for HD playback but I can't be sure.)
Note that for a backend, the main limitations of using a Mini-ITX box will be the number of PCI slots - if you want multiple tuners, a Mini-ITX machine may be too limited.
I wound up going with a dual-core Athlon 64 for my Myth server, in order to provide good transcoding performance, and also because it won't be used *only* for Myth serving, it will also be used as part of a compile farm and possibly a few other CPU-intensive apps I have in mind. I'm not too worried about the CPU power usage, as it'll be very low at idle compared to the 5 SATA Seagate 7200.8s running in that system.
Free, RELIABLE wi-fi is not available in nearly as many areas in the U.S. as even T-Mobile cell phone coverage. (Note: T-Mobile's coverage SUCKS. They still have far greater and more reliable coverage than free or even paid Wi-Fi.)
Also note that 802.11's channel access scheme is not well suited to transferring many small packets at low latency, which is required for VoIP. The end result is that even an 802.11g access point at full rate (54 Mbps) has trouble matching even a 1.544 Mbps T1 line in terms of VoIP capacity, *even with voice compression*. This is because the capacity limit turns out to be not the raw bitrate, but the number of *packets* per second that the system is able to handle. Small packets and 802.11 just don't mix for a number of reasons. For bulk data, there are packet bursting extensions to 802.11 that help a lot (Part of SuperG for example, and I think Broadcom's equivalent to SuperG also does bursting), but packet bursting introduces too much latency and variation in latency for VoIP.
There was a good analysis of 802.11 capacity for SIP-based VoIP somewhere, I can't remember where. Note that IAX trunks would get MUCH better capacity in this situation, but this only helps for actual trunk connections (for example, trunking across a long-range cantenna-based 11g link), not when each user has a different device connected to the AP.
"Reducing the number of cases of Avian Flu in humans by culling birds and inducing fear in the populations where it occurs all helps by reducing the chances the virus has to mutate."
Inducing fear in populations leads to a distribution nightmare for treatments.
Due to all the scare and paranoia, there is a worldwide shortage of Tamiflu despite the fact that the actual need for the drug is far lower than the production capability. The problem is that tons of people who have no actual need for it are hoarding it in advance, resulting in the few people who actually need it not getting it.
A few months ago I was at a pharmacy getting a prescription filled, and the Asian lady in front of me somehow convinced a doctor to give her three "blank check" prescriptions for Tamiflu without any patient names on them. It was pretty clear the lady didn't need it, and I'm pretty sure given the hinky nature of the prescription(s) that no one in her family actually needed it too. If they had, their doctor would have actually written the required patient names on the prescriptions. (Thankfully, the pharmacy wouldn't fill the prescriptions because they weren't legitimate without a patient name. Of course I had to wait ten minutes while the lady argued with the pharmacist...)
Well, you could, but you would lose huge amounts of power due to resistive losses in the wiring. (See previous comments about why power is distributed from the power company at over 100 kilovolts and doesn't even get stepped down to 120 or 240 volts until just outside your house.)
By one of two methods: Increasing the voltage, and using DC/DC switching regulators for "legacy" hardware. (There is a push now towards 24 and 48v automotive systems, because even with incredibly thick cables, the current draws from the battery/alternator on modern cars are just getting to be too great. 48v batteries also make pseudo-hybrid systems such as GM's FAS system feasible.)
Increasing cable thickness to reduce resistance. This gets to be expensive, difficult to manage, and heavy.
There is one problem with the GP post - Incandescent lights do NOT get more efficient as voltage decreases - low-voltage incandescents tend to be MUCH less efficient than higher voltage ones. This is the main reason why (in addition to cost), LEDs have only replaced incandescents in small battery powered devices. Low voltage incandescents have horrible efficiency and horrible bulb life (10-20 hours per bulb), while 120v incandescents have much higher efficiency and much longer bulb life. (120v incandescents are more efficient than LEDs, or at least that was the case 3-4 years ago, LEDs were improving steadily though. Neither could touch fluorescents in terms of efficiency though.)
The linear regulator approach you suggest will have an efficiency of (output voltage/input voltage) - so for 5v out from 12v in, it'll be 5/12, or less than 50%. Thus if your device consumes 5 watts, the regulator will have to dissipate 7 watts of additional power.
Replacing the linear regulator with a DC/DC switching regulator would fix this, but switchers are more complex, more expensive, and present a potential EMI problem. They are much more efficient though, and in theory can provide a wide variety of output voltages, but in reality it is best to design the switcher around a specific output voltage and load current to maximize efficiency. If you're not too concerned with getting the absolute maximum efficiency and "good" efficiency is OK, a bunch of switchers will work great for a multipurpose system. There are a wide variety of switching regulator controllers out there that use a sense input for control. The controller varies the output in order to maintain the sense input at a predetermined level, usually on the order of 1.2 volts. So you wire a resistive voltage divider across your output terminals so that when the output voltage is what you want, the sense input to the switching controller is 1.2 volts (or whatever the controller expects). The nice thing about this is that since the sense input draws almost no current, (Ideally it draws none, but nothing in the electronics world is ideal) the length of the sense input wire has no effect on output voltage. Thus, if you have a long output wire with a voltage drop and the resistive divider network at the end, the voltage at the *end* of the wire will be regulated, not the input.
BTW, this is how the "universal" power adapters like iGo and Kensington's variant on the iGo work - They have a generic switcher in the main box, and the tips have the appropriate divider network for the desired output voltage.
My total cost, including 5 250 gig drives (total $500 there) for a total of 1 TB usable RAID 5 space, an Athlon 64 X2 (massive overkill, although very nice if you want to transcode some things to a lower res/bitrate after recording), a high-end UPS, and a dual-tuner Hauppauge PVR-500 was approx. $1750 from NewEgg.
A system similar to my old Myth box (which is still my main desktop machine) could easily be built for less than $1000.
I know NewEgg is not the cheapest, but they're the cheapest vendor that I actually trust.
Nearly every time I've ordered from a company with lower prices than NewEgg, I've run into problems. Shipping estimates that proved false (e.g. getting charged $15 for shipping when my order confirmation claimed $5), bad product quality + bad return policies, etc. I remember the first time I bought a GeForce4 card - The card was defective on arrival (seemingly one of the memory address lines was bad, as every N pixels were corrupt on an intermittent basis.) Obtaining an RMA was a massive pain from the company in question (some place on Long Island with customer service that barely spoke any English), and when they got the product back they claimed that they could find no problems with it. As a result I had to eat a 15% restocking fee.
NewEgg, on the other hand, has never given me any problems. (Admittedly, in the previous case Best Buy was my fallback. Their prices usually suck, but returning items to BB is ridiculously easy.)
All that highly optimized C is part of a prewritten library (as is the case here).
For the remaining non-performance-critical stuff, Perl is often MUCH easier to develop with.
And in many cases, keep in mind the 80/20 rule of thumb. 80% of the time is spent in 20% of the code. This does vary, but in many cases the amount of highly optimized code needed for good performance is very little.
Many years ago, I was writing a program in Perl. I knew that there was a good chance I'd have to rewrite some of it in C eventually for decent performance, and this turned out to be true. In the end, I obtained 20-40 times the performance (and most likely 95%+ of the performance I would have obtained using C only) by rewriting approximately five lines out of 100-200 lines of Perl in C. The time it took me to figure out how to interface C and Perl (doing so was not documented very well then, it took me 2 weeks to find SWIG) was still far less than the time it would've taken me to write the entire program in scratch using straight C.
Given that Palm Inc. is one of PalmSource's largest licensees, I would say that PalmSource already has a pretty big foothold in the mobile market.
The Treo 600 was pretty popular, the Treo 650 is incredibly popular (and is getting huge amounts of product placement in TV shows and movies - even teenagers are packing 650s in Smallville!:) ), and while the initial release of the Verizon Treo 700w is Windows Mobile based, there are lots of rumors with some substantiation that a Sprint Treo 700p is under development. The Treo 750 may likely be using this new Linux-based PalmOS version.
BTW, a Linux-based PalmOS isn't exactly new news - it's been known for quite a while that the next generation of PalmOS was going to be based on Linux.
Firewire - 400 or 800 Mbps (megabits/second) = 50-100 MB/second (Megabytes/second) minus overhead PCI (standard old PCI) - 32 bits @ 33 MHz in most configurations = 133 MB/second 64-bit and 66 MHz PCI existed but were rare. Even standard PCI is faster than 1394. AGP - 1x is 266 MB/sec, 4x is 1066 MB/s, and 8x is 2133 MB/s PCI Express - x1 is 250 MB/sec, x16 is 4000 MB/sec (in both cases, this is minus some unknown amount of overhead.)
I've been a huge GNOME fan in the past, I hated KDE every time I used it for quite some time. I also was never too happy with some of the developers' blatant disregard for licensing problems, which didn't go away until the controversy essentially forced TrollTech to release a GPL-licensed version of Qt so that the only major application using their toolkit could be used legally.
Unfortunately, thanks to the likes of idiots like Havoc Pennington who claim to be gods of user interface design but don't actually have ANY real credentials in terms of human interface design, and obtain their rationales from other sources who have no actual credentials in the area of human interface design, GNOME has become completely unusuable for me. I simply can't live without basic productivity features such as edge flipping. After years of people bitching about the GNOME file selection dialog, what did the GNOME devs do? They made it WORSE. How can anyone justify having to hit control-L to type in a file path in the name of usability? Yet that is what they did - in order to actually use the new GNOME file dialog, you need to hit a key combination that is basically undocumented.
So I've switched to KDE. It's far less polished than GNOME and has quite a few more bugs, but it isn't as buggy as the workarounds needed to get decent usability out of GNOME such as brightside (which crashed on a regular basis but was the only way to get edge flipping to work reasonably well in GNOME. The day GNOME changes broke brightside is the day I switched to KDE.)
The article mentions quite a few corporate-hosted AJAX desktops.
Are there any similar open-source entries in the market for those of us who might want a "usable from anywhere" solution but which is hosted on a machine we control?
I currently use Horde IMP for web-based email, and I'm thinking of possibly installing FCKEditor on my home server box, but I'm wondering if there's an "all in one" solution out there.
Slashdot Mirror
The people who created Vorbis took care to search for any patents covering audio codecs, and then avoid them.
You'd be surprised at the narrow scope of many patents.
They offload some of the processing, but they'll still take up a hefty chunk of CPU.
I'm talking about 100% hardware MPEG decoders that take an MPEG stream in and give video out, such as the decoder on MyHD MDP-1x0 series cards. (Unfortunately not supported under Linux.) The only CPU those will use is that required to shift a stream from your hard drive to the card.
Depends on your video card, depends on your exact playback configuration (type of deinterlacing desired/used, etc).
A 1.7 GHz P4 won't cut it even with MoComp and IDCT. It doesn't even come close - I've tried.
A 2 GHz P4 will barely do the job with MoComp and IDCT acceleration.
If you want acceptable quality deinterlacing (The hardware deinterlacing offered by XvMC is awful, or at least it was a year ago), I haven't heard of anyone pulling it off with less than a 2.8 GHz P4 with HyperThreading.
Of course, Athlons will do this with somewhat lower clock rates, although not the typical 2/3 of an equivalent P4 that is the general rule of thumb - the P4 isn't nearly as crippled by its deep pipeline when doing video decompression as it is for most other applications.
I haven't had a chance to test HD playback on my Athlon XP 2800+ yet (no HD content available until I buy a new QAM-capable tuner card, the old one was ATSC only and never did get reliable reception), although from what I've heard it'll get by for HD playback in MythTV.
Modern video cards accelerate a decent portion of MPEG-2 playback, but you still need a decent amount of CPU.
I think with the most recent video cards, it's something like 50/50.
Note: I'm not counting hardware resolution scaling here. Output scaling is one aspect of video playback that is historically EXTREMELY CPU-hungry, but has been supported in hardware on any video card made in the past decade or more. Even with hardware scaling, you need a 2-3 GHz+ CPU to play back high def MPEG-2, and additional HW acceleration (IDCT, MoComp) offloads 20-30% at best. VIA's video chipsets offload much more of MPEG-2 playback than most other video cards, but until the CN400 series, they were only able to offload standard def content. (90% of hardware MPEG decoders on the market only support MPEG-2 MP@ML, i.e. standard def content. MP@HL decoders for high def content are rare and expensive.)
Go to T-Mobile's website. Look at New York State on their coverage map.
Then compare it to Verizon's coverage map of the same area.
Compared to VZW up there, T-Mo's coverage is utterly abysmal.
There's a reason T-Mo is so cheap as far as cost per minute - you get what you pay for.
How many simultaneous calls per AP were you running?
I didn't say that 802.11g was totally unsuited to VoIP, just that the maximum capacity was much lower than one would expect given the bitrate of 11g (54 Mbps) and the required bitrate per VoIP channel (worst case 64 kbps) because the throughput penalty for small packets over 802.11g is so large. The analysis I remember reading indicated at best 24-30 concurrent VoIP connections on an 11g AP with a good codec, which is approximately the same capacity as uncompressed TDM voice over a T1 (24 concurrent 64 kbps uncompressed connections).
The problem is that people running home servers are becoming more and more common.
These CPUs would be great for machines such as home mail servers and MythTV backends, except for the fact that many such home server machines have lots of HD storage, and the power usage of the CPUs becomes small at idle compared to the power usage of the HDs.
A pure "backend only" server?
Definately. Backend-only servers, if configured correctly, will use little to no CPU. (Unless you want to transcode from MPEG2 to MPEG4 at a lower bitrate after recording.) If recording MPEG2 from either a hardware MPEG encoder (Hauppauge PVR-150/250/350/500 for example) or an HDTV tuner card (pcHDTV HD-3000, AirStar HD5000, etc), all the system has to do is shuffle data between the card and hard drive. My PVR-350 used at most 1% of my Athlon XP 2800+ when recording, my PVR-500 probably is similar in performance but since it's in a seperate box I don't really pay attention.
For playback of SD content, Via-based Mini-ITX systems will also work well. The basic guideline is that if you can play back DVDs on a system, it should work fine as a MythTV frontend for standard def content. (Same resolutions/framerates/bitrates.)
For HD playback, it's a different story. Only the new CN400-chipset Mini-ITX boards (e.g. SP8000, SP13000) have even a chance at HD playback, but I haven't really seen any solid confirmation yet as to whether they actually do work for HD. (I've occasionally seen hints that people were using SP13000s for HD playback but I can't be sure.)
Note that for a backend, the main limitations of using a Mini-ITX box will be the number of PCI slots - if you want multiple tuners, a Mini-ITX machine may be too limited.
I wound up going with a dual-core Athlon 64 for my Myth server, in order to provide good transcoding performance, and also because it won't be used *only* for Myth serving, it will also be used as part of a compile farm and possibly a few other CPU-intensive apps I have in mind. I'm not too worried about the CPU power usage, as it'll be very low at idle compared to the 5 SATA Seagate 7200.8s running in that system.
Free, RELIABLE wi-fi is not available in nearly as many areas in the U.S. as even T-Mobile cell phone coverage. (Note: T-Mobile's coverage SUCKS. They still have far greater and more reliable coverage than free or even paid Wi-Fi.)
Also note that 802.11's channel access scheme is not well suited to transferring many small packets at low latency, which is required for VoIP. The end result is that even an 802.11g access point at full rate (54 Mbps) has trouble matching even a 1.544 Mbps T1 line in terms of VoIP capacity, *even with voice compression*. This is because the capacity limit turns out to be not the raw bitrate, but the number of *packets* per second that the system is able to handle. Small packets and 802.11 just don't mix for a number of reasons. For bulk data, there are packet bursting extensions to 802.11 that help a lot (Part of SuperG for example, and I think Broadcom's equivalent to SuperG also does bursting), but packet bursting introduces too much latency and variation in latency for VoIP.
There was a good analysis of 802.11 capacity for SIP-based VoIP somewhere, I can't remember where. Note that IAX trunks would get MUCH better capacity in this situation, but this only helps for actual trunk connections (for example, trunking across a long-range cantenna-based 11g link), not when each user has a different device connected to the AP.
Ebola Reston is named after Restion, Virginia, a suburb of Washington, D.C. Not the state of Washington.
Also I believe there is a second African strain of Ebola that is less lethal than Zaire but still lethal to humans.
I think it's a lot harder to make a vaccine against bacterial infection than against a viral one.
This is why vaccines against bacterial infections (lyme, meningitis) have only recently appeared on the market.
For a very long time, only viral infections could be prevented by vaccination.
"Reducing the number of cases of Avian Flu in humans by culling birds and inducing fear in the populations where it occurs all helps by reducing the chances the virus has to mutate."
Inducing fear in populations leads to a distribution nightmare for treatments.
Due to all the scare and paranoia, there is a worldwide shortage of Tamiflu despite the fact that the actual need for the drug is far lower than the production capability. The problem is that tons of people who have no actual need for it are hoarding it in advance, resulting in the few people who actually need it not getting it.
A few months ago I was at a pharmacy getting a prescription filled, and the Asian lady in front of me somehow convinced a doctor to give her three "blank check" prescriptions for Tamiflu without any patient names on them. It was pretty clear the lady didn't need it, and I'm pretty sure given the hinky nature of the prescription(s) that no one in her family actually needed it too. If they had, their doctor would have actually written the required patient names on the prescriptions. (Thankfully, the pharmacy wouldn't fill the prescriptions because they weren't legitimate without a patient name. Of course I had to wait ten minutes while the lady argued with the pharmacist...)
"One can wire his house in this voltage."
No you can't.
Well, you could, but you would lose huge amounts of power due to resistive losses in the wiring. (See previous comments about why power is distributed from the power company at over 100 kilovolts and doesn't even get stepped down to 120 or 240 volts until just outside your house.)
By one of two methods:
Increasing the voltage, and using DC/DC switching regulators for "legacy" hardware. (There is a push now towards 24 and 48v automotive systems, because even with incredibly thick cables, the current draws from the battery/alternator on modern cars are just getting to be too great. 48v batteries also make pseudo-hybrid systems such as GM's FAS system feasible.)
Increasing cable thickness to reduce resistance. This gets to be expensive, difficult to manage, and heavy.
There is one problem with the GP post - Incandescent lights do NOT get more efficient as voltage decreases - low-voltage incandescents tend to be MUCH less efficient than higher voltage ones. This is the main reason why (in addition to cost), LEDs have only replaced incandescents in small battery powered devices. Low voltage incandescents have horrible efficiency and horrible bulb life (10-20 hours per bulb), while 120v incandescents have much higher efficiency and much longer bulb life. (120v incandescents are more efficient than LEDs, or at least that was the case 3-4 years ago, LEDs were improving steadily though. Neither could touch fluorescents in terms of efficiency though.)
Bad idea.
The linear regulator approach you suggest will have an efficiency of (output voltage/input voltage) - so for 5v out from 12v in, it'll be 5/12, or less than 50%. Thus if your device consumes 5 watts, the regulator will have to dissipate 7 watts of additional power.
Replacing the linear regulator with a DC/DC switching regulator would fix this, but switchers are more complex, more expensive, and present a potential EMI problem. They are much more efficient though, and in theory can provide a wide variety of output voltages, but in reality it is best to design the switcher around a specific output voltage and load current to maximize efficiency. If you're not too concerned with getting the absolute maximum efficiency and "good" efficiency is OK, a bunch of switchers will work great for a multipurpose system. There are a wide variety of switching regulator controllers out there that use a sense input for control. The controller varies the output in order to maintain the sense input at a predetermined level, usually on the order of 1.2 volts. So you wire a resistive voltage divider across your output terminals so that when the output voltage is what you want, the sense input to the switching controller is 1.2 volts (or whatever the controller expects). The nice thing about this is that since the sense input draws almost no current, (Ideally it draws none, but nothing in the electronics world is ideal) the length of the sense input wire has no effect on output voltage. Thus, if you have a long output wire with a voltage drop and the resistive divider network at the end, the voltage at the *end* of the wire will be regulated, not the input.
BTW, this is how the "universal" power adapters like iGo and Kensington's variant on the iGo work - They have a generic switcher in the main box, and the tips have the appropriate divider network for the desired output voltage.
Build from the ground up.
My total cost, including 5 250 gig drives (total $500 there) for a total of 1 TB usable RAID 5 space, an Athlon 64 X2 (massive overkill, although very nice if you want to transcode some things to a lower res/bitrate after recording), a high-end UPS, and a dual-tuner Hauppauge PVR-500 was approx. $1750 from NewEgg.
A system similar to my old Myth box (which is still my main desktop machine) could easily be built for less than $1000.
Good point.
Also, not portable in terms of potential customers.
It tells you EXACTLY what the $2.99 gets you.
No, they don't sit on your order without it. Yes, most of the time unless you order late in the day, it won't actually make a difference.
I know NewEgg is not the cheapest, but they're the cheapest vendor that I actually trust.
Nearly every time I've ordered from a company with lower prices than NewEgg, I've run into problems. Shipping estimates that proved false (e.g. getting charged $15 for shipping when my order confirmation claimed $5), bad product quality + bad return policies, etc. I remember the first time I bought a GeForce4 card - The card was defective on arrival (seemingly one of the memory address lines was bad, as every N pixels were corrupt on an intermittent basis.) Obtaining an RMA was a massive pain from the company in question (some place on Long Island with customer service that barely spoke any English), and when they got the product back they claimed that they could find no problems with it. As a result I had to eat a 15% restocking fee.
NewEgg, on the other hand, has never given me any problems. (Admittedly, in the previous case Best Buy was my fallback. Their prices usually suck, but returning items to BB is ridiculously easy.)
All that highly optimized C is part of a prewritten library (as is the case here).
For the remaining non-performance-critical stuff, Perl is often MUCH easier to develop with.
And in many cases, keep in mind the 80/20 rule of thumb. 80% of the time is spent in 20% of the code. This does vary, but in many cases the amount of highly optimized code needed for good performance is very little.
Many years ago, I was writing a program in Perl. I knew that there was a good chance I'd have to rewrite some of it in C eventually for decent performance, and this turned out to be true. In the end, I obtained 20-40 times the performance (and most likely 95%+ of the performance I would have obtained using C only) by rewriting approximately five lines out of 100-200 lines of Perl in C. The time it took me to figure out how to interface C and Perl (doing so was not documented very well then, it took me 2 weeks to find SWIG) was still far less than the time it would've taken me to write the entire program in scratch using straight C.
Given that Palm Inc. is one of PalmSource's largest licensees, I would say that PalmSource already has a pretty big foothold in the mobile market.
:) ), and while the initial release of the Verizon Treo 700w is Windows Mobile based, there are lots of rumors with some substantiation that a Sprint Treo 700p is under development. The Treo 750 may likely be using this new Linux-based PalmOS version.
The Treo 600 was pretty popular, the Treo 650 is incredibly popular (and is getting huge amounts of product placement in TV shows and movies - even teenagers are packing 650s in Smallville!
BTW, a Linux-based PalmOS isn't exactly new news - it's been known for quite a while that the next generation of PalmOS was going to be based on Linux.
How big is this jackpot you propose?
:)
p.s. GP poster's ID is not low, 4099 is damn high.
Firewire - 400 or 800 Mbps (megabits/second) = 50-100 MB/second (Megabytes/second) minus overhead
PCI (standard old PCI) - 32 bits @ 33 MHz in most configurations = 133 MB/second 64-bit and 66 MHz PCI existed but were rare. Even standard PCI is faster than 1394.
AGP - 1x is 266 MB/sec, 4x is 1066 MB/s, and 8x is 2133 MB/s
PCI Express - x1 is 250 MB/sec, x16 is 4000 MB/sec (in both cases, this is minus some unknown amount of overhead.)
I've been a huge GNOME fan in the past, I hated KDE every time I used it for quite some time. I also was never too happy with some of the developers' blatant disregard for licensing problems, which didn't go away until the controversy essentially forced TrollTech to release a GPL-licensed version of Qt so that the only major application using their toolkit could be used legally.
Unfortunately, thanks to the likes of idiots like Havoc Pennington who claim to be gods of user interface design but don't actually have ANY real credentials in terms of human interface design, and obtain their rationales from other sources who have no actual credentials in the area of human interface design, GNOME has become completely unusuable for me. I simply can't live without basic productivity features such as edge flipping. After years of people bitching about the GNOME file selection dialog, what did the GNOME devs do? They made it WORSE. How can anyone justify having to hit control-L to type in a file path in the name of usability? Yet that is what they did - in order to actually use the new GNOME file dialog, you need to hit a key combination that is basically undocumented.
So I've switched to KDE. It's far less polished than GNOME and has quite a few more bugs, but it isn't as buggy as the workarounds needed to get decent usability out of GNOME such as brightside (which crashed on a regular basis but was the only way to get edge flipping to work reasonably well in GNOME. The day GNOME changes broke brightside is the day I switched to KDE.)
The article mentions quite a few corporate-hosted AJAX desktops.
Are there any similar open-source entries in the market for those of us who might want a "usable from anywhere" solution but which is hosted on a machine we control?
I currently use Horde IMP for web-based email, and I'm thinking of possibly installing FCKEditor on my home server box, but I'm wondering if there's an "all in one" solution out there.