"GNU software" refers to software expressly under the GNU banner. Most free software is not GNU software. And indeed you'll note that the past recipients of the award are known mostly for their non-GNU software. So your suggestion is clearly off the mark.
People--including the FSF--have tried for a long time to come up with a better (English) term than "free software". The only one that has caught on is "open source", which has entirely different connotations. "Free software" is imperfect, but it's what we got.
One thing I have never heard a real python programmer say is that there
is only one way to do it.
Larry didn't say that. Nobody said that. That would be ridiculous. Even
the "one obvious way" mantra is a point of contention among Python
programmers (as the other respondant pointed out, check the comp.lang.python
discussions).
By the way, I don't mean to criticize people who prefer Python. I like
Python too, especially compared to writing Java. I merely decry the trend
to cast Perl and Larry as a dilettanti and a bad hack (in some order). Most
of it is mean-spirited and has little merit.
could get away with using the word "renaissanciest".
Lately, I've seen more and more uptight types[1] skewer Larry as a half-assed linguist, a half-assed language designer, a half-assed art historian, and a half-assed philosopher. What they don't realize is that Larry sees things from so many perspectives--some entirely original--and incorporates them so fluidly, that analyzing him in any narrow way is laughably short-sighted. Yes, he is educated in these fields, but expecting him to come off sounding like an orthodox linguist, language designer, art historian, or philosopher entirely misses his true gifts.
Set aside your judgement for a moment, and simply savor the output of one of the most creative, wittiest, and just plain renaissanciest minds with which we have the pleasure to associate. (Oh, he's also a nice guy and never said anything mean about you.:-) )
Not to me. Restrictions could, in principle, be either fair or unfair. But I think the connotation leans towards unfair.
A better ancronym for DRM is "Digital Rights Mutilation"
That's one way to look at it, because that's how its promoters want to use it. But if you're talking about the technology per se, it's inaccurate, because DRM doesn't necessarily impinge on freedoms. (Consider businesses using it to protect trade secrets.)
I think the term "Digital Restrictions Management" points out the salient fact about the technology. Unlike most technology, it doesn't let you do anything you couldn't do before--rather takes away your ability to do something you could do before! This, IMO, is the important message to get across.
To claim that RMS is the definition of OSS implies you either are new to this argument, or are a troll.
To me, you seem new to this.;-)
RMS does believe that all software should be free, he is one pillar of OSS.
RMS has nothing to do with OSS, and says so all the time.
I on the other hand feel that OSS software... [snip]
You can feel whatever you want, but you can't just make up your own meaning for the term "open source". "Open source" should mean what its coiners said it means, and they are very clear about it. They say "open source" is a better development methodology.
In this particular case the definition of "Free Software" should fall under the category of software that dosen't give a private company absolute control of your data.
You can't just make up your own meaning for "free software", either. If everyone uses the terms to mean what they want, how will we ever communicate? Your definition has nothing to do with that which has been in common usage for 15 years.
MS is capable of creating "Free Software", and even selling it with thier current UELA if they so choose.
Utter nonsense.
P.S.:
RMS is more important because he's writen Emacs and Hurd, where as I've only spit out a few drivers, is absurd.
No offense to you, but RMS is more important (in the context of this debate) than you (and me and the rest of slashdot) because he's a bona fide genius who's thought about this issue more than any of use ever will.
The ZDNet article voices the common "insight" that,
Open source is supposed to be about freedom.
where "freedom" is interpreted as choice. The same cry--sometimes with
"free software" in place of "open source" appears in countless slashdot
comments, and even in articles
by the normally sane Jonathan Corbet.
But in either form ("open source" or "free software"), it's revisionist
bullshit.
Free software, according to Stallman and the FSF, is about the essential
freedom to share and modify software. They explictly reject the
choice to produce and use proprietary software as a freedom. That makes as
much sense, they say,
as the "freedom to choose slavery". Free software is about as far away from
"freedom to choose" as you can get.
How about open source, that much more convenient doctrine? According to its
founders,
The basic idea behind open source is very simple: When
programmers can read, redistribute, and modify the source code for a piece
of software, the software evolves.
So while ESR may support the freedom to choose in general (he does), that is
not at all what open source is about. Open source is about convincing the
world that it is a better development methodology. Most of its adherents
would be perfectly happy it it killed off proprietary software, thus
eliminating "choice".
So, the "freedom to choose" may be your philosophy, or Tim O'Reilly's
philosophy, but it is not that of free software or open source.
Is a crucial link missing, or are you asking us our opinion about a license
we haven't seen? If there's some good reason you can't show us the license
(I can't think of any), at least you could give us some specific details.
a license which includes a requirement for
click-wrap
A requirement imposed on whom, to do what?
She said yes, because of various legal precedents. We consulted
a few people and yes, it looks like a license without click-wrap is weaker
at protecting your rights.
What precedents? Whom did you consult? Whose rights? What's the argument?
The time is coming when you won't be able to distribute software
unless you have presented the license to the user and their assent is
necessary to access the software. Even free software.
What kind of FUD is this? Are you telling us it's a forgone conclusion that
you will accept this license? Are you telling us that the FSF (which
defines "free software") will accept this license? Are they and other free
software distributers going to change their licenses to require
click-through?
Come on, Russ. Give us the facts, straight, so we have some basis for
discussion.
This list does not appear to be a replacement for Bugtraq, because it is unmoderated. There is a need for a list moderated by someone respected in the security community, so that we can be assured of both high quality and full disclosure.
By which I mean displaying things wordwrapped, even when it's one long line.
You're right that vim doesn't seem to support automatically wrapping with newlines, but I think such a mode would get confused by newlines that were entered intentionally.
If you want various motion commands to work on screen lines, instead of file lines, add things like
map j gj map k jk map <down> gj map <up> gk map $ g$ map ^ g^
Re:Why parse XML in the first place?
on
Perl & XML
·
· Score: 5, Insightful
Interoperability is great and all, but I think XML is nothing but hype.
Heck, let me give this my crack...:-)
Ok, obviously the biggest reason for XML's popularity is hype. That's just
the way the industry works; it doesn't make XML good or bad.
There are a several legitimate technical benefits to XML, that might be
persuasive in one context or another.
It looks like HTML, so everyone intuitively "gets" it.
It's textual (not binary)--but of course, many formats are textual.
It's reasonably easy for humans to understand without a spec, provided
the tag and attribute names are not obfuscated, and the relationships are
relatively simple. Note this does not make it easy for programs to
understand!
You don't have to write your own parser. You don't even have to write a
grammar--just throw in a tag and the corresponding code to read and write
it. This advantage is not as big as some make it out to be: many languages
have easy-to-use features for parsing, and those that don't can make use of
easy-to-use parser-generator tools.
There are lots of libraries and tools. Of course, this is
self-reinforcing (tools -> popular -> more tools -> more popular ->...).
Many XML proponents, including some in this thread, would add to this list
that XML is a good data storage and/or interchange format. Some
"insightfully" note that it is better for data interchange than data
storage. This is the biggest delusion over XML: XML is a rotten format for
data.
Remember what XML was back before the hype machine was in overdrive? It was
a better HTML, and a simpler SGML. HTML and SGML have always been formats
for documents, and XML was intended to be the same. XML is indeed a pretty
good match for documents. (This is debated of course: documents are complex
things, and modeling them is non-trivial. Embedded Markup
Considered Harmful, by Ted Nelson, is a good introduction.)
But XML is a poor match for data. This is because an XML document is a
tree, and most data are not hierarchical. Consider that the database
industry abandoned hierarchical databases many years ago (ok, abandoned is a
little strong: we still use LDAP). Hierarchical data formats force you to
pick which relationships will define the hierarchy, and any other
relationships have to be kluged in.
Take a simple example of the sort of thing people use XML for: address book
entries. Say you start out with a person element (I'm not going to write
out the examples in XML syntax because it's too painful on slashdot)
containing a name element and an address element. Now, you realize that
multiple people may live at the same address, and you don't want to
duplicate the address (data formats should be normalized). You either have
to turn things inside out, putting the person element inside the address
element, or make person and address both top-level elements, and link them
somehow. In the former case, you have chosen an awkward hierarchy, and have
"used-up" your ability to group people. What if you want a different
grouping in the future? In the latter case, you have given up a lot of
simplicity and read/writability (since now names and their corresponding
addresses are in different places) by forcing non-hierarchical data into a
hierarchical format.
What is the solution? Well, I won't assert that it is the best data model
that will ever exist, but the database industry has settled (roughly) on the
relational model. So I think we should create a format describing
relations, combined with the other advantages of XML: extensible, textual,
readable, and most of all, standards-based. Yes, this would mean we would
have to learn two technologies, one for documents and one for data. But the
technology for data would be so much simpler--and as a bonus, integrate
easily into our databases--that it would be a huge win overall. I don't
have time to defend this model in depth. But think about it.
By the way, another example of the bad match between XML and data is the
great debate over when you should use elements, and when you should use
attributes. The fact that there is an arbitrary decision to be made shows
that XML has degrees of complexity that only get in the way when you use it
as a data format. (If you're going to use XML for data, at least have the
decency to eschew attributes except for an id attribute.)
Ever watched a one handed typist? I know one at work, and she's blazingly fast with one hand.
August Dvorak designed keyboard layouts for single left and right hands. I actually learned the right-hand layout once for fun, though I didn't stick with it long. Does your friend use a special layout?
Anyway, I'm sure your friend is fast, but are you really arguing that alternation between hands doesn't let most people go faster?
I think s/he has large hands and is used to moving them great distances
(piano)
Probably. (I rebelled against the piano long enough ago that I'm sure it has
no influence on my typing.)
When you hold your hand still, it certainly is uncomfortable, but playing
around just now, I've found that there's an easy way to make it simple:
dance.
I tried it--and you're right. I had to make a conscious adjustment, but
when I let my hands "roam free", 2-4-1 worked. But as I said in another
post, I don't like having to look down to orient myself, and I'm
uncomfortable with so much motion. And my gut feeling is that it is harder
on the hands.
It seems to me that your typing style is heavily influenced by the 'hold
your damn hand still!' school of typistry. Understandably, this probably
works well for you, but I, and many others, have found it far too rigid.
Undoubtably true on both points. But I would suggest (if you have not) that
you try touch typing with the Dvorak layout. It requires significantly
less finger-travel, so keeping your hands relatively still is less of a
problem.
My theory is that mousing is what's causing wrist injuries.
I'm inclined to agree. Part of my problem is that I have an obsessive habit
of clicking around while I'm reading, and this is most often what makes my
hands sore.
There are basically two types of typing tasks - copying text from another source and composing text as you type it. Touch typing seems to be designed for the copying case, where you can't afford to look at the keyboard. You said "for most people, the key to finding a key quickly is knowing its position relative to a fixed reference". But if can afford to look at the keyboard you don't have maintain a fixed reference, you can always re-establish where you are.
It's funny that this didn't think of this: I'm so used to touch typing, that it doesn't occur to me to look at the keyboard, ever (except for typing unusual keys). I tend to think that having two techniques--one for blink typing, one for looking at the keys--is a waste, compared to concentrating on one. But I have touch-typed for so long that it may just be me. I also prefer to keep my eyes on the screen, even if I am not copying from anything.
It seems to me that you're trying to avoid moving your hands horizontally. If you stop trying to keep your index finger on the 'j' column you won't find getting to 'p' a stretch and your thumb should be moving toward the '.' too.
Again, probably true--when I look at they keys and (consciously) allow my hands to wander, I can do 2-4-1. But it feels to me like so much excess motion, I can't really get comfortable with it. Plus the fact above: I don't want to adopt any habits that require looking at the keys.
I certainly agree that the functionality you described is useful. But most of the systems I've heard described as "configuration management" don't do that, at least not as their primary function. They primarily do version control. For example, OpenCM calls itself configuration management, but describes itself as a "replacement for CVS". So either someone (you or the OpenCM people) is confused about what CM is, or CM is just an amorphous buzzword.
That said, I do now have a better appreciation for your view of configuration management. Let me try to fit my experience into that framework. ClearCase (which I do know fairly thoroughly) has some features in this area. For example, it can hook into your build process and remember which source-controlled files contributed to built files. It can give you a "view" onto arbitrary versions of different modules. But bundling up a release, producing a manifest, tracking installations, etc, are generally outside its scope (and are left for tools such as ReleasePro). So by your definition, ClearCase is not a configuration management system.
3.
If you are managing sets of versions of files, instead of versions of a single file, then you are doing configuration management. I understand why you don't want to give a separate name to configuration management, but the naming debate ended in the SCM industry almost 15 years ago. Arguing about it now is pointless.
Ok, I'll relent and accept that as the defining characteristic of
configuration management. At least it is a clear criterion that is stronger
than "version control", and has some amount of sense to it. As opposed to
some of the divers definitions offered on this thread.
Even though to me (as I said before), it is just "better version control".
That is a nice, quick, once-then-forget solution on a system where only one person has root. The trick is making it work when multiple users can su. It's not technically hard, it's just that there's no standard method.
I agree that having deltas that span multiple files is a good thing. But this is just an improvement on the version control theme: managing changes in groups of files, not individual files. If this is "the whole point of CM", then CM is clearly just version control.
I know (everyone knows) that CVS has many shortcomings. But the shortcomings (at least the ones I've heard about, eg lack of atomic changesets, poor branching/merging, centralized) are still about version control.
ClearCase has some disconnected functionality (snapshot views), though it has many flaws (like, due to the fascist license regime, you can't run any clearcase commands while disconnected!). But what is the point of your question? ClearCase is commonly termed a CM tool, but as a user, all I see is version control. What part of ClearCase is CM, as opposed to version control?
Again, my challenge is to evince some important function of "configuration management" tools that is fundamentally different from version control.
Ok, if configuration management is this big thing that is fundamentally more than version control,
answer these challenges:
Why does the OpenCM home page call itself a "replacement for CVS", which
you say is a version control tool, not a configuration management system.
Why does the site (at least the overview and features sections) list only
version control features? Where are the CM features in OpenCM?
If CM is needed for programming "in the large", how have most large free
software projects gotten away without it? Or, if they are using CM in some
form, where is it?
I've used ClearCase for several medium-sized (5-10 full-time
programmers) projects. As far as I can tell, all of our use of ClearCase
falls under what I would consider version control. What parts of ClearCase
are configuration management? (Of course, you can skip this if you haven't
used ClearCase.)
I know about programming "in the large" (or at least medium-sized). I've
used tools more powerful than CVS. These tools are powerful because they do
version control better than CVS, not because they offer something
fundamentally different.
And your argument that CM is about what files go where seems like nonsense
to me. First, even if that is important, it hardly requires a sophisticated
tool. You might as well use (a subset of) RPM for that. Or a 100 line Perl
script (that reads the file locations, etc, from a config file). Second,
code should generally be buildable and runnable right in the source control
system, for quick testing. So if you need some fancy layer just to get the
code into a runnable state, you're probably doing something wrong.
OpenCM, like many other tools, is mistaken as a revision control tool
It's more natural for me simly to think of RCS and CVS as semantically limited revision control tools, and ClearCase, subversion, and BitKeeper as more complete and powerful revision control tools. Ie, I acknowledge the fundamental differences between more primitive and more advanced systems, but I reject the notion that they deserve different names.
Maybe the easiest way is to think of a system as one of those cool (well, they were then) transformer toys. In its airplain configuration is goes really fast, but change it to its robot configuration and it has laser weapons.
Yeah, I've thought of that argument, but it's a big stretch. "SCM" systems don't let you use a single codebase as either an airplane or a weapon, at least not the way they are normally used. And even if I let you get away with calling the specification of library versions as "configuration", that is hardly a core feature of these systems.
Face it: the primary purpose of any of these systems is to manage the various versions in some body of content. So I reassert that "version control" or "revision control" or "change control" is the best name.
And by the way, the fact that the name is confusing does matter, especially for a free software project. If you're trying to appeal to developers, its best to pick a name that won't confuse all the students who haven't been corrputed by industry jargon.:-)
Slashdot Mirror
People--including the FSF--have tried for a long time to come up with a better (English) term than "free software". The only one that has caught on is "open source", which has entirely different connotations. "Free software" is imperfect, but it's what we got.
Larry said,
That's right there in The Zen of Python.One thing I have never heard a real python programmer say is that there is only one way to do it.
Larry didn't say that. Nobody said that. That would be ridiculous. Even the "one obvious way" mantra is a point of contention among Python programmers (as the other respondant pointed out, check the comp.lang.python discussions).
By the way, I don't mean to criticize people who prefer Python. I like Python too, especially compared to writing Java. I merely decry the trend to cast Perl and Larry as a dilettanti and a bad hack (in some order). Most of it is mean-spirited and has little merit.
Lately, I've seen more and more uptight types[1] skewer Larry as a half-assed linguist, a half-assed language designer, a half-assed art historian, and a half-assed philosopher. What they don't realize is that Larry sees things from so many perspectives--some entirely original--and incorporates them so fluidly, that analyzing him in any narrow way is laughably short-sighted. Yes, he is educated in these fields, but expecting him to come off sounding like an orthodox linguist, language designer, art historian, or philosopher entirely misses his true gifts.
Set aside your judgement for a moment, and simply savor the output of one of the most creative, wittiest, and just plain renaissanciest minds with which we have the pleasure to associate. (Oh, he's also a nice guy and never said anything mean about you. :-) )
[1] Yes, they're mostly Python advocates
Not to me. Restrictions could, in principle, be either fair or unfair. But I think the connotation leans towards unfair.
A better ancronym for DRM is "Digital Rights Mutilation"
That's one way to look at it, because that's how its promoters want to use it. But if you're talking about the technology per se, it's inaccurate, because DRM doesn't necessarily impinge on freedoms. (Consider businesses using it to protect trade secrets.)
I think the term "Digital Restrictions Management" points out the salient fact about the technology. Unlike most technology, it doesn't let you do anything you couldn't do before--rather takes away your ability to do something you could do before! This, IMO, is the important message to get across.
"Digital Restrictions Management" is more accurate, and has the right letters at the beginnings of the words. :-)
I didn't coin this; it's been floating around for a while, I think. But we would do well to push this term into the mainstream.
Whew!... just imagine if this technology had been developed before our ability to uncloak terrorist networks.
The terms in question are "free software" and "open source", as used in the computer field. Try again.
To me, you seem new to this. ;-)
RMS does believe that all software should be free, he is one pillar of OSS.
RMS has nothing to do with OSS, and says so all the time.
I on the other hand feel that OSS software ... [snip]
You can feel whatever you want, but you can't just make up your own meaning for the term "open source". "Open source" should mean what its coiners said it means, and they are very clear about it. They say "open source" is a better development methodology.
In this particular case the definition of "Free Software" should fall under the category of software that dosen't give a private company absolute control of your data.
You can't just make up your own meaning for "free software", either. If everyone uses the terms to mean what they want, how will we ever communicate? Your definition has nothing to do with that which has been in common usage for 15 years.
MS is capable of creating "Free Software", and even selling it with thier current UELA if they so choose.
Utter nonsense.
P.S.:
RMS is more important because he's writen Emacs and Hurd, where as I've only spit out a few drivers, is absurd.
No offense to you, but RMS is more important (in the context of this debate) than you (and me and the rest of slashdot) because he's a bona fide genius who's thought about this issue more than any of use ever will.
But in either form ("open source" or "free software"), it's revisionist bullshit.
Free software, according to Stallman and the FSF, is about the essential freedom to share and modify software. They explictly reject the choice to produce and use proprietary software as a freedom. That makes as much sense, they say, as the "freedom to choose slavery". Free software is about as far away from "freedom to choose" as you can get.
How about open source, that much more convenient doctrine? According to its founders,
So while ESR may support the freedom to choose in general (he does), that is not at all what open source is about. Open source is about convincing the world that it is a better development methodology. Most of its adherents would be perfectly happy it it killed off proprietary software, thus eliminating "choice".
So, the "freedom to choose" may be your philosophy, or Tim O'Reilly's philosophy, but it is not that of free software or open source.
Another curious story about Bhutan.
A requirement imposed on whom, to do what?
What precedents? Whom did you consult? Whose rights? What's the argument?
What kind of FUD is this? Are you telling us it's a forgone conclusion that you will accept this license? Are you telling us that the FSF (which defines "free software") will accept this license? Are they and other free software distributers going to change their licenses to require click-through?
Come on, Russ. Give us the facts, straight, so we have some basis for discussion.
This list does not appear to be a replacement for Bugtraq, because it is unmoderated. There is a need for a list moderated by someone respected in the security community, so that we can be assured of both high quality and full disclosure.
You're right that vim doesn't seem to support automatically wrapping with newlines, but I think such a mode would get confused by newlines that were entered intentionally.
set nowrap
set linebreak
If you want various motion commands to work on screen lines, instead of file lines, add things like
map j gj
map k jk
map <down> gj
map <up> gk
map $ g$
map ^ g^
Heck, let me give this my crack... :-)
Ok, obviously the biggest reason for XML's popularity is hype. That's just the way the industry works; it doesn't make XML good or bad.
There are a several legitimate technical benefits to XML, that might be persuasive in one context or another.
Many XML proponents, including some in this thread, would add to this list that XML is a good data storage and/or interchange format. Some "insightfully" note that it is better for data interchange than data storage. This is the biggest delusion over XML: XML is a rotten format for data.
Remember what XML was back before the hype machine was in overdrive? It was a better HTML, and a simpler SGML. HTML and SGML have always been formats for documents, and XML was intended to be the same. XML is indeed a pretty good match for documents. (This is debated of course: documents are complex things, and modeling them is non-trivial. Embedded Markup Considered Harmful, by Ted Nelson, is a good introduction.)
But XML is a poor match for data. This is because an XML document is a tree, and most data are not hierarchical. Consider that the database industry abandoned hierarchical databases many years ago (ok, abandoned is a little strong: we still use LDAP). Hierarchical data formats force you to pick which relationships will define the hierarchy, and any other relationships have to be kluged in.
Take a simple example of the sort of thing people use XML for: address book entries. Say you start out with a person element (I'm not going to write out the examples in XML syntax because it's too painful on slashdot) containing a name element and an address element. Now, you realize that multiple people may live at the same address, and you don't want to duplicate the address (data formats should be normalized). You either have to turn things inside out, putting the person element inside the address element, or make person and address both top-level elements, and link them somehow. In the former case, you have chosen an awkward hierarchy, and have "used-up" your ability to group people. What if you want a different grouping in the future? In the latter case, you have given up a lot of simplicity and read/writability (since now names and their corresponding addresses are in different places) by forcing non-hierarchical data into a hierarchical format.
What is the solution? Well, I won't assert that it is the best data model that will ever exist, but the database industry has settled (roughly) on the relational model. So I think we should create a format describing relations, combined with the other advantages of XML: extensible, textual, readable, and most of all, standards-based. Yes, this would mean we would have to learn two technologies, one for documents and one for data. But the technology for data would be so much simpler--and as a bonus, integrate easily into our databases--that it would be a huge win overall. I don't have time to defend this model in depth. But think about it.
By the way, another example of the bad match between XML and data is the great debate over when you should use elements, and when you should use attributes. The fact that there is an arbitrary decision to be made shows that XML has degrees of complexity that only get in the way when you use it as a data format. (If you're going to use XML for data, at least have the decency to eschew attributes except for an id attribute.)
August Dvorak designed keyboard layouts for single left and right hands. I actually learned the right-hand layout once for fun, though I didn't stick with it long. Does your friend use a special layout?
Anyway, I'm sure your friend is fast, but are you really arguing that alternation between hands doesn't let most people go faster?
Probably. (I rebelled against the piano long enough ago that I'm sure it has no influence on my typing.)
When you hold your hand still, it certainly is uncomfortable, but playing around just now, I've found that there's an easy way to make it simple: dance.
I tried it--and you're right. I had to make a conscious adjustment, but when I let my hands "roam free", 2-4-1 worked. But as I said in another post, I don't like having to look down to orient myself, and I'm uncomfortable with so much motion. And my gut feeling is that it is harder on the hands.
It seems to me that your typing style is heavily influenced by the 'hold your damn hand still!' school of typistry. Understandably, this probably works well for you, but I, and many others, have found it far too rigid.
Undoubtably true on both points. But I would suggest (if you have not) that you try touch typing with the Dvorak layout. It requires significantly less finger-travel, so keeping your hands relatively still is less of a problem.
My theory is that mousing is what's causing wrist injuries.
I'm inclined to agree. Part of my problem is that I have an obsessive habit of clicking around while I'm reading, and this is most often what makes my hands sore.
It's funny that this didn't think of this: I'm so used to touch typing, that it doesn't occur to me to look at the keyboard, ever (except for typing unusual keys). I tend to think that having two techniques--one for blink typing, one for looking at the keys--is a waste, compared to concentrating on one. But I have touch-typed for so long that it may just be me. I also prefer to keep my eyes on the screen, even if I am not copying from anything.
It seems to me that you're trying to avoid moving your hands horizontally. If you stop trying to keep your index finger on the 'j' column you won't find getting to 'p' a stretch and your thumb should be moving toward the '.' too.
Again, probably true--when I look at they keys and (consciously) allow my hands to wander, I can do 2-4-1. But it feels to me like so much excess motion, I can't really get comfortable with it. Plus the fact above: I don't want to adopt any habits that require looking at the keys.
That said, I do now have a better appreciation for your view of configuration management. Let me try to fit my experience into that framework. ClearCase (which I do know fairly thoroughly) has some features in this area. For example, it can hook into your build process and remember which source-controlled files contributed to built files. It can give you a "view" onto arbitrary versions of different modules. But bundling up a release, producing a manifest, tracking installations, etc, are generally outside its scope (and are left for tools such as ReleasePro). So by your definition, ClearCase is not a configuration management system.
Ok, I'll relent and accept that as the defining characteristic of configuration management. At least it is a clear criterion that is stronger than "version control", and has some amount of sense to it. As opposed to some of the divers definitions offered on this thread.
Even though to me (as I said before), it is just "better version control".
That is a nice, quick, once-then-forget solution on a system where only one person has root. The trick is making it work when multiple users can su. It's not technically hard, it's just that there's no standard method.
Finally, the guy I've been looking for!! How the hell should I set up X so that when I su, I can run X programs as root?
Again, my challenge is to evince some important function of "configuration management" tools that is fundamentally different from version control.
I know about programming "in the large" (or at least medium-sized). I've used tools more powerful than CVS. These tools are powerful because they do version control better than CVS, not because they offer something fundamentally different.
And your argument that CM is about what files go where seems like nonsense to me. First, even if that is important, it hardly requires a sophisticated tool. You might as well use (a subset of) RPM for that. Or a 100 line Perl script (that reads the file locations, etc, from a config file). Second, code should generally be buildable and runnable right in the source control system, for quick testing. So if you need some fancy layer just to get the code into a runnable state, you're probably doing something wrong.
It's more natural for me simly to think of RCS and CVS as semantically limited revision control tools, and ClearCase, subversion, and BitKeeper as more complete and powerful revision control tools. Ie, I acknowledge the fundamental differences between more primitive and more advanced systems, but I reject the notion that they deserve different names.
Maybe the easiest way is to think of a system as one of those cool (well, they were then) transformer toys. In its airplain configuration is goes really fast, but change it to its robot configuration and it has laser weapons.
Yeah, I've thought of that argument, but it's a big stretch. "SCM" systems don't let you use a single codebase as either an airplane or a weapon, at least not the way they are normally used. And even if I let you get away with calling the specification of library versions as "configuration", that is hardly a core feature of these systems.
Face it: the primary purpose of any of these systems is to manage the various versions in some body of content. So I reassert that "version control" or "revision control" or "change control" is the best name.
And by the way, the fact that the name is confusing does matter, especially for a free software project. If you're trying to appeal to developers, its best to pick a name that won't confuse all the students who haven't been corrputed by industry jargon. :-)