next message in archive
next message in thread
previous message in archive
previous message in thread
Index of Subjects

Index of Subjects
On Jul 15,  8:36am, "Jeff Warnica" wrote:
} > -----Original Message-----
} > From: ccn-tech-owner@chebucto.ns.ca
} > [mailto:ccn-tech-owner@chebucto.ns.ca]On Behalf Of John Nemeth
} > Sent: Thursday, February 22, 2001 3:38 AM
} > To: csuite-tech@chebucto.ns.ca
} > Cc: Ccn-Tech; James Carroll; Marilyn MacDonald
} >
} > On Jul 11, 12:49pm, Jeff  Warnica wrote:
} 
} > } storage; there are more people around who know, and more people
} > around who
} > } don't know, but want to learn these, compared to shell. Not to
} > mention that
} > } these languages are for more capable of scaling up for large
} > projects. 1.x
} >
} >      I completely disagree with this.  VTN has over 10,000 accounts,
} > which makes it a rather large community net and it doesn't have any
} > problems.
} >
} > } is tied very much to the unix philosophy, and while valid, that
} > only scales
} > } so big.
} >
} >      It scales very nicely.
} 
} 'Scale' not as in works on large sets of data, but easily added to. Yes
} software engineering more so then language choice..

     I would have to disagree with this as well.  You can add any record
type you want.  Things that don't care about the type you added will just
ignore it.

} A prime example is the data files.. The deliminator is a '|' character.
} However, there are no checks that pervent a script from writing in a | in
} the middle of a data item, corrupting the data. Someone here - not me - who
} is doing graduate level CS courses has said that therefor, in a formal CS
} sence, the CSuite database is unparasable.

     This could be said about any "database" that is kept in a text
file, such as /etc/passwd.  It could also be said about several popular
data interchange formats such as comma delimited and tab delimited
files.  I have to ask just how much real world experience this person
has.  I did CompSci at university.  One thing I quickly learned when I
got into the real world is that things aren't nearly as cut and dry as
they are in academia and that theory must be tempered with practical
reality.  There is nothing wrong with storing data in a text file.  In
fact text files do have certain advantages in that they are easily read
and manipulated by both programs and humans, as well as being easy to
repair with any standard text editor when they get corrupted.  I will
agree that programs shouldn't be willy-nilly reading and writing the
data storage on their own, but rather should go through a well defined
interface, but that is orthoganal to the actual data storage method.

} > } CSuite should be two things; new packages that provide
} > functionality which
} > } is unobtainable now, and glue so that CSuite can talk to
} > existing systems
} > } that one would want to use. Linuxconf knows how to read and
} > write files like
} > } /etc/exports, but it doesn't include a NFS server.
} >
} >      NFS is a standard part of just about all UNIX systems (we won't
} > count things like SCO).  Most of the stuff that CSuite uses doesn't
} > come standard with the system, or you get extremely old versions, i.e.
} > perl 4.0pl36 on HP-UX.  Even when things can be relatively easily added
} > using things like rpms, there is still the issue of where everything
} > goes and the configuration files.  Also, since we can't expect every
} > CSuite site to have an experienced systems administrator, much less a
} > skilled programmer, CSuite must be completely turnkey.  This means that
} > it has to include everything it needs which isn't normally found in the
} > base OS
} 
} Lets say that an exploit is found in Apache... What is easier for a
} unexperienced sysadmin to do:
} 
} rpm -Uvh apache		(on a redhat/rpm system)

     CSuite currenly runs on three different OS'es, and may run on
others as well in the future.  My current favourite OS is NetBSD, and
given that there was a request for a NetBSD port on the surver, I'm
considering doing it (I did both the Solaris and HP-UX ports, so I have
a very good idea of what needs to be done).  Given that CSuite needs to
be portable, rpms (or, any other OS specific technology) is completely
out of the question.  Heck, just try installing an rpm on CCN and see
how far you get.

     Even, if we did consider using things like rpms, we would still
have to tangle with things like where files are placed on different
systems, how to correctly modify the config files for our needs, in the
case of something like apache whether or not the correct modules are
installed and if not how to install them, etc.  It would quickly turn
into an unmanageable nightmare.

} [snip other examples]
} 
} Perhaps CSuite should be distributed as a collection of RPMs, so even if it
} does the complex third choice, you only have to type in the first. But if
} you dont include apache, just require it, then its not your problem.

     CSuite is a turnkey package, therefore everything is our problem,
like it or not.  I have stated that we need to come up a clean patch
method for installing updates before.

} > } I don't see any reason why 2.0 shouldn't be OSS; AFAIK the only
} > package that
} >
} >      What would it gain by being completely OSS?
} 
} I dont know.. Im warry of this..

     It looks to me like people have just been jumping on the OSS
bandwagon like some sort of fad without seriously considering how it
would affect CSuite or whether it would bring any real benefit.  I
rechecked the survey results and their wasn't much mention of this.
The biggest concern with the CSuite licence is the one year limit.  I
would agree that term should go.  I really think everybody needs to sit
down and think about the goals of the project and what kind of licence
would work best and give some serious thought to it.

} > } Given the crufty nature of 1.x, and that I don't think 2.0
} > should have any
} > } text interface, I cant see any reason to stay with that code base.
} >
} >      Many of the users here would scream "blue murder" if you took away
} > the text interface.  You could also have serious problems in developing
} > countries.  Given that we want to spread CSuite around the world, you
} > have to stop thinking in terms of the relative affluence of the western
} > world and think about what you would find in developing countries.
} > Also, a text interface is much nicer for people with disabilities,
} > especially blindness.  I think it would be a rather unwise decision to
} > write off the text interface at this point in time.
} 
} Well, there is the 1.x series for the people who realy realy want or need
} text. I dont think that there is any reason to support text, but with my
} plugable design, then one could do a text plugin... Even have rules that
} talk to a 1.x system.

     This is unacceptable.  It would have too much of an administrative
burden.  Most community nets do not have on-site system admins.