On 11/23/2018 08:42 AM, Per Jessen wrote:

Liam Proven wrote:

...

I have a new desktop. \o/

I want to copy my home directory -- all of it -- from my old one to my new one. They're on the same LAN. I do not have write access to a local fileserver, though.

So what's the best way? I don't really want to do it over ssh, because there's no need for encryption -- it's pointless overhead. For a one-off, it doesn't matter. Just use rsync.

You do have the ssh server running on the new laptop and the ssh port open in the firewall, right?  I agree with Per, rsync is perfect for this task. BTW, you can configure rsync to use rsh instead of ssh if you really want to ditch encryption.  I use it this way for a customer who has four big servers in two adjacent equipment racks.  We have 10-GigE connections between the servers and we can transfer large files almost three times faster without the encryption.  It makes a big difference when you need to move 10TB between systems!  Of course the 10-GigE subnet and switch are isolated from external networks, so there's no significant security threat.  Of course, you have to install rsh and rshd and figure out how to configure them, but this is all fun, right? Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 23/11/2018 19.27, Carlos E. R. wrote:

On 23/11/2018 17.19, Liam Proven wrote:

...

I have a new desktop. \o/

I want to copy my home directory -- all of it -- from my old one to my new one. They're on the same LAN. I do not have write access to a local fileserver, though.

So what's the best way? I don't really want to do it over ssh, because there's no need for encryption -- it's pointless overhead.

Doesn't matter if your network is gigabit. If it is 10 gig, then it is a consideration.

...

Old machine runs Tumbleweed. New one has Tumbleweed, Leap 15 and Win10. Neither is a server for anything at all.

One way is to setup an nfsserver in one of them, and the other is using rsync. If you setup an rsync server in one of them, it should run faster.

I basically use:

rsync --archive --acls --xattrs --hard-links \ --sparse --stats --human-readable --checksum \ /home/ /backup/current/home

Example using an rsync server: server side: /etc/rsyncd.conf: [Mail] uid = cer path = /home1/cer/Mail auth users = cer secrets file = /etc/rsyncd.secrets comment = To make backups of email hosts allow = 192.168.1.127 192.168.1.129 /etc/rsyncd.secrets: # user:passwd cer:xxxxxxxxxxxxxxxxxxxx And enable rsync in xinetd.d: /etc/xinetd.d/rsync: # default: off # description: rsync file transfer daemon service rsync { socket_type = stream protocol = tcp wait = no user = root server = /usr/sbin/rsyncd server_args = --daemon } On client: RSYNC_PARAMS="-a --password-file /home/cer/mailsync.key --exclude .imap/" cd ~/Mail rsync $RSYNC_PARAMS Telcontar.valinor::Mail/in_* . /home/cer/mailsync.key: xxxxxxxxxxxxxxxxxxxx Just that single line. Notice that the password file do not have the same format on server or client. You may want to disable the server side after the job is done. Yet another way to do it: set NFS server on one machine, then use rsync "locally". Or even "mc'. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 26/11/2018 13.15, Liam Proven wrote:

On 23/11/2018 19:46, Carlos E. R. wrote:

...

Yet another way to do it: set NFS server on one machine, then use rsync "locally".

That looks the least intimidating.

After some fumbling, I now have an NFS server working and I can mount a remote folder.

Bizarre as this may seem, in 30y of using Unix and *nix machines, this is the first time I have ever used NFS. Yes, really.

:-)

...

Or even "mc'.

I can manage with the shell. :-D

'mc' can, or could, connect to another machine on ssh and present the filesystem with a "click", and thus copy the entire tree. But a long lasting bug handicaps connecting via ssh. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 26/11/2018 16.22, Liam Proven wrote:

On 26/11/2018 14:10, Carlos E. R. wrote:

...

'mc' can, or could, connect to another machine on ssh and present the filesystem with a "click", and thus copy the entire tree.

...

But a long lasting bug handicaps connecting via ssh.

Ah, I did not know that...

<https://bugzilla.novell.com/show_bug.cgi?id=856501> And we discussed it here: <https://lists.opensuse.org/opensuse/2014-12/msg00500.html> Subject: [opensuse] mc in 13.2: no "shell link" So, long time ago... My workaround is to use sshfs. I create empty directory "~/fusermount/", then: sshfs cer@machine:/ ~/fusermount/ then mc to "~/fusermount/" and finally: fusermount -u ~/fusermount_l to exit the mount. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 24/11/2018 00:50, L A Walsh wrote:

    How big is your 'home'?  What type of network are you using for transfer? (100Mb/1000Mb/1Gb/10Gb), wired/wireless.

