Aricle 1 section 8 gives Congress the power to grant copyright and patent protection, as you said, "if they choose to do so." It doesn't say what those rights actually are, or enumerate which rights are accorded the author vs. the public.
So yes, I was overly broad in claiming the constitution says "nothing" about copyright and was being juvenile in using word search results to try to make my point--my bad. A law granting authors copyright in perpetuity would be clearly unconstitutional, for example.
The right of First Sale, however, would only be "constitutional" (as claimed by the author to which I was responding) to the extent that First Sale "promote[s] the Progress of Science and useful Arts," which is by no means explicitly specified or necessarily a given.
In this case, the specific constitutional language gives congress authority to limit rights, it doesn't specifically protect any public right apart from the general promotion of progress.
And all that said, yes, I do know that First Sale on the part of the public is an established part of Copyright, and personally agree with everyone who wants to see that protected when it comes to DRM. I just don't think you can claim it's a right protected by the constitution per se. I think people are too quick to wave around the word "unconstitutional" every time rights are involved.
The U.S. Constitution says nothing about copyright. The string "copy" doesn't appear once, the word "work" only shows up about not compelling a type of labor by traitors, and "publish" is only used to require the legislators and treasury to publicize proceedings and financial statements.
Copyright in the U.S. is defined by the legal code, not the Constitution.
Evidence of a political viewpoint doesn't necessarily preclude either side's ability to be genuinely civic-minded, even when it's in support of political goals. Are Republican- and Democrat-run voter registration drives somehow "illegitimate" because they try to bolster the voter rolls where they have statistical advantages? Of course not, because increasing voter participation is a Good Thing.
In fact, conservatives ought to be getting involved in this because PAW is behind it. If Bush wins and a PAW-backed organization has observed little evidence of voter disenfranchisement, it will strengthen the legitimacy of the victory. A variety of volunteers of various political stripes would help ensure the training isn't biased. And if the organization were to bald-facedly turn away volunteers whose political views don't line up with theirs, it would provide concrete evidence that it's the sham you're assuming it will be.
It's hard for me to see the downside in increasing visibility and transparency in the election, and to try to make sure everyone gets a fair chance to vote, regardless of who initiates the effort. I'd be applauding just as loudly if it were a right-wing organization trying to curb real or perceived left-wing excesses.
A U.S. organization is seeking volunteers to help monitor elections in cities where there is historic concern about voter disenfranchisement: http://www.electionprotection.org/.
They're seeking volunteers, especially lawyers, law students and clergy, to become trained and help with the effort.
I'm not connected with the organization, I just think it's a good idea.
So the idea has been presented to the FTC, the ACM, the NBER and the ITU. Big deal. What about the Internet Engineering Task Force, guys? They have more than a little to do with setting standards for the Internet. Technical flaws aside, any effort to change the way email gets handled that tries to end-run the IETF is doomed to failure anyway.
On the SCons project, we've been heavy users of a Test-Drive Development methodology from day one of the project (coming up on three years now).
SCons is a next-generation build tool, or make tool, written in Python with strong cross-platform support, integrated autoconf-like functionality, a lot of stable features, and a growing user community.
We're currently at 14K+ lines of non-comment, non-blank source code,
and 32K+ lines of non-comment, non-blank test code.
We use a combination of two different testing methodologies:
1) Individual modules all have PyUnit unit tests (similar to JUnit, but in Python, of course).
2) The SCons application itself is tested using a custom testing module that manages creation of temporary directories and files, execution of the application, and checking against expected results.
This custom module is actually a wrapper around a generic "test any script/command" infrastructure module that could be easily
used to test other scripts and/or commands.
(The command under test could be implemented in any language, not just in Python.)
I use the
Aegis change management system to manage the SCons development and testing cycle. Aegis' primary value add (for me) is its management of the test cases and the testing methodology it enforces. By default, all Aegis changes must have one or more modified or new tests. The new/modified tests must not only pass when run against the new code, but must (by default) fail when run against the old code. This helps guarantee that your tests are good, and that your code isn't passing because you made a mistake in your test and forgot to call the new feature.
By testing in this fashion from day one, we've built up a very strong regression test base--284 test scripts at last count, each script containing multiple individual tests. This test base has become crucial to our ability to refactor (and refactor and refactor...) the internals as we add more features. Sometimes it takes longer, of course, to make a rewrite satisfy all of the regression tests, but when you're done, you can be pretty sure you haven't broken anything. And if you did break something, then you have to add or modify a test when you fix it, and that becomes another part of the regression test base.
The key to getting going with this kind of test-driven development (in my opinion) is making writing and executing the tests as simple as possible (but no simpler!). If writing a test is too difficult, then a lot of developers will simply avoid it. But if you can get them over the initial hump by making it easy to write tests, it gets downright addictive because you get all of this positive feedback when your tests show you that your new code works.
We'd be glad to have you check out the testing infrastructure we've developed for SCons, either for code you can actually use, or simply as a source of ideas. Feel free to contact the SCons development team if you have any questions.
a question I wish had been asked
on
The Voice of Groklaw
·
· Score: 4, Insightful
In addition to asking, "What are the three things you like best about open source software?" and "What are the five things you dislike most about proprietary software?" I really really really wish the interviewer had asked, "What are the N things you like least about open source software?"
Jones is a savvy user, and her ideas for what needs improvement would be valuable, provided we listen and react to input such as hers.
The props are nice, but don't help identify what we need to improve as much as good, honest feedback does.
I'd like your permission to quote your
comments about your experience with SCons (from the Slashdot thread back in July) on the SCons web site. Could you drop me a line at webmaster@NOSPAMscons.org to let me know if that's cool with you? Thanks!
Sorry for the OT post, I couldn't find another handy way to get in touch.
I've always seen Forking as something of a blessing... it's the abandoned projects are the ones that are in danger.
Yes, if you only look at the effect on the projects themselves (that is, the software developers involved). But what about the users of the projects?
At best, a Fork means that a project's users have to understand some technical (or political) differences that caused the Fork, and pick one project or another. At worst, they have to stick with an unsupported version of the software, or convert all their old files to some new format, or something equally unappealing.
As a software developer, I'm all for the idea that forking is software evolution in action, better projects survive and less viable ones die out, etc., etc. But that doesn't mean we can ignore the fact that Forking causes (or can cause) extra work and potential loss of investment to users who may not be able to afford it.
I'd like your permission to quote
your comments
about your experience with SCons (from the Slashdot
thread
back in July)
on the SCons web site.
Could you drop me a line at webmaster@NOSPAMscons.org
to let me know if that's cool with you? Thanks!
Sorry for the OT post, I couldn't find another ready way to get in touch...
One of the significant differentiators between RHEL and Fedora is that RHEL will continue to benefit from Red Hat's QA resources, while Fedora will now rely on "community testing" for QA.
To what extent is Red Hat part of the "Fedora community" for QA purpose? If Red Hat QA finds bugs in the Fedora Core from which RHEL draws, will Red Hat contribute bug reports and/or patches back to Fedora, so that the community as a whole will benefit from that work?
Since Red Hat is naturally interested in maintaining some sort of differentiation to give people incentive to purchase RHEL, what criteria will govern when Red Hat would or would not contribute bug reports and/or patches to Fedora?
You're self-selecting for good "kids" movies and ignoring the drek.
Pixar has a stellar track record largely because John Lasseter (who spent most of his early career at Disney, BTW) understands and values how to tell an engaging story. Pixar spends a lot of time and energy on getting the story right, and the results speak for themselves in terms of quality of the movie. When you combine that with Disney's marketing muscle, you get good box office.
The others you mention are great films, but the box office record is mixed. Ice Age was a hit, but Iron Giant but did pretty lousy box office ($23M domestically in four years) despite being a great film. Spirited Away is stunning, but didn't crack the mainstream U.S. market (only $10M U.S., although it did do $260M worldwide).
But the real point is: For every one of the artistic successes you mention, there are many more lousy kids pictures. Go to Blockbuster with any parent who's trying to find a good kids movie that's also watchable by adults. There's a ton of crap there,
just like there is in any genre.
The fact that there are, thank goodness, examples of good kids/animated features we can point to doesn't mean
that it's significantly easier to write or make a good kids movie than it is any other kind of movie.
how hard can it be to make an entertaining kids movie
Pretty damn hard. If it's so easy, why are there so few really entertaining movies for kids? Why are Shrek and Finding Nemo the exceptions, rather than the rule? Hollywood studios would be falling all over themselves making "entertaining kids movies" if it were that easy to make them, and to make money doing them. The great graphics serve the story, not the other way around.
Another poster got this right: The reason that movies like Shrek and Finding Nemo are the rare gems that they are is because they're well-written, engaging stories with real characters, not worn-out, thread bare plots with a "couple of childish jokes and a couple farts."
Good writing is hard to come by and difficult to create, no matter the genre.
...and consumers get a ditro, just as before, but the name will be different,
No, not just as before: Fedora does not have Red Hat QA behind it (check the comparison chart). How stable Fedora remains will depend on how quickly they can put together good community QA (a la Debian).
If I were to guess, I'd say you've never run Debian, and never known anyone who has.
No, I'm well aware of how good a release Debian is, but Debian has had many years now to develop a good community QA process. The idea that the newly-formed Fedora community will be able to provide the same level of QA, without the dedicated QA resources that Red Hat used to provide and without the ramp-up time that Debian has had, is a bit of a stretch.
I would certainly hope that Fedora will adopt a lot of the best Debian QA practices, but that's going to take some time to develop, and I think it's realistic to expect some bumps during the transition period. But Debian does demonstrate that it's possible, so like I said, I'll be absolutely thrilled if I'm proven wrong...
Also, I suppose it's possible that Red Hat QA will be involved in Fedora in some way (as another post pointed out), which could keep Fedora on an even keel. Red Hat's own pages, though, very clearly state that Red Hat's QA testing is one of the added values you get from purchasing RHEL...
Well, not totally ridiculous, if you ignore the "Red Hat sucks" part of the rant and look at the substantive issue about what retail Linux users are losing.
What I'm going to miss is Red Hat QA, which to me was the real value-add of Red Hat and which is not part of what you get with your free Fedora download. (Check out the last two lines in the comparison chart
with the Enterprise Linux version.)
Due to Red Hat's QA, I always had a high degree of confidence that what I would get from up2date wouldn't break my RH system. Call me paranoid, but I don't have the same degree of confidence that the "developer community" will have the resources (time, machines and testing methodology) to maintain the same level of quality, especially given that the code base in Fedora will be apparently much larger than RHEL. I will be delighted if I'm wrong, but I'm expecting a gradual decline in quality.
Increasing the amount of support you get for $179 if you buy RHEL is okay so far as it goes, but that doesn't change the fact that the increase will price the QA-tested product out of many Linux users' home-computing budget (including mine).
I don't really blame Red Hat, because I think this move does make business sense for them. But I'm really disappointed that the retail Linux market never materialized to the point where they could keep shipping a high-quality, tested Linux desktop for ~$50-$70 and make money doing it.
In many cases, commercially used open source software is developed by organizations such as Red Hat and IBM who, we hope, have significant QA teams and resources.
In fact, I'd argue that in most cases, the QA is the primary added value of a commercially-backed open source offering.
Monta Vista, for example, test their embedded Linux system on upwards of 80 (last I heard) combinations of compilation platform + cross-compiler + execution environment. Yes, they contribute a great deal of code and give back a lot to the Linux community. But as someone who has to back the decision to go with Monta Vista for our product, the QA is more valuble to me. If they stopped hacking the kernel themselves and kept their test process, the releases would come more slowly but I could still sleep at night using their product. But if they cut the QA and kept just the coders, I'd have to seriously question the viability of basing our product on them in the future.
Similar argument for the desk top: the real value of a commercial distro to me is the time I save not having to test the individual packages and get them to interoperate by hand.
Even so, aediff, aepatch, aeimport, and aecomp look rather fundamental.
Umm... They're not fundamental. At least, I can personally vouch that I never use any of them, and I've been using Aegis heavily for five years. (No, wait, I can remember using aepatch once--it generates an incremental change set in an cpio-based Aegis format for distribution to other sites or other branches.)
So you obviously didn't RTFM...
...making these commands incomptable in cases where the incompatability is unnecessary is an unnecessary disadvantage.
...but you somehow know enough about how Aegis is designed to have already determined, after a quick sniff, that the design decisions were "unnecessary."
I see.
Hey, guess what? I can shout while quoting your original post, too...:-) :
I also think that it could be implemented more simply as a separate package that used some kind of cvs successor
(or, ideally, was retargetable to a number of software repository types).
And, as I've pointed out, Aegis is retargetable to any number of source-code management models and repository types.
So when your uber-CVS gets invented,
my assertion is that the Aegis model will handle it just fine, thank you.
And I'm confident of that because I've actually been using Aegis and experiencing its flexibility first-hand.
aegis apparently has a layer for representing these types of transactions (that operates on top of an existing file-based revision control system such as sccs or rcs). That layer is what I think should be separate, as I think it has much broader applicability.
And based on my experience with it,
Aegis is a separate layer that leaves the details of source code management and building software to the underlying utilities, which sounds to me exactly like the kind of separability you
seem to think is a good idea...
So are we just violently agreeing?:-)
More specifically, it seems like you're noticing that Aegis accomodates file-based source-code management systems like SCCS and RCS, and leaping to the conclusion that it doesn't do other things that you'd like.
But Aegis does operate on atomic change sets, handles symlinks and file renames just fine,
and has a proven distributed development model.
The only capability you list that I'm not sure about is inode information, but that's simply because I don't know how you'd want that tied in to your process layer. If the underlying (source-code and build) tools handle inode information just fine, I'd be highly surprised if Aegis would even blink.
Look, I'm not saying you, or anyone else, have to like Aegis. Its command syntax evidently rubbed you the wrong way, and that's fine. But out of that initial bad taste, you're making assertions about what Aegis' design can handle that are demonstrably not true. I'm frankly at a loss as to why you don't just admit the fact that, based on an initial cursory glance, you had some misimpressions about what Aegis could do, and no real harm done.
Aegis installs 17 new programs (at least they begin with "ae") plus an "aegis" program that is designed to implement yet another command syntax in an attempt to ameliorate the complexity of the ae* programs
This is a misrepresentation. The aegis program itself is not to "ameliorate the complexity" of other programs, it is the workhorse that implements the process and is
the only executable
the vast majority of users
will end up running.
The other ae* programs are for
ancillary functions like generating reports,
distributing change sets,
command completion, etc.
They need only be learned as needed,
or by an administrator,
in much the same way that not every developer who
uses CVS has to learn the branching mechanisms.
Perhaps you feel that the argument syntax of these 17 new programs is a great improvement over cvs (but readers may notice that you don't explain why)...
No, I think I stated why I consider Aegis a huge step forward from underlying, raw source-code management commands, and it is for far more important reasons than command-line syntax.
Among other reasons, Aegis is worth the learning curve because, once configured, you sidestep having to be preoccupied with the particular syntax or specific model of an underlying source-code management system. You get to focus not on managing your
source-code tree,
but on developing and testing your softare. That's supposed to be the whole point of good tools, yes?
(If we're going to point out parts of the argument that are being ignored, though, I didn't see anything explaining why you think Aegis isn't separable from the underlying source-code management after I pointed out that it can be configured to use any package.:-)
This makes me realize that I'm confused about one seeming inconsistency: you complain on the one hand that Aegis isn't separate enough from the source-code package, and at the same time say that isn't enough like CVS or RCS or whatever you'd like it to look more like. Perhaps I'm missing your underlying point...?)
...in which case I'll leave it to interested readers to check out some of the aegis manual pages and form their own conclusions.
Agreed; one size doesn't fit all,
so people should figure out if the Aegis model (or any other process/tool set) is appropriate for their needs.
Forewarned is forearmed, as they say...
Aegis has a bit of an unncessary learning curve because Aegis does not use commands compatible with cvs, sccs or rcs when this is possible.
Aegis is a process wrapper around any of those source code management systems, so it's doing a great deal more. I view the fact that Peter Miller chose not to just pass-through the (often clunky) underlying syntax of the source-code management commands to be a great strength of Aegis, not a weakness. Why? I can develop on any Aegis project and not have to know or care what underlying source code management system is being used. I get to focus on developing and testing code, not the specifics of wrestling with RCS or SCCS or CVS or fhist.
In other words, it's an abstraction layer, and as in any abstraction, you lose a little fine-grained control. But in my experience this is more than offset by the benefits. I personally use Aegis on multiple projects; some older ones still use RCS, while I've started using CVS on some newer ones as my tastes have changed over time. Guess what? I've been able to do this without having to re-learn my development methodology, because I've been using Aegis to wrap the underlying source-code management details.
I think Aegis's repository control based on regression testing is a great idea...
Hear, hear. This is very well-thought-out in Aegis, and a huge win.
...but I also think that it could be implemented more simply as a separate package that used some kind of cvs successor (or, ideally, was retargetable to a number of software repository types).
Ummm... it already is a separate packge. You can use Aegis in conjunction with RCS, SCCS, CVS, fhist, or (probably just about) any other underlying source code management system by configuring the appropriate commands into the project config file. What makes you think Aegis isn't already separate enough from the
underlying source code management?
Slashdot Mirror
So yes, I was overly broad in claiming the constitution says "nothing" about copyright and was being juvenile in using word search results to try to make my point--my bad. A law granting authors copyright in perpetuity would be clearly unconstitutional, for example.
The right of First Sale, however, would only be "constitutional" (as claimed by the author to which I was responding) to the extent that First Sale "promote[s] the Progress of Science and useful Arts," which is by no means explicitly specified or necessarily a given. In this case, the specific constitutional language gives congress authority to limit rights, it doesn't specifically protect any public right apart from the general promotion of progress.
And all that said, yes, I do know that First Sale on the part of the public is an established part of Copyright, and personally agree with everyone who wants to see that protected when it comes to DRM. I just don't think you can claim it's a right protected by the constitution per se. I think people are too quick to wave around the word "unconstitutional" every time rights are involved.
Try reading the Constitution yourself.
The U.S. Constitution says nothing about copyright. The string "copy" doesn't appear once, the word "work" only shows up about not compelling a type of labor by traitors, and "publish" is only used to require the legislators and treasury to publicize proceedings and financial statements.
Copyright in the U.S. is defined by the legal code, not the Constitution.
In this vein, Hollywood's standard saying is, "Film is a collaborative medium."
David Mamet amended this to summarize Hollywood's attitudes towards writers: "Film is a collaborative medium; bend over."
In fact, conservatives ought to be getting involved in this because PAW is behind it. If Bush wins and a PAW-backed organization has observed little evidence of voter disenfranchisement, it will strengthen the legitimacy of the victory. A variety of volunteers of various political stripes would help ensure the training isn't biased. And if the organization were to bald-facedly turn away volunteers whose political views don't line up with theirs, it would provide concrete evidence that it's the sham you're assuming it will be.
It's hard for me to see the downside in increasing visibility and transparency in the election, and to try to make sure everyone gets a fair chance to vote, regardless of who initiates the effort. I'd be applauding just as loudly if it were a right-wing organization trying to curb real or perceived left-wing excesses.
A U.S. organization is seeking volunteers to help monitor elections in cities where there is historic concern about voter disenfranchisement: http://www.electionprotection.org/. They're seeking volunteers, especially lawyers, law students and clergy, to become trained and help with the effort. I'm not connected with the organization, I just think it's a good idea.
So the idea has been presented to the FTC, the ACM, the NBER and the ITU. Big deal. What about the Internet Engineering Task Force, guys? They have more than a little to do with setting standards for the Internet. Technical flaws aside, any effort to change the way email gets handled that tries to end-run the IETF is doomed to failure anyway.
SCons is a next-generation build tool, or make tool, written in Python with strong cross-platform support, integrated autoconf-like functionality, a lot of stable features, and a growing user community. We're currently at 14K+ lines of non-comment, non-blank source code, and 32K+ lines of non-comment, non-blank test code.
We use a combination of two different testing methodologies: 1) Individual modules all have PyUnit unit tests (similar to JUnit, but in Python, of course). 2) The SCons application itself is tested using a custom testing module that manages creation of temporary directories and files, execution of the application, and checking against expected results. This custom module is actually a wrapper around a generic "test any script/command" infrastructure module that could be easily used to test other scripts and/or commands. (The command under test could be implemented in any language, not just in Python.)
I use the Aegis change management system to manage the SCons development and testing cycle. Aegis' primary value add (for me) is its management of the test cases and the testing methodology it enforces. By default, all Aegis changes must have one or more modified or new tests. The new/modified tests must not only pass when run against the new code, but must (by default) fail when run against the old code. This helps guarantee that your tests are good, and that your code isn't passing because you made a mistake in your test and forgot to call the new feature.
By testing in this fashion from day one, we've built up a very strong regression test base--284 test scripts at last count, each script containing multiple individual tests. This test base has become crucial to our ability to refactor (and refactor and refactor...) the internals as we add more features. Sometimes it takes longer, of course, to make a rewrite satisfy all of the regression tests, but when you're done, you can be pretty sure you haven't broken anything. And if you did break something, then you have to add or modify a test when you fix it, and that becomes another part of the regression test base.
The key to getting going with this kind of test-driven development (in my opinion) is making writing and executing the tests as simple as possible (but no simpler!). If writing a test is too difficult, then a lot of developers will simply avoid it. But if you can get them over the initial hump by making it easy to write tests, it gets downright addictive because you get all of this positive feedback when your tests show you that your new code works.
We'd be glad to have you check out the testing infrastructure we've developed for SCons, either for code you can actually use, or simply as a source of ideas. Feel free to contact the SCons development team if you have any questions.
Jones is a savvy user, and her ideas for what needs improvement would be valuable, provided we listen and react to input such as hers. The props are nice, but don't help identify what we need to improve as much as good, honest feedback does.
On the whole, though, a pretty good interview...
I'd like your permission to quote your comments about your experience with SCons (from the Slashdot thread back in July) on the SCons web site. Could you drop me a line at webmaster@NOSPAMscons.org to let me know if that's cool with you? Thanks!
Sorry for the OT post, I couldn't find another handy way to get in touch.
Yes, if you only look at the effect on the projects themselves (that is, the software developers involved). But what about the users of the projects?
At best, a Fork means that a project's users have to understand some technical (or political) differences that caused the Fork, and pick one project or another. At worst, they have to stick with an unsupported version of the software, or convert all their old files to some new format, or something equally unappealing.
As a software developer, I'm all for the idea that forking is software evolution in action, better projects survive and less viable ones die out, etc., etc. But that doesn't mean we can ignore the fact that Forking causes (or can cause) extra work and potential loss of investment to users who may not be able to afford it.
I'd like your permission to quote your comments about your experience with SCons (from the Slashdot thread back in July) on the SCons web site. Could you drop me a line at webmaster@NOSPAMscons.org to let me know if that's cool with you? Thanks!
Sorry for the OT post, I couldn't find another ready way to get in touch...
To what extent is Red Hat part of the "Fedora community" for QA purpose? If Red Hat QA finds bugs in the Fedora Core from which RHEL draws, will Red Hat contribute bug reports and/or patches back to Fedora, so that the community as a whole will benefit from that work? Since Red Hat is naturally interested in maintaining some sort of differentiation to give people incentive to purchase RHEL, what criteria will govern when Red Hat would or would not contribute bug reports and/or patches to Fedora?
Pixar has a stellar track record largely because John Lasseter (who spent most of his early career at Disney, BTW) understands and values how to tell an engaging story. Pixar spends a lot of time and energy on getting the story right, and the results speak for themselves in terms of quality of the movie. When you combine that with Disney's marketing muscle, you get good box office.
The others you mention are great films, but the box office record is mixed. Ice Age was a hit, but Iron Giant but did pretty lousy box office ($23M domestically in four years) despite being a great film. Spirited Away is stunning, but didn't crack the mainstream U.S. market (only $10M U.S., although it did do $260M worldwide).
But the real point is: For every one of the artistic successes you mention, there are many more lousy kids pictures. Go to Blockbuster with any parent who's trying to find a good kids movie that's also watchable by adults. There's a ton of crap there, just like there is in any genre.
The fact that there are, thank goodness, examples of good kids/animated features we can point to doesn't mean that it's significantly easier to write or make a good kids movie than it is any other kind of movie.
Pretty damn hard. If it's so easy, why are there so few really entertaining movies for kids? Why are Shrek and Finding Nemo the exceptions, rather than the rule? Hollywood studios would be falling all over themselves making "entertaining kids movies" if it were that easy to make them, and to make money doing them. The great graphics serve the story, not the other way around.
Another poster got this right: The reason that movies like Shrek and Finding Nemo are the rare gems that they are is because they're well-written, engaging stories with real characters, not worn-out, thread bare plots with a "couple of childish jokes and a couple farts."
Good writing is hard to come by and difficult to create, no matter the genre.
No, not just as before: Fedora does not have Red Hat QA behind it (check the comparison chart). How stable Fedora remains will depend on how quickly they can put together good community QA (a la Debian).
No, I'm well aware of how good a release Debian is, but Debian has had many years now to develop a good community QA process. The idea that the newly-formed Fedora community will be able to provide the same level of QA, without the dedicated QA resources that Red Hat used to provide and without the ramp-up time that Debian has had, is a bit of a stretch.
I would certainly hope that Fedora will adopt a lot of the best Debian QA practices, but that's going to take some time to develop, and I think it's realistic to expect some bumps during the transition period. But Debian does demonstrate that it's possible, so like I said, I'll be absolutely thrilled if I'm proven wrong...
Also, I suppose it's possible that Red Hat QA will be involved in Fedora in some way (as another post pointed out), which could keep Fedora on an even keel. Red Hat's own pages, though, very clearly state that Red Hat's QA testing is one of the added values you get from purchasing RHEL...
What I'm going to miss is Red Hat QA, which to me was the real value-add of Red Hat and which is not part of what you get with your free Fedora download. (Check out the last two lines in the comparison chart with the Enterprise Linux version.)
Due to Red Hat's QA, I always had a high degree of confidence that what I would get from up2date wouldn't break my RH system. Call me paranoid, but I don't have the same degree of confidence that the "developer community" will have the resources (time, machines and testing methodology) to maintain the same level of quality, especially given that the code base in Fedora will be apparently much larger than RHEL. I will be delighted if I'm wrong, but I'm expecting a gradual decline in quality.
Increasing the amount of support you get for $179 if you buy RHEL is okay so far as it goes, but that doesn't change the fact that the increase will price the QA-tested product out of many Linux users' home-computing budget (including mine).
I don't really blame Red Hat, because I think this move does make business sense for them. But I'm really disappointed that the retail Linux market never materialized to the point where they could keep shipping a high-quality, tested Linux desktop for ~$50-$70 and make money doing it.
In many cases, commercially used open source software is developed by organizations such as Red Hat and IBM who, we hope, have significant QA teams and resources.
In fact, I'd argue that in most cases, the QA is the primary added value of a commercially-backed open source offering.
Monta Vista, for example, test their embedded Linux system on upwards of 80 (last I heard) combinations of compilation platform + cross-compiler + execution environment. Yes, they contribute a great deal of code and give back a lot to the Linux community. But as someone who has to back the decision to go with Monta Vista for our product, the QA is more valuble to me. If they stopped hacking the kernel themselves and kept their test process, the releases would come more slowly but I could still sleep at night using their product. But if they cut the QA and kept just the coders, I'd have to seriously question the viability of basing our product on them in the future.
Similar argument for the desk top: the real value of a commercial distro to me is the time I save not having to test the individual packages and get them to interoperate by hand.
Even so, aediff, aepatch, aeimport, and aecomp look rather fundamental.
Umm... They're not fundamental. At least, I can personally vouch that I never use any of them, and I've been using Aegis heavily for five years. (No, wait, I can remember using aepatch once--it generates an incremental change set in an cpio-based Aegis format for distribution to other sites or other branches.)
So you obviously didn't RTFM...
I see.
Hey, guess what? I can shout while quoting your original post, too... :-) :
I also think that it could be implemented more simply as a separate package that used some kind of cvs successor (or, ideally, was retargetable to a number of software repository types).
And, as I've pointed out, Aegis is retargetable to any number of source-code management models and repository types. So when your uber-CVS gets invented, my assertion is that the Aegis model will handle it just fine, thank you. And I'm confident of that because I've actually been using Aegis and experiencing its flexibility first-hand.
aegis apparently has a layer for representing these types of transactions (that operates on top of an existing file-based revision control system such as sccs or rcs). That layer is what I think should be separate, as I think it has much broader applicability.
And based on my experience with it, Aegis is a separate layer that leaves the details of source code management and building software to the underlying utilities, which sounds to me exactly like the kind of separability you seem to think is a good idea... So are we just violently agreeing? :-)
More specifically, it seems like you're noticing that Aegis accomodates file-based source-code management systems like SCCS and RCS, and leaping to the conclusion that it doesn't do other things that you'd like. But Aegis does operate on atomic change sets, handles symlinks and file renames just fine, and has a proven distributed development model. The only capability you list that I'm not sure about is inode information, but that's simply because I don't know how you'd want that tied in to your process layer. If the underlying (source-code and build) tools handle inode information just fine, I'd be highly surprised if Aegis would even blink.
Look, I'm not saying you, or anyone else, have to like Aegis. Its command syntax evidently rubbed you the wrong way, and that's fine. But out of that initial bad taste, you're making assertions about what Aegis' design can handle that are demonstrably not true. I'm frankly at a loss as to why you don't just admit the fact that, based on an initial cursory glance, you had some misimpressions about what Aegis could do, and no real harm done.
Aegis installs 17 new programs (at least they begin with "ae") plus an "aegis" program that is designed to implement yet another command syntax in an attempt to ameliorate the complexity of the ae* programs
This is a misrepresentation. The aegis program itself is not to "ameliorate the complexity" of other programs, it is the workhorse that implements the process and is the only executable the vast majority of users will end up running. The other ae* programs are for ancillary functions like generating reports, distributing change sets, command completion, etc. They need only be learned as needed, or by an administrator, in much the same way that not every developer who uses CVS has to learn the branching mechanisms.
Perhaps you feel that the argument syntax of these 17 new programs is a great improvement over cvs (but readers may notice that you don't explain why)...
No, I think I stated why I consider Aegis a huge step forward from underlying, raw source-code management commands, and it is for far more important reasons than command-line syntax. Among other reasons, Aegis is worth the learning curve because, once configured, you sidestep having to be preoccupied with the particular syntax or specific model of an underlying source-code management system. You get to focus not on managing your source-code tree, but on developing and testing your softare. That's supposed to be the whole point of good tools, yes?
(If we're going to point out parts of the argument that are being ignored, though, I didn't see anything explaining why you think Aegis isn't separable from the underlying source-code management after I pointed out that it can be configured to use any package. :-)
This makes me realize that I'm confused about one seeming inconsistency: you complain on the one hand that Aegis isn't separate enough from the source-code package, and at the same time say that isn't enough like CVS or RCS or whatever you'd like it to look more like. Perhaps I'm missing your underlying point...?)
Agreed; one size doesn't fit all, so people should figure out if the Aegis model (or any other process/tool set) is appropriate for their needs. Forewarned is forearmed, as they say...
Aegis is a process wrapper around any of those source code management systems, so it's doing a great deal more. I view the fact that Peter Miller chose not to just pass-through the (often clunky) underlying syntax of the source-code management commands to be a great strength of Aegis, not a weakness. Why? I can develop on any Aegis project and not have to know or care what underlying source code management system is being used. I get to focus on developing and testing code, not the specifics of wrestling with RCS or SCCS or CVS or fhist.
In other words, it's an abstraction layer, and as in any abstraction, you lose a little fine-grained control. But in my experience this is more than offset by the benefits. I personally use Aegis on multiple projects; some older ones still use RCS, while I've started using CVS on some newer ones as my tastes have changed over time. Guess what? I've been able to do this without having to re-learn my development methodology, because I've been using Aegis to wrap the underlying source-code management details.
I think Aegis's repository control based on regression testing is a great idea...
Hear, hear. This is very well-thought-out in Aegis, and a huge win.
Ummm... it already is a separate packge. You can use Aegis in conjunction with RCS, SCCS, CVS, fhist, or (probably just about) any other underlying source code management system by configuring the appropriate commands into the project config file. What makes you think Aegis isn't already separate enough from the underlying source code management?