[Bdi4emc-help] Re: subversion etc.

[Kent A. Reed]

So then Paul replied:

>
>Hi Kent & Gene
>
>On Thursday 29 December 2005 20:21, Kent A. Reed wrote:
>  
>
>>At least on paper, subversion looks great. If Source Forge is going to
>>migrate to it from CVS, then it sounds like your hand will be forced
>>soon enough.
>>    
>>
>
>If the EMC developers decide to switch to subversion, I fear they will be 
>shooting themselves in the collective foot. Quite a few users and developers 
>are running RH-7.x systems, and there are a considerable number of RH-6.x 
>installations to boot. Whilst there are subversion.rpm packages available for 
>RH-7.x, you have to go digging for them. For the many running RH-6.x boxes, I 
>suspect the situation will be much worse.
>
>  
>
"Gee,' I thought, "even Cygwin offers subversion, so how hard can this 
be?" Then I did some digging at sourceforge and elsewhere and decided 
you are right. Yikes.

I'm in agreement with Gene, though. I wouldn't want to let an older RH 
system near the Internet. I guess the folk who do are using firewalls 
and NAT, etc., and hoping that between that and the lesser status of 
Linux vis-a-vis Windows, hackerwise, they'll achieve "security through 
obscurity." My experience at work, where we have something on the order 
of 10000 computers and pretty good resident packet-police, suggests this 
approach isn't good enough, but everyone has to do the cost/benefit 
analysis for their own situation. Maybe I lean too heavily toward 
security because I've had too much experience cleaning infected machines.

>I've not done any significant work with the old EMC tree for the best part of 
>two years now. Most of my efforts have been in a branch of emc2 - The EMC 
>version found on the BDI-4 disk is the result. Although both head and bdi-4 
>branches share much code in common, most of the user space code is identical, 
>as are core parts of the RT modules, the bdi-4 branch does not use the HAL 
>layer. Think of the BDI-4 build as a staging platform for the time when 
>(if ?) emc2 becomes stable enough for widespread use. Although from what I 
>hear, emc3 may be just round the corner.
>
>  
>
And the payoff for me is that you've already done this so I don't have 
to, just as you've already worked out the details for merging the  RTAI 
with the Debian distribution. One of life's lessons for me has been to 
stop saying immediately "I can do that" and start asking "who's done it" 
so I don't have to.

When I made my comment, I wasn't thinking about the different branches, 
only about EMC vs EMC2 as nominally fixed vs. still evolving 
applications. I confess it isn't clear to me what achieving a stable 
EMC2 would mean for the BDI. Do you mean you could retire all 
EMC1-specific code and build EMC2 strictly from the sourceforge head 
branch, and/or something else?

I really like the people who are developing EMC, but your last two 
sentences in the above quote worry me. I've been involved in a number of 
major IT standards developments where core developers could not resist 
starting a new version before the ink was dry on the current version's 
release candidate (futureware is always more fun than presentware). As 
long as the EMC developers continue to use their evolving product to 
make chips fly, this probably will be ok, but if they let the perfect 
become the enemy of the good, it could end badly. The marginalization of 
the perfect ISO/OSI communications protocols by the wart-covered TCP/IP 
protocols is a good example of what I mean.

Regards,
Kent