Quite big -- ~200 GB. It's a gigabit LAN.

    To be honest, I haven't benched NFS v. SMB/CIFS in a VERY long time, but SMB was notably faster about 10-20 years ago and its gotten faster since then, though I'd assume NFS would have too.

I've got NFS working now, so I'll probably use that.

    What file system type?(if 'xfs', then xfsdump|xfsrestore maybe with a 'mbuffer' before the restore on the destination might be best -- will capture any Xattrs/acls (if any).  Newest versions of cp & tar will too, check the docs. cp doesn't seem as fast as it used to -- not sure why, but if small enough transfer size, it may not matter.

XFS. I don't know how to use xfsdump like that, though...

    For most situations, anything will work, if you have a large home with xattrs/acls, make sure they get xfered as well.

I don't think so.

If you don't like ssh and if your network between the two computers is internal-only, then setup rsh -- you'll get noticeably more speed on a fast network, then disable it/turn it off before you expose it to the outside world.

I tried that. Authentication doesn't seem to work. The only instructions I could find are for SUSE 11 and seem to be out-of-date.

BTW, congratulations! :-)

Well, a colleague quit, and his nice new workstation was sitting there all unloved, so I asked for it... -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/26/2018 7:22 AM, Liam Proven wrote:

XFS.

I don't know how to use xfsdump like that, though...

Similar to how you would use 'tar' to do the same. But I have a shell script i wrote a few years back cuz I could never remember all the options (attached). If you aren't root already, it will try to use sudo to become root. It tries to prioritize the work to optimize the speed. I stuck 'mbuffer' in between them to create a smoother run. #!/bin/bash -u # trival fulldisk copy using xfs_{dump,restore} & mbuffer - lwalsh # sets cpu and iopriorities to optimize copy speed # $1=source # $2=target # ensure enough args if (($#!=2)) ; then echo "xfscopy needs source and target mount points" exit 1 fi PATH="/usr/sbin:/sbin:/usr/bin:/bin:$PATH" #ensure util paths are first # ensure privs (root or sudo) export sudo="$(type -P sudo)" function sudo { if (($(id -u))); then [[ ! $sudo ]] && return 1 $sudo -n -- "$@" else exec "$@" fi } export -f sudo read uid < <(sudo id -u) if [[ $uid != 0 ]]; then echo "Must have admin privs"; exit 1; fi # xfsdump ops: # -b = blocksize # -l = level (0=all) # -J = inhibit inventory update # -p = progress report every # seconds # next to last arg is '-' for stdout/in & out # last arg is for source or destination mount points mbuffer_size=1024M xfs_bs=128k xfs_report_interval=300 # setting restore proc's cpu+disk io "higher" than "dump"s helps # prevent filling memory and thrashing # prios c:1=real(don't use), 2=best-effort(timeshare); 3=idle # in Best effort, -n=0-7 where 0=highest, 7=lowest, but not strict! dump_cprio=-19 restore_cprio=-5 dump_dprio="-c3" restore_dprio="-c 2 -n3" #construct command for echo & running cmd=" nice $dump_cprio ionice $dump_dprio \ xfsdump -b $xfs_bs -l 0 -p $xfs_report_interval -J - $1 | nice -1 mbuffer -m $mbuffer_size -L | nice $restore_cprio ionice $restore_dprio \ xfsrestore -b $xfs_bs -B -F -J - $2" echo $cmd sudo bash --norc -c "$cmd"

On 27/11/2018 09:33, L A Walsh wrote:

On 11/26/2018 7:22 AM, Liam Proven wrote:

...

XFS.

I don't know how to use xfsdump like that, though...

Similar to how you would use 'tar' to do the same. But I have a shell script i wrote a few years back cuz I could never remember all the options (attached).

If you aren't root already, it will try to use sudo to become root.

It tries to prioritize the work to optimize the speed.

I stuck 'mbuffer' in between them to create a smoother run.

Wow. Thank you for that! Genuinely. It looks very clever, I am sincerely impressed, and I have no idea how it works or exactly what it does. But I don't want to sync a whole disk, just a single directory tree... and because I have no idea how that works, I can't tell if it can do that, or if I can modify it in order to do that... -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 24/11/2018 à 02:46, David T-G a écrit :

