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

burden.  Most community nets do not have on-site system admins.  


> -----Original Message-----
> From: John Nemeth [mailto:jnemeth@victoria.tc.ca]
> Sent: Saturday, February 24, 2001 10:27 AM
> To: Jeff Warnica; csuite-tech@chebucto.ns.ca
> Cc: Ccn-Tech; James Carroll; Marilyn MacDonald
> Subject: RE:
>
>
> 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:

> } >      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.

To have any chance in making modifications to CSuite, one has to come close
to understanding the whole thing. Small changes in one place frequently have
the effect of breaking something elsewhere.

>
> } 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


Yes. I was not arguing agianst csuite data formats, but text based data
formats in general.

> 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.

Ok. But if your going to rewite all the data IO, then why dont you move to
SQL? If text databases were the way to go then the second largest software
company would be viINC, not Oracle.

It could be argued that being able to edit data by hand is a bad thing. With
modern SQL systems, you can do rollbacks, and transaction tracking. You know
what program/person modified what, and you know what it used to be. Being
able to hand edit text files is not necessaraly a good thing due to security
concerns.

> } 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.

If CSuite is supposed to be a turnkey system, then shouldnt it include the
OS as well? RedHat (for example) is aviable for intel, sparc and alpha based
machines.

Would it be a big leap to say that CSuite 2.x requires Redhat? That way the
problems of not quite CSuite packages (like perl and apache), and conf file
locations are solved for you.

Cycles are cheep, programing time expensive. RH is free, so why not use the
package management of RH? Package management problem is solved. Conf
locations, solved.


>      This is unacceptable.  It would have too much of an administrative
> burden.  Most community nets do not have on-site system admins.  It
> must be as simple to administrate as possible, which means that
> everything must be fully integrated.  Have you worked with any of the
> smaller community nets?
>

I think if things were fully intergrated, and /actualy worked/ then that
would be great. But they dont, and things require constant hand tweeking
here to maintain the system.

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