I agree that it's anyone's right to spend money in whatever way that makes them feel like royalty.
And it's also my right to point out that spending $200K on a bathroom is plainly ludicrous and without merit. It reminds me of other noveau riche, grandiose stupidities.
No, I'm not in academia. I just have sensitivities towards irrational excess.
I suppose it's everyone's right to piss away hundreds of thousands of dollars in a nihilistic effort to get HDTV in their bathrooms. Leave it to the WSJ to highlight conspicuous excess and rich people behaving badly.
And I don't care if they worked for it or not; it's reprehensible.
In an era where some kids have to walk miles through some of the poorest and toughest neighborhoods in the world, just to do email at a library..... we're talking about $200K conspicuous consumption 'tech' bathrooms.
Somehow, out-of-control capitalists just can't stop from writing about their new awesome dead-end look-at-me wicked hot toys. What a waste of digital space.
Sure, a second one is nice. How nice? Worth the extra $$$$$ (not $$ as implied up-thread)? For some, yes. Others no. It's a luxury.... and in many cases the extra expense could be spent on a machine with an unfettered mission to do things like compiles, FFTs, rendering, and so on. Bridge them together at the hip (NFS, WinShare, some other kind of cross-mount) and life is good and inexpensive.
Or, get a process that monitors interrupts frequency and watch the square wave of performance as you jarringly try to get something done in a stream re-write, as an example.
If you have the $$$, it's nice. but OSes and compilers still aren't optimized in any stretch of the imagination to effectively use one CPU, let alone two and more.
This said as I'm addicted to two and more cores/machine. Sigh.
You suspect incorrectly. I have few machines that *aren't* dual CPU or better at this point, including the notebook I'm writing this on.
You must work for a chip or hardware vendor and have rose coloured glasses. I'm a critic.
It may feel faster, but in actuality, work performed is never 2x or close. Yes, faster. 2x: not even close. This isn't to say that a multi-core isn't a bad idea for performance. But realistically, it's not the panacea that some think it is. There's graphics subsystems, internal bus chipset and mgmt, the OS's decision matrix for non-multi-specific tasks and asks. And then there's how much the cache gets dirty, and how fast it can be cleansed or reused or simply reallocated.
The OSes only touch the capabilities, and apps less. But they look cute, suck power, and sometimes are nicer than swift kick in VClock.
First, let's say the OS is well-organized to be able to handle the demands, rather than FIFO'ing them. Then let's say that the OS will assign reasonable task queueing. Let's also say that all of the cache among the CPUs has coherency, and one process doesn't hang an adjoining CPU.
It's a beautiful day.
And NOTHING guarantees this at all. Indeed job queuing is pretty much random unless the OS has native tendencies. You won't get a stochastic job distribution among the processors, except by luck, and perhaps phase of the moon. So, fie.
Do the right thing. Find a machine with the correct graphics chipset solution that your software currently likes. The dual-core machines don't help that much unless code is written for them specifically; there's precious little code that can really whup a dual-core just yet. So, buy lots of memory, and watch for cogent compiles of your favorite stuff. Otherwise, buy a big disk, known chipset with drivers for your favorite OS, and a display that won't blind you.
Then, be prepared to put it on the inheritance plan in three years, as mentioned above.
Linus' philosophy doesn't bridge the gap between us vs them (coders vs hardware engineers), but it does help content owners deal with their own cesspool of problems.
I applaud his choice; it's not quite an RMS sort of view, but close: let the idiots deal with their issues. We'll let the software do its job.
And so, the number 42 as an example. Life is a dice roll.
Consider the homeopaths that believe that water has the 'signature' or inference of ingredients mixed in it.... tinctures as it were. This is memory long after the connection.... an impression. If you have enough impressions, you're allowed boundaries to be defined. Humans have thousands of impressions daily from the moment of sentience/self-awareness. These impressions, cause and effects, algorithms tried, tested, discarded, accepted, rejected, faith, dogma all add up to boundaries. After a while the filtration mechanism for the process of taking a seeming single data point, cross correlating it with all of the aformentioned heuristics, and if the light bulb doesn't go off in metaphorical answer, then an insufficient number of those boundaries were tested, or the new algorithmic instance has been created. All the possibilities on the dice thrown, all adding up to your meaning of life.
In other words, the poor data couldn't escape processing, and was hurled by the answer.
It's not all about data and results. It's also about pre-formed boundaries, or domains within which answers usually (and some might say 'logically') fall.
This is one of those elementary, goosey sorts of tomes (if you RTFA) where a bunch of nerds go around with a bad hypthosis and come to an 'enlightened' conclusion.
Consider the techniques that surround Wolfram's expostuations-- that the world is algorhmic, and language ill-describes these algorithms, loosely defining them as processes. These setup boundaries within which we derive domains where answers must lay.
Proving that with just a few data points within a tight algorithm that you'll get the right answer is just hilarious-- of course you will. The domain fits, and so the answer must. The domain gets defined by a number of experience points as hidden references that allow the frequentists to get magic (e.g. hidden and historical) inferences to the answer. This is where the phenomenon of the trick question makes us all so frustrated.
My point? Inference has predefined boundaries, and so of course Bayesian logic doesn't require a bunch of data to lead to a correct conclusion because the boundaries are already so tightened that only those that randomly guess, and don't use historical data points (e.g. their freaking memories) are going to blow the answers.
Once, houses like MacMillan, Knopf, and others could be trusted. Only rarely was their a problem with quality. Nowadays, it's difficult to know which house owns what; the publishers are actually little LLCs owned by bigger houses to reduce liability should something nasty happen. The lawyers have pushed liability out past the point where the public is protected, only the publisher. Indemnification is a shell game now../
It's also quantity game. Quality is how much you can pimp your book at ABA, or find clever marketing tricks to move your product. The product is a brand-- the author or perhaps a genre. The political diatribe is especially rife with lies and hubris.... with a pseudo-leather jacket on.
In the computer trade press Microsoft Press and Cisco Press killed the little (if sometimes profitable) computer book publishers.... with the rare O'R book that's somewhat decent. Books in the computer trades are now collaborative books sold on the hoof. The really great tomes rarely emerge these days because publishers wouldn't know how to sell them, or to whom. They keep their losses cut to the bone. Authors have little financial incentive.... the shelf life of a product-specific title is the same as hamburger.
This said from the author/co-author of ten highly fact-checked books. In their day, they made only a little money because quality |= profits. Publishers learned that a title, TOC, and timing made all the difference. Content? They're indemnified. It's all spin after that. Look at how Washington DC has learned that lesson.
It's a question of values with many trade-offs
on
Fibre Channel Storage?
·
· Score: 4, Insightful
The answer has a lot to do with the previously mentioned I/O goals that you have. Let me try to answer this in a taxonomy. This rambles for a bit but bear with me.
Case One
Let's say this array is to be used for a single application that needs lots of pull and is populated initially from other sources, with a low delta of updates. In other words, largely reads vs writes. Cacheing may help; and if so, then you can tune the app (and the OS) to get fairly good performance from SATA RAID or through FC JBODs when in a Raid 0 or 5 configuration. (there is no Raid 0; its just a striped array without redundancy/availability and is therefore a misnomer)
Case Two
Maybe you need a more generalized SAN, as it will be hit by a number of machines with a number of apps. You'll need better controller logic. You'll likely initially need a SAN that has a single SCSI LUN appearance, where you can log on to the SAN via IP for external control of the can that stores the drives (and controls the RAID level, and so on). This is how the early Xserve RAID worked, and how many small SAN subsystems work. Here, the I/O blocks/problems come at different places-- mostly at the LUN when the drive is being hit by multiple requests from different apps connected via (hopefully) an FC non-blocking switch (Think an old eBay-purchased Brocade Silkworm, etc). SCSI won't necessarily help you much.... and a SATA array has the same LUN point block. Contention is the problem here; delivery is a secondary issue unless you're looking for superlative performance with calculated streams.
Case Three
Maybe you're streaming or rendering and need concurrent paths in an isochronous arrangement with low latency but fairly low data rates-- just many of them concurrently. Studio editing; rendering farms, etc. Here's where a fat server connecting a resilient array works well. Consider a server that uses a fast, cached, PCI-X controller connected to a fat line of JBOD arrays. The server costs a few bucks, as does the controller, but the JBOD cans and drives are fairly inexpensive and can be high-duration/streaming devices. You need to have a server whose PCI-X array isn't somehow trampled by a slow, non-PCI-X GBE controller as non-PCI-X devices will slow down the bus. You also get the flexibility of hanging additional items off the FC buses, then adding FC switches as the need arises. At some point, the server becomes more useless in cache and becomes its own botleneck-- but you'll have proven your point and will have what now amounts to a real SAN with real switches and real devices.
The SATA vs SCSI argument is somewhat moot. Unless you cache the SATA drives, they're simply 2/3rd the possible speed (at best) of a high-RPM SCSI/FC drive. It's that simple. uSATA will come one day, then uSATA/hi-RPM..... and they'll catch up until the 30Krpm SCSI drives appear.... with higher density platters....and the cost will shrink some more.
I've been doing this since a 5MB hard drive was a big deal. SCSI drives will continue to lead SATA for a while, but SATA will eventually catch up. In the mean time, watch the specs and don't be afraid of configuring your own JBOD. And if you want someone to yell at, the Xserve RAID is as good as the next one.... except that it has the Apple Sex Appeal that seems a bit much on a device that I want to hide in a rack in another building.
Their lobbying efforts are huge. Bills written in the past 18 months aren't nearly as bad as those that came from Billy Tauzin, the king of telecom lobbying debauchery, but nearly so. A backlash is forming, coming from numerous quarters. Shortly, the head of the NTIA will switch out, and another hullaballoo will ensue.
If you really think that the carriers are benevolent, just go back a couple of issues of 2600 and look at the cover. The Bells are united again, and they're pissed. They own their 'goddamn' networks and we don't. They're purporting their own long lines and internal warmed over x.25 networks as part of the deal. It's stomach churning.
Their enemies are clear: anyone else, and especially cable companies, dark fiber owners, and anyone that thinks twice about FTTH-- if it's not theirs. The last mile will be fought with lobbying money, and tooth and nail. Armies of lawyers, and the boorish threats that telcos have made, will win them no friends. But they have $$$.... just like our friends the petrochemical companies. And they'll use it in Washington where they can now usurp all of the state PUCs. And they're doing it right now, under your noses. Have a nice communications day. Love that latency, don't you?
SCSI is very fast, and usually more expensive. You can get really fast, highly cached drives in SCSI with high-RPM spindles, and cool controllers. But they're $$$$. Do you need the speed?
If not, SATA is still pretty fast, much less expensive, less clever controllers, but still very reasonable for things like archiving, steady low-concurrency-demand streaming, and so on.
SATA also has the advantage of not needing loads of austere cables with distance limitations imposed on them; it's a serial rather than a parallel bus-- hence the S in SATA. Use SATA when you don't need the absolute fastest you can get-- and you won't have to spend the most on the controller (which is hopefully a SCSI PCI-X controller or other fast clocker), the drives, the pricey cables, and so on. But if you need the speed, there is no faster than SCSI except for flash drives, which are still hideously expensive.... and not writeable as much as we'd like them to be.
Are the Analogy Police Lurking? USB |= wheel
on
Wireless USB hubs
·
· Score: 3, Interesting
Take a look at the USB specs, and the number of vendors deploying them. USB devices are 'trusted' where BT devices are 'paired'. BT in its first incarnation had an operation radius of 8m. With WiFi, the operational radius, given Defcon successes, might be nearly 200km (line of sight, no sun spots, nearby Schwarzchild radius, etc). So far, 8m vs 200km. Speed in payload is about 52x, USB 2.0 vs BT 1.1 spec.
BT is really designed as a paired communications medium (with dedicated voice channel) as a PAN setup utilizing OBEX (object exchange) and a few other interesting inter-device tricks. USB is a perhipheral connector and virtualizing the electrical part through wireless is a godsend. USB is more layer 1 & 2, where BT is a full stack.
The boorishness and panache of the Bush administration knows no boundaries. This is one more straw on the camel's back of liberty. How far this administration will go is still unknown.
As others have said: buy Google Stock. They need no "Google Defense Fund"....
What madness. What All Star Weenies: MSN, Yahoo, and AOL-- who cave and cower and quiver in fealty to this adminstration. How mindlessly droll and insensitive....
If Google caves to the subpoena, then the last shred of dignity and privacy from the Internet is gone.
If Patrick Henry were alive, there'd be a regime change in Washington.
Jeremey Campbell's Grammatical Man-- on Entropy in Information Systems, goes a long way towards explaining both linguistics and even genetic concepts in communications, of which semiotics is a discipline. Although this book is out of print, it goes a long way towards explaining how we arrive at correct information when assembling data, and how various communications systems avoid entropy.
The Deux ex Machina (or vice versa) rage really has to do with context vs perceptions. We can all be robotic and make our behavior mathematical. And we'd be plainly bored to tears. Yet when a robot tries to communicate with a human, a context is needed. As robots don't invent themselves (at least those that communicate with humans) they're required by human programming to achieve communications compatible with humans-- else humans don't understand the robots. That's also what makes speech to text so contextually sensitive.
There's only one atty general in the USA that has both the testosterone, the guts, the gonads, and the budget to do the job on a RICO with these guys. But he's leaving his job in NY to run for governor.
Why waste real estate on that old, non-proprietary, open, well known and licensed x86 stuff when we can pull everyone down the rosy path towards the real goal of this HP-Intel PA-RISC-64-bit wonder? SO WE DON'T HAVE TO WORRY ABOUT THE BEGGARS STEALING OUR IDEAS ANYMORE.
Mr Grove? Mr Grove? Your pacemaker's not working. We think it's the chip..... we couldn't find a way to port the code. Hello Mr Ruiz? Can you give Mr Grove a hand here? We think he's dying.
Actually, a significant portion is owned by them. Consider inter-NAP, longlines, fiber, and so on. This isn't like SS7 where there's a neat hand-off and billing solution for fractional use of an overall segment (the full end2end hop count). Google, by historical measures (and numerous theories of law) could defend their action but the telcos have advanced associations with gillions of $$ to spend.
Remember that this is where the Telcos live, while bothering only one business segment (and ostensibly more unnannounced) of Google's. Snack on Googles revenues and you eat from a big pie, but snack on the telcos, and they only eat sausage.
SBC/AT&T, Bell South, and soon others will be at Congress's heels to get the concept changed.
The mentality of the telcos, now that their monopolies are being rapidly deregulated, is to get as much revenue as possible from their infrastructure. Now that voice is virtualized and becoming removed from their revenue models, they feel they have to make money some way to compete with cable, BPL, fiber, and other broadband providers to survive.
They won't be shaken easily, and a pooh-pooh from Google won't slow them down an inch. These are guys that go into Congressional offices armed with a dozen lawyers-- per visit-- every visit. Do not mistake their resolve.
This is just the first salvo, folks. Get you umbrellas.
The use of a registry has been criticized since its inception. Even though Microsoft has gone to lengths to remove user/root access from the registry, a hierarchical information manipulation system hasn't been implemented-- causing exploit after successful exploit.
Why should we have to buy firewall apps, virus mitigators, spyware removers and other products when an inherently strong and systematic approach to security would have prevented all of these problems?
Exceptions to this rule: PBFix in San Luis Obispo (sells PowerBook Parts, and has a decent stock of parts); CDW isn't bad, and CompUSA can often turn things around quickly.
Otherwise, the big seven all have parts/SLA agreements that you can buy. The only one I trust anymore is IBM.
Slashdot Mirror
This is about embarrassment.
I agree that it's anyone's right to spend money in whatever way that makes them feel like royalty.
And it's also my right to point out that spending $200K on a bathroom is plainly ludicrous and without merit. It reminds me of other noveau riche, grandiose stupidities.
No, I'm not in academia. I just have sensitivities towards irrational excess.
I suppose it's everyone's right to piss away hundreds of thousands of dollars in a nihilistic effort to get HDTV in their bathrooms. Leave it to the WSJ to highlight conspicuous excess and rich people behaving badly.
And I don't care if they worked for it or not; it's reprehensible.
In an era where some kids have to walk miles through some of the poorest and toughest neighborhoods in the world, just to do email at a library..... we're talking about $200K conspicuous consumption 'tech' bathrooms.
Somehow, out-of-control capitalists just can't stop from writing about their new awesome dead-end look-at-me wicked hot toys. What a waste of digital space.
Sure, a second one is nice. How nice? Worth the extra $$$$$ (not $$ as implied up-thread)? For some, yes. Others no. It's a luxury.... and in many cases the extra expense could be spent on a machine with an unfettered mission to do things like compiles, FFTs, rendering, and so on. Bridge them together at the hip (NFS, WinShare, some other kind of cross-mount) and life is good and inexpensive.
Or, get a process that monitors interrupts frequency and watch the square wave of performance as you jarringly try to get something done in a stream re-write, as an example.
If you have the $$$, it's nice. but OSes and compilers still aren't optimized in any stretch of the imagination to effectively use one CPU, let alone two and more.
This said as I'm addicted to two and more cores/machine. Sigh.
You suspect incorrectly. I have few machines that *aren't* dual CPU or better at this point, including the notebook I'm writing this on.
You must work for a chip or hardware vendor and have rose coloured glasses. I'm a critic.
It may feel faster, but in actuality, work performed is never 2x or close. Yes, faster. 2x: not even close. This isn't to say that a multi-core isn't a bad idea for performance. But realistically, it's not the panacea that some think it is. There's graphics subsystems, internal bus chipset and mgmt, the OS's decision matrix for non-multi-specific tasks and asks. And then there's how much the cache gets dirty, and how fast it can be cleansed or reused or simply reallocated.
The OSes only touch the capabilities, and apps less. But they look cute, suck power, and sometimes are nicer than swift kick in VClock.
First, let's say the OS is well-organized to be able to handle the demands, rather than FIFO'ing them. Then let's say that the OS will assign reasonable task queueing. Let's also say that all of the cache among the CPUs has coherency, and one process doesn't hang an adjoining CPU.
It's a beautiful day.
And NOTHING guarantees this at all. Indeed job queuing is pretty much random unless the OS has native tendencies. You won't get a stochastic job distribution among the processors, except by luck, and perhaps phase of the moon. So, fie.
Do the right thing. Find a machine with the correct graphics chipset solution that your software currently likes. The dual-core machines don't help that much unless code is written for them specifically; there's precious little code that can really whup a dual-core just yet. So, buy lots of memory, and watch for cogent compiles of your favorite stuff. Otherwise, buy a big disk, known chipset with drivers for your favorite OS, and a display that won't blind you.
Then, be prepared to put it on the inheritance plan in three years, as mentioned above.
Linus' philosophy doesn't bridge the gap between us vs them (coders vs hardware engineers), but it does help content owners deal with their own cesspool of problems.
I applaud his choice; it's not quite an RMS sort of view, but close: let the idiots deal with their issues. We'll let the software do its job.
Fairly simple, eh?
And so, the number 42 as an example. Life is a dice roll.
Consider the homeopaths that believe that water has the 'signature' or inference of ingredients mixed in it.... tinctures as it were. This is memory long after the connection.... an impression. If you have enough impressions, you're allowed boundaries to be defined. Humans have thousands of impressions daily from the moment of sentience/self-awareness. These impressions, cause and effects, algorithms tried, tested, discarded, accepted, rejected, faith, dogma all add up to boundaries. After a while the filtration mechanism for the process of taking a seeming single data point, cross correlating it with all of the aformentioned heuristics, and if the light bulb doesn't go off in metaphorical answer, then an insufficient number of those boundaries were tested, or the new algorithmic instance has been created. All the possibilities on the dice thrown, all adding up to your meaning of life.
In other words, the poor data couldn't escape processing, and was hurled by the answer.
Your production unit lacks motivation.
Your marketers will quit because they're bored and going broke.
It's not all about data and results. It's also about pre-formed boundaries, or domains within which answers usually (and some might say 'logically') fall.
This is one of those elementary, goosey sorts of tomes (if you RTFA) where a bunch of nerds go around with a bad hypthosis and come to an 'enlightened' conclusion.
Consider the techniques that surround Wolfram's expostuations-- that the world is algorhmic, and language ill-describes these algorithms, loosely defining them as processes. These setup boundaries within which we derive domains where answers must lay.
Proving that with just a few data points within a tight algorithm that you'll get the right answer is just hilarious-- of course you will. The domain fits, and so the answer must. The domain gets defined by a number of experience points as hidden references that allow the frequentists to get magic (e.g. hidden and historical) inferences to the answer. This is where the phenomenon of the trick question makes us all so frustrated.
My point? Inference has predefined boundaries, and so of course Bayesian logic doesn't require a bunch of data to lead to a correct conclusion because the boundaries are already so tightened that only those that randomly guess, and don't use historical data points (e.g. their freaking memories) are going to blow the answers.
Sigh.
Once, houses like MacMillan, Knopf, and others could be trusted. Only rarely was their a problem with quality. Nowadays, it's difficult to know which house owns what; the publishers are actually little LLCs owned by bigger houses to reduce liability should something nasty happen. The lawyers have pushed liability out past the point where the public is protected, only the publisher. Indemnification is a shell game now. ./
It's also quantity game. Quality is how much you can pimp your book at ABA, or find clever marketing tricks to move your product. The product is a brand-- the author or perhaps a genre. The political diatribe is especially rife with lies and hubris.... with a pseudo-leather jacket on.
In the computer trade press Microsoft Press and Cisco Press killed the little (if sometimes profitable) computer book publishers.... with the rare O'R book that's somewhat decent. Books in the computer trades are now collaborative books sold on the hoof. The really great tomes rarely emerge these days because publishers wouldn't know how to sell them, or to whom. They keep their losses cut to the bone. Authors have little financial incentive.... the shelf life of a product-specific title is the same as hamburger.
This said from the author/co-author of ten highly fact-checked books. In their day, they made only a little money because quality |= profits. Publishers learned that a title, TOC, and timing made all the difference. Content? They're indemnified. It's all spin after that. Look at how Washington DC has learned that lesson.
The answer has a lot to do with the previously mentioned I/O goals that you have. Let me try to answer this in a taxonomy. This rambles for a bit but bear with me.
Case One
Let's say this array is to be used for a single application that needs lots of pull and is populated initially from other sources, with a low delta of updates. In other words, largely reads vs writes. Cacheing may help; and if so, then you can tune the app (and the OS) to get fairly good performance from SATA RAID or through FC JBODs when in a Raid 0 or 5 configuration. (there is no Raid 0; its just a striped array without redundancy/availability and is therefore a misnomer)
Case Two
Maybe you need a more generalized SAN, as it will be hit by a number of machines with a number of apps. You'll need better controller logic. You'll likely initially need a SAN that has a single SCSI LUN appearance, where you can log on to the SAN via IP for external control of the can that stores the drives (and controls the RAID level, and so on). This is how the early Xserve RAID worked, and how many small SAN subsystems work. Here, the I/O blocks/problems come at different places-- mostly at the LUN when the drive is being hit by multiple requests from different apps connected via (hopefully) an FC non-blocking switch (Think an old eBay-purchased Brocade Silkworm, etc). SCSI won't necessarily help you much.... and a SATA array has the same LUN point block. Contention is the problem here; delivery is a secondary issue unless you're looking for superlative performance with calculated streams.
Case Three
Maybe you're streaming or rendering and need concurrent paths in an isochronous arrangement with low latency but fairly low data rates-- just many of them concurrently. Studio editing; rendering farms, etc. Here's where a fat server connecting a resilient array works well. Consider a server that uses a fast, cached, PCI-X controller connected to a fat line of JBOD arrays. The server costs a few bucks, as does the controller, but the JBOD cans and drives are fairly inexpensive and can be high-duration/streaming devices. You need to have a server whose PCI-X array isn't somehow trampled by a slow, non-PCI-X GBE controller as non-PCI-X devices will slow down the bus. You also get the flexibility of hanging additional items off the FC buses, then adding FC switches as the need arises. At some point, the server becomes more useless in cache and becomes its own botleneck-- but you'll have proven your point and will have what now amounts to a real SAN with real switches and real devices.
The SATA vs SCSI argument is somewhat moot. Unless you cache the SATA drives, they're simply 2/3rd the possible speed (at best) of a high-RPM SCSI/FC drive. It's that simple. uSATA will come one day, then uSATA/hi-RPM..... and they'll catch up until the 30Krpm SCSI drives appear.... with higher density platters....and the cost will shrink some more.
I've been doing this since a 5MB hard drive was a big deal. SCSI drives will continue to lead SATA for a while, but SATA will eventually catch up. In the mean time, watch the specs and don't be afraid of configuring your own JBOD. And if you want someone to yell at, the Xserve RAID is as good as the next one.... except that it has the Apple Sex Appeal that seems a bit much on a device that I want to hide in a rack in another building.
Their lobbying efforts are huge. Bills written in the past 18 months aren't nearly as bad as those that came from Billy Tauzin, the king of telecom lobbying debauchery, but nearly so. A backlash is forming, coming from numerous quarters. Shortly, the head of the NTIA will switch out, and another hullaballoo will ensue.
If you really think that the carriers are benevolent, just go back a couple of issues of 2600 and look at the cover. The Bells are united again, and they're pissed. They own their 'goddamn' networks and we don't. They're purporting their own long lines and internal warmed over x.25 networks as part of the deal. It's stomach churning.
Their enemies are clear: anyone else, and especially cable companies, dark fiber owners, and anyone that thinks twice about FTTH-- if it's not theirs. The last mile will be fought with lobbying money, and tooth and nail. Armies of lawyers, and the boorish threats that telcos have made, will win them no friends. But they have $$$.... just like our friends the petrochemical companies. And they'll use it in Washington where they can now usurp all of the state PUCs. And they're doing it right now, under your noses. Have a nice communications day. Love that latency, don't you?
SCSI is very fast, and usually more expensive. You can get really fast, highly cached drives in SCSI with high-RPM spindles, and cool controllers. But they're $$$$. Do you need the speed?
If not, SATA is still pretty fast, much less expensive, less clever controllers, but still very reasonable for things like archiving, steady low-concurrency-demand streaming, and so on.
SATA also has the advantage of not needing loads of austere cables with distance limitations imposed on them; it's a serial rather than a parallel bus-- hence the S in SATA. Use SATA when you don't need the absolute fastest you can get-- and you won't have to spend the most on the controller (which is hopefully a SCSI PCI-X controller or other fast clocker), the drives, the pricey cables, and so on. But if you need the speed, there is no faster than SCSI except for flash drives, which are still hideously expensive.... and not writeable as much as we'd like them to be.
Take a look at the USB specs, and the number of vendors deploying them. USB devices are 'trusted' where BT devices are 'paired'. BT in its first incarnation had an operation radius of 8m. With WiFi, the operational radius, given Defcon successes, might be nearly 200km (line of sight, no sun spots, nearby Schwarzchild radius, etc). So far, 8m vs 200km. Speed in payload is about 52x, USB 2.0 vs BT 1.1 spec.
BT is really designed as a paired communications medium (with dedicated voice channel) as a PAN setup utilizing OBEX (object exchange) and a few other interesting inter-device tricks. USB is a perhipheral connector and virtualizing the electrical part through wireless is a godsend. USB is more layer 1 & 2, where BT is a full stack.
The boorishness and panache of the Bush administration knows no boundaries. This is one more straw on the camel's back of liberty. How far this administration will go is still unknown.
As others have said: buy Google Stock. They need no "Google Defense Fund"....
What madness. What All Star Weenies: MSN, Yahoo, and AOL-- who cave and cower and quiver in fealty to this adminstration. How mindlessly droll and insensitive....
If Google caves to the subpoena, then the last shred of dignity and privacy from the Internet is gone.
If Patrick Henry were alive, there'd be a regime change in Washington.
Jeremey Campbell's Grammatical Man-- on Entropy in Information Systems, goes a long way towards explaining both linguistics and even genetic concepts in communications, of which semiotics is a discipline. Although this book is out of print, it goes a long way towards explaining how we arrive at correct information when assembling data, and how various communications systems avoid entropy.
The Deux ex Machina (or vice versa) rage really has to do with context vs perceptions. We can all be robotic and make our behavior mathematical. And we'd be plainly bored to tears. Yet when a robot tries to communicate with a human, a context is needed. As robots don't invent themselves (at least those that communicate with humans) they're required by human programming to achieve communications compatible with humans-- else humans don't understand the robots. That's also what makes speech to text so contextually sensitive.
There's only one atty general in the USA that has both the testosterone, the guts, the gonads, and the budget to do the job on a RICO with these guys. But he's leaving his job in NY to run for governor.
But we can pray.
Why waste real estate on that old, non-proprietary, open, well known and licensed x86 stuff when we can pull everyone down the rosy path towards the real goal of this HP-Intel PA-RISC-64-bit wonder? SO WE DON'T HAVE TO WORRY ABOUT THE BEGGARS STEALING OUR IDEAS ANYMORE.
Mr Grove? Mr Grove? Your pacemaker's not working. We think it's the chip..... we couldn't find a way to port the code. Hello Mr Ruiz? Can you give Mr Grove a hand here? We think he's dying.
Actually, a significant portion is owned by them. Consider inter-NAP, longlines, fiber, and so on. This isn't like SS7 where there's a neat hand-off and billing solution for fractional use of an overall segment (the full end2end hop count). Google, by historical measures (and numerous theories of law) could defend their action but the telcos have advanced associations with gillions of $$ to spend.
Remember that this is where the Telcos live, while bothering only one business segment (and ostensibly more unnannounced) of Google's. Snack on Googles revenues and you eat from a big pie, but snack on the telcos, and they only eat sausage.
Yes. Fat armies of lawyers. All smiling. Some with little drools of saliva.
SBC/AT&T, Bell South, and soon others will be at Congress's heels to get the concept changed.
The mentality of the telcos, now that their monopolies are being rapidly deregulated, is to get as much revenue as possible from their infrastructure. Now that voice is virtualized and becoming removed from their revenue models, they feel they have to make money some way to compete with cable, BPL, fiber, and other broadband providers to survive.
They won't be shaken easily, and a pooh-pooh from Google won't slow them down an inch. These are guys that go into Congressional offices armed with a dozen lawyers-- per visit-- every visit. Do not mistake their resolve.
This is just the first salvo, folks. Get you umbrellas.
The use of a registry has been criticized since its inception. Even though Microsoft has gone to lengths to remove user/root access from the registry, a hierarchical information manipulation system hasn't been implemented-- causing exploit after successful exploit.
Why should we have to buy firewall apps, virus mitigators, spyware removers and other products when an inherently strong and systematic approach to security would have prevented all of these problems?
His lips are moving.
Exceptions to this rule: PBFix in San Luis Obispo (sells PowerBook Parts, and has a decent stock of parts); CDW isn't bad, and CompUSA can often turn things around quickly.
Otherwise, the big seven all have parts/SLA agreements that you can buy. The only one I trust anymore is IBM.