Re: libraries being removed from the archive
On Tue, 05 Aug 2003 07:32:57 +0200, Matthias Urlichs wrote: Hi, Peter Mathiasson wrote: [...] distcc sends the complete preprocessed source code across the network for each job. Hmm, OK, but that would just speedup the actual compilation. Granted, that's the largest chunk, but cpp/asm/ld could do with a speed-up too. As a point of information, distcc runs the assembler remotely too (in this case, on the x86). cpp's CPU usage is usually negligible, and while ld can be slow it is often a small fraction of the total time. Building a cross suite with the excellent Debian toolchain-source package is easy, and I regularly use that to have several x86 machines help with ia64 builds. For many packages the biggest problem is actually ./configure, since it is slow and not parallelizable. -- Martin
Re: proposal: per-user temporary directories on by default?
On Fri, 25 Jul 2003 23:11:04 -0400, Matt Zimmerman wrote: On Fri, Jul 25, 2003 at 07:33:25PM -0600, Dwayne C. Litzenberger wrote: rant Personally, I'd rather see a better set of tools for programmers to use to create temporary files. tmpfile(3) is horribly inadequade for a lot of things (like when you need to know the filename of the file you just created) mkstemp(3) Just by the by: mkstemp(3) is inadequate for some cases, such as creating temporary files to pass to gcc. mkstemp changes the final characters of the filename, but the file extension is important to gcc (and other programs). Sometimes you need /tmp/tmp12345.i. I mention this just as an example where developers with the best of intentions have no choice but to use a nonstandard method to create files. Certainly this can be done safely, but to return to my original point: it's good if there is additional protection beyond hoping that every program is correct. -- Martin
Re: proposal: per-user temporary directories on by default?
On Fri, 25 Jul 2003 19:33:25 -0600, Dwayne C. Litzenberger wrote: On Sat, Jul 26, 2003 at 09:16:44AM +1000, Matthew Palmer wrote: Not necessarily. With the current /tmp system, the only directory entries that are created are the ones that are actually needed at any given time. If we switch to /tmp/username, then there will be a directory entry in /tmp for *every user* who ever logs on. Hang about. You seem to have two different systems running here. One where files get cleaned out of /tmp sometimes, and one where they don't. No, I'm not, actually. tmpreaper works by absolute time, like 7 days. *Many* users can log into a system during that amount of time, but they probably won't all be creating temporary files that they don't clean up shortly after. With libpam-tmpdir, it doesn't matter whether the user doesn't even have a home directory (i.e. system users, qmail users, nobody, etc) -- they will all cause an entry to be created in /tmp/user. I'm having trouble imagining a system where the working set of active uids is so large that creating one directory for each of them stresses the filesystem. A machine with hundreds of users probably ought to use ext3 directory hashes, reiserfs or xfs. Do I think using libpam-tmpdir by default would work? Yes, at least for the short term. However, I also think it's a band-aid solution for the real problem (excessive /tmp vulnerabilities), and it introduces problems of its own. I think the real problem is the original misdesign of /tmp: requiring systems to have a world-writable directory, and making a large number of programs deal with the issues of world-writable directories was a horrible idea. Why make programs and users be careful when all they really want is some private scratch space? -- Martin
Re: proposal: per-user temporary directories on by default?
On Fri, 25 Jul 2003 13:27:04 -0600, Dwayne C. Litzenberger wrote: I'm not trying to start a flamewar. You asked Is there *any* reason why defaulting TMPDIR=/tmp/username is inferior to TMPDIR=/tmp?, I answered, and now you're being hostile and dismissive. That is a reasonable question to ask. I think Dwayne has pointed out two reasons: 1- Creating per-user directories might be expensive. 2- There are some problems with the current libpam implementation. #1 is not quite invalid, but I don't think it is the overriding concern here. The disk used by an empty directory is negligible. Machines which are very tiny, or have thousands of users can set up their own system. There are a large number of insecure scripts out there, and very likely still some applications with tmpfile holes. I don't think a minor or probably negligible performance issue justifies leaving these problems open. #2 is a reason to fix libpam-tmpdir, not to stick with a shared /tmp. Dwayne, can you think of anything aside from those two? - Bob logs in. /tmp/bob is created - Bob leaves his terminal xlocked for a week - in the meantime, tmpreaper cleans up /tmp/bob - Mllory creates a new /tmp/bob, allowing for later attacks - Bob comes back and runs some shell script he wrote (under the assumption that /tmp/bob would always be safe -- something which would not have happened with the regular /tmp) - Mallory executes a symlink attack As Dwayne probably discovered, this would be impossible because the actual directory is (say) /tmp/users/1001, and only root can write to /tmp/users. As someone else mentioned in this thread, libpam-tmpdir creates a single /tmp/user and /tmp/user/$uid/. If /tmp/user already exists but with the wrong permissions, it fails. Yes, that is a problem with the current code. It is not a problem with the general idea of per-user temp directories. There are various ways to fix it, including - Creating /tmp/user as root during startup before Mallory can log in - Putting this somewhere other than /tmp -- say /usertmp, mode 711. (But I suppose people will think it's ugly and I can't think of a good name.) Perhaps tmpreaper could be set up not to never reap /tmp/user. It is a little ironic that the issue of making sure /tmp/user is the real one is exactly what I hope to avoid by moving away from 1777 /tmp. Oddly, it doesn't seem to set the environment variables properly when using su, though it seems to be creating the correct directories. But neither does pam_env.so (anyone know why?). Does su mop the environment? -- Martin
Re: proposal: per-user temporary directories on by default?
On Fri, 25 Jul 2003 22:52:43 -0400, Joey Hess wrote: Dwayne C. Litzenberger wrote: - in the meantime, tmpreaper cleans up /tmp/bob Just FWIW, but a multiuser system that is running tmpreaper is insecure. The bugs apparantly cannot be fixed, but I can write up an exploit if you pay me. :-) Private temporary directories will help to some extent. It's not a complete solution, because people can still play tricks with the temporary files created by setuid programs they have run. On the other hand if we could hold down the attack to only setuid programs (which one hopes are more careful anyhow) it would be a benefit. Directory size matters less and less anyway, modern fileystems use btrees, and this includes ext3 with -O dir_index. Not default yet, apparently. If it was the deciding factor in getting this adopted, I would write the 20-line patch to make libpam-tmpdir use multi-level directories. But as you say I don't think it would be a big deal for most (if any) systems. -- Martin
Re: proposal: per-user temporary directories on by default?
On Wed, 23 Jul 2003 11:26:58 +0200, Tollef Fog Heen wrote: * Christoph Hellwig | On Wed, Jul 23, 2003 at 02:09:28PM +1000, Martin Pool wrote: | There is already a PAM modules, libpam-tmpdir which automatically sets | this up on login by creating a per-user directory under /tmp and | pointing TMPDIR at it. Despite the scary low version number of 0.04 | it seems to work reliably and presumably any bugs could be fixed. | | Nice idea, wrong implementation. Let login fork the login shell with | CLONE_NEWNS and do a VFS-binding from ~/tmp to /tmp. Presumably you'd want to add this through a PAM module rather than hacking it right into login, otherwise gdm, ssh etc wouldn't be consistent. Having decided to do it through PAM, is it really necessary to change the VFS rather than setting $TMPDIR? Making it impossible to get to the real /tmp makes it a bit more intrusive and potentially confusing than really seems necessary. Given that there is a TMPDIR variable which is obeyed in most cases, using it seems to be easier than remapping /tmp. Fixing programs which are hardcoded to /tmp to use TMPDIR is pretty trivial. Making sure that operations in a world-writable directory are secure can be very hard. A PAM module which does VFS setup would be pretty cool, but I don't think that's the one Debian should use by default. CLONE_NEWNS is 2.4.19 and higher only. Also, ~ might be on NFS or similar where you don't want to put temporary files. (And about the version number of libpam-tmpdir: it could just as easy have been 0.4, in which case nobody would have thought it was «scaringly low». Yes, I'm upstream for it.) Thanks for writing it. I couldn't find any web pages about libpam-tmpdir other than the Debian package. It might be nice to put up just a small one so that it's easier for other systems to find. If we were to put it in as default, I'd like to clean up the code a bit.. it should be safe, but it could use a little tidying up. There are small issues I'll discuss offline. I'm not sure if this is featurism, but you might add a parameter to allow people to set the path. /tmp/users/$uid/ is a good default but people might possibly want it in /home or elsewhere for disk space or other reasons. -- Martin
Re: proposal: per-user temporary directories on by default?
On Wed, 23 Jul 2003 17:14:09 -0400, Joey Hess wrote: Martin Pool wrote: At the least I would like to see Debian prompt for this at installation much as it does for shadow passwords. Ideally it would be on by default. I'm all for this idea. Thanks. What needs to be done to have it adopted? Since I use static per-user in home tmp directories I have not looked at libpam-tmpdir though. I suppose that enabling it currently requires making some modifications to many of the pam.d files? Yes, it does. This is a slight problem: it would be nice if there were a way to say this session module should apply to all services, but I don't think there's any way to do that in PAM. It could be done in either libpam or a Debian script that generates the files, but it's not strictly needed. For the time being I suppose it could just be applied to the services for which it is most relevant: login, ssh, gdm, kdm, xdm, etc. -- Martin
Re: proposal: per-user temporary directories on by default?
On Thu, 24 Jul 2003 16:58:33 -0500, Steve Langasek wrote: Does the PAM module *create* /tmp/username if it's not there? Actually it is /tmp/users/uid at the moment, and yes, it creates both levels securely. -- Martin
Re: proposal: per-user temporary directories on by default?
On Thu, 24 Jul 2003 16:56:50 -0600, Dwayne C. Litzenberger wrote: On Thu, Jul 24, 2003 at 02:50:05PM -0500, Steve Greenland wrote: Please don't. Is there *any* reason why defaulting TMPDIR=/tmp/username is inferior to TMPDIR=/tmp? Systems with large numbers of users (and normally use, for example /home/u/username), and filesystem which doesn't like large numbers of entries quickly might have performance problems. The issue is having a number of directories under /tmp/users/uid, each with a moderate number of files, vs having a large number of files directly under /tmp. It will depend on the particular case but I don't think the first will be be worse than the second. Indeed the two-level case with /tmp/users/uid is closer to the setup you mention. The tmpdir for an active user is likely to be in the dcache much of the time, which means that accessing files in it may well be faster than looking through an enormous /tmp/ shared by all users. If people are running a tmpreaper, then it will reap the directories of any users who have not used them for n days. On machines with many users who are intermittently active the case is quite different to /home, where all the directories have to exist all the time. Administrators for whom this is a concern can always override it from a profile script. Anyhow, I don't think a highly speculative possible performance issue justifies neglecting a concrete security improvement that would have effectively protected users from a number of existing problems. And then there's the issue of making *really sure* that /tmp/username always exists and has the correct permissions, I think doing this once and properly in libpam-tmpdir is more likely to be secure than various administrators or programs trying to get it right. I have already done a quick audit of the source and filed some (fairly minor) bugs; other people are welcome to do do too. I am not saying that libpam-tmpdir is eternal and perfect in its current state. There are some issues that could be improved. But I would like Debian to move towards per-user tmp as a general idea. otherwise this would be worse, because once we do this, people will probably stop caring about creating temporary files securely. Well, those people would be pretty damn foolish, because the issue will still exist on almost all other Unix systems or on systems that reset TMPDIR. -- Martin
proposal: per-user temporary directories on by default?
There has been about one temporary file vulnerability in Debian per month since the start of the year. Given the number of relatively unaudited programs that create temporary files and the possible complexity of tempfile vulnerabilities, I am not sure that all the problems will be found and fixed any time soon. In addition, on many machines there are probably a fair number of local programs and scripts that make tempfiles insecurely. Most of the vulnerabilities could be hidden by per-user tempdirs. That's not to say they should not be fixed for the benefit of people on other systems or out of general cleanliness, but making them unexploitable would be highly desirable. There is already a PAM modules, libpam-tmpdir which automatically sets this up on login by creating a per-user directory under /tmp and pointing TMPDIR at it. Despite the scary low version number of 0.04 it seems to work reliably and presumably any bugs could be fixed. At the least I would like to see Debian prompt for this at installation much as it does for shadow passwords. Ideally it would be on by default. Perhaps some programs rely on temp files that are readable across accounts, though I can't really think of any such. To fail, I think they would have to create a temporary file as one user and then need to access it as another non-root user. That seems a bit contrived. It's possible there are some programs that are hardcoded to /tmp, but that should be straightforward to detect, find and fix. Doing this through PAM may cause issues with daemons that are started by root but then change to another account that is not able to access root's tmpdir. However it ought to be straightforward to resolve this if there is a general principle of per-user directories. I think if the daemon is started through su it will be OK. -- Martin
Re: plagiarism of reiserfs by Debian
On Wed, 23 Apr 2003 21:43:24 -0500, Manoj Srivastava wrote: On Thu, 24 Apr 2003 11:46:32 +1000, Martin Pool [EMAIL PROTECTED] said: On Tue, 22 Apr 2003 17:53:14 -0500, Manoj Srivastava wrote: I was intentionally using moderate language because (a) I don't believe it is strictly plagiarism (as you say), You need a modifier strictly there? You think it was loosely plagiarism? We are going over old ground here: Various organizations contributed to development of reiserfsprogs. They were credited in the upstream source, but acknowledgment of their contribution was completely removed from one version of the Debian package. Failing to give credit where it is due is not a million miles away from plagiarism. If you start out by being rude, what ought you to expect? I am not in the business of defending Hans's negotiating technique. The fact that the outcome reached meets your desires in no way mitigates the bias you were displaying. Can you be more specific about what bias I am supposed to have? Wanting Debian to fawn over authors... You are simply exaggerating, and it's a bit silly. If you do not think your view point is biased, then I am sorry to say I am not wearing those blinkers. You're sorry because you wish you were wearing blinkers? -- Martin
Re: plagiarism of reiserfs by Debian
On Wed, 23 Apr 2003 15:10:45 -0500, Adam Heath wrote: On Wed, 23 Apr 2003, Hans Reiser wrote: Ed has graciously agreed to restore the credits, and I thank Debian for its respect for the wishes of the original author in regards to prominently crediting those who have contributed. I'm glad to hear that. Again, what does Debian(as a community/organization) have to do with a maintainer fixing a minor bug? Imagine you are the developer of some random piece of free software. You don't necessarily use Debian; you certainly don't understand all its systems and protocols. The conventional way to get in touch with the developers of a free software project to raise an issue is to write to the -devel list. It's not surprising that this is what people do with debian. By all means suggest they write to [EMAIL PROTECTED], but there's no need to flame people for doing the normal and reasonable thing. -- Martin
Re: plagiarism of reiserfs by Debian
On Tue, 22 Apr 2003 17:53:14 -0500, Manoj Srivastava wrote: On Tue, 22 Apr 2003 16:59:59 +1000, Martin Pool [EMAIL PROTECTED] said: For example, at least two people called Hans a troll. An upstream author expressing concern about the way their code is packaged is not trolling (i.e. making random arguments just to provoke flames.) I find it interesting that you consider a public accusation of plagiarism to be merely expressing concern. I was intentionally using moderate language because (a) I don't believe it is strictly plagiarism (as you say), and (b) because I don't think inflaming the debate by tossing around words like plagiarism (or troll, slander, etc) is very helpful. (Had I thought about it more, I would have realized the second one goes completely against the behaviour expected on -devel, which is apparently to be as personal and negative as possible.) However, I also find your judgment in this horribly tainted, which leads me to place less credence in the rest of your argument, sorry. Well, Hans and Ed seem to have arrived at exactly the outcome I was arguing for, so I suppose I can't have been completely wrong: despite that Debian has the legal right to change the code, it should seek compromise between the author and the distribution's goals. You need to get past the emotional upset you felt (understandably) at Debian being accused of plagiarism. (Well, it seems to have been resolved without your help, so I suppose you can stay upset if you prefer.) Or the blindingly obvious choice: Your blatant spin displays a bias so huge that your arguments are no longer credible? It's a sorry day when wanting Debian to give some consideration to the opinions of original authors is huge bias. -- Martin
Re: plagiarism of reiserfs by Debian
On Mon, 21 Apr 2003 23:22:36 -0400, Glenn Maynard wrote: On Tue, Apr 22, 2003 at 12:25:39PM +1000, Martin Pool wrote: We don't care what the author wants, we have the legal right to change what we like is not a good message to send. Even if you don't Thankfully, Debian isn't sending this message. For me (as an author whose software is in Debian) this is exactly how it comes across. Some people here apparently delight in pissing off upstream authors who object to the way their software is modified. There are plenty of posts saying that Debian can do what it likes, and precious few acknowledging that Hans ought to have any say in what is done to the software he wrote. Authors have a moral right (and a legal one in some places) not to have their work mutilated. I personally would not have put such a large and informal notice in my software, but perhaps Hans has good reasons, such as promising the sponsors that they would be prominently acknowledged. (That seems to be required by some research grants.) Debian should not stomp all over the author's intentions if it is reasonably avoidable. The alternatives do not seem to have been adequately explored. It ought to be obvious that removing a author/sponsor notice would be likely to offend. It's not obvious. Removing a sponsorship notice is something I'd do without a second thought; it's nothing more than advertisement and it's just as annoying to me as a banner ad. I say it ought to be obvious, because Hans put the message in there intending it to be prominent, rather than (say) putting it in a doc file. It is reasonable to assume that he cared about putting this message in front of everyone who used it. If you can't understand why removing it would annoy him then I really doubt your ability to cooperate with other people. -- Martin
Re: plagiarism of reiserfs by Debian
On 22 Apr 2003, Michael Tindal [EMAIL PROTECTED] wrote:
Authors have a moral right (and a legal one in some places) not to
have their work mutilated.
I do not consider removing 20-something lines of output from a
program whose purpose is to create a filesystem mutilating it. By
contrast, mkfs.ext[2,3] and mkfs.xfs do not output such messages,
simply the status of the task at hand. As an author, I can see how
these messages severely hinder usability. They would be more
appropriate in a CREDITS or AUTHORS file.
I agree that a file would be a more appropriate location. I'm just
asking that Debian persuade Hans rather than unilaterally removing it.
Note that reiserfsprogs-3.6.4-4.diff has in fact not moved the credits
to another file, but *removed them entirely*. The sponsors of the
program are not mentioned at all in the Debian package. This is
unconscionable.
Prominently does not necessarily imply causing the program to be
unusable.
That kind of hyperbole is not helpful.
unusable
adj 1: impossible to use [syn: {unserviceable}, {unuseable}]
2: not able to perform its normal function [syn: {inoperable}]
--
Martin
Re: plagiarism of reiserfs by Debian
On Tue, 22 Apr 2003 02:09:39 -0400, Glenn Maynard wrote: On Tue, Apr 22, 2003 at 01:19:17AM -0400, Michael Tindal wrote: I do not understand your accusations here. No one stated what you said, and no one has delibaretly attempted to upset Hans. Quite the contrary, actually. I have seen _several_ people attempting to find a compromise, Indeed. I don't know where Martin is getting that from; he certainly didn't provide any citations. People on the Debian side have been extremely reasonable (at least when talking to Hans; not when talking to, say, Ben Collins ...) For example, at least two people called Hans a troll. An upstream author expressing concern about the way their code is packaged is not trolling (i.e. making random arguments just to provoke flames.) I'm glad to see people are trying to find a compromise. I'm sure one is possible with some goodwill. Perhaps Ed or Hans can post more history if it can't be resolved offline. -- Martin
Re: plagiarism of reiserfs by Debian
On Sun, 20 Apr 2003 22:45:59 -0500, Steve Langasek wrote: On Mon, Apr 21, 2003 at 06:54:42AM +0400, Hans Reiser wrote: It is really a question of, do you respect the authors? Who do you respect, Hans? Many Debian Developers are also Free Software authors. How much respect are you showing us with your brazen accusations of impropriety? How would you like it if somebody distributed your software with changes you didn't like, and with your name filed off? It's not so hard to understand that it might at least momentarily make you feel offended and reconsider whether using the GPL was really a good idea. Do you realize that after a brace of beautifully crafted non-specific rants on your part, most members of the Debian community reading this thread have *no idea* what offense you're referring to? It seems fairly easy to understand that Hans is upset that Debian has removed the startup message from mkfs. By modifying the program against the wishes of the upstream maintainer Debian is creating what some people call a hostile fork. Certainly the GPL allows anybody to fork projects, but I'd hope it's clear that gratuitous forking is not polite behavior, nor in the long term interests of either Debian's users or the project itself. Not everything that is permitted is beneficial. We don't care what the author wants, we have the legal right to change what we like is not a good message to send. Even if you don't use the package in question, other maintainers reading this thread might be less willing to cooperate with Debian in future. There is some validity to #152547; in some circumstances having a big banner at startup is inconvenient. However just cutting it out is not a good way to resolve the bug. The maintainer made a mistake here. It ought to be obvious that removing a author/sponsor notice would be likely to offend. It would have been much better to contact the upstream author and ask for a shorter message, a --quiet option, or displaying the message during installation, etc. Please talk to the upstream author about changes, especially in sensitive areas. Please don't just unilaterally fork unless there is no alternative. A little cooperation is needed. -- Martin
Re: XFree 4.2.0 - again
On 16 Apr 2002, Lasse Karkkainen [EMAIL PROTECTED] wrote: Forgot to cc this to the list.. The message is attached. Here's another clue, for free: when somebody specifically replies to you rather to the list, and points that out in the message body, they probably had a reason. Going back on to the list is not perfect etiquette. It's the hardware support. People are getting sick of VGA/VESA. I thought that it would be obvious. Hyperbole is not making you any more credible. For example, I'm using a 64MB FireGL2 (which does not even support VESA) on Brendan's xf86 4.1. the problem is that I know next to nothing about Debian. So I see. :-) Please do some reading first. You might, for example, start here: http://www.tuxedo.org/~esr/faqs/smart-questions.html http://www.tuxedo.org/~esr/writings/homesteading/homesteading/ (I know not everybody loves esr, but I think most would agree he's more informed here than Lasse.) Assuming you actually want to get better software and not just start flamewars those documents should help. Also, if Branden is working on 4.1.0, why doesn't someone else do 4.2.0? Sounds like two separate projects to me. The thing about most free software lists is that people are basically not interested in your opinion about this until you can demonstrate that it is an *informed* opinion. Since you've admitted and demonstrated you don't actually know anything much about XFree86 or Debian (socially or politically) you're not doing well so far. Offering money comes second to having a clue, but it ought to be something reasonably related to the effort involved, like say USD10k. I have a feeling you had about $10 in mind. Then I'll be spending lot of time in the local library, trying to learn how *nix/Debian work, That would be good. Keep away from the email terminals :-) Lasse, if you need more help understanding why your bozo bit just got set, then please reply to me, not to the list. -- Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rsync and debian -- summary of issues
On 13 Apr 2002, Brian May [EMAIL PROTECTED] wrote: On Fri, Apr 12, 2002 at 10:19:27PM +1000, Donovan Baarda wrote: The big problem with rproxy is it's implemented in perl (perl: crypto for There might be some other unrelated program called rproxy that's in Perl, but the one I wrote certainly is not. It's just C. apt-proxy is written in sh (or bash?). I believe it has been statically linked with libhsync. That's the old name for librsync. -- Martin You know, if Jesus comes back to Earth, I bet the last thing he'll want to see again is another cross. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rsync and debian -- summary of issues
On 12 Apr 2002, Jason Gunthorpe [EMAIL PROTECTED] wrote: nobody8835 25.7 0.3 22120 1740 ?RN Apr10 525:24 rsync --daemon nobody 22896 5.0 0.3 22828 1992 ?SN Apr11 21:20 rsync --daemon nobody3907 7.3 0.5 22336 2820 ?RN Apr11 15:30 rsync --daemon nobody 10729 13.7 4.0 22308 20904 ? RN Apr11 13:10 rsync --daemon The load average is currently 7 all due to rsync. I'm not sure what that one that has sucked up 500mins is actually doing, but I've come to accept that as 'normal'. I expect some client has asked it to recompute every checksum for the entire 30G of data and it's just burning away processor power sigh. Hi, I've changed my opinion on this since we last talked, partly because of taking over rsync itself, and partly because of learning more about the problem space. I'd hope it was possible to make things work better, either by fixing bugs or by giving the sysadmin more range to restrict expensive operations. What I'd really like is to have access to one of these machines and be able to attach debuggers to rsync and see what it's doing. (In this case, that would mean being able to ssh in as 'nobody', or something equivalent.) I realize there might be some security difficulties with doing that, but if we can get past them it would be good for rsync, and hopefully also for Debian. If direct access is impossible then maybe somebody who can ssh to the machine can work with me. -- Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rsync and debian -- summary of issues
On 12 Apr 2002, Martin Pool [EMAIL PROTECTED] wrote: I've changed my opinion on this since we last talked, partly because of taking over rsync itself, ... what I meant, but people other than jgg probably didn't know, is that I was looking at installing rproxy and I'd now rather fix rsync. -- Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rsync and debian -- summary of issues
On 11 Apr 2002, Robert Tiberius Johnson [EMAIL PROTECTED] wrote: Thanks for all your hard work on rsync. I think it is a great tool. I'm especially excited to hear it is used in Intermezzo. I like your rsync/debian web page. I'm glad you like them.[0] I feel you aren't fair to diff (in Section 2.1). For example, I diffed two Packages files, and then compressed the diff. I also computed the xdelta of the files. The compressed diff was smaller (by 10%-20%). It's quite true that diff will do much better for some cases, and the Packages file is one of them. I'll update the document to be more fair about that. Of course the most important advantage of rsync is what tridge calls the morning after pill: you don't have to still have a copy of the old file to be able to generate a diff relative to it. If we accept that it's not reasonable for servers to retain information about every previous version of a package, then something related to rsync is the most likely solution. Also, in section 3.15, you say, Fetching a series of deltas which update the same area is less efficient than calculating the deltas directly. This is true, but by my computations, the number of packages which change more than once in a month is 300, which require about 30K of wasted bandwidth. Sorry, I don't understand what the 30kB number relates to. Is that only for the updates to the Packages file? -- Martin [0] I'm obviously too polite to stay on debian-devel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
rsync and debian -- summary of issues
There seems to be a thread about rsync and Debian packages every couple of months. I've written up a document which tries to cover all of the questions and debates. It's pretty informal, but hopefully will be useful. http://rsync.samba.org/rsync-and-debian/ I'd appreciate comments. -- Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rsync and debian -- summary of issues
On 12 Apr 2002, Brian May [EMAIL PROTECTED] wrote: I think some more details is required regarding rproxy. I've added a lot more detail about rproxy, and my understanding of Goswin's proposal. Let me know if they're unclear. Why is nobody actively developing it? I'm not sure what kind of answer is possible for that question, since it is really foreach programmer in the world: why are they not hacking on rproxy? Nevertheless I have tried to explain more about it on the web site. AFAIK, it solves all the problems regarding server load discussed in rsync, doesn't it??? Why did you think that? rproxy addresses a rather different problem to rsync: for example, it transfers only one file at a time, not whole directories. No, rproxy does not have a magic way to do the delta computation in zero time. Compared to rsync, rproxy has the advantage of cleaner code (imho), but the disadvantage that no optimization work has been done. -- Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
