Re: Debian flamewar (plus a "GNU/Linux" rant)

2005-02-16 Thread Paul Iadonisi
On Tue, 2005-02-15 at 22:20 -0500, Benjamin Scott wrote:

[snip]

>   Hope that clears that up.  :-)
> 
> > You may not agree with my estimates of what most problems with rpm
> > have to do with ...
> 
>   If anything, I strongly *agree* with your views on this subject.

  Hmm, okay, that does clear it up.  Sorry, I guess I misread what you
wrote.

[snip]

>  And the fact that BSD ports downloads, configures,
> builds, and installs all the specified components *from source* leads BSD
> bigots into thinking that the BSD ports packagers must be doing a much
> better job then Red Hat or Debian packagers.

  Yeah, the source junkies never seem to take into account managing
hundreds or even thousands of boxes.  './configure;make;make install'
gets old *real* fast in those situations.

> 
>   And, again, it's also largely responsible for why Windoze sucks so much.  
[snip]
>  -- then, yah, it's a minor kind of
> miracle the thing ever works at all.

  Does it work at all?  ;-)

-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: Debian flamewar (plus a "GNU/Linux" rant) (plus PHP4/PHP5 experiences)

2005-02-16 Thread Fred
On Tue, 2005-02-15 at 23:28 -0500, Kevin D. Clark wrote:
> Benjamin Scott <[EMAIL PROTECTED]> writes:
...
> You haven't lived until you realize that the poor slobs three cubes away from
> you have 6 copies of the "same" DLL, which they categorize by file
> size.  When they want to run application A, they copy the X-byte DLL
> to the system directory.  When they want to run application B, they
> copy the Y-byte DLL to the system directory.  You hear people yelling
> things like "NO...DON'T RUN THE APPLICATION WITH THE 9689-byte DLL --
> IT CORRUPTS THE DATABASE!".
> 
> Things like this cause me to weep.

It would be a definite ROFL if it weren't so serious.

In the past I've been involved with BIG Windows systems/applications
developments, and you get nowhere unless you pay a big support fee to
Microsoft and develop first-name relationships with various key
engineers.

I doubt if the situation has changed much today. Haven't bothered
looking at their .net offerings since I became a die-hard Java and Linux
type by then. 

While we are on the upgrade subject, I will soon be upgrading my
dedicated server from RH9 to FC3. Upgrades of this magnitude *always*
involved gotchas, but I've done this upgrade once before so I kinda know
what to expect. 

I am forced to do this upgrade, BTW, because I *need* PHP5 running on
that server, and keep running into dependency issues under RH9 that yum
cannot resolve -- mainly because the RH9 repositories are no longer kept
up to date. PHP5 has it own peculiar dependencies depending on what
features you enable when you build it. And I spent time resolving one
such dependency on RH9 and ran into yet another after that. That was a
hint and a half for me to bite the bullet and just upgrade the entire
distro.

Yum works like a charm when everything is up to date in the
repositories. It's next to useless otherwise.

I've not used Debian before, and now after having followed this
"flamewar", methinks I'll stick to Fedora. RPMs and Yum are not perfect
by a longshot, but I know how to work around those headaches. apt-get
would introduce a new set of headaches, and I'm running low on the
asprin. :-)

> --kevin

BTW, if anyone's interested, getting my PHP4 code to run under PHP5 was
mostly painless -- just a few minor changes I had to make.

Alas, my code can't be pure PHP5, but parts of it must still run under
PHP4 systems. Since PHP5 code generates syntax errors under PHP4, I've
had to devise means to keep PHP5-code from even *loading* under PHP4.
Turns out that my equivalent of an autoloader that I created for the
PHP4 code lended itself nicely to the solution.

The biggest difference which I had to deal with is how objects are
passed, assigned and copied on PHP5. Since I've been paying strict
attention to this under PHP4, that made it all that much easier to fix.
The "clone" keyword under PHP5 breaks under PHP4, so I took the rather
clever approach of using "clone(...)" which winds up calling a dummy
function under PHP4 and works as the "clone" keyword under PHP5. That is
pretty much the only really nasty kludge I had to implement.

