Linux-Advocacy Digest #314, Volume #31 Sun, 7 Jan 01 02:13:03 EST
Contents:
Re: linux does NOT suck (oh yes it does) ("Les Mikesell")
Re: linux does NOT suck (oh yes it does) ("Les Mikesell")
Re: Sucking Linux 2.0.4!!! ("Tom Wilson")
Re: Linux is crude and inconsistant, but Windows is pure junk! ("Kyle Jacobs")
Re: linux does NOT suck (oh yes it does) ("Kyle Jacobs")
Re: linux does NOT suck (oh yes it does) ("Kyle Jacobs")
----------------------------------------------------------------------------
From: "Les Mikesell" <[EMAIL PROTECTED]>
Crossposted-To: alt.linux.sux
Subject: Re: linux does NOT suck (oh yes it does)
Date: Sun, 07 Jan 2001 06:08:14 GMT
"Ayende Rahien" <[EMAIL PROTECTED]> wrote in message
news:938kdd$osr$[EMAIL PROTECTED]...
>
>
> > Of course, the fact that it's so easy to "point, click, execute,
> > kaboom" on Microsoft isn't helpful either (on Unix, at least, one
> > has to go through some hoops; it's doable, but the only damage would
> > be to one's own account -- not the entire system).
>
> Can you show me the virus for NT that can damage other people's file on
> NTFS?
Most of them, using the typical virus technique of getting all those
other people to run a copy too. Having outlook around makes
this pretty easy.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: "Les Mikesell" <[EMAIL PROTECTED]>
Crossposted-To: alt.linux.sux
Subject: Re: linux does NOT suck (oh yes it does)
Date: Sun, 07 Jan 2001 06:14:53 GMT
"Ayende Rahien" <[EMAIL PROTECTED]> wrote in message
news:938o2v$q9j$[EMAIL PROTECTED]...
>
> >
> > > Can you show me the virus for NT that can damage other people's file
on
> > > NTFS?
> >
> > Sure, just use one of the many applications that require Everyone
> > (Full Access) to a directory, save your file there, and you're done.
> > You could make this even easier by using Omnipage Pro, which requires
> > Administrator access to even run.
>
> This goes to every permission FS in the world, you know.
> If you give Everyone full access to a directory, Everyone will be able to
do
> whatever they want with the files in that directory.
It doesn't happen with the typical unix FS configuration that you
see in /tmp or the mail spool. If you set the 'sticky' bit on the
directory, you can allow anyone to create files (with file permissions
being independent of the directory) but only the owner of the file is
allowed to delete it.
> I've asked a question which you've no answered.
> What virus can damage other people files on NTFS (implied within this
> statement is that the other people's files are protected by premissions) ?
The ones that send outlook attachments to those other people. Or have
you missed the news stories about all the companies where this has
happened?
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: "Tom Wilson" <[EMAIL PROTECTED]>
Subject: Re: Sucking Linux 2.0.4!!!
Date: Sun, 07 Jan 2001 06:23:26 GMT
"genkai wa doko da" <[EMAIL PROTECTED]> wrote in message
news:9386f3$ahs$[EMAIL PROTECTED]...
>
>
>
> linux usings being fagit who don't know real perfesional operatoning
> systim like windows NT!!
So solly! Me wush out buy NT.
Many tanks!
>
> fuck off!
Herro you too!
Many tanks!
Many tanks!
So solly!
Bye Bye!
------------------------------
From: "Kyle Jacobs" <[EMAIL PROTECTED]>
Crossposted-To: alt.linux.sux
Subject: Re: Linux is crude and inconsistant, but Windows is pure junk!
Date: Sun, 07 Jan 2001 06:31:42 GMT
Wow, you BOTH have good points.
Now, is there anything that can be done to expedite the situation. Hmm...
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Sun, 07 Jan 2001 03:02:19 GMT, [EMAIL PROTECTED] (The
> Ghost In The Machine) wrote:
>
>
> >It's not clear that Windows is much better, although with the built-in
> >GUI elements (pulldown menus, scrollbars, etc.), it can look much
> >more slickly polished. But underneath, it's the same old glop,
> >not unlike giving a Trabant or Lada a shiny metallic paint job and
> >trying to race a Ferrari, or at least an old beat-up-looking but
> >well-maintained and smoothly running Chevy. To make the analogy
> >even better, it's not a stock Chevy, either, but a Chevy with
> >a Mac Truck motor, a Ford transmission, a hemi sticking through a
> >hole in the hood, super-beefy shocks, struts, and springs -- in fact,
> >the general appearance is that of the vehicle in _Mad Max_ which Mad
> >Max drove after his wife was killed. Granted, it still looks
> >like a car -- but it's an ugly sucker. And yet -- it can run
> >rings around a Trabant. (Another variant might look like that
> >even uglier homemade helicopter - but that worked pretty well, too.)
>
> I won't disagree that technically, on paper, the Windows platform has
> a lot to be desired and the Mac platform even more, but when the end
> results are tabulated they both come out on top because of the
> support, consistency and applications albeit at the cost of technical
> superiority.
>
>
> >OK, enough with the silly analogies. :-)
>
> I thought you were pretty close :)
>
> >Part of *nix's reliability may simply be the management of
> >resource handles. In Unix (and Linux), if one wants a resource,
> >one does one of two things.
> >
> >[1] Memory is allocated and initialized in the local address space.
> > In other words, it's owned by the process, to have and to hold
> > until said process' death.
> >[2] An integer is handed back from a kernel routine, which is
> > effectively owned by the process. This integer is typically
> > small and positive, or perhaps non-negative, and can even
> > be checked when handed about to different routines, to ensure
> > that it's valid.
> >
> >In NT, [2] appears to be rarely used, and it is not clear that the
> >allocated memory in [1] is always owned by the process. Therefore,
> >woe betide the process that doesn't follow the allocation rules to
> >the letter! Windows 95 is even worse, although it tries hard to
> >emulate NT.
> >
> >(Side note: in older Mac operating systems, MacOS did a lot
> >of handle-to-pointer-to-structure management, to give it
> >the option of keeping memory defragmented by moving around
> >the structures (one merely changes the pointer in the handle).
> >This is an old design, no longer needed by modern operating
> >systems which assign each process its own virtual address space.
> >I don't know what Windows 3.1 and Win95 did regarding this sort
> >of thing, though. Note also that the Amiga, if anyone still remembers
> >it, didn't bother with handles, but just returned a pointer to
> >more or less shared memory, which anyone could tromp on.
> >But everyone knew this, :-) and it was a well-documented system
> >which eventually got the bugs engineered out. I hope it comes back.)
> >
> >This appears, to me at least, to be a design decision that is
> >partly responsible for various issues within NT and Windows,
> >and the lack of those same issues in Linux.
> >
> >X is an interesting animal, as well, compared to Win32. X is an
> >old design (ca. 1980's or so; I don't know when MIT first came out
> >with X10, then X11), but was intended at the outset to work with
> >networking, as far as I can tell. This transparency introduces
> >some interesting quirks in the design (for example, one cannot
> >determine precisely when something will be drawn unless one
> >uses XFlush() or XSync(), and even then the server may hesitate
> >in drawing; the selection protocol is straightforward, but not
> >intuitive; colormap management is straightforward, but slightly
> >peculiar, although newer versions of X attempt to work around
> >that, possibly by using round-robin allocations of named colors when
> >possible; bitmap issues can be done either on the server side (slow
> >on Linux) or the client side (faster on Linux unless going across
> >the network).)
> >
> >It's not clear what an X window is (the Window or Drawable type), since
> >all one gets is a rather cryptic handle -- it's not even a small
> >integer -- but it doesn't really matter; the server is charged with
> >checking all things coming in and it knows all the windows it creates,
> >for it creates them (on request). A bunged handle can be detected
> >and ignored.
> >
> >The Xlib side is on the client, and is the usual memory allocation
> >issue; while it may corrupt itself, throwing the process into an
> >unknown state, the X server, which is also protecting itself from
> >bad info, won't do weird things if the Xlib completely goes south, or
> >the user tries to get cute and send things directly over the wire.
> >(A number of programs do just that.)
> >
> >Another illustration may be the management of X Graphics Contexts
> >versus Hardware Drawing Contexts. In X, if one wants to change
> >the color of a GC prior to drawing a line, one has to:
> >
> >- find the right color (XAllocColor(), XAllocNamedColor())
> >- issue an XSetForeground() call to the GC
> >- draw the line(s), polygons, text, what have you
> >
> >GCs are limited (they are implemented as pointers), but not shareable
> >across programs as far as I know; in any event, X does not have any
> >elegant methods by which to hand a GC from one process to another.
> >Note that the machinery is complicated by various queueing issues
> >(the XSetForeground() call is queued up along with the drawing codes),
> >but this usually doesn't cause problems and is transparent to the
> >casual developer.
> >
> >It is left up to the program to decide whether to restore the GC,
> >and it's usually not that big of a deal.
> >
> >Win32, by contrast, is terrible. If one wants to change the color
> >of a Hardware Drawing Context prior to drawing a line, one has to:
> >
> >- find the right color (RGB() macro; I'm not sure if there's a
> > method in Windows to select colors by name -- if there is,
> > I haven't found it yet)
> >- create the pen (CreatePen())
> >- select the pen, noting that the previous pen is in fact returned
> > (SelectObject()).
> >- hold onto the old pen as long as necessary, while drawing things
> > (MoveToEx(), LineTo(), TextOut())
> >- return the saved pen when done (SelectObject() again), and
> >- destroy the pen created (DeleteObject()).
> >
> >Failure to follow these rules precisely may result in memory leaks,
> >or worse. Note also that there's a CreatePen(), but no DeletePen();
> >this is admittedly a minor issue, but it would be nice to balance
> >the two. (I suspect a number of developers simply define a
> >macro or create a DeletePen() which simply calls DeleteObject().)
> >
> >HDCs may or may not be owned by a single program, but this sort of
> >behavior -- which also applies to brushes and fonts -- is typical
> >of Win32 protocol.
> >
> >One nice thing about Windows -- if implemented properly -- is
> >that identical code can be used for drawing something on the
> >screen, and later on printing it, or saving the results to a
> >metafile (there is a code in the HDC somewhere). However, I
> >would not be surprised that the implementation is lacking; font
> >metrics, if not perfectly implemented, can lead to some strange things
> >happening. This is probably less of a problem now than in the past,
> >given modern raster hardware and TrueType fonts.
> >
> >X is horribly lacking here -- but it's not usually much of a problem.
> >But it is something I miss. (I can compensate for it somewhat
> >using Ghostscript metrics, which are shipped with Ghostscript
> >fonts.)
> >
> >Windows also has a nice idea that got horribly bodged in the
> >implementation. Developers can basically, using Visual Basic
> >or Visual C++, create beautiful forms with buttons, gadgets,
> >and what not (the idea is not new to Windows, of course; Motif
> >and OpenLook also had GUI creators). So far, so good -- but the
> >wedging occurs when one realizes that the resources are
> >specified using absolute positioning; this means that, if someone
> >changes a font, things look ridiculous. The Xt Intrinsics
> >Xrm database is far cruder, and somewhat more limited -- but within
> >those limitations, it works very well; it also has multilevel
> >"hive"-type stuff even before Windows thought of the idea and
> >bodged that as well, and it's more robustly implemented.
> >In fact, the idea is almost identical to old-style Win3.1 .INI files.
> >
> >It's also been banged on for at least a decade; Motif is that old.
> >
> >A final comment, this on window management. In Windows, this appears
> >to be a process-by-process issue, or perhaps thread-by-thread; this
> >means that, if an application hangs (ceases to process input from
> >the user event queue), one is sitting there staring at a
> >beautifully-drawn but unresponsive window; if another window
> >subsequently draws on top of it, one gets some horrible graphics.
> >There's no way to move it out of the way; the only recourse is to
> >kill the app -- and that only on Windows NT. Apps do have the option
> >of starting another thread and dedicating it to window management --
> >but not many apps bother.
> >
> >X, by contrast, has window management running in a totally separate
> >process, and some safeguards should that process futz out.
> >This means that a window under control of the window manager
> >(most X windows are, and the WM is aware of just about everything
> >going on) can be iconified out of the way, even if the app
> >which manages redrawing of that window decides to go south.
> >It's a simple design which works; the only drawback is if the
> >window manager goes south as well, which usually results in
> >a plethora of uniconified windows suddenly appearing sans frames
> >on one's screen. Not much one can do about it -- but one can
> >restart the window manager if one can find an open xterm, and the WM
> >will then reiconify the windows.
> >
> >This means the window manager is simpler, too, and less likely
> >to blow up. (I will note that there is a peculiarity on HP-UX --
> >sorry, John W :-) -- that occasionally likes to hang HP's window
> >manager (dtwm?), and X with it, somewhat. It's not clear where the
> >flaw is here, and in any event, that's why one wants nice small
> >window managers so that they don't have to page in and out.)
> >
> >OK, I'm coming out of the vehicle now, face all greasy from
> >poking around in the innards. :-) It's clear that most users won't
> >actually care whether it's typedef int (*XErrorHandler)(Display *,
> >XErrorEvent*) or EXPORT CALLBACK WinMain, but some of the underlying
> >structural elements may contribute to the stability or
> >instability of a graphics system.
> >
> >I think that what you are complaining about here are various
> >high-level user issues -- in other words, whether there's
> >a scratch on the door as you get in to start the car.
> >Granted, there can be problems, especially with Windows-specific
> >hardware (Winmodems being especially vexing).
> >
> >>
> >>I received my Mandrake update CD this week and decided to give
> >>Mandrake 7.2 another whirl, partly because I am bored at the moment
> >>and partly because I was hoping that this one was the big winner.
> >
> >Anecdotal evidence.
> >
> >["detailed log" snipped]
> >
> >I don't use Mandrake, so can't say whether it is accurate or not;
> >therefore I'm snipping it. Sorry, FF.
> >
> >The last time I installed Redhat (6.2), I did it over the net, and
> >it was extremely slick. Granted, I was helped by a high-speed
> >net connection and no sound card, but once I had created the floppies
> >and rebooted the machine, it pretty much installed itself.
> >(This particular machine didn't even have a CD-ROM, and I did have
> >some ticklish issues regarding IP address assignment for
> >various reasons -- 'pump' and NT DHCP do not get along.)
> >
> >I understand that Mandrake is (or was) a RedHat derivative,
> >but again, I haven't tried to do anything with it.
>
>
> I left the quoted text because you took the time to post it and I
> appreciate that. The problem arises amongst users however because we
> are interested in the end result and not so much the means to an end.
> Of course we are concerned when out ISP is down, or the print file
> server or such, and maybe this is where Linux can be of use, but when
> it comes to a desktop that is easily installed, has support, has
> hardware, software, applications and a friend down the street to help
> when it goes amok, Windows or possibly Mac is the ticket and Linux
> isn't even in the same ballpark.
> While the Linux people actually like compiling kernels, writing
> scripts and hunting the net to figure out how to customize their
> systems, we normal users prefer to use our computers and enjoy not
> having to jump through hoops to make things work. An example is that
> Linux Movie (Anti-Trust) that is being released by MGM in January.
> Running Linux one can not even view the video clips because they are
> in Quicktime 4.0 format. We as Windows users can, as well as the Mac
> folks. We are not willing to settle for non-support of hardware and
> software, yet the Linux folks make do with featureless and in some
> cases downright hostile applications.
> Granted they are free, but is that really the reason or is there a
> deeper darker reason?
> For every mainstream type application a Linux user can show me, I can
> show him/her a far better overall solution running under Windows and
> this is just off the top of my head.
> Printers regularly come with copies of Adobe Photoshop and coupons to
> get WordPerfect 2000 Office suite as well as many other programs for
> free or little cost (check Lexmark for example). In reality nobody is
> paying $495.00 (legally) for an Office suite, so the free stuff that
> is for the most part unstable and hostile under Linux, takes on a
> whole new meaning. Also much of this free software for Linux is
> available for Windows as well (StarOffice for example) yet virtually
> nobody is using it?
> Why is that?
>
> So anyway, I don't know what the solution is but I don't see Linux
> being on the desktop anytime soon.
> Windows and Mac are just so far ahead in that arena it isn't even
> close.
>
>
>
> Flatfish
> Why do they call it a flatfish?
> Remove the ++++ to reply.
------------------------------
From: "Kyle Jacobs" <[EMAIL PROTECTED]>
Crossposted-To: alt.linux.sux
Subject: Re: linux does NOT suck (oh yes it does)
Date: Sun, 07 Jan 2001 06:35:07 GMT
Except I was talking about an intelligent heuristics code that COULD
possibly perform system administration by recognizing "configurations".
Which DO change, but the changes ARE noticeable, AND could possibly be
recognized if the source program (the program being configured) has the
"mappings" of the configuration in it's source code WHICH is available under
Linux.
"Les Mikesell" <[EMAIL PROTECTED]> wrote in message
news:xPT56.56281$[EMAIL PROTECTED]...
>
> "Ayende Rahien" <[EMAIL PROTECTED]> wrote in message
> news:938o2v$q9j$[EMAIL PROTECTED]...
> >
> > >
> > > > Can you show me the virus for NT that can damage other people's file
> on
> > > > NTFS?
> > >
> > > Sure, just use one of the many applications that require Everyone
> > > (Full Access) to a directory, save your file there, and you're done.
> > > You could make this even easier by using Omnipage Pro, which requires
> > > Administrator access to even run.
> >
> > This goes to every permission FS in the world, you know.
> > If you give Everyone full access to a directory, Everyone will be able
to
> do
> > whatever they want with the files in that directory.
>
> It doesn't happen with the typical unix FS configuration that you
> see in /tmp or the mail spool. If you set the 'sticky' bit on the
> directory, you can allow anyone to create files (with file permissions
> being independent of the directory) but only the owner of the file is
> allowed to delete it.
>
> > I've asked a question which you've no answered.
> > What virus can damage other people files on NTFS (implied within this
> > statement is that the other people's files are protected by premissions)
?
>
> The ones that send outlook attachments to those other people. Or have
> you missed the news stories about all the companies where this has
> happened?
>
> 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: Sun, 07 Jan 2001 06:39:55 GMT
I have a better idea.
Take your head out of your ass and think about the possibilities.
ALGORITHMS. Why not? Why couldn't an algorithm produce a satisfactory
interface standard for an application's configuration.
Of course we're not talking about autoconfiguration OF the system, we're
talking about intelligent conversion of a TEXT file into a control panel
applet. The problem with an XML derived configuration tool is that
configuration formats CHANGE. What if the changes could be detected by a
simplistic AI engine and could modify the "plug-in's" of an administration
tool appropriately?
"Aaron R. Kulkis" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Kyle Jacobs wrote:
> >
> > What the hell are you smoking?
>
> Listen, Doofus...classical AI ***DOESN'T WORK****.
>
> Heuristic methods don't work reliably enough to configure your machine for
you
> ...if they did work, they would be ALGORITHMS.
>
> Now....why don't you quit making a foold of yourself and go take about
> 80 credit hours of computer science and computer systems engineering.
>
>
> >
> > "Aaron R. Kulkis" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Kyle Jacobs wrote:
> > > >
> > > > Listen, there IS a technology called "pattern detection" which works
on
> > Word
> > > > macro viruses (to detect "suspect" patterns).
> > >
> > > Of course, putting such functionality into a WYSIWYG editor so that it
can
> > > even carry a virus is the ultimate in LOUSY FUCKING DESIGN in the
first
> > place.
> > >
> > >
> > >
> > > >
> > > > Why can't pattern and behavior recognition be instituted into an
> > intelligent
> > > > recognition system to recognize the interdependencies, and MODIFY
the
> > > > previous configuration strings accordingly?
> > > >
> > > > I'm thinking an XML system meets heuristics detection from AV.
> > > >
> > > > "Roberto Alsina" <[EMAIL PROTECTED]> wrote in message
> > > > news:932c5b$ju6$[EMAIL PROTECTED]...
> > > > > In article <9306l2$5sc$[EMAIL PROTECTED]>,
> > > > > "Ayende Rahien" <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > "Roberto Alsina" <[EMAIL PROTECTED]> wrote in message
> > > > > > news:92vf9q$4hs$[EMAIL PROTECTED]...
> > > > > > > In article <92vark$i8r$[EMAIL PROTECTED]>,
> > > > > > > "Ayende Rahien" <[EMAIL PROTECTED]> wrote:
> > > > > > > >
> > > > > > > > "Roberto Alsina" <[EMAIL PROTECTED]> wrote in message
> > > > > > > > news:92tcpa$fg4$[EMAIL PROTECTED]...
> > > > > > > > > In article <92t60a$cks$[EMAIL PROTECTED]>,
> > > > > > > > > "Ayende Rahien" <[EMAIL PROTECTED]> wrote:
> > > > > > > > > >
> > > > > > > > > > "Roberto Alsina" <[EMAIL PROTECTED]> wrote in message
> > > > > > > > >
> > > > > > > > > [snip]
> > > > > > > > >
> > > > > > > > > > > > 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.
> > > > > > > > > > >
> > > > > > > > > > > And probably screw it to death. Really.
> > > > > > > > > >
> > > > > > > > > > Not likely, not if both file & application are built
> > correctly.
> > > > > > > > > > Why would it screw it?
> > > > > > > > >
> > > > > > > > > Because although it knows the options change, it has no
idea
> > of
> > > > > > > > > HOW they change. For example, if optionA is now
deprecated,
> > and
> > > > > > > > > those who set optionA to valueA should now set optionB to
> > valueB,
> > > > > > > > > it won't know, and it will (in Gus Grissom's words) screw
the
> > > > > > > > > pooch.
> > > > > > > >
> > > > > > > > The program doesn't need to remember the settings, it read
them
> > from
> > > > > > > > the file.
> > > > > > >
> > > > > > > And the setting is still the old one.
> > > > > >
> > > > > > No, because when the program installed itself, it would either
> > > > > > replace the file with a new, default one, or update the file
format.
> > > > >
> > > > > So, you have the choice of losing the configuration or hope
there's
> > > > > a converting tool.
> > > > >
> > > > > > > > A new version will update the file, and should covert the
old
> > > > > > > > file format to the new format with more/less/updated
options.
> > > > > > >
> > > > > > > No program ever comes with config file updaters.
> > > > > >
> > > > > > How hard would it be to write such a thing.
> > > > > > Or be backward compatible?
> > > > >
> > > > > If you just expect them to be backward compatible, you end as
> > smb.conf,
> > > > > with a bazillion options that work and are more or less the same.
> > > > >
> > > > > And it can indeed be a terribly difficult thing to do.
> > > > >
> > > > > [snip some]
> > > > >
> > > > > > > The format is the same. The options are not.
> > > > > >
> > > > > > I know, so?
> > > > > > It's the program's fault for keeping an old, no-longer-supported
> > > > > > format, as its config file.
> > > > >
> > > > > Who cares? The user is still left with a non-functional setup.
> > > > >
> > > > > And this is really the easy part, still. What happens if you have
> > > > > interdependent settings? For instance, What happens if a global
> > > > > default setting changes the options available for others?
> > > > >
> > > > > For example:
> > > > >
> > > > > if A is "a", then B can be "1" or "2".
> > > > > if A is "b", then B can be "3" or "4".
> > > > > if A is "c", then B must be "5".
> > > > >
> > > > > A simple example of this is fstab (if partition type is swap, no
> > > > > mount point can be specified, if fs is proc, it should default to
> > > > > /proc and so on)
> > > > >
> > > > > Now, any ideas?
> > > > >
> > > > > Really, embedding the logic of the GUI into the file itself only
makes
> > > > > the file harder to manage, and doesn't fix the problem.
> > > > >
> > > > > Consider, example smb.conf that comes with SAMBA, compared to
smb.conf
> > > > > generated from scratch via SWAT.
> > > > >
> > > > > The SAMBA one is long, and has most options in, commented.
> > > > > the SWAT one is short and simply does what it must.
> > > > >
> > > > > The SAMBA one is better if you intend to hack it without reading
the
> > > > > docs.
> > > > >
> > > > > The SWAT one is better for almost any other thing.
> > > > >
> > > > > --
> > > > > Roberto Alsina
> > > > >
> > > > >
> > > > > Sent via Deja.com
> > > > > http://www.deja.com/
> > >
> > >
> > > --
> > > Aaron R. Kulkis
> > > Unix Systems Engineer
> > > DNRC Minister of all I survey
> > > ICQ # 3056642
> > >
>
>
> --
> Aaron R. Kulkis
> Unix Systems Engineer
> DNRC Minister of all I survey
> ICQ # 3056642
>
>
> H: "Having found not one single carbon monoxide leak on the entire
> premises, it is my belief, and Willard concurs, that the reason
> you folks feel listless and disoriented is simply because
> you are lazy, stupid people"
>
> I: Loren Petrich's 2-week stubborn refusal to respond to the
> challenge to describe even one philosophical difference
> between himself and the communists demonstrates that, in fact,
> Loren Petrich is a COMMUNIST ***hole
>
> J: Other knee_jerk reactionaries: billh, david casey, redc1c4,
> The retarded sisters: Raunchy (rauni) and Anencephielle (Enielle),
> also known as old hags who've hit the wall....
>
> A: The wise man is mocked by fools.
>
> B: Jet Silverman plays the fool and spews out nonsense as a
> method of sidetracking discussions which are headed in a
> direction that she doesn't like.
>
> C: Jet Silverman claims to have killfiled me.
>
> D: Jet Silverman now follows me from newgroup to newsgroup
> ...despite (C) above.
>
> E: Jet is not worthy of the time to compose a response until
> her behavior improves.
>
> F: Unit_4's "Kook hunt" reminds me of "Jimmy Baker's" harangues against
> adultery while concurrently committing adultery with Tammy Hahn.
>
> G: Knackos...you're a retard.
------------------------------
** 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
******************************
