"Which distribution?" ...
Matt McLeod
an argument.
Which is why I'm asking it here instead of over in col* -
reasonable answers aren't all *that* uncommon around here.
The situation:
We have about 50 Sun workstations of varying spec (from
SS4's to Ultra 5's). Gradually they're all being replaced
by U5's.
Management wants us to trial the use of PCs with Linux
or FreeBSD as a replacement for buying new workstations.
My preference is for FreeBSD (I've tried maintaining a couple
of Red Hat boxes, and, well, no offense to the RH guys, but
it really wasn't a lot of fun), but we need to run VMware,
and that apparently doesn't run under FreeBSD's Linux
emulation, so...
The key thing, really, is that it needs to be easy to
maintain a whole heap of machines. We don't worry about it
so much with Solaris because it isn't our job to maintain
the workstations, but if we move to something else we become
unsupported, so suddenly we care.
I've looked at Debian, Red Hat, and SuSE. None of them
really seem to do the "easy updating of a heap of machines"
thing as well as FreeBSD does - is there a distribution I'm
missing which comes anywhere near FreeBSD on this one?
Matt
--
Matt McLeod Putt's Law:
System Administrator Technology is dominated by two types of people:
ASAC, Ericsson Australia Those who understand what they do not manage.
<m...@asac.ericsson.se> Those who manage what they do not understand.
Jim Kingdon
> really seem to do the "easy updating of a heap of machines"
> thing as well as FreeBSD does - is there a distribution I'm
> missing which comes anywhere near FreeBSD on this one?
Hmm, I haven't used it myself, but wouldn't the Debian apt-get be
pretty good for this? At least, I seem to keep hearing from people
who love it.
As for Red Hat, well, I know that we (feels strange to use that word,
but there it is) have made some attempts to improve this in the past
(KickStart) and are planning to make more in the future. Since I
haven't actually maintained heaps of machines, I don't really know
whether said attempts have been _successful_, however ;-).
Matt McLeod
>> I've looked at Debian, Red Hat, and SuSE. None of them
>> really seem to do the "easy updating of a heap of machines"
>> thing as well as FreeBSD does - is there a distribution I'm
>> missing which comes anywhere near FreeBSD on this one?
>
>Hmm, I haven't used it myself, but wouldn't the Debian apt-get be
>pretty good for this? At least, I seem to keep hearing from people
>who love it.
FreeBSD (and presumably the other BSDs) are extremely easy to
maintain in largish numbers -- you have one box keep in sync
with the source tree, keep an eye on the appropriate mailing
lists, and do the occasional build followed by make installworld'ing
the rest (which are mounting /usr/src and /usr/obj from the first
machine). Third-party stuff lives in /usr/local (and is generally
installed on the servery box using the ports collection).
Nice, simple, elegant.
This has a fairly clean feel (to me, anyway). The Debian
approach isn't *bad*, but it "feels" messy. Not as messy
as RH, though.
>As for Red Hat, well, I know that we (feels strange to use that word,
>but there it is) have made some attempts to improve this in the past
>(KickStart) and are planning to make more in the future. Since I
>haven't actually maintained heaps of machines, I don't really know
>whether said attempts have been _successful_, however ;-).
The basic problem IME with RH isn't doing the installs. It's
keeping a heap of machines up-to-date. Last I recall (and I'll
be glad to be corrected on this), which was around 5.0, there
wasn't really any automated process for this - it was a case of
download the RPMs, figure out what order to install them, then
install. Debian makes this easier (as you've noted), but
the BSDs make it so amazingly simple that even trying to keep
a lot of Solaris boxes in sync seems scary (and it's not *that*
difficult there, either - grab the latest patch cluster, install,
Theoretically, anyway).
The other hitch with RH is that it seems to go for having everything
installed locally (at least if you're going to do more than a basic
install then build everything else yourself, which is generally
what I prefer to do anyway). I'd rather only have one set of
third-party tools to maintain -- it's bad enough as it is with
at least five seperate gcc installations and three of Sun C++...
Debian has this, too, although that's more my impression after
using it for a bit at home rather than the result of trying to
look after a bunch of Debian machines.
Yes, I know I could just NFS-mount /usr, but that feels too
much like just begging for trouble. And there are some things
that live under /usr on a sane system which should really be
local.
Of course, my dislike for RH could very well be coloured by
having had to look after RH5.0 boxes at my last job, without
being "allowed" to upgrade them. :-)
The silly thing is that if they were offering a FreeBSD
version of VMware, we'd probably buy 50. Just to start.
Matt
--
Divide By Cucumber Error. Please Reinstall Universe and Reboot
Russ Allbery
> The basic problem IME with RH isn't doing the installs. It's keeping a
> heap of machines up-to-date. Last I recall (and I'll be glad to be
> corrected on this), which was around 5.0, there wasn't really any
> automated process for this - it was a case of download the RPMs, figure
> out what order to install them, then install. Debian makes this easier
> (as you've noted), but the BSDs make it so amazingly simple that even
> trying to keep a lot of Solaris boxes in sync seems scary (and it's not
> *that* difficult there, either - grab the latest patch cluster, install,
> Theoretically, anyway).
We don't bother doing that even; we just rebuild the machine periodically
from scratch off Jumpstart for Solaris servers. But we have the advantage
of a site-wide robust distributed file system, so we don't have to
preserve anything on local disk.
My experience with updating Red Hat from RPMs is pretty good. It seems to
me like you could just put together a list of packages and their order
that you need to update by fooling around on one box, and then once you
have it down, just stick it in a shell script and run it on all the
systems.
I don't have any experience with what *BSD does to make it easier, though.
I would assume that the other distributions have similar capabilities.
--
Russ Allbery (r...@stanford.edu) <URL:http://www.eyrie.org/~eagle/>
David Damerell
ObDistributionFlameage: not SuSE. Their package manager is not free
software, and they're in the KDE camp.
>I've looked at Debian, Red Hat, and SuSE. None of them
>really seem to do the "easy updating of a heap of machines"
>thing as well as FreeBSD does - is there a distribution I'm
>missing which comes anywhere near FreeBSD on this one?
Debian has a package called 'cfengine' which purports to do this; I have
no idea if it's any good or not, though.
Ah, hang on. 'man apt-get';
update update is used to resynchronize the package
overview files from their sources. The overviews of
available packages are fetched from the location(s)
specified in /etc/apt/sources.list.
upgrade
upgrade is used to install the newest versions of
all packages currently installed on the system from
the sources enumerated in /etc/apt/sources.list.
[and so forth]
That would imply that a single machine can be updated with two commands
(there's a dist-upgrade which attempts to sensibly resolve conflicts -
frex, when moving between versions of Debian and all the packages change
at once); you can easily add the proposed-updates directory to
/etc/apt/sources.list for security updates, and also NFS export (or
whatever) a 'local' packages directory.
I have no idea what FreeBSD can do in this regard, so I can't tell if
that's any good by comparison.
--
David/Kirsty Damerell. dame...@chiark.greenend.org.uk
"We have always been quite clear that Win95 and Win98 are not the systems to
use if you are in a hostile security environment." "We absolutely do recognize
that the Internet is a hostile environment." Paul Leach <pau...@microsoft.com>
Peter da Silva
Matt McLeod <Matt....@ericsson.com.au> wrote:
>I've looked at Debian, Red Hat, and SuSE. None of them
>really seem to do the "easy updating of a heap of machines"
>thing as well as FreeBSD does - is there a distribution I'm
>missing which comes anywhere near FreeBSD on this one?
There's Mastodon, which is working towards a Linux kernel with a
BSD userland.
--
This is The Reverend Peter da Silva's Boring Sig File - there are no references
to Wolves, Kibo, Discordianism, or The Church of the Subgenius in this document
"Be vewy vewy quiet...I'm hunting Jedi." -- Darth Fudd
Matt McLeod
>Matt McLeod <m...@labyrinth.net.au> writes:
>
>> The basic problem IME with RH isn't doing the installs. It's keeping a
>> heap of machines up-to-date. Last I recall (and I'll be glad to be
>> corrected on this), which was around 5.0, there wasn't really any
>> automated process for this - it was a case of download the RPMs, figure
>> out what order to install them, then install. Debian makes this easier
>> (as you've noted), but the BSDs make it so amazingly simple that even
>> trying to keep a lot of Solaris boxes in sync seems scary (and it's not
>> *that* difficult there, either - grab the latest patch cluster, install,
>> Theoretically, anyway).
>
>We don't bother doing that even; we just rebuild the machine periodically
>from scratch off Jumpstart for Solaris servers. But we have the advantage
>of a site-wide robust distributed file system, so we don't have to
>preserve anything on local disk.
When going from revision to revision, we do the Jumpstart thing
(like a couple of 2.4 machines we have sitting around the place).
While there isn't theoretically much reason to store stuff
locally, when you've got the current basic workstation having
a 9G disk in it, and /home constantly over 90%, people end up
storing stuff locally.
>My experience with updating Red Hat from RPMs is pretty good. It seems to
>me like you could just put together a list of packages and their order
>that you need to update by fooling around on one box, and then once you
>have it down, just stick it in a shell script and run it on all the
>systems.
It's the having to fool around on one system in the first place
that I object to - I've got better things to do, like figuring out
why isql has decided not to see the data in some fields, yet
just about anything else we throw at it (like SQL Advantage)
is perfectly happy...
>I don't have any experience with what *BSD does to make it easier, though.
No packages for the base system, for starters. A single source
tree, automated stuff for tracking whichever branch you prefer.
Keeps the base system up-to-date pretty easily. Anything else
lives in a file server, so you only need to keep one copy up to
date.
>I would assume that the other distributions have similar capabilities.
Most other Linux distributions are using RPM (or it seems that
way, anyway), and they seem to be making the same sort of assumptions
about stuff being kept locally. Debian avoids the figuring-out-
the-dependencies stuff.
It would *almost* be worth investing some time in building a
BSD-like Linux distribution, but given the standard VBC
cost-cutting stuff going round again I doubt I could get the
time approved to do it.
Matt McLeod
>In article <930638183.153622@brsi00>,
>Matt McLeod <Matt....@ericsson.com.au> wrote:
>>I've looked at Debian, Red Hat, and SuSE. None of them
>>really seem to do the "easy updating of a heap of machines"
>>thing as well as FreeBSD does - is there a distribution I'm
>>missing which comes anywhere near FreeBSD on this one?
>
>There's Mastodon, which is working towards a Linux kernel with a
>BSD userland.
Looks interesting, but it also looks like it wouldn't be
able to run VMware (which is the only reason why FreeBSD
isn't an option), so we might as well just run a real BSD.
Of course, it could probably be hacked to make it work
(by adding a more recent libc, for starters), but from
the info on the web site, at least, it looks like it isn't
really going to go the whole hog.
Jim Kingdon
> BSD userland.
Right, and I also ran into someone at LinuxWorld (I forget who) who
was at least playing with the idea of a Debian userland with a BSD
kernel.
Personally, I've found the Debian/Red Hat approach (that is, the
general concept of having most everything in packages) to be a great
improvement (being able to ask what package a file is part of, and so
on), and with something like apt-get it seems like it should work
nicely for the many-machines situation. But I suppose there is a
certain element of religion and/or whether apt-get really does
everything which you'd like it to.
Jim Kingdon
> keeping a heap of machines up-to-date. Last I recall (and I'll
> be glad to be corrected on this), which was around 5.0, there
> wasn't really any automated process for this - it was a case of
> download the RPMs, figure out what order to install them, then
> install.
I think we are all agreed that Red Hat is well behind systems like
Debian on this score. I don't expect this to remain true forever, but
there is no point in talking about vaporware.
> The other hitch with RH is that it seems to go for having everything
> installed locally
I guess my preferred solution to that would be to have a better way to
update a package on a bunch of local disks, rather than trying to make
it easier to NFS-mount /usr. While the latter could probably work
(maybe with some work, there are things like the RPM database which
would would presumably get confused about whether something is shared
with other machines or not), given that disks are big and networks are
slow, I'm not sure I see the point.
> Of course, my dislike for RH could very well be coloured by
> having had to look after RH5.0 boxes at my last job, without
> being "allowed" to upgrade them. :-)
Well, I'm very biased as well. Even before I went to work for Red
Hat, I knew lots of people there and this was a pretty tangible
benefit in terms of being able to get questions answered and such (if
I really needed to). Quite aside from technical merits or demerits.
David Damerell
>>There's Mastodon, which is working towards a Linux kernel with a
>>BSD userland.
>Right, and I also ran into someone at LinuxWorld (I forget who) who
>was at least playing with the idea of a Debian userland with a BSD
>kernel.
Debian GNU/ BSD has been worked on for a while; it presents much of the same
problems as Debian GNU/ Hurd, which the Hurd folks are very keen on and so
which gets a lot of attention; but I think Debian GNU/ BSD is more of an
'it would be nice if' thing. It would be nice to get Debian on all the
platforms the BSDs support, mind...
IMAO, the BSD/ Linux stuff is just a knee-jerk response to not liking
RMS's insistence on GNU/ Linux; I don't think it's going anywhere at all.
--
David/Kirsty Damerell. dame...@chiark.greenend.org.uk
CUWoCS President. http://www.chiark.greenend.org.uk/~damerell/ Hail Eris!
|___| Time for some bonking. I likes a bit of bonking! |___|
| | | (Trapdoor - British children's TV) | | |
Bryan C. Andregg
>FreeBSD (and presumably the other BSDs) are extremely easy to
>maintain in largish numbers -- you have one box keep in sync
>with the source tree, keep an eye on the appropriate mailing
>lists, and do the occasional build followed by make installworld'ing
>the rest (which are mounting /usr/src and /usr/obj from the first
>machine). Third-party stuff lives in /usr/local (and is generally
>installed on the servery box using the ports collection).
>Nice, simple, elegant.
1 server with up-to-date updates directory from the ftp site or a mirror.
50+ clients with the server's public RSA key allowing one way entry from
server to client.
1 script that basically does an "rpm --freshen <new rpms>"
Not that hard.
--
Bryan C. Andregg * <band...@redhat.com> * Red Hat, Inc.
1024/625FA2C5 F5 F3 DC 2E 8E AF 26 B0 2C 31 78 C2 6C FB 02 77
1024/0x46E7A8A2 46EB 61B1 71BD 2960 723C 38B6 21E4 23CC 46E7 A8A2
Bryan C. Andregg
>I think we are all agreed that Red Hat is well behind systems like
>Debian on this score. I don't expect this to remain true forever, but
>there is no point in talking about vaporware.
For my edification, how does debian handle this?
Matt McLeod
that Bryan C. Andregg did write:
>On 29 Jun 1999 12:22:51 GMT, Matt McLeod <m...@labyrinth.net.au> wrote:
>>FreeBSD (and presumably the other BSDs) are extremely easy to
>>maintain in largish numbers -- you have one box keep in sync
>>with the source tree, keep an eye on the appropriate mailing
>>lists, and do the occasional build followed by make installworld'ing
>>the rest (which are mounting /usr/src and /usr/obj from the first
>>machine). Third-party stuff lives in /usr/local (and is generally
>>installed on the servery box using the ports collection).
>>Nice, simple, elegant.
>
>1 server with up-to-date updates directory from the ftp site or a mirror.
>50+ clients with the server's public RSA key allowing one way entry from
>server to client.
>1 script that basically does an "rpm --freshen <new rpms>"
>
>Not that hard.
It is if you're on the other side of a firewall with
a b0rken proxy... :-(
This, of course, is also a problem for Debian.
(Non-issue with BSD, since I can get the updates by mail. Or
is RH offering a mailing-list to which all updates are sent?)
Matt
--
Matt McLeod "Stuff existentialism,
System Administrator I'm goin' back to momma"
ASAC, Ericsson Australia TISM
<m...@asac.ericsson.se>
Matt McLeod
that Bryan C. Andregg did write:
>>I think we are all agreed that Red Hat is well behind systems like
>>Debian on this score. I don't expect this to remain true forever, but
>>there is no point in talking about vaporware.
>
>For my edification, how does debian handle this?
Not sure on the technical details, but somehow or other
apt (or possibly dselect) "know" which order packages
need to be installed, and if something is needed which isn't
already installed, it'll go grab it from whatever sources
you've specified.
Matt
--
Matt McLeod "I'd love to go out with you,
System Administrator but I've been scheduled for
ASAC, Ericsson Australia a karma transplant."
<m...@asac.ericsson.se>
Ryan Tucker
Bryan C. Andregg <br...@redhat.com> spewed:
>1 server with up-to-date updates directory from the ftp site or a mirror.
>50+ clients with the server's public RSA key allowing one way entry from
>server to client.
>1 script that basically does an "rpm --freshen <new rpms>"
>
>Not that hard.
Is there any way to do something like rpm -fvh
ftp://swerver/updates/*.rpm and have it Work?
I know I'm lazy... if I wasn't, don't you think I'd check for myself?
;-) -rt (so what if it's 20 miles away?)
--
Ryan Tucker <rtuck...@ttgcitn.com> http://www.ttgcitn.com/~rtucker/
President, TTGCITN Communications Box 92425, Rochester NY 14692-0425
Please keep public threads public -- e-mail responses will be ignored.
Matt McLeod
>In <slrn7nkoob...@sideshow.redhat.com>,
>Bryan C. Andregg <br...@redhat.com> spewed:
>>1 server with up-to-date updates directory from the ftp site or a mirror.
>>50+ clients with the server's public RSA key allowing one way entry from
>>server to client.
>>1 script that basically does an "rpm --freshen <new rpms>"
>>
>>Not that hard.
>
>Is there any way to do something like rpm -fvh
>ftp://swerver/updates/*.rpm and have it Work?
>
>I know I'm lazy... if I wasn't, don't you think I'd check for myself?
>;-) -rt (so what if it's 20 miles away?)
I don't *think* so. Unfortunately, it seems that rpm doesn't
want to use a http-based proxy (Netcache in this case) for FTP,
either.
Anyone know of a mirror utility which will use such a proxy?
"mirror" wants a more sane FTP proxy (which I can get access
to, but first have to convince my manager to approve then pay
for access...)
Yes, despite not being an RH fan, I'm seriously considering it
as an option. If I can deal with the updates thing satisfactorily,
it should be OK, and at least the default desktop stuff is pretty
slick - and that counts for something if you're expecting your
CDE users to be happy with the switch...
Matt
--
Matt McLeod "I'd love to go out with you,
System Administrator but I'm having all my plants neutered."
ASAC, Ericsson Australia
<m...@asac.ericsson.se>
Ryan Tucker
Matt McLeod <Matt....@ericsson.com.au> spewed:
>I don't *think* so. Unfortunately, it seems that rpm doesn't
>want to use a http-based proxy (Netcache in this case) for FTP,
>either.
If it can use a HTTP-based proxy for HTTP, you can get the updates via
HTTP... http://www.rge.com/pub/systems/linux/redhat/updates/ is one
place.
>Anyone know of a mirror utility which will use such a proxy?
>"mirror" wants a more sane FTP proxy (which I can get access
>to, but first have to convince my manager to approve then pay
>for access...)
Tried wget? It might do something. -rt
Kai Henningsen
> I don't *think* so. Unfortunately, it seems that rpm doesn't
> want to use a http-based proxy (Netcache in this case) for FTP,
> either.
>
> Anyone know of a mirror utility which will use such a proxy?
Any LWP based perl script should do. LWP certainly can handle
ftp_proxy=http://localhost:3128/ with squid (I just tested that).
Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
- Russ Allbery (r...@stanford.edu)
Kai Henningsen
> Yea, it is written in the Book of Cyril
> that Bryan C. Andregg did write:
> >On 30 Jun 1999 10:47:20 -0400, Jim Kingdon <kin...@panix6.panix.com>
> >>wrote: I think we are all agreed that Red Hat is well behind systems like
> >>Debian on this score. I don't expect this to remain true forever, but
> >>there is no point in talking about vaporware.
> >
> >For my edification, how does debian handle this?
>
> Not sure on the technical details, but somehow or other
> apt (or possibly dselect) "know" which order packages
> need to be installed, and if something is needed which isn't
> already installed, it'll go grab it from whatever sources
> you've specified.
Typical Debian upgrade, command line style:
<make sure /etc/apt/sources.list still points to sane mirrors>
(I should mention that apt-get understands ftp, http, and file URLs.)
(And that you can point at various package sets on different servers,
such as different releases, local packages, and so on, all at the same
time)
apt-get update (fetches packages lists)
(I should mention dpkg-awk for searching package
lists)
<if this broke, restart at the top>
apt-get upgrade
apt-get dist-upgrade (trying to figure out package restructuring)
apt-get dselect-upgrade (processing stuff selected from dselect)
If there's something else you want, or if you only want to update a single
package, or stuff like that:
apt-get install <package> (apt will figure out any necessary support
packages or conflicts, and ask if there are
any)
apt-get clean (optional, remove downloaded packages from
caching directory)
Typical Debian upgrade, dselect style:
<make sure you have apt installed>
<make sure apt config is ok, see above - in dselect, [A]ccess>
In dselect, [U]pdate
In dselect, [S]elect and look through the list of new stuff (optional)
In dselect, [I]nstall
(I'm not sure if [R]emove is still necessary with apt)
In dselect, [Q]uit
Problems with the current state of Debian:
* installation will ask questions, so you need to stay around
* dpkg (the actual package tool) insists on installing everything in a
package, so you need to have all file systems writable
* you can't upgrade X from inside X (but you can upgrade everything from
inside telnet, I've done it often enough).
* When doing a large upgrade run, services can be turned off for a long
time.
(All of these have improvements planned, of course.)
If you just want to keep a lot of machines in sync (and possible mounting
/usr from a central server), there are easy solutions not involving the
distribution. For example, you can update selected directories of those
machines easily with rsync. (rsync can work over ssh, if you want. Debian
uses rsync to keep its main mirrors in sync - it's a lot better than ftp
mirror programs.)
Kai Henningsen
> It is if you're on the other side of a firewall with
> a b0rken proxy... :-(
>
> This, of course, is also a problem for Debian.
It must be pretty b0rken for that. Can you use a web browser? Then you can
update with apt. (In fact, apt prefers http for updates - it's lower
overhead than ftp.)
> (Non-issue with BSD, since I can get the updates by mail. Or
Ugh. That would be an extreme last resort, considering volume.
Kai
Richard Kettlewell
> I don't *think* so. Unfortunately, it seems that rpm doesn't want
> to use a http-based proxy (Netcache in this case) for FTP, either.
>
> Anyone know of a mirror utility which will use such a proxy?
> "mirror" wants a more sane FTP proxy (which I can get access to, but
> first have to convince my manager to approve then pay for access...)
Does wget do what you want? (Check a recent version - I have access
to 1.4.5 and 1.5.3 here and I'm pretty sure that the earlier of the
two won't do what you want.)
Georg Bauer
McLeod) wrote:
>Yes, despite not being an RH fan, I'm seriously considering it
>as an option.
There are some advantages of apt-get over the rpm: it uses http-proxies
quite nicely, it does the stuff needed to fetch and install updated
packages automatically, and the most important part: it does it in the
right order. I'd say that if you can go the way with prepackaged systems
(I know that not everybody accepts prepackaged binaries and that there are
lot of people out there that prefer to compile their own), I think that
Debian has the package mechanism that's goes most of the way. And in that
aspect it's much better than rpm.
It's one reason why we chose Debian as the base-distribution for our
business. Since several of our systems are at customers sites and only
part-time online, it's quite nice to just enter two apt-get commands to
get the system up-to-date. And to be sure that it will stay working during
that process, even if it involves major system changes.
Working dependencies in binary packages are really a good idea.
bye, Georg
Matt McLeod
>Matt....@ericsson.com.au (Matt McLeod) wrote on 01.07.99 in <930800415.357920@brsi00>:
>
>> It is if you're on the other side of a firewall with
>> a b0rken proxy... :-(
>>
>> This, of course, is also a problem for Debian.
>
>It must be pretty b0rken for that. Can you use a web browser? Then you can
>update with apt. (In fact, apt prefers http for updates - it's lower
>overhead than ftp.)
I was thinking in terms of keeping a local mirror of updates - I've
done Debian installs via Netcache before with no problems.
It's looking like wget may do what I need in this respect (haven't
had time to look at it properly today - as per usual all hell
broke loose on one of our production hacks).
(I should add that it isn't so much that Netcache is b0rken - it
actually seems to perform pretty well on most stuff - but that
large downloads tend to time out before they've completed, and
last I recall HTTP doesn't do regets. But since I've been
told that the cost of access to the real FTP gateway isn't an
issue, it doesn't matter so much longer term anyway).
>> (Non-issue with BSD, since I can get the updates by mail. Or
>
>Ugh. That would be an extreme last resort, considering volume.
It isn't a major problem with FreeBSD - it's just receiving
patches for the sourcetree, not binary packages. Most of
the differences between BSD and Linux don't bother me, but
the nice single source tree thing on BSD really appeals.
Matt McLeod
After a quick look at the manpage, it seems like it might. Although
I'm not certain how it'd handle trying to mirror an FTP site via
a HTTP proxy - unless it's got enough intelligence to be able
to handle the HTML "directories" returned by such a proxy.
Richard Kettlewell
> * you can't upgrade X from inside X (but you can upgrade everything
> from inside telnet, I've done it often enough).
IIRC you used to be able to upgrade X from an X session - I've always
been a bit disappointed that this doesn't work any more.
--
BORK BORK BORK FREE THE INTERNET BORK BORK BORK
Richard Kettlewell
> (I should add that it isn't so much that Netcache is b0rken - it
> actually seems to perform pretty well on most stuff - but that large
> downloads tend to time out before they've completed, and last I
> recall HTTP doesn't do regets. But since I've been told that the
> cost of access to the real FTP gateway isn't an issue, it doesn't
> matter so much longer term anyway).
HTTP has syntax for getting byte ranges, see RFC2068 14.36. How
widely implemented this is I do not know.
Matt McLeod
I've never seen it used -- at least, none of the clients I've
tried (admittedly only browsers - lynx, netscape, that sort of
thing) seem to support it.
Anyway, I now have the painful task of trying to decide which
Linux variant (if any) gets the nod. Not really looking
forward to that...
Robert Collier
<rich...@chiark.greenend.org.uk> wrote:
>IIRC you used to be able to upgrade X from an X session - I've always
>been a bit disappointed that this doesn't work any more.
I've upgraded X from an X session several times recently - where's the
problem?
- Rob.
--
Robert Collier Pilot Network Services, Inc
r...@pilot.net +44 (0) 20 7 464 8547
Kai Henningsen
> On 02 Jul 1999 10:18:50 +0100, Richard Kettlewell
> <rich...@chiark.greenend.org.uk> wrote:
>
> >IIRC you used to be able to upgrade X from an X session - I've always
> >been a bit disappointed that this doesn't work any more.
Never been possible in Debian AFAIR.
> I've upgraded X from an X session several times recently - where's the
> problem?
Surely not in Debian?!
The problem is that the X server install stops and restarts the X server.
It's a case of chopping the branch you're sitting on.
Kai Henningsen
> (I should add that it isn't so much that Netcache is b0rken - it
> actually seems to perform pretty well on most stuff - but that
> large downloads tend to time out before they've completed, and
> last I recall HTTP doesn't do regets. But since I've been
> told that the cost of access to the real FTP gateway isn't an
> issue, it doesn't matter so much longer term anyway).
Well, apt-get *does* download continuations with http IIRC. It's in the
standard, something about byte ranges.
> It isn't a major problem with FreeBSD - it's just receiving
> patches for the sourcetree, not binary packages. Most of
> the differences between BSD and Linux don't bother me, but
> the nice single source tree thing on BSD really appeals.
Well, you can at least theoretically do the same with Debian, though there
are still a number of snags that make it not work in practice. Some of
this is used to automate porting packages to different architectures.
There are a number of machines around trying to do that for Debian. Though
there is a certain amount of handholding necessary right now.
Georg Bauer
m...@labyrinth.net.au (Matt McLeod) wrote:
>I've never seen it used -- at least, none of the clients I've
>tried (admittedly only browsers - lynx, netscape, that sort of
>thing) seem to support it.
At least apt-get does use it. Or something similar - I don't know what
they exactly do, but they do have reget under http.
Richard Kettlewell
>> IIRC you used to be able to upgrade X from an X session - I've
>> always been a bit disappointed that this doesn't work any more.
>
> I've upgraded X from an X session several times recently - where's
> the problem?
Last time I did it it wanted to shut down xdm. It asked you first -
if you said no then it stopped in its tracks, if you said yes then all
X sessions on that machine disappeared.
Perhaps they've changed it again. The last time I did an upgrade
(rather than a fresh install) was a while ago, now. I've an upgrade
to do fairly soon though so we'll see.
Peter Maydell
>kaih=7K2JAe$Xw...@khms.westfalen.de (Kai Henningsen) writes:
>
>> * you can't upgrade X from inside X (but you can upgrade everything
>> from inside telnet, I've done it often enough).
>
>been a bit disappointed that this doesn't work any more.
Some stray neurons are telling me that you still can if you aren't
using xdm; I could well be wrong, though; it's been a while since I
upgraded...
Peter Maydell
Richard Kettlewell
> r...@pilot.net (Robert Collier) writes:
>> Richard Kettlewell <rich...@chiark.greenend.org.uk> wrote:
>>> IIRC you used to be able to upgrade X from an X session - I've
>>> always been a bit disappointed that this doesn't work any more.
>
> Never been possible in Debian AFAIR.
Could've sworn it used to work... *shrug*
> The problem is that the X server install stops and restarts the X
> server. It's a case of chopping the branch you're sitting on.
I don't think that's a sensible thing to do; you don't kill all copies
of telnetd or bash while upgrading those, why should X be different?
Peter Maydell
>r...@pilot.net (Robert Collier) wrote on 02.07.99
> in <377cb566....@news.lspace.org>:
>> problem?
>
>
>The problem is that the X server install stops and restarts the X server.
>It's a case of chopping the branch you're sitting on.
I just did a test 'upgrade' of xserver-svga_3.3.2.3a-11.deb and
xserver-common_3.3.2.3a-11.deb; although I didn't actually do it from
within X (simply because I have no mouse :-> and couldn't get focus on
the xterm) I did it with X running and it never restarted the X server.
[Obviously you're still running the old X server until you restart it;
but you can do that at your leisure.]
And the changelog mentions an xdm 'no-restart-on-upgrade' option, so you
should be able to configure it to allow you to do this...
(although I don't use xdm anyway :->)
Peter Maydell
Kai Henningsen
> kaih=7K6tP$fX...@khms.westfalen.de (Kai Henningsen) writes:
> > r...@pilot.net (Robert Collier) writes:
> >> Richard Kettlewell <rich...@chiark.greenend.org.uk> wrote:
>
> >>> IIRC you used to be able to upgrade X from an X session - I've
> >>> always been a bit disappointed that this doesn't work any more.
> >
> > Never been possible in Debian AFAIR.
>
> Could've sworn it used to work... *shrug*
>
> > The problem is that the X server install stops and restarts the X
> > server. It's a case of chopping the branch you're sitting on.
>
> I don't think that's a sensible thing to do; you don't kill all copies
> of telnetd or bash while upgrading those, why should X be different?
On further thought, I *think* it's xdm that was the problem. So if you use
startx or something like that instead, it might not bite you.
Actually, I've never been completely clear on *why* it did that, but it's
been doing it at least since the 0.9something days.