I really *like* PHP5 because now I can do the same style exception
handling I had gotten used to with Java and C++. I also like the stack
trace dump I automatically get by echoing the exception object. And
there are a few other niceties that gives me the "it's about bloody
time" reaction.

-- 
-- Fred
"Don't let IE happen to YOU!"
- My daughter, who designs web sites for everything BUT Internet
Explorer.


___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: Debian flamewar (plus a "GNU/Linux" rant)

2005-02-15 Thread Kevin D. Clark

Benjamin Scott <[EMAIL PROTECTED]> writes:

>   And, again, it's also largely responsible for why Windoze sucks so much.  
> When everything a binary which you have no source for, and no two packages
> share information on what is being installed, and you can only install one
> version of any given library at once time -- then, yah, it's a minor kind of
> miracle the thing ever works at all.

You haven't lived until you realize that the poor slobs three cubes away from
you have 6 copies of the "same" DLL, which they categorize by file
size.  When they want to run application A, they copy the X-byte DLL
to the system directory.  When they want to run application B, they
copy the Y-byte DLL to the system directory.  You hear people yelling
things like "NO...DON'T RUN THE APPLICATION WITH THE 9689-byte DLL --
IT CORRUPTS THE DATABASE!".

Things like this cause me to weep.

--kevin
-- 
GnuPG ID: B280F24E And the madness of the crowd
alumni.unh.edu!kdc Is an epileptic fit
   -- Tom Waits

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: Debian flamewar (plus a "GNU/Linux" rant)

2005-02-15 Thread Benjamin Scott
On Tue, 15 Feb 2005, at 12:01pm, [EMAIL PROTECTED] wrote:
>> There must be something about this that is either hard to comprehend, or
>> hard to accept.  It gives a lot of RPM users trouble, it gives Debian
>> users a sense of superiority,
> 
>   Um, Ben ... I take exception to this.  By saying that it is hard to
> comprehend or hard to accept your are implying that the problem is on my
> end.

  That was not my intent.  As I said, I know *you* know this.  I was trying
communicate an observation that it appears, *in general*, people have a
problem with this concept.  People, *in general*, keep trying to blame
things on a package manager, or a dependency manager, or a binary package
repository, or a lack of any of these, when the cause is really just that
binary compatibility is simply a lot harder then many people *in general*
appreciate.

  Hope that clears that up.  :-)

> You may not agree with my estimates of what most problems with rpm
> have to do with ...

  If anything, I strongly *agree* with your views on this subject.

> I don't believe for a second that it has much to do with Debian users'
> sense of superiority.

  I was attempting to assert, about half-seriously, that the binary
compatibility confusion issue was a contributor to Debian elitism.  
Specifically, that having such a large pool of configured, compiled, and
tested packages readily available via "apt-get install foo" leads a lot of
Debian people into think APT is somehow magic.

  Likewise, RPM properly saying "I don't think you have the pieces you need
for this to work" leads so many people into thinking that RPM *causes*
"dependency hell".  And the fact that BSD ports downloads, configures,
builds, and installs all the specified components *from source* leads BSD
bigots into thinking that the BSD ports packagers must be doing a much
better job then Red Hat or Debian packagers.

  And, again, it's also largely responsible for why Windoze sucks so much.  
When everything a binary which you have no source for, and no two packages
share information on what is being installed, and you can only install one
version of any given library at once time -- then, yah, it's a minor kind of
miracle the thing ever works at all.

  :-)

-- 
Ben Scott <[EMAIL PROTECTED]>
| The opinions expressed in this message are those of the author and do  |
| not represent the views or policy of any other person or organization. |
| All information is provided without warranty of any kind.  |


___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: Debian flamewar (plus a "GNU/Linux" rant)

2005-02-15 Thread Paul Iadonisi
[sorry if this is a double post.  I posted with the wrong address]

On Tue, 2005-02-15 at 00:54 -0500, Benjamin Scott wrote:
> On Thu, 10 Feb 2005, at 6:43pm, [EMAIL PROTECTED] wrote:
> >   Wait, I'm have a little trouble understanding the problem.
> 
>   I know you know this, but it's educational to state it explicitly:
> 
>   The problem is simply that binary compatibility is hard.

  Agreed, but it is most certainly not something that should be abandon
given the potential benefits.

[snip]

