You can't possibly put icons for everything on the desktop - you'd need a 50" screen.
Which reminds me: In the cases where I do want to put an icon on the desktop, what are the available non-GIMP tools that can create or edit icons and other such silly little images? I've tried to do this with GIMP, but about all I succeeded in doing was destroying the icons I had. (Good thing I made backup copies of them first.;-) Maybe someday I'll learn to use GIMP, if I ever find a novice-friendly intro doc. But meanwhile, something not so powerful could be very useful.
Back in the 1990s, there were a number of small, specialized apps for tweaking such little image files (such as bitmap). Some of them even did color (unlike bitmap). I don't seem to find them on any of the linux boxes that I have access to. Yeah; I know about google, and in fact have a reply from it in another window. But this seems on-topic here, and it's likely that some readers with expertise in the topic are perusing this discussion. So if you have a favorite icon editor, even if it's capable of doing more sophisticated stuff, how about telling us about why you like it?
Don't get me wrong. If you know what you're doing and you have the time and patience to get through it, you can do some pretty cool stuff with Drupal. That said, if the only CMS you've ever touched in your life was something like Wordpress, you're in for a rough ride.
Yeah; that's the impression I got, which was why I spent some time (and money;-) trying to learn to use it. I may have to put it off a while longer, since I've been having a lot of success just building my own stuff. But the main problems with drupal are a lot more basic than trying to figure out which modules to use. I'm nowhere near even looking at modules. Thus, a major brick wall has been when I get to the point in several docs saying to use the login page (or node). I've had no success at finding it. I even asked on a drupal forum, and got some interesting replies, but nobody answered the very basic question: How to I get to the login node? I've gotten to dozens of other nodes, but the only instance of "log" in any of them is one that has a link called "Logout".
A funny part of this is that of course I googled "drupal login", including with a few other likely keywords. I got zillions of hits, apparently all of the form "... after you login to drupal...". But if google knows of a page that says how to do this, its page rank isn't high enough to get within the first 100 or so hits that I looked at with any of the keywords that I guessed.
This worries me, actually, The fact that I'm not invited to log in, but I am invited to log out implies that I am in fact already logged in. I'm pretty sure I didn't ever do this. Although I created a couple of new login ids (or at least I think I did), I have never typed those ids or their passwords to anything recognizable as a login procedure. That single "Logout" links tells me that my machine probably has some account logged in permanently, most likely an admin account (since I was allowed to create new logins). I spent some time looking for clues that would verify that this is true or false, but couldn't find anything that I recognized as telling me who I was logged in as. Presumably anyone who knows the default login name and can connect to my machine will have free run of my drupal installation, and I won't have a clue that they're doing anything.
So until I decide I have enough free time to dig into it again, perhaps I should hunt down everything I can find that's associated with drupal and delete it. OTOH, I'm not confidant I could even do that. If drupal installed something that doesn't have "drupal" anywhere in its name or contents, I probably wouldn't identify it for what it is.
I was careful to install it on a "test" machine that's hidden behind a firewall. But I'm using it for testing a lot of other stuff, so I'm not sure I want to refomat the disk and do a clean install, just to get rid of drupal. And it took long enough to install that I'm tempted to just keep it around until I have the time again. If only I could verify its logged-in state...
In a previous job we got rid of a proprietary system because we moved to a new one. No one thought about all the old records during this transaction. Well, we had access the the DB, but it was coded in such a way that the fields were a jumble of crap and would have taken forever to pull apart to get the records. I asked the proprietary company if they had a way to dump the records to PDF for easy reading and storage. Nope... This company was in business for 7+ years and they had no way to mass export records?
Of course. The vendors do that all the time, to lock customers into their products. It's no accident at all.
I've worked on several projects like this. Cracking the data using printouts (billing, customer notices, etc.) messy, ad-hoc coding. But if a company wants to pay the sort of hackers who know how to do it (naming no names;-), you can usually get almost all the data out this way.
One funny thing I've found is that after a short time, the DB experts - even the ones being paid by IBM or Microsoft - are usually rather friendly, and cooperate in finding ways to get the data out in some readable format. I think it's because people who work a lot at customer sites end up being very sympathetic with the customers' problems, and don't have a lot of respect for the tricks their employers have used against the customers. But that's just my experience; others may have found a lot less cooperation.
I've usually felt relief when those jobs became "previous jobs".;-)
There's only one you, and you inherited the code used to make you.
It belongs to you and only you. And your maternal twin.
Heh. I'll assume you meant fraternal twin.
A few years ago, I read a interesting article (which I probably can't find any more) that among other things calculated the probability that there were pairs of "unrelated" humans with identical DNA. From what was known of DNA variability in humans, they calculated that there were between roughly 100,000 and 1,000,000 such pairs of "pseudo-twins" in the world, born to different parents but having identical DNA.
If we could find them, they would usually turn out to be distant relatives, of course, with common grandparents N times removed. At least their ancestors would probably come from the same part(s) of the world. But in many cases, the common ancestors would be so remote that they couldn't be determined from existing birth records.
Even more years ago, I remember reading a novel in which two of the characters were "anti-twins", born from the same parents, but with no shared chromosomes. The probability of this is a lot higher than the above number. I'll leave the calculation as an exercise for the reader.;-)
sell the customer data to some health insurance company.
Sell it to researchers, since insurance company wouldnt benefit much from such a small set of DNA samples.
You're probably both right.
As many armchair econ theorists here have been pointing out repeatedly, the attempted purchaser is an American corporation. As such, their primary (and according to some, only) obligation is to the bank accounts of their officers and shareholders. If there's a commercial value to the information, they likely consider it immoral to not sell the information for whatever price the market will bear.
The fact that mere "citizens" might be upset by this only means that they'll do this quietly, with no public notice and no records of the sales available to outsiders. If we learn of the sales, it'll be far too late for us to do anything about it.
Expecting anything else is simply naive. We should be assuming that, if anyone has had the opportunity to collect a sample of our DNA, they have done so, and the information is in the databases of anyone willing to pay the asking price. This especially applies if you have ever had any dealings with a private, for-profit medical organization.
(Point is: Do we need more social networking sites? Why would I start my own...)
Well, I've recently got ahold of several drupal books, and lots of the online docs, and installed on a handy machine. The reason is that I'm involved in a couple of products where we could really use a local social network/news/blog site over which we have full control. Drupal seemed to have lots of rave reviews, so it was a good candidate.
Unfortunately, after several weeks of roughly half-time studying the docs and experimenting with the software, I had to admit that "I just don't get it". I wasn't able to make it do anything useful. This was mostly because I found the docs a morass of new jargon, none of which I understand, mostly written by people who apparently don't understand the concept of a "definition", and think that glowing descriptions are the same thing. A few questions on the drupal forum didn't help much. For example, after all that reading, I have no idea what a "node" is or how to recognize one when I see it; I only have many assurances that it's an important concept. At first I thought it was a kind of file, then I thought it might be like what browser users call a "page", and I had several other guesses, but I had to admit that all were probably wrong.
So I faced the fact that I had to get something working and usable. I collected a mixed bag of more limited tools from elsewhere, started exercising my mad perl skillz, and a few weeks later I have something that impresses the clients enough that they've started using it and burying me under requests for more features.
Now, I can tell by googling that many of those requests could probably be handled by something in drupal. But unless I can find something that will explain to a dummy like me what buttons to hit on my keyboard and/or mouse/touchpad to get something actually working, I don't think I'll be quite as willing to throw away any more resources on it. I'll just write off the money (and time) I spent on the books as a loss.
So is this book useful to a dummy who doesn't yet understand the jargon? Can an experienced programmer with no knowledge of drupal's terminology actually use it to produce something useful? And would that programmer understand the results well enough to be able to tweak it the way a client wants? (That's mostly deep stuff like "Can you put that button on the left and make it a bigger font?";-) Would money spent on the book pay off, or would I still be unable to get anything to work right?
I also have some serious security questions, but I suppose this isn't the place to ask them. And unless I can get the nuts-and-bolts stuff to work, they're not too relevant to anything.
They would be if they we're actively promoting it like The Pirate Bay, or something like setting up a DC++ hub called "All The Warez You Need".
Well, now; it seems to me that I've heard or seen lots and lots of ads from ISPs touting their "blindingly fast download" speeds. We all know what they're talking about here. They're not targeting geeks wanting the latest linux ISOs, y'know. Maybe they don't use words like "copyright" or "infringement", but it's fairly obvious what they're getting at.
Isn't it funny that the ISPs don't get prosecuted for such blatantly obvious enticement?
The real problem here is the use of an atrociously bad metaphor. The term "maintenance" refers to keeping something in its original state, so that it continues to perform its original function. Software never needs this, because software doesn't wear out or degrade. Except for the occasional dropped bit, which usually totally destroys the software so you have to restore it from backup, software stays the same forever, without change. I have programs that I wrote 25 years ago that still do their original task perfectly, despite constant use.
The problems is that we're using "maintenance" to mean making changes to the software, to change its behavior so that it can do new things. Before software, such changes were never called "maintenance". They was called things like "revisions" or "alterations" or "redesigns", something with a "re-" prefix to remind you that you're changing things.
To use the usual transport metaphor, it's like you have a very functional road that has long been maintained by fixing the usual cracks, potholes, and other degradation that happens to all roads due to traffic and weather. Then management comes along, and decides that the road needs to be usable by trains, and this is a simple enough enhancement that the Maintenance Department can do it in a day or so. The maintenance folks have no experience with railway building, but they dutifully rush out, dig up the road, and install tracks. They don't have the training or time, so they haven't properly rebuilt the roadbed to support the much heavier traffic, and nobody had told them about the need for a much larger turn radius that trains need than cars do, so trains can hardly use the result. It takes several weeks, so management criticises them for not adhering to the scheduled two-day delivery time, as well as for building a low-quality railway that constantly needs more "maintenance" work.
Then, some time later, management decides that the road should also be "slightly augmented" to handle boat traffic. Never mind that it goes over a hill; that can be handled by building a system of locks. So the "maintenance" crew sets out to do the job, again without any training in canal building, using tools designed for maintaining auto roadways. And again, they're criticised for getting behind schedule and doing a poor job. And the water supply for the lock system is a constant resource hog.
Of course, with roads, railroads and canals, people can see the physical results. Even the dumbest manager can see that they're not at all similar (and why you try to avoid building canals over hills). A problem with software is that it's just bits hidden inside the computer's memory, so it all looks the same from the outside. This makes it hard to understand the difference between small bug fixes and total redesign and rewrite. It's all just "maintenance", right? How hard can it be? And why are the software maintenance people always so slow and behind schedule? They can't be very good at their job, right?
I suppose there's no chance that we can ban the use of the word "maintenance" in software. That would be the best approach. But it would require admitting that we'd made a major blunder in our terminology. So we're probably stuck with doing "maintenance" to make major revisions and retargeting of software.
The large number of servants who ran away or committed suicide suggests that the conditions of life during the period of bondage may not have been so different for the servant and the slave.
Bloody Christian literalists.
We should note that the Bible wasn't written in English; the relevant passages were in classical Hebrew. There was a single word in that language, usually transliterated "'eved" (pl. "'avadim") that has been variously translated as "servant" or "slave", often in neighboring passages. There seems to be no clear reason why a particular translation was used in each instance.
It's just another example of the difficulties in translating languages, because categories like these often don't quite line up.
Of course, to a lot of American Christian literalists, the "original" bible was the one written in the English of the early 17th century. But they do still have some competition from the folks who insist that the original bible was the 1534 version written in German.;-)
[i]f you're ridiculously pedantic, you'd interpret "can you put peroxide in your ear?" as meaning "is it physically possible to put peroxide in your ear?" and the answer, of course, is yes... Normal people, on the other hand, will interpret it as "is it a good idea to put peroxide in your ear?"...
Perhaps we should note that these questions were not asked of ridiculous pedants nor of normal people. The article was about questions sent to computers. Even the dumbest of n00b lusers knows that no computer actually "understands" these questions in any usual sense.
Talking about how normal people would understand such questions is utterly off topic in this discussion.
(And not just because you don't find such people here.;-)
(Also, I wonder why the stupid/. stylesheets force this textarea input widget to such a narrow width? Anyone know how to fix it in firefox? Why not just say something like"width: 80%;"? Maybe I should switch to Safari for/., since it puts a resize corner on textareas that lets you correct stupid problems like this.)
The Torah has 613 Mitzvot, commandments, or laws. Yet there are 10 commandments directly attributed to God.... That means fundamentalists who want to come down on gays suddenly don't have much in the way of Biblical evidence to support themselves, but it also means those that want to mock Judeo-Christian beliefs can't uphold the silliness contained within the 613 Mitzvot either.
Oh, I dunno about that; it seems to me that you're going against the leadership of centuries of precedent by millions of clergy with that suggestion.
You're basically objecting to people taking one or two biblical verses out of context, and interpreting the words however you can to support your personal beliefs. You might think this is wrong (or silly) on its face. But it's exactly what nearly every preacher does every Sunday morning in every church. It's totally conventional to start with a Bible Reading, usually just one or two verses, and use those words as the basis of a sermon.
This is done routinely as part of the standard Christian service in nearly every church. So claiming that it's wrong is just going to puzzle most people who've ever participated in such services. If it's wrong, why do all the church leaders make it the main point of their main religious service?
Part of what the author of the questions to Dr. Laura was doing was parodying this Christian (and Jewish) practice. If it's OK for your pastor or priest or rabbi to take a Bible verse out of context and expound on it, why is it wrong for anyone else to do the same thing?
If they can't take critics using this technique against them, they shouldn't be using the same technique so routinely as the basis of religious services that are purportedly to educate and edify the masses.
But by deleting and disabling it I at least make sure that nobody besides Google can access that information, even if they somehow find out my password.
Or if they pay someone who works at google for a copy of the information.
Or if they work for a government agency who has sent google a letter demanding a copy of the data under such-and-such federal law or regulation.
Or if they're a private investigator who has paid a judge for a court order.
Or if they just happen to have a good buddy at google who is willing to do a favor.
Even our best language translators typically understand very little linguistic comprehension, and then only in a specific language or topical domain. Yet, the average five-year-old child demonstrates ALL of these capabilities.
Very true. But probably not all that important, because we don't need artificial 5-year-olds.;-)
I'd suggest that AI success might follow more easily from concentrating on that "only in a specific language or topical domain" part. Like other engineering advance, that's where we have problems that we aren't good at solving, but could well be amenable to computer assistance.
A semi-humorous example from several projects that I've worked on: When faced with the usual problems in making the code portable to different systems, I've often written a little perl program that opens one or more files under/usr/man and reads through the text, extracting information. The program's output is usually C or related languages, and includes definitions of constants, initial values of variables (or tables of such), and sometimes a few small low-level routines for dealing with parts of the system that vary. Inevitably, some of the others eventually notice, and respond with something like "What??? You wrote a program that reads the manual and generates code?" I adopt an innocent look, and basically say "Yeah, uh, is there a problem with that?" It especially impresses management when they find that it works. But I just point out that they have several known or suspected perl (and/or python) programmers on the team, and we consider this sort of thing routine. It's one of the reasons that particular tool was developed, y'know, and it's easier than doing it by hand on every new machine that comes along.
But this isn't a violation of the known problems with machine understanding of natural human languages. It's dealing with a very narrow sort of English, the kind found in technical documentation. This isn't at all like trying to get the machine to understand general English. It's not easy, and it took us a few decades to build tools that made it tractable. But it's only practical for reasonably narrow technical dialects, which are typically much more regular and less ambiguous than the general language. And the code doesn't have converse with random humans; it only has to extract certain very narrowly-defined information from the text, much of which consists of snippets of code surrounded by an explanation of what they are.
Similarly, software that generates fairly readable English output isn't all that difficult, especially for very narrow technical topics. Lots of us do that routinely. But we're not trying to make the machine communicate with 5-year-olds; we're trying to make them communicate technical information to people who (maybe;-) should understand it.
Maybe this will never lead to computers that can usefully talk to infants. If so, it doesn't matter, because we'll still have lots of those things called "parents" that can do that job. But we might be able to make machines that can do something that most humans won't be able to do, which is to communicate better with the more technically-trained people that are using the computers. And, as has happened in other areas of engineering, this could eventually lead to somewhat better computer communication with less technical people.
But we probably won't call it "intelligent". When we get it working, we call it "engineering".;-)
I think the first important steps in creating true AI is understanding the human brain better.
Well, maybe, but maybe not. Consider flight: We finally made practical flying machines when some experimenters gave up on trying to imitate birds, and just worked on building machines that could fly. The results were only superficially similar to birds, and functioned rather differently..
Actually, understanding the details of how birds fly followed from what we learned by building other kinds of flying gadgetry (airplanes, helicopters, blimps, kites). For a century or more, there was a running joke about how aerodynamic theory proved that bumblebees can't fly. It was only around 1990 that scientists figured out how bumblebees fly, and it involves a process very different from how airplanes and helicopters (and birds) fly. So far, this hasn't turned out to be very useful for us, since it doesn't scale up to objects much larger than a moth or dragonfly. But our non-avian aerodynamics has turned out to be very practical for many purposes. Only recently have we finally succeeding at building small flying gadgets that use flapping wings similar to birds' wings, and they don't yet have any practical uses. The ultralights, which are very unlike anything in nature, are far more practical.
Also, as others have pointed out, we really don't need computers that mimic human intelligence. We have a plentiful supply of humans that can do that, and we're hardly using them to full capacity. It's more likely that we'll learn how do build intelligences by continuing the path we're already on, building more and more complex experimental software structures that can deal with new kinds of information problem solving. Eventually this might lead to better theories of intelligence, though we'll more like call it "computability" or something similar. Understanding of the human mind might eventually develop after we've learned how to build things that implement "intelligence" very different from ours to solve problems that we can't do well.
We also have examples of natural processes that we didn't even know existed until after we invented them ourselves. Consider our rotary engines powered by chemical processes. Such things do exist in nature. The bacterial flagellum is one example. But we only learned this in recent decades, about two centuries after the first rotary motors were developed for human industry and transport. Similarly, some fish have had electro-chemical "batteries" for probably millions of years, but we didn't understand them until we'd been making our own batteries for over a century.
In general, we've often had more success by figuring things out ourselves, which then leads to understanding of how the things in nature actually work.
Another geographical blunder in the article is saying that the rift will connect the Red Sea and the Gulf of Aden. That's because they're already connected.
Yeah; I was sorta wondering what map they're using. Another channel linking the Red Se and the Gulf of Aden wouldn't really do much to either of those bodies of water, though it might sorta change property values along the length of the rift.
In any case, I've been noticing that we seem to have this sort of wide-eyed "OMG Africa is splitting apart and we're gonna have a NEW OCEAN!!!" sort of report at least once a year. The nature of Africa's Great Rift has been pretty much understood for at least a century. And the "new ocean" idea is sorta silly. It'll split off a new small continent about the size of Australia, though longer and narrower. There'll be a watery passage that's comparable to the Mediterranean or Baltic. It'll be much like what formed Madagascar, but on a scale 2 or 3 times bigger. And it'll slowly happen over a few million years, with lots of major earthquakes and volcanic eruptions along the way. Just as the geological record says has been happening for several million years of the past. This is intro geology text material, not news. There are much better articles on the subject in National Geographic from 20 or 40 years ago.
One interesting aspect to the whole story is that it's the main environment where our earliest ancestors split off from the other great apes. This has been observed by any number of paleontologists, though so far there's not really all that much evidence of a cause-and-effect relation between Great Rift conditions and human evolution. But it is our species' home turf.
The speed of this event is interesting, and possibly a news story. But the geological record shows lots of earlier events that were equally fast and catastrophic. It's a major fault zone, with a string of huge live volcanoes and several large calderas. Of course there are going to be big, catastrophic events now and then.
[T]he resolution on the DS is too low, and the LCD (at least on my phat DS) is too bright at night, and not bright enough outdoors.
The brightness problem is slowly being solved, and it probably won't be more that a few more years until you can quickly adjust brightness to what's comfortable to your eyes under most conditions. They might even learn what the paperback-book producers learned decades ago, and replace the default full-white background that is the "standard" now with color schemes that are easier on the eyes.
The pixel count (or resolution if you prefer) problem may be harder, since for most eyes, we're reaching the point where smaller pixels won't add anything to readability. This means they're facing a basic problem of screen size. And, as was observed by developers of the first Palm handhelds, if it doesn't fit in my pocket, I won't have it in my pocket. It'll be sitting back on my desk rather than somewhere that I can grab it and use it. So the handhelds are basically limited to a size that fits in the majority of pockets, which is something controlled by the fashion industry, not by anyone with any intelligence or interest in usability.
It's true that a few models are now coming in a form that opens like a book, presenting two small screens to the reader, thus doubling the visible screen area. But this probably can't be improved much. We'll have to wait for the "content suppliers" to supply the content in formats that actually work on the small screens of pocket-size portable computers.
One reason to expect that this might take a while is that, if you look at the earliest design of Web software, you'll find a lot of explanations that HTML was specifically designed to make it easy for the "content" to be displayed on screens of different sizes. This was considered an important problem right from the start, and HTML was consciously designed with the idea that the software at the last "display it" stage would make all layout and formatting decisions.
But it hasn't worked out that way. The Web is mostly run by designers that are openly contemptuous of such concepts. They know how their lovely designs should look, and they've "extended" the markup to let them restrict the layout to exactly what looks good to them on their own big screen. Most of it is crappy on small, pocket-size screens. The designers know this, but don't care. You should use a screen big enough to properly render their designs, not a tiny screen that fits in your pocket. I've lost count of how many times I've built web pages that came out clear and readable on all screens I could test them on, including my pocket "smartphone", only to have my design vetoed by a higher-up, and replaced by something similar but with all layout details specified. They even have people test the redesign to make sure that it doesn't look good on small screens (though of course that wasn't how they worded the testing procedure).
Until this user-hostile attitude is broken, we'll continue to have major usability problems with the growing population of our little pocket-size computers. Improved screen resolution will help for a while, but we're rapidly reaching the resolution limit of most human eyes, and that'll put an end to that path.
(Actually, I'm working on a couple of web sites now that have exactly this problem. My nefarious scheme is to find out what screens and software the decision makers are using, and write code that produces the restricted formats for those, while also detecting most smaller screens and sending free-form pages to them that can be formatted to fit by their local software. I've gotten away with that a few times, and I can probably do it again. But I often wish that Web standards had included a mandatory field in requests telling the server the client's window size.;-)
haha, did you just say humanity has an oversupply of intelligence??
Well, we don't seem to making very good use of it, do we?;-)
When a resource is sitting around in plain sight, unused, you'd usually conclude that you have an oversupply. Either that, or you're not intelligent enough to make use of an available resource.
Perl sure, but Prolog? A common programming language?
Heh. Actually, I probably should have said Python. Prolog is what I usually like to use as an example of a major failing of the software industry. I may use Prolog in a few of my own projects, but in the business/industrial world, I've always been turned down when I try to introduce it. I keep running into problems where I find myself thinking "This would only take a few lines of Prolog." But instead, I spend weeks or months programming a stripped-down mimic of resolution logic. It would be so much easier if I just had the whole package available for use when that kind of problem comes up. Of course, nobody else on the team understands what I'm talking about, or believes that the task would be an afternoon's job (or less) in the right language, since they've never seen anything that packages Prolog's little trick of logic. They've often been impressed by the "AI" routine that I implemented to do something they doubted was doable, and I get lotsa geek points out of it. But I can't convince them that they've missed an important bit of software technology.
There's also the number crunching arena, where I've known a number of people who lament the fact that the good idea behind APL never much caught on. That's also something that could be usefully incorporated into many other languages. After all, if you have some function in your library, it's rather easy for a compiler to generate the loops to do it across arbitrary arrays. It's not a sophisticated trick any more, and easily within the capabilities of modern compilers or interpreters. You'd think by now that scalar operators in particular would automatically parallelize when fed arrays as args. But for some reason, this simple software-engineering advance isn't available in any of our common languages. Not even now that nearly everyone is buying laptops with multiple cpus, which could really parallelize a lot of things with no extra code needed.
But as some other software sage observed, contrary to Newton's famous comment, in the software business we don't stand on the shoulders of giants; we step on their toes.
And on top of what you have said - if anyone does achieve "true" artificial intelligence then nobody would want it, because it will include all the traits that we so desperately want to eliminate. Eg: machines will have to start becoming inaccurate, emotional, imaginative, needy etc. as these are all fundamental to our "intelligence" as humans.
Well, I'm afraid you may be right. And it's a variant of something that a few AI researchers have pointed out: There's no point to duplicating human intelligence. We have a perfectly good way of getting that already, and our problem is that we have an oversupply. What would be a more useful result would be machines that were intelligent in different ways than we are.
The usual parallel is with other machines. We have machines that fly. They don't duplicate birds or bats or insects; the useful flying machines do it in different ways that are more useful to humans. No flying creature can carry the tons of people or freight that the airlines do. Similarly, someone has pointed out that asking whether machines can think like we do is as pointless as asking whether a submarine can swim like a fish. Of course not; it "swims" in a manner that's more useful to us than a true fish mimic would be. Of course, airplanes and submarines have a superficial resemblance to birds and fish, for the simple engineering reason of efficient motion through the air and water. But the resemblance pretty much ends there, for very practical reasons. And on land, we have many kinds of vehicles that aren't mimics of horses or other beasts of burden; they're designed to have large capacity and higher speeds than the animals they (mostly) replaced. The fact that most of them are limited to roadways that we also build isn't a serious problem; we don't much need all-terrain vehicles for most of our purposes.
Similarly, we could argue that the AI computer researchers have had a great deal of success. Decades ago, we had machines that were capable of very fast arithmetic, and not much more. Now we have machines that are replacing many kinds of menial tasks that used to require human intelligence. It's true that they aren't very intelligent; they're doing a lot of "mindless" tasks that used to require a human mind, but now can be relegated to a machine. They do these tasks very fast, and don't get bored and sloppy like any semi-intelligent person does. This is a growing benefit to us, especially as it frees up many human minds for more "lofty" pursuits (while it introduces the social problems caused by a reduced need for uneducated human workers).
But we still have the problem that even these successes are disparaged by the people who consider themselves above all that geeky stuff. We see this in the current article, which lists AI as a total failure. In fact, the AI researchers are responsible for a fair number of technical advances in the software field. Software engineering depends on a lot of their developments for many things that used to be wild futuristic speculation, and now are extensive libraries for handling complex data structures. Many of their wild ideas are incorporated in our more advanced programming languages. That may not be success in creating a god-like machine intelligent, but it's not failure.
The most obvious counterexample to the "AI" nonsense is to consider that, back around 1800 or any time earlier, it was obvious to anyone that the ability to count and do arithmetic was a sign of intelligence. Not even smart animals like dogs or monkeys could add or subtract; only we smart humans could do that. Then those engineer types invented the adding machine. Were people amazed by the advent of intelligent machines? No; they simply reclassified adding and subtracting as "mechanical" actions that required no intelligence at all.
Fast forward to the computer age, and you see the same process over and over. As soon as something becomes routinely doable by a computer, it is no longer considered a sign of intelligence; it's a mere mechanical activity. Back in the 1960s, when the widely-used programming languages were Fortran and Cobol, the AI researchers were developing languages like LISP that could actually process free-form, variable-length lists. This promised to be the start of truly intelligent computers. By the early 1970s, however, list processing was taught in low-level programming courses and had become a routine part of the software developers toolkits. So it was just a "software engineering" tool, a mechanical activity that didn't require any machine intelligence.
Meanwhile, the AI researchers were developing more sophisticated "intelligent" data structures, such as tables that could associate arbitrary strings with each other. Did these lead to development of intelligent software? Well, now some of our common programming languages (perl, prolog, etc.) include such tables as basic data types, and the programmers use them routinely. But nobody considers the resulting software "intelligent"; it's merely more complex computer software, but basically still just as mechanical and unintelligent as the first adding machines.
So my prediction is that we'll never have Artificial Intelligence. Every new advance in that direction will always be reclassified from "intelligent" to "merely mechanical". When we have computer software composing best-selling music and writing best-selling novels or creating entire computer-generated movies from scratch, it will be obvious that such things are merely mechanical activities, requiring no actual intelligence.
Whether there will still be things that humans are intelligent enough to do, I can't predict.
Well, I am a bit confused. Plants do perspire and release water vapour but they also usually release heat (they have a metabolism and show on infrared).
It is a bit complicated.;-)
It's true that plants give off IR radiation. But they also release water vapor, and the evaporation process is endothermic. This cools the plant tissues slightly, and conductance cools the air at the leaf surfaces. There's a lot of energy conversion and transfer going on around a functioning leaf. The "bottom line" of it all is that the air among masses of plant life is usually a few degrees cooler than the outside air, unless the air is cold, when the plants may somewhat warm the air. You can feel this when you walk into a clump of trees, even if you're still in the sunlight. Much of this effect is due to inefficiencies in the plants' techniques for controlling their own internal temperature.
It is interesting that plants can be giving off IR while being cooler than their surroundings. Part of the explanation is that the photosynthetic process involves a lot of frequency shifting. Photons are absorbed at one frequency, electrons bounce the absorbed energy around a bit, and another photon is radiated at a lower energy level. Most of this is significant to the plant's metabolism, but there are inefficiences. Thus, chlorophyll absorbs best in the green/blue part of the spectrum; a quick google found a graph at http://www.statemaster.com/encyclopedia/Chlorophyll. Note the complexity of the graph, with a lower peak in the red. To increase its absorbency, chloroplasts surround the chlorophyll with frequency-shifting molecules that absorb photons at other frequencies and reradiate the energy as photons that the chlorophyll prefers. But chlorophyll molecules don't intercept all these green/blue(/red) photons, explaining why leaves are greener than the incoming light. The whole process is impressively complex, and we're not very close to fully understanding it all. But much of the accidental reradiation is at low-energy frequencies, in the IR part of the spectrum.
Some interesting research reports a few years ago involved some tiny temperature sensors that could measure the temperature inside leaves. They reported that a wide variety of plants tested, over a wide range of atmospheric conditions, the internal leaf temperatures were close to 21 Celsius. This is somewhat cooler than our body temperature, and generally different from the air. The "higher" plants seem to have evolved some impressive temperature regulation methods, presumably because chemistry is simpler and cheaper if you can control the temperature. So at cooler temperatures, leaves tend to absorb lots of photons that they don't need for photosynthesis, but which function solely to warm the leaf to its operating temperature. The leakage from this process mostly loses low-energy photons, i.e., infrared. At higher temperatures, leaves can both radiate more energetic photons, and also release water vapor, which cools the tissues rapidly. In this case, most of the inefficiency is in heat absorbed from the surrounding warmer air, which is the main reason that clumps of plants are cool. But it's not really that the water was vaporized to cool the air. It was vaporized to cool the internal leaf tissues, and the air cooling is due to poor insulation at the leaf surface. The plants are trying to keep themselves at operating temperature, and cooling of surrounding warmer air is an inefficiency in this process.
Anyway, it's complex. And it's impressive how much control can be done by critters that have no muscles or nervous system and are stuck spending their whole life in one spot. It's almost entirely complex chemistry, including some very sophisticated control of photons and passing energy via electrons along chains of carbon atoms. Understanding what's known of it takes years of study. But you can find a lot of summaries by googling for someth
Dubious claims that sound scientific, but not made in a scientific journal, not peer reviewed and making 1st grade biology errors in the title, and you still think there is some truth in that article?
And to make it even sillier, the article is illustrated by a face (female, of course) sniffing three flowers from the Compositae family. The Sage (genus Salvia in the family Lamiaceae) and gardenia (genus Gardenia, family Rubiaceae) have flowers that are radically different from composite flowers.
I did especially like the claim that the gardenia "creates water vapor". Ex nihilo? If they release water vapor, that's pretty much what all leafy plants do as part of their normal metabolism. Of course, some are more wasteful of water than others, so maybe this gardenia has been selected to really squander its water. But, strictly speaking, the water vapor doesn't cool anything. The cooling happens when the water is converted to vapor, in or at the surface of the leaf. Anything else is cooled by the mixing of the air at the cool leaf surface with other air; entrained water vapor has no real effect on this. It might actually have the opposite effect, if the air is sufficiently moist to produce condensation, which will release a "heat of condensation" into whatever surface it condenses on, but this is generally a minor effect compared to the cooling from the leaf surfaces.
I'd wonder if there is a better description anywhere of what (if anything) they've developed. The story sounds like a typical mangling of a scientific report by publicists who don't understand any of the words. The fact that they'd illustrate it with flowers from a different family supports that inference.
In my opinion, the reason those apps do not exist is that consumers really only care about 4 apps at most, and that number is really reduced to one app in this day and age. There are plenty of things I am doing with free/open source software that are could not be done without spending a fortune on proprietary licensing, but they are things that consumers do not care about.
This is the history of much or our technology. New things are developed out of public sight, by people who want them for their own narrow purposes. Thus, most people would tell you that the World Wide Web was invented by Microsoft. In fact, it started of at CERN, a totally meaningless name to 99% of the Web's users, to make it easier for physicists to share their experimental data, research papers, etc. Outside of the geek community, hardly anyone has ever heard of Tim Berners-Lee, and he wouldn't make it onto any lists made by anyone not involved in Web development.
This is the norm. Last night I was at an event where I was approached by several people who told me how much they appreciate my web site and the things I've done for them. I won't mention the topic, because it's just one of many similar stories. This includes my usual explanation that I really did it for my own nefarious purposes. I'd found a growing number of sites that had data of a sort that I find useful. I made a sort of combined aggregator/index/search site, because I was annoyed with the time I was wasting trying to find things on those other sites, and decided "This is a job for the computer". I set it up as a web site so that I could use it anywhere that I had Net access. I mentioned it to a few colleagues, who mentioned it to a few others, and now it has between 5000 and 1000 hits most days. It's not a huge commercial thing, and probably never will be, but it's useful to a few tens of thousands of people (much less than 1% of the world's population).
Of the many such online development, most of them are free/open source because they have no obvious commercial potential. Eventually, a few may reach some sort of public notice. At that time, the commercial world will probably pick up on what has happened. A few corporate giants will to buy them out (or reverse engineer them) and commercialize them. This will probably include incorporating them into the big, monolithic apps that we're all familiar with. People will say how wonderful this new thing is that corporation X has invented. And they'll say that the Open Source stuff is still irrelevant, because it doesn't provide anything that people want.
These predictions are fairly easy, because it's how things have always been done. If you dig a bit, you can probably find examples in whatever area you're intimately familiar with.
The really glaring example is the "Windows" GUI that's been so much discussed here. Insiders know about the Xerox PARC project that started it all. But probably even most/. readers don't know about its origins, because they only know the decade-later version commercialized by Microsoft, and they judge everything else by how well it mimics this particular offshoot of the original project. This is, of course, a loser's game, since you can't possibly track a moving target whose future moves are secret. But it's likely that right now there are a few small projects underway that, in a few more years or decades, will suddenly appear in the public eye as a huge improvement, to be taken over by the corporate marketers and sold as their marvelous new development. But it won't be produced anyone trying to clone the current market leader.
Does the whole idea of "Open Source" has been kidnaped by the corporate *bs* and rebranded with a new background, meaning and of course, new corporate "heroes"?
Nah; it just means that the people who did this survey didn't bother talking to anyone who really knows what Open Source is or who might be influencing a lot of others right now. They talked to a bunch of top corporate management guys, who mostly have no knowledge of or interest in where their lowly workers are getting their ideas or tools. That's for the bean counters, y'know. To most of them, Open Source is a marketing phrase with growing positive connotations, and that's all they need to know about it.
Pretty much the same thing applies to the question of why there were no influential women in the results. Did they actually ask any female executives? (And have they verified that all those "foreign" names belong to males?;-)
Actually, I wonder how this would work out if you asked the programmers. How many of you involved in programming actually know the sex of any of the authors of the software that you're downloading? Do you even care? I'm reasonably certain that Linus is male, but for most of the open source software that I have on my machine, I can't actually tell you much about the authors. Often I don't even recall their name, and would have to look it up in the code. I know I've seen feminine names there, but I haven't paid that much attention. I've also noticed a lot of foreign names that I can't assign to a sex.
Companies selling open source software is a Good Thing. It means the open source movement has been successful. How is it exploitation?
There's a difference?
(Actually, I did do a google "define:" check. The results were worded somewhat differently, but I couldn't pin down an actual difference in meaning. I do suspect that we're talking about different words used to "frame" an issue by different subcultures.)
Slashdot Mirror
You can't possibly put icons for everything on the desktop - you'd need a 50" screen.
Which reminds me: In the cases where I do want to put an icon on the desktop, what are the available non-GIMP tools that can create or edit icons and other such silly little images? I've tried to do this with GIMP, but about all I succeeded in doing was destroying the icons I had. (Good thing I made backup copies of them first. ;-) Maybe someday I'll learn to use GIMP, if I ever find a novice-friendly intro doc. But meanwhile, something not so powerful could be very useful.
Back in the 1990s, there were a number of small, specialized apps for tweaking such little image files (such as bitmap). Some of them even did color (unlike bitmap). I don't seem to find them on any of the linux boxes that I have access to. Yeah; I know about google, and in fact have a reply from it in another window. But this seems on-topic here, and it's likely that some readers with expertise in the topic are perusing this discussion. So if you have a favorite icon editor, even if it's capable of doing more sophisticated stuff, how about telling us about why you like it?
Don't get me wrong. If you know what you're doing and you have the time and patience to get through it, you can do some pretty cool stuff with Drupal. That said, if the only CMS you've ever touched in your life was something like Wordpress, you're in for a rough ride.
Yeah; that's the impression I got, which was why I spent some time (and money ;-) trying to learn to use it. I may have to put it off a while longer, since I've been having a lot of success just building my own stuff. But the main problems with drupal are a lot more basic than trying to figure out which modules to use. I'm nowhere near even looking at modules. Thus, a major brick wall has been when I get to the point in several docs saying to use the login page (or node). I've had no success at finding it. I even asked on a drupal forum, and got some interesting replies, but nobody answered the very basic question: How to I get to the login node? I've gotten to dozens of other nodes, but the only instance of "log" in any of them is one that has a link called "Logout".
A funny part of this is that of course I googled "drupal login", including with a few other likely keywords. I got zillions of hits, apparently all of the form "... after you login to drupal ...". But if google knows of a page that says how to do this, its page rank isn't high enough to get within the first 100 or so hits that I looked at with any of the keywords that I guessed.
This worries me, actually, The fact that I'm not invited to log in, but I am invited to log out implies that I am in fact already logged in. I'm pretty sure I didn't ever do this. Although I created a couple of new login ids (or at least I think I did), I have never typed those ids or their passwords to anything recognizable as a login procedure. That single "Logout" links tells me that my machine probably has some account logged in permanently, most likely an admin account (since I was allowed to create new logins). I spent some time looking for clues that would verify that this is true or false, but couldn't find anything that I recognized as telling me who I was logged in as. Presumably anyone who knows the default login name and can connect to my machine will have free run of my drupal installation, and I won't have a clue that they're doing anything.
So until I decide I have enough free time to dig into it again, perhaps I should hunt down everything I can find that's associated with drupal and delete it. OTOH, I'm not confidant I could even do that. If drupal installed something that doesn't have "drupal" anywhere in its name or contents, I probably wouldn't identify it for what it is.
I was careful to install it on a "test" machine that's hidden behind a firewall. But I'm using it for testing a lot of other stuff, so I'm not sure I want to refomat the disk and do a clean install, just to get rid of drupal. And it took long enough to install that I'm tempted to just keep it around until I have the time again. If only I could verify its logged-in state ...
In a previous job we got rid of a proprietary system because we moved to a new one. No one thought about all the old records during this transaction. Well, we had access the the DB, but it was coded in such a way that the fields were a jumble of crap and would have taken forever to pull apart to get the records. I asked the proprietary company if they had a way to dump the records to PDF for easy reading and storage. Nope... This company was in business for 7+ years and they had no way to mass export records?
Of course. The vendors do that all the time, to lock customers into their products. It's no accident at all.
I've worked on several projects like this. Cracking the data using printouts (billing, customer notices, etc.) messy, ad-hoc coding. But if a company wants to pay the sort of hackers who know how to do it (naming no names ;-), you can usually get almost all the data out this way.
One funny thing I've found is that after a short time, the DB experts - even the ones being paid by IBM or Microsoft - are usually rather friendly, and cooperate in finding ways to get the data out in some readable format. I think it's because people who work a lot at customer sites end up being very sympathetic with the customers' problems, and don't have a lot of respect for the tricks their employers have used against the customers. But that's just my experience; others may have found a lot less cooperation.
I've usually felt relief when those jobs became "previous jobs". ;-)
Heh. I'll assume you meant fraternal twin.
A few years ago, I read a interesting article (which I probably can't find any more) that among other things calculated the probability that there were pairs of "unrelated" humans with identical DNA. From what was known of DNA variability in humans, they calculated that there were between roughly 100,000 and 1,000,000 such pairs of "pseudo-twins" in the world, born to different parents but having identical DNA.
If we could find them, they would usually turn out to be distant relatives, of course, with common grandparents N times removed. At least their ancestors would probably come from the same part(s) of the world. But in many cases, the common ancestors would be so remote that they couldn't be determined from existing birth records.
Even more years ago, I remember reading a novel in which two of the characters were "anti-twins", born from the same parents, but with no shared chromosomes. The probability of this is a lot higher than the above number. I'll leave the calculation as an exercise for the reader. ;-)
You're probably both right.
As many armchair econ theorists here have been pointing out repeatedly, the attempted purchaser is an American corporation. As such, their primary (and according to some, only) obligation is to the bank accounts of their officers and shareholders. If there's a commercial value to the information, they likely consider it immoral to not sell the information for whatever price the market will bear.
The fact that mere "citizens" might be upset by this only means that they'll do this quietly, with no public notice and no records of the sales available to outsiders. If we learn of the sales, it'll be far too late for us to do anything about it.
Expecting anything else is simply naive. We should be assuming that, if anyone has had the opportunity to collect a sample of our DNA, they have done so, and the information is in the databases of anyone willing to pay the asking price. This especially applies if you have ever had any dealings with a private, for-profit medical organization.
(Point is: Do we need more social networking sites? Why would I start my own...)
Well, I've recently got ahold of several drupal books, and lots of the online docs, and installed on a handy machine. The reason is that I'm involved in a couple of products where we could really use a local social network/news/blog site over which we have full control. Drupal seemed to have lots of rave reviews, so it was a good candidate.
Unfortunately, after several weeks of roughly half-time studying the docs and experimenting with the software, I had to admit that "I just don't get it". I wasn't able to make it do anything useful. This was mostly because I found the docs a morass of new jargon, none of which I understand, mostly written by people who apparently don't understand the concept of a "definition", and think that glowing descriptions are the same thing. A few questions on the drupal forum didn't help much. For example, after all that reading, I have no idea what a "node" is or how to recognize one when I see it; I only have many assurances that it's an important concept. At first I thought it was a kind of file, then I thought it might be like what browser users call a "page", and I had several other guesses, but I had to admit that all were probably wrong.
So I faced the fact that I had to get something working and usable. I collected a mixed bag of more limited tools from elsewhere, started exercising my mad perl skillz, and a few weeks later I have something that impresses the clients enough that they've started using it and burying me under requests for more features.
Now, I can tell by googling that many of those requests could probably be handled by something in drupal. But unless I can find something that will explain to a dummy like me what buttons to hit on my keyboard and/or mouse/touchpad to get something actually working, I don't think I'll be quite as willing to throw away any more resources on it. I'll just write off the money (and time) I spent on the books as a loss.
So is this book useful to a dummy who doesn't yet understand the jargon? Can an experienced programmer with no knowledge of drupal's terminology actually use it to produce something useful? And would that programmer understand the results well enough to be able to tweak it the way a client wants? (That's mostly deep stuff like "Can you put that button on the left and make it a bigger font?" ;-) Would money spent on the book pay off, or would I still be unable to get anything to work right?
I also have some serious security questions, but I suppose this isn't the place to ask them. And unless I can get the nuts-and-bolts stuff to work, they're not too relevant to anything.
They would be if they we're actively promoting it like The Pirate Bay, or something like setting up a DC++ hub called "All The Warez You Need".
Well, now; it seems to me that I've heard or seen lots and lots of ads from ISPs touting their "blindingly fast download" speeds. We all know what they're talking about here. They're not targeting geeks wanting the latest linux ISOs, y'know. Maybe they don't use words like "copyright" or "infringement", but it's fairly obvious what they're getting at.
Isn't it funny that the ISPs don't get prosecuted for such blatantly obvious enticement?
The real problem here is the use of an atrociously bad metaphor. The term "maintenance" refers to keeping something in its original state, so that it continues to perform its original function. Software never needs this, because software doesn't wear out or degrade. Except for the occasional dropped bit, which usually totally destroys the software so you have to restore it from backup, software stays the same forever, without change. I have programs that I wrote 25 years ago that still do their original task perfectly, despite constant use.
The problems is that we're using "maintenance" to mean making changes to the software, to change its behavior so that it can do new things. Before software, such changes were never called "maintenance". They was called things like "revisions" or "alterations" or "redesigns", something with a "re-" prefix to remind you that you're changing things.
To use the usual transport metaphor, it's like you have a very functional road that has long been maintained by fixing the usual cracks, potholes, and other degradation that happens to all roads due to traffic and weather. Then management comes along, and decides that the road needs to be usable by trains, and this is a simple enough enhancement that the Maintenance Department can do it in a day or so. The maintenance folks have no experience with railway building, but they dutifully rush out, dig up the road, and install tracks. They don't have the training or time, so they haven't properly rebuilt the roadbed to support the much heavier traffic, and nobody had told them about the need for a much larger turn radius that trains need than cars do, so trains can hardly use the result. It takes several weeks, so management criticises them for not adhering to the scheduled two-day delivery time, as well as for building a low-quality railway that constantly needs more "maintenance" work.
Then, some time later, management decides that the road should also be "slightly augmented" to handle boat traffic. Never mind that it goes over a hill; that can be handled by building a system of locks. So the "maintenance" crew sets out to do the job, again without any training in canal building, using tools designed for maintaining auto roadways. And again, they're criticised for getting behind schedule and doing a poor job. And the water supply for the lock system is a constant resource hog.
Of course, with roads, railroads and canals, people can see the physical results. Even the dumbest manager can see that they're not at all similar (and why you try to avoid building canals over hills). A problem with software is that it's just bits hidden inside the computer's memory, so it all looks the same from the outside. This makes it hard to understand the difference between small bug fixes and total redesign and rewrite. It's all just "maintenance", right? How hard can it be? And why are the software maintenance people always so slow and behind schedule? They can't be very good at their job, right?
I suppose there's no chance that we can ban the use of the word "maintenance" in software. That would be the best approach. But it would require admitting that we'd made a major blunder in our terminology. So we're probably stuck with doing "maintenance" to make major revisions and retargeting of software.
We should note that the Bible wasn't written in English; the relevant passages were in classical Hebrew. There was a single word in that language, usually transliterated "'eved" (pl. "'avadim") that has been variously translated as "servant" or "slave", often in neighboring passages. There seems to be no clear reason why a particular translation was used in each instance.
It's just another example of the difficulties in translating languages, because categories like these often don't quite line up.
Of course, to a lot of American Christian literalists, the "original" bible was the one written in the English of the early 17th century. But they do still have some competition from the folks who insist that the original bible was the 1534 version written in German. ;-)
[i]f you're ridiculously pedantic, you'd interpret "can you put peroxide in your ear?" as meaning "is it physically possible to put peroxide in your ear?" and the answer, of course, is yes ... Normal people, on the other hand, will interpret it as "is it a good idea to put peroxide in your ear?" ...
Perhaps we should
note that these
questions were not
asked of ridiculous
pedants nor of normal
people. The article was
about questions sent to
computers.
Even the dumbest of
n00b lusers knows that
no computer actually
"understands" these
questions in any usual
sense.
Talking about how
normal people would
understand such
questions is utterly off
topic in this discussion.
(And not just because ;-)
you don't find such
people here.
(Also, I wonder why the /. stylesheets /.,
stupid
force this textarea input
widget to such a narrow
width? Anyone know
how to fix it in firefox?
Why not just say
something like"width:
80%;"? Maybe I should
switch to Safari for
since it puts a resize
corner on textareas that
lets you correct stupid
problems like this.)
The Torah has 613 Mitzvot, commandments, or laws. Yet there are 10 commandments directly attributed to God. ... That means fundamentalists who want to come down on gays suddenly don't have much in the way of Biblical evidence to support themselves, but it also means those that want to mock Judeo-Christian beliefs can't uphold the silliness contained within the 613 Mitzvot either.
Oh, I dunno about that; it seems to me that you're going against the leadership of centuries of precedent by millions of clergy with that suggestion.
You're basically objecting to people taking one or two biblical verses out of context, and interpreting the words however you can to support your personal beliefs. You might think this is wrong (or silly) on its face. But it's exactly what nearly every preacher does every Sunday morning in every church. It's totally conventional to start with a Bible Reading, usually just one or two verses, and use those words as the basis of a sermon.
This is done routinely as part of the standard Christian service in nearly every church. So claiming that it's wrong is just going to puzzle most people who've ever participated in such services. If it's wrong, why do all the church leaders make it the main point of their main religious service?
Part of what the author of the questions to Dr. Laura was doing was parodying this Christian (and Jewish) practice. If it's OK for your pastor or priest or rabbi to take a Bible verse out of context and expound on it, why is it wrong for anyone else to do the same thing?
If they can't take critics using this technique against them, they shouldn't be using the same technique so routinely as the basis of religious services that are purportedly to educate and edify the masses.
But by deleting and disabling it I at least make sure that nobody besides Google can access that information, even if they somehow find out my password.
Or if they pay someone who works at google for a copy of the information.
Or if they work for a government agency who has sent google a letter demanding a copy of the data under such-and-such federal law or regulation.
Or if they're a private investigator who has paid a judge for a court order.
Or if they just happen to have a good buddy at google who is willing to do a favor.
Or if ....
Even our best language translators typically understand very little linguistic comprehension, and then only in a specific language or topical domain. Yet, the average five-year-old child demonstrates ALL of these capabilities.
Very true. But probably not all that important, because we don't need artificial 5-year-olds. ;-)
I'd suggest that AI success might follow more easily from concentrating on that "only in a specific language or topical domain" part. Like other engineering advance, that's where we have problems that we aren't good at solving, but could well be amenable to computer assistance.
A semi-humorous example from several projects that I've worked on: When faced with the usual problems in making the code portable to different systems, I've often written a little perl program that opens one or more files under /usr/man and reads through the text, extracting information. The program's output is usually C or related languages, and includes definitions of constants, initial values of variables (or tables of such), and sometimes a few small low-level routines for dealing with parts of the system that vary. Inevitably, some of the others eventually notice, and respond with something like "What??? You wrote a program that reads the manual and generates code?" I adopt an innocent look, and basically say "Yeah, uh, is there a problem with that?" It especially impresses management when they find that it works. But I just point out that they have several known or suspected perl (and/or python) programmers on the team, and we consider this sort of thing routine. It's one of the reasons that particular tool was developed, y'know, and it's easier than doing it by hand on every new machine that comes along.
But this isn't a violation of the known problems with machine understanding of natural human languages. It's dealing with a very narrow sort of English, the kind found in technical documentation. This isn't at all like trying to get the machine to understand general English. It's not easy, and it took us a few decades to build tools that made it tractable. But it's only practical for reasonably narrow technical dialects, which are typically much more regular and less ambiguous than the general language. And the code doesn't have converse with random humans; it only has to extract certain very narrowly-defined information from the text, much of which consists of snippets of code surrounded by an explanation of what they are.
Similarly, software that generates fairly readable English output isn't all that difficult, especially for very narrow technical topics. Lots of us do that routinely. But we're not trying to make the machine communicate with 5-year-olds; we're trying to make them communicate technical information to people who (maybe;-) should understand it.
Maybe this will never lead to computers that can usefully talk to infants. If so, it doesn't matter, because we'll still have lots of those things called "parents" that can do that job. But we might be able to make machines that can do something that most humans won't be able to do, which is to communicate better with the more technically-trained people that are using the computers. And, as has happened in other areas of engineering, this could eventually lead to somewhat better computer communication with less technical people.
But we probably won't call it "intelligent". When we get it working, we call it "engineering". ;-)
I think the first important steps in creating true AI is understanding the human brain better.
Well, maybe, but maybe not. Consider flight: We finally made practical flying machines when some experimenters gave up on trying to imitate birds, and just worked on building machines that could fly. The results were only superficially similar to birds, and functioned rather differently..
Actually, understanding the details of how birds fly followed from what we learned by building other kinds of flying gadgetry (airplanes, helicopters, blimps, kites). For a century or more, there was a running joke about how aerodynamic theory proved that bumblebees can't fly. It was only around 1990 that scientists figured out how bumblebees fly, and it involves a process very different from how airplanes and helicopters (and birds) fly. So far, this hasn't turned out to be very useful for us, since it doesn't scale up to objects much larger than a moth or dragonfly. But our non-avian aerodynamics has turned out to be very practical for many purposes. Only recently have we finally succeeding at building small flying gadgets that use flapping wings similar to birds' wings, and they don't yet have any practical uses. The ultralights, which are very unlike anything in nature, are far more practical.
Also, as others have pointed out, we really don't need computers that mimic human intelligence. We have a plentiful supply of humans that can do that, and we're hardly using them to full capacity. It's more likely that we'll learn how do build intelligences by continuing the path we're already on, building more and more complex experimental software structures that can deal with new kinds of information problem solving. Eventually this might lead to better theories of intelligence, though we'll more like call it "computability" or something similar. Understanding of the human mind might eventually develop after we've learned how to build things that implement "intelligence" very different from ours to solve problems that we can't do well.
We also have examples of natural processes that we didn't even know existed until after we invented them ourselves. Consider our rotary engines powered by chemical processes. Such things do exist in nature. The bacterial flagellum is one example. But we only learned this in recent decades, about two centuries after the first rotary motors were developed for human industry and transport. Similarly, some fish have had electro-chemical "batteries" for probably millions of years, but we didn't understand them until we'd been making our own batteries for over a century.
In general, we've often had more success by figuring things out ourselves, which then leads to understanding of how the things in nature actually work.
Another geographical blunder in the article is saying that the rift will connect the Red Sea and the Gulf of Aden. That's because they're already connected.
Yeah; I was sorta wondering what map they're using. Another channel linking the Red Se and the Gulf of Aden wouldn't really do much to either of those bodies of water, though it might sorta change property values along the length of the rift.
In any case, I've been noticing that we seem to have this sort of wide-eyed "OMG Africa is splitting apart and we're gonna have a NEW OCEAN!!!" sort of report at least once a year. The nature of Africa's Great Rift has been pretty much understood for at least a century. And the "new ocean" idea is sorta silly. It'll split off a new small continent about the size of Australia, though longer and narrower. There'll be a watery passage that's comparable to the Mediterranean or Baltic. It'll be much like what formed Madagascar, but on a scale 2 or 3 times bigger. And it'll slowly happen over a few million years, with lots of major earthquakes and volcanic eruptions along the way. Just as the geological record says has been happening for several million years of the past. This is intro geology text material, not news. There are much better articles on the subject in National Geographic from 20 or 40 years ago.
One interesting aspect to the whole story is that it's the main environment where our earliest ancestors split off from the other great apes. This has been observed by any number of paleontologists, though so far there's not really all that much evidence of a cause-and-effect relation between Great Rift conditions and human evolution. But it is our species' home turf.
The speed of this event is interesting, and possibly a news story. But the geological record shows lots of earlier events that were equally fast and catastrophic. It's a major fault zone, with a string of huge live volcanoes and several large calderas. Of course there are going to be big, catastrophic events now and then.
[T]he resolution on the DS is too low, and the LCD (at least on my phat DS) is too bright at night, and not bright enough outdoors.
The brightness problem is slowly being solved, and it probably won't be more that a few more years until you can quickly adjust brightness to what's comfortable to your eyes under most conditions. They might even learn what the paperback-book producers learned decades ago, and replace the default full-white background that is the "standard" now with color schemes that are easier on the eyes.
The pixel count (or resolution if you prefer) problem may be harder, since for most eyes, we're reaching the point where smaller pixels won't add anything to readability. This means they're facing a basic problem of screen size. And, as was observed by developers of the first Palm handhelds, if it doesn't fit in my pocket, I won't have it in my pocket. It'll be sitting back on my desk rather than somewhere that I can grab it and use it. So the handhelds are basically limited to a size that fits in the majority of pockets, which is something controlled by the fashion industry, not by anyone with any intelligence or interest in usability.
It's true that a few models are now coming in a form that opens like a book, presenting two small screens to the reader, thus doubling the visible screen area. But this probably can't be improved much. We'll have to wait for the "content suppliers" to supply the content in formats that actually work on the small screens of pocket-size portable computers.
One reason to expect that this might take a while is that, if you look at the earliest design of Web software, you'll find a lot of explanations that HTML was specifically designed to make it easy for the "content" to be displayed on screens of different sizes. This was considered an important problem right from the start, and HTML was consciously designed with the idea that the software at the last "display it" stage would make all layout and formatting decisions.
But it hasn't worked out that way. The Web is mostly run by designers that are openly contemptuous of such concepts. They know how their lovely designs should look, and they've "extended" the markup to let them restrict the layout to exactly what looks good to them on their own big screen. Most of it is crappy on small, pocket-size screens. The designers know this, but don't care. You should use a screen big enough to properly render their designs, not a tiny screen that fits in your pocket. I've lost count of how many times I've built web pages that came out clear and readable on all screens I could test them on, including my pocket "smartphone", only to have my design vetoed by a higher-up, and replaced by something similar but with all layout details specified. They even have people test the redesign to make sure that it doesn't look good on small screens (though of course that wasn't how they worded the testing procedure).
Until this user-hostile attitude is broken, we'll continue to have major usability problems with the growing population of our little pocket-size computers. Improved screen resolution will help for a while, but we're rapidly reaching the resolution limit of most human eyes, and that'll put an end to that path.
(Actually, I'm working on a couple of web sites now that have exactly this problem. My nefarious scheme is to find out what screens and software the decision makers are using, and write code that produces the restricted formats for those, while also detecting most smaller screens and sending free-form pages to them that can be formatted to fit by their local software. I've gotten away with that a few times, and I can probably do it again. But I often wish that Web standards had included a mandatory field in requests telling the server the client's window size. ;-)
haha, did you just say humanity has an oversupply of intelligence??
Well, we don't seem to making very good use of it, do we? ;-)
When a resource is sitting around in plain sight, unused, you'd usually conclude that you have an oversupply. Either that, or you're not intelligent enough to make use of an available resource.
Perl sure, but Prolog? A common programming language?
Heh. Actually, I probably should have said Python. Prolog is what I usually like to use as an example of a major failing of the software industry. I may use Prolog in a few of my own projects, but in the business/industrial world, I've always been turned down when I try to introduce it. I keep running into problems where I find myself thinking "This would only take a few lines of Prolog." But instead, I spend weeks or months programming a stripped-down mimic of resolution logic. It would be so much easier if I just had the whole package available for use when that kind of problem comes up. Of course, nobody else on the team understands what I'm talking about, or believes that the task would be an afternoon's job (or less) in the right language, since they've never seen anything that packages Prolog's little trick of logic. They've often been impressed by the "AI" routine that I implemented to do something they doubted was doable, and I get lotsa geek points out of it. But I can't convince them that they've missed an important bit of software technology.
There's also the number crunching arena, where I've known a number of people who lament the fact that the good idea behind APL never much caught on. That's also something that could be usefully incorporated into many other languages. After all, if you have some function in your library, it's rather easy for a compiler to generate the loops to do it across arbitrary arrays. It's not a sophisticated trick any more, and easily within the capabilities of modern compilers or interpreters. You'd think by now that scalar operators in particular would automatically parallelize when fed arrays as args. But for some reason, this simple software-engineering advance isn't available in any of our common languages. Not even now that nearly everyone is buying laptops with multiple cpus, which could really parallelize a lot of things with no extra code needed.
But as some other software sage observed, contrary to Newton's famous comment, in the software business we don't stand on the shoulders of giants; we step on their toes.
And on top of what you have said - if anyone does achieve "true" artificial intelligence then nobody would want it, because it will include all the traits that we so desperately want to eliminate. Eg: machines will have to start becoming inaccurate, emotional, imaginative, needy etc. as these are all fundamental to our "intelligence" as humans.
Well, I'm afraid you may be right. And it's a variant of something that a few AI researchers have pointed out: There's no point to duplicating human intelligence. We have a perfectly good way of getting that already, and our problem is that we have an oversupply. What would be a more useful result would be machines that were intelligent in different ways than we are.
The usual parallel is with other machines. We have machines that fly. They don't duplicate birds or bats or insects; the useful flying machines do it in different ways that are more useful to humans. No flying creature can carry the tons of people or freight that the airlines do. Similarly, someone has pointed out that asking whether machines can think like we do is as pointless as asking whether a submarine can swim like a fish. Of course not; it "swims" in a manner that's more useful to us than a true fish mimic would be. Of course, airplanes and submarines have a superficial resemblance to birds and fish, for the simple engineering reason of efficient motion through the air and water. But the resemblance pretty much ends there, for very practical reasons. And on land, we have many kinds of vehicles that aren't mimics of horses or other beasts of burden; they're designed to have large capacity and higher speeds than the animals they (mostly) replaced. The fact that most of them are limited to roadways that we also build isn't a serious problem; we don't much need all-terrain vehicles for most of our purposes.
Similarly, we could argue that the AI computer researchers have had a great deal of success. Decades ago, we had machines that were capable of very fast arithmetic, and not much more. Now we have machines that are replacing many kinds of menial tasks that used to require human intelligence. It's true that they aren't very intelligent; they're doing a lot of "mindless" tasks that used to require a human mind, but now can be relegated to a machine. They do these tasks very fast, and don't get bored and sloppy like any semi-intelligent person does. This is a growing benefit to us, especially as it frees up many human minds for more "lofty" pursuits (while it introduces the social problems caused by a reduced need for uneducated human workers).
But we still have the problem that even these successes are disparaged by the people who consider themselves above all that geeky stuff. We see this in the current article, which lists AI as a total failure. In fact, the AI researchers are responsible for a fair number of technical advances in the software field. Software engineering depends on a lot of their developments for many things that used to be wild futuristic speculation, and now are extensive libraries for handling complex data structures. Many of their wild ideas are incorporated in our more advanced programming languages. That may not be success in creating a god-like machine intelligent, but it's not failure.
The most obvious counterexample to the "AI" nonsense is to consider that, back around 1800 or any time earlier, it was obvious to anyone that the ability to count and do arithmetic was a sign of intelligence. Not even smart animals like dogs or monkeys could add or subtract; only we smart humans could do that. Then those engineer types invented the adding machine. Were people amazed by the advent of intelligent machines? No; they simply reclassified adding and subtracting as "mechanical" actions that required no intelligence at all.
Fast forward to the computer age, and you see the same process over and over. As soon as something becomes routinely doable by a computer, it is no longer considered a sign of intelligence; it's a mere mechanical activity. Back in the 1960s, when the widely-used programming languages were Fortran and Cobol, the AI researchers were developing languages like LISP that could actually process free-form, variable-length lists. This promised to be the start of truly intelligent computers. By the early 1970s, however, list processing was taught in low-level programming courses and had become a routine part of the software developers toolkits. So it was just a "software engineering" tool, a mechanical activity that didn't require any machine intelligence.
Meanwhile, the AI researchers were developing more sophisticated "intelligent" data structures, such as tables that could associate arbitrary strings with each other. Did these lead to development of intelligent software? Well, now some of our common programming languages (perl, prolog, etc.) include such tables as basic data types, and the programmers use them routinely. But nobody considers the resulting software "intelligent"; it's merely more complex computer software, but basically still just as mechanical and unintelligent as the first adding machines.
So my prediction is that we'll never have Artificial Intelligence. Every new advance in that direction will always be reclassified from "intelligent" to "merely mechanical". When we have computer software composing best-selling music and writing best-selling novels or creating entire computer-generated movies from scratch, it will be obvious that such things are merely mechanical activities, requiring no actual intelligence.
Whether there will still be things that humans are intelligent enough to do, I can't predict.
Well, I am a bit confused. Plants do perspire and release water vapour but they also usually release heat (they have a metabolism and show on infrared).
It is a bit complicated. ;-)
It's true that plants give off IR radiation. But they also release water vapor, and the evaporation process is endothermic. This cools the plant tissues slightly, and conductance cools the air at the leaf surfaces. There's a lot of energy conversion and transfer going on around a functioning leaf. The "bottom line" of it all is that the air among masses of plant life is usually a few degrees cooler than the outside air, unless the air is cold, when the plants may somewhat warm the air. You can feel this when you walk into a clump of trees, even if you're still in the sunlight. Much of this effect is due to inefficiencies in the plants' techniques for controlling their own internal temperature.
It is interesting that plants can be giving off IR while being cooler than their surroundings. Part of the explanation is that the photosynthetic process involves a lot of frequency shifting. Photons are absorbed at one frequency, electrons bounce the absorbed energy around a bit, and another photon is radiated at a lower energy level. Most of this is significant to the plant's metabolism, but there are inefficiences. Thus, chlorophyll absorbs best in the green/blue part of the spectrum; a quick google found a graph at http://www.statemaster.com/encyclopedia/Chlorophyll. Note the complexity of the graph, with a lower peak in the red. To increase its absorbency, chloroplasts surround the chlorophyll with frequency-shifting molecules that absorb photons at other frequencies and reradiate the energy as photons that the chlorophyll prefers. But chlorophyll molecules don't intercept all these green/blue(/red) photons, explaining why leaves are greener than the incoming light. The whole process is impressively complex, and we're not very close to fully understanding it all. But much of the accidental reradiation is at low-energy frequencies, in the IR part of the spectrum.
Some interesting research reports a few years ago involved some tiny temperature sensors that could measure the temperature inside leaves. They reported that a wide variety of plants tested, over a wide range of atmospheric conditions, the internal leaf temperatures were close to 21 Celsius. This is somewhat cooler than our body temperature, and generally different from the air. The "higher" plants seem to have evolved some impressive temperature regulation methods, presumably because chemistry is simpler and cheaper if you can control the temperature. So at cooler temperatures, leaves tend to absorb lots of photons that they don't need for photosynthesis, but which function solely to warm the leaf to its operating temperature. The leakage from this process mostly loses low-energy photons, i.e., infrared. At higher temperatures, leaves can both radiate more energetic photons, and also release water vapor, which cools the tissues rapidly. In this case, most of the inefficiency is in heat absorbed from the surrounding warmer air, which is the main reason that clumps of plants are cool. But it's not really that the water was vaporized to cool the air. It was vaporized to cool the internal leaf tissues, and the air cooling is due to poor insulation at the leaf surface. The plants are trying to keep themselves at operating temperature, and cooling of surrounding warmer air is an inefficiency in this process.
Anyway, it's complex. And it's impressive how much control can be done by critters that have no muscles or nervous system and are stuck spending their whole life in one spot. It's almost entirely complex chemistry, including some very sophisticated control of photons and passing energy via electrons along chains of carbon atoms. Understanding what's known of it takes years of study. But you can find a lot of summaries by googling for someth
Dubious claims that sound scientific, but not made in a scientific journal, not peer reviewed and making 1st grade biology errors in the title, and you still think there is some truth in that article?
And to make it even sillier, the article is illustrated by a face (female, of course) sniffing three flowers from the Compositae family. The Sage (genus Salvia in the family Lamiaceae) and gardenia (genus Gardenia, family Rubiaceae) have flowers that are radically different from composite flowers.
I did especially like the claim that the gardenia "creates water vapor". Ex nihilo? If they release water vapor, that's pretty much what all leafy plants do as part of their normal metabolism. Of course, some are more wasteful of water than others, so maybe this gardenia has been selected to really squander its water. But, strictly speaking, the water vapor doesn't cool anything. The cooling happens when the water is converted to vapor, in or at the surface of the leaf. Anything else is cooled by the mixing of the air at the cool leaf surface with other air; entrained water vapor has no real effect on this. It might actually have the opposite effect, if the air is sufficiently moist to produce condensation, which will release a "heat of condensation" into whatever surface it condenses on, but this is generally a minor effect compared to the cooling from the leaf surfaces.
I'd wonder if there is a better description anywhere of what (if anything) they've developed. The story sounds like a typical mangling of a scientific report by publicists who don't understand any of the words. The fact that they'd illustrate it with flowers from a different family supports that inference.
In my opinion, the reason those apps do not exist is that consumers really only care about 4 apps at most, and that number is really reduced to one app in this day and age. There are plenty of things I am doing with free/open source software that are could not be done without spending a fortune on proprietary licensing, but they are things that consumers do not care about.
This is the history of much or our technology. New things are developed out of public sight, by people who want them for their own narrow purposes. Thus, most people would tell you that the World Wide Web was invented by Microsoft. In fact, it started of at CERN, a totally meaningless name to 99% of the Web's users, to make it easier for physicists to share their experimental data, research papers, etc. Outside of the geek community, hardly anyone has ever heard of Tim Berners-Lee, and he wouldn't make it onto any lists made by anyone not involved in Web development.
This is the norm. Last night I was at an event where I was approached by several people who told me how much they appreciate my web site and the things I've done for them. I won't mention the topic, because it's just one of many similar stories. This includes my usual explanation that I really did it for my own nefarious purposes. I'd found a growing number of sites that had data of a sort that I find useful. I made a sort of combined aggregator/index/search site, because I was annoyed with the time I was wasting trying to find things on those other sites, and decided "This is a job for the computer". I set it up as a web site so that I could use it anywhere that I had Net access. I mentioned it to a few colleagues, who mentioned it to a few others, and now it has between 5000 and 1000 hits most days. It's not a huge commercial thing, and probably never will be, but it's useful to a few tens of thousands of people (much less than 1% of the world's population).
Of the many such online development, most of them are free/open source because they have no obvious commercial potential. Eventually, a few may reach some sort of public notice. At that time, the commercial world will probably pick up on what has happened. A few corporate giants will to buy them out (or reverse engineer them) and commercialize them. This will probably include incorporating them into the big, monolithic apps that we're all familiar with. People will say how wonderful this new thing is that corporation X has invented. And they'll say that the Open Source stuff is still irrelevant, because it doesn't provide anything that people want.
These predictions are fairly easy, because it's how things have always been done. If you dig a bit, you can probably find examples in whatever area you're intimately familiar with.
The really glaring example is the "Windows" GUI that's been so much discussed here. Insiders know about the Xerox PARC project that started it all. But probably even most /. readers don't know about its origins, because they only know the decade-later version commercialized by Microsoft, and they judge everything else by how well it mimics this particular offshoot of the original project. This is, of course, a loser's game, since you can't possibly track a moving target whose future moves are secret. But it's likely that right now there are a few small projects underway that, in a few more years or decades, will suddenly appear in the public eye as a huge improvement, to be taken over by the corporate marketers and sold as their marvelous new development. But it won't be produced anyone trying to clone the current market leader.
Does the whole idea of "Open Source" has been kidnaped by the corporate *bs* and rebranded with a new background, meaning and of course, new corporate "heroes"?
Nah; it just means that the people who did this survey didn't bother talking to anyone who really knows what Open Source is or who might be influencing a lot of others right now. They talked to a bunch of top corporate management guys, who mostly have no knowledge of or interest in where their lowly workers are getting their ideas or tools. That's for the bean counters, y'know. To most of them, Open Source is a marketing phrase with growing positive connotations, and that's all they need to know about it.
Pretty much the same thing applies to the question of why there were no influential women in the results. Did they actually ask any female executives? (And have they verified that all those "foreign" names belong to males? ;-)
Actually, I wonder how this would work out if you asked the programmers. How many of you involved in programming actually know the sex of any of the authors of the software that you're downloading? Do you even care? I'm reasonably certain that Linus is male, but for most of the open source software that I have on my machine, I can't actually tell you much about the authors. Often I don't even recall their name, and would have to look it up in the code. I know I've seen feminine names there, but I haven't paid that much attention. I've also noticed a lot of foreign names that I can't assign to a sex.
Companies selling open source software is a Good Thing. It means the open source movement has been successful. How is it exploitation?
There's a difference?
(Actually, I did do a google "define:" check. The results were worded somewhat differently, but I couldn't pin down an actual difference in meaning. I do suspect that we're talking about different words used to "frame" an issue by different subcultures.)