but computers are good at that. So ... what's the real impact? If the dir is small enough, it won't take noticeably longer. If it's big, I'd be off watching a movie (or sleeping) anyway and wouldn't care.

rsync is far the best way, because long copy can be interrupted and restarted. I happen to have stopped a computer because I forgot a copy was running, it's as simple as restarting it next day jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 24/11/2018 22.57, David T-G wrote:

Hi, all --

...and then jdd@dodin.org said... % % Le 24/11/2018 à 02:46, David T-G a écrit : % % >but computers are good at that. So ... what's the real impact? If the ... % rsync is far the best way, because long copy can be interrupted and

I am inclined to agree, but I of course run rsync over ssh. I still don't know how much that really matters, despite all of the discussion of turning off encryption. And, of course, I'm too lazy to benchmark it ;-)

Anyone? ...

Depends on the network speed. Up to Gigabit, I think a relatively modern computer can fill the pipe using ssh. I would have to actually measure speed to be fully sure.

% restarted. I happen to have stopped a computer because I forgot a % copy was running, it's as simple as restarting it next day

Oui :-)

Indeed. And if you are somewhat paranoid, it can do CRC comparison between original and copy. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

Op maandag 26 november 2018 21:50:13 CET schreef ken:

...

% rsync is far the best way, because long copy can be interrupted and

Interesting. Does one simply re-run the same rsync command...? or are there options which must be included in the first (interrupted) invocation of rsync and/or the second invocation? rsync actually syncs. What was not changed in the meantime won't be synced again.

-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 26/11/2018 à 21:50, ken a écrit :

...

% rsync is far the best way, because long copy can be interrupted and

Interesting.  Does one simply re-run the same rsync command...?

yes, very same jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/24/18 5:02 PM, Carlos E. R. wrote:

...

Depends on the network speed. Up to Gigabit, .... I would have to actually measure speed to be fully sure. If there are any rsync developers listening, it would be a handy option which, based on options and args and a brief net speed test, would give a close estimate of the time it would take to perform the transfer. I've seen other network file transfer utilities' progress meters give such estimates (while a transfer is already underway, and yes those estimates can vary widely during the course of the transfer), but in cases such as we're discussing here it would be useful at least to have a range, fastest to minimum, of the time required for the specified files to be transferred. Eh, if you have a couple of days of spare time, you might read the manual

Op maandag 26 november 2018 22:24:59 CET schreef ken: pages of rsync. I think it's already available in the numerous options. -- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Op maandag 26 november 2018 22:48:23 CET schreef Carlos E. R.:

On 26/11/2018 22.28, Knurpht-openSUSE wrote:

...

Op maandag 26 november 2018 22:24:59 CET schreef ken:

...

On 11/24/18 5:02 PM, Carlos E. R. wrote:

...

Depends on the network speed. Up to Gigabit, .... I would have to actually measure speed to be fully sure.

If there are any rsync developers listening, it would be a handy option which, based on options and args and a brief net speed test, would give a close estimate of the time it would take to perform the transfer. I've seen other network file transfer utilities' progress meters give such estimates (while a transfer is already underway, and yes those estimates can vary widely during the course of the transfer), but in cases such as we're discussing here it would be useful at least to have a range, fastest to minimum, of the time required for the specified files to be transferred.

Eh, if you have a couple of days of spare time, you might read the manual pages of rsync. I think it's already available in the numerous options.

Huh? Where? I read the manual almost entirely, years ago, and such a thing escaped my attention.

The word "estimate" is just once in the manual and it is not that.

It can display stats, but they are confusing.

--progress That's what I meant, the --progress option. I use luckybackup ( an rsync frontend ) and maybe that confused me by calculating and presenting me with an ETA.

-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 29/11/2018 06:05, ken wrote:

IF it were run, i.e., without actually running it... or prior to actually running it.

Rsync has a "dry run" option to do exactly that. I think it's the ``-n'' option. It doesn't copy any data, it just tells you what data it _would_ copy. It takes, or should take, about the same time as the actual process, *if* you're syncing existing file sets on both ends and the changes are small. The downside is that if your sync will take, say, 2 hours, it will take you 2 hours to find that out. In other words, in total, it will take you 4 hours: it doubles the length of the task, the exact problem I was describing earlier. -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 29/11/2018 06.05, ken wrote:

Is luckybackup a GUI app?  I'd prefer if it weren't, but if it could provide an estimate of the total time for a transfer (~380G without deletes), and do so without actually doing any of the transfer, well, the I guess I could give it a try. 

