Linux-Advocacy Digest #130, Volume #31 Fri, 29 Dec 00 22:13:03 EST
Contents:
Re: FTP in Unix mistake (Gary Hallock)
Re: linux does NOT suck (oh yes it does) ("Kyle Jacobs")
Re: Why Advocacy? ("Les Mikesell")
Re: linux does NOT suck (oh yes it does) ("Kyle Jacobs")
Re: Who LOVES Linux again? ("Kyle Jacobs")
Re: Why Advocacy? ("Les Mikesell")
Re: Newbie: "Linux has come so far only to seem so far away" (maximus)
Re: Who LOVES Linux again? ("Kyle Jacobs")
Re: Why Advocacy? ("Les Mikesell")
Re: linux does NOT suck (oh yes it does) ("Ayende Rahien")
Re: Please, give up fighting with Windows users. (maximus)
----------------------------------------------------------------------------
Date: Fri, 29 Dec 2000 20:48:06 -0500
From: Gary Hallock <[EMAIL PROTECTED]>
Subject: Re: FTP in Unix mistake
[EMAIL PROTECTED] wrote:
> We have (had !) a production application running
> under SCO Unix System
> V Release 3.2 and Sybase 4.2. This PC is on a
> LAN with other Windows
> systems. The backup procedure was to "dump" the
> database in the Unix
> system, then FTP it to the Windows system and
> take a backup on tape
> connected to the Windows system.
> The problem: The Unix system crashed. We had to
> reinstall Unix and
> Sybase. When we wanted to "restore" the
> database, Sybase did not
> recognise the format of the dump.
> The reason: When the FTP was done from the Unix
> system to the Windows
> system, it had defaulted to "ASCII" mode transfer
> instead of "binary".
> We attempted transfer back in ascii as well as
> binary - but neither
> format is recognised by Sybase as a valid dump
> file.
> Can someone suggest as to what can be done to get
> back the data dump
> in its original format? Our line of thinking was
> also something like
> "...if ascii mode ftp pads CR+LF then the reverse
> ftp should strip
> away the LF...."; but the file size never seems
> to agree in the
> sample binary files with which we attempted to re-
> create the scenario,
> by ftp-ing it back and forth.
> Any help will be appreciated.
>
> Thanks.
>
> Sent via Deja.com
> http://www.deja.com/
I doubt there is any way to retrieve the data. If you try stripping
off CR+LF, you can't tell if this was a real CR+LF added by the ASCII
transfer or just some binary data that happens to look like CR+LF.
That's why you should always test your backup process before you really
need to use it.
Gary
------------------------------
From: "Kyle Jacobs" <[EMAIL PROTECTED]>
Crossposted-To: alt.linux.sux
Subject: Re: linux does NOT suck (oh yes it does)
Date: Sat, 30 Dec 2000 01:56:25 GMT
Oh my god, this makes SENSE.
"Ayende Rahien" <[EMAIL PROTECTED]> wrote in message
news:92isv1$fu3$[EMAIL PROTECTED]...
>
> "Les Mikesell" <[EMAIL PROTECTED]> wrote in message
> news:b6W26.52507$[EMAIL PROTECTED]...
> >
> > "Ayende Rahien" <[EMAIL PROTECTED]> wrote in message
> > news:92h7sc$mqn$[EMAIL PROTECTED]...
> > >
> > > > >
> > > > > > Because IT WOULD MAKE SENSE. That's why.
> > > > >
> > > > > Why just those? Why not every window manager known to man?
> > >
> > > Why not make a file like RPM, so each application can have, which will
> > > contain its configurations and will be openable by some common
program.
> > > And no, I'm talking about
> > > pico/ed/whatever-other-text-editor-you-had-in-mind.
> > > XML would do nicely here.
> >
> > XML is just syntax. It saves you from writing a parser or reusing
> > any of the more free-form parsers already done, but nothing
> > else. This is not unreasonable for new programs but the
> > people who have copied the same config files from machine
> > to machine for the last 20 years and know how to read and
> > type them aren't going to be happy if they suddenly are forced
> > to make them ugly and unreadable. XML is easy for the
> > computer to parse but I'm not sure it makes sense these days
> > to make it harder for the human and easier for the CPU.
>
> The advantage XML has is in that it's both human & machine readable. And
> building a program that would be able to read & change every program's
> setting that I can think of would not be a problem.
> And you could probably add a switch to turn the application to the old
> config method instead of XML, so old fashion guys who like text files
could
> still have them.
> The advantage a common syntax to all config files would be that a single
> tool can handle them all, making tools such as LinuxConf so much easier to
> user.
>
>
------------------------------
From: "Les Mikesell" <[EMAIL PROTECTED]>
Subject: Re: Why Advocacy?
Date: Sat, 30 Dec 2000 02:03:38 GMT
"Pete Goodwin" <[EMAIL PROTECTED]> wrote in message
news:_H636.25687$[EMAIL PROTECTED]...
> JM wrote:
>
> > Decide yourself, or look in the documentation somewhere.
>
> It wasn't in the documentation anywhere, so I guessed.
Where did you get the script that you put in /etc/rc.d/init.d?
If it is intended for use with recent systems it should include
a line like
# chkconfig: 2345 20 80
These are the hints from the person who wrote that script about
where it should go. The first group of digits is the list of run
levels where the entries would be appropriate, the 2nd number
is the start priority, the 3rd is the stop priority. (I.e. it should
be linked as S20filename and K80filename).
Running 'chkconfig --add filename' will make all the links for
you following the hints.
>
> > >Ah yes, RTFM.
> >
> > Yes.
>
> See above.
man chkconfig
>
> > If you put them in the right order then YES.
>
> How do you debug it when it doesn't work? I saw no messages about why the
> service wasn't starting.
You can start it manually with:
sh -x /etc/rc.d/init.d/filename start
and you'll see the shell trace of each statement in the script. If it works
manually but not at bootup, you may have it starting too soon, before
some other needed service. If it isn't obvious from looking at the
script (does it need DNS before named starts, etc.?) you can try something
like adding:
exec >/tmp/logfile 2>&1
set -x
near the top of the script. This will log the stderr and stdout of the
script and trace to /tmp/logfile which you can review later and
compare to the working manual execution. Normally you will see
some part of the script fail or produce empty fields on the command
line and can figure out which service should be supplying the
missing part, then adjust the start order accordingly.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: "Kyle Jacobs" <[EMAIL PROTECTED]>
Crossposted-To: alt.linux.sux
Subject: Re: linux does NOT suck (oh yes it does)
Date: Sat, 30 Dec 2000 02:00:59 GMT
Yes, standards would make this fascinating idea possible. Pity NONE exist.
This is why the Windows registry shines. It's truly uniform.
"Ayende Rahien" <[EMAIL PROTECTED]> wrote in message
news:92j7hc$lj6$[EMAIL PROTECTED]...
>
> "Roberto Alsina" <[EMAIL PROTECTED]> wrote in message
> news:92j3of$456$[EMAIL PROTECTED]...
> > In article <92isv1$fu3$[EMAIL PROTECTED]>,
> > "Ayende Rahien" <[EMAIL PROTECTED]> wrote:
> > >
> > > "Les Mikesell" <[EMAIL PROTECTED]> wrote in message
> > > news:b6W26.52507$[EMAIL PROTECTED]...
> > > >
> > > > "Ayende Rahien" <[EMAIL PROTECTED]> wrote in message
> > > > news:92h7sc$mqn$[EMAIL PROTECTED]...
> > > > >
> > > > > > >
> > > > > > > > Because IT WOULD MAKE SENSE. That's why.
> > > > > > >
> > > > > > > Why just those? Why not every window manager known to man?
> > > > >
> > > > > Why not make a file like RPM, so each application can have,
> > which will
> > > > > contain its configurations and will be openable by some common
> > program.
> > > > > And no, I'm talking about
> > > > > pico/ed/whatever-other-text-editor-you-had-in-mind.
> > > > > XML would do nicely here.
> > > >
> > > > XML is just syntax. It saves you from writing a parser or reusing
> > > > any of the more free-form parsers already done, but nothing
> > > > else. This is not unreasonable for new programs but the
> > > > people who have copied the same config files from machine
> > > > to machine for the last 20 years and know how to read and
> > > > type them aren't going to be happy if they suddenly are forced
> > > > to make them ugly and unreadable. XML is easy for the
> > > > computer to parse but I'm not sure it makes sense these days
> > > > to make it harder for the human and easier for the CPU.
> > >
> > > The advantage XML has is in that it's both human & machine readable.
> >
> > So is sendmail.cf for some value of readable, human and computer ;-).
>
> Which use different fomrat than what other config tools user.
>
> > > And building a program that would be able to read & change every
> > > program's setting that I can think of would not be a problem.
> >
> > There is one, it's called "pico". Just because a program can parse
> > XML, it doesn't mean that it can figure out what the XML means.
>
> But it means that the file contain all the options, and that one program
can
> be used to config all the config files without the user needing to know
> about the file's format.
>
> > Take, for example, a very simple config file format: INI-like files.
> > You know, tag/value pairs grouped on sections?
>
> Yeah, I know, and that is why it's bad.
>
> take apahce's configuration, frex:
>
> ServerType: standalone
>
> The other option is "inetd"
>
> No where it the config file there is even a *hint* about the other option.
>
> This mean that if I want to write a program that configure apache, I will
> need to store the other option *inside* the program.
> And this mean that if apache has a new version with another value to
> ServerType, I'll have to update my program to include this.
> And if I want to write a tool such as LinuxConf, I've to store inside the
> program *all* the programs options, and when one program config file is
> changed, I need to update the program.
> This mean that writing LinuxConf or similar tools will be *hard*. Because
> I've to store both old settings & new settings, and find out what version
> each program is running, and fit itwith its sets of options.
>
> OTOH, if all programs adhered to some sort of a common format, such as
> this*:
> http://www10.ewebcity.com/ayende/lmc.xml
>
> Building such a tool would be very easy, and will mainly include finding
> GPLed XML phraser and writing the UI.
>
> This way, the config file itself is the one who stores all the options. If
a
> new version, with new options, comes out, the same tool, with absolutely
no
> modifications, be able to handle it.
>
>
> > They are trivial to parse for men and computers (much simpler than
> > XML!). They are used by many apps (all KDE apps, all GNOME apps).
> >
> > Now, write a program that can configure all KDE and all GNOME apps.
>
> No, because of the reasons mentioned above, the config files don't
contained
> the other options, so building such a tool would be quite hard.
> Assuming that the programs follow a format as I purpose, or a similar one,
> it would be far easier.
>
> > Now, are you sure writing that program would not be a problem?
>
> Yes, because if you do it the way I suggest, you wouldn't have that much
of
> a problem.
>
> > > And you could probably add a switch to turn the application to the
> > > old config method instead of XML, so old fashion guys who like text
> > > files could still have them.
> >
> > As someone who has had to go through it: bad idea. If the app has two
> > different mechanisms to save data, there is a awfully large chance that
> > the data will not be saved right in one or the other.
>
> Not if the program is written well.
> But I agree it might be a problem.
> I think that the advantages this method gives you are worth it.
>
> > > The advantage a common syntax to all config files would be that a
> > > single tool can handle them all, making tools such as LinuxConf so
> > > much easier to user.
> >
> > Parsing the config files is the simplest of all steps in the road to
> > having a global config tool. You still have to write the logic to
> > present the user with a comprehensible UI to change configs, the
> > logic to modify the config data based on user input, the logic
> > the verify coherence of the generated config data, and then (this one
> > is easy) turn the config data back into storage form.
>
> You need to do it *anyway* when you write a tool such as LinuxConf.
> The hardest part in making such a tool is that the tool need to "remember"
> what each program's settings, this method would release the program from
> remembering, and allow much easier life for the writers of the global
config
> tools.
> Not to mention that it is still readable by humans, quite easily, and it
> contain the info that a user need to know about how to config the
> application via tools such as pico.
> You get to enjoy both worlds.
>
>
> [*] I'm not purposing this file format, actually, I wrote it when I
learned
> XML.
> It's an example only, to show how I think it should be done.
>
>
------------------------------
From: "Kyle Jacobs" <[EMAIL PROTECTED]>
Crossposted-To: alt.linux.sux
Subject: Re: Who LOVES Linux again?
Date: Sat, 30 Dec 2000 02:03:41 GMT
That's right, you already know the answer.
"MH" <[EMAIL PROTECTED]> wrote in message
news:92i6p3$1s2$[EMAIL PROTECTED]...
> Wow, what a collection this one inspired!
>
> First, getting a couple of mb's per second of hdd access time isn't going
to
> help that much.
> It is more NN's library architecture that is the problem. Besides, I've
done
> the manual 'tuneup' of my disk access via hdparam.
>
> Second, why would I leave that bloat ball running all the time? It leaks
> like a sieve, takes more memory than some OS's and prone to freezing
solid.
>
> Third, why do linvocates always change the topic three posts in?
>
> Fourth, funny how the penguinistas bray about how you DON'T need
horsepower
> to run linux.
> You've heard it, right? "Why should I purchase <insert choice of hardware
> here> to run a stinkin' OS"
> Now, you want me to ante up to a 700mhz cpu with 256mb's of ram to run
> nutscraped?
> Are you people insane?
>
> Never mind, don't answer that. I think I know the answer.
>
>
> "Yatima" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > On Thu, 28 Dec 2000 09:17:41 -0500, MH <[EMAIL PROTECTED]> wrote:
> > >
> > >That's good. But you know, I'll take the 30 seconds it takes to reboot
> the
> > >winbox after a driver install over the 20 seconds it takes everytime I
> > >launch Netscape to get a url box.
> >
> > Hmm. It takes ~5 sec here and konqueror (my primary browser) takes under
> > 2 sec (Athlon 700, 256M).
> >
> > --
> > yatima
>
>
------------------------------
From: "Les Mikesell" <[EMAIL PROTECTED]>
Subject: Re: Why Advocacy?
Date: Sat, 30 Dec 2000 02:07:45 GMT
"Pete Goodwin" <[EMAIL PROTECTED]> wrote in message
news:O%Z26.22492$[EMAIL PROTECTED]...
> Joseph T. Adams wrote:
>
> > That's probably up to you.
> >
> > If your service depends on another one, then, obviously, run it after
> > the one it depends on, and shut down in reverse order.
> >
> > Otherwise, it doesn't matter.
>
> And how do I know what the order is from staring at the directory? It's
not
> obvious is it!
>
> Yes, I know, go and RTFM.
It is obvious once you realize that an upper-level shell processes the
linked scripts with a wildcard expansion, and that all shell wildcard
expansions are done in alphabetically sorted order. In other words
the order is exactly as ls (with no sorting arguments) will display
the list. Or 'echo S*' would.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: maximus <[EMAIL PROTECTED]>
Subject: Re: Newbie: "Linux has come so far only to seem so far away"
Date: Sat, 30 Dec 2000 01:55:46 GMT
Thank you Mick, good sound insightful advice. You are one of the Good
Linux people. Hear you loud and clear about posting on this forum.
There are certainly some very strange people in this forum (hello
Nick), but they love to do their weird rude thing in the other forums
as well. I just ignore them. Thanks again and hope I can reciprocate
someday.
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Form@C) wrote:
> maximus <[EMAIL PROTECTED]> wrote in <92c704$pr1$[EMAIL PROTECTED]>:
>
> > Greetings all. I posted a question on this forum and alt.os.linux
> >looking for the best distro for a linux newbie. The posting was
> >titled "Which retail Linux distribution is best?" The responses I
> <snip>
>
> You may like to think on these points:
>
> Suse
> An excellent distribution but has a very strict package control
system.
> There are a number of golden rules which you *must* follow if you
want to
> keep your system working and stable: Suse Rule 1:
> Never attempt to configure a program using any other tool if it is
> supported by YAST (Yet Another Setup Tool) or by a tool documented
by
> Suse.
> Suse Rule 2:
> Never attempt to install software obtained from *any* source other
then
> the CDs supplied with your version of the package or from Suse's web
> site if it is available for your version of the package. At least,
not
> until you *really* know what you are doing! (Note that although it
> supports the RPM format it appears to treat the contents of the
package
> in its own way - there is no guarantee that a RPM will install if it
> was produced by a different distribution - I hope that this has been
> improved since the last version I tried - 6.3).
> Suse Rule 3:
> Always give /home, at least, a partition of its own when
installing. It
> is not easy to upgrade Suse and a complete, clean re-install is
often
> the best way to go.
>
> It seems to be based on "lets build a really good distribution, but
where
> our ideas conflict with accepted practices, we'll stick to our own
> ideas". In spite of this, this is probably my favourite distribution
so
> far. It comes with so many applications (which is a *good thing* - see
> rule 2) that you are often confused as to which is the best!
>
> RedHat
> Much loved by magazines - they often put applications on the cover
disks
> in their own RPM format. This is not necessarily good, as the
> applications are often unstable and/or incomplete! A very "high
profile"
> distribution but not one of the best - especially not for beginners. I
> get the feeling that RH would dearly love to rule the Linux scene and
> set standards.
>
> Mandrake
> A very pretty installation which AKAIK includes most of the useful
stuff.
> Some people think that is incomplete once you get away from running
KDE
> but this has never bothered me much. Really intended as a GUI-based
> desktop machine.
>
> Corel
> Another very pretty installation but not easy to use at all once you
> leave KDE. What it does, it appears to do well but it doesn't do
enough
> for many people. Seems to be aimed at the same market as Mandrake. I
> would have put this in the "one to watch" catagory, but I'm not
certain
> about its future now.
>
> There are many others, but I havn't tried them! I'm sure someone else
can
> give you more info on these.
>
> Is this info of use to you?
>
> Don't worry about "fragmentation" of Linux. It was never anything else
> but "fragmented" because there has never been a single commercial
venture
> behind it!
>
> Linux, if it is pre-installed on a system with the applications that
will
> be run, is excellent. Problems arise when (some) users want to change
> hardware or software to suit themselves rather than to suit Linux. In
> this respect all distributions are equal.
>
> By the way, maximus, this is an "advocacy" group. You can expect a
lot of
> shouting and support for particular operating systems and
distributions.
> Not really a good place to look for calm, unbiased advice!
>
> <ok. flame repellant mode on again...>
>
> --
> Mick
> Olde Nascom Computers - http://www.mixtel.co.uk
>
--
"Strength and Honor"
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Kyle Jacobs" <[EMAIL PROTECTED]>
Crossposted-To: alt.linux.sux
Subject: Re: Who LOVES Linux again?
Date: Sat, 30 Dec 2000 02:06:28 GMT
You CAN'T do an xkill or a killall or any other process terminations when
the user session is LOCKED UP.
(User Session=Your interface, period)
"Les Mikesell" <[EMAIL PROTECTED]> wrote in message
news:6d936.52547$[EMAIL PROTECTED]...
>
> "MH" <[EMAIL PROTECTED]> wrote in message
> news:92i6p3$1s2$[EMAIL PROTECTED]...
> > Wow, what a collection this one inspired!
> >
> > First, getting a couple of mb's per second of hdd access time isn't
going
> to
> > help that much.
> > It is more NN's library architecture that is the problem. Besides, I've
> done
> > the manual 'tuneup' of my disk access via hdparam.
> >
> > Second, why would I leave that bloat ball running all the time? It leaks
> > like a sieve, takes more memory than some OS's and prone to freezing
> solid.
>
> If it freezes, do an xkill, but otherwise leaving it up doesn't bother
> anything
> else.
>
> > Third, why do linvocates always change the topic three posts in?
> >
> > Fourth, funny how the penguinistas bray about how you DON'T need
> horsepower
> > to run linux.
> > You've heard it, right? "Why should I purchase <insert choice of
hardware
> > here> to run a stinkin' OS"
> > Now, you want me to ante up to a 700mhz cpu with 256mb's of ram to run
> > nutscraped?
> > Are you people insane?
>
> If you want fair comparisons, you should always compare equal dollars.
> Put the money you save on the OS and included apps into more RAM
> and/or a faster CPU. Linux can do many jobs on lightweight
> hardware, especially things that are best left unattended like
> routing and serving files/web pages/email, etc. But it is still a
> lot more fun to have something speedy on your desktop.
>
> Les Mikesell
> [EMAIL PROTECTED]
>
>
------------------------------
From: "Les Mikesell" <[EMAIL PROTECTED]>
Subject: Re: Why Advocacy?
Date: Sat, 30 Dec 2000 02:12:24 GMT
"Pete Goodwin" <[EMAIL PROTECTED]> wrote in message
news:6E636.25678$[EMAIL PROTECTED]...
> Gary Hallock wrote:
>
> > True. But then, if setting arbitrary sequence numbers did not break
> > startup,
> > there would be no need for them in the first place. I guess I just
don't
> > understand your point. If all of this were done in a single startup
> > script you would still have to know what order to start things.
>
> Well, recently I had to add a service by hand as Linuxconf refused to do
it
> for me. There was an error message, but it was obscured by the text box
> dialog. I can't use Linuxconf with X as I didn't install Gtk (or whatever
> it is Linuxconf requires to run on X).
>
> It wasn't too obvious to me where I should put this service - there was
> nothing mentioned in the documentation so I made a wild guess. It didn't
> work, until I put it in rc.6 then things started working correctly.
What???? Runlevel 6 doesn't really exist - it is a shorthand notation for
going down to level 0 (shutdown) then rebooting back to the default
level (usually 3 or 5). Something else must be going on here.
> If I were editing a startup script, I'd simply put it in as the last item.
> I suppose I could use S99 or K99 but that was already allocated.
Oh, I thought you meant you added an rc6.d directory.
My smbd file suggests S91 and K35.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: "Ayende Rahien" <[EMAIL PROTECTED]>
Crossposted-To: alt.linux.sux
Subject: Re: linux does NOT suck (oh yes it does)
Date: Sat, 30 Dec 2000 04:16:06 +0200
"Les Mikesell" <[EMAIL PROTECTED]> wrote in message
news:gIa36.52578$[EMAIL PROTECTED]...
>
> "Ayende Rahien" <[EMAIL PROTECTED]> wrote in message
> news:92isv1$fu3$[EMAIL PROTECTED]...
> >
> > > > XML would do nicely here.
> > >
> > > XML is just syntax. It saves you from writing a parser or reusing
> > > any of the more free-form parsers already done, but nothing
> > > else. This is not unreasonable for new programs but the
> > > people who have copied the same config files from machine
> > > to machine for the last 20 years and know how to read and
> > > type them aren't going to be happy if they suddenly are forced
> > > to make them ugly and unreadable. XML is easy for the
> > > computer to parse but I'm not sure it makes sense these days
> > > to make it harder for the human and easier for the CPU.
> >
> > The advantage XML has is in that it's both human & machine readable.
>
> As is the plain text config file, those liberally sprinkled with comments
> are especially nice for humans.
They are very nice indeed, I agree, but they are all but useless when you
are trying to write a tool such as LinuxConf, where you need to write
functions to handle each application that you want to add to this tool.
Assuming that I want to write a tool that will allow me to edit
X,Apache,KDE,Gnome,sendmail,MySQL, PHP, etc. I'll have to write the program
to each program's settings individually.
If there would be something like this:
http://www10.ewebcity.com/ayende/lmc.xml
Then I could write a single program, and that program would be able to
handle every program that uses this syntax, and you wouldn't need to update
your global config tool for each update/change in the applications it
support.
> > And
> > building a program that would be able to read & change every program's
> > setting that I can think of would not be a problem.
>
> Text editors that can edit every text files have been around about
> as long as the concept of files themselves.
So? That is not what I'm talking about.
> > And you could probably add a switch to turn the application to the old
> > config method instead of XML, so old fashion guys who like text files
> could
> > still have them.
>
> And you are doing this to make it easier for the machine?
No, for the end user.
> > The advantage a common syntax to all config files would be that a single
> > tool can handle them all, making tools such as LinuxConf so much easier
to
> > user.
>
> A single tool has handled all text config files for as long as anyone
> has used them. Actually many tools are useful with them besides
> the editor: diff, patch, cvs, etc. can all be very handy when you have
> several versions to maintain.
Irrelevent to the discussion, because that isn't what I'm talking about.
I'm talking about making a global config tool, and why it is so hard to do
so.
Why is LinuxConf is so popular?
Because it's much nicer to have UI instead of flat text files when you try
to configure something.
> The part that really is a problem with text files and can't be easily
> solved with a simple syntax-driven wrapper is that what you
> really want from a config tool is some protection from making
> preventable errors that might crash the application. For example,
> a menu pick list can keep you from entering invalid choices, but
> to get this right, the tool has to know as much as the app itself and
> may need to cross-check against all the other settings. A more
> attainable goal would be to teach the apps themselves to do a
> syntax-check pass with reasonable error messages. Apache does
> this with 'httpd -T' so you don't have to break a running server by
> attempting to reconfigure with a bad config file.
What I'm propusing would include the bad syntax checking internally, so the
configurator will be able to handle it, and not the application.
See link above, to see what I'm talking about.
------------------------------
From: maximus <[EMAIL PROTECTED]>
Subject: Re: Please, give up fighting with Windows users.
Date: Sat, 30 Dec 2000 02:07:08 GMT
I couldn't agree with you more. I am a Linux neophyte and admitted it
up front. I posted a couple of very general questions asking for
advice and the good Linux people responded promptly and
professionally. Then the anti-christ's of Linux came and started the
ranting and raving that they are notorious for. Very disgusting and the
most unproductive thing that anyone could do. I would even say, Windows
users quit fighting with Linux users and vice versa. Best Regards.
In article <92ef4m$hh9$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Really, people, its pointless. Windows users pick up Red Hat and
can't get it
> to work, so they figure, "oh ,well, I'll go be a dumbass and post in
linux
> advocacy about how Linux sux, cuz I'm too stupid too follow
instructions"
> instead of coming to us and asking questions and getting help from
us. But,
> here's the catch: we are fighting back! I admit, I fell for it too,
but come
> on, its pointless. We can exchange quips all day and never convince
them
> other wise. So why bother?! When I first started to use Linux, right
before
> the Windows people caught wind of it, I was amazed at the support one
could
> receive in these forums when I had a problem. Immediate response, 15
replies
> within an hour on my questions. Now, look at us. Screaming our
mantras of
> GPL/Open Source philosophy, only to have it fall upon closed ears. So
what if
> they think Windoze is better? What should we care? As I just said,
Open
> Source *PHILOSOPHY*<-[key word here]. Not everyone is going to accept
it.
> Really, it is a completely radical new way of thinking compared to the
> standard license agreements. Not every one accepted Martin Luther
Kings
> philosophies, or Jesus, or Joan of Arc, etc. What is the point in
trying to
> force our beliefs on them? I say, let them come and post their stupid
shit.
> Don't reply. They do it to piss us off. Just let it go. And lets start
> talking about meaningful things and community news again. Lets use
the forums
> to start more LUGs. Maybe I'm wrong. I could be. But this, the
wasting our
> time fighting a lost cause, doesn't seem right either. What do you
all think?
> C Pungent
>
> Sent via Deja.com
> http://www.deja.com/
>
--
"Strength and Honor"
Sent via Deja.com
http://www.deja.com/
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to comp.os.linux.advocacy.
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Advocacy Digest
******************************
