On Sat, May 23, 2015 at 01:52:25PM -0300, Fernando de Oliveira wrote: > On 23-05-2015 13:23, Ken Moffat wrote: > > You guys must be on more reliable systems than me ;-) In the last > > couple of weeks I have several times had vim hang on my server, and > > rather more times I've lost the network (nothing in the logs, but > > seems to be related to 4.0+ kernels - both stable and rc) while > > editing my notes using nfs. I'm very friendly with vim's .swp files, > > I would not want to put them in /tmp. > > > > ĸen > > > > No, I have had crashes. That is the reason I keep saving what I do with > vim (actually, gvim) as soon as I can or remember. > I try not to have many terms open with _unsaved_ changes - usually only two or three. Then I can usually remember what I was doing.
> Point is more having all ,swp in one place. You can create a /tmp-saved > with the same permissions as /tmp and use: > > " Prevent .swp creation in current directory > set directory=/tmp-save. > Sounds good, but for me keeping them in the current directory helps on those occasions when I'm using two machines and accidentally try to edit the same file on both. > I hated having to "find" vim's .swp's all over the place. Even in the > svn directories!!! > > That way, you save a lot of time when recovering from a crash. > > I also use that directory to keep sources files I'm editing for the > book, when it is necessary to reboot for checking if new packages work > properly. > > BTW, I'm now using > > $ uname -r > 4.0.4 > > and apart from vmplayer, everything else seems to be behaving very well. > My desktops have been stuck on 4.0.3 for this week (apart from a brief boot of 3.19.0 to confirm intel sna worked on that kernel with a current svn system). The losses of network were all on an AMD machine using r8169, but that might have been coincidence. Oh, and to expand on what I said - the vim hangups on my server were over ssh, and the server is running a fairly recent 3.18 kernel. I've never seen that happen until this week, but then twice. Thanks for mentioning 4.0.4 - I suppose I ought to test that on the intel just in case the sna problem disappears (unlikely, but it sort-of looks more like a kernel problem). But first I need to try to sort out my least-powered desktop box (the one which also runs i686 and windows) - a couple of weeks ago I saw log messages saying it had run backup scripts from fcron when I was fairly sure it had been powered off - somehow, it had turned on and then booted the default option in grub. The next time I tried to boot it, nothing until I turned off the power, fiddled about with the connections to no obvious effect, and then tried again. Today it is again not coming alive, I need to close down the intel box before I turn off the power. Sometimes, hardware can be a PITA and that box is only about 2 years old. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