Just to be as clear as possible and avoid confusion, I'm not looking for any kind of progress "meter" (though that might be helpful if the rsync copy will take ten hours or so), MUCH less looking for a GUI, but rather just an estimate of the time the rsync copy (to a new space) IF it were run, i.e., without actually running it... or prior to actually running it.

Thanks up front.

What I do is that I use my own script to do the backup, and write in the script an echo statement that writes how long it took the last time I did the backup. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

Le 27/11/2018 à 12:28, Liam Proven a écrit : please don't speak about Windows :-))

Non-time-based, non-proportional time indicators are fine.

E.g. "processed file XXX" which increments, or "processed XXX $units_of_storage"

is it possible to have this with rsync? even "-v" is very time consuming thanks jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 27/11/2018 22:28, Carlos E. R. wrote:

Thanks! Very interesting :-)

You're very welcome. This was one of those things that for a long time I just assumed everyone knew... then it has become apparent in the last ~dozen years (since Vista) that apparently lots of people _didn't_ know, and indeed, that this lack of knowledge was percolating up the chain. The time it hit me personally was upgrading a customer's installation of MS Office XP to SR1. This was so big, for the time -- several hundred megabytes, zipped, in 2002 and thus before many people had broadband -- that optionally you could request it on CD. He did. The CD contained a self-extracting Zip that extracted into the current directory. So you couldn't run it directly from the CD. It was necessary to copy it to the hard disk, temporarily wasting ¼ GB or so, /then/ run it. The uncompressed files would have fitted on the CD. That was a warning sign; several people failed in attention to detail and checks. (Think this doesn't matter? The tutorial for Docker instructs you to install a compiler, then build a copy of MongoDB (IIRC) from source. It leaves the compiler and the sources in the resulting container. This is the exact same sort of lack of attention to detail. Deploying that container would waste a gigabyte or so per instance, and thus waste space, energy, machine time, and cause over-spend on cloud resources. All because some people just didn't think. They didn't do their job well enough. So, I copied the self-extractor, I ran it, and I started the installation. A progress bar slowly crept up to 100%. It took about 5-10 minutes. The client and I watched. When it got to 100%... it went straight back to zero and started again. This is my point: progress bars are actually quite difficult. It did this SEVEN TIMES. The installation of a service release took about 45 minutes, three-quarters of an hour, plus the 10 minutes wasted because an idiot put a completely unnecessary download-only SEA onto optical media. The client paid his bill, but unhappily, because he'd watched *me* wasting a lot of expensive time because Microsoft was incompetent at: [1] Packaging a service pack properly. [2] Putting it onto read-only media properly. [3] Displaying a progress bar properly. Of course it would have been much easier and simpler to just distribute a fresh copy of Office, but that would have made piracy easier than this product is proprietary software and one of Microsoft's main revenue-earners, so it's understandable that they didn't want to do that. But if the installer had just said: Installation stage x/7: Progress: [XXXXXXXXXX..........] That would have been fine. But it didn't. It went from 0 to 100%, seven times over, probably because first the Word team's patch was installed, then the Excel team's patch, then the Powerpoint team's patch, then the Outlook team's patch, then the Access team's patch, then the file import/export filters team's patch, etc. etc. Poor management. Poor attention to detail. Lack of thought. Lack of planning. Major lack of integration and overview. But this was just a service release. Those are unplanned; if the apps had been developed and tested better, in a language immune to buffer overflows and which didn't permit pointer arithmetic and so on, it would have have been necessary. But the Windows Vista copy dialog box, as parodied in XKCD -- that's taking orders from poorly-trained management who don't understand the issues, because someone didn't think it through or explain it, or because someone got promoted to a level they were incompetent for. https://en.wikipedia.org/wiki/Peter_principle These are systemic problems. Good high-level management can prevent them. Open communications, where someone junior can point out issues to someone senior without fear of being disciplined or dismissed, can help. But many companies lack this. I don't know yet if SUSE has sorted these issues. I can confirm from bitter personal experience that Red Hat suffers badly from them.

Some software gives an estimate which is constantly adjusted. In the end, it matches ;-)

(yast install does that ;-P )

OK. Another answer is to concede that the problem is hard, and display a "throbber" instead: show an animated widget that shows something is happening, but not how far along it is. That's what the Microsoft apps team often does now. Personally, I hate it. It's better than nothing but it conveys no useful information.

