Simulating something is faking, the way I see it is impossible to program true emotions.
Look at a neural network which has been trained (to take a trivial example) to distinguish between paintings and photographs. NNs learn by example -- nobody "tought" the system a set of rules for distinguishing between one and the other, and it's typically damn near impossible to determine how one works after it's set itself up -- but that doesn't mean it can't make the distinction just fine. Likewise, simply because a machine is capable of creating art doesn't mean that some human necessarily sat down to "program human emotions". With humans, art is (arguably) an emergent effect; these happen in other complex iterative systems, many of which can occur inside a computer as well.
Finally, I disagree that "simulating something is faking". A system which perfectly simulates intelligence is for all intents and purposes intelligent; arguing that its intelligence is nothing but a sham may make you feel better as an intellectual exercise, but makes the (hypothetical) machine no less capable of providing its opinions on Shakespeare.
Eh? A PDA is generally considered to be a (large) embedded device; a smart phone is no doubt likewise.
Smart phones are [...] shrunken multi-function devices.
Granted -- so we're certainly far enough out of the 100K range that Linux is no longer utterly infeasible, but that doesn't mean that battery life and production cost stop being important factors.
Certainly, there are folks who are willing to give up battery life and pay a bit more for snazzy features, and maybe an OS that makes coding those features easier at the expense of hardware cost and battery life makes some level of sense there. That said, it's foolish to expect that the engineering staff working on designing such devices will forget about those factors altogether. People with more interest in practicality than the ability to show off their gadgets at parties do, and will continue to, make their purchasing decisions based on low price and long life rather than the developers' ability to get a few more nifty features crammed in.
I happen to know some very skilled embedded systems developers, and at least one (also a Linux kernel maintainer) recently lost a possible contract with a very large multinational company because Linux turned out to be too large for the environment they wanted to run it in.
Hopefully VSTa or a like open operating system better suited to very small environments (eCos? dunno) will become practical and popular for such usage. Linux is reasonable in larger embedded systems -- networking hardware and the like -- but its suitability becomes less and less as space constraints constrict (think 100K of RAM or less). Remember, it's not just the cost of the OS that's an issue -- the cost of the extra hardware to run it, and the loss of battery life, is also a dealbreaker.
So no, I'm not convinced by this report; the summary makes it look too much like something concocted by talking to managers with insufficient engineering input.
I've done my time in a "philosophy of AI" class -- and frankly, as far as I'm concerned, the Chinese Room argument and the like are bogus. If it looks like a duck, walks like a duck, quacks like a duck -- it's a duck, at least until someone finds out that it doesn't in fact keel over when given cyanide-laced bread and has to plug itself in to charge its batteries every so often.
Consider: For the purposes of this thread, AI is considered incomplete due to inability to simulate emotions why? Because it's argued that the desired output (emotionally-charged vocalization) is impossible without a precondition which is argued to be impossible. If the output were indeed achieved, then for the purpose of its singing, would the system not for all intents and purposes be emotional, even if one is unable to demonstrate that the system actually experiences qualia? (After all, if we're unable to make this demonstration wrt other humans, why make it a requirement for nonhuman intelligence?)
Granted, I also think that a machine which can pass an unrestricted Turing Test over an extended period can be safely be considered capable of thought, so it's obvious which side of this debate I land on.:)
Or maybe you should rethink your earlier statement about only "crappy" and "broken" applications needing to be explicitly certified on a particular browser. To criticize people and organizations who are going out of their way to invest in supporting platforms with miniscule market share doesn't really help your cause of standards promotion.
When the application is core enough to ones' customers that they'd gladly install the appropriate platform to be able to use it -- and when the platform is licensed in such a way that it could freely be installed as just another component or dependency by the application -- I'm not sure this argument is particularly appropriate or sensible.
Yup. And that would be true, too, if it weren't for the letter of understanding to the contrary; see Exhibit C from here:
"3. Regarding Section 2.01, we agree that modifications and derivative works prepared by or for you are owned by you. However, ownership of any portion or portions of SOFTWARE PRODUCTS included in any such modification or derivative work remains with us."
This makes it pretty darned clear that IBM does in fact own their own "modifications and derivative works", which covers JFS and all the other features IBM added to AIX (and later Linux).
Re:Yes, but measuring webserver market share is ha
on
2003: Year of Apache
·
· Score: 1
I would disagree. The number of easy-to-publish tools (webfolders, frontPage, etc) for IIS makes it far more lucrative for Windows folks.
Web folders are nothing but WebDAV -- nothing there that Apache won't do. At my workplace, we use a Plone-based system for content management on our intranet, running on top of Apache, and the Windows users (which is most of the tech writing and graphics teams) seem quite happy with it.
Granted, I haven't tried Tomcat 5.0 -- but as of 4.1.29, Apache HTTPD whoops its ass serving static content (over SSL, anyhow). Moreover, Tomcat just doesn't have the flexibility provided by the vast numbers of modules available for Apache httpd -- meaning less flexibility (sans hoop-jumping) in authentication, header rewriting, integration with 3rd-party components, etc etc etc.
Tomcat is fine -- as a *backend* servlet container -- but it's not really a serious competitor for Apache httpd for those with more serious requirements. (In cases where an extra layer is undesirable, I'm pondering looking into using Jetty, but haven't done more than toy with it yet).
Never had any trouble with my (IBM) microdrive over the past year-and-a-half -- and it's been dropped at least a few times within that period. (Thankfully, it's not been in my camera on any of those occasions).
I don't know how the legality of the system works, but you can sue people for breach of contract and such here, I do not know if you can do that with overseas contractors, is it more of a "buyer beware" methodology?
International legal battles can be done (though only if the amount in contention is over a certain minimum), but it's very, very expensive.
Actually, my previous supervisor (and the best damn manager I've ever had the privilege to work with) left the company a bit ago, so if I still needed a reference from her, I suppose that I could get one now.
That said, while she was employed by the company, they were quite firm about disallowing even personal references, and she (and everyone upward in the chain) was quite firm about following the rule. One poster here mentioned a company (Cisco?) where managers' contracts specify enforcement of the no-personal-references rule, and breaking it is grounds for not only dismissal but a breach-of-contract suit; perhaps they did something like that (though I don't recall anything about managerial types being asked to sign new contracts as part of the Corporate Stuffiness campaign, it wouldn't suprise me a bit if they did).
In any event -- the ask-for-a-personal-reference thing was tried, and turned down, and the other ex-MVistans I talked to had a similar experience.
I'm not going to defend the others, because I don't particularly like them either, but let me throw in a word or two about Arch here:
The interface to Arch is only unintuitive until one's played with it enough, or crawled inside Tom's head for a bit. Given this effort, Arch just Makes Sense -- quite a lot of the interface reflects the underlying implementation concepts and such quite cleanly.
Further, the "extra steps" argument is less true than it used to be. For instance, tla 1.1's archive-setup command makes into a single step what used to be a 3-step process (creating a new category, branch and version in the archive for a fresh project or branch), and star-merge has a syntax that's vastly simplified.
Tom has played around with the idea of writing "itla" -- an interactive client for TLA -- or overarch (a tool for writing project-specific arch scripts). In the meantime, though, there are a fair number of 3rd-party frontends available -- I don't use any of them, but Samium Gromoff has been actively looking for user feedback on "tlator", so it's probably a good place to start.
A full build of a sample project with CVS takes me 30 seconds. CC takes 7 min, 30 sec.
Checking out a repository with a server-side cachrev is, in Arch, as fast as downloading and unpacking a tarball of the project over $CHOSEN_TRANSPORT (say, http). Creating a working directory of a repository with a client-side revision library is, with all the optimizations turned on, as fast as creating a hardlink tree shadowing the revision library's tree. (Of course, this needs to be done with your editor set to break hardlinks -- all the major ones do -- and Arch will detect it should a file in the revision library be modified without breaking the hardlink by mistake).
Doing an update in a tree where one file has changed is a simple as downloading the single changeset -- unlike CVS, where the status of every single file needs to be queried to find the one that's altered. In a 30,000-file tree, this is a major performance improvement.
CVS doesn't need multi-site repositories, clearcase does if you have a lot of remote development.
Bah -- neither CVS nor ClearCase can really scale.
For an example of my "CVS can't scale" assertion in action, just look at the pains SourceForge has had to go through, and oppose that to a system like Arch (where the repositories can be served over a completely unmodified web server using standard HTTP load-balancers, multi-layer distributed caching and all the other techniques used by high-volume web sites serving static content).
CVS has better add-on GUI tools for branching
Arch doesn't need GUI add-on tools for branching -- indeed, the ease and power of its branching and merging operators is one of the things that best recommends it.
CVS may be adequate version control for those with few needs -- but by no means is it "great". See my other post for more on that.
90% of projects do not use what CVS has to offer (scripting to check commits and log messages, vendor branches etc), so all the posts complaining about CVS lacking features compared with other newer version control systems are moot.
I disagree. The reason folks don't CVS's advanced features much is because they suck.
No, really. Take a look at branches. They'd be exceedingly useful if they just worked right -- but half the time in CVS they're more trouble than they're worth (because merging's so difficult, branches do weird things like make files added on the branch suddenly show up in HEAD, someone always ends up checking things in on the branch that belong in HEAD or vice-versa, etc) so half the time people who would otherwise use a branch just decide to do without. That's not necessarily a conscious decision -- if you think of branching as difficult and error-prone, it's not going to come to you naturally as the appropriate thing to do as often as it would if you thought of it as trivial.
In Arch, where branches Just Work, everyone uses them -- not just that, but folks who are making their own branch off someone else's arch repository and then merges newer changes from the parent are doing the same thing a CVS user would perform with never-used "vendor branch support" -- except in Arch, these "vendor branches" are actually useful.
If you argue that the failure of CVS's advanted features to actually be worthwhile implies that users have no need of the advanced features of other revision control systems -- why do folks on Arch actually make use of automated changelog generation, intelligent merge operators, or cryptographically signed archives?
Because, to put it briefly, these features are, as implemented by Arch, easily understood, readily available, and useful with few caveats -- something which can't be said regarding much of CVS.
You just hit on a weak point there -- Cygwin won't run Arch correctly on complex repositories until some fixes to support long filenames (by using the Win32 unicode file management API) are in.
Such a patch has already been written, but its contribution is being held up by legal issues (the author did it on company time, and he needs to jump through a bunch of hoops before his employer will agree to transfer copyright).
Presumably Tom could work on writing support for the filesystem abstraction layer and such to support Windows natively -- but until the available copies of tar and such cope gracefully with very long filenames, arch will still be broken on Windows.
Nope -- the policy prohibits personal references too. Of course, the other engineers were happy to ignore it -- but when someone wanted a reference from a manager, they were out (or rather, I was) of luck.
Past employers can be a liability even if they've got a positive reputation, if they refuse to say anything about you -- indeed, such a refusal can be misconstrued as covering ones' ass rather than telling the truth about an incompetant or otherwise unworthy employee.
I spent almost 3 years working at MontaVista Software, having started off there as an intern in college. I did damned good work, porting more than 3x the number of packages slated for my team during my first three months there, and coming up with some innovated automated testing tools later on in my employment. During my last year there, as part of the Corporate Stuffiness effort, a new policy went up: No references to former employees. Not good references, not bad references, nothing. Any queries would be sent to HR, which would confirm dates of employment and last position held.
So: I decide that I've had enough of the Bay Area and move to Texas; MontaVista decides they don't need the management overhead of an additional remote employee and lets me go. When trying to find new work (halfway across the country in a city where I had no contacts), the refusal to give out references hurt. A lot.
Which is not to say that there's no happy ending. I'm now employed at an underfunded, understaffed startup making some really amazingly neat software going out for a first release in the very near future. (Live in Austin? Good with Java? Willing to work mostly for stock? Demangle my email address and get in touch).
Re versioning directory structures: If I rename the directory "a" to be called "b", and do a commit, I want people who do an update to suddenly have "a" renamed to "b" -- with all their local changes still intact. Subversion does it, Arch does it, CVS won't.
With atomic commits: I change 3 files. I want do a single commit that makes these 3 files part of one atomic change. If someone does an update and gets one of these, I want them to get all of them. (Say they're a change to a method description in a header, a change to the C file implementing that method, and a change to another file calling it -- if someone does an update and only gets one of the 3 they always have a broken tree; they should have all or none). CVS won't do that; Subversion will, Arch will.
See my other post for a bit more on why modern revision control systems are more useful.
My guess is that Arch is even less mature than Subversion though, since it appears to have not been around as long.
Actually, in practice, I've found Arch to be not only more featureful than Subversion, but much more robust as well.
Tom Lord (Arch's author) has written a few screeds with his interpretation of where the Subversion design and development process went wrong (to take so many man-hours to develop a product which, in his view, has severe design flaws); his arguments there are likely to be much better than any I could make here.
Slashdot Mirror
Simulating something is faking, the way I see it is impossible to program true emotions.
Look at a neural network which has been trained (to take a trivial example) to distinguish between paintings and photographs. NNs learn by example -- nobody "tought" the system a set of rules for distinguishing between one and the other, and it's typically damn near impossible to determine how one works after it's set itself up -- but that doesn't mean it can't make the distinction just fine. Likewise, simply because a machine is capable of creating art doesn't mean that some human necessarily sat down to "program human emotions". With humans, art is (arguably) an emergent effect; these happen in other complex iterative systems, many of which can occur inside a computer as well.
Finally, I disagree that "simulating something is faking". A system which perfectly simulates intelligence is for all intents and purposes intelligent; arguing that its intelligence is nothing but a sham may make you feel better as an intellectual exercise, but makes the (hypothetical) machine no less capable of providing its opinions on Shakespeare.
Since when is a "smart phone" an embedded device?
Eh? A PDA is generally considered to be a (large) embedded device; a smart phone is no doubt likewise.
Smart phones are [...] shrunken multi-function devices.
Granted -- so we're certainly far enough out of the 100K range that Linux is no longer utterly infeasible, but that doesn't mean that battery life and production cost stop being important factors.
Certainly, there are folks who are willing to give up battery life and pay a bit more for snazzy features, and maybe an OS that makes coding those features easier at the expense of hardware cost and battery life makes some level of sense there. That said, it's foolish to expect that the engineering staff working on designing such devices will forget about those factors altogether. People with more interest in practicality than the ability to show off their gadgets at parties do, and will continue to, make their purchasing decisions based on low price and long life rather than the developers' ability to get a few more nifty features crammed in.
I happen to know some very skilled embedded systems developers, and at least one (also a Linux kernel maintainer) recently lost a possible contract with a very large multinational company because Linux turned out to be too large for the environment they wanted to run it in.
Hopefully VSTa or a like open operating system better suited to very small environments (eCos? dunno) will become practical and popular for such usage. Linux is reasonable in larger embedded systems -- networking hardware and the like -- but its suitability becomes less and less as space constraints constrict (think 100K of RAM or less). Remember, it's not just the cost of the OS that's an issue -- the cost of the extra hardware to run it, and the loss of battery life, is also a dealbreaker.
So no, I'm not convinced by this report; the summary makes it look too much like something concocted by talking to managers with insufficient engineering input.
I've done my time in a "philosophy of AI" class -- and frankly, as far as I'm concerned, the Chinese Room argument and the like are bogus. If it looks like a duck, walks like a duck, quacks like a duck -- it's a duck, at least until someone finds out that it doesn't in fact keel over when given cyanide-laced bread and has to plug itself in to charge its batteries every so often.
:)
Consider: For the purposes of this thread, AI is considered incomplete due to inability to simulate emotions why? Because it's argued that the desired output (emotionally-charged vocalization) is impossible without a precondition which is argued to be impossible. If the output were indeed achieved, then for the purpose of its singing, would the system not for all intents and purposes be emotional, even if one is unable to demonstrate that the system actually experiences qualia? (After all, if we're unable to make this demonstration wrt other humans, why make it a requirement for nonhuman intelligence?)
Granted, I also think that a machine which can pass an unrestricted Turing Test over an extended period can be safely be considered capable of thought, so it's obvious which side of this debate I land on.
Or maybe you should rethink your earlier statement about only "crappy" and "broken" applications needing to be explicitly certified on a particular browser. To criticize people and organizations who are going out of their way to invest in supporting platforms with miniscule market share doesn't really help your cause of standards promotion.
When the application is core enough to ones' customers that they'd gladly install the appropriate platform to be able to use it -- and when the platform is licensed in such a way that it could freely be installed as just another component or dependency by the application -- I'm not sure this argument is particularly appropriate or sensible.
I would disagree. The number of easy-to-publish tools (webfolders, frontPage, etc) for IIS makes it far more lucrative for Windows folks.
Web folders are nothing but WebDAV -- nothing there that Apache won't do. At my workplace, we use a Plone-based system for content management on our intranet, running on top of Apache, and the Windows users (which is most of the tech writing and graphics teams) seem quite happy with it.
Eh? Static analysis can be done in Python. See pychecker.
I call bullshit.
Granted, I haven't tried Tomcat 5.0 -- but as of 4.1.29, Apache HTTPD whoops its ass serving static content (over SSL, anyhow). Moreover, Tomcat just doesn't have the flexibility provided by the vast numbers of modules available for Apache httpd -- meaning less flexibility (sans hoop-jumping) in authentication, header rewriting, integration with 3rd-party components, etc etc etc.
Tomcat is fine -- as a *backend* servlet container -- but it's not really a serious competitor for Apache httpd for those with more serious requirements. (In cases where an extra layer is undesirable, I'm pondering looking into using Jetty, but haven't done more than toy with it yet).
Never had any trouble with my (IBM) microdrive over the past year-and-a-half -- and it's been dropped at least a few times within that period. (Thankfully, it's not been in my camera on any of those occasions).
That joke was old 20 years ago!
I don't know how the legality of the system works, but you can sue people for breach of contract and such here, I do not know if you can do that with overseas contractors, is it more of a "buyer beware" methodology?
International legal battles can be done (though only if the amount in contention is over a certain minimum), but it's very, very expensive.
Actually, my previous supervisor (and the best damn manager I've ever had the privilege to work with) left the company a bit ago, so if I still needed a reference from her, I suppose that I could get one now.
That said, while she was employed by the company, they were quite firm about disallowing even personal references, and she (and everyone upward in the chain) was quite firm about following the rule. One poster here mentioned a company (Cisco?) where managers' contracts specify enforcement of the no-personal-references rule, and breaking it is grounds for not only dismissal but a breach-of-contract suit; perhaps they did something like that (though I don't recall anything about managerial types being asked to sign new contracts as part of the Corporate Stuffiness campaign, it wouldn't suprise me a bit if they did).
In any event -- the ask-for-a-personal-reference thing was tried, and turned down, and the other ex-MVistans I talked to had a similar experience.
*shrug*.
I'm not going to defend the others, because I don't particularly like them either, but let me throw in a word or two about Arch here:
The interface to Arch is only unintuitive until one's played with it enough, or crawled inside Tom's head for a bit. Given this effort, Arch just Makes Sense -- quite a lot of the interface reflects the underlying implementation concepts and such quite cleanly.
Further, the "extra steps" argument is less true than it used to be. For instance, tla 1.1's archive-setup command makes into a single step what used to be a 3-step process (creating a new category, branch and version in the archive for a fresh project or branch), and star-merge has a syntax that's vastly simplified.
Tom has played around with the idea of writing "itla" -- an interactive client for TLA -- or overarch (a tool for writing project-specific arch scripts). In the meantime, though, there are a fair number of 3rd-party frontends available -- I don't use any of them, but Samium Gromoff has been actively looking for user feedback on "tlator", so it's probably a good place to start.
Doing an update in a tree where one file has changed is a simple as downloading the single changeset -- unlike CVS, where the status of every single file needs to be queried to find the one that's altered. In a 30,000-file tree, this is a major performance improvement.
Bah -- neither CVS nor ClearCase can really scale.
For an example of my "CVS can't scale" assertion in action, just look at the pains SourceForge has had to go through, and oppose that to a system like Arch (where the repositories can be served over a completely unmodified web server using standard HTTP load-balancers, multi-layer distributed caching and all the other techniques used by high-volume web sites serving static content).
Arch doesn't need GUI add-on tools for branching -- indeed, the ease and power of its branching and merging operators is one of the things that best recommends it.
CVS may be adequate version control for those with few needs -- but by no means is it "great". See my other post for more on that.
I disagree. The reason folks don't CVS's advanced features much is because they suck.
No, really. Take a look at branches. They'd be exceedingly useful if they just worked right -- but half the time in CVS they're more trouble than they're worth (because merging's so difficult, branches do weird things like make files added on the branch suddenly show up in HEAD, someone always ends up checking things in on the branch that belong in HEAD or vice-versa, etc) so half the time people who would otherwise use a branch just decide to do without. That's not necessarily a conscious decision -- if you think of branching as difficult and error-prone, it's not going to come to you naturally as the appropriate thing to do as often as it would if you thought of it as trivial.
In Arch, where branches Just Work, everyone uses them -- not just that, but folks who are making their own branch off someone else's arch repository and then merges newer changes from the parent are doing the same thing a CVS user would perform with never-used "vendor branch support" -- except in Arch, these "vendor branches" are actually useful.
If you argue that the failure of CVS's advanted features to actually be worthwhile implies that users have no need of the advanced features of other revision control systems -- why do folks on Arch actually make use of automated changelog generation, intelligent merge operators, or cryptographically signed archives?
Because, to put it briefly, these features are, as implemented by Arch, easily understood, readily available, and useful with few caveats -- something which can't be said regarding much of CVS.
*shrug*. The SVN folks say outright that what they aim to be is a better CVS. I think the relevant phrase is "polishing a turd".
That said, if you can dig up an article by anyone on the SVN team on Arch's shortcomings, I'd find it an interesting read.
*shrug*. I'd think that if that were the case, the references from my fellow engineers would have been a bit less glowing.
You just hit on a weak point there -- Cygwin won't run Arch correctly on complex repositories until some fixes to support long filenames (by using the Win32 unicode file management API) are in.
Such a patch has already been written, but its contribution is being held up by legal issues (the author did it on company time, and he needs to jump through a bunch of hoops before his employer will agree to transfer copyright).
Presumably Tom could work on writing support for the filesystem abstraction layer and such to support Windows natively -- but until the available copies of tar and such cope gracefully with very long filenames, arch will still be broken on Windows.
Nope -- the policy prohibits personal references too. Of course, the other engineers were happy to ignore it -- but when someone wanted a reference from a manager, they were out (or rather, I was) of luck.
Past employers can be a liability even if they've got a positive reputation, if they refuse to say anything about you -- indeed, such a refusal can be misconstrued as covering ones' ass rather than telling the truth about an incompetant or otherwise unworthy employee.
I spent almost 3 years working at MontaVista Software, having started off there as an intern in college. I did damned good work, porting more than 3x the number of packages slated for my team during my first three months there, and coming up with some innovated automated testing tools later on in my employment. During my last year there, as part of the Corporate Stuffiness effort, a new policy went up: No references to former employees. Not good references, not bad references, nothing. Any queries would be sent to HR, which would confirm dates of employment and last position held.
So: I decide that I've had enough of the Bay Area and move to Texas; MontaVista decides they don't need the management overhead of an additional remote employee and lets me go. When trying to find new work (halfway across the country in a city where I had no contacts), the refusal to give out references hurt. A lot.
Which is not to say that there's no happy ending. I'm now employed at an underfunded, understaffed startup making some really amazingly neat software going out for a first release in the very near future. (Live in Austin? Good with Java? Willing to work mostly for stock? Demangle my email address and get in touch).
"Diagnosing SVN" is one of the most widely linked. I think there've been a few others as well, but I couldn't locate them immediately.
tla uses GNU tar, diff and patch at runtime. It doesn't require rcs, apache or others.
*sigh*.
Re versioning directory structures: If I rename the directory "a" to be called "b", and do a commit, I want people who do an update to suddenly have "a" renamed to "b" -- with all their local changes still intact. Subversion does it, Arch does it, CVS won't.
With atomic commits: I change 3 files. I want do a single commit that makes these 3 files part of one atomic change. If someone does an update and gets one of these, I want them to get all of them. (Say they're a change to a method description in a header, a change to the C file implementing that method, and a change to another file calling it -- if someone does an update and only gets one of the 3 they always have a broken tree; they should have all or none). CVS won't do that; Subversion will, Arch will.
See my other post for a bit more on why modern revision control systems are more useful.
My guess is that Arch is even less mature than Subversion though, since it appears to have not been around as long.
Actually, in practice, I've found Arch to be not only more featureful than Subversion, but much more robust as well.
Tom Lord (Arch's author) has written a few screeds with his interpretation of where the Subversion design and development process went wrong (to take so many man-hours to develop a product which, in his view, has severe design flaws); his arguments there are likely to be much better than any I could make here.