I disagree. Even if it's for your own reference, a database is (in my opinion) worth it.
For one thing, the structure of a database encourages you to stay organized in a way that a delimited text file doesn't (e.g. enforcing strict type rules for columns).
Perhaps more importantly, using a (well-established) database system means that you can all kinds of add-ons, extensions, and useful tricks 'for free'. Data is becomes more useful the more you're able to interact with it (by which I mean add/manage data, query data, visualize data, etc.). By using a database, you immediately have access to a whole slew of software. For example you will not only be limited to querying the data in your own code, but can also organize it using a GUI management/query tool, or a web-browser, or interface with your favorite spreadsheet, etc. (Obviously you can do all this with a "roll-your-own" approach, but it will take you much longer and probably won't be as elegant/robust/scaleable).
In short, I've found that even for relatively small datasets, having things in a proper database can be amazingly powerful. It causes me to analyze and extract insight from the data in ways that I wouldn't have otherwise. I also love the power of command-line text processing... but for database-like information (multi-column, etc.), in my experience you should get it into a database. From the sound of the original post, it sounds like the submitter has indeed hit the level where he would extract more value from having a database.
I think it's such a significant scientific achievement that it will be on the cover of Wired. Not to be a jerk, but truly "significant scientific achievements" end up on the cover of Science Magazine or Nature Magazine, not Wired.
Getting on the cover of Wired is more of a significant marketing achievement.
More seriously, if this is actually a scientific advance, then it would be published in peer-reviewed journals, scrutinized by the community, and (if worthy) built upon by others. It isn't really science if you keep the secrets of your techniques locked up, and don't allow others to see/understand what you're doing. And it's certainly not a "significant achievement" if all you're doing is using the same techniques that are well-established in the field. Grandiose claims of novelty need correspondingly rigorous evidence.
In addition to the applications you mentioned (medicine and security), a more mundane application is in manufacturing and quality control. For instance, with these scanners you can automate the quality and consistency checks on many manufactured goods, including foods. For instance, the scans could visualize the internal dispersion of nuts in a candy bar, or the consistency of bread. It could also be very useful for detecting anomalous matter in food (e.g. pick out metal or a band-aid that accidentally found its way into the food), or detecting insects and larvae inside fruits and vegetables.
The scans are totally benign and non-ionizing, so there's no health risks associated with scanning food.
You're absolutely correct that it takes a ton of research (and hence a ton of money) to find those few successful drugs that work.
The question remains: is the most sensible way to pay for all that research to hide the cost in successful drugs? Is giving out temporary monopolies on the sale of drugs really the most efficient (and ethical) way to it?
On the surface of it, something feels "wrong" about having the price of drugs be so uncorrelated to their manufacturing cost. Digging deeper, it is surely bothersome that the prices we are charged for drugs may be well above what is needed to pay for all the research. (For instance, approximately half of that money goes into advertising.) Deeper still, and it seems wholly unethical to charge people so much for things they need to save their lives.
What are the alternatives? Well, we could just fund scientists to do the research and release the results for anyone to use. (Companies would then compete only on who can manufacture the drugs to specification at the best price.) In fact, a large amount of medical research is already performed outside of industry. I don't see why we couldn't divert the current money put towards buying expensive drugs, and put it towards directly funding the research instead.
True, we lose the free market competition of having pharmaceutical companies competing with each other to find the next drug (although university scientists do indeed compete with each other, too). On the other hand, we would no longer be indirectly paying for advertising (and other business-specific expenses). So, unless independent scientific research is horribly inefficient compared to industrial research (which I doubt), then it makes more sense to fund them directly.
It's an expensive offence to commit Interesting. I had the opposite reaction.
A £600 fine? That's nothing! Think about the probability of being caught. If you look at the number of users on a typical torrent site (tens of thousands for a popular file), and the number of torrent sites (dozens)... and then compare that to the number of cases actually being brought against suspected infringers... Well, the probability of being accused is quite low.
That low probability multiplied by a ~$1,000 fine is, really, not much (certainly much less than actually buying the game for the retail price). So the expectation cost for illegally downloading it is lower than the expectation cost for buying it from a store. And most people could pay off a fine that like quite quickly (I'm not saying they would be happy about it, but it wouldn't ruin them).
The scarier stuff are things like the $220,000 fine the RIAA managed to get. Court fees and fines like that (multiple infringements at $9000 each) can indeed ruin a person's life. But if copyright infringement were just treated as a minor infraction with a capped fine (like how speeding is), then it really wouldn't be dangerous to infringe.
(No doubt that's one of the reasons that most people do violate copyright at some point or other; the enforcement is, in reality, so sporadic that there's almost no chance of getting caught.)
To be fair, this particular sequence of events could have happened to a proprietary product as well. The article explains that an add-on developer uploaded a new version of the language pack. The language pack was automatically scanned for viruses, and found to be clean (since the signature for this particular Trojan wasn't yet known). It appears that this occurred because the developer's computer was infected (i.e.: this was accidental, not intentional, on the part of the contributor).
This isn't too different from a hypothetical employee whose home computer is infected, and who is working from home and emails a module to his boss, who merges it into the final product. If his home computer was infected, and the standard virus scans missed it, then the final product could end up having Trojan code buried inside.
Would the company necessarily have caught the Trojan? Doubtful. They, too, would probably not have done a line-by-line review of each module update that is submitted.
So I'm not convinced this can be pointed to as a failing of the OSS development model per se. The only difference is that the OSS user contributor is perhaps less well-known (less trustworthy?) to the distributors than in a corporate setting. (But, again, this wasn't a problem of trust... this was a contributor machine being infected. And I assure you that corporate developers can and do get their machines infected.)
Nevertheless, this points to a breakdown in Mozilla's auditing practices. They should be very careful with any code they distribute. But these kinds of quality-control breakdowns occur in OSS projects and corporations, too. (One could tangentially argue that at least with OSS, breaches are likely to be publicized, whereas companies will frequently try to suppress information that points out a security breach.)
And, for anyone interested (and who has a subscription), here's the article in Physical Review E that describes the scientific experiment and analysis of the recovered data:
Robert F. Berg, Michael R. Moldover, Minwu Yao, Gregory A. Zimmerli Shear thinning near the critical point of xenon, Phys. Rev. E 77, 041116 (2008) doi 10.1103/PhysRevE.77.041116.
In the article, they mention a bit about the data recovery:
During the mission, the apparatus recorded 370 h of data, of which 85% were downlinked for real-time analysis. Fortunately, the hard disk drive was recovered from Columbia's debris in a condition that made 99% of the data available for analysis. Also quite interesting is an off-hand comment they make about the sample cell they used:
Seven months after the Columbia disaster in 2003, the meniscus height was remeasured in the recovered sample cell... This suggests that in addition to getting the hard drive (and the data off the hard drive), the Columbia debris search also found the sample cell for their experiment, which allowed them to make some additional measurements for their data analysis. This is also quite impressive!
The data-recovery aspect is quite interesting. So is the fundamental science. They had to run the experiment in micro-gravity to eliminate the density stratification that occurs for any liquid or gas subject to gravity. Shear thinning is a well-established and fairly well-understood phenomena in "complex fluids" (e.g. mixtures of solvents and polymers, like paints, lubricants, etc.); but it is quite interesting to have measured the effect in a pure one-component atomic gas. It's hard to imagine a simpler fluid, and yet it exhibits this interesting viscosity effect!
I'm glad that this scientific experiment was salvaged from the otherwise tragic final mission of Challenger.
But that's just it... For the same reason that paid registrations are not common, all of his proposed authentication schemes won't become common. Registration is onerous and invasive. At a minimum, it's a hassle to have to provide information. Worse, you have to pay a price, whether it's with dollars or personal details (which, as we all know, have great value to companies). Even people who are not privacy nuts dislike having to give out their name and email address just to view some online content or post a comment.
So what will happen? Sites are welcome to create more complex authentication and registration schemes... but as long as other sites don't have such schemes, online participants will naturally gravitate to the sites that have the lowest barriers to entry. So the successful sites will be those that make it very easy to participate.
Of course, we already see this online. Wikipedia and Slashdot are two examples of sites that don't try to prevent anonymous contributions... instead they rely on community self-policing to filter the useful contributions from the trolls. Ultimately, that's the solution: it keeps the barrier to participation low (so you can build up a thriving community), and the mechanism of burying crappy contributions inherently highlights better contributions.
The reason that many sites don't like this answer is that it is hard to generate a useful community (for one thing, you can't treat your users as merely cattle to squeeze money out of--you have to actually build value to keep them visiting your site).
So you not only believe:
1. Sun (a corporation) makes decisions not based on what will bring in the most revenue, but based on what "fanatics" want;
You also apparently believe:
2. The Slashdot crowd has the ability to shape corporate policies to their whims.
I think a reality check is in order.
Sun/MySQL were considering a variety of licenses (including closed source ones). To the extent that comments made on Slashdot (and other online sources) made sense, they were probably taken into account. However, the final decision was undoubtedly what they thought would maximize profits. Yes, maintaining community good-will is probably part of their strategy, since it gives them free advertising (evangelism, etc.) and some free development (patch submissions, etc.).
Frankly I don't see how this isn't a victory for both open-source and MySQL. The community gets open-source code, MySQL gets development and exposure. Win-win.
I agree with you that people (especially politicians) should be allowed to change their minds, to say "I was wrong--with new data and experience, this is what I now believe." However you still must present a consistent view, and not be hypocritical. Some examples of consistent viewpoints would be:
1. I engaged in copyright infringement as a teenager. I now understand that copyright infringement is a terrible thing, and should be punished severely. I should have been punished severely as a teenager, and I will work to make sure that everyone is punished severely for copyright infringement.
2. I engaged in copyright infringement as a teenager. I now understand that copyright infringement is detrimental overall. We as a society should find ways to encourage citizens to respect copyright. However, we all understand that teenagers sometimes do ill-conceived things, so the law should not be overly harsh in dealing with these transgressions. I will work to make sure that copyright law is enforced, without its penalties being unfairly large.
3. I engaged in copyright infringement as a teenager. I now understand that copyright is a bad law, and should be radically altered. I was morally right to ignore copyright as a teenager, and I will work to change the law so that everyone can legally engage in those activities.
Any of those viewpoints is consistent (though I only agree with one of them). The problem is when politicians try to have it both ways. In this case, it seems like he wants to pass it off as some sort of small youthful indiscretion. That's fine--so long as you use your political power to make sure that others enjoy the same implicit forgiveness that you are claiming for yourself.
It would be the height of hypocrisy to claim that this youthful indiscretion was no big deal, but then vote in favor of laws making copyright law stricter (or indeed standing by and allowing other indiscreet youths to be slapped with massive penalties when you were not).
(Sidenote: For some people, #1 would only be consistent with the additional "...and I submit myself for the appropriate harsh punishment at this time." Whether or not there should be a statute of limitations on moral high-ground issues is unclear to me (e.g. a youth who is sued may still be paying off the debt 20 years later... so why shouldn't a 20-year old crime be punished?).)
Of course, in this case you have to balance the confusion stemming from the Tera in IT context meaning 1024 in some cases. It's worse than that. According to SI prefixes, "Tera" should mean 10^12 (1,000,000,000,000), but in common usage applied to computers it sometimes means 2^40 (1,099,511,627,776). But it also sometimes means "1024 Giga", where the Giga could be using either convention (and, for all you know, the "Mega" implied within could have been computed using either convention). So you can get a gradient of "mixed numbers" that conform to neither standard. You might say that only a non-professional would make such a stupid mistake... but on the other hand, if you see a column of numbers listed in "Gigabytes" and you want to convert them to Terabytes, what conversion factor would you use? How would you know what conversion factor the previous author had used? How could you guarantee that you were doing it right? Would you be able to confidently convert it into an exact number of bytes?
Personally, I think the whole thing is a mess, and computer professionals should be working harder to enforce a consistent scheme. Unfortunately, only a minority of computer professionals seem interested in changing the status quo confusion.
Maybe a linguist can pitch in to explain why tebibyte sounds so awful? I'm no linguist, but I don't think "Tebibyte" sounding silly is the real problem. I admit that I laughed when I first heard the binary prefixes. They sound lame. But who cares? "Quark" was silly when it was first coined. So was "Yahoo" and "Google" and "Linux" and "WYSIWYG" and "SCSI" and "Drupal" and so on... Silly names become second-nature once they are used enough.
I think the real problem is that people, inherently, are loathe to change. They are more apt to come up with rationalizations and justifications for doing things "the old way" rather than put in the work to learn (and code!) a new system. Sorry if this sounds harsh, but I find the people who say the binary prefixes "sound dumb" or say that "the current (inconsistent)* system works fine" are just coming up with excuses to avoid doing the work to use a properly consistent standard/notation.
Maybe you're right, and that if the new prefixes had sounded "cooler", then adoption would have been faster... but I'm not so sure. Even if true, it doesn't absolve any of us for allowing the confusion to persist: cool or not, we (geeks especially!) should have the discipline to use proper standards.
* The current system can be roughly described as: SI prefixes are powers of 10 everywhere except in computer science, when they become powers of 2. But only when referring to memory, and some data structure sizes, but not when referring to transmission rates or disk space (unless it's a flash drive, sometimes), and other kinds of data structures.
It's worth noting that the article is talking specifically about prototyping, not necessarily full game development. They do acknowledge that once a good idea is found, it will take some time to give it the polish and variation that people expect from a full game.
So, I wouldn't think of this as any developer's full-time job. Rather, they are describing a strategy for coming up with novel game mechanics, game genres, game elements, etc. Maybe in-between big projects, you give your designers/developers a few weeks of this kind of structured rapid prototyping. At the end, you decide which ideas are not worth pursuing, which ideas could be polished into small games (for release as flash games, as mini-games inside full games, etc.), and which ideas could be expanded upon to create a full, novel game. (E.g. the next "Portal" in terms of novel game-play.)
You're probably right that any developer would burn-out if they tried to churn out a new, novel game every week (they might also eventually become frustrated by never being able to "finish" any project). But as a way to sometimes come up with actually creative game ideas... it definitely has merit.
For that matter, why is an XO $300? The current production cost of an XO is ~188 USD. This is how much they cost as part of the "Give one Get one" program (the other ~$200 was a charitable donation).
Why are these machines so expensive? Just because you can get specs X for $650 doesn't mean you can get specs X/2 for $325. There are all kinds of reasons (size of market, supply and demand, scaling of technology, base costs, etc.)... but the end result is that for most metrics, the "metric per dollar" vs. "cost" graph is non-linear. There is a sweet spot of lowest dollar/performance, with fringe cases (ultra-cheap or ultra-performance) having a price premium.
In the case of these ultra-portables, a significant fraction of the cost also comes from the engineering and components required to make them so small and lightweight. You can of course get a clunky 200MHz laptop for real cheap (old model off eBay, for example), but it will not be as light or slick as the Eee PC or others.
The prices will probably keep dropping. But frankly I'm amazed at how cheap these ultra-portables already are: compare the performance, size, and price to what was available even 5 years ago and see how far we've come!
That's been the trouble with these "peer to peer" protocols. The routing algorithms have been horribly inefficient. It's quite possible to have the same data flowing in both directions on the same pipe. Multiple copies, even. Seems to me that is an artifact of a protocol being designed to operate on a hostile network.
Distribution could be wildly efficient if the users and the network operators were on the "same team." If they wanted to, they could design a bit-torrent variant where chunks are cached by intermediary servers, so that they can always be delivered quickly from a local node. Further, servers could maintain accurate models of network topology, and clients could then use this data to pick the best path. Chunks from popular files would almost always be available from a nearby server cache or a nearby peer.
The problem is that the network is either indifferent to user activities, or actively trying to prevent user activities (throttling, etc.). The end result is that the protocol is tweaked not for efficiency, but for circumvention (e.g. encryption).
I like the idea presented in the summary, since it is in principle a net benefit to both the users and the network operators. However even if it works, it may not last. For instance, ISPs may use even more aggressive tricks (maybe even exploiting this proposed variant), forcing the protocol to become even more inefficient (e.g. switching to a multi-hop TOR-like protocol).
That said, I believe most EU countries, as well as Australia and recently Canada have laws similar to the DMCA. FYI: A DMCA-like law was proposed in Canada, but it was never ratified. Actually, it is being repeatedly tabled, but has always been struck down. For the time being, Canada doesn't have any DMCA-like legal provisions. (Refer to Michael Geist's blog for more information.)
The neutrino interaction is indeed very weak, so they are difficult to detect. A major problem is that the other sources (cosmic rays, ambient radiation) can give false positives.
However the proposal is to place the device rather near to a nuclear reactor. A reactor generates enough flux that big detectors can measure the neutrino flux from miles away. So a small (and probably less shielded) detector that is much closer (<100 m) will receive enough flux to get statistically significant data.
The preprint says:
For example, cubic meter scale hydrogenous scintillator detectors, containing 10^28 target protons Np, will register thousands of interactions per day at standoff distances of 10-50 meters from typical commercial nuclear reactors. The proposal thus requires the detector to be installed on-site at the nuclear reactor. You may wonder "Is this actually useful for monitoring, then? If someone wants to lie about their reactor usage and burn rate, they will just falsify the detector records, too." Well, the idea is that this local detector is completely independent from the reactor (it doesn't rely on sensors hooked into the reactor, for instance). Thus it can be locked and sealed off completely; installed and managed by a completely independent oversight organization.
Drunk driving is not a game, and it is not a joke. True enough. Regular driving is also not a game (in fact, "using a vehicle as a toy" is explicitly illegal in most places). However having a video game involve driving (even reckless driving) isn't a problem, is it?
Drunk driving is a choice, a violent crime and it is also 100 percent preventable. Many forms of entertainment describe crime. Books and movies depict theft, murder, rape, etc. Many video games involve killing or worse. These are all, in real life, choices and preventable crimes. Does that mean that our fiction and entertainment cannot involve these subjects, out of some sort of "respect for the victims"?
Rockstar's response is right on the money: adults should be able to distinguish between entertainment/fantasy/fiction (where murder may be depicted, or drunk driving may be a game) and reality (where these things are illegal and unethical). Adults who cannot make those distinctions are a danger to society (regardless of what video games are on the market).
Thanks alot. I personally didn't think of the connection to "nuisance"... but now that you've pointed it out, I won't be able to stop thinking that everytime I hear it.
Just like when someone pointed out to me what "new direction" sounds like if you say it fast enough.
I hate it. Now everytime I'm in a strategic meeting, and someone says "what the project needs is a new direction", I'm momentarily shocked that they are suggesting nude erections. (Perhaps I've now infected you with this terrible meme-virus.)
It takes the author quite awhile to get to his point about the greater Ubuntu ecosystem being non-free. His point is:
Canonical has introduced a new twist into the Ubuntu business model with the launch of its Landscape systems management and monitoring tool. Basically Landscape is very similar to Red Hat Network. It allows you to track the configurations and status of all your Ubuntu desktops and servers, and to install updates under central control (though with full customization options). And the catch is? This is completely proprietary code. It's not GPL'd, you can't see the source, and you can't get it for free. In fact, you can't even have the binary, because Landscape is provided as an online service only. Only the Landscape client is free and open source, which it has to be of course because it cohabits physically with the kernel on each of your Ubuntu machines. (emphasis added)
So his complaint amounts to: "Sure they give you the source code for all distributed binaries, but they don't give you the source code for a subscription-based online service that they run."
For those of us who believe in software freedom, the question is really "does software freedom extend to web services?" Is providing someone with a web service akin to providing them with a binary? That is, you should give them access to the source code (where I'm using "should" as shorthand for "it's the free software thing to do").
The fact is that this is a point of contention in the community. It was debated considerably during the writing of GPLv3. Both sides have valid points: on the one hand, an online service isn't distributing software to end-users. On the other hand, this may be a "loophole" that allows companies to modify free software, but deny the eventual users of that software the ability to use the changes or further modify the code.
The author was inherently assuming that not providing code for web services was non-free. But really that's an unfinished debate, and he should have pointed out the nuances.
For anyone interested, the fork is called "Funpidgin" and can be found here.
The summary makes light of it, but the Funpidgin page explains that their intention is to respond more directly to the requests of the user community. In addition to the feature mentioned in the summary, Funpidgin has implemented some others, and will presumably continue adding user-requested features (while still integrating upgrades from the pidgin codebase, presumably).
Forks are both good and bad; this one is no exception. On the one hand it "wastes effort" and can duplicate work. On the other hand, it can give the user community (which isn't homogeneous) the product(s) they want. It can encourage useful competition. Often the end result will be better than if no fork had occurred. Another example is the Compiz/Beryl fork, which created some duplication for awhile, but ultimately turned out for the best since the merged Compiz Fusion includes the best features from both (a stable core and all the whiz-bang features users wanted, in the form of plugins).
If both the Pidgin and Funpidgin developers work to provide something that their respective users find worthwhile, then what's the problem?
I would say that a death certificate is a necessary, but by no means sufficient, piece of evidence.
There was recently a death in my extended family. I have seen how, even with a death certificate and all official documents (police reports, etc.), it still took literally years to finalize routine things (closing accounts, transferring assets, dealing with insurance, etc.). So it turns out its quite long and complicated to even just do the "normal" things (that must be done when any person dies, and for which no one was really contesting anything... just following the protocol). So I can only imagine how difficult it will be in situations where things are unclear.
For instance, if you show a death certificate to an email provider, what does that prove? It shows that someone died, but doesn't actually prove that it was the owner of the account that died. (Did he sign up with his real name, or fake details?) I can imagine an email provider requesting certain conditions (like waiting a year to make sure there is no activity on the account, and requiring some proof of connection between the person and the account).
All this to say: prepare for a long and drawn-out ordeal. Finalizing a person's affairs is not a quick matter. (On the other hand, you might end up being lucky, and finding a "passwords.txt" file on his computer somewhere.)
This is quite different from the case where a company loses a lawsuit, but otherwise continues business. The "danger" to ReiserFS isn't merely some loss of reputation or credibility. The real issue here is that founder and head of Namesys Inc. is now in prison. Worse, this person was also the lead technical contributor to the ReiserFS project.
So ReiserFS has lost both its organization head and its technical head. Most companies or projects would find it difficult to recover from that.
Ultimately, the code for ReiserFS is open, so others can continue working on it. But losing a key contributor is a blow to any software project--they possess a great amount of technical insight, which will take newcomers a long time to acquire. Moreover, ReiserFS was implementing many truly unique ideas that require contributors with both talent and vision to really make them happen.
The ReiserFS project has certainly lost a great deal of momentum here. It's not at all clear whether enough other people will step up to keep the project going.
The article several times suggests that the solution to some of these problems is, essentially, user education: having balloons that signal "new item installed" or wizards open the first time you launch a program, telling you how the program works.
The problem is that this approach often doesn't work. For one thing, it annoys the piss out of experience users. For another thing, new users tend to ignore most of that information... mainly because they are being overwhelmed by new information and can't possibly assimilate it all.
Take, for instance, the problem that was encountered when changing screen resolution. The tester changed the resolution easily, but then she clicked the "Keep settings" immediately, which locked her into graphic settings that were hard to change back. Part of the problem, I suppose is that the system allowed the user to make a ridiculous change. But part of the problem is also, perhaps, that the user is very used to clicking "OK" on any dialog that gets in the way: there are too many new things to read and learn, and the easiest way to get things done (in the mind of a new user) is to dismiss those annoying boxes as quickly as possible. Would a second popup, that described in detail why this low resolution was a bad idea (and how to undo it when desired), have changed anything? Doubtful. Most users would just click "OK" without reading it.
All this to say that I'm by no means convinced that adding more balloons, wizards, and dialog boxes will magically make it easier for users to figure out what's going on. I don't know what the solution is: usability is a tough problem. There is a place for helpful information (balloons, tool-tips, etc.), reminders, and wizards. But too much of this becomes decidedly counter-productive.
Slashdot Mirror
I disagree. Even if it's for your own reference, a database is (in my opinion) worth it.
For one thing, the structure of a database encourages you to stay organized in a way that a delimited text file doesn't (e.g. enforcing strict type rules for columns).
Perhaps more importantly, using a (well-established) database system means that you can all kinds of add-ons, extensions, and useful tricks 'for free'. Data is becomes more useful the more you're able to interact with it (by which I mean add/manage data, query data, visualize data, etc.). By using a database, you immediately have access to a whole slew of software. For example you will not only be limited to querying the data in your own code, but can also organize it using a GUI management/query tool, or a web-browser, or interface with your favorite spreadsheet, etc. (Obviously you can do all this with a "roll-your-own" approach, but it will take you much longer and probably won't be as elegant/robust/scaleable).
In short, I've found that even for relatively small datasets, having things in a proper database can be amazingly powerful. It causes me to analyze and extract insight from the data in ways that I wouldn't have otherwise. I also love the power of command-line text processing... but for database-like information (multi-column, etc.), in my experience you should get it into a database. From the sound of the original post, it sounds like the submitter has indeed hit the level where he would extract more value from having a database.
Getting on the cover of Wired is more of a significant marketing achievement.
More seriously, if this is actually a scientific advance, then it would be published in peer-reviewed journals, scrutinized by the community, and (if worthy) built upon by others. It isn't really science if you keep the secrets of your techniques locked up, and don't allow others to see/understand what you're doing. And it's certainly not a "significant achievement" if all you're doing is using the same techniques that are well-established in the field. Grandiose claims of novelty need correspondingly rigorous evidence.
In addition to the applications you mentioned (medicine and security), a more mundane application is in manufacturing and quality control. For instance, with these scanners you can automate the quality and consistency checks on many manufactured goods, including foods. For instance, the scans could visualize the internal dispersion of nuts in a candy bar, or the consistency of bread. It could also be very useful for detecting anomalous matter in food (e.g. pick out metal or a band-aid that accidentally found its way into the food), or detecting insects and larvae inside fruits and vegetables.
The scans are totally benign and non-ionizing, so there's no health risks associated with scanning food.
You actually missed one of the wiki* in this conflict. In particular, Wikileaks is reporting that the Wikimedia Foundation is suppressing a news item on Wikinews about Wikipedia.
It's also worth noting that all of the above sites are managed using the MediaWiki software.
You're absolutely correct that it takes a ton of research (and hence a ton of money) to find those few successful drugs that work.
The question remains: is the most sensible way to pay for all that research to hide the cost in successful drugs? Is giving out temporary monopolies on the sale of drugs really the most efficient (and ethical) way to it?
On the surface of it, something feels "wrong" about having the price of drugs be so uncorrelated to their manufacturing cost. Digging deeper, it is surely bothersome that the prices we are charged for drugs may be well above what is needed to pay for all the research. (For instance, approximately half of that money goes into advertising.) Deeper still, and it seems wholly unethical to charge people so much for things they need to save their lives.
What are the alternatives? Well, we could just fund scientists to do the research and release the results for anyone to use. (Companies would then compete only on who can manufacture the drugs to specification at the best price.) In fact, a large amount of medical research is already performed outside of industry. I don't see why we couldn't divert the current money put towards buying expensive drugs, and put it towards directly funding the research instead.
True, we lose the free market competition of having pharmaceutical companies competing with each other to find the next drug (although university scientists do indeed compete with each other, too). On the other hand, we would no longer be indirectly paying for advertising (and other business-specific expenses). So, unless independent scientific research is horribly inefficient compared to industrial research (which I doubt), then it makes more sense to fund them directly.
A £600 fine? That's nothing! Think about the probability of being caught. If you look at the number of users on a typical torrent site (tens of thousands for a popular file), and the number of torrent sites (dozens)... and then compare that to the number of cases actually being brought against suspected infringers... Well, the probability of being accused is quite low.
That low probability multiplied by a ~$1,000 fine is, really, not much (certainly much less than actually buying the game for the retail price). So the expectation cost for illegally downloading it is lower than the expectation cost for buying it from a store. And most people could pay off a fine that like quite quickly (I'm not saying they would be happy about it, but it wouldn't ruin them).
The scarier stuff are things like the $220,000 fine the RIAA managed to get. Court fees and fines like that (multiple infringements at $9000 each) can indeed ruin a person's life. But if copyright infringement were just treated as a minor infraction with a capped fine (like how speeding is), then it really wouldn't be dangerous to infringe.
(No doubt that's one of the reasons that most people do violate copyright at some point or other; the enforcement is, in reality, so sporadic that there's almost no chance of getting caught.)
To be fair, this particular sequence of events could have happened to a proprietary product as well. The article explains that an add-on developer uploaded a new version of the language pack. The language pack was automatically scanned for viruses, and found to be clean (since the signature for this particular Trojan wasn't yet known). It appears that this occurred because the developer's computer was infected (i.e.: this was accidental, not intentional, on the part of the contributor).
This isn't too different from a hypothetical employee whose home computer is infected, and who is working from home and emails a module to his boss, who merges it into the final product. If his home computer was infected, and the standard virus scans missed it, then the final product could end up having Trojan code buried inside.
Would the company necessarily have caught the Trojan? Doubtful. They, too, would probably not have done a line-by-line review of each module update that is submitted.
So I'm not convinced this can be pointed to as a failing of the OSS development model per se. The only difference is that the OSS user contributor is perhaps less well-known (less trustworthy?) to the distributors than in a corporate setting. (But, again, this wasn't a problem of trust... this was a contributor machine being infected. And I assure you that corporate developers can and do get their machines infected.)
Nevertheless, this points to a breakdown in Mozilla's auditing practices. They should be very careful with any code they distribute. But these kinds of quality-control breakdowns occur in OSS projects and corporations, too. (One could tangentially argue that at least with OSS, breaches are likely to be publicized, whereas companies will frequently try to suppress information that points out a security breach.)
Robert F. Berg, Michael R. Moldover, Minwu Yao, Gregory A. Zimmerli Shear thinning near the critical point of xenon, Phys. Rev. E 77, 041116 (2008) doi 10.1103/PhysRevE.77.041116.
In the article, they mention a bit about the data recovery: During the mission, the apparatus recorded 370 h of data, of which 85% were downlinked for real-time analysis. Fortunately, the hard disk drive was recovered from Columbia's debris in a condition that made 99% of the data available for analysis. Also quite interesting is an off-hand comment they make about the sample cell they used: Seven months after the Columbia disaster in 2003, the meniscus height was remeasured in the recovered sample cell... This suggests that in addition to getting the hard drive (and the data off the hard drive), the Columbia debris search also found the sample cell for their experiment, which allowed them to make some additional measurements for their data analysis. This is also quite impressive!
The data-recovery aspect is quite interesting. So is the fundamental science. They had to run the experiment in micro-gravity to eliminate the density stratification that occurs for any liquid or gas subject to gravity. Shear thinning is a well-established and fairly well-understood phenomena in "complex fluids" (e.g. mixtures of solvents and polymers, like paints, lubricants, etc.); but it is quite interesting to have measured the effect in a pure one-component atomic gas. It's hard to imagine a simpler fluid, and yet it exhibits this interesting viscosity effect!
I'm glad that this scientific experiment was salvaged from the otherwise tragic final mission of Challenger.
But that's just it... For the same reason that paid registrations are not common, all of his proposed authentication schemes won't become common. Registration is onerous and invasive. At a minimum, it's a hassle to have to provide information. Worse, you have to pay a price, whether it's with dollars or personal details (which, as we all know, have great value to companies). Even people who are not privacy nuts dislike having to give out their name and email address just to view some online content or post a comment.
So what will happen? Sites are welcome to create more complex authentication and registration schemes... but as long as other sites don't have such schemes, online participants will naturally gravitate to the sites that have the lowest barriers to entry. So the successful sites will be those that make it very easy to participate.
Of course, we already see this online. Wikipedia and Slashdot are two examples of sites that don't try to prevent anonymous contributions... instead they rely on community self-policing to filter the useful contributions from the trolls. Ultimately, that's the solution: it keeps the barrier to participation low (so you can build up a thriving community), and the mechanism of burying crappy contributions inherently highlights better contributions.
The reason that many sites don't like this answer is that it is hard to generate a useful community (for one thing, you can't treat your users as merely cattle to squeeze money out of--you have to actually build value to keep them visiting your site).
What?
So you not only believe:
1. Sun (a corporation) makes decisions not based on what will bring in the most revenue, but based on what "fanatics" want;
You also apparently believe:
2. The Slashdot crowd has the ability to shape corporate policies to their whims.
I think a reality check is in order.
Sun/MySQL were considering a variety of licenses (including closed source ones). To the extent that comments made on Slashdot (and other online sources) made sense, they were probably taken into account. However, the final decision was undoubtedly what they thought would maximize profits. Yes, maintaining community good-will is probably part of their strategy, since it gives them free advertising (evangelism, etc.) and some free development (patch submissions, etc.).
Frankly I don't see how this isn't a victory for both open-source and MySQL. The community gets open-source code, MySQL gets development and exposure. Win-win.
I agree with you that people (especially politicians) should be allowed to change their minds, to say "I was wrong--with new data and experience, this is what I now believe." However you still must present a consistent view, and not be hypocritical. Some examples of consistent viewpoints would be:
1. I engaged in copyright infringement as a teenager. I now understand that copyright infringement is a terrible thing, and should be punished severely. I should have been punished severely as a teenager, and I will work to make sure that everyone is punished severely for copyright infringement.
2. I engaged in copyright infringement as a teenager. I now understand that copyright infringement is detrimental overall. We as a society should find ways to encourage citizens to respect copyright. However, we all understand that teenagers sometimes do ill-conceived things, so the law should not be overly harsh in dealing with these transgressions. I will work to make sure that copyright law is enforced, without its penalties being unfairly large.
3. I engaged in copyright infringement as a teenager. I now understand that copyright is a bad law, and should be radically altered. I was morally right to ignore copyright as a teenager, and I will work to change the law so that everyone can legally engage in those activities.
Any of those viewpoints is consistent (though I only agree with one of them). The problem is when politicians try to have it both ways. In this case, it seems like he wants to pass it off as some sort of small youthful indiscretion. That's fine--so long as you use your political power to make sure that others enjoy the same implicit forgiveness that you are claiming for yourself.
It would be the height of hypocrisy to claim that this youthful indiscretion was no big deal, but then vote in favor of laws making copyright law stricter (or indeed standing by and allowing other indiscreet youths to be slapped with massive penalties when you were not).
(Sidenote: For some people, #1 would only be consistent with the additional "...and I submit myself for the appropriate harsh punishment at this time." Whether or not there should be a statute of limitations on moral high-ground issues is unclear to me (e.g. a youth who is sued may still be paying off the debt 20 years later... so why shouldn't a 20-year old crime be punished?).)
Personally, I think the whole thing is a mess, and computer professionals should be working harder to enforce a consistent scheme. Unfortunately, only a minority of computer professionals seem interested in changing the status quo confusion. Maybe a linguist can pitch in to explain why tebibyte sounds so awful? I'm no linguist, but I don't think "Tebibyte" sounding silly is the real problem. I admit that I laughed when I first heard the binary prefixes. They sound lame. But who cares? "Quark" was silly when it was first coined. So was "Yahoo" and "Google" and "Linux" and "WYSIWYG" and "SCSI" and "Drupal" and so on... Silly names become second-nature once they are used enough.
I think the real problem is that people, inherently, are loathe to change. They are more apt to come up with rationalizations and justifications for doing things "the old way" rather than put in the work to learn (and code!) a new system. Sorry if this sounds harsh, but I find the people who say the binary prefixes "sound dumb" or say that "the current (inconsistent)* system works fine" are just coming up with excuses to avoid doing the work to use a properly consistent standard/notation.
Maybe you're right, and that if the new prefixes had sounded "cooler", then adoption would have been faster... but I'm not so sure. Even if true, it doesn't absolve any of us for allowing the confusion to persist: cool or not, we (geeks especially!) should have the discipline to use proper standards.
* The current system can be roughly described as: SI prefixes are powers of 10 everywhere except in computer science, when they become powers of 2. But only when referring to memory, and some data structure sizes, but not when referring to transmission rates or disk space (unless it's a flash drive, sometimes), and other kinds of data structures.
It's worth noting that the article is talking specifically about prototyping, not necessarily full game development. They do acknowledge that once a good idea is found, it will take some time to give it the polish and variation that people expect from a full game.
So, I wouldn't think of this as any developer's full-time job. Rather, they are describing a strategy for coming up with novel game mechanics, game genres, game elements, etc. Maybe in-between big projects, you give your designers/developers a few weeks of this kind of structured rapid prototyping. At the end, you decide which ideas are not worth pursuing, which ideas could be polished into small games (for release as flash games, as mini-games inside full games, etc.), and which ideas could be expanded upon to create a full, novel game. (E.g. the next "Portal" in terms of novel game-play.)
You're probably right that any developer would burn-out if they tried to churn out a new, novel game every week (they might also eventually become frustrated by never being able to "finish" any project). But as a way to sometimes come up with actually creative game ideas... it definitely has merit.
Why are these machines so expensive? Just because you can get specs X for $650 doesn't mean you can get specs X/2 for $325. There are all kinds of reasons (size of market, supply and demand, scaling of technology, base costs, etc.)... but the end result is that for most metrics, the "metric per dollar" vs. "cost" graph is non-linear. There is a sweet spot of lowest dollar/performance, with fringe cases (ultra-cheap or ultra-performance) having a price premium.
In the case of these ultra-portables, a significant fraction of the cost also comes from the engineering and components required to make them so small and lightweight. You can of course get a clunky 200MHz laptop for real cheap (old model off eBay, for example), but it will not be as light or slick as the Eee PC or others.
The prices will probably keep dropping. But frankly I'm amazed at how cheap these ultra-portables already are: compare the performance, size, and price to what was available even 5 years ago and see how far we've come!
Distribution could be wildly efficient if the users and the network operators were on the "same team." If they wanted to, they could design a bit-torrent variant where chunks are cached by intermediary servers, so that they can always be delivered quickly from a local node. Further, servers could maintain accurate models of network topology, and clients could then use this data to pick the best path. Chunks from popular files would almost always be available from a nearby server cache or a nearby peer.
The problem is that the network is either indifferent to user activities, or actively trying to prevent user activities (throttling, etc.). The end result is that the protocol is tweaked not for efficiency, but for circumvention (e.g. encryption).
I like the idea presented in the summary, since it is in principle a net benefit to both the users and the network operators. However even if it works, it may not last. For instance, ISPs may use even more aggressive tricks (maybe even exploiting this proposed variant), forcing the protocol to become even more inefficient (e.g. switching to a multi-hop TOR-like protocol).
I prefer this analogy:
"Microsoft is demonstrably the best OS in the same way that McDonald's ubiquity makes it demonstrably the best restaurant."
Popularity is a poor metric of quality.
However the proposal is to place the device rather near to a nuclear reactor. A reactor generates enough flux that big detectors can measure the neutrino flux from miles away. So a small (and probably less shielded) detector that is much closer (<100 m) will receive enough flux to get statistically significant data.
The preprint says: For example, cubic meter scale hydrogenous scintillator detectors, containing 10^28 target protons Np, will register thousands of interactions per day at standoff distances of 10-50 meters from typical commercial nuclear reactors. The proposal thus requires the detector to be installed on-site at the nuclear reactor. You may wonder "Is this actually useful for monitoring, then? If someone wants to lie about their reactor usage and burn rate, they will just falsify the detector records, too." Well, the idea is that this local detector is completely independent from the reactor (it doesn't rely on sensors hooked into the reactor, for instance). Thus it can be locked and sealed off completely; installed and managed by a completely independent oversight organization.
Rockstar's response is right on the money: adults should be able to distinguish between entertainment/fantasy/fiction (where murder may be depicted, or drunk driving may be a game) and reality (where these things are illegal and unethical). Adults who cannot make those distinctions are a danger to society (regardless of what video games are on the market).
Thanks alot. I personally didn't think of the connection to "nuisance" ... but now that you've pointed it out, I won't be able to stop thinking that everytime I hear it.
Just like when someone pointed out to me what "new direction" sounds like if you say it fast enough.
I hate it. Now everytime I'm in a strategic meeting, and someone says "what the project needs is a new direction", I'm momentarily shocked that they are suggesting nude erections. (Perhaps I've now infected you with this terrible meme-virus.)
So his complaint amounts to: "Sure they give you the source code for all distributed binaries, but they don't give you the source code for a subscription-based online service that they run."
For those of us who believe in software freedom, the question is really "does software freedom extend to web services?" Is providing someone with a web service akin to providing them with a binary? That is, you should give them access to the source code (where I'm using "should" as shorthand for "it's the free software thing to do").
The fact is that this is a point of contention in the community. It was debated considerably during the writing of GPLv3. Both sides have valid points: on the one hand, an online service isn't distributing software to end-users. On the other hand, this may be a "loophole" that allows companies to modify free software, but deny the eventual users of that software the ability to use the changes or further modify the code.
The author was inherently assuming that not providing code for web services was non-free. But really that's an unfinished debate, and he should have pointed out the nuances.
For anyone interested, the fork is called "Funpidgin" and can be found here.
The summary makes light of it, but the Funpidgin page explains that their intention is to respond more directly to the requests of the user community. In addition to the feature mentioned in the summary, Funpidgin has implemented some others, and will presumably continue adding user-requested features (while still integrating upgrades from the pidgin codebase, presumably).
Forks are both good and bad; this one is no exception. On the one hand it "wastes effort" and can duplicate work. On the other hand, it can give the user community (which isn't homogeneous) the product(s) they want. It can encourage useful competition. Often the end result will be better than if no fork had occurred. Another example is the Compiz/Beryl fork, which created some duplication for awhile, but ultimately turned out for the best since the merged Compiz Fusion includes the best features from both (a stable core and all the whiz-bang features users wanted, in the form of plugins).
If both the Pidgin and Funpidgin developers work to provide something that their respective users find worthwhile, then what's the problem?
My condolences to the family.
I would say that a death certificate is a necessary, but by no means sufficient, piece of evidence.
There was recently a death in my extended family. I have seen how, even with a death certificate and all official documents (police reports, etc.), it still took literally years to finalize routine things (closing accounts, transferring assets, dealing with insurance, etc.). So it turns out its quite long and complicated to even just do the "normal" things (that must be done when any person dies, and for which no one was really contesting anything... just following the protocol). So I can only imagine how difficult it will be in situations where things are unclear.
For instance, if you show a death certificate to an email provider, what does that prove? It shows that someone died, but doesn't actually prove that it was the owner of the account that died. (Did he sign up with his real name, or fake details?) I can imagine an email provider requesting certain conditions (like waiting a year to make sure there is no activity on the account, and requiring some proof of connection between the person and the account).
All this to say: prepare for a long and drawn-out ordeal. Finalizing a person's affairs is not a quick matter. (On the other hand, you might end up being lucky, and finding a "passwords.txt" file on his computer somewhere.)
This is quite different from the case where a company loses a lawsuit, but otherwise continues business. The "danger" to ReiserFS isn't merely some loss of reputation or credibility. The real issue here is that founder and head of Namesys Inc. is now in prison. Worse, this person was also the lead technical contributor to the ReiserFS project.
So ReiserFS has lost both its organization head and its technical head. Most companies or projects would find it difficult to recover from that.
Ultimately, the code for ReiserFS is open, so others can continue working on it. But losing a key contributor is a blow to any software project--they possess a great amount of technical insight, which will take newcomers a long time to acquire. Moreover, ReiserFS was implementing many truly unique ideas that require contributors with both talent and vision to really make them happen.
The ReiserFS project has certainly lost a great deal of momentum here. It's not at all clear whether enough other people will step up to keep the project going.
The article several times suggests that the solution to some of these problems is, essentially, user education: having balloons that signal "new item installed" or wizards open the first time you launch a program, telling you how the program works.
The problem is that this approach often doesn't work. For one thing, it annoys the piss out of experience users. For another thing, new users tend to ignore most of that information... mainly because they are being overwhelmed by new information and can't possibly assimilate it all.
Take, for instance, the problem that was encountered when changing screen resolution. The tester changed the resolution easily, but then she clicked the "Keep settings" immediately, which locked her into graphic settings that were hard to change back. Part of the problem, I suppose is that the system allowed the user to make a ridiculous change. But part of the problem is also, perhaps, that the user is very used to clicking "OK" on any dialog that gets in the way: there are too many new things to read and learn, and the easiest way to get things done (in the mind of a new user) is to dismiss those annoying boxes as quickly as possible. Would a second popup, that described in detail why this low resolution was a bad idea (and how to undo it when desired), have changed anything? Doubtful. Most users would just click "OK" without reading it.
All this to say that I'm by no means convinced that adding more balloons, wizards, and dialog boxes will magically make it easier for users to figure out what's going on. I don't know what the solution is: usability is a tough problem. There is a place for helpful information (balloons, tool-tips, etc.), reminders, and wizards. But too much of this becomes decidedly counter-productive.