Yes, actually, I do have to ask, as I don't have a particular problem with iTunes. Now that you've described the reasons you don't like it (Buelldozer?), I still don't see the behavior you describe. It's not a paragon of truth and justice I'd uphold as the Best Program Eva, but it seems functional enough.
Thank you so much for that link; in addition to the specific matter being discussed, it gives a great overview of the dynamics and personalities of the court. Excellent read, very accessible!
No endeavor is entirely free of the stink of corruption, error, and temptation, government and corporation alike. They suffer very similar problems in this regard. Chalk it up to the human condition.
Signs will get obscured in snowstorms, whether it's a traffic light, speed limit, left lane must turn left, etc. Part of being a licensed driver is being able to understand and implement the rules of right of way to avoid problems when the usual control systems aren't available (okay - and also when they are). Tighten up US driver's licensing like Europe's, and I doubt these problems would be as severe.
Sorry, it's very obvious when: a) using anything from a smoker's house b) being near a smoker, whether they are smoking or not. c) driving behind a smoking driver d) someone is smoking nearby.
Zippthorne is in no way unique in this regard, even if your own olfactory sense is not processing the stench in the same way.
All of the things you mention affect only the person doing it. Smoking (and maybe excessive drinking) affects others.
I'm not for a nanny state, but don't expect me to stand up for the nauseating direct and indirect health effects of the smoker. You smoke, you'd better be doing it out of my face.
We recently detected abnormal activity on your computer associated with a virus infection. To protect your computer, please verify your name, password, and birthday, and then download this anti-virus software.
Same hub-bub that rolled around about how great voice recognition was going to be a few years ago. Just like voice recognition, multi-touch WILL be adopted, and just like in voice recognition, in limited, specialized devices or applications.
It will find less purchase as a general purpose controlling device.
Your point is legit - except that Google (and Yahoo, and Facebook, and...) most certainly continue to use off-the-shelf commodity hardware, because they understand how best to create horizontal scalability for their application needs.
The main point with large systems is that everything, I mean everything, fails, no matter how trivial: passive backplanes, power cables, physical failure, etc. You don't have time when you're dealing with a cluster of 100 or 400 thousand machines to diagnose - you just detect the problem, yank it out of the cluster, fix it whenever (or throw it away if it's more cost efficient) and throw in a new box.
SAN has its own set of baggage, mostly in complexity and increased failure scenarios (HBA failures, transceiver failures, switch failures, cable failures, management/monitoring/presentation software issues, split brain, increased human error - better be sure your technicians know exactly how the SAN behaves before monkeying around with cables - firmware incompatibilities, etc.). One of the biggest problem with SANs is that, though the underlying protocols and link layers have gotten fairly good at blocking and recovering when the underlying problem is corrected, most applications that require a SAN do NOT survive failure in the block layer well, AT REASONABLE COST. Yes yes, multipath HBAs, blah blah blah, etc. etc.
For most needs, a SAN is totally overkill: expensive new acquisition, expensive in expertise required. I would recommend everyone who can afford to do so build one and understand one, and start simulating failure, before issuing blanket decrees of SAN advisability.
Yes, perhaps they were wrong to compare themselves directly to enterprise arrays - they service radically different accessibility and availability models. That said, they acknowledge these are components of a system, not the end-all/be-all. They're building a service here: who cares if a node goes down, if I've got two others that are ready to pick up the request?
Think service redundancy, not in-box server redundancy.
Backblaze understands that. Their redundancy is accomplished via replication to other nodes. A node goes down, for whatever reason - no prob, just use one of the other nodes that has the data. As the article mentions, these are building blocks that can be used to create much larger structures - don't think of it as a stand-alone array, anyone who's engineering their own solution like this already knows what it takes to service their availability or accessibility needs, and will accomplish those needs via other mechanisms.
A server isn't important. A service is. Engineer for availability of the service.
You both don't "get it", if you can't see that different types of storage serve radically different needs. The system described in the article is ideal for near-line, at-rest data. Sweet spots would include data warehousing, log storage and aggregation, HDFS backing, bulk content distribution store, even a small-to-medium business LAN file server (if coupled with a redundant server).
You wouldn't want to be putting OLTP systems on this environment - you could, but it's not its sweet spot, for many of the reasons you mention. Some of the products you mention do a better job of serving that market's needs, and does so at exorbitant prices that for most companies are significant barriers to adoption.
The article is quite clear that the system is a COMPONENT that does not address redundancy, in and of itself, but is used as a building block coupled with their glue that addresses their market's needs for availability, reliability, and accessibility. Use the right tool for the right job, and make it fit into the budget.
Do you honestly think that's it's the legitimate companies that're the problem? Look through your junk folder on gmail, and you tell me how many of those represent legitimate companies involved in online marketing.
I empathize with the pain you describe, but place the blame where due - on the stupidity of those that actually respond to the spam, or the shady fly-by-night viagra and penis pump outfits, or botnet operators.
(there will always be idiots in legit companies who are just trying to make it, and don't follow double opt-in practices, and the CAN-SPAM law is in my opinion fatally flawed primarily through that omission.
Could be that many people who buy into MacOS X don't know as much about computers as others, just as you imply. Just for grins, though, try attending a technical conference sometime (one that doesn't have "MSDN" in the title), and count how many Apple laptops you see.
Ultimately, I suspect that most people who use MacOS X, whether or not they're computer savvy or otherwise, just want something that they don't have to fight with or think about much.
"Oracle bought Sun because buying Innodb didn't kill MySQL."
I don't understand that.
Oracle bought the Innodb engine that provided much of whatever ACID compliance MySQL has. They had no real reason to do so, other than to give MySQL the finger. That didn't really slow MySQL down - but now that Sun owns MySQL, buying Sun will at least stem some portion of Oracle's market share being eaten from beneath. Maybe.
Oh yeah, Sun has a lot of storage and systems software that can be sold off or cannibalized at will, plus a patent portfolio that Larry can use to stick to competitors (though I haven't been aware of Oracle as a huge patent troll to date...)
Personally I think Oracle and Sun are perfect for each other business wise. Two companies that have some good products, often don't even realize the potential of what they have, have no real vision other than getting big contracts signed, and couldn't market their way out of a wet paper bag.
Nicely stated, and I happen to agree with your assessment.
Given that you've already experience the "Ellison touch", I think you know exactly what's going to happen with Sun's hardware. Fuzzier for software.
Every big proprietary Unix provider faced the same set of issues - comparatively low volume of sales, the resultant premium prices, and much longer evolutionary times for performance increases. Sun's demise was ultimately inevitable, even though they had some interesting technology towards the end (dtrace, zfs, Unified Storage System 7000).
Sun materially offered nothing that couldn't be achieved cheaper elsewhere, and in this race-to-the-bottom commodity market, made it impossible to compete. Sun kept trying to do what they always did - engineer decent but conservative systems offered at a premium price. Remember, Sun thrived first in a time where the standard Intel offerings couldn't begin to compete with the multi-user scalability of Sun. They either couldn't recognize or couldn't adapt themselves to an evolved future wherein PCs dominated the sweetspot of the price-performance curve.
Oracle bought Sun because buying Innodb didn't kill MySQL. There's nothing else that Oracle can likely do with the other assets of Sun other than sell them for parts. I refuse to believe that Oracle has either the ability or the impetus to continue any of Sun's hardware or non-DB software.
Here's a completely uninformed theory (hey, it's slashdot). Swearing is taboo - there is thrill associated with breaking that taboo. That serves as the payoff for swearing.
I'll bet that if they looked, they could find persons predisposed to addiction swear more often than those that don't. But what the fuck do I know.
Unfortunately, raw FTP still rules when you need a high bandwidth. With SCP/SFTP I get consistently 4-5 times lower transfer speeds compared to FTP. It doesn't matter much if one transfers megabytes. But SCP/SFTP becomes a pain when one needs to upload dozens/hundreds megabyte. 'tar cf - . | ssh tar xf -' trick speed things up, but not always available.
One thing you can try is to change your default cipher - try as an option to scp or ssh "-c blowfish" It helps.
Honestly, I prefer using WebDAV over HTTPS, even though the performance is worse than scp/sftp, because you (potentially) don't need to have an actual user account on the destination to achieve authentication.
Slashdot Mirror
Yes, actually, I do have to ask, as I don't have a particular problem with iTunes. Now that you've described the reasons you don't like it (Buelldozer?), I still don't see the behavior you describe. It's not a paragon of truth and justice I'd uphold as the Best Program Eva, but it seems functional enough.
Thank you so much for that link; in addition to the specific matter being discussed, it gives a great overview of the dynamics and personalities of the court. Excellent read, very accessible!
No endeavor is entirely free of the stink of corruption, error, and temptation, government and corporation alike. They suffer very similar problems in this regard. Chalk it up to the human condition.
Signs will get obscured in snowstorms, whether it's a traffic light, speed limit, left lane must turn left, etc. Part of being a licensed driver is being able to understand and implement the rules of right of way to avoid problems when the usual control systems aren't available (okay - and also when they are). Tighten up US driver's licensing like Europe's, and I doubt these problems would be as severe.
Of all the times not to have moderation points! Concisely perfect summation. Mods, up the parent.
Sorry, it's very obvious when:
a) using anything from a smoker's house
b) being near a smoker, whether they are smoking or not.
c) driving behind a smoking driver
d) someone is smoking nearby.
Zippthorne is in no way unique in this regard, even if your own olfactory sense is not processing the stench in the same way.
All of the things you mention affect only the person doing it. Smoking (and maybe excessive drinking) affects others.
I'm not for a nanny state, but don't expect me to stand up for the nauseating direct and indirect health effects of the smoker. You smoke, you'd better be doing it out of my face.
Greetings,
We recently detected abnormal activity on your computer associated with a virus infection. To protect your computer, please verify your name, password, and birthday, and then download this anti-virus software.
Same hub-bub that rolled around about how great voice recognition was going to be a few years ago. Just like voice recognition, multi-touch WILL be adopted, and just like in voice recognition, in limited, specialized devices or applications.
It will find less purchase as a general purpose controlling device.
Rebuild time doesn't sound like it matters in a system like online backup. You need to write the data once for a few nodes, and read it rarely.
Your point is legit - except that Google (and Yahoo, and Facebook, and ...) most certainly continue to use off-the-shelf commodity hardware, because they understand how best to create horizontal scalability for their application needs.
The main point with large systems is that everything, I mean everything, fails, no matter how trivial: passive backplanes, power cables, physical failure, etc. You don't have time when you're dealing with a cluster of 100 or 400 thousand machines to diagnose - you just detect the problem, yank it out of the cluster, fix it whenever (or throw it away if it's more cost efficient) and throw in a new box.
SAN has its own set of baggage, mostly in complexity and increased failure scenarios (HBA failures, transceiver failures, switch failures, cable failures, management/monitoring/presentation software issues, split brain, increased human error - better be sure your technicians know exactly how the SAN behaves before monkeying around with cables - firmware incompatibilities, etc.). One of the biggest problem with SANs is that, though the underlying protocols and link layers have gotten fairly good at blocking and recovering when the underlying problem is corrected, most applications that require a SAN do NOT survive failure in the block layer well, AT REASONABLE COST. Yes yes, multipath HBAs, blah blah blah, etc. etc.
For most needs, a SAN is totally overkill: expensive new acquisition, expensive in expertise required. I would recommend everyone who can afford to do so build one and understand one, and start simulating failure, before issuing blanket decrees of SAN advisability.
Yes, perhaps they were wrong to compare themselves directly to enterprise arrays - they service radically different accessibility and availability models. That said, they acknowledge these are components of a system, not the end-all/be-all. They're building a service here: who cares if a node goes down, if I've got two others that are ready to pick up the request?
Think service redundancy, not in-box server redundancy.
Backblaze understands that. Their redundancy is accomplished via replication to other nodes. A node goes down, for whatever reason - no prob, just use one of the other nodes that has the data. As the article mentions, these are building blocks that can be used to create much larger structures - don't think of it as a stand-alone array, anyone who's engineering their own solution like this already knows what it takes to service their availability or accessibility needs, and will accomplish those needs via other mechanisms.
A server isn't important. A service is. Engineer for availability of the service.
You both don't "get it", if you can't see that different types of storage serve radically different needs. The system described in the article is ideal for near-line, at-rest data. Sweet spots would include data warehousing, log storage and aggregation, HDFS backing, bulk content distribution store, even a small-to-medium business LAN file server (if coupled with a redundant server).
You wouldn't want to be putting OLTP systems on this environment - you could, but it's not its sweet spot, for many of the reasons you mention. Some of the products you mention do a better job of serving that market's needs, and does so at exorbitant prices that for most companies are significant barriers to adoption.
The article is quite clear that the system is a COMPONENT that does not address redundancy, in and of itself, but is used as a building block coupled with their glue that addresses their market's needs for availability, reliability, and accessibility. Use the right tool for the right job, and make it fit into the budget.
It doesn't look cool. It's the UI equivalent of spinners and under-chassis neon lighting.
I empathize with the pain you describe, but place the blame where due - on the stupidity of those that actually respond to the spam, or the shady fly-by-night viagra and penis pump outfits, or botnet operators. (there will always be idiots in legit companies who are just trying to make it, and don't follow double opt-in practices, and the CAN-SPAM law is in my opinion fatally flawed primarily through that omission.
Could be that many people who buy into MacOS X don't know as much about computers as others, just as you imply. Just for grins, though, try attending a technical conference sometime (one that doesn't have "MSDN" in the title), and count how many Apple laptops you see. Ultimately, I suspect that most people who use MacOS X, whether or not they're computer savvy or otherwise, just want something that they don't have to fight with or think about much.
Oracle bought the Innodb engine that provided much of whatever ACID compliance MySQL has. They had no real reason to do so, other than to give MySQL the finger. That didn't really slow MySQL down - but now that Sun owns MySQL, buying Sun will at least stem some portion of Oracle's market share being eaten from beneath. Maybe.
Oh yeah, Sun has a lot of storage and systems software that can be sold off or cannibalized at will, plus a patent portfolio that Larry can use to stick to competitors (though I haven't been aware of Oracle as a huge patent troll to date...)
Nicely stated, and I happen to agree with your assessment. Given that you've already experience the "Ellison touch", I think you know exactly what's going to happen with Sun's hardware. Fuzzier for software.
Sun materially offered nothing that couldn't be achieved cheaper elsewhere, and in this race-to-the-bottom commodity market, made it impossible to compete. Sun kept trying to do what they always did - engineer decent but conservative systems offered at a premium price. Remember, Sun thrived first in a time where the standard Intel offerings couldn't begin to compete with the multi-user scalability of Sun. They either couldn't recognize or couldn't adapt themselves to an evolved future wherein PCs dominated the sweetspot of the price-performance curve.
Oracle bought Sun because buying Innodb didn't kill MySQL. There's nothing else that Oracle can likely do with the other assets of Sun other than sell them for parts. I refuse to believe that Oracle has either the ability or the impetus to continue any of Sun's hardware or non-DB software.
Yes on apathy. That's how we as humans can survive - by NOT attaching ourselves to tragedies that don't have direct impact. Got enough to worry about.
Here's a completely uninformed theory (hey, it's slashdot). Swearing is taboo - there is thrill associated with breaking that taboo. That serves as the payoff for swearing. I'll bet that if they looked, they could find persons predisposed to addiction swear more often than those that don't. But what the fuck do I know.
One thing you can try is to change your default cipher - try as an option to scp or ssh "-c blowfish" It helps. Honestly, I prefer using WebDAV over HTTPS, even though the performance is worse than scp/sftp, because you (potentially) don't need to have an actual user account on the destination to achieve authentication.
Uh, yeah, I've never bought a second battery, for any of my cameras.