Version control systems based on distributed repositories can be quite condusive to workflows viable in a commercial environment. At my workplace, for instance, we're considering using Arch with tla-pqm -- a "patch queue manager". Roughly, what this does is permit a developer to send a request "merge this patch and this patch from my personal branch into the central repository". PQM does the merge (throwing the developer an error if it doesn't -- in that case they need to update to the latest copy), and then runs a user-defined script to decide whether to go ahead; in our case, we'd be running a compile followed by a run of the automated test suite. Test suite passes? The developer's changes get committed. Test suite fails? Developer gets a nastygram.
Per-file locking can be done via a 3rd-party dedicated lock server tool -- no need to integrate into the source control system -- if one really needed it. As for the rest of it: Tagging off a new branch in Arch is exceedingly cheap (no, it doesn't involve making a whole new copy of the tree); indeed, its branching support is the best I've seen anywhere. I can't comment on darcs, but in Arch, at least, using a centrallized repository is in no way a prerequisite for cheap and intuitive branching support.
That's rather vague. What's better about Arch's core design?
Well, for instance, it actually can support things like history-sensitive merges without substantial rearchitecting. After RMS asked for a revision control system with digital signature support, Arch's design was flexible enough that it had a finished implementation while the SVN folks were still debating over how they wanted to implement it. Those are just examples, though.
If you want something a bit better, let me point you to a missive by Tom Lord (the Arch maintainer), entitled Diagnosing SVN, and a refutation by Greg Hudson, Undiagnosing SVN. Note in particular Greg's response to Tom's "under-developed notion of version control" claim.
Eh? Arch has been fully converted to C; its modern implementation, tla, uses a number of performance optimizations that simply couldn't be done in shell. There's a full separately maintained branch for Cygwin support that (I understand) works quite well, and TLA itself works great under WSU.
I disagree -- massively -- with the allegation that the "implementation suck[s]", or that Tom is in any way lacking clue. Perhaps you could ellaborate a bit on these statements? Or even put your name behind them?
(BTW, I once worked at a BitKeeper shop; not only did I have issues with frequent repository corruption [probably fixed by now, this was about 4 years ago], but LMV did all kinds of nasty things like changing the licensing such that our company, at the time a small startup, which was professionally writing OSS, no longer qualified for the free one).
It has basically the same functionality as CVS, but is based on a BerkeleyDB backend instead of a simple filesystem approach like CVS. This means, among many other things, that you can move files from directory to directory and rename them without orphaning them.
Bogus. GNU Arch is based on a filesystem-based repository as well, but can revision file moves, permissions, symlinks, and so forth.
Further, even if the Arch tools were to disappear tomorrow, I could still retrieve the contents of my files using tar, patch and similar tools -- something I can't do with a tool that backends into BerkeleyDB. (Yes, call me paranoid -- but I don't trust my source to big binary blobs managed by the same library that's destroyed my RPM database so many times). The repository format is write-once, so the files in the repository, once created, are never overwritten or modified as new history is added (unlike CVS's,v files or Subversion's database backend).
There are other reasons to prefer Arch as well, including distributed repository support, history-sensitive merge operators, and arguably superior core design.
Yes, I'm glad to look at SVN on its merits alone -- and while it's a huge improvement over CVS, I still find it lacking compared to the other modern revision control systems out there.
Heh -- having been on the Arch list for a while, I distinctly recall watching the feature requests from Linux kernel developers ("we need $THIS before we can migrate away from BitKeeper" sort of thing).
Their objections (other than performance, which has been dramatically improved lately) have been largely silly things, not related to the Arch core itself (which is most excellently designed; thanks Tom!), but rather mostly UI-type issues ("we want built-in a graphical 3-way merge tool!" type items).
That's the case for Arch, anyhow. As for the post you just mentioned, its objections to SVN happen to be things that either don't hinder Arch at all or should be non-issues altogether (ie. better solution available):
1. Equivalent to cvsup. Arch has this functionality built in, implicit in its mirroring and distributed support features.
2. Support for (user-supplied) keywords. The general consensus on the Arch list is that it's a bad idea for any revision control system to support this "feature" at all, and that there are better ways to do anything one could want them for.
3. Converting the repository -- cscvs, a tool I help to maintain, does just that.
[Yes, you hit the basics -- but the implicit per-file assumption a la CVS just hit my "rant" button... hopefully some of what I'm throwing out here is actually useful].
First, it tracks changes made to files in your source tree [...]
While CVS tracks changes made to individual _files_ in the source tree, some other revision control systems (ie. Arch, BitKeeper, etc) store changes to the tree state atomically. That is to say, if you have file1.c and file1.h and you make a change that touches both of them, you can bundle both those changes together into one atomic operation, so that they show up as just one changelog entry and that every developer who applies one of these changes always gets both of them.
In CVS, to know that file1.c version 1.13 and file1.h version 1.2 both belong in the same tree, you need to "tag" each file in the tree -- adding notation to the backend store for each individual file indicating that they both are tied to THIS_TAG_VERSION. In the case of a changeset-oriented system, on the other hand, the appropriate version of both files is just another element of the repository state -- so instead of a set of individual file states, you just have one big repository state that holds everything together.
This also makes updates very fast, since instead of checking for each file "is there an updated version of this file?" for each and every file in the repository, you can just check "are there new patches for this repository?" and download that.
There are other things one can reasonably expect of a modern revision control system, as well. For instance, a site using tla-pqm to manage their Arch repository can be set up such that only code which compiles and passes the unit tests can be merged into the primary repository; this is exceedingly good practice, especially on big teams.
Another nifty thing good revision control systems can do (well, some of them -- Subversion, for instance, lacks this) is distributed operation. For instance, this means you can make a branch of someone else's code stored on your own server, make revision-controlled changes on that server, and then ask them to merge your changes back into their branch -- without yourself having any access to their server at all! Distributed branching, in combination with good branch and merge operators, enable quite a lot of workflows that would otherwise be quite impractical. In terms of release-quality revision control systems, the only two that really have this support are Arch and BitKeeper (svk and darcs do something similar, but neither is exactly mature or in posession of a substantial userbase; that said, I think darcs is quite interesting from a research-project point of view).
By the way, I'm currently the maintainer of cscvs (a tool for building a SQLite database with inferred changeset information from analyzing a CVS repository's history, and then doing interesting things in it -- ranging from reporting to importing the archive into Arch), making me an interesting combination of "informed" and "biased" in this discussion. If you're interested in revision control and possibly interested in a continuation of this rant (or disagree with some part of it), please drop me an email.
Look at Arch. You can access your repository via WebDAV (and thus apache -- this time without any extra modules), or sftp, or ftp, or raw filesystem access, and adding more is as simple as adding a new backend to the pfs layer. I'm not sure how depending on WebDAV + a svn module for your server is supposed to be _more_ extensible.
Use Arch with a WebDAV backend, then all you need is a WebDAV account, not a UNIX account. Problem solved. (I've also seen tools for setting up sftp-only accounts and the like).
As per subject; looked into the tablets from Motion Computing? Okay, I don't know that they sell to consumers -- but we've been evaluating their tablets at work, and we're generally quite impressed. (We make medical software intended to be used from tablet PC hardware, and have been working on it quite some time -- actually, the company's first incarnation about 5 years ago had among its primary risk factors that nobody would have hardware akin to modern tablets on the market by the time our code was ready, which is happening right now).
Second choice is NEC's tablets -- they're light and have good battery life, but the accessories that come with them (stands and such) are cheap and of questionable quality, and they can't convert into a laptop form-factor. The Compaq tablets, like the Motion Computing ones, *are* convertable, but the Compaqs are relatively heavy.
If you're going to be running Linux, I'd look into FIC's Crusoe-based tablets. They gave us a few preproduction units, and we had nothing but trouble with them -- until we tried running Linux on one as a research project; its performance is dramatically better there than it was on Windows XP Tablet Edition! (Granted, it was a *prerelease* of WinXP Tablet; the whole reason we played with Linux on the system in the first place was that its OS had expired).
All that said, though, I'm with (most) everyone else here -- if you want to do the practical thing, get yourself a laptop.
[PS: In Austin? Good with Java, or an exceedingly excellent sysadmin with some system-level programming skills? Willing to work mostly for stock, at least for a while? Drop me a line].
it did all that automatically, i just ran apt-get update; apt-get upgrade; and came back about two hours later to find a metric assload of software gone.
dist-upgrade, maybe; upgrade never removes packages.
You guys had an opportunity to seperate yourselves from those who did it, and instead you all referred to them as litigous bastards.
Eh?
It's one thing to express an opinion that someone is a litigious bastard, and another thing to set off a bomb in their front yard (and damage the innocent neighbors as well). Just because we're, as a group, willing and happy to make a public statement to the effect that we dislike SCO isn't to say that we're willing to, as a group, support some illegal and destructive action against them -- particularly one with collateral damage on the scale that MyDoom has caused, and most particularly one which distributes a payload helpful towards spammers and crackers (whom, as a rule, we hate).
If the only thing in question here were a DOS of SCO, then sure, you'd be reasonable to say in public that there's reason to believe that one of our members is most likely at fault (though not that the community necessarily supports such an action; indeed, in all the prior DOS attacks, the general impression was that much more harm than good was done via giving Darl and company more to talk about). As for the impression that the only thing in question is a DOS, though -- that's not the case, and pretending that it is is simply irresponsible.
God you are slow. My whole point was that computer manufacturing and sales are no longer IBM's core businesses either. They are primarily a services company now
I think the point he's attempting to make is that services can be legitimately part of a "computer company"'s business. It's not as if IBM's services division is off doing janitorial work.
If one was saying "computer manufacturer", that'd be different; "computer company" is more general.
Err, actually, it is. Remember, this is a governmental organization; there's quite a bit of left hand/right hand disconnect.
I could see it being true for DARPA, but then, if they were really interested in improving the information security of the U.S., then why renege on the grants/funding for OpenBSD, an OS that is frequently reputed to be one of the--if not the most--secure OS's out there?
Eh? So they fund something for a while, and then they stop, and from this you infer that the thing that they were once funding is contrary to their mission? There are lots of possible reasons for the change in funding decisions; perhaps you should look for publicly available transcripts rather than engaging in unfounded speculation.
And people accuse me of wearing a tin-foil hat. Jeesh.
The question you should be asking yourself is why organizations like the NSA and DARPA, which are after all dedicated to eavesdropping and intelligence gathering, would want to spend time and resources making the computer systems of target nations more secure.
Perhaps because their mission also includes improving the information security of their own nation?
What this comes down to is that you claim to believe that I might as well be a computer program. My argument is that I don't think you actually believe this to be true, except perhaps as an intellectual excercise of sorts.
I consider it unlikely as a practical matter -- because programs with the appropriate level of sophistication are unavailable at present -- but that's by no means disbelief. Certainly, I'll grant that embodiment implies a certain set of experiences and consequently a different outlook than an unembodied intelligence would have -- but then, an embodied AI is itself entirely feasible, and I never specified "human" -- merely "intelligent" and as capable of experiencing qualia as you or I.
Similar in many regards to '99% of Scientologists.'
What's your point?
Public perception of "99% of scientologists" is that they're, at worst, dupes; it's only the small subset that does things like filing annoying lawsuits that raises the public ire.
It's all in the eye of the beholder. I would hazard to say most spammers don't think they're doing anybody any harm, either.
The "beholder" -- not the beholdee. How the spammers, or the scientologists, or the commies percieve themselves is irrelevant. How the people they directly interact with perceive them is far more important.
Most commies don't annoy or harm most people who interact with them most of the time; neither do most scientologists. In the case of spammers, however, the bulk of transactions they have with other people are transactions which result in annoyance on the part of the involved 3rd party.
For this reason, comparing spammers to commies or scientologists is simply inappropriate. (I also notice that you're sidestepping my counterarguments re the "scapegoat" allegation).
99%+ of "commies" actually did nothing at all to harm anyone, and indeed were folks seeking a peaceful transition to an improved political system. 100% of spammers do plenty to harm (or, at least, annoy) everyone; they wouldn't be spammers if they didn't. For this reason, the comparison you draw is bogus at best.
They make handy scapegoats and excellent targets for the daily 'five minute hate' rally.
The only things I've heard spammers get blamed for are spam (abviously) and direct effects thereof, and viruses clearly written with the intent of aiding spam. The former is obvious, and the latter is exceedingly plausible. Face it -- yer average virus writer hates spam as much as anyone else; you wouldn't be seeing spam-enabling virii unless someone were paying for it.
Just my making this comment will get people perking up and saying to themselves (and possibly openly in this forum) 'hmmm, so you're a spammer sympathizer, eh?' That should mean something.
That you're paranoid and/or full of yourself? I can't say I care what you think about spammers. I do care if you happen to spam me, but that's an entirely separate issue.
It all starts from awareness; not the other way around.
A matter of opinion. There's another school of thought to the effect that qualia is simply a side effect of qualifying physical processes; this happens to be the one that I subscribe to. (As for determining which physical processes qualify, what mechanism do we have other than observing behaviour to attempt inference? This is why I believe in the Turing test and its equivalents).
Why is human intelligence necessarily real, and artificial intelligence necessarily fake?
I never made this claim.
Quite right, you didn't -- it was the AC that started this subthread who said something to that effect. My apologies for presuming that you agree with his/her/its position.
It's completely irrelevant. We (us humans) don't distinguish paintings from photographs because we were "exposed to a set of rules", we do it because it gives meaning to our world.
Bullshit. Maybe if you were talking about appreciating the artistic value of paintings and/or photographs, your dodge might at least try to have some merit; as it is, however, it's nothing but utter irrelevancy itself.
That said: Perhaps I should replace "paintings" and "photographs" with objects having a bit less emotional charge. How do we, as humans, distinguish between tables and chairs? Well, we've been exposed to tables, and we've been exposed to chairs, and we've internally formulated a set of criteria that distinguish between the two. Generally speaking, our brains are composed of neurons which tend to fire if a specific set of conditions are met -- there might be one that fires if it observes a horizontal line in the upper left hand corner of your field of vision, another that fires if it observes movement in that same area, another that fires if it detects a given color there. These in turn are connected to additional neurons, which adjust their levels of neurochemicals in play (and thus their liklihood of firing in turn) based on the messages received; the "weightings" assigned to each connection (ie. whether firing becomes more or less likely should a message come in on that connection) are adjusted via feedback occuring during the learning process; repeat through several additional layers. The end result of this is that there tend to be specific sets of neurons that have connections such that they trigger on tables but not on chairs, and vice-versa.
This learning process (of adjusted neural connection weights) is also how modern artificial neural networks (ANNs) operate. [Actually, what I just described is simplified in mostly the same ways ANNs are; I only took one semester of brain physiology, but 3 of them on AI]. Humans learn to distinguish between paintings and photographs the same way we learn anything else -- because of feedback adjusting connection weightings between neurons. ANNs, likewise, learn the same way.
So, once again: Why is human intelligence necessarily real, and artificial intelligence necessarily fake?
The rules are implicit in the selection of the test sets.
The set of rules a human uses to make that same distinction is based on the photographs and paintings which he or she has been exposed to. Would you say that a human is capable of distinguishing between photographs and paintings because he or she has been given a set of rules to use in doing so?
What you're saying right now is that Johnny the bodybuilder would make a good forklift -- it's completely backwards.
Eh? I'm not sure that I follow, and I'm even less sure how this addresses the distinction between "fake" and "real" intelligence.
Note that I specified other humans. As in, people who aren't you. No fair using introspection!
After all: Sure, you're experiencing qualia -- but can you prove that I am, or am not? If you're unable to make this proof for me, why propose that you could do so for an AI?
Sorry, man, but I just can't see the hole that this (supposedly) points out. If his behaviour is consistant with it being good for him, then so it was; likewise for her. What's the point of this joke, again?
Slashdot Mirror
Version control systems based on distributed repositories can be quite condusive to workflows viable in a commercial environment. At my workplace, for instance, we're considering using Arch with tla-pqm -- a "patch queue manager". Roughly, what this does is permit a developer to send a request "merge this patch and this patch from my personal branch into the central repository". PQM does the merge (throwing the developer an error if it doesn't -- in that case they need to update to the latest copy), and then runs a user-defined script to decide whether to go ahead; in our case, we'd be running a compile followed by a run of the automated test suite. Test suite passes? The developer's changes get committed. Test suite fails? Developer gets a nastygram.
Per-file locking can be done via a 3rd-party dedicated lock server tool -- no need to integrate into the source control system -- if one really needed it. As for the rest of it: Tagging off a new branch in Arch is exceedingly cheap (no, it doesn't involve making a whole new copy of the tree); indeed, its branching support is the best I've seen anywhere. I can't comment on darcs, but in Arch, at least, using a centrallized repository is in no way a prerequisite for cheap and intuitive branching support.
That's rather vague. What's better about Arch's core design?
Well, for instance, it actually can support things like history-sensitive merges without substantial rearchitecting. After RMS asked for a revision control system with digital signature support, Arch's design was flexible enough that it had a finished implementation while the SVN folks were still debating over how they wanted to implement it. Those are just examples, though.
If you want something a bit better, let me point you to a missive by Tom Lord (the Arch maintainer), entitled Diagnosing SVN, and a refutation by Greg Hudson, Undiagnosing SVN. Note in particular Greg's response to Tom's "under-developed notion of version control" claim.
Eh? Arch has been fully converted to C; its modern implementation, tla, uses a number of performance optimizations that simply couldn't be done in shell. There's a full separately maintained branch for Cygwin support that (I understand) works quite well, and TLA itself works great under WSU.
I disagree -- massively -- with the allegation that the "implementation suck[s]", or that Tom is in any way lacking clue. Perhaps you could ellaborate a bit on these statements? Or even put your name behind them?
(BTW, I once worked at a BitKeeper shop; not only did I have issues with frequent repository corruption [probably fixed by now, this was about 4 years ago], but LMV did all kinds of nasty things like changing the licensing such that our company, at the time a small startup, which was professionally writing OSS, no longer qualified for the free one).
It has basically the same functionality as CVS, but is based on a BerkeleyDB backend instead of a simple filesystem approach like CVS. This means, among many other things, that you can move files from directory to directory and rename them without orphaning them.
,v files or Subversion's database backend).
Bogus. GNU Arch is based on a filesystem-based repository as well, but can revision file moves, permissions, symlinks, and so forth.
Further, even if the Arch tools were to disappear tomorrow, I could still retrieve the contents of my files using tar, patch and similar tools -- something I can't do with a tool that backends into BerkeleyDB. (Yes, call me paranoid -- but I don't trust my source to big binary blobs managed by the same library that's destroyed my RPM database so many times). The repository format is write-once, so the files in the repository, once created, are never overwritten or modified as new history is added (unlike CVS's
There are other reasons to prefer Arch as well, including distributed repository support, history-sensitive merge operators, and arguably superior core design.
Yes, I'm glad to look at SVN on its merits alone -- and while it's a huge improvement over CVS, I still find it lacking compared to the other modern revision control systems out there.
If you're looking at switching to a more modern RCS, please consider Arch as well.
Heh -- having been on the Arch list for a while, I distinctly recall watching the feature requests from Linux kernel developers ("we need $THIS before we can migrate away from BitKeeper" sort of thing).
Their objections (other than performance, which has been dramatically improved lately) have been largely silly things, not related to the Arch core itself (which is most excellently designed; thanks Tom!), but rather mostly UI-type issues ("we want built-in a graphical 3-way merge tool!" type items).
That's the case for Arch, anyhow. As for the post you just mentioned, its objections to SVN happen to be things that either don't hinder Arch at all or should be non-issues altogether (ie. better solution available):
1. Equivalent to cvsup. Arch has this functionality built in, implicit in its mirroring and distributed support features.
2. Support for (user-supplied) keywords. The general consensus on the Arch list is that it's a bad idea for any revision control system to support this "feature" at all, and that there are better ways to do anything one could want them for.
3. Converting the repository -- cscvs, a tool I help to maintain, does just that.
First, it tracks changes made to files in your source tree [...]
While CVS tracks changes made to individual _files_ in the source tree, some other revision control systems (ie. Arch, BitKeeper, etc) store changes to the tree state atomically. That is to say, if you have file1.c and file1.h and you make a change that touches both of them, you can bundle both those changes together into one atomic operation, so that they show up as just one changelog entry and that every developer who applies one of these changes always gets both of them.
In CVS, to know that file1.c version 1.13 and file1.h version 1.2 both belong in the same tree, you need to "tag" each file in the tree -- adding notation to the backend store for each individual file indicating that they both are tied to THIS_TAG_VERSION. In the case of a changeset-oriented system, on the other hand, the appropriate version of both files is just another element of the repository state -- so instead of a set of individual file states, you just have one big repository state that holds everything together.
This also makes updates very fast, since instead of checking for each file "is there an updated version of this file?" for each and every file in the repository, you can just check "are there new patches for this repository?" and download that.
There are other things one can reasonably expect of a modern revision control system, as well. For instance, a site using tla-pqm to manage their Arch repository can be set up such that only code which compiles and passes the unit tests can be merged into the primary repository; this is exceedingly good practice, especially on big teams.
Another nifty thing good revision control systems can do (well, some of them -- Subversion, for instance, lacks this) is distributed operation. For instance, this means you can make a branch of someone else's code stored on your own server, make revision-controlled changes on that server, and then ask them to merge your changes back into their branch -- without yourself having any access to their server at all! Distributed branching, in combination with good branch and merge operators, enable quite a lot of workflows that would otherwise be quite impractical. In terms of release-quality revision control systems, the only two that really have this support are Arch and BitKeeper (svk and darcs do something similar, but neither is exactly mature or in posession of a substantial userbase; that said, I think darcs is quite interesting from a research-project point of view).
By the way, I'm currently the maintainer of cscvs (a tool for building a SQLite database with inferred changeset information from analyzing a CVS repository's history, and then doing interesting things in it -- ranging from reporting to importing the archive into Arch), making me an interesting combination of "informed" and "biased" in this discussion. If you're interested in revision control and possibly interested in a continuation of this rant (or disagree with some part of it), please drop me an email.
More extensible? Bah!
Look at Arch. You can access your repository via WebDAV (and thus apache -- this time without any extra modules), or sftp, or ftp, or raw filesystem access, and adding more is as simple as adding a new backend to the pfs layer. I'm not sure how depending on WebDAV + a svn module for your server is supposed to be _more_ extensible.
Use Arch with a WebDAV backend, then all you need is a WebDAV account, not a UNIX account. Problem solved. (I've also seen tools for setting up sftp-only accounts and the like).
As per subject; looked into the tablets from Motion Computing? Okay, I don't know that they sell to consumers -- but we've been evaluating their tablets at work, and we're generally quite impressed. (We make medical software intended to be used from tablet PC hardware, and have been working on it quite some time -- actually, the company's first incarnation about 5 years ago had among its primary risk factors that nobody would have hardware akin to modern tablets on the market by the time our code was ready, which is happening right now).
Second choice is NEC's tablets -- they're light and have good battery life, but the accessories that come with them (stands and such) are cheap and of questionable quality, and they can't convert into a laptop form-factor. The Compaq tablets, like the Motion Computing ones, *are* convertable, but the Compaqs are relatively heavy.
If you're going to be running Linux, I'd look into FIC's Crusoe-based tablets. They gave us a few preproduction units, and we had nothing but trouble with them -- until we tried running Linux on one as a research project; its performance is dramatically better there than it was on Windows XP Tablet Edition! (Granted, it was a *prerelease* of WinXP Tablet; the whole reason we played with Linux on the system in the first place was that its OS had expired).
All that said, though, I'm with (most) everyone else here -- if you want to do the practical thing, get yourself a laptop.
[PS: In Austin? Good with Java, or an exceedingly excellent sysadmin with some system-level programming skills? Willing to work mostly for stock, at least for a while? Drop me a line].
it did all that automatically, i just ran apt-get update; apt-get upgrade; and came back about two hours later to find a metric assload of software gone.
dist-upgrade, maybe; upgrade never removes packages.
You guys had an opportunity to seperate yourselves from those who did it, and instead you all referred to them as litigous bastards.
Eh?
It's one thing to express an opinion that someone is a litigious bastard, and another thing to set off a bomb in their front yard (and damage the innocent neighbors as well). Just because we're, as a group, willing and happy to make a public statement to the effect that we dislike SCO isn't to say that we're willing to, as a group, support some illegal and destructive action against them -- particularly one with collateral damage on the scale that MyDoom has caused, and most particularly one which distributes a payload helpful towards spammers and crackers (whom, as a rule, we hate).
If the only thing in question here were a DOS of SCO, then sure, you'd be reasonable to say in public that there's reason to believe that one of our members is most likely at fault (though not that the community necessarily supports such an action; indeed, in all the prior DOS attacks, the general impression was that much more harm than good was done via giving Darl and company more to talk about). As for the impression that the only thing in question is a DOS, though -- that's not the case, and pretending that it is is simply irresponsible.
God you are slow. My whole point was that computer manufacturing and sales are no longer IBM's core businesses either. They are primarily a services company now
I think the point he's attempting to make is that services can be legitimately part of a "computer company"'s business. It's not as if IBM's services division is off doing janitorial work.
If one was saying "computer manufacturer", that'd be different; "computer company" is more general.
Well obviously that isn't true for the NSA.
Err, actually, it is. Remember, this is a governmental organization; there's quite a bit of left hand/right hand disconnect.
I could see it being true for DARPA, but then, if they were really interested in improving the information security of the U.S., then why renege on the grants/funding for OpenBSD, an OS that is frequently reputed to be one of the--if not the most--secure OS's out there?
Eh? So they fund something for a while, and then they stop, and from this you infer that the thing that they were once funding is contrary to their mission? There are lots of possible reasons for the change in funding decisions; perhaps you should look for publicly available transcripts rather than engaging in unfounded speculation.
And people accuse me of wearing a tin-foil hat. Jeesh.
The question you should be asking yourself is why organizations like the NSA and DARPA, which are after all dedicated to eavesdropping and intelligence gathering, would want to spend time and resources making the computer systems of target nations more secure.
Perhaps because their mission also includes improving the information security of their own nation?
What this comes down to is that you claim to believe that I might as well be a computer program. My argument is that I don't think you actually believe this to be true, except perhaps as an intellectual excercise of sorts.
I consider it unlikely as a practical matter -- because programs with the appropriate level of sophistication are unavailable at present -- but that's by no means disbelief. Certainly, I'll grant that embodiment implies a certain set of experiences and consequently a different outlook than an unembodied intelligence would have -- but then, an embodied AI is itself entirely feasible, and I never specified "human" -- merely "intelligent" and as capable of experiencing qualia as you or I.
because it denies the experience of everyday life
Eh? How so?
Similar in many regards to '99% of Scientologists.'
What's your point?
Public perception of "99% of scientologists" is that they're, at worst, dupes; it's only the small subset that does things like filing annoying lawsuits that raises the public ire.
It's all in the eye of the beholder. I would hazard to say most spammers don't think they're doing anybody any harm, either.
The "beholder" -- not the beholdee. How the spammers, or the scientologists, or the commies percieve themselves is irrelevant. How the people they directly interact with perceive them is far more important.
Most commies don't annoy or harm most people who interact with them most of the time; neither do most scientologists. In the case of spammers, however, the bulk of transactions they have with other people are transactions which result in annoyance on the part of the involved 3rd party.
For this reason, comparing spammers to commies or scientologists is simply inappropriate. (I also notice that you're sidestepping my counterarguments re the "scapegoat" allegation).
The only things I've heard spammers get blamed for are spam (abviously) and direct effects thereof, and viruses clearly written with the intent of aiding spam. The former is obvious, and the latter is exceedingly plausible. Face it -- yer average virus writer hates spam as much as anyone else; you wouldn't be seeing spam-enabling virii unless someone were paying for it.
That you're paranoid and/or full of yourself? I can't say I care what you think about spammers. I do care if you happen to spam me, but that's an entirely separate issue.
Quite right, you didn't -- it was the AC that started this subthread who said something to that effect. My apologies for presuming that you agree with his/her/its position.
It's completely irrelevant. We (us humans) don't distinguish paintings from photographs because we were "exposed to a set of rules", we do it because it gives meaning to our world.
Bullshit. Maybe if you were talking about appreciating the artistic value of paintings and/or photographs, your dodge might at least try to have some merit; as it is, however, it's nothing but utter irrelevancy itself.
That said: Perhaps I should replace "paintings" and "photographs" with objects having a bit less emotional charge. How do we, as humans, distinguish between tables and chairs? Well, we've been exposed to tables, and we've been exposed to chairs, and we've internally formulated a set of criteria that distinguish between the two. Generally speaking, our brains are composed of neurons which tend to fire if a specific set of conditions are met -- there might be one that fires if it observes a horizontal line in the upper left hand corner of your field of vision, another that fires if it observes movement in that same area, another that fires if it detects a given color there. These in turn are connected to additional neurons, which adjust their levels of neurochemicals in play (and thus their liklihood of firing in turn) based on the messages received; the "weightings" assigned to each connection (ie. whether firing becomes more or less likely should a message come in on that connection) are adjusted via feedback occuring during the learning process; repeat through several additional layers. The end result of this is that there tend to be specific sets of neurons that have connections such that they trigger on tables but not on chairs, and vice-versa.
This learning process (of adjusted neural connection weights) is also how modern artificial neural networks (ANNs) operate. [Actually, what I just described is simplified in mostly the same ways ANNs are; I only took one semester of brain physiology, but 3 of them on AI]. Humans learn to distinguish between paintings and photographs the same way we learn anything else -- because of feedback adjusting connection weightings between neurons. ANNs, likewise, learn the same way.
So, once again: Why is human intelligence necessarily real, and artificial intelligence necessarily fake?
Huh?
The most likely event (I believe, and I think Bruce agrees) is not a conspiracy but just a spammer trying to deflect some blame.
Since when did that have anything to do with paranoia?
to stop cross contamination
You mean "to prevent unauthorized use", right?
Preventing cross-contamination is just a handy side effect.
The rules are implicit in the selection of the test sets.
The set of rules a human uses to make that same distinction is based on the photographs and paintings which he or she has been exposed to. Would you say that a human is capable of distinguishing between photographs and paintings because he or she has been given a set of rules to use in doing so?
What you're saying right now is that Johnny the bodybuilder would make a good forklift -- it's completely backwards.
Eh? I'm not sure that I follow, and I'm even less sure how this addresses the distinction between "fake" and "real" intelligence.
Note that I specified other humans. As in, people who aren't you. No fair using introspection!
After all: Sure, you're experiencing qualia -- but can you prove that I am, or am not? If you're unable to make this proof for me, why propose that you could do so for an AI?
Sorry, man, but I just can't see the hole that this (supposedly) points out. If his behaviour is consistant with it being good for him, then so it was; likewise for her. What's the point of this joke, again?