[nylug-talk] I'm a Gentoo convert.

Ruben Safir ruben at mrbrklyn.com
Mon Mar 5 20:01:07 EST 2007


> 
> I've used portage. It's nice, but not my cup of tea. I've used
> freebsd. It's nice, but not my cup of tea. I've used netbsd. It's not
> too nice, and it's not my cup of tea. I've used openbsd. It's nifty,
> but not my cup of tea. Have you used these systems? 
> 


I origianlly wrote software for my PhD on BSD-OS system and Free-BSD
which included an interface to a specific peice of High Liquid Chromotrography
system which was needed to get results and crunch the data for the research.

In addition to that, off the top of my head, I've used Open-BSD, Free-BSD, SCO
which was a system I wrote of lot of C software on, Slackware, Redhat 4.2 on to about 6,
SuSe from 5.2 on, Yellow Dog, Mandrake, Debian, Knoppix, Memphis, Linspire, turbo linux, 
Caldera, which I first got from my first NYLUG meeting, Corel Linux, Fedora with 
clusters, not to mention VMS, OS-9 and some OS involving punchcards in the late 1960's 
when I was in 2nd grade.

Off the top of my head.  At one time we were doing installfests nearly every other week and
the single only thing I every refused to install was SLS on ancient an ancient laptop for 'fun'
and when someone wanted to install debian through my modem connection. In fact, I've installed 
so many systems, and so many distros, and taught so many other people to do installs and kernel
compilations, that frankly the new distro of the year doesn't make me all that excited.  Reports
that is could take all day to install Gentoo was a big put off, although I clearly understand
the advantages that a ports like system can give you.


> > > Why are we still stuck talking about the religion of how to hand
> > > someone something for free in 2007?
> > 
> > Someone else might be able to make this clearer, but the only religious
> > topic I mentions was in relationship to Purim.  I wished everyone a happy
> > Purim.  If that was offense I take it back.  Other than that I'm at a loss at 
> > what your even refering to.
> 
> Yes, happy purim. But you wandered off-topic to a trope about how
> apache (and by extensions software in general) should be
> distributed. Which is religion because it's about belief, not about
> how software is distributed or how it's used, but how you want people
> to use it.
> 

Actually, it is exactly parellel to the previous discussion. Portage presents a
system to use its package management system to compile cleanly then entire OS.
For me, this seems to be too much.  But the Apache distrbibution and compilation
tools do the same for Apache.

> > > The reality is that the software is out there. for the most part it's
> > > free and as long as you don't get pissy with the author they'll help
> > > you as much as they can (deferring to the distro when they've
> > > broken/fixed something). 
> > 
> > Sometimes they do and sometimes they don't and sometimes they tell you
> > that the code is the documents and sometimes they take the attitude that if
> > you can't understand the code that you essentially don't deserve to use
> > the product.
> 
> So... how does that relate to your trope about compiling source
> vs. packaging?
>  
> > I would strongly disagree with most of these attitudes.  This is not related
> > to the current thread, so I'm not certain as to why you bring this up.
> 
> I bring it up as a fait accompi - software packaging is there, yet you
> rail against it as though it's something you can stop.
>

I'm not the one railing at all.  I'm trying to teach you something and to discuss something
I find interesting.  If your not interested in learning something new then I can't be made
to be at fault for your being snappy.  If you depend on package management alone to work
with your apache installtion, you'll end up in DLL and Package Management hell, as was the
case in the prior thread.  Furthermore, you'll be crippled in trying to discuss fixes for
your setup because your limited to understanding your problem only within the confines of
the packaging system.  And in fact, in the case before the user had to find a non-supported
package to make his system work.  That's not ideal with either the packaging system or understanding
your apache installation.

Gentoo seems to largely eliminate issues of this kind through Portage, because it compiles everything,
and as Marco said, eliminates the RPM-Hell problem.  However, there is a cost in terms of time and 
energy.



> > > Beyond that, why do you (and others) want people to have to buckle
> > > under and subscribe to a sub-sub-sub-sub-sub-specialization of an
> > > overall beneficial ideology or else you won't respect their choices?
> > > This isn't supposed to be about preventing people's choices.
> > 
> > Again, you'll have to explain yourself more clearly here and with less
> > heat if you want a rational descussion.
> 
> I'm tired of you saying that apache is meant to be distributed as
> source, compiled, and then distributed, so don't use packages. 

Your being 'tired' is not a reflection of anything I've said.  I've given the
very specific reasons why the Apache Organzation devotes so much of its time
in explaining how to install Apache from source, and why it has developed
important and well thoughtout new tools for distributing its source and 
easing its compilation.

The installation instructions on Apache.org are documented right here:

http://httpd.apache.org/docs/2.0/install.html
---------------------------------------------------------------
Download  	$ lynx http://httpd.apache.org/download.cgi
Extract 	$ gzip -d httpd-2_0_NN.tar.gz
$ tar xvf httpd-2_0_NN.tar
Configure 	$ ./configure --prefix=PREFIX
Compile 	$ make
Install 	$ make install
Customize 	$ vi PREFIX/conf/httpd.conf
Test 	$ PREFIX/bin/apachectl start

NN must be replaced with the current minor version number, and PREFIX must be 
replaced with the filesystem path under which the server should be installed. 
If PREFIX is not specified, it defaults to /usr/local/apache2.

Each section of the compilation and installation process is described in more detail 
below, beginning with the requirements for compiling and installing Apache HTTPD.



------------------------------------------------------------------------------
The next step is to configure the Apache HTTPd source tree for your particular platform and personal 
requirements. This is done using the script configure included in the root directory of the distribution.
(Developers downloading an unreleased version of the Apache HTTPd source tree will need to have autoconf 
and libtool installed and will need to run buildconf before proceeding with the next steps. This is 
not necessary for official releases.)

	To configure the source tree using all the default options, simply type ./configure. 
	To change the default options, configure accepts a variety of variables and command line options.

	The most important option is the location --prefix where the Apache HTTP Server is to be 
	installed later, because Apache HTTPd has to be configured for this location to work correctly. 
	More fine-tuned control of the location of files is possible with additional configure options.

	Also at this point, you can specify which features you want included in Apache HTTPd by enabling 
	and disabling modules. The Apache HTTP Server comes with a Base set of modules included by default. 
	Other modules are enabled using the --enable-module option, where module is the name of the module 
	with the mod_ string removed and with any underscore converted to a dash. You can also choose to 
	compile modules as shared objects (DSOs) -- which can be loaded or unloaded at runtime -- by using 
	the option --enable-module=shared. Similarly, you can disable Base modules with the --disable-module 
	option. Be careful when using these options, since configure cannot warn you if the module you 
	specify does not exist; it will simply ignore the option.

	In addition, it is sometimes necessary to provide the configure script with extra information about 
	the location of your compiler, libraries, or header files. This is done by passing either environment 
	variables or command line options to configure. For more information, see the configure manual page.

	For a short impression of what possibilities you have, here is a typical example which compiles Apache 
	for the installation tree /sw/pkg/apache with a particular compiler and flags plus the two additional 
	modules mod_rewrite and mod_speling for later loading through the DSO mechanism:

	$ CC="pgcc" CFLAGS="-O2" \
	      ./configure --prefix=/sw/pkg/apache \
	      --enable-rewrite=shared \
	      --enable-speling=shared

	      When configure is run it will take several minutes to test for the availability of features 
	      on your system and build Makefiles which will later be used to compile the server.

	      Details on all the different configure options are available on the configure manual page.

> How you
> write it is illogical. I suppose you mean that it should be downloaded
> and built everywhere and anyone doing anything different is wrong, but
> everyone's heard it before. If someone wants to do it that way, they
> can, but your opinion has been heard, and it's certianly not going to
> change the opinion of those who are distributing the software - either
> the source or the package.
>  

Your listening to what you want to hear rather than what I'm saying.  I'm saying that if you want to be
an expert in Apache, you can't avoid understanding its code base and its compilation tools.  Further more,
in the spirit of Free Software, I highly encourage people to give it a try and to work with the source, even
build a custom module or two.  Its a lot easier than one would think and you'll be miles ahead from the
experience.

> > > 
> > > IMO if you didn't write the software and you're not contributing to
> > > it, you don't get the right to b***h about what gets done with
> > > it. Leave that to the people who have to deal with it because they
> > > take responsability for it. Stop talking shit from the gallery.
> > 
> > This is completely unrelated to the thread BUT, its wrong, fundementally wrong
> > and destructive to Free Software.  Its just plain bad business to ignor the
> > needs of your user base if you hope for a project to be a success.
> 
> It's absolutely related. If you're not helping, find a way to help
> (which you do well). Part of helping that's difficult for a lot of
> people, however, is to not snipe at silly things that aren't problems
> and treat it as though it's a big deal and to keep boring everyone
> else wtih it.
>

Well, I agree with this.  But more importantly, who has the time any more for sniping.  I have 6 kids,
4 or them on this mailing list and who work with these systems every day.  I need to keep them fed
and have little time for non-profitable adventures.  I leave it to the kids to blowout their hard drives
with the latest distro rage and to run the installfests.


Ruben
-- 
http://www.mrbrklyn.com - Interesting Stuff http://www.nylxs.com - Leadership Development in Free Software So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world  - RI Safir 1998 http://fairuse.nylxs.com  DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 "Yeah - I write Free Software...so SUE ME" "The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society." "> I'm an engineer. I choose the best tool for the job, politics be damned.< You must be a stupid engineer then, because politcs and technology have been attacted at the hip since the 1st dynasty in Ancient Egypt.  I guess you missed that one."


More information about the nylug-talk mailing list