So now you are saying that subversion doesnt work with open source projects but does for closed source? I am getting really confused...
I think he's saying that many organizations don't have the resources to make a tool like subversion worthwhile. You may have an environment where memory and disk are plentiful, but some of us don't. It was pointed out that many open source projects fit into the latter category.
I own 4 workstations and the sum of the parts of all 4 don't match the specs of the machines you work with. Given the similar feature sets of subversion and CVS there is no way that you'll convince me that the cost of the resources necessary to use a subversion repository is justifiable, the ROI just isn't there when I can run a CVS repository easily on an old or low power machine.
This isn't even considering the benfits of familiarity with CVS and RCS. Subversion is a useful tool, I'm sure it will steadily improve as time goes on, but it's not perfect and certainly doesn't fit every situation.
... it means switching to a systems programming language that has error checking by default but still gives you all the low-level features you need when you need them. There have been a number of such languages over the years, but, unfortunately, they were all killed by C, not because C was better, but because C shipped with UNIX.
I don't think you understand the "low-level" appeal of C, error checking and other useful security features like strong typing are not low-level. The ability to break abstractions and treat memory as memory instead of data is both the cause of C's problems and the force behind C's use. The problem isn't C being included in Unix (dozens of languages are included in most modern Unix environments), the problem is that C is genuinely useful for the same reasons that it is hard to secure.
It's the old-BSD obnoxious advertising clause all over again. So maybe it is an appropriate license...
The BSD advertising clause wouldn't require a false statement, since it uses the wording "... includes software developed by..." and even then it's only required where you advertise the features of the BSD licensed software.
All advertising materials mentioning features or use of this software
must display the following acknowledgement:
This product includes software developed by the University of California, Berkeley and its contributors.
Nothing much, there was a few additions to the base system, unfinished installers that didn't even make it into CVS. There was a BSD licensed clone of dialog (which lives with MirOS now).
how long has this logo been in the running? they manage to mention it constantly, but never actually give any information on it. just strikes me as a bit odd.
They started it in January, and it closed at the end of February. It was announced on at least their advocacy mailing list, and was on their news section on the front page of NetBSD.org at the time. They've been choosing a winner since then.
Speaking as a computer engineer who passed the FE (on my first try) - the FE is most definitely biased in favor of civil and mechanical engineers, and against electrical and chemical. That being said, there's really very little incentive for EEs to take it. The only things you need it for are government work or testifying in court.
The requirements to be an Engineer vary from place to place as well. In Canada there is a national organization that sets out an approved curriculum including some basic education in all fields of engineering. This curriculum is then used by the provincial associations (which were created by legislation to prevent untrained people from practicing engineering) as criteria for membership (there is also an exam based route for those who didn't attend a Canadian university).
I'm a Canadian computer engineer who took the NCEES FE exam just in case I move to the US. I passed on my first try as well and found that the material was pretty representative of the material covered in the courses I took.
However, it really gets under my skin when people call themselves "engineers" and they have *no clue* about engineering in general.
I strongly agree. There is a strong emphasis on responsibility and correctness in the Engineering profession that isn't adhered to by many people who call themselves engineers
In the case of a school course, it *is* a valid complaint to point out that a stated given was a lie, and that's why the program doesn't work. If the givens say your program has to take a list of up to 1000 items, and the test data contains 2000 items, then that is a legitimate reason for the student to complain.
I'm not talking about valid complaints here, though the example whining I gave didn't really make that clear. The best example I can think of was an assignment (I forget exactly what it was now) that was reading some sort of data from a file. The specifications explicitly said that the programs should handle incorrect input, but many students still complained afterwards about the use of an empty file as a test case.
I don't think that students should have to above and beyond the project specification, and I know all about time constraints since I had a heavier class load then most of the students in those classes. But to actually complain because you didn't add the three extra lines it would take to handle an empty file, and for the professor to accept such complaints, seems to encourage programmers that do the absolute minimum specified to get the job done.
This certainly was not the case when I was in school. They definitely started checking nasty edge cases in intro CS courses, which was frequently automated, and it got worse from there. I remember my Operating Systems TAs being particularly evil testers. Maybe it's the case that most universities don't do this? That's a scary thought.
My experience was that most instructors tried to impress upon students the importance of correct code, and the TAs tested for it. But soon after the marks came back there was a chorus of complaints in the newsgroups "You never said we had to handle that condition", or "I didn't understand the specification ", and unfortunately the instructors caved in many occasions.
That's not to say that nobody came out of the classes with the ability and desire to write code well, but the ones who slid by on complaints and shoddy programs came out as well.
I agree, Dillon looks to be making serious work and serious progress with DragonFly, whereas Micro, Mir, ekko and Pico all appear to be goalless, understaffed and the staff they have do not seem to be as talented as the likes of Dillon or de Raadt.
There aren't many people in any community who can claim to be as dedicated and talented at Matt Dillon or Theo de Raadt, and understaffing is a problem that I know the ekkoBSD and MirOS teams would like to solve.
... I think that Net will eventually die out, gloomy as it is, the goal of being on every platform is hardly a thing to unite a project in my mind. Though, as I've said a few times as a chant against flamming, that is just my opinion.
That opinion isn't uncommon, but there are a notable number of people who appreciate NetBSD because of their attention to architectural and technical detail. I think NetBSD will last for a long time to come. As you disclaimed, this is all IMHO
Slashdot Mirror
I use it to lure muggers, then beat the crap out of them with the bag because my laptop weighs a ton.
So now you are saying that subversion doesnt work with open source projects but does for closed source? I am getting really confused...
I think he's saying that many organizations don't have the resources to make a tool like subversion worthwhile. You may have an environment where memory and disk are plentiful, but some of us don't. It was pointed out that many open source projects fit into the latter category.
I own 4 workstations and the sum of the parts of all 4 don't match the specs of the machines you work with. Given the similar feature sets of subversion and CVS there is no way that you'll convince me that the cost of the resources necessary to use a subversion repository is justifiable, the ROI just isn't there when I can run a CVS repository easily on an old or low power machine.
This isn't even considering the benfits of familiarity with CVS and RCS. Subversion is a useful tool, I'm sure it will steadily improve as time goes on, but it's not perfect and certainly doesn't fit every situation.
I don't think you understand the "low-level" appeal of C, error checking and other useful security features like strong typing are not low-level. The ability to break abstractions and treat memory as memory instead of data is both the cause of C's problems and the force behind C's use. The problem isn't C being included in Unix (dozens of languages are included in most modern Unix environments), the problem is that C is genuinely useful for the same reasons that it is hard to secure.
The BSD advertising clause wouldn't require a false statement, since it uses the wording "... includes software developed by ..." and even then it's only required where you advertise the features of the BSD licensed software.
That's not nearly as unreasonable as the FDLNothing much, there was a few additions to the base system, unfinished installers that didn't even make it into CVS. There was a BSD licensed clone of dialog (which lives with MirOS now).
They started it in January, and it closed at the end of February. It was announced on at least their advocacy mailing list, and was on their news section on the front page of NetBSD.org at the time. They've been choosing a winner since then.
Mailing list announcement
NetBSD news
The requirements to be an Engineer vary from place to place as well. In Canada there is a national organization that sets out an approved curriculum including some basic education in all fields of engineering. This curriculum is then used by the provincial associations (which were created by legislation to prevent untrained people from practicing engineering) as criteria for membership (there is also an exam based route for those who didn't attend a Canadian university).
I'm a Canadian computer engineer who took the NCEES FE exam just in case I move to the US. I passed on my first try as well and found that the material was pretty representative of the material covered in the courses I took.
However, it really gets under my skin when people call themselves "engineers" and they have *no clue* about engineering in general.
I strongly agree. There is a strong emphasis on responsibility and correctness in the Engineering profession that isn't adhered to by many people who call themselves engineers
I'm not talking about valid complaints here, though the example whining I gave didn't really make that clear. The best example I can think of was an assignment (I forget exactly what it was now) that was reading some sort of data from a file. The specifications explicitly said that the programs should handle incorrect input, but many students still complained afterwards about the use of an empty file as a test case.
I don't think that students should have to above and beyond the project specification, and I know all about time constraints since I had a heavier class load then most of the students in those classes. But to actually complain because you didn't add the three extra lines it would take to handle an empty file, and for the professor to accept such complaints, seems to encourage programmers that do the absolute minimum specified to get the job done.
My experience was that most instructors tried to impress upon students the importance of correct code, and the TAs tested for it. But soon after the marks came back there was a chorus of complaints in the newsgroups "You never said we had to handle that condition", or "I didn't understand the specification ", and unfortunately the instructors caved in many occasions.
That's not to say that nobody came out of the classes with the ability and desire to write code well, but the ones who slid by on complaints and shoddy programs came out as well.
There aren't many people in any community who can claim to be as dedicated and talented at Matt Dillon or Theo de Raadt, and understaffing is a problem that I know the ekkoBSD and MirOS teams would like to solve.
That opinion isn't uncommon, but there are a notable number of people who appreciate NetBSD because of their attention to architectural and technical detail. I think NetBSD will last for a long time to come. As you disclaimed, this is all IMHO