>   There must be something about this that is either hard to
comprehend, or
> hard to accept.  It gives a lot of RPM users trouble, it gives Debian
users
> a sense of superiority,

  Um, Ben ... I take exception to this.  By saying that it is hard to
comprehend or hard to accept your are implying that the problem is on my
end.  You may not agree with my estimates of what most problems with rpm
have to do with (i.e.: not real problems with rpm *itself*, but rather
with the way it is being used, or the way specific rpm packages are
built), but I'm sure, if necessary, I could gather some real statistics
that match my assertion that rpm is not the problem.
  I don't believe for a second that it has much to do with Debian users'
sense of superiority.  I've seen that sense of superiority displayed
many times (though not much on this list) and it's nothing more than
plain arrogance.  And a refusal to look at what the real problems are,
i.e.: not with rpm itself.

>  it's what makes BSD ports work so well, and it's
> largely responsible for making Microsoft Windows the unholy mess that
it is.  
> Clearly, there's a disconnect here.

-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: Debian flamewar (plus a "GNU/Linux" rant)

2005-02-14 Thread Benjamin Scott
On Thu, 10 Feb 2005, at 6:43pm, [EMAIL PROTECTED] wrote:
>   Wait, I'm have a little trouble understanding the problem.

  I know you know this, but it's educational to state it explicitly:

  The problem is simply that binary compatibility is hard.

  Easy enough; it's the implications that are subtle.  Like that building a
key system library with different options makes it a different package.  
That changing a key system library thus changes the entire configuration
management scenario.  That a package that has different subcomponents, each
with their own dependencies, is a package that depends on all of them.  
That auto-built dependencies tend to be even pickier then the real ones.  
That packages are only as good as their (builder supplied) metadata.  And so 
on and so forth.

  There must be something about this that is either hard to comprehend, or
hard to accept.  It gives a lot of RPM users trouble, it gives Debian users
a sense of superiority, it's what makes BSD ports work so well, and it's
largely responsible for making Microsoft Windows the unholy mess that it is.  
Clearly, there's a disconnect here.

-- 
Ben Scott <[EMAIL PROTECTED]>
| The opinions expressed in this message are those of the author and do  |
| not represent the views or policy of any other person or organization. |
| All information is provided without warranty of any kind.  |

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: Debian flamewar (plus a "GNU/Linux" rant)

2005-02-14 Thread Benjamin Scott
On Thu, 10 Feb 2005, at 11:15pm, [EMAIL PROTECTED] wrote:
> Maybe someone should start an "OSS/Linux" meme.

  I hereby propose FLOSS: Free/Linux/Open Source Software!

  Floss every day to keep decay away!  ;-)

-- 
Ben Scott <[EMAIL PROTECTED]>
| The opinions expressed in this message are those of the author and do  |
| not represent the views or policy of any other person or organization. |
| All information is provided without warranty of any kind.  |

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: Debian flamewar (plus a "GNU/Linux" rant)

2005-02-10 Thread Bill McGonigle
On Feb 10, 2005, at 18:43, Paul Iadonisi wrote:
  Okay, putting the sarcasm aside, I have no problem with referring to
Red Hat Enterprise Linux as well as Fedora Core as "GNU/Linux based
operating systems."
I used to not care too much about the push for GNU/Linux but upon 
further reflection it does tend to denigrate the contributions of other 
significant developers.  A linux webserver depends just as much on 
Apache as it does on libc as it does on the linux kernel.

Maybe someone should start an "OSS/Linux" meme.
-Bill
-
Bill McGonigle, Owner   Work: 603.448.4440
BFC Computing, LLC  Home: 603.448.1668
[EMAIL PROTECTED]   Cell: 603.252.2606
http://www.bfccomputing.com/Page: 603.442.1833
AIM: wpmcgonigleSkype: bill_mcgonigle
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss


Re: Debian flamewar (plus a "GNU/Linux" rant)

2005-02-10 Thread Paul Iadonisi
[As The Linux Lobbyist comes to life, he says...]

Oh, goody, my favorite flamewar! ;-)

On Thu, 2005-02-10 at 01:09 -0500, Jason Stephenson wrote:
> Heh. I find this discussion mildly interesting from where I sit, a 
> mostly xBSD user.

  As preface, let me say that I like the BSDs somewhat, save the anti-
GPL bigotry among many of the developers that is usually accompanied by
a completely lack of understanding (or deliberate misrepresentation) of
its terms.

[snip]

>  we had multiple systems running HP-UX, 
> Solaris, IRIX, Red Hat GNU/Linux, Debian GNU/Linux, FreeBSD, and even 1 

  Hmm, "Red Hat GNU/Linux"?  Is that something new that Red Hat is
selling and/or distributing?  Because I've never heard of it before.
Funny...poking around http://www.redhat.com/, it looks like Red Hat has
heard of it either!  So I guess I'm not crazy.
  Okay, putting the sarcasm aside, I have no problem with referring to
Red Hat Enterprise Linux as well as Fedora Core as "GNU/Linux based
operating systems."  But as far as I'm concerned, when you put the
distribution together, you get to keep the naming rights.  Not the FSF.
Not the GNU project.  And not (sorry, I know he may be on this list, but
that's life) Richard Stallman.  For the record, I like and agree with
nearly everything, if not everything that has come from those three.
And if RMS and I hashed this particular issue out over a latte we'd
probably end up agreeing in the end.


> It was largely the issues of "package management" that made me decide to 
> go with FreeBSD and OpenBSD for my computers at home, instead of various 
> flavors of GNU/Linux. I found the ports collections to be the solution 
> to deb and rpm hells. In almost every case, I cd into the program's 
> ports directory, type 'make install' and the software builds, installs, 
> and then runs with no hitches. There's very little to package manage and 
> that's how it should be, IMHO.

  Ah, but you are demonstrating almost the exact disconnect that Ben
spoke about in his initial complaint about how the Debianites equate the
large collection of debs available at many mirrors with the
functionality of apt-get when apt-get is not at all unique and arguably
inferior to many of the equivalent dependency resolution tools available
in rpmland.
  What's missing in the GNU/Linux world (there, see?  I'm not totally
opposed to "GNU/Linux" usage ;-)) outside of Debian is a good process.
(Debian, of course, could use a little *less* process so that there is
an update more than once a decade.)  The tools are really there with
possibly some minor tweaks necessary.
  What the BSD ports collection seems to have is an excellent process
for making sure that everything works together.  I don't know how big
the ports collections are in the various BSDs, but its possible that
there is also more software than you will find in the typical GNU/Linux
distro (save Debian, of course).

> I experienced all kinds of problems on the Linux machines, mainly 
> because we were a research institution and the profs would need some 
> bizarre hardware combination that wouldn't quite work with the default 
> packages from the various releases. It became a nightmare trying to 
> maintain a machine loading packages from 2 different Debian releases, or 
> trying to install binary RPMs on some of the RedHat machines with 
> different kernels, etc.

  Wait, I'm have a little trouble understanding the problem.  What were
the problems specifically?  If you are saying that you needed to install
a custom kernel and because you did that (with make bzImage;make
modules;make install;make modules_install or whatever), then I think I
see the problem.
  It all comes down to packaging.  I'm a packaging fanatic.  I hate
stuff in /usr/local.  I also won't touch a 'make install' as root with a
ten foot pole that poops all over my filesystem.  I create rpms in my
sleep even.  If I were a Slackware fan, I'd create tgz's in my sleep.
The point is, an OS should be divided up into manageable chunks so that
they can be updated independently and without source.  Source is good,
but how many times, for example, do you want to build perl and answer
those questions?
  So, I've even going as far as foregoing the (rather baroque, IMO)
usually kernel compile/install.  Instead, I start with Red Hat's source
rpm file and make the mods there.  Add a tag to the Release: to indicate
it's changed and 'rpmbuild -bs SPECS/kernel-2.6.spec;rpmbuild --rebuild
--target=i586,i686,noarch SRPMS/kernel--.src.rpm' and
a while latter I have some binary kernel rpms that keeps the dependency
tree in /var/lib/rpm consistent.  It's work, yes, but once you master
it, it's *much* easier to diagnose many classes of problems.
  You master the OSes you need to deal with.  What I'm saying is that
your choice to go with BSDs in some places was very likely the right one
for you, particularly if you had more of an interest in learning them
because that inertia alone would help you in managing