Personally, I think this is a good thing. Now to just neuter them, and we'll be set.
My current job (IT admin in the financial sector) involves a fair bit of security work. A natural understanding of security is stunningly absent, even in places where security should be one of the highest concerns. Someone building an accounting program won't think about encrypting their data, because they're trained in accounting, not security. Someone programming a radiation therapy machine won't think about hardware interlocks, because they're trained in programming software, not hardware safety.
Network-connected medical devices are becoming prevalent, and I expect they will only get more useful and necessary in time. They present opportunities for doctors, and hospital managers are trained in hospital management, not security.
I like seeing someone bringing a security-conscious mindset to the public. The DHS certainly wouldn't be my first choice, but they're better than not having anybody. Now if only we could get Bruce Schneier as Secretary...
It's also the kind of thinking that's been demonstrated to be true repeatedly over the past few millenia.
The phrase "loose lips sink ships" was used to remind WWII soldiers and families that enemies could infer sensitive information (like ship itineraries) from casual conversation (like Cousin Joe getting leave for Christmas). Today, America's enemies aren't nations - they're more often underground organizations of people (including American citizens) who disregard American laws.
In computer security, we find it perfectly understandable that phishers will collect certain bits of public information (addresses, names, preferences) then use that information later to execute the actual scam (such as getting Amazon to resend products for free). Why is it so hard to believe that others could do similar assembly and use the established procedures against the FBI? Perhaps exploiting a weakness in the procedure to generate fake exculpatory evidence? Even a trivial procedural note like "GPS reception was poor in <standard position>, so we moved the tracker to <somewhere else>" could be easily turned into a list of places to check (or parts to swap) before using a vehicle.
The expectation that the enemy will use all information they can get doesn't apply only to "believers" or "people in the system". It should apply to everyone with any interest in security. Yes, it'd be nice if the FBI had better oversight with an interest in preserving public freedom, but the make-everything-public ACLU isn't going to be able to provide that. All the ACLU will ever get is 90%-redacted memos. Any organization that is trusted by the FBI to provide such oversight without releasing sensitive information won't be trusted by the gub'mint-hating public.
Blocking open Ds will eliminate a lot of past-tense words. Blocking other open Es will require the opponent to have both Es for the many "ee" words. No, it's not possible to completely and reliably lock out opponents, but experts can make each turn very difficult. Most competitive players will keep track on their score sheet of which tiles have been played, giving them a clear picture of what options the opponent has. Some will even keep track in their head, accurately. It's not terribly hard to turn that list of options into a defensive strategy.
Those E's would be worth many points, but be effectively useless. The best Scrabble players can control their opponent's options. An expert would easily limit the E-playing options, until you're left with a rack full of tiles you can't play, and have to start exchanging tiles hoping for anything but an E.
First, there's the novice's strategy. Pull letters from the back, make a word on the rack, and figure out where it can fit. At this level, the game is purely a contest to see who has the biggest vocabulary.
For intermediate players, recognizing words scrambled on the rack is easier, and perhaps even memorizing common anagrams is a viable means for improvement. Multiple options are planned, and bonuses (including making multiple words) figure into the decision.
Experts use the letters more as a means to control the board, under the assumption that their opponent has perfect tiles to use opportunities open to them. The game is less about words, and more about controlling what options the other player has available. A low-scoring word may be the best option if it means that future plays will be better. The whole playable dictionary is memorized, and anagrams are recognized naturally. This is not to say that words are unimportant, but rather that the game is more of strategy than chance for experts.
Whether a particular letter actually matches its distribution means practically nothing to the really competitive players. The score total of each play, though, is something these players have spent years refining.
Source: One of my in-laws is one of the top 5 Scrabble players in his state. I know exactly how poorly I play... and I had a cheat sheet and help.
I lack the ambition to actually verify this one, but my experience with government contracts is that the vast majority are fixed-cost, same as any normal business transaction. Those that aren't usually have some percentage of additional cost applied, so the company will be absorbing most of the cost of overruns. I've yet to personally see a contract that says the government pays 100% for all cost overruns, but I do assume they exist.
Keep in mind that for every event that makes it to the news as a scandal, there's a few million mundane events that go perfectly as they should.
Fixing costs isn't stupidity - it's good business. NASA gets the technology for $17.8 million, per the contract. If the technology costs more than expected to develop, the extra cost probably falls on Bigelow rather than taxpayers. Meanwhile, NASA's management and researchers can focus on other things that may have less commercial application, so they won't be developed without government support.
One of NASA's goals is to ensure that space technology continues to advance. It's not required to do all the work itself.
IT cycles well because IT really just exists to work with humans, and human needs don't change much. All that ever changes is the current best way to accomplish some particular goal.
Need to put computing power in your workers' hands, without management hassles? Distribute identical terminals... to run the VDI client.
Need to store tons of data? Store your data in segments spread across a ton of media, and shuffle them around as needed to keep them organized and safe... which is trivial with a rack-aware filesystem on a large SAN.
Need to process tons of data? Divide the job into many small tasks, then book time on a nearby supercomputer... which is built from Hadoop MapReduce nodes for only a five-figure price tag.
Need a timeclock to track your workers? Punchcards are cheap, disposable, pretty reliable, and the plastic-coated ones are waterproof... but RFID tags are faster.
Each technology that's returning had some major issue that prevented its wide deployment (usually speed, size, or bandwidth), and other alternatives took the spotlight. Now that those problems have been solved (or reduced), the alternatives' shortcomings are highlighted, and those old solutions are being revisited.
Because copyright terms have changed over the years. For a work published in 1938 whose copyright was renewed (as was necessary then, and we'll assume occurred), it doesn't enter public domain until 95 years later: 2033.
This would only apply to the character itself (which may also be a trademark, which falls under different rules), and the first stories about that character. More recent stories and characters would have even later expiration dates.
Of course. That's why the middle-of-the-road average folks never brag about their fantasy football team, or how their kid did well in the science fair, or how perfectly that prank went off last week... And that failed project wasn't because of the "sick" day when the report was due, but definitely because of the manager's incompetence. Sure.
Everybody takes credit for their achievements, and blames others for their problems. Why should CEOs or criminals be any different?
My thoughts exactly. The petition was obviously a joke, but they're required to respond, so they respond. There's no requirement that they acquiesce to the demands of a tiny percentage of the population, regardless of what silent majority is perceived.
A good rule of thumb is that every issue is more complicated that everybody thinks:
Drone surveillance is obviously an invasion of privacy (unless its use is regulated, and it does provide an opportunity to improve police efficiency).
Syria obviously needs help (though it's not really clear which side should get the help, or how aid could be administered, or which side (if any) is less inclined to cause more bloodshed later).
America obviously should pull out of its Middle Eastern conflicts (miraculously without leaving any weapons, ammunition, vulnerable informants (or their families), or hard feelings, yet still leaving a peace-loving effective local government in place).
A major government labor project, such as building a Death Star, would create STEM-sector jobs for millions of unemployed (and disrupt international relations, start a new Cold War, and drive government debt even higher, with no source of funding).
The multinationals that get so easily upset are the paychecks and resources for most Americans, directly or indirectly. If they're in trouble, that's a large swath of America that's facing a rough road ahead. Similarly, most Americans (including an overlapping group) want to support the higher profit margins of local enterprise. Still another group of most Americans (including overlap) want to end up with more money in their own pocket without doing any more work.
It's wonderfully easy to blame the problems of the world on our political opponents, but the truth is that everything is everyone's fault. Everyone is subject to their biases, and everyone wants what's best for whatever cause they support, according to whatever theories they follow. Without perfect knowledge, there will continue to be disagreements, and the solutions are certainly not simple enough to fit in any petition response.
A petition will not solve the nation's problems. Neither will Congress, or a different President, or even a million activists protesting unhappiness. Only time will fix today's problems, but it will also bring tomorrow's.
But that's not good enough for Anonymous. Somebody saw a small story in the news, got outraged, and didn't bother finding facts. Then they stir up a small army of vigilantes who scour the Web for information, without concern for or restriction by due process. Exculpatory evidence need not be cataloged. Eventually something suitably close to incriminating is found, an a big fuss is made over it, to force a trial of public opinion. As the now-highly-publicized trial starts, the Anonymous participants move on to other activities, basking in the good feelings of having fought and won against the evil government and its corrupt law enforcement.
Then the real world goes on. The lawyers argue about whether the trial is fair, whether the evidence is admissible, whether all evidence is disclosed properly, and whether it's really even right to drag the whole rest of the school through the ensuing media circus. The town's under scrutiny for years, regardless of the actual outcome of the trial. "Innocent until proven guilty" doesn't matter, but Anonymous still doesn't care. They made a dent in their windmill.
I understand how a software keyboard can emulate a physical keyboard, but how about a webcam, or a graphics card, or a mobile phone.
Just like we've done many times with sound cards, old graphics cards, and serial devices. A piece of hardware is emulated, and it's connected to a non-infringing piece of real hardware. If the real value is in the software (as it would be in a software patent replaced by a patent on purpose-built hardware), then any similar hardware will do, and the "protected" software isn't really protected any more.
True. My experience is primarily with HBase, and the details that I know don't generalize I try to clearly mark. Most of what I say should apply to any BigTable-based NoSQL store, but there are certainly others out there.
I'm actually serious. If the software is the valuable part, emulate the whole system the software runs in, including all relevant parts. For a "chainsaw" program that may, for example, plan a cut to maximize the usable wood from a tree trunk, it may be sufficient to emulate the tree in a simulation with the custom hardware, complete with knots and flaws, and run an implementation of the chainsaw program (as disclosed in the patent or reverse-engineered from an original copy) in that simulation. The program gives the simulation a cutting plan, and the simulation can do anything with the plan, including running a competitor's chainsaw.
Thanks to emulation, any benefit from tying valuable software to patented purpose-built hardware is lost. Since the hardware isn't used, the patent isn't infringed, but the software can be copied (reimplemented) easily. The whole point of patents is to allow inventors time to market an invention before the competition can copy it, so having purpose-built hardware is actually worse (due to expense) than simply not patenting anything.
Oh dear... I seem to have offended your RDBMS-is-God sensibilities again. I do so love a good argument. I hope I can find one...
Please explain in what possible universe what you just described is better than a normal relational table where each row contains a timestamp, headers, content, and HTTP code. (And presumably a URL, although you left that out.)
One where every row has a monetary (and time) cost, which is conveniently close to the one we live in. On a huge database, pulling a specific set of rows from a date range may or may not actually align well with how the database is sharded. If you've been partitioning the table by the "URL" column, and now you want to query by the "timestamp" column for a single "URL" value, you're likely going to be doing all your work on a single shard, on a single server. Conversely, if you partition the table by timestamp, all searches for the most recent data will be hammering one server.
The URL is the row key, as stated the first time I mentioned the crawler example.
And, no, 'a sufficiently-slow crawler' is nonsense.
I could make one for you if you like. The point is to illustrate that since most NoSQL stores are column-oriented, it's more expensive to actually make new rows, but columns are cheap and easy. Each row can have its own set of column names to suit its needs. There is no enforcement of any particular table design.
A status is part of the headers, and the headers and the content are returned over the same connection in order. Any webcrawler that has the content has the other two, and if something it has all three, why would anything else be doing anything else?
Because it might. That's the point of the example, to show what can be done, in such a way that the principles can be applied elsewhere. Incidentally, you have highlighted another interesting aspect of such a design: it provides a passive measurement of the speed of the transmitting webserver, by measuring the time to receive the document as the timestamp difference between the status and content fields.
if you really are logging three unrelated things happening at three unrelated times, uh, duh, you should put them in three tables.
In an RDBMS, yes. This isn't an RDBMS, though. Specifically in HBase, large tables are preferred because they allow for easier load balancing. One big table will perform better than three smaller tables. Each table is partitioned by blocks of rows, so with three small tables it's possible (and more likely than pure random chance) that a query for data from the same row will end up running the query on the same node three times. On one big table, only the columns you ask for are scanned for the rows that match the query, and the row's position in one column is related to its position in other columns, so the whole row is found quickly.
(Now I'm wondering if there's actually any way to get a response that is _just_ the status codes in your universe. Or do you have to pull in every record and check?)
You just ask for only those columns. Since it's column-oriented, this is a straightforward operation, just as in an RDBMS you can ask for a row with a WHERE clause on the primary key.
There is nothing stopping fields from being blank in a RDBMs.
Again, you're missing the point of the example. It's not that the columns are blank - it's that they don't exist. They aren't taking space in the database, they aren't compressed, and they aren't null. They simply aren't.
(BTW, that 404 bit was a mistake from revision. It started out as a socket error, but then I got to thinking about whether it should be logged for retrial later, so I changed it to be a known failure, but didn't change the rest of the example)
The hardware part doesn't matter, though. Hardware can be emulated in software, and since that software emulation wouldn't be covered by the hardware-only patent, and couldn't have its own patent, there's now a publicly-available system that runs your software. The actual hardware becomes worthless, being purchased only as a means of getting an original copy of the latest software. Remember what happened to all the separate TVs, telephones, old computers, fax machines, and typewriters we used to have? That's the eventual fate of all purpose-built hardware. It's discarded as soon as its function is absorbed by something else.
All physical inventions are, by definition, following the laws of physics. All physics is, by definition, math. And all math, by definition, is not patentable.
The whole point of patents is to protect the market incentive for creating, rather than copying, technology. That doesn't somehow become magically irrelevant when software's involved. Producing a new algorithm that's better suited to a particular purpose takes a lot of work and research, and is easily copied by others once it's in production. Patent protection should still apply, to allow the original inventors the time to bring their product to market, and have a chance at recouping their investment, and maybe even profiting.
What's wrong with software patents is the speed at which the state of the art is advancing. Where an engine design remains relevant and useful for 20 years, computing technology progresses far faster, with obsolescence setting in after as few as two years. That's what I'd like to see changed. For each field of invention (e.g. computing, manufacturing, consumables, artistic production, etc.), a patent's life should be based on how fast that field progresses, with the lifespans reevaluated periodically. Software patents, for example, could reasonably expire after only three to five years. In that time, whatever improvements the patented algorithm made will likely be surpassed by simply using an older algorithm and faster hardware, so the patented algorithm itself is no longer driving innovation. On the other hand, a new vehicle engine design might not even see appreciable market penetration for a decade after introduction, as older cars are slowly replaced. Such a patent should live longer.
I think I'd been led the wrong direction on use cases for nosql solutions.
It sounds like you probably have. There's a lot of misinformation out there parroted by folks who don't really understand NoSQL paradigms. They'll say it lacks ACID, has no schema, relations, or joins, and they'd be right, but sometimes those features aren't actually necessary for a particular application. That's why I keep coming back to statistics: Statistical analysis is perfect for minimizing the effect of outliers such as corrupt data.
The idea of "agility" sounded good, which to my mind meant worrying less about the schema.
Ah, but that's only half of it. You don't have to worry about the schema in a rigid form. You do still need to arrange data in a way that makes sense, and you'll need to have a general idea of what you'll want to query by later, just to set up your keys. If you're working with, for instance, Web crawling records, a URL might make a good key.
If I need to add field to something, I add a field.
Most NoSQL products are column-centric. Adding a column is a trivial matter, and that's exactly how they're meant to be used. Consider the notion of using columns whose names are timestamps. In a RDBMS, that's madness. In HBase, that's almost* ideal. A query by date range can simply ask for rows that have columns matching that particular range. For that web crawler, it'd make perfect sense to have one column for each datum you want to record about a page at a particular time. Perhaps just headers, content. and HTTP code each time, but that's three new columns every time a page is crawled - and assuming a sufficiently-slow crawler, each row could have entirely different sets of columns!
But the part about no relations always seemed like a show stopper for any case I'm likely to encounter.
It's not that there aren't relations, but that they aren't enforced. A web site might have had a crawl attempted, but a 404 was returned. It could still be logged by just having a missing content column for that particular timestamp, and only the 404 column filled. On later queries about content, a filter would ignore everything but 200 responses. For statistics about dead links, the HTTP code might be all that's queried. On-the-fly analysis can be done without reconfiguring the data store.
It'd be nice to store user status updates in a way where I don't have to worry too much about types of update, but I can't do that if correlating 'mentions', the user that posted it, and visibility against user groups would be a problem.
Here's one solution, taking advantage of the multi-value aspect of each row (because that's really the important part):
Store a timestamped column for each event (status update, mention, visibility change). As you guessed, don't worry much about what each event is, but just store the details (much like Facebook's timeline thing). When someone tries to view a status, run a query to pull all events for the user, and run through them to determine the effective visibility privileges, the most recent status, and the number of "this person was mentioned" events. There's your answer.
As you may guess, that'd be pretty slow, but we do have the flexibility to do any kind of analysis without reconfiguring our whole database. We could think ahead a bit, though, and add to our schema for a big speed boost: Whenever a visibility change happens, the new settings are stored serialized in the event. Sure, it violates normalization, but we don't really care about that.Now, our query need not replay all of the user's events... just enough to get the last status and visibility, and any "mentioned" events. That'll at least be pretty likely constant time, regardless of how long our users have been around.
"Free-form crap" like blogs doesn't really care what database it's in. Use a blob in MySQL, and it won't matter. You'll be pulling the whole field as a unit and won't do analysis anyway.
The analysis of atomic data is exactly what NoSQL stores are designed for. MapReduce programs are built to evaluate every record in the table, filter out what's interesting, then run computation on that. The computation is done in stages that can be combined later in a multistage process. Rather than joining tables to build a huge set of possibilities, then trimming that table down to a result set, the query operates directly on a smaller data set, leaving correlation for a later stage. The result is a fast and accurate statistic, though there is a loss of precision due to any inconsistent records. Hence, bigger databases are preferred to minimize the error.
I like the analogy of NoSQL being a cabinet full of files, though I'd alter it a little. Rather than having no idea what's in the files, we do know what they're supposed to contain, but they're old and may not be perfectly complete as expected. To find some information about the contents, we have to dive in, flip through all the files, and make an effort. Yes, some files will be useless for our search, and some will be missing important data - but we can still get information of statistical significance. Note that over time, the forms might even change, adding new fields or changing options. We might have to ask a supervisor how to handle such odd cases, which is analogous to pushing some decisions back to the application.
When one wants to write a ton of data as fast as possible, where the data may not actually be complete or consistent (but still useful). Something on the order of a million rows a minute is a prime candidate for a NoSQL store. Consider, for example, the sum of all posts on Facebook at any given time.
From the other side, an application like the current trend of "Big Data" models, monitoring every aspect of every action on a website (or in a hospital, or through a retail distribution chain, or the environmental systems of a factory) to glean statistically-meaningful information also makes a good use case for NoSQL. At the expense of consistency, the store is designed to be fast and fault-tolerant, so it really doesn't matter whether the data's complete or not. For Big Data applications, which are interested only in statistics, having a few inconsistent records out of billions doesn't matter much to the end result.
Sure, traditional RDBMSs can be tweaked and optimized to make any particular query run as fast as any NoSQL engine... but that's an expensive and time-consuming process that's often not feasible.
Because the key word "religion" has been a hot issue for so long that it's built into many laws. Employers discriminating against a religion is outlawed, but forbidding membership in a non-religious group may be fine (and the reverse as well... employers often can't only hire one religion, but can mandate union membership). Church property may be exempt from police searches under age-old sanctuary laws. Of course, those taxes you mentioned can also mean a difference of 20-50% in a church budget.
Much of law is based on categorizing entities. Some categories are governed by this particular set of laws, other categories by a different set. Trying to work entities in to or out of any particular category is therefore a big part of a lawyer's job, and where lawyers get such a reputation for being dishonest.
And here I thought it was about not letting others take open-source software, package a wrapper around it, and sell it as their own closed-source work.
We need some form of DRM system that the user can manage to protect their system from physical access or general boot exploits.
Sounds familiar...
Once upon a time in a far-away land of fantasy, the great mechanical wizards of the Blue Tower toiled away with their spellbooks and tools day and night until they produced a novel machine. This machine was incredible, able to condense several books' worth of information into one circle of a magically-imbued fabric. Since only the wizards would be able to read the magical inscriptions, they also produced a machine, granted with the power of induction, to read the fabric's tales, and write new tales onto the cloth as well.
It was quickly apparent that this fabric would be fragile, and much valuable information could be damaged if a particularly important piece of fabric was reused. To solve both problems, the fabric was carried in a hard shell that only the reading and writing machine would open. Writing would only be allowed if a particular part of the shell was intact. In this manner, kings and nobles who had their important information stored could simply pierce the shell, and the fabric would be reasonably safe from accidental harm.
We should start working on making something like this real. Each user could just load up one of these fabric disks with keys they want to allow, and use some kind of toggling switch to enable or disable writing. Linux advocates could hand out key disks with their distros, and users could be reasonably safe from harm. The only real attack vector is physical access, at which point the attacker could just pry the case open and pull the drives.
Slashdot Mirror
Personally, I think this is a good thing. Now to just neuter them, and we'll be set.
My current job (IT admin in the financial sector) involves a fair bit of security work. A natural understanding of security is stunningly absent, even in places where security should be one of the highest concerns. Someone building an accounting program won't think about encrypting their data, because they're trained in accounting, not security. Someone programming a radiation therapy machine won't think about hardware interlocks, because they're trained in programming software, not hardware safety.
Network-connected medical devices are becoming prevalent, and I expect they will only get more useful and necessary in time. They present opportunities for doctors, and hospital managers are trained in hospital management, not security.
I like seeing someone bringing a security-conscious mindset to the public. The DHS certainly wouldn't be my first choice, but they're better than not having anybody. Now if only we could get Bruce Schneier as Secretary...
It's also the kind of thinking that's been demonstrated to be true repeatedly over the past few millenia.
The phrase "loose lips sink ships" was used to remind WWII soldiers and families that enemies could infer sensitive information (like ship itineraries) from casual conversation (like Cousin Joe getting leave for Christmas). Today, America's enemies aren't nations - they're more often underground organizations of people (including American citizens) who disregard American laws.
In computer security, we find it perfectly understandable that phishers will collect certain bits of public information (addresses, names, preferences) then use that information later to execute the actual scam (such as getting Amazon to resend products for free). Why is it so hard to believe that others could do similar assembly and use the established procedures against the FBI? Perhaps exploiting a weakness in the procedure to generate fake exculpatory evidence? Even a trivial procedural note like "GPS reception was poor in <standard position>, so we moved the tracker to <somewhere else>" could be easily turned into a list of places to check (or parts to swap) before using a vehicle.
The expectation that the enemy will use all information they can get doesn't apply only to "believers" or "people in the system". It should apply to everyone with any interest in security. Yes, it'd be nice if the FBI had better oversight with an interest in preserving public freedom, but the make-everything-public ACLU isn't going to be able to provide that. All the ACLU will ever get is 90%-redacted memos. Any organization that is trusted by the FBI to provide such oversight without releasing sensitive information won't be trusted by the gub'mint-hating public.
Blocking open Ds will eliminate a lot of past-tense words. Blocking other open Es will require the opponent to have both Es for the many "ee" words. No, it's not possible to completely and reliably lock out opponents, but experts can make each turn very difficult. Most competitive players will keep track on their score sheet of which tiles have been played, giving them a clear picture of what options the opponent has. Some will even keep track in their head, accurately. It's not terribly hard to turn that list of options into a defensive strategy.
Those E's would be worth many points, but be effectively useless. The best Scrabble players can control their opponent's options. An expert would easily limit the E-playing options, until you're left with a rack full of tiles you can't play, and have to start exchanging tiles hoping for anything but an E.
There are three ways to play Scrabble.
First, there's the novice's strategy. Pull letters from the back, make a word on the rack, and figure out where it can fit. At this level, the game is purely a contest to see who has the biggest vocabulary.
For intermediate players, recognizing words scrambled on the rack is easier, and perhaps even memorizing common anagrams is a viable means for improvement. Multiple options are planned, and bonuses (including making multiple words) figure into the decision.
Experts use the letters more as a means to control the board, under the assumption that their opponent has perfect tiles to use opportunities open to them. The game is less about words, and more about controlling what options the other player has available. A low-scoring word may be the best option if it means that future plays will be better. The whole playable dictionary is memorized, and anagrams are recognized naturally. This is not to say that words are unimportant, but rather that the game is more of strategy than chance for experts.
Whether a particular letter actually matches its distribution means practically nothing to the really competitive players. The score total of each play, though, is something these players have spent years refining.
Source: One of my in-laws is one of the top 5 Scrabble players in his state. I know exactly how poorly I play... and I had a cheat sheet and help.
I lack the ambition to actually verify this one, but my experience with government contracts is that the vast majority are fixed-cost, same as any normal business transaction. Those that aren't usually have some percentage of additional cost applied, so the company will be absorbing most of the cost of overruns. I've yet to personally see a contract that says the government pays 100% for all cost overruns, but I do assume they exist.
Keep in mind that for every event that makes it to the news as a scandal, there's a few million mundane events that go perfectly as they should.
Fixing costs isn't stupidity - it's good business. NASA gets the technology for $17.8 million, per the contract. If the technology costs more than expected to develop, the extra cost probably falls on Bigelow rather than taxpayers. Meanwhile, NASA's management and researchers can focus on other things that may have less commercial application, so they won't be developed without government support.
One of NASA's goals is to ensure that space technology continues to advance. It's not required to do all the work itself.
IT cycles well because IT really just exists to work with humans, and human needs don't change much. All that ever changes is the current best way to accomplish some particular goal.
Each technology that's returning had some major issue that prevented its wide deployment (usually speed, size, or bandwidth), and other alternatives took the spotlight. Now that those problems have been solved (or reduced), the alternatives' shortcomings are highlighted, and those old solutions are being revisited.
Because copyright terms have changed over the years. For a work published in 1938 whose copyright was renewed (as was necessary then, and we'll assume occurred), it doesn't enter public domain until 95 years later: 2033.
This would only apply to the character itself (which may also be a trademark, which falls under different rules), and the first stories about that character. More recent stories and characters would have even later expiration dates.
Of course. That's why the middle-of-the-road average folks never brag about their fantasy football team, or how their kid did well in the science fair, or how perfectly that prank went off last week... And that failed project wasn't because of the "sick" day when the report was due, but definitely because of the manager's incompetence. Sure.
Everybody takes credit for their achievements, and blames others for their problems. Why should CEOs or criminals be any different?
My thoughts exactly. The petition was obviously a joke, but they're required to respond, so they respond. There's no requirement that they acquiesce to the demands of a tiny percentage of the population, regardless of what silent majority is perceived.
A good rule of thumb is that every issue is more complicated that everybody thinks:
The multinationals that get so easily upset are the paychecks and resources for most Americans, directly or indirectly. If they're in trouble, that's a large swath of America that's facing a rough road ahead. Similarly, most Americans (including an overlapping group) want to support the higher profit margins of local enterprise. Still another group of most Americans (including overlap) want to end up with more money in their own pocket without doing any more work.
It's wonderfully easy to blame the problems of the world on our political opponents, but the truth is that everything is everyone's fault. Everyone is subject to their biases, and everyone wants what's best for whatever cause they support, according to whatever theories they follow. Without perfect knowledge, there will continue to be disagreements, and the solutions are certainly not simple enough to fit in any petition response.
A petition will not solve the nation's problems. Neither will Congress, or a different President, or even a million activists protesting unhappiness. Only time will fix today's problems, but it will also bring tomorrow's.
An inflammatory statement in a Slashdot story on privacy vs. government? Surely you jest!
But that's not good enough for Anonymous. Somebody saw a small story in the news, got outraged, and didn't bother finding facts. Then they stir up a small army of vigilantes who scour the Web for information, without concern for or restriction by due process. Exculpatory evidence need not be cataloged. Eventually something suitably close to incriminating is found, an a big fuss is made over it, to force a trial of public opinion. As the now-highly-publicized trial starts, the Anonymous participants move on to other activities, basking in the good feelings of having fought and won against the evil government and its corrupt law enforcement.
Then the real world goes on. The lawyers argue about whether the trial is fair, whether the evidence is admissible, whether all evidence is disclosed properly, and whether it's really even right to drag the whole rest of the school through the ensuing media circus. The town's under scrutiny for years, regardless of the actual outcome of the trial. "Innocent until proven guilty" doesn't matter, but Anonymous still doesn't care. They made a dent in their windmill.
I understand how a software keyboard can emulate a physical keyboard, but how about a webcam, or a graphics card, or a mobile phone.
Just like we've done many times with sound cards, old graphics cards, and serial devices. A piece of hardware is emulated, and it's connected to a non-infringing piece of real hardware. If the real value is in the software (as it would be in a software patent replaced by a patent on purpose-built hardware), then any similar hardware will do, and the "protected" software isn't really protected any more.
True. My experience is primarily with HBase, and the details that I know don't generalize I try to clearly mark. Most of what I say should apply to any BigTable-based NoSQL store, but there are certainly others out there.
Emulate a tree.
I'm actually serious. If the software is the valuable part, emulate the whole system the software runs in, including all relevant parts. For a "chainsaw" program that may, for example, plan a cut to maximize the usable wood from a tree trunk, it may be sufficient to emulate the tree in a simulation with the custom hardware, complete with knots and flaws, and run an implementation of the chainsaw program (as disclosed in the patent or reverse-engineered from an original copy) in that simulation. The program gives the simulation a cutting plan, and the simulation can do anything with the plan, including running a competitor's chainsaw.
Thanks to emulation, any benefit from tying valuable software to patented purpose-built hardware is lost. Since the hardware isn't used, the patent isn't infringed, but the software can be copied (reimplemented) easily. The whole point of patents is to allow inventors time to market an invention before the competition can copy it, so having purpose-built hardware is actually worse (due to expense) than simply not patenting anything.
Oh dear... I seem to have offended your RDBMS-is-God sensibilities again. I do so love a good argument. I hope I can find one...
Please explain in what possible universe what you just described is better than a normal relational table where each row contains a timestamp, headers, content, and HTTP code. (And presumably a URL, although you left that out.)
One where every row has a monetary (and time) cost, which is conveniently close to the one we live in. On a huge database, pulling a specific set of rows from a date range may or may not actually align well with how the database is sharded. If you've been partitioning the table by the "URL" column, and now you want to query by the "timestamp" column for a single "URL" value, you're likely going to be doing all your work on a single shard, on a single server. Conversely, if you partition the table by timestamp, all searches for the most recent data will be hammering one server.
The URL is the row key, as stated the first time I mentioned the crawler example.
And, no, 'a sufficiently-slow crawler' is nonsense.
I could make one for you if you like. The point is to illustrate that since most NoSQL stores are column-oriented, it's more expensive to actually make new rows, but columns are cheap and easy. Each row can have its own set of column names to suit its needs. There is no enforcement of any particular table design.
A status is part of the headers, and the headers and the content are returned over the same connection in order. Any webcrawler that has the content has the other two, and if something it has all three, why would anything else be doing anything else?
Because it might. That's the point of the example, to show what can be done, in such a way that the principles can be applied elsewhere. Incidentally, you have highlighted another interesting aspect of such a design: it provides a passive measurement of the speed of the transmitting webserver, by measuring the time to receive the document as the timestamp difference between the status and content fields.
if you really are logging three unrelated things happening at three unrelated times, uh, duh, you should put them in three tables.
In an RDBMS, yes. This isn't an RDBMS, though. Specifically in HBase, large tables are preferred because they allow for easier load balancing. One big table will perform better than three smaller tables. Each table is partitioned by blocks of rows, so with three small tables it's possible (and more likely than pure random chance) that a query for data from the same row will end up running the query on the same node three times. On one big table, only the columns you ask for are scanned for the rows that match the query, and the row's position in one column is related to its position in other columns, so the whole row is found quickly.
(Now I'm wondering if there's actually any way to get a response that is _just_ the status codes in your universe. Or do you have to pull in every record and check?)
You just ask for only those columns. Since it's column-oriented, this is a straightforward operation, just as in an RDBMS you can ask for a row with a WHERE clause on the primary key.
There is nothing stopping fields from being blank in a RDBMs.
Again, you're missing the point of the example. It's not that the columns are blank - it's that they don't exist. They aren't taking space in the database, they aren't compressed, and they aren't null. They simply aren't.
(BTW, that 404 bit was a mistake from revision. It started out as a socket error, but then I got to thinking about whether it should be logged for retrial later, so I changed it to be a known failure, but didn't change the rest of the example)
T
The hardware part doesn't matter, though. Hardware can be emulated in software, and since that software emulation wouldn't be covered by the hardware-only patent, and couldn't have its own patent, there's now a publicly-available system that runs your software. The actual hardware becomes worthless, being purchased only as a means of getting an original copy of the latest software. Remember what happened to all the separate TVs, telephones, old computers, fax machines, and typewriters we used to have? That's the eventual fate of all purpose-built hardware. It's discarded as soon as its function is absorbed by something else.
All physical inventions are, by definition, following the laws of physics. All physics is, by definition, math. And all math, by definition, is not patentable.
The whole point of patents is to protect the market incentive for creating, rather than copying, technology. That doesn't somehow become magically irrelevant when software's involved. Producing a new algorithm that's better suited to a particular purpose takes a lot of work and research, and is easily copied by others once it's in production. Patent protection should still apply, to allow the original inventors the time to bring their product to market, and have a chance at recouping their investment, and maybe even profiting.
What's wrong with software patents is the speed at which the state of the art is advancing. Where an engine design remains relevant and useful for 20 years, computing technology progresses far faster, with obsolescence setting in after as few as two years. That's what I'd like to see changed. For each field of invention (e.g. computing, manufacturing, consumables, artistic production, etc.), a patent's life should be based on how fast that field progresses, with the lifespans reevaluated periodically. Software patents, for example, could reasonably expire after only three to five years. In that time, whatever improvements the patented algorithm made will likely be surpassed by simply using an older algorithm and faster hardware, so the patented algorithm itself is no longer driving innovation. On the other hand, a new vehicle engine design might not even see appreciable market penetration for a decade after introduction, as older cars are slowly replaced. Such a patent should live longer.
I think I'd been led the wrong direction on use cases for nosql solutions.
It sounds like you probably have. There's a lot of misinformation out there parroted by folks who don't really understand NoSQL paradigms. They'll say it lacks ACID, has no schema, relations, or joins, and they'd be right, but sometimes those features aren't actually necessary for a particular application. That's why I keep coming back to statistics: Statistical analysis is perfect for minimizing the effect of outliers such as corrupt data.
The idea of "agility" sounded good, which to my mind meant worrying less about the schema.
Ah, but that's only half of it. You don't have to worry about the schema in a rigid form. You do still need to arrange data in a way that makes sense, and you'll need to have a general idea of what you'll want to query by later, just to set up your keys. If you're working with, for instance, Web crawling records, a URL might make a good key.
If I need to add field to something, I add a field.
Most NoSQL products are column-centric. Adding a column is a trivial matter, and that's exactly how they're meant to be used. Consider the notion of using columns whose names are timestamps. In a RDBMS, that's madness. In HBase, that's almost* ideal. A query by date range can simply ask for rows that have columns matching that particular range. For that web crawler, it'd make perfect sense to have one column for each datum you want to record about a page at a particular time. Perhaps just headers, content. and HTTP code each time, but that's three new columns every time a page is crawled - and assuming a sufficiently-slow crawler, each row could have entirely different sets of columns!
But the part about no relations always seemed like a show stopper for any case I'm likely to encounter.
It's not that there aren't relations, but that they aren't enforced. A web site might have had a crawl attempted, but a 404 was returned. It could still be logged by just having a missing content column for that particular timestamp, and only the 404 column filled. On later queries about content, a filter would ignore everything but 200 responses. For statistics about dead links, the HTTP code might be all that's queried. On-the-fly analysis can be done without reconfiguring the data store.
It'd be nice to store user status updates in a way where I don't have to worry too much about types of update, but I can't do that if correlating 'mentions', the user that posted it, and visibility against user groups would be a problem.
Here's one solution, taking advantage of the multi-value aspect of each row (because that's really the important part):
Store a timestamped column for each event (status update, mention, visibility change). As you guessed, don't worry much about what each event is, but just store the details (much like Facebook's timeline thing). When someone tries to view a status, run a query to pull all events for the user, and run through them to determine the effective visibility privileges, the most recent status, and the number of "this person was mentioned" events. There's your answer.
As you may guess, that'd be pretty slow, but we do have the flexibility to do any kind of analysis without reconfiguring our whole database. We could think ahead a bit, though, and add to our schema for a big speed boost: Whenever a visibility change happens, the new settings are stored serialized in the event. Sure, it violates normalization, but we don't really care about that.Now, our query need not replay all of the user's events... just enough to get the last status and visibility, and any "mentioned" events. That'll at least be pretty likely constant time, regardless of how long our users have been around.
Counting all those "mentioned" events might
That's almost exactly wrong.
"Free-form crap" like blogs doesn't really care what database it's in. Use a blob in MySQL, and it won't matter. You'll be pulling the whole field as a unit and won't do analysis anyway.
The analysis of atomic data is exactly what NoSQL stores are designed for. MapReduce programs are built to evaluate every record in the table, filter out what's interesting, then run computation on that. The computation is done in stages that can be combined later in a multistage process. Rather than joining tables to build a huge set of possibilities, then trimming that table down to a result set, the query operates directly on a smaller data set, leaving correlation for a later stage. The result is a fast and accurate statistic, though there is a loss of precision due to any inconsistent records. Hence, bigger databases are preferred to minimize the error.
I like the analogy of NoSQL being a cabinet full of files, though I'd alter it a little. Rather than having no idea what's in the files, we do know what they're supposed to contain, but they're old and may not be perfectly complete as expected. To find some information about the contents, we have to dive in, flip through all the files, and make an effort. Yes, some files will be useless for our search, and some will be missing important data - but we can still get information of statistical significance. Note that over time, the forms might even change, adding new fields or changing options. We might have to ask a supervisor how to handle such odd cases, which is analogous to pushing some decisions back to the application.
Assuming you're not trolling...
When one wants to write a ton of data as fast as possible, where the data may not actually be complete or consistent (but still useful). Something on the order of a million rows a minute is a prime candidate for a NoSQL store. Consider, for example, the sum of all posts on Facebook at any given time.
From the other side, an application like the current trend of "Big Data" models, monitoring every aspect of every action on a website (or in a hospital, or through a retail distribution chain, or the environmental systems of a factory) to glean statistically-meaningful information also makes a good use case for NoSQL. At the expense of consistency, the store is designed to be fast and fault-tolerant, so it really doesn't matter whether the data's complete or not. For Big Data applications, which are interested only in statistics, having a few inconsistent records out of billions doesn't matter much to the end result.
Sure, traditional RDBMSs can be tweaked and optimized to make any particular query run as fast as any NoSQL engine... but that's an expensive and time-consuming process that's often not feasible.
Because the key word "religion" has been a hot issue for so long that it's built into many laws. Employers discriminating against a religion is outlawed, but forbidding membership in a non-religious group may be fine (and the reverse as well... employers often can't only hire one religion, but can mandate union membership). Church property may be exempt from police searches under age-old sanctuary laws. Of course, those taxes you mentioned can also mean a difference of 20-50% in a church budget.
Much of law is based on categorizing entities. Some categories are governed by this particular set of laws, other categories by a different set. Trying to work entities in to or out of any particular category is therefore a big part of a lawyer's job, and where lawyers get such a reputation for being dishonest.
And here I thought it was about not letting others take open-source software, package a wrapper around it, and sell it as their own closed-source work.
How mistaken I must be...
We need some form of DRM system that the user can manage to protect their system from physical access or general boot exploits.
Sounds familiar...
Once upon a time in a far-away land of fantasy, the great mechanical wizards of the Blue Tower toiled away with their spellbooks and tools day and night until they produced a novel machine. This machine was incredible, able to condense several books' worth of information into one circle of a magically-imbued fabric. Since only the wizards would be able to read the magical inscriptions, they also produced a machine, granted with the power of induction, to read the fabric's tales, and write new tales onto the cloth as well.
It was quickly apparent that this fabric would be fragile, and much valuable information could be damaged if a particularly important piece of fabric was reused. To solve both problems, the fabric was carried in a hard shell that only the reading and writing machine would open. Writing would only be allowed if a particular part of the shell was intact. In this manner, kings and nobles who had their important information stored could simply pierce the shell, and the fabric would be reasonably safe from accidental harm.
We should start working on making something like this real. Each user could just load up one of these fabric disks with keys they want to allow, and use some kind of toggling switch to enable or disable writing. Linux advocates could hand out key disks with their distros, and users could be reasonably safe from harm. The only real attack vector is physical access, at which point the attacker could just pry the case open and pull the drives.