Those are the kind of "contextual clues" that people use all the time to make lethal misjudgements, and in the case at hand resulted in a completely innocent Brazilian who was legally in Britain going legally about his legal business being murdered by police.
No system lacking full disclosure of all information is perfect. People, by definition, *have* to make judgments without enough information to be sure. Yet we *have* to be sure.
Sometimes this results in mistakes. And sometimes, those mistakes add up to a lethal combination. But the vast majority of the time, those judgments, lacking full information, seem to do a pretty good job. In fact, even if you compare these judgement rantes to something like the odds that a particular Apache install will be active, you'll find that people, despite their occasional flaws, actually do a pretty damned good job.
Have you considered using one-time pads to minimize the risk of a key disclosure? Depending on your circumstances, you could actually allow full disclosure of the keys in a session and *still* have a very secure session!
Seems like the majority of the comments here deride this as a bad idea. But many (most?) of these same people rely on SSL and SSH to encrypt data, and purposefully send it out over a very public network, trusting the power of the encryption to protect them.
Logically, how is this really any different?
We've been using this technique for a long time, now. Our client-based application uses strong encryption to protect the files. Our encryption/decryption system embeds the password in as part of the encryption/decryption process. This means that if the laptop is ever stolen or lost, it does not constitute a compromise or leak of data.
Sure, it's possible that somebody could crack the encryption. But we use very standard, very trusted libraries and best practices. And even if it isn't bullet-proof, it's far, far better than no protection at all. And certainly, we aren't disclosing our encryption key in javascript!
The point here is that the Government previously said it was legal. Then after the fact, pull the rug out from underneath organizations in order to prosecute them.
"Da Gubbmint" is not a single entity. What defines what is legal are the LAWS of the land, not officials who are supposed to enforce them. Officials frequently break the law, and just 'cause you worked with a bad official doesn't mean you are protected.
You aren't protected, even if the bad official is the president. You break the law, you pay the price.
There is no doubt that the telecoms have some of the best legal advisors in the land, who should have informed the executives that the government requests were NOT in accordance with the laws of the land.
And they weren't. Warrantless surveillance, in numerous forms, has been found many times in history to clearly violate constitutional principles. The competent legal representatives should have advised the telcos to STEER CLEAR. But instead, they stuck a deal.
Oh, come on. It's not a BS unit. It's not like we're trying to scientifically measure them, just convey some idea what these big numbers might mean in a more "real world" sense. And, in that sense, the cliche of "LOC's" actually carries some legitimacy, in that books contain data that can be easily compared to bytes. When somebody asks me what a "byte" is, I usually start by explaining that 1 byte is a keystroke. While not strictly true (Unicode can take up to 4 bytes per character) it's still a useful comparison, and gives an idea of the vast amounts of information we now deal with.
Seriously, who remembers the day when a GB was an unimaginably large amount of disk space? I remember dreaming over a series of "Ultimate PC" articles in PC/Computing where the author goes "all out" to build the biggest, baddest PC around - and it had a full GIGABYTE of disk space for its Pentium/66 motherboard....
Now moving on: what privacy implications would this much processing power have? How long would it take for a billion PCs (equivalent) collectively computing to crack a 1024 bit key? 2048 bits? 4096 bits? Can an RSA key easily computed on a P3 in a few seconds still hold the NSA at bay, when they could conceivably have a the equivalent of a BILLION cores under a single point of control?
I remember when a 128 bit key was strong, now 1024 bits are commonplace, and 4096 are used for more extreme cases. Since a $50 used PC can compute a new 4096 bit key in a few seconds, perhaps we should be increasing key length more?
We do something similar with rsync, backing up about 6-8 TB of data. We have php scripts that manage it all and version the backups, keeping them as long as disk space allows. Heck, you can even have a copy of our scripts free of charge!
With these scripts, and a cheap-o tower computer with huge power supply and mondo cheap, SATA drives, we manage to reliably backup a half-dozen busy servers off-site, off-network, to a different city over the Internet automagically every night.
Yes, more information is needed, blah blah blah. But it's definitely a feasible idea.
Why is this a different "sense" organ? Because it uses the sense of "touch"?
Because to the user, it quickly stops feeling like a "touch" and becomes much more automatic. The end user literally stops feeling the "buzz" and instead it becomes more like a low-level "I know where North is" type of feeling as the brain rewires itself to accommodate this new input.
Once this has happened, it really feels like a new sense.
As posted elsewhere, similar experiments have been done with blind people and a buzzing sensor on the tongue. After acclimation, they quite literally begin to "see" and even stimulate the parts of the brain typically used for visual processing, despite it all being done by the sense of "touch" through the tongue.
Is a handheld compass also an "on-body" circuit? How about a handheld electronic compass that beeps when you're pointing north?
This story is a nothingburger. The concept here appears to be "but this was strapped to the writers' ankle". As if the pseudo-prosthetic reference has relevance here. The writer would have experienced the same revelations of orientation with dashboard GPS.
In both of the examples you gave, there is a clear sense of "Look here to get this information". In the OP, the user loses the input as a sense of "feeling" and it becomes far more automatic.
Most of what we do is web-based, so we took a hint from GlusterFS and moved the decisional logic to the client. We host the client so we can assume a trustworthy client. This make debugging easy since all we have to do is echo stuff and see it in the browser.
Data stores work something like gluster 'bricks' - they serve as only a data store, nothing more. You can thing of a data store as a webDAV server. Each partition is served by multiple data stores. To keep things simple, data stores trust requests and so 'auto-configure' based on the request.
We divide our data into partitions that correspond to DNS subdomains. Then we use DNS to publish partition data. We provide minimal of two hosts (IP addresses) for each subdomain. All writes are made to all hosts by opening multiple sockets. Reads are read from the first 'best' host after reading header data.
In the case where any host doesn't have matching 'best' data on a read, the socket reverses and a write is performed as read from the best read. This gives us auto-heal as needed. The only sticky point is delete, which we solve by assuming that a delete operation is successful only when all applicable data stores report success.
While implementation details are thorny and expensive, this is a system that should scale to any concievable size since we can partition to as many data stores as there is IP space to. And, by dividing our cloud so that data stores will be grouped along with the client's hosting, we should see near-perfect linear scalability.
Works well so far, but it took over a year of experience to get it all working right, though we certainly weren't working on it exclusively.
I've been on the market for a distributed, clustered file system for some time. Unfortunately, Hardoop is not really what I'm looking for. What I'm looking for:
1) Redundancy - no single point of failure. 2) Suitable for standard-sized file I/O. 3) Performance that doesn't completely suck ass. 4) Graceful re-integration when bringing a cluster portion back online. 5) Accessible through standard interfaces. (EG: Posix F/S) 6) Doesn't require a PHD in the technology to administer. 7) Doesn't require insane quantities of cash to build. 8) Stable.
There are clustered file systems that have some of these qualities. None that I've found so far have *all* of these qualities.
Hardoop fails on #1, #2, and #6. It has a single nameserver commanding the cluster, so if it goes down, well... (shrug) It also does poorly for "normal" sized files, somehow having a 10 GB file is the norm for Google. And setting a multiple node cluster up is definitely non-trivial.
Of all that I've reviewed, GlusterFS did the best but even in that case, I ran into severe over-serialization that brought my 6-node cluster to its knees. I tried three times to roll it out, and had to roll back all three times. I fiddled with the brick setup and caches for days before finally throwing in the towel.
Now I get by with rsyncing program files, and a homegrown data distribution setup using network sockets and xinetd. Not optimal to be sure, but so far it's scaled linearly and provides decent performance, at the price of a PHD in said technology. I guess you could compare our technology to MogileFS, only our scheme
A) uses DNS records to coordinate the cluster so that it scales up, B) has a richer "where is the file" schema than the simple flat keys used by Mogile, and C) has the ability to execute programs against files for performance. (EG: grep for searching text files, tar/gzip for compress/uncompress, virus scans, etc) D) has the ability to "hang open" for activities like logging.
So far, this has held up well with about 500,000 file operations and millions of log entries per business day with an average file size of about 1-3 megabytes and every sign that growth can continue by simply stacking on more hardware. No, I'm not talking about massive throughput, but I *am* talking about the need for high availability systems that scale nicely without bottlenecks and exorbitant expense. Yes, it works pretty well, but we've had to invest significant programming time to do this.
Guess it's like the old engineering saw: Convenient, Cheap, Quality: pick any two!
I've seen several comments here that you've left about just how bad cell phones are "at altitude". And while I can confirm the FCC regulations, I can't confirm the truth of this allegation - that using a cell phone at altitude (let's say about 3,000 feet above ground level?) causes a "denial of service attack".
Sure, I understand the theory - cell phones connect to the closest tower on a frequency that's not shared by other closest towers, and cell phones at altitude could connect to many towers using the same frequency and thus degrade system performance by "hogging" a channel - but is there any *documentation* that this effect actually happens?
As a software engineer, I can't name the number of times that I've identified a potential weakness in an algorithm, documented it as such in a comment in the code, and then discovered the note a year or two later after it's patently obvious that the flaw never materialized in any meaningful sense. Yes, those things *could* happen and cause things to come crashing down, but in many cases, it just doesn't happen.
Yes, the cell signal *could* connect to multiple towers at altitude. But even high altitudes aren't really that high. Even when crusigin at 30,000 feet, you are just 5 or 6-ish miles away. Since towers are typically about 5 miles apart, and don't share channels, that means that, in most cases, one tower will be significantly closer than the others. And the inverse square law is pretty strict - 2x the distance, 1/4 the signal strength. That means that at any time, there are perhaps two towers that will have more than 4x the signal strength as their nearest applicable neighbors.
Sure, I'll accept that there's some effect - but a DDOS that extends all the way to the horizon? Hardly. I'd really, really like to see any kind of actual study that would document this effect. Are you aware of any?
PS: I miss Technocrat. You had your reasons to let it go that I respect, but I still liked it.
1. Where was the firewall admin to prevent external systems from connecting to these webservers over port 8080? 2. Why did the admins use insecure tools or insecure systems to allow their credentials to be sniffed? 3. Where was the IDS/IPS to notice the sudden change in traffic? 4. Where was the load balancer/reverse proxy to intecept this junk? 5. Where was the routine review of logs to notice the dynamic DNS updates from computers with (presumably) static DNS entries somewhere? 6. Where was the periodic pen/vulnerability test against these systems?
Back around 2001, I found a "botnet" comprising a perl script that ran on websites. Because it ran as a child of Apache, it showed up as "http" in ps. It would log into an IRC server, and wait for commands which appeared to be little more than arbitrary bash commands that were shelled out.
Bone-headedly simple. Ran well on any unix website host running perl scripts, installed via an insecure formmail.pl script. I penetrated the IRC network and watched for a few hours while the operator attacked a few hosts. There were some 50 hosts or so. Then I killed the script and updated all copies of formmail.pl hosted on the server...
Is this new news?
What's next? "Hammers can be used to smack things, even if they aren't nails." !?!?!
Truth is this: no operating system is 100% secure. But this "botnet" isn't necessarily even a compromise of the Operating System! Port 8080 is above 1024, so non-root controlled processes can open sockets there. This may be nothing more than something like the perl script I mentioned and having nothing to do with the Operating System in question. The server wasn't compromised, just a bad script was running that had to be deleted, then killed with an Apache restart.
Given the parameters I just mentioned, there isn't an Operating System around that would stop this from happening. It's just that the "Mom's basement" fanbois get all riled up because it's gospel that Linux is immune to $allBadThings.
It's like the OP asks for a solution to a problem when using Linux, and then there's a grand cacophony of people denying that there is a problem! (when there is, why else was it presented?)
There are two solutions that I use:
1) Use tar to zip up the files with attributes, Then copy the.tar or.tgz file to the USB drive. Both Winzip and Archiver read tar files, so they can still be read on Win/Mac. Disadvantage? You can't easily save changes...
2) create a loopback file on the USB drive, format Ext3, then mount when it's needed. You get easy writes on Linux, but you can't read on Win/Mac w/o special drivers.
Of course it's unfair. You can get a *LOT* of data on a flash card nowadays. They're selling 8 GB cards at the store I'm standing in for $25. And a pidgeon could easily carry 4 of these. Go 16 GB cards, same size, double the capacity.
It's the common confusion of speed vs latency. Speed is how much you can cram through the pipe in a given period, and at this, pigeons excel.
Latency is end-to-end, unloaded communication lag, and this is where pigeons do very poorly.
Stunts like this one purposely confuse the two issues.
I can't help but feel that it's a matter of time. But really I don't see the difference between diluted Christians/Jews/Muslims/Buddhists/Hinduists and Scientologists.
That's because you've never been a Scientologist. They practice everything from exorcism (they call it "Auditing OT3" to kidnapping. (They call it the "introspection rundown")
When a religion decides to tell its members that they have to abort pregnancies, it's a bad idea. When a religion decides to tell its members lies about those who oppose it, it's a bad idea.
"Not seeing" the difference is matter of blindness an ineptitude on your part. Otherwise Christians are no different than the Branch Davidian cult.
This is late in the thread, this post will probably not be modded up. I hope you read it nonetheless.
You need PARTNERS! There are four planks to a well-run business, and they are: 1) Technical, 2) Operations/support, 3) Legal, 4) Finance.
You need to 1) Produce the product, 2) Support the product and the staff who do 3) CYA, 4) Count the money made.
It really is as simple as that. Since you provide #1, you either need to provide 2, 3, and 4 yourself, or find others who can provide them. I was in a position like you some 8 years ago. I had some interesting technology for application development that I thought was useful. I tried to go it alone for a year or two, and had only limited success.
But then I took a community business training class called "V3", run through my local college, that taught me the basics of running a startup business. They actually had a worksheet that you could use to evaluate the likelihood of success of your business. It was hard to swallow to realize that my odds of success were somewhere around 8%.
So I realized that I needed partners. And partners I found. Good partners, that, between the 4 partners, actually covered all four bases very nicely. And it's been a very well balanced company - not a single down quarter in 6+ years, and 40% to 70% annual growth.
We chose to grow organically rather than go the sudden rush/VC route, and we've done well with it.
Find partners who are decent, who you can trust, who are motivated and professional. If you do, you'll never regret it.
> Banks are, in fact, proof that SaaS is a very viable business model - they've been managing money as a service for hundreds of years....
Have you been following the news lately?
Yes. Funny that profits are UP...
Nice dodge. Connectivity is not required for ALL computer operations. The cloud push is designed to get people USED to the idea, even if it means degraded performance for now, so that they become used/dependent on it for ALL their needs. It's pure marketing/control freak bullshit.
It's not a dodge. DSL MODEMS do offer 99% or better uptime in most cases.
>At my cloud-computing company, we offer strong clauses in our default contracts for the benefit of our customers. We take information security > and privacy very seriously. All staff with access to privileged information are under a strongly worded NDA.
Bwhahaha! Only a lawyer would think that legalese has the ability to usurp physical and mathematical laws. The reality is that your employees can still, at any time, violate such pieces of paper and cause damage. Then there's the government, which current trends suggest will have an ever increasing scope of power and precedent to do whatever it wants. For example, look how well the constitution is protecting us from PATRIOT powered liberties violations...oh right, it isn't.
And how is that any different than the NDA signed by an employee? Oh, right, it's not any different.
so basically you're saying "sorry you've already lost your rights, so you might as well trust your data to me anyway with the expectation that when the authorities come knocking, I'll happily let them mine any and all data without any resistance." sorry, I'd rather retain the only copies of my data so to limit this kind of patent abuse. I'd love it if you'd define 'bad things' for me. What's ok today, isn't tomorrow, and that's the major thrust of the argument against 'cloud computing.' As we both know, writing congress without a check in the envelope will do exactly nothing.
I've worked as a server administrator or technology administrator for over 10 years, serving many thousands of clients in a variety of environments. I've only once been legally requested to recover data, and that was in a civil suit. It's just not commonplace. (But don't let that interfere with your rhetoric.) It's to your detriment to ignore the realities of the present.
It's all about probabilities, right? Moving the data from dozens of corporations to one centralized e-location just makes that location more tempting to would-be attackers. Also, the single point of failure moves from the old server rooms of these companies to the ever-so-pliant legal contracts between them and you. Net out, the only ones who gain something are those who benefit from easy access to huge data hoards....of other people's data.
Most of our clients have their servers in a hot, dusty closet at the end of the hall, protected by a $20 cardboard door with a $10 door knob, usually found unlocked. Compare that to our ultra-high-security data center with three high-security, mob-rated security doors, magnetic locks, and 10" steel-reinforced concrete walls, and tell me there's a net decline in security?
And the "single point of failure"? Give me a bag. We have redundant power. Redundant network feeds. Redundant load balancers. Redundant servers, in a cluster. Redundant hosting facilities, just in case. Redundant administrators, and a rule that our Admins never travel all together. We average somewhere between 99.95% and 99.99% uptime, with a pessimistic view.
This is just a level of service that a single admin on a tight budget can't manage.
Eww.. Write back when one can do high-data volume, high cpu load media work via RDP.
Why? What our clients need is highly structured data storage and collation. Data that they frequently don't
The people who should fear clouds are the people who want their data in their own hands, and don't trust third parties to handle it for then. It's that easy, and it's what will make SaaS fail.
I see sooo much bitching and whining here about "OMG Waat about the intarnetz goind down!" and "third party data security". I hear it all the way to the bank. Which, BTW, is an outsourced third party who manages information for me. (The bank, that is)
Woops!
See, money is information. It's abstract information about amassed wealth potential. It's not even pieces of paper, any more. (Perhaps 1% of my financial transactions by amount are in cash.) And the bank does a pretty damned good job of keeping track of this information for me, and even though thousands of bank employees have access to this privileged information, the real risk of harm from banking is pretty slim. Banks are, in fact, proof that SaaS is a very viable business model - they've been managing money as a service for hundreds of years....
Cloud computing is no different. You are trusting a third party to track information for you. It's really no more or less to it than that. Just as you should take some care about where you put your money, you should take some care about where you put your business information. (Which is, in a sense, another form of money)
"What about when the webs goes downzes!?" - Yea, that'd be tough. Since many businesses primarily transact on the Internet anyway, if the 'net is down, the company is effectively closed, anyway. And even a crappy $20/month home DSL line generally manages 99% or better uptime.
"Trust your information to a third party"... Take a look at the SLA for your contract. Wait, you don't have one? Well, you are getting what you are asking for. Any good contract with an out-sourced third party should include clauses for discretion. Talk to a lawyer if it matters. At my cloud-computing company, we offer strong clauses in our default contracts for the benefit of our customers. We take information security and privacy very seriously. All staff with access to privileged information are under a strongly worded NDA.
"Patriot Act" - do you think that the information being at a third party makes a damned bit of difference? If the feds want your data, they'll get it. The only real question is whether or not you spend time in the clink while they are doing it. My advice? 1) Don't do bad things, and 2) vote down the patriot act. I've several times written my congresscritters in opposition.
"Evil Plus Bad" - Yes, there are cases where outsourced vendors failed to perform backups. Go back to your SLA/Contract (you do have one, right?) and take a look at the terms. Periodically check to see that backups are being done - demand proof, and raise hell if you find any lack. It's your right, it's your money, and it's your contract.
Hook up with a company you can really trust.
People here are convinced that the worst is going to happen. Well, you know what? We've closed contracts after terrible things happened *in house*. Servers die with corrupt backup tapes, or backups of directory short-cuts. Horrid performance, where simple queries take minutes to perform. In one case, the client's server room was stolen. No, I'm not kidding. Servers,routers, switches, all gone. Including the backup tapes!
In our case, the equipment sits in a multi-million dollar, high-class, maximum security data center. We have a redundant site for Disaster Recovery, with fresh data every 24 hours, and a pre-release process that incidentally verifies out backups, every time we issue an update. And a third location just for long-term data backups and archiving. All with excellent security, under lock and key, with strong encryption in use.
I run a cloud-computing service, and I say with confidence: the Web "O/S" is here, and its name is Firefox/IE/Safari/WebKit/Opera.
Good parents would do well with this, poor parents terribly. If only there were a way to decide who gets to do this.... but then who gets to decide? We can't, that's who.
As an unschooling Dad with grown kids, I can say that it's not for everybody. What most people don't realize is that nearly all of the time spent in traditional school is waste. For about 90% of the time in class, the young kid is idle, boring his/her way through another day of teacher yammer. It's astonishingly effective at stifling creativity, crushing interest, and blunting any motivation or desire to achieve. Learning becomes synonymous with tortured boredom - hardly a way to encourage education!
Un-schooling, however, gives kids the time to explore themselves and who they are. When combined with a realistic representation of what's required, it's remarkably effective. But you have to be the right parent. To be successful at it, you have to:
1) Be willing to deal with your kids all the time.
2) Be attentive enough to notice when your kids' curiosity has been piqued so that you can get some supporting materials in the subject of interest,
3) Be intelligent enough to know when you aren't the right resource to teach NNN and hand the job off to somebody more competent.
4) Have the resources available to do it. It's often not cheap (such as when your daughter becomes fascinated with marine biology - there went (cough) $6,000... )
It's not for everybody. I would strongly recommend against it for the uneducated poor, for example. But if you are an educated parent who really cares about your kids, and are humble enough to say "I don't know", you'll probably do quite well at it. While some "unschoolers" are actually opposed to any type of classroom education, I've always presented it as an option to my kids. While it's often not very efficient, there are times where formalized education truly is the best option available. For example, it's almost impossible to learn the more advanced subjects outside a classroom.
But basic math and number sense? Basic reading? Simple science? These beg and scream for individualized instruction, and that's where homeschooling / unschooling excel.
Your kids will model you, to a great extent. They will use you as an example of who to be and what to value. So take a good, hard look at yourself and ask: If your kids ended up with your life, would you be happy with that?
Slashdot Mirror
Those are the kind of "contextual clues" that people use all the time to make lethal misjudgements, and in the case at hand resulted in a completely innocent Brazilian who was legally in Britain going legally about his legal business being murdered by police.
No system lacking full disclosure of all information is perfect. People, by definition, *have* to make judgments without enough information to be sure. Yet we *have* to be sure.
Sometimes this results in mistakes. And sometimes, those mistakes add up to a lethal combination. But the vast majority of the time, those judgments, lacking full information, seem to do a pretty good job. In fact, even if you compare these judgement rantes to something like the odds that a particular Apache install will be active, you'll find that people, despite their occasional flaws, actually do a pretty damned good job.
Wish you could edit posts!
Have you considered using one-time pads to minimize the risk of a key disclosure? Depending on your circumstances, you could actually allow full disclosure of the keys in a session and *still* have a very secure session!
Seems like the majority of the comments here deride this as a bad idea. But many (most?) of these same people rely on SSL and SSH to encrypt data, and purposefully send it out over a very public network, trusting the power of the encryption to protect them.
Logically, how is this really any different?
We've been using this technique for a long time, now. Our client-based application uses strong encryption to protect the files. Our encryption/decryption system embeds the password in as part of the encryption/decryption process. This means that if the laptop is ever stolen or lost, it does not constitute a compromise or leak of data.
Sure, it's possible that somebody could crack the encryption. But we use very standard, very trusted libraries and best practices. And even if it isn't bullet-proof, it's far, far better than no protection at all. And certainly, we aren't disclosing our encryption key in javascript!
The point here is that the Government previously said it was legal. Then after the fact, pull the rug out from underneath organizations in order to prosecute them.
"Da Gubbmint" is not a single entity. What defines what is legal are the LAWS of the land, not officials who are supposed to enforce them. Officials frequently break the law, and just 'cause you worked with a bad official doesn't mean you are protected.
You aren't protected, even if the bad official is the president. You break the law, you pay the price.
There is no doubt that the telecoms have some of the best legal advisors in the land, who should have informed the executives that the government requests were NOT in accordance with the laws of the land.
And they weren't. Warrantless surveillance, in numerous forms, has been found many times in history to clearly violate constitutional principles. The competent legal representatives should have advised the telcos to STEER CLEAR. But instead, they stuck a deal.
And the telcos need to pay.
Oh, come on. It's not a BS unit. It's not like we're trying to scientifically measure them, just convey some idea what these big numbers might mean in a more "real world" sense. And, in that sense, the cliche of "LOC's" actually carries some legitimacy, in that books contain data that can be easily compared to bytes. When somebody asks me what a "byte" is, I usually start by explaining that 1 byte is a keystroke. While not strictly true (Unicode can take up to 4 bytes per character) it's still a useful comparison, and gives an idea of the vast amounts of information we now deal with.
Seriously, who remembers the day when a GB was an unimaginably large amount of disk space? I remember dreaming over a series of "Ultimate PC" articles in PC/Computing where the author goes "all out" to build the biggest, baddest PC around - and it had a full GIGABYTE of disk space for its Pentium/66 motherboard....
Now moving on: what privacy implications would this much processing power have? How long would it take for a billion PCs (equivalent) collectively computing to crack a 1024 bit key? 2048 bits? 4096 bits? Can an RSA key easily computed on a P3 in a few seconds still hold the NSA at bay, when they could conceivably have a the equivalent of a BILLION cores under a single point of control?
I remember when a 128 bit key was strong, now 1024 bits are commonplace, and 4096 are used for more extreme cases. Since a $50 used PC can compute a new 4096 bit key in a few seconds, perhaps we should be increasing key length more?
I second that motion....
We do something similar with rsync, backing up about 6-8 TB of data. We have php scripts that manage it all and version the backups, keeping them as long as disk space allows. Heck, you can even have a copy of our scripts free of charge!
With these scripts, and a cheap-o tower computer with huge power supply and mondo cheap, SATA drives, we manage to reliably backup a half-dozen busy servers off-site, off-network, to a different city over the Internet automagically every night.
Yes, more information is needed, blah blah blah. But it's definitely a feasible idea.
A vanishingly small percentage of the population actually sees four colors. To them, we're somewhat color blind as well. I wonder if this type of therapy can be used to give us 25% blindies another color to check out?
You know what's even more funny? He claims to have a degree in electrical engineering!
Why is this a different "sense" organ? Because it uses the sense of "touch"?
Because to the user, it quickly stops feeling like a "touch" and becomes much more automatic. The end user literally stops feeling the "buzz" and instead it becomes more like a low-level "I know where North is" type of feeling as the brain rewires itself to accommodate this new input.
Once this has happened, it really feels like a new sense.
As posted elsewhere, similar experiments have been done with blind people and a buzzing sensor on the tongue. After acclimation, they quite literally begin to "see" and even stimulate the parts of the brain typically used for visual processing, despite it all being done by the sense of "touch" through the tongue.
Is a handheld compass also an "on-body" circuit? How about a handheld electronic compass that beeps when you're pointing north?
This story is a nothingburger. The concept here appears to be "but this was strapped to the writers' ankle". As if the pseudo-prosthetic reference has relevance here. The writer would have experienced the same revelations of orientation with dashboard GPS.
In both of the examples you gave, there is a clear sense of "Look here to get this information". In the OP, the user loses the input as a sense of "feeling" and it becomes far more automatic.
I'll get off your lawn now, mmkay?
Take down notice: BAD
Software developer: GOOD
Copyrights: BAD
Twitter: GOOD
Lawsuit: BAD
Caught red-handed: GOOD
==Head Assplodes=l
Most of what we do is web-based, so we took a hint from GlusterFS and moved the decisional logic to the client. We host the client so we can assume a trustworthy client. This make debugging easy since all we have to do is echo stuff and see it in the browser.
Data stores work something like gluster 'bricks' - they serve as only a data store, nothing more. You can thing of a data store as a webDAV server. Each partition is served by multiple data stores. To keep things simple, data stores trust requests and so 'auto-configure' based on the request.
We divide our data into partitions that correspond to DNS subdomains. Then we use DNS to publish partition data. We provide minimal of two hosts (IP addresses) for each subdomain. All writes are made to all hosts by opening multiple sockets. Reads are read from the first 'best' host after reading header data.
In the case where any host doesn't have matching 'best' data on a read, the socket reverses and a write is performed as read from the best read. This gives us auto-heal as needed. The only sticky point is delete, which we solve by assuming that a delete operation is successful only when all applicable data stores report success.
While implementation details are thorny and expensive, this is a system that should scale to any concievable size since we can partition to as many data stores as there is IP space to. And, by dividing our cloud so that data stores will be grouped along with the client's hosting, we should see near-perfect linear scalability.
Works well so far, but it took over a year of experience to get it all working right, though we certainly weren't working on it exclusively.
What's your project like?
I've been on the market for a distributed, clustered file system for some time. Unfortunately, Hardoop is not really what I'm looking for. What I'm looking for:
1) Redundancy - no single point of failure.
2) Suitable for standard-sized file I/O.
3) Performance that doesn't completely suck ass.
4) Graceful re-integration when bringing a cluster portion back online.
5) Accessible through standard interfaces. (EG: Posix F/S)
6) Doesn't require a PHD in the technology to administer.
7) Doesn't require insane quantities of cash to build.
8) Stable.
There are clustered file systems that have some of these qualities. None that I've found so far have *all* of these qualities.
Hardoop fails on #1, #2, and #6. It has a single nameserver commanding the cluster, so if it goes down, well... (shrug) It also does poorly for "normal" sized files, somehow having a 10 GB file is the norm for Google. And setting a multiple node cluster up is definitely non-trivial.
Of all that I've reviewed, GlusterFS did the best but even in that case, I ran into severe over-serialization that brought my 6-node cluster to its knees. I tried three times to roll it out, and had to roll back all three times. I fiddled with the brick setup and caches for days before finally throwing in the towel.
Now I get by with rsyncing program files, and a homegrown data distribution setup using network sockets and xinetd. Not optimal to be sure, but so far it's scaled linearly and provides decent performance, at the price of a PHD in said technology. I guess you could compare our technology to MogileFS, only our scheme
A) uses DNS records to coordinate the cluster so that it scales up,
B) has a richer "where is the file" schema than the simple flat keys used by Mogile, and
C) has the ability to execute programs against files for performance. (EG: grep for searching text files, tar/gzip for compress/uncompress, virus scans, etc)
D) has the ability to "hang open" for activities like logging.
So far, this has held up well with about 500,000 file operations and millions of log entries per business day with an average file size of about 1-3 megabytes and every sign that growth can continue by simply stacking on more hardware. No, I'm not talking about massive throughput, but I *am* talking about the need for high availability systems that scale nicely without bottlenecks and exorbitant expense. Yes, it works pretty well, but we've had to invest significant programming time to do this.
Guess it's like the old engineering saw: Convenient, Cheap, Quality: pick any two!
... 5. The solution is clear: Clone Carl Sagan!
Where's my flying car so I (alone) can leave the unwashed masses on the ground.
There. Fixed that for ye...
Hey Bruce!
I've seen several comments here that you've left about just how bad cell phones are "at altitude". And while I can confirm the FCC regulations, I can't confirm the truth of this allegation - that using a cell phone at altitude (let's say about 3,000 feet above ground level?) causes a "denial of service attack".
Sure, I understand the theory - cell phones connect to the closest tower on a frequency that's not shared by other closest towers, and cell phones at altitude could connect to many towers using the same frequency and thus degrade system performance by "hogging" a channel - but is there any *documentation* that this effect actually happens?
As a software engineer, I can't name the number of times that I've identified a potential weakness in an algorithm, documented it as such in a comment in the code, and then discovered the note a year or two later after it's patently obvious that the flaw never materialized in any meaningful sense. Yes, those things *could* happen and cause things to come crashing down, but in many cases, it just doesn't happen.
Yes, the cell signal *could* connect to multiple towers at altitude. But even high altitudes aren't really that high. Even when crusigin at 30,000 feet, you are just 5 or 6-ish miles away. Since towers are typically about 5 miles apart, and don't share channels, that means that, in most cases, one tower will be significantly closer than the others. And the inverse square law is pretty strict - 2x the distance, 1/4 the signal strength. That means that at any time, there are perhaps two towers that will have more than 4x the signal strength as their nearest applicable neighbors.
Sure, I'll accept that there's some effect - but a DDOS that extends all the way to the horizon? Hardly. I'd really, really like to see any kind of actual study that would document this effect. Are you aware of any?
PS: I miss Technocrat. You had your reasons to let it go that I respect, but I still liked it.
1. Where was the firewall admin to prevent external systems from connecting to these webservers over port 8080?
2. Why did the admins use insecure tools or insecure systems to allow their credentials to be sniffed?
3. Where was the IDS/IPS to notice the sudden change in traffic?
4. Where was the load balancer/reverse proxy to intecept this junk?
5. Where was the routine review of logs to notice the dynamic DNS updates from computers with (presumably) static DNS entries somewhere?
6. Where was the periodic pen/vulnerability test against these systems?
...
7) Where was the funding to pay for 1 through 6?
Is it just me that's annoyed that in most cars we actually still use glorified wheels ?
There, fixed that for you...
PS: Old technology is often the best, otherwise it would be DEAD technology....
Back around 2001, I found a "botnet" comprising a perl script that ran on websites. Because it ran as a child of Apache, it showed up as "http" in ps. It would log into an IRC server, and wait for commands which appeared to be little more than arbitrary bash commands that were shelled out.
Bone-headedly simple. Ran well on any unix website host running perl scripts, installed via an insecure formmail.pl script. I penetrated the IRC network and watched for a few hours while the operator attacked a few hosts. There were some 50 hosts or so. Then I killed the script and updated all copies of formmail.pl hosted on the server...
Is this new news?
What's next? "Hammers can be used to smack things, even if they aren't nails." !?!?!
Truth is this: no operating system is 100% secure. But this "botnet" isn't necessarily even a compromise of the Operating System! Port 8080 is above 1024, so non-root controlled processes can open sockets there. This may be nothing more than something like the perl script I mentioned and having nothing to do with the Operating System in question. The server wasn't compromised, just a bad script was running that had to be deleted, then killed with an Apache restart.
Given the parameters I just mentioned, there isn't an Operating System around that would stop this from happening. It's just that the "Mom's basement" fanbois get all riled up because it's gospel that Linux is immune to $allBadThings.
It's like the OP asks for a solution to a problem when using Linux, and then there's a grand cacophony of people denying that there is a problem! (when there is, why else was it presented?)
There are two solutions that I use:
1) Use tar to zip up the files with attributes, Then copy the .tar or .tgz file to the USB drive. Both Winzip and Archiver read tar files, so they can still be read on Win/Mac. Disadvantage? You can't easily save changes...
2) create a loopback file on the USB drive, format Ext3, then mount when it's needed. You get easy writes on Linux, but you can't read on Win/Mac w/o special drivers.
Of course it's unfair. You can get a *LOT* of data on a flash card nowadays. They're selling 8 GB cards at the store I'm standing in for $25. And a pidgeon could easily carry 4 of these. Go 16 GB cards, same size, double the capacity.
It's the common confusion of speed vs latency. Speed is how much you can cram through the pipe in a given period, and at this, pigeons excel.
Latency is end-to-end, unloaded communication lag, and this is where pigeons do very poorly.
Stunts like this one purposely confuse the two issues.
I can't help but feel that it's a matter of time. But really I don't see the difference between diluted Christians/Jews/Muslims/Buddhists/Hinduists and Scientologists.
That's because you've never been a Scientologist. They practice everything from exorcism (they call it "Auditing OT3" to kidnapping. (They call it the "introspection rundown")
When a religion decides to tell its members that they have to abort pregnancies, it's a bad idea. When a religion decides to tell its members lies about those who oppose it, it's a bad idea.
"Not seeing" the difference is matter of blindness an ineptitude on your part. Otherwise Christians are no different than the Branch Davidian cult.
This is late in the thread, this post will probably not be modded up. I hope you read it nonetheless.
You need PARTNERS! There are four planks to a well-run business, and they are: 1) Technical, 2) Operations/support, 3) Legal, 4) Finance.
You need to 1) Produce the product, 2) Support the product and the staff who do 3) CYA, 4) Count the money made.
It really is as simple as that. Since you provide #1, you either need to provide 2, 3, and 4 yourself, or find others who can provide them. I was in a position like you some 8 years ago. I had some interesting technology for application development that I thought was useful. I tried to go it alone for a year or two, and had only limited success.
But then I took a community business training class called "V3", run through my local college, that taught me the basics of running a startup business. They actually had a worksheet that you could use to evaluate the likelihood of success of your business. It was hard to swallow to realize that my odds of success were somewhere around 8%.
So I realized that I needed partners. And partners I found. Good partners, that, between the 4 partners, actually covered all four bases very nicely. And it's been a very well balanced company - not a single down quarter in 6+ years, and 40% to 70% annual growth.
We chose to grow organically rather than go the sudden rush/VC route, and we've done well with it.
Find partners who are decent, who you can trust, who are motivated and professional. If you do, you'll never regret it.
I wish you the best of luck.
> Banks are, in fact, proof that SaaS is a very viable business model - they've been managing money as a service for hundreds of years....
Have you been following the news lately?
Yes. Funny that profits are UP...
Nice dodge. Connectivity is not required for ALL computer operations. The cloud push is designed to get people USED to the idea, even if it means degraded performance for now, so that they become used/dependent on it for ALL their needs. It's pure marketing/control freak bullshit.
It's not a dodge. DSL MODEMS do offer 99% or better uptime in most cases.
>At my cloud-computing company, we offer strong clauses in our default contracts for the benefit of our customers. We take information security
> and privacy very seriously. All staff with access to privileged information are under a strongly worded NDA.
Bwhahaha! Only a lawyer would think that legalese has the ability to usurp physical and mathematical laws. The reality is that your employees can still, at any time, violate such pieces of paper and cause damage. Then there's the government, which current trends suggest will have an ever increasing scope of power and precedent to do whatever it wants. For example, look how well the constitution is protecting us from PATRIOT powered liberties violations...oh right, it isn't.
And how is that any different than the NDA signed by an employee? Oh, right, it's not any different.
so basically you're saying "sorry you've already lost your rights, so you might as well trust your data to me anyway with the expectation that when the authorities come knocking, I'll happily let them mine any and all data without any resistance." sorry, I'd rather retain the only copies of my data so to limit this kind of patent abuse. I'd love it if you'd define 'bad things' for me. What's ok today, isn't tomorrow, and that's the major thrust of the argument against 'cloud computing.' As we both know, writing congress without a check in the envelope will do exactly nothing.
I've worked as a server administrator or technology administrator for over 10 years, serving many thousands of clients in a variety of environments. I've only once been legally requested to recover data, and that was in a civil suit. It's just not commonplace. (But don't let that interfere with your rhetoric.) It's to your detriment to ignore the realities of the present.
It's all about probabilities, right? Moving the data from dozens of corporations to one centralized e-location just makes that location more tempting to would-be attackers. Also, the single point of failure moves from the old server rooms of these companies to the ever-so-pliant legal contracts between them and you. Net out, the only ones who gain something are those who benefit from easy access to huge data hoards....of other people's data.
Most of our clients have their servers in a hot, dusty closet at the end of the hall, protected by a $20 cardboard door with a $10 door knob, usually found unlocked. Compare that to our ultra-high-security data center with three high-security, mob-rated security doors, magnetic locks, and 10" steel-reinforced concrete walls, and tell me there's a net decline in security?
And the "single point of failure"? Give me a bag. We have redundant power. Redundant network feeds. Redundant load balancers. Redundant servers, in a cluster. Redundant hosting facilities, just in case. Redundant administrators, and a rule that our Admins never travel all together. We average somewhere between 99.95% and 99.99% uptime, with a pessimistic view.
This is just a level of service that a single admin on a tight budget can't manage.
Eww.. Write back when one can do high-data volume, high cpu load media work via RDP.
Why? What our clients need is highly structured data storage and collation. Data that they frequently don't
The people who should fear clouds are the people who want their data in their own hands, and don't trust third parties to handle it for then. It's that easy, and it's what will make SaaS fail.
I see sooo much bitching and whining here about "OMG Waat about the intarnetz goind down!" and "third party data security". I hear it all the way to the bank. Which, BTW, is an outsourced third party who manages information for me. (The bank, that is)
Woops!
See, money is information. It's abstract information about amassed wealth potential. It's not even pieces of paper, any more. (Perhaps 1% of my financial transactions by amount are in cash.) And the bank does a pretty damned good job of keeping track of this information for me, and even though thousands of bank employees have access to this privileged information, the real risk of harm from banking is pretty slim. Banks are, in fact, proof that SaaS is a very viable business model - they've been managing money as a service for hundreds of years....
Cloud computing is no different. You are trusting a third party to track information for you. It's really no more or less to it than that. Just as you should take some care about where you put your money, you should take some care about where you put your business information. (Which is, in a sense, another form of money)
"What about when the webs goes downzes!?" - Yea, that'd be tough. Since many businesses primarily transact on the Internet anyway, if the 'net is down, the company is effectively closed, anyway. And even a crappy $20/month home DSL line generally manages 99% or better uptime.
"Trust your information to a third party"... Take a look at the SLA for your contract. Wait, you don't have one? Well, you are getting what you are asking for. Any good contract with an out-sourced third party should include clauses for discretion. Talk to a lawyer if it matters. At my cloud-computing company, we offer strong clauses in our default contracts for the benefit of our customers. We take information security and privacy very seriously. All staff with access to privileged information are under a strongly worded NDA.
"Patriot Act" - do you think that the information being at a third party makes a damned bit of difference? If the feds want your data, they'll get it. The only real question is whether or not you spend time in the clink while they are doing it. My advice? 1) Don't do bad things, and 2) vote down the patriot act. I've several times written my congresscritters in opposition.
"Evil Plus Bad" - Yes, there are cases where outsourced vendors failed to perform backups. Go back to your SLA/Contract (you do have one, right?) and take a look at the terms. Periodically check to see that backups are being done - demand proof, and raise hell if you find any lack. It's your right, it's your money, and it's your contract.
Hook up with a company you can really trust.
People here are convinced that the worst is going to happen. Well, you know what? We've closed contracts after terrible things happened *in house*. Servers die with corrupt backup tapes, or backups of directory short-cuts. Horrid performance, where simple queries take minutes to perform. In one case, the client's server room was stolen. No, I'm not kidding. Servers,routers, switches, all gone. Including the backup tapes!
In our case, the equipment sits in a multi-million dollar, high-class, maximum security data center. We have a redundant site for Disaster Recovery, with fresh data every 24 hours, and a pre-release process that incidentally verifies out backups, every time we issue an update. And a third location just for long-term data backups and archiving. All with excellent security, under lock and key, with strong encryption in use.
I run a cloud-computing service, and I say with confidence: the Web "O/S" is here, and its name is Firefox/IE/Safari/WebKit/Opera.
Good parents would do well with this, poor parents terribly. If only there were a way to decide who gets to do this.... but then who gets to decide? We can't, that's who.
As an unschooling Dad with grown kids, I can say that it's not for everybody. What most people don't realize is that nearly all of the time spent in traditional school is waste. For about 90% of the time in class, the young kid is idle, boring his/her way through another day of teacher yammer. It's astonishingly effective at stifling creativity, crushing interest, and blunting any motivation or desire to achieve. Learning becomes synonymous with tortured boredom - hardly a way to encourage education!
Un-schooling, however, gives kids the time to explore themselves and who they are. When combined with a realistic representation of what's required, it's remarkably effective. But you have to be the right parent. To be successful at it, you have to:
1) Be willing to deal with your kids all the time.
2) Be attentive enough to notice when your kids' curiosity has been piqued so that you can get some supporting materials in the subject of interest,
3) Be intelligent enough to know when you aren't the right resource to teach NNN and hand the job off to somebody more competent.
4) Have the resources available to do it. It's often not cheap (such as when your daughter becomes fascinated with marine biology - there went (cough) $6,000... )
It's not for everybody. I would strongly recommend against it for the uneducated poor, for example. But if you are an educated parent who really cares about your kids, and are humble enough to say "I don't know", you'll probably do quite well at it. While some "unschoolers" are actually opposed to any type of classroom education, I've always presented it as an option to my kids. While it's often not very efficient, there are times where formalized education truly is the best option available. For example, it's almost impossible to learn the more advanced subjects outside a classroom.
But basic math and number sense? Basic reading? Simple science? These beg and scream for individualized instruction, and that's where homeschooling / unschooling excel.
Your kids will model you, to a great extent. They will use you as an example of who to be and what to value. So take a good, hard look at yourself and ask: If your kids ended up with your life, would you be happy with that?