It may give an estimate of the maximum time needed, after it does the scanning of files and it knows how many files to try copy. This could be adjusted after some time copying files and calculating an average. There are of course many variables: time to do the compare, time to do the crc check (if requested or needed), time to do the copy...

I'd prefer an indicator that says "stage 6 of 15, copying file 475 of 13,615." I may not know which files are big or small, which stages will be quick or slow... but I can see what it's doing, I can make an approximate estimate in my head, and if it's inaccurate, well, I can blame myself and not the developer. And nobody has to try to work out what percent of an /n/ stage process with /o/ files of /p/ different sizes they're at. That's hard for someone to work out, and it's possible that someone can't tell them a correct number of files or something... so you can get progress bars that go to 87% and then suddenly end, or that go to 106%, or that go to 42% and then sit there for an hour, and then do the rest in 2 seconds. I'm sure we've all seen all of those. I certainly have. -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 24/11/2018 02:46, David T-G wrote:

I've enjoyed reading this thread, but I'm confused. Yes, it's pointless, but computers are good at that. So ... what's the real impact? If the dir is small enough, it won't take noticeably longer.

200 gig. It will take a while. And it seems so _wasteful_... it's on an internal office LAN, from one desk to the next...

If it's big, I'd be off watching a movie (or sleeping) anyway and wouldn't care.

I wish. It's on work time...

I can't help but wonder if all of the talk and configuration effort has taken longer than an encrypted copy anyway :-) But this is the sort of question I love to ponder, so I'm actually interested...

I am learning stuff here. It's been a very typical Linux community sort of response. Half a dozen different, contradictory methods, some with as many sub-options, people vigorously disagreeing over their merits, some described in detail, some merely hinted at. Everything I could have hoped for. If you asked a Mac or Windows community, it'd be "link to a shared drive, select, drag, drop on the destination." :-D -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 26/11/2018 à 17:50, Dave Howorth a écrit :

Well you can do that now. If you presuppose a shared drive, which you've now set up with NFS, then pretty much any graphical file manager will handle the copy :)

beware hidden files and permissions (and file size) if the shared disk is fat32 :-( share with ext4 and copy as root to have no problem jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 26/11/2018 22:51, Carlos E. R. wrote:

I would not do it that way, because they are slooowww...

See my comment above about time estimates... - -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEeNZxWlZYyNg7I0pvkm4MJhv0VBYFAlv9KoAACgkQkm4MJhv0 VBb/eQ/+JN0wij/x07ERFjhnLEi7iwEz1EoqeoPJ9eYzShzbhZUyKe/WS3YPfY5O VRe9Xg0gzjdEeAkffOk12lFaocULzykak4O57HId6wm6cczFiulWtC9Almq4r1gC pMuGsNXTtJJJVpWTOTDON4OK85viobfIthfxlbjoQqaHsWzHw+6uEmH6DivESjyB eXhMAN2+m3vurRT5AKhdc57sODJF3e6FRHAbcRDQKcVFh3ast7EqXwZYn66zuZOA AXy5xeMXDSyOs0m2/RfZsuXsZTBDuXLC95zZ2lCTuEyiMdfubpxpnh2KRBPpdyAz 8pwfwiWmex2A8yaBLHPDw07ZbIQyEqJ634ee8LyvXGQBT+16iah5LuOOd9P16rgx QoArSFGPUz4iQEAs1jOAHe3izpp/6BRg5SDU2AKu3FrEizdcxjb5t8C77IPLr3ab zVqGnPyMwriibb0G5UDwZH8UjHjts28jkhv2muLPfpBa/OMta4bxiV5x05CVwf1v k76exC0v9wvy+DJPVMxMhiu+qAnkShH1cwyspo27I3M4KwBxbHe0Ik7OA8syiE7f YY0OsQm2a++TJcwiSJFOWntQoAB3tw3OIWZndsgH3eJocZW2hxq6epfj8VCFbKzH j4aLHVIB3AotXDOQBy6gEU8zxfC5avIRvZ/qcJOq3ujihOtZyZs= =+iOF -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hi again, all -- ...and then Liam Proven said... % ... % It's been a very typical Linux community sort of response. Half a dozen % different, contradictory methods, some with as many sub-options, people % vigorously disagreeing over their merits, some described in detail, some % merely hinted at. [snip] Oh, yeah -- and from what I can tell it pretty much only makes a difference if you have a slow machine with fast disk and fast network. Since I have a decent machine and lousy disk & network, so I'm safe ;-) HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org