Plenty of low/zero carb energy drinks out there
on
An Energy Drinks Roundup?
·
· Score: 2, Insightful
They're a bit harder to find - often a store will only have the sugared version.
Of the ones I've tried (I've tried a lot over the past few months), I can't tell any difference in their actual ability to give me energy. They don't help if I'm totally exhausted (very late at night), they don't make me feel super-tiptop-shape (they are a bit overhyped in this regard.) They DO help me feel a bit more human (more so than caffeine only) if I'm a bit borderline. (Such as any time before noon.)
A list of most of the ones I've tried, one or two are missing - all of these are only the low/zero carb variants (I'm diabetic, so the high-sugar versions are out of the question):
Bawls - Tastes great, but it's very expensive, hard to find, and doesn't give me any more boost than Mountain Dew (that is to say, almost no boost at all.)
Rockstar - Works, but tastes like crap.
Red Bull - Actually, I've only had a small amount of the normal non-low-carb version once at a bar. It tasted like crap and I didn't go near energy drinks for over a year because I assumed they all tasted like crap. From what I recall, it was the same taste as Rockstar.
Von Dutch - UGH HORRIBLE. Even worse than Rockstar and Red Bull. The only energy drink I haven't even been able to finish an entire can of. No wonder it was on clearance where I bought it.
Full Throttle - One of the easiest non-RedBull energy drinks to find, it has a sharp citrusy taste that is somewhat (but not very) similar to Mountain Dew, except with a bit more bite to it. Probably my third favorite as far as taste goes.
MDX - One of the more readily available energy drinks, and typically cheaper than most others. Taste is very similar to Mountain Dew, except a much smoother taste with less bite. My second favorite in terms of taste.
Monster - Also a fruity/citrusy taste, but extremely smooth. Not even remotely close to Mountain Dew though. By far the most delicious of the energy drinks I've tasted (even if it didn't give me any energy, I'd probably continue drinking it just because it tastes so damn good.), and it also does a good job of making me feel human in the morning.
What other effects might this have?
on
Toy Story 3 Scrapped
·
· Score: 4, Insightful
Ignoring all of the possible positive potential this might have on the creative process at Disney, this isn't the only effect the merger might have.
Keep in mind that until the Sony rootkit, Disney has historically been one of the worst offenders as far as pushing DRM. (If I recall correctly, they were one of the most solid backers of DIVX - no, not DivX, DIVX. There's a big difference. I'm also pretty sure they were also one of the only backers of DIVX that apparently intended not to ever allow customers to "silver" a disc - paying a one time flat fee for unlimited viewing, you would only ever be able to view your Disney DIVX discs as pay-per-view.)
Jobs, on the other hand (well, at least Apple with him at the helm), has had a much more lenient approach with DRM. Apple's DRM has typically been described as "the bare minimum to keep content providers happy", and Apple has actively resisted attempts to force increases in the restrictions of their DRM. Keep in mind that throughout this all, Jobs was also a content provider, since he also ran Pixar.
Could Jobs calling the shots at Disney mean a more consumer-friendly Disney? I hope so.
The article you linked to stated insane floating point performance, not insane integer performance. Thus the Cell isn't necessarily going to perform well for crypto (crypto is integer-based, not FP.) The Cell in general is highly optimized for FP performance.
Your link to an IBM Cell-based blade server means nothing as far as the Cell's suitability for general purpose computing. Keep in mind that many of IBM's customers purchase VERY large special-purpose systems. Building a blade motherboard based on Cell for those that want to perform scientific computing (one of the few areas where Cell will excel at) is nothing compared to designing an entire custom special purpose processor, which IBM *has* done for at least two customers - Microsoft (Xbox 360) and Lawrence Livermore National Laboratories (BlueGene/L uses custom CPUs designed specifically for the type of work BlueGene/L does.)
Myself, I do indeed look forward to playing with a Cell-based system, but that's because my focus in graduate school was on signal processing for communications, which is one of the areas at which the Cell does excel. But there's no way I'm ever going to spec a Cell processor for a general purpose machine.
"IBM cell based hardware running GNU/Linux is going to blow all of this trash into a distantly remembered nightmare."
No, it isn't. It's not even going to come close. It's not even going to exist, ever. 90% of the Cell's computing horsepower is in the SPUs, which are optimized for signal processing and geometry processing applications (namely, grinding away on lots of number crunching). No instruction reordering, floating-point only, and very limited branching functionality. The coprocessors are more comparable to devices such as Analog Devices' TigerSHARC or TI's TMS320 series than any general purpose CPU. Despite the insane floating point performance, you don't see TigerSHARC or TMS320 based computers, do you? That's because they are not suitable for general purpose computing in any way.
The Cell's general purpose "controller" CPU is an incredibly stripped down PPC core that has incredibly low performance compared to any standard general purpose CPU.
While it will have incredible performance for gaming and signal processing, the Cell is an utterly crap CPU for general purpose computing. Using a Cell in a normal desktop machine is like trying to cut a tree trunk with a cordless electric drill rather than a reciprocating saw. No matter how nice of a drill it is, it's going to do a shitty job compared to even the cheapest recipro saw, if it manages to do the job at all.
For a desktop system, I'll take AMD over Intel any day, especially one I've specced and built myself. I've got the parts for an Athlon 64 X2-based system on the way to my door from NewEgg right now.:)
For a pre-purchased desktop system, I'd prefer AMD over Intel, but unfortunately, prebuilt systems with AMD CPUs often aren't the nicest systems available. There are some (such as Sun's Opteron-based machines), but it's a lot harder to find a prebuilt system with high overall quality which contains an AMD CPU than with an Intel CPU. That's why my fathers' new file server is Intel-based - you can't get Dell PowerEdge systems with AMD CPUs. Say what you want about Dell, while some of their lower-end systems may be crap, my experience has been that their higher end servers and laptops are incredibly solid and well designed systems. The PE830 has one of the nicest internal designs I've seen in a long time, and both my father's Inspiron 8000 and my I8200 have been flawless for me. (Or at least, have been since I nuked XP from my 8200 and installed Win2k because XP's SpeedStep implementation is utter fucking crap compared to Intel's SpeedStep control applet for Win2k.)
When it comes to laptops, Intel is the only viable choice. Whether or not the Turion 64 is better or worse than the Pentium M, it's impossible to actually buy a high-end Turion 64 based machine from a reputable vendor. Every Turion-based system I've seen has been either from a small-time noname vendor or is an incredibly low-end system (crappy screen, crappy video card, etc). There simply are no Turion-based systems that can even come close to competing with IBM/Lenovo ThinkPads or Dell's higher-end Inspirons like the XPS M170, the 9300, and 9400. If there are, they are impossible to find.
Still, prior art is prior art in that case. Doesn't really change anything in my example.:)
Broad Patents vs. Narrow Patents
on
Hopes Rise for RIM
·
· Score: 3, Informative
I believe NTP's patents are on a much narrower definition of the way RIM's system works.
i.e. they haven't patented sending text messages between devices, they've patented a very specific method of making email available to a mobile device. I don't recall, but I believe the patent deals partially with the corporate firewall problem.
In short, whether it is valid or not, their patent does not apply to packet radio, nor can packet radio be considered prior art for the system.
A good example. Joe Caveman invents the wheel in 500 B.C.
In 1990, John Doe invents a specific tread pattern for a rubber tire that has some Really Nifty Benefit. It's based on the wheel, but enhances it. John Doe can't patent the wheel due to prior art (Joe Caveman in 500 B.C.), but John can patent his specific enhancement of the wheel.
Did you buy desktop-targeted SATA drives (like the Maxtor DiamondMax series, known for having major problems), or server-targeted ones like the Maxtor MAXLine nearline drives, WD Caviar RE2 nearline drives, or the WD Raptors?
SATA itself blows SCSI out of the water in terms of cabling reliability. It's even in terms of performance features such as NCQ. You just have to be careful not to buy a desktop grade drive. (It's impossible to buy a desktop grade SCSI drive. It IS possible to buy a server grade SATA drive that has been tested as rigorously as its SCSI counterpart, you just have to be more careful with the drive purchase.)
I had one bad experience that resulted in massive data corruption.
I had routine bad experiences with systems that wouldn't boot due to something in the SCSI chain flaking out.
It's too damn easy for a single failure somewhere in the chain to take down the entire bus.
Meanwhile, if there's a failure on an SATA channel, only one drive is taken out of commission (unless you're using an SATA port multiplier, which you shouldn't be if you care about performance or reliability).
The fact that SATA cables have fewer conductors and hence are much thinner means they can be routed more easily within a case in a manner that does not produce stress on the connectors. Stress on the connectors reduces reliability. Also, every SCSI connector I've seen that was designed for internal system use had no inherent method of securing it to the device. (Neither did IDE by the way, although IDE connectors always had a tendency to fit tightly, unlike those horrific SCA connectors on many SCSI drives, which are loose as hell.) SATA connectors are designed to clip into whatever they're plugged in to.
In short, while you may be able to come up with a reliable SCSI cabling setup, it's going to require a huge amount of money, research, and trial and error. SATA, on the other hand, will Just Work. Don't forget the fact that with SATA, you no longer need to deal with SCSI IDs, termination, or in the case of IDE, master/slave issues.
Here's a good analogy: SCSI is like 10base2 Thinnet (remember, where one failure or improper termination would take down the entire network?), and SATA is switched 10baseT (failure in the equipment connected to one port has no effect on the other ports). 10base2 was technically superior when it came out, but does anyone use it anymore? I've seen it in use once in the past decade (back in 1999 or so), care to take a guess how I found out it was in use? Yup, an entire network segment failed at a place I was working due to a loose connector.
In the case of an autoimmune response causing immunodeficiency, then the disease isn't actually AIDS.
AIDS - Acquired ImmunoDeficiency Syndrome. Note the Acquired. If it wasn't actually *acquired* from somewhere but instead happened due to a genetic defect, it isn't actually AIDS by definition.
Thus, in the case you state, the immune deficiency is not actually AIDS. (There ARE other known immunodeficiency disorders. While they aren't caused by HIV, in fact many are caused by genetic defects, they aren't AIDS either.) Most likely the idiots claiming "AIDS without HIV" are actually confusing an immunodeficiency disorder that is not actually AIDS and calling it AIDS, even though it isn't actually AIDS.
SATA's peak raw transfer rate (150 MB/sec) is half that of the peak raw transfer rate of SCSI (320 MB/sec), but you're going to be limited by the individual hard drive's transfer rate anyway. Keep in mind that a proper SATA implementation will be 150MB/sec PER DRIVE, since each drive is on its own channel. SCSI is 320 MB/sec per channel, but you're in for a cabling nightmare if you want only one drive per channel. Note that there is a 300 MB/sec SATA standard, although few drives and controllers seem to support it.
If you buy the right model, you can get SATA drives that have gone through the rigorous quality control testing that has historically been reserved for SCSI drives. Many of the higher end server-grade SATA models are warrantied for 24/7 operation. SCSI has lost its advantage there.
SATA has Native Command Queueing, formerly a SCSI-only performance feature. Note that it's optional for SATA drives though, so make sure you get a controller and drives that support NCQ. Again, one of SCSI's few advantages has disappeared.
Last, but most definately not least, SATA cabling is far simpler and robust than SCSI cabling. SCSI cabling is a finicky nightmare where even high-end cables can cause data corruption if you're not careful, whereas even the cheapest SATA cables I've seen worked reliably. I've had hardware related data loss on hard drives twice in my life. One case was an IBM Deathstar, the other was a SCSI cable that started flaking out and corrupted data on three drives at once. I haven't touched SCSI with a ten foot pole since that incident.
1) domU instances don't get access to the graphics hardware. If you want hardware video acceleration, virtualization is currently not an option. There's a chance that you can do it in a case where your system has multiple video cards, but so far there is no solution for concurrent access to the same video card.
2) dom0 instances (generally considered the "host") OS actually run under Xen too. Apparently (according to the Xen mailing lists) dom0 OSes actually need more modifications than domUs. Thus, it may not be possible to use OSX as a dom0.
Please name one pair of competing driver projects where both projects are currently active. (e.g. the ar5k project is long dead and was superseded by madwifi well a year or two ago at least, so the ar5k project does not count)
Watch out for the WPNT511 (RangeMax 240) - those are Airgo-based. Currently the only 11g chipset manufacturer I know of without any native Linux support in any form. (add Broadcom if you don't want to count the recently released experimental Broadcom native drivers.)
If you want rock-solid integrated-into-the-kernel support, go with an older 11b chipset. Classic Ciscos and Orinoco Golds have some of the highest RF frontend performance available. (More sensitive receivers than most prism2 chipsets). This is if you are using PCMCIA - If you are using PCI, then most of the 802.11 chipsets suck. 90% of PCI-based b-only solutions are PCMCIA cards in a PCI to PCMCIA bridge. IRQ problems galore!
If you want 11g or a good PCI solution, then your best bets are probably Intel or Atheros based chipsets. I use a Netgear RangeMax (WPN511) card in my laptop with a RangeMax router (WPN824). They work incredibly well, although turbo (108Mbps support) is still iffy. 54Mbps support has been rock solid with madwifi in my experience, and the madwifi-ng drivers have some insanely nifty features (such as multiple virtual station/AP interfaces bound to the same card.)
Avoid the RangeMax 240 series (WPNT511, and WPNT834). Those are Airgo-based, which at the moment is one of the only remaining chipsets with no native support whatsoever.
There's one other chipset without any Linux support - the Airgo MIMO chipset(s)
The good news is that there's a grand total of only 3-4 adapters based on Airgo's chipset. Unfortunately Belkin produces one of them (their Pre-N gear is Airgo-based). Linksys SRX and Netgear RangeMax 240 (not the old RangeMax, the new RM 240 stuff) are the only other two I can think of at the moment. (I'm pretty sure there is one other Airgo-based unit.)
When it comes to WLAN support, as long as you avoid Broadcom chipsets (semi-common, but it takes ten minutes of Googling to find if your card is a Broadcom paperweight) and Airgo chipsets (rare as hell - only 3-4 Airgo-based cards exist, the Belkin pre-N hardware being one of those three) are about the only ones that don't have a native Linux driver now.
Atheros - supported by madwifi Intersil - Supported by the various Prism variants (either linux-wlan, the kernel prism/hermes drivers, or the prism54 drivers) Cisco - Supported (new Ciscos are Atheros-based anyway I believe) Orinocos - Old ones are supported with a very stable driver. New ones are Atheros-based. Atmel - I believe these are USB-only, and are supported. Intel - Supported
The list of cards that are natively supported (although not necessarily in the main kernel tree) is very long.
Given the recent advent of a native Broadcom driver (although currently experimental), it looks like the original poster bought one of the sum total of *four* cards on the market based on one of Airgo's MIMO chipsets. Those would be:
Linksys SRX (note - Avoid Linksys if you're concerned about stable and reliable Linux support, as most of their newer cards are Broadcom bombs.) Belkin Pre-N NetGear RangeMax 240 (the previous gen RangeMax equipment is Atheros-based though, my WPN511 works beautifully under Linux.) There's one other but I don't recall the manufacturer at the moment.
IIRC, Linus added one or two clauses to the GPL allowing for binary modules.
i.e. it's 99% GPL, but some modifications were made to the initial release. This IS legal - The initial author of some software can release it under any license they want. Either that, or it was deemed that due to the way the kernel module loading system worked, non-GPL modules were allowed to exist.
The end result, whatever the means, is that non-GPL (including binary-only) kernel modules are perfectly legal (albeit frowned upon - the kernel bitches with "taint" warnings when you load a non-GPL module.)
I found there was a lot of egotism and greed. The rich got richer, while the poor stayed poor. This even happened within large corps like Xan - not only was the corp rich, but some of the members were filthy rich too. The same members who would tell everyone else they needed to spend more time contributing to the corporation. People who could get multiple battleships blown up in one day, while I would have to spend multiple days to recoup a battleship loss. The end result was lots of infighting that eventually resulted in Xanadu splitting in half 1-2 months after I left. I left the game rather than stay around and potentially destroy friendships. Those that stayed wound up dealing with that rift, and I know that there were many cases where people had friends on the other side of the rift.
Phoenix Alliance - weren't they up "north" somewhere?
Or is that what FA became after the big Xan split? (Remember, I quit the game a month or so before then.)
I didn't like EVE's PvP at all - hours of boredom followed by 15-30 seconds of excitement.
CCP's sledgehammer approach to fixes really annoyed me. Rather than making slight adjustments, they'd make huge ones that would wind up with them adjusting the other way not too far down the line. The end result is that nothing ever stablized, and nothing ever actually got fixed properly.
DAoC has its own problems, but overall it's a bit more stable and Mythic are much more careful with fixes/adjustments/nerfs than CCP. Most importantly, the game mechanics are much less conducive to intra-guild strife than EVE was. EVE had a bad tendency to make bitter enemies out of former friends.
I played EVE for around 9 months. Independent for 1-2, then finally got back into Xanadu (I was Xanadu in Planetarion, but being a member in PA didn't guarantee EVE membership. I wouldn't have played EVE if not for Xan though.)
EVE had a great concept, but it was too full of bugs and no real endgame other than mindless mining and farming NPCs in 0.0 space. There was supposed to be this rich commerce market, but the truth was that the commerce market crashed almost instantly with oversupply, and the only people who could make profit were those that controlled the rare Tech 2 blueprints. The problem is that CCP made it too easy for one player organization to control the T2 market. (Yes, I know that organization happened to be MY corporation. I disliked what happened nearly as much as the little guys that got stepped on, partly because I did spend 1-2 months as the "little guy".)
I got tired of the game, and while I loved Xanadu, the game mechanics caused us to fight internally way too often. I wound up leaving the game before it destroyed friendships. Unfortunately, not everyone was so smart - I don't recall the details but Xan tore itself in half a month or two later. I wasn't surprised.
I play Dark Age of Camelot now, which has a much simpler concept (bad in some ways) but a much more well thought out endgame (very good) and game mechanics that don't easily contribute to strife within guilds/corporations/whatever they may be called in a given game. The only bad thing is that none of my former Xan buddies play.:(
StrongARM was a DEC product, but remember that while Compaq bought most of DEC, Intel bought DEC's semiconductor business.
Intel quickly killed Alpha (although I think somehow Compaq still had some control of Alpha too, I think the Alpha was a special exception but I can't be sure), but the StrongARM was so good that it overrode Intel's Not-Invented-Here syndrome. The PXA (Xscale) series is just marketing speak for the new StrongARM. Probably the same design team as the original SAs.
Not sure exactly what happened with DEC's networking chipset line. I know Intel was selling Tulips for a while, but I think eventually all of the old DEC-based designs were phased out, although most likely Intel's newer networking chipsets probably include some of the neat stuff that made Tulips so nice back in the day.
Yeah, I use it despite the fact that it's a CPU hog.
Strangely enough, I've sometimes had MAJOR performance issues with the original BT client (which I used to swear by) - At some point it began acting like my router's ports were not open (they were), Azureus had much more consistent performance. Azureus also let me only download some files in a multi-file torrent (good when I had a few episodes from a season of TV already and wanted to fill in the gaps using a whole-season torrent).
Unfortunately, Azureus is a massive resource hog, and what's worse is that it's GUI-only, which means I can't run it on an X-less machine, or that I have to restart it if I log out of X and back in for some reason. As a result, my share ratio isn't quite what it should be because I often forget to fire Azureus back up after a reboot.
Slashdot Mirror
They're a bit harder to find - often a store will only have the sugared version.
Of the ones I've tried (I've tried a lot over the past few months), I can't tell any difference in their actual ability to give me energy. They don't help if I'm totally exhausted (very late at night), they don't make me feel super-tiptop-shape (they are a bit overhyped in this regard.) They DO help me feel a bit more human (more so than caffeine only) if I'm a bit borderline. (Such as any time before noon.)
A list of most of the ones I've tried, one or two are missing - all of these are only the low/zero carb variants (I'm diabetic, so the high-sugar versions are out of the question):
Bawls - Tastes great, but it's very expensive, hard to find, and doesn't give me any more boost than Mountain Dew (that is to say, almost no boost at all.)
Rockstar - Works, but tastes like crap.
Red Bull - Actually, I've only had a small amount of the normal non-low-carb version once at a bar. It tasted like crap and I didn't go near energy drinks for over a year because I assumed they all tasted like crap. From what I recall, it was the same taste as Rockstar.
Von Dutch - UGH HORRIBLE. Even worse than Rockstar and Red Bull. The only energy drink I haven't even been able to finish an entire can of. No wonder it was on clearance where I bought it.
Full Throttle - One of the easiest non-RedBull energy drinks to find, it has a sharp citrusy taste that is somewhat (but not very) similar to Mountain Dew, except with a bit more bite to it. Probably my third favorite as far as taste goes.
MDX - One of the more readily available energy drinks, and typically cheaper than most others. Taste is very similar to Mountain Dew, except a much smoother taste with less bite. My second favorite in terms of taste.
Monster - Also a fruity/citrusy taste, but extremely smooth. Not even remotely close to Mountain Dew though. By far the most delicious of the energy drinks I've tasted (even if it didn't give me any energy, I'd probably continue drinking it just because it tastes so damn good.), and it also does a good job of making me feel human in the morning.
Ignoring all of the possible positive potential this might have on the creative process at Disney, this isn't the only effect the merger might have.
Keep in mind that until the Sony rootkit, Disney has historically been one of the worst offenders as far as pushing DRM. (If I recall correctly, they were one of the most solid backers of DIVX - no, not DivX, DIVX. There's a big difference. I'm also pretty sure they were also one of the only backers of DIVX that apparently intended not to ever allow customers to "silver" a disc - paying a one time flat fee for unlimited viewing, you would only ever be able to view your Disney DIVX discs as pay-per-view.)
Jobs, on the other hand (well, at least Apple with him at the helm), has had a much more lenient approach with DRM. Apple's DRM has typically been described as "the bare minimum to keep content providers happy", and Apple has actively resisted attempts to force increases in the restrictions of their DRM. Keep in mind that throughout this all, Jobs was also a content provider, since he also ran Pixar.
Could Jobs calling the shots at Disney mean a more consumer-friendly Disney? I hope so.
The article you linked to stated insane floating point performance, not insane integer performance. Thus the Cell isn't necessarily going to perform well for crypto (crypto is integer-based, not FP.) The Cell in general is highly optimized for FP performance.
Your link to an IBM Cell-based blade server means nothing as far as the Cell's suitability for general purpose computing. Keep in mind that many of IBM's customers purchase VERY large special-purpose systems. Building a blade motherboard based on Cell for those that want to perform scientific computing (one of the few areas where Cell will excel at) is nothing compared to designing an entire custom special purpose processor, which IBM *has* done for at least two customers - Microsoft (Xbox 360) and Lawrence Livermore National Laboratories (BlueGene/L uses custom CPUs designed specifically for the type of work BlueGene/L does.)
Myself, I do indeed look forward to playing with a Cell-based system, but that's because my focus in graduate school was on signal processing for communications, which is one of the areas at which the Cell does excel. But there's no way I'm ever going to spec a Cell processor for a general purpose machine.
"IBM cell based hardware running GNU/Linux is going to blow all of this trash into a distantly remembered nightmare."
No, it isn't. It's not even going to come close. It's not even going to exist, ever. 90% of the Cell's computing horsepower is in the SPUs, which are optimized for signal processing and geometry processing applications (namely, grinding away on lots of number crunching). No instruction reordering, floating-point only, and very limited branching functionality. The coprocessors are more comparable to devices such as Analog Devices' TigerSHARC or TI's TMS320 series than any general purpose CPU. Despite the insane floating point performance, you don't see TigerSHARC or TMS320 based computers, do you? That's because they are not suitable for general purpose computing in any way.
The Cell's general purpose "controller" CPU is an incredibly stripped down PPC core that has incredibly low performance compared to any standard general purpose CPU.
While it will have incredible performance for gaming and signal processing, the Cell is an utterly crap CPU for general purpose computing. Using a Cell in a normal desktop machine is like trying to cut a tree trunk with a cordless electric drill rather than a reciprocating saw. No matter how nice of a drill it is, it's going to do a shitty job compared to even the cheapest recipro saw, if it manages to do the job at all.
For a desktop system, I'll take AMD over Intel any day, especially one I've specced and built myself. I've got the parts for an Athlon 64 X2-based system on the way to my door from NewEgg right now. :)
For a pre-purchased desktop system, I'd prefer AMD over Intel, but unfortunately, prebuilt systems with AMD CPUs often aren't the nicest systems available. There are some (such as Sun's Opteron-based machines), but it's a lot harder to find a prebuilt system with high overall quality which contains an AMD CPU than with an Intel CPU. That's why my fathers' new file server is Intel-based - you can't get Dell PowerEdge systems with AMD CPUs. Say what you want about Dell, while some of their lower-end systems may be crap, my experience has been that their higher end servers and laptops are incredibly solid and well designed systems. The PE830 has one of the nicest internal designs I've seen in a long time, and both my father's Inspiron 8000 and my I8200 have been flawless for me. (Or at least, have been since I nuked XP from my 8200 and installed Win2k because XP's SpeedStep implementation is utter fucking crap compared to Intel's SpeedStep control applet for Win2k.)
When it comes to laptops, Intel is the only viable choice. Whether or not the Turion 64 is better or worse than the Pentium M, it's impossible to actually buy a high-end Turion 64 based machine from a reputable vendor. Every Turion-based system I've seen has been either from a small-time noname vendor or is an incredibly low-end system (crappy screen, crappy video card, etc). There simply are no Turion-based systems that can even come close to competing with IBM/Lenovo ThinkPads or Dell's higher-end Inspirons like the XPS M170, the 9300, and 9400. If there are, they are impossible to find.
Still, prior art is prior art in that case. Doesn't really change anything in my example. :)
I believe NTP's patents are on a much narrower definition of the way RIM's system works.
i.e. they haven't patented sending text messages between devices, they've patented a very specific method of making email available to a mobile device. I don't recall, but I believe the patent deals partially with the corporate firewall problem.
In short, whether it is valid or not, their patent does not apply to packet radio, nor can packet radio be considered prior art for the system.
A good example. Joe Caveman invents the wheel in 500 B.C.
In 1990, John Doe invents a specific tread pattern for a rubber tire that has some Really Nifty Benefit. It's based on the wheel, but enhances it. John Doe can't patent the wheel due to prior art (Joe Caveman in 500 B.C.), but John can patent his specific enhancement of the wheel.
Did you buy desktop-targeted SATA drives (like the Maxtor DiamondMax series, known for having major problems), or server-targeted ones like the Maxtor MAXLine nearline drives, WD Caviar RE2 nearline drives, or the WD Raptors?
SATA itself blows SCSI out of the water in terms of cabling reliability. It's even in terms of performance features such as NCQ. You just have to be careful not to buy a desktop grade drive. (It's impossible to buy a desktop grade SCSI drive. It IS possible to buy a server grade SATA drive that has been tested as rigorously as its SCSI counterpart, you just have to be more careful with the drive purchase.)
I had one bad experience that resulted in massive data corruption.
I had routine bad experiences with systems that wouldn't boot due to something in the SCSI chain flaking out.
It's too damn easy for a single failure somewhere in the chain to take down the entire bus.
Meanwhile, if there's a failure on an SATA channel, only one drive is taken out of commission (unless you're using an SATA port multiplier, which you shouldn't be if you care about performance or reliability).
The fact that SATA cables have fewer conductors and hence are much thinner means they can be routed more easily within a case in a manner that does not produce stress on the connectors. Stress on the connectors reduces reliability. Also, every SCSI connector I've seen that was designed for internal system use had no inherent method of securing it to the device. (Neither did IDE by the way, although IDE connectors always had a tendency to fit tightly, unlike those horrific SCA connectors on many SCSI drives, which are loose as hell.) SATA connectors are designed to clip into whatever they're plugged in to.
In short, while you may be able to come up with a reliable SCSI cabling setup, it's going to require a huge amount of money, research, and trial and error. SATA, on the other hand, will Just Work. Don't forget the fact that with SATA, you no longer need to deal with SCSI IDs, termination, or in the case of IDE, master/slave issues.
Here's a good analogy: SCSI is like 10base2 Thinnet (remember, where one failure or improper termination would take down the entire network?), and SATA is switched 10baseT (failure in the equipment connected to one port has no effect on the other ports). 10base2 was technically superior when it came out, but does anyone use it anymore? I've seen it in use once in the past decade (back in 1999 or so), care to take a guess how I found out it was in use? Yup, an entire network segment failed at a place I was working due to a loose connector.
In the case of an autoimmune response causing immunodeficiency, then the disease isn't actually AIDS.
AIDS - Acquired ImmunoDeficiency Syndrome. Note the Acquired. If it wasn't actually *acquired* from somewhere but instead happened due to a genetic defect, it isn't actually AIDS by definition.
Thus, in the case you state, the immune deficiency is not actually AIDS. (There ARE other known immunodeficiency disorders. While they aren't caused by HIV, in fact many are caused by genetic defects, they aren't AIDS either.) Most likely the idiots claiming "AIDS without HIV" are actually confusing an immunodeficiency disorder that is not actually AIDS and calling it AIDS, even though it isn't actually AIDS.
SATA's peak raw transfer rate (150 MB/sec) is half that of the peak raw transfer rate of SCSI (320 MB/sec), but you're going to be limited by the individual hard drive's transfer rate anyway. Keep in mind that a proper SATA implementation will be 150MB/sec PER DRIVE, since each drive is on its own channel. SCSI is 320 MB/sec per channel, but you're in for a cabling nightmare if you want only one drive per channel. Note that there is a 300 MB/sec SATA standard, although few drives and controllers seem to support it.
If you buy the right model, you can get SATA drives that have gone through the rigorous quality control testing that has historically been reserved for SCSI drives. Many of the higher end server-grade SATA models are warrantied for 24/7 operation. SCSI has lost its advantage there.
SATA has Native Command Queueing, formerly a SCSI-only performance feature. Note that it's optional for SATA drives though, so make sure you get a controller and drives that support NCQ. Again, one of SCSI's few advantages has disappeared.
Last, but most definately not least, SATA cabling is far simpler and robust than SCSI cabling. SCSI cabling is a finicky nightmare where even high-end cables can cause data corruption if you're not careful, whereas even the cheapest SATA cables I've seen worked reliably. I've had hardware related data loss on hard drives twice in my life. One case was an IBM Deathstar, the other was a SCSI cable that started flaking out and corrupted data on three drives at once. I haven't touched SCSI with a ten foot pole since that incident.
1) domU instances don't get access to the graphics hardware. If you want hardware video acceleration, virtualization is currently not an option. There's a chance that you can do it in a case where your system has multiple video cards, but so far there is no solution for concurrent access to the same video card.
2) dom0 instances (generally considered the "host") OS actually run under Xen too. Apparently (according to the Xen mailing lists) dom0 OSes actually need more modifications than domUs. Thus, it may not be possible to use OSX as a dom0.
Please name one pair of competing driver projects where both projects are currently active. (e.g. the ar5k project is long dead and was superseded by madwifi well a year or two ago at least, so the ar5k project does not count)
Drivers for differing chipsets do not count.
The WPN511 (RangeMax) card is also Atheros-based.
Watch out for the WPNT511 (RangeMax 240) - those are Airgo-based. Currently the only 11g chipset manufacturer I know of without any native Linux support in any form. (add Broadcom if you don't want to count the recently released experimental Broadcom native drivers.)
If you want rock-solid integrated-into-the-kernel support, go with an older 11b chipset. Classic Ciscos and Orinoco Golds have some of the highest RF frontend performance available. (More sensitive receivers than most prism2 chipsets). This is if you are using PCMCIA - If you are using PCI, then most of the 802.11 chipsets suck. 90% of PCI-based b-only solutions are PCMCIA cards in a PCI to PCMCIA bridge. IRQ problems galore!
If you want 11g or a good PCI solution, then your best bets are probably Intel or Atheros based chipsets. I use a Netgear RangeMax (WPN511) card in my laptop with a RangeMax router (WPN824). They work incredibly well, although turbo (108Mbps support) is still iffy. 54Mbps support has been rock solid with madwifi in my experience, and the madwifi-ng drivers have some insanely nifty features (such as multiple virtual station/AP interfaces bound to the same card.)
Avoid the RangeMax 240 series (WPNT511, and WPNT834). Those are Airgo-based, which at the moment is one of the only remaining chipsets with no native support whatsoever.
There's one other chipset without any Linux support - the Airgo MIMO chipset(s)
The good news is that there's a grand total of only 3-4 adapters based on Airgo's chipset. Unfortunately Belkin produces one of them (their Pre-N gear is Airgo-based). Linksys SRX and Netgear RangeMax 240 (not the old RangeMax, the new RM 240 stuff) are the only other two I can think of at the moment. (I'm pretty sure there is one other Airgo-based unit.)
When it comes to WLAN support, as long as you avoid Broadcom chipsets (semi-common, but it takes ten minutes of Googling to find if your card is a Broadcom paperweight) and Airgo chipsets (rare as hell - only 3-4 Airgo-based cards exist, the Belkin pre-N hardware being one of those three) are about the only ones that don't have a native Linux driver now.
Atheros - supported by madwifi
Intersil - Supported by the various Prism variants (either linux-wlan, the kernel prism/hermes drivers, or the prism54 drivers)
Cisco - Supported (new Ciscos are Atheros-based anyway I believe)
Orinocos - Old ones are supported with a very stable driver. New ones are Atheros-based.
Atmel - I believe these are USB-only, and are supported.
Intel - Supported
The list of cards that are natively supported (although not necessarily in the main kernel tree) is very long.
Given the recent advent of a native Broadcom driver (although currently experimental), it looks like the original poster bought one of the sum total of *four* cards on the market based on one of Airgo's MIMO chipsets. Those would be:
Linksys SRX (note - Avoid Linksys if you're concerned about stable and reliable Linux support, as most of their newer cards are Broadcom bombs.)
Belkin Pre-N
NetGear RangeMax 240 (the previous gen RangeMax equipment is Atheros-based though, my WPN511 works beautifully under Linux.)
There's one other but I don't recall the manufacturer at the moment.
IIRC, Linus added one or two clauses to the GPL allowing for binary modules.
i.e. it's 99% GPL, but some modifications were made to the initial release. This IS legal - The initial author of some software can release it under any license they want. Either that, or it was deemed that due to the way the kernel module loading system worked, non-GPL modules were allowed to exist.
The end result, whatever the means, is that non-GPL (including binary-only) kernel modules are perfectly legal (albeit frowned upon - the kernel bitches with "taint" warnings when you load a non-GPL module.)
I found there was a lot of egotism and greed. The rich got richer, while the poor stayed poor. This even happened within large corps like Xan - not only was the corp rich, but some of the members were filthy rich too. The same members who would tell everyone else they needed to spend more time contributing to the corporation. People who could get multiple battleships blown up in one day, while I would have to spend multiple days to recoup a battleship loss. The end result was lots of infighting that eventually resulted in Xanadu splitting in half 1-2 months after I left. I left the game rather than stay around and potentially destroy friendships. Those that stayed wound up dealing with that rift, and I know that there were many cases where people had friends on the other side of the rift.
Phoenix Alliance - weren't they up "north" somewhere?
Or is that what FA became after the big Xan split? (Remember, I quit the game a month or so before then.)
I didn't like EVE's PvP at all - hours of boredom followed by 15-30 seconds of excitement.
CCP's sledgehammer approach to fixes really annoyed me. Rather than making slight adjustments, they'd make huge ones that would wind up with them adjusting the other way not too far down the line. The end result is that nothing ever stablized, and nothing ever actually got fixed properly.
DAoC has its own problems, but overall it's a bit more stable and Mythic are much more careful with fixes/adjustments/nerfs than CCP. Most importantly, the game mechanics are much less conducive to intra-guild strife than EVE was. EVE had a bad tendency to make bitter enemies out of former friends.
I played EVE for around 9 months. Independent for 1-2, then finally got back into Xanadu (I was Xanadu in Planetarion, but being a member in PA didn't guarantee EVE membership. I wouldn't have played EVE if not for Xan though.)
:(
EVE had a great concept, but it was too full of bugs and no real endgame other than mindless mining and farming NPCs in 0.0 space. There was supposed to be this rich commerce market, but the truth was that the commerce market crashed almost instantly with oversupply, and the only people who could make profit were those that controlled the rare Tech 2 blueprints. The problem is that CCP made it too easy for one player organization to control the T2 market. (Yes, I know that organization happened to be MY corporation. I disliked what happened nearly as much as the little guys that got stepped on, partly because I did spend 1-2 months as the "little guy".)
I got tired of the game, and while I loved Xanadu, the game mechanics caused us to fight internally way too often. I wound up leaving the game before it destroyed friendships. Unfortunately, not everyone was so smart - I don't recall the details but Xan tore itself in half a month or two later. I wasn't surprised.
I play Dark Age of Camelot now, which has a much simpler concept (bad in some ways) but a much more well thought out endgame (very good) and game mechanics that don't easily contribute to strife within guilds/corporations/whatever they may be called in a given game. The only bad thing is that none of my former Xan buddies play.
StrongARM was a DEC product, but remember that while Compaq bought most of DEC, Intel bought DEC's semiconductor business.
Intel quickly killed Alpha (although I think somehow Compaq still had some control of Alpha too, I think the Alpha was a special exception but I can't be sure), but the StrongARM was so good that it overrode Intel's Not-Invented-Here syndrome. The PXA (Xscale) series is just marketing speak for the new StrongARM. Probably the same design team as the original SAs.
Not sure exactly what happened with DEC's networking chipset line. I know Intel was selling Tulips for a while, but I think eventually all of the old DEC-based designs were phased out, although most likely Intel's newer networking chipsets probably include some of the neat stuff that made Tulips so nice back in the day.
What AQ is supposed to be (for those that don't play WoW).
An expansion? Just a new dungeon? What's so special about it that it causes such server overload?
Yeah, I use it despite the fact that it's a CPU hog.
Strangely enough, I've sometimes had MAJOR performance issues with the original BT client (which I used to swear by) - At some point it began acting like my router's ports were not open (they were), Azureus had much more consistent performance. Azureus also let me only download some files in a multi-file torrent (good when I had a few episodes from a season of TV already and wanted to fill in the gaps using a whole-season torrent).
Unfortunately, Azureus is a massive resource hog, and what's worse is that it's GUI-only, which means I can't run it on an X-less machine, or that I have to restart it if I log out of X and back in for some reason. As a result, my share ratio isn't quite what it should be because I often forget to fire Azureus back up after a reboot.
If your app requires JavaScript, then clearly, anyone who is logged as using your app WILL have JavaScript enabled.
Your logs won't show how many people wanted to use your app but didn't because they had JS turned off for whatever reason.