[Beowulf] Parallel Development Tools
Robert G. Brown
rgb at phy.duke.edu
Wed Oct 17 11:23:06 PDT 2007
On Wed, 17 Oct 2007, Jon Tegner wrote:
> Drifting off a bit further, but as I see it, the biggest advantage of FC over
> debien/ubuntu is kickstart. Or???
I don't know if that question has an easy answer. Kickstart is
certainly AN advantage in certain environments, but Debian will install
automagically over a network, and there is FAI (although I've never used
it and cannot comment on its comparative ease of use). Truthfully I'd
absolutely consider yum an advantage -- so much so that the bulk of the
Fedora installs in the future will be done by yum. Yum enables
something that is truly marvelous for people who have to install through
thin pipes (e.g. DSL links): a two stage interruptable install. It is
possible to install a barebones system in the first pass in a relatively
short period of time and have it come up on the second boot and run yum
to complete the rest of the install. Yum is robust, more or less,
against midstream interruption caused by flaky networks and the like,
where anaconda in traditional RH installs has to be restarted from
scratch if anything breaks in midstream, something that happens way too
often.
As far as management goes, they may provide different management tools
but that doesn't matter too much to me as I don't use management tools
much. I'm an Old Guy and I just use jove to edit the config files in
/etc because I don't trust GUI tools to do so (correctly) for me. I
will SOMETIMES invoke systems config tools for things like iptables and
firewalls, but only where my needs are trivial and it is just matter of
enabling a standard hole for e.g. ssh, http, or whatever.
Both of them have WAY more packages than I can ever use, and both of
them seem to have all or nearly all of the packages I do use. It takes
me some 3-4 days of "shopping" post-upgrade to just look over what each
new release of Fedora has in it. I then end up crapping up my system
with all kinds of new toys and later regretting it, then uncrapping it
(a good thing about yum is that good old "yum erase" part:-), to the
point where I haven't even LOOKED at all the stuff on Fedora 7. My
favorite Debian correspondant tells me that nobody even tries to look
anymore on Debian, as I was running out of gas in that regard at 10
kilopackages and can't imagine wading through 20 kilopackages looking
for gold. Truthfully, I end up USING more like 80 or 100 or something
like that, and might find another 100 passingly interesting or useful in
some narrow context. Or games. Hard to have too many games, as long as
they work...;-)
If I had my druthers, we (the Linux community) would work towards a
unified packaging scheme, a nice binary standard, a common /etc layout
(ideally one that converts a lot of /etc files from flat to xml, since
flatfiles suck for the specification for slowly varying extensible
hierarchical data one would like to manage with GUI tools). Lower the
barriers between distros, not raise them. Get it so that one can
kickstart Debian, use aptitude (with a configuration option set) with
Fedora. Get it so that a binary package on one can convert and load on
the other (dependencies permitting) without library conflicts. Get it
so a GUI tool written to manage one could equally well manage the other,
or ALL others.
But that just plain makes too much sense for users, and not enough sense
for corporate heads who ultimately rely on differences to sell their
products, not similarities.
Sigh,
rgb
>
> /jon
>
> Robert G. Brown wrote:
>> On Wed, 17 Oct 2007, andrew holway wrote:
>>
>>> Apt-cache with a bit of grep is a powerful tool indeed.
>>>
>>> $apt-cache search foo | grep bar
>>>
>>> everyone I work with however prefers yum. They regard Debian as being
>>> a bit backward.
>>
>> I don't know if Debian is backward, but I will affirm that yum is pretty
>> fashion-forward. I'm probably biased, of course, since I wrote the
>> original HOWTO and since Seth developed it about seventy feet from where
>> I'm sitting right now. I've never seriously contributed to its
>> development but I've been a user for years, and it continues to improve
>> even now.
>>
>> There are lots of ways to search out info using yum, some faster or more
>> complex than others, but the most common ones, also the most useful and
>> fastest, are as simple as "yum list \*whatever\*, e.g. --
>>
>> rgb at ganesh|B:1011>yum list \*pvm\*
>> Available Packages
>> pvm.x86_64 3.4.5-7.fc6.1 fedora
>> pvm-gui.x86_64 3.4.5-7.fc6.1 fedora
>>
>> It also supports yum search foo (likely to get more than you really
>> want), yum info, yum deplist, etc. most of which I rarely use. It's
>> nice to do "yum info \* > /tmp/yum.list" once right after an install or
>> upgrade, though, as this pretty much gives you a catalog of all the
>> available packages and their synopses, so that you can find almost
>> anything efficiently and interactively with less /tmp/yum.list and its
>> built in find tools, or via grep , or by just plain browsing through it.
>>
>> Of course with 20K or so packages, browsing through Debian is a bit more
>> tedious I understand...;-)
>>
>> rgb
>>
>>>
>>> On 17/10/2007, Tim Cutts <tjrc at sanger.ac.uk> wrote:
>>>>
>>>> On 16 Oct 2007, at 10:19 pm, Robert G. Brown wrote:
>>>>
>>>>> On Tue, 16 Oct 2007, Jon Tegner wrote:
>>>>>
>>>>>> You should switch to a .deb-system, to save you some trouble:
>>>>>>
>>>>>> $ apt-cache search jove
>>>>>> jove - Jonathan's Own Version of Emacs - a compact, powerful editor
>>>>>>
>>>>>> Sorry, couldn't resist ;-)
>>>>>
>>>>> Hey, it's ok. I'm actually trisystemal. FC 6 on top (soon to jump to
>>>>> 8, but in no hurry), VMware, then debian and XP Pro VM. And yes,
>>>>> it was
>>>>> a good thing debian already had jove as I still don't really know
>>>>> how to
>>>>> build debian packages,
>>>>
>>>> If you want a good introduction to debian packages and how they work,
>>>> then I recommend Martin Krafft's book "The Debian System". I've been
>>>> a Debian Developer for ten years, and that book still teaches me
>>>> useful stuff about Debian on a regular basis.
>>>>
>>>> The chapter on packaging is superb; it teaches you how to make
>>>> packages from the ground up, so you really understand how they work,
>>>> starting with the basic fact that fundamentally a debian binary
>>>> package is an ar archive which contains two tarballs. One,
>>>> data.tar.gz contains the files belonging to the package. The other,
>>>> control.tar.gz, contains the scripts and information about the
>>>> package used by the packaging tools, and at a minimum this contains
>>>> two files: DEBIAN/control, which contains the information about the
>>>> package (description, dependencies and whatnot) and DEBIAN/md5sums
>>>> which is, as you'd expect, a list of md5sums of all the plain files
>>>> in the package.
>>>>
>>>> Once he's shown you how to build a Debian package manually like that,
>>>> he then shows you how to do it the more normal way using the various
>>>> wrapper scripts that Debian provides for the purpose to make life a
>>>> bit easier (and to help enforce the Debian policy on packages)
>>>>
>>>> Debian doesn't really have a source package idea like Red Hat -
>>>> instead, when you use "apt-get source" to download the source for a
>>>> package you get three files; the upstream tarball, which is
>>>> completely unmodified from upstream. You also get a gzipped patch,
>>>> and a description file containing md5sums for the patch and the
>>>> tarball, amongst other things. Typically, the patch creates a debian
>>>> directory within the upstream source directory, and inside that
>>>> debian directory is a file called "rules". This is just a normal
>>>> makefile, containing all the instructions for configuring, compiling
>>>> and packaging the software on a Debian system. Once you have one of
>>>> these things, building the .debs is just a matter of typing:
>>>>
>>>> dpkg-buildpackage -rfakeroot
>>>>
>>>> or something similar. There are still fancier things available for
>>>> doing this by keeping the sources and debian/* files in a CVS,
>>>> subversion or other revision control repository. I use these in my
>>>> own package management activities to be able to go back and build
>>>> previous releases when users report bugs against them.
>>>>
>>>>> and manage to get myself confused by apt tools
>>>>
>>>> I can sympathise. I've only started using aptitude since etch came
>>>> out, and it's taken me some time to get used to, but now that I am, I
>>>> quite like it, for the most part. Especially the etch version, the
>>>> version of it in sarge had some really annoying behaviour under
>>>> certain circumstances.
>>>>
>>>>> (I'm too used to yum). But there is no doubt:
>>>>>
>>>>> a) Debian is a perfectly useful, fully functional variety of linux,
>>>>> and I have been painfully taught to bow down before its selection of
>>>>> available packages, which is for all practical purposes inexhaustible.
>>>>> In fact, you need a search engine with powerful features even to go
>>>>> shopping amongst them.
>>>>
>>>> ... which fortunately it provides for you. It's called apt-cache.
>>>>
>>>> Regards,
>>>>
>>>> Tim
>>>>
>>>>
>>>> --
>>>> The Wellcome Trust Sanger Institute is operated by Genome Research
>>>> Limited, a charity registered in England with number 1021457 and a
>>>> company registered in England with number 2742969, whose registered
>>>> office is 215 Euston Road, London, NW1 2BE.
>>>> _______________________________________________
>>>> Beowulf mailing list, Beowulf at beowulf.org
>>>> To change your subscription (digest mode or unsubscribe) visit
>>>> http://www.beowulf.org/mailman/listinfo/beowulf
>>>>
>>>
>>
>
--
Robert G. Brown
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone(cell): 1-919-280-8443
Web: http://www.phy.duke.edu/~rgb
Lulu Bookstore: http://stores.lulu.com/store.php?fAcctID=877977
More information about the Beowulf